Skip to content
intermediate Phase 2 · Cluster Setup & Management

Cluster Upgrades

Master Kubernetes cluster upgrade strategies including rolling upgrades and version management.

1h
0 problems
Topic Progress 0%

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?

Question 1 options

2. Which command makes a node safe to upgrade?

Question 2 options

3. Why is a control-plane downgrade unsupported?

Question 3 options

Flashcards

Question

kubelet skew rule

Answer

Never newer than kube-apiserver; at most three minor versions older.

Question

Upgrade order

Answer

etcd backup → apiserver → controllers/scheduler → kube-proxy/CoreDNS → kubelets one by one.

Question

drain vs cordon

Answer

Cordon marks unschedulable; drain also evicts running pods so workloads move.

Question

Rollback strategy

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.

Continue Learning