Version Skew Rules
Version Skew Rules
Kubernetes releases three times a year, and the compatibility rules constrain your plan:
- kubelet must not be newer than kube-apiserver and may be up to three minor versions older.
- kubectl supports one minor version either direction against the apiserver.
- You cannot skip minors: 1.28 to 1.30 passes through 1.29.
That yields the canonical order: backup etcd → apiserver → scheduler and controller-manager → kube-proxy and CoreDNS → kubelet, node by node. Read release notes per hop; deprecated APIs such as batch/v1beta1 CronJob must be migrated before the apiserver drops them, or those objects stop serving.
Executing the Upgrade
Executing the Upgrade
kubectl drain node-2 --ignore-daemonsets --delete-emptydir-data
# on the control-plane node:
sudo kubeadm upgrade plan
sudo kubeadm upgrade apply v1.30.4
sudo apt-mark unhold kubelet kubeadm
sudo apt-get install kubelet=1.30.4-1.1 kubeadm=1.30.4-1.1
sudo systemctl restart kubelet
kubectl uncordon node-2
Repeat drain → upgrade kubelet → uncordon per worker while checking kubectl get nodes for the new version and kubectl get pods -A for anything CrashLooping. Managed providers compress this into a control-plane action plus a node-group roll.
A complete etcd snapshot taken first is your rollback path — control planes do not support downgrade.
Pitfalls and Rollback
Pitfalls and Rollback
Pitfall 1 — draining the last schedulable capacity. Roll one node at a time, respect PodDisruptionBudgets, and expect prompts: unmanaged DaemonSets are skipped with --ignore-daemonsets, and pods with local storage need --delete-emptydir-data or eviction stalls.
Pitfall 2 — kubelet before apiserver. That inverts the skew rule and can destabilize the node. apiserver first, kubelet last.
Interview-ready: recite the skew rules, the upgrade order, and your verification commands. For failure: pause the roll, inspect kubectl describe node and kubelet logs, restore etcd from the pre-upgrade snapshot if state is corrupt — and explain why downgrades are unsupported once storage versions migrate forward.
Quiz
1. Can kubelet run two minor versions behind kube-apiserver?
2. Which command makes a node safe to upgrade?
3. Why is a control-plane downgrade unsupported?
Flashcards
Question
kubelet skew rule
Click to reveal answer
Answer
Never newer than kube-apiserver; at most three minor versions older.
Question
Upgrade order
Click to reveal answer
Answer
etcd backup → apiserver → controllers/scheduler → kube-proxy/CoreDNS → kubelets one by one.
Question
drain vs cordon
Click to reveal answer
Answer
Cordon marks unschedulable; drain also evicts running pods so workloads move.
Question
Rollback strategy
Click to reveal answer
Answer
Pre-upgrade etcd snapshot plus paused rollout — downgrades across minors are not supported.
Revision Notes
Key Takeaways
- 1. Upgrade one minor at a time in apiserver-before-kubelet order
- 2. Snapshot etcd before touching anything
- 3. Verify with get nodes, get pods -A, and rollout status after each step
Interview Tips
- • Quote the skew policy numbers rather than hand-waving "versions should match"
- • Describe a failed upgrade as a pause-diagnose-restore procedure with concrete commands
Cheat Sheet
Skew: kubelet ≤ apiserver, ≥ apiserver-3. Order: backup → control plane → add-ons → kubelet per node. Drain with --ignore-daemonsets; snapshot first, no downgrade.