BM: Baca dalam Bahasa Melayu
World K5: Lunch Rush
Cluster upgrades and version skew
You will learn: how far apart a cluster's parts may be, and the safe order to upgrade them.
Checked with Kubernetes 1.37 on 31 Oct 2026
The problem
The Kubernetes project patches only the three newest minor versions: 1.37, 1.36 and 1.35. Your old cluster runs 1.34. What is the risk?
Pick one answer.
Watch
kind-dev namespace defaultYour kubectl, the API server and each stall’s kubelet all have versions. version skew: How far apart the versions of a cluster's parts may be, and still work together. is how far apart they may be and still work together.
Try it
The API server runs 1.37. Which parts are close enough?
Drag a card into a box. Or tap the card, then tap the box.
Watch
So the API server goes first, and stalls follow. Put a minor upgrade in order.
First step at the top. Put these in order. Use the arrows, or drag.
- Uncordon it, then do the next stall
- Drain one stall
- Read the release notes for removed APIs
- Upgrade that stall’s kubelet
- Upgrade the control plane, API server first
Predict
Your control plane runs 1.35. Can you upgrade it straight to 1.37?
Pick one answer.
Try it
Practise the stall routine. Drain dev-worker. Pretend you upgrade its kubelet. Then uncordon it.
kind-dev namespace defaultdev-control-planeOpenManagerNo trays here.
dev-workerOpen- shop·b7f55
- shop·jwjsl
dev-worker2Open- shop·fsjkb
Hint
Firstkubectl drain dev-worker --ignore-daemonsets, then kubectl uncordon dev-worker.Check
Good habit, or needs work?
Swipe right for good, left for needs work. Or use the buttons.
Check for removed APIs before the upgrade
You did it!
You can now upgrade a cluster in a safe order, inside the skew rules.
Go deeper (optional)
Each minor gets about a year of patches. Managed clouds can upgrade the control plane for you. You still check your YAML first. Self-built clusters use tools like kubeadm upgrade. In-place minor kubelet upgrades are not supported: drain the stall first.
Bahasa Melayu
Projek Kubernetes hanya tampal tiga versi minor terbaru: 1.37, 1.36 dan 1.35. Kluster lama anda guna 1.34. Apa risikonya?
kubectl anda, API server dan kubelet setiap node (gerai) semuanya ada versi. Version skew ialah sejauh mana ia boleh berbeza dan masih berfungsi bersama.
API server guna 1.37. Bahagian mana yang cukup dekat?
Jadi API server dulu, dan gerai ikut. Susun satu naik taraf minor.
Control plane anda guna 1.35. Bolehkah terus naik taraf ke 1.37?
Latih rutin gerai. Drain dev-worker. Anggap anda naik taraf kubeletnya. Kemudian uncordon.
kubectl drain dev-worker --ignore-daemonsets, kemudian kubectl uncordon dev-worker.Tabiat baik, atau perlu diperbaiki?
Kini anda boleh naik taraf kluster dalam urutan selamat, ikut peraturan skew.
You finished this before. Practice is always welcome!
Official docs: Kubernetes: version skew policy · Kubernetes: releases · Kubernetes: safely drain a node
You've learned for 25 minutes. A short break helps your brain.
Sprint done! Great focus. Stretch for a minute?