CKA — Upgrade Planning
Why Cluster Upgrades Matter
Kubernetes releases a new minor version roughly every four months. Each version brings security patches, bug fixes, and new features. Running outdated versions means missing security fixes and eventually losing community support.
In the CKA exam, you will be asked to upgrade a cluster from one minor version to the next — for example, from v1.29.0 to v1.30.0.
Version Skew Policy
Kubernetes enforces strict rules about which component versions can run together.
| Component | Allowed Skew from API Server |
|---|---|
| kube-controller-manager | Same or one minor version older |
| kube-scheduler | Same or one minor version older |
| kubelet | Same or up to two minor versions older |
| kube-proxy | Same minor version as kubelet |
| kubectl | +/- 1 minor version |
Key rules:
- You can only upgrade one minor version at a time (v1.29 -> v1.30, NOT v1.29 -> v1.31)
- Always upgrade the control plane first, then the worker nodes
- Components on the control plane should be upgraded before worker node components
Upgrade Order
1. Upgrade kubeadm on control plane
2. kubeadm upgrade plan
3. kubeadm upgrade apply
4. Upgrade kubelet & kubectl on control plane
5. Drain each worker node (one at a time)
6. Upgrade kubeadm on worker node
7. kubeadm upgrade node
8. Upgrade kubelet & kubectl on worker node
9. Uncordon the worker node
10. Repeat 5-9 for remaining workers
Pre-Upgrade Checklist
Before starting any upgrade:
- Back up etcd (see etcd Backup & Restore)
- Read the release notes for the target version
- Check version skew — ensure you are only upgrading one minor version
- Verify cluster health — all nodes Ready, all system Pods Running
- Check PodDisruptionBudgets that might block draining
# Verify current state
kubectl get nodes
kubectl get pods -n kube-system
kubeadm version
Exam tip: Always back up etcd before upgrading. The exam may not explicitly ask for it, but it is best practice and shows deeper understanding.
Next: Drain & Cordon Nodes ->