CKA — Upgrade Planning

1 minute read

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 ->

Updated: