Upgrading Kubernetes to Patch Vulnerabilities
"Upgrade Kubernetes to avoid vulnerabilities" is a competency and a task you can be handed, and it is the one place where getting the order wrong turns maintenance into an outage. This guide upgrades a live cluster, verifies the control plane and the node separately, and shows why the version in kubectl get nodes is the one that tells you whether you finished.
Cluster Hardening Guide 13 of 40 Advanced
- Kubernetesapiserver v1.36.4, kubelet v1.36.3
- Runtimecontainerd 2.2.6
- CNICilium 1.18.1
- Built withkubeadm v1.36.3
- TimeAbout 22 min
Run on cka8001, the single-node cluster this path uses for anything that touches the control plane. kubeadm and kubelet binaries were backed up to /root before being replaced.
- Host kernel7.0.0-29
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA8001 | 192.168.0.56 | Ubuntu 26.04 LTS | Single Node (control plane, untainted) | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when a cluster has to be upgraded to pick up a fix. This matters because kubeadm upgrade apply does not touch the kubelet - so the upgrade is only half finished at the point most people stop.
- establishing where the cluster is, across four versions that do not all agree
- running
kubeadm upgrade plan, which changes nothing at all - upgrading the kubeadm binary, verifying its digest first and keeping the old one
- upgrading the control plane, then reading carefully what it did not do
- draining the node, replacing the kubelet by hand, and checking every layer before putting it back
Before you start
-
Where the cluster is before anything is touched
-
The plan, which is a read-only command
-
Upgrade the kubeadm binary, verified first
-
Upgrade the control plane, and read what it did not do
-
Take the node out of service, then replace the kubelet
-
Wait for it, check every layer, and put it back