CNI and add-on upgrades — the post-control-plane migrations

The CNI and add-ons run after the control plane upgrade. They are the cluster’s data plane and DNS layer; upgrading them requires the control plane to be at the new version. This lesson walks the post-control-plane upgrades.

The order

flowchart LR
    A[Control plane at new version] --> B[Upgrade CNI]
    B --> C[Upgrade CoreDNS]
    C --> D[Upgrade kube-proxy]
    D --> E[Upgrade ingress controller]
    E --> F[Validate]

The CNI is first because it owns the cluster’s network fabric. CoreDNS is next because it depends on the cluster DNS. kube-proxy follows. Ingress controllers are last.

The CNI upgrade

Cilium

helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --version 1.16.x \
  --values cilium-values.yaml

The upgrade is rolling: Cilium’s DaemonSet replaces the agent pods one at a time. The cluster’s network is uninterrupted.

Calico

kubectl apply -f calico-v3.28.yaml

The Calico manifests include the Typha (if used), the DaemonSet, and the CRDs. The upgrade is rolling.

Flannel

kubectl apply -f flannel-v0.24.yaml

Flannel is a simple CNI; the upgrade is a manifest replacement.

The CNI compatibility check

Each CNI publishes a compatibility matrix:

Verify the CNI’s compatibility with the new version before the upgrade.

The CoreDNS upgrade

helm upgrade coredns coredns/coredns \
  --namespace kube-system \
  --version 1.11.x \
  --values coredns-values.yaml

The CoreDNS upgrade is a Deployment rollout. The pods are replaced one at a time.

kubectl rollout status deployment/coredns -n kube-system

The rollout is complete when all replicas are at the new version.

The kube-proxy upgrade

The kube-proxy is updated via the kubeadm upgrade:

sudo kubeadm upgrade apply v1.34.1

The upgrade apply command updates the kube-proxy manifest in /etc/kubernetes/manifests/. The kubelet restarts the kube-proxy pods on each host.

Alternatively, kube-proxy can be installed via a DaemonSet:

kubectl -n kube-system set image ds/kube-proxy \
  kube-proxy=registry.k8s.io/kube-proxy:v1.34.1

The DaemonSet rollout replaces the pods one at a time.

The ingress controller upgrade

nginx ingress

helm upgrade ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --version 4.10.x \
  --values ingress-values.yaml

The upgrade is rolling; the ingress controller’s pods are replaced one at a time.

Traefik

helm upgrade traefik traefik/traefik \
  --namespace traefik \
  --version 3.0.x \
  --values traefik-values.yaml

HAProxy

helm upgrade haproxy haproxytech/kubernetes-ingress \
  --namespace haproxy-controller \
  --version 1.10.x

The CRD upgrade

Some add-ons (Cilium, Calico, cert-manager) ship with CRDs. The CRDs are upgraded first:

kubectl apply -f crds-v1.16.x.yaml

The CRD upgrade is one-way; the CRDs evolve to the new schema. Pre-existing CRs are preserved.

flowchart LR
    A[Read CRD release notes] --> B[Apply new CRDs]
    B --> C[Update chart values]
    C --> D[helm upgrade]
    D --> E[Validate]

The validation

After all add-ons are upgraded:

kubectl get pods -n kube-system
# All add-on pods Running at the new version

kubectl get nodes -o wide
# All nodes Ready at v1.34.1

# Smoke test
kubectl run nginx-test --image=nginx --rm -it --restart=Never --command -- nginx -v

# DNS test
kubectl run dns-test --image=busybox --rm -it --restart=Never -- nslookup kubernetes.default

# Service test
kubectl expose deployment nginx-test --port=80
kubectl run curl-test --image=curlimages/curl --rm -it --restart=Never -- curl -s http://nginx-test

The cluster is fully upgraded.

Cross-course references

• The Terraform course covers IaC-managed add-on upgrades.
• The Observability course covers alerting during add-on upgrade windows.
• The Helm course covers chart versioning and rollout strategies.

Quiz

Production discipline

• Check the compatibility matrix first. Always.
• Upgrade in order: CNI, CoreDNS, kube-proxy, ingress. Network first, then DNS, then ingress.
• Backup CRDs before upgrading. The CRDs may evolve.
• Validate at each step. kubectl get pods -n kube-system; smoke tests.
• Test on staging. Add-on upgrades are cluster-specific.
• Document the upgrade. The chart versions, the values, the rollback path.

The post-control-plane upgrades are the cluster’s data plane. Operating them well is following the order, checking compatibility, and validating at each step.