Hands-on Lab·Certified Kubernetes Security Specialist
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 - tunnel/VXLAN, with Hubble relay and UI
- Host OSUbuntu 26.04 LTS, kernel 7.0.0-29
- Built withkubeadm v1.36.3 - podSubnet 10.244.0.0/16, serviceSubnet 10.96.0.0/12
- TimeAbout 22 min
- Reviewed25 August 2026
Written against the versions above. 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.
| 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 |
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