Hands-on Lab·Certified Kubernetes Administrator
Upgrading a Cluster with kubeadm
A real minor-version upgrade of a two-node cluster, control plane then worker. The order is not negotiable and the first obstacle is not kubeadm at all: the apt repository is pinned to one minor version, so the newer packages are invisible until you change it.
Cluster Architecture and Configuration Guide 22 of 103 Advanced
- Kubernetes1.35.8 to 1.36.4
- Cluster2 nodes
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 50 min
- Reviewed21 August 2026
Upgraded from the versions above. Package version strings such as 1.36.4-1.1 include a Debian revision. Use the exact string apt-cache madison prints.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA3001 | 192.168.0.185 | Ubuntu 26.04 LTS | Control Plane Node | 2 Core | 4 GB | 50 GB |
| CKA3001-NODE01 | 192.168.0.186 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
Before you start
- A kubeadm cluster at least one minor version behind, and root on every node.
- The etcd backup guide, done first. Take a snapshot before upgrading anything; there is no downgrade.
- The control plane guide, for why the control plane components are static Pods and what that means when one does not come back.
-
Where we start
-
The first obstacle is apt, not kubeadm
-
Repoint the repository
-
Upgrade kubeadm, and only kubeadm
-
The plan, now that kubeadm knows what 1.36 is
-
Apply it: the control plane
-
The kubelet, which kubeadm does not upgrade for you
-
Certificates were renewed as a side effect
-
Drain the worker
-
On the worker: upgrade node, not upgrade apply
-
Uncordon, and verify the whole thing