5.2 Kubernetes Releases & Cluster Upgrade
1️⃣ Kubernetes Releases
Check Cluster Version
Example:
- controlplane → v1.33.0
- worker nodes → v1.33.0
Note
Kubernetes follows Semantic Versioning: vMAJOR.MINOR.PATCH
Version Structure
Example: v1.33.0
- Major (1) → Rare architectural changes
- Minor (33) → New features & improvements
- Patch (0) → Bug fixes & security fixes
Abstract
Minor releases add features.
Patch releases improve stability and security.
Release Lifecycle
Alpha
- Experimental
- Disabled by default
- Not production ready
Beta
- Stable feature set
- Enabled by default
- Suitable for testing
Stable (GA)
- Fully tested
- Production supported
- Official releases
Warning
Never enable Alpha features in production.
Support Policy
Kubernetes supports only the latest 3 minor versions.
If latest = 1.34
Supported = 1.34, 1.33, 1.32
Danger
Running unsupported versions exposes clusters to security and compatibility risks.
2️⃣ Version Skew Policy
If kube-apiserver = version X:
- controller-manager → X or X-1
- kube-scheduler → X or X-1
- kubelet → X-1 or X-2
- kube-proxy → X-1 or X-2
- kubectl → X-1, X, or X+1
Warning
No core component (except kubectl) may be higher than kube-apiserver.
Success
Version skew allows rolling, zero-downtime upgrades.
3️⃣ Production Upgrade Strategy
Golden Rules
Abstract
- Upgrade one minor version at a time
- Upgrade control plane first
- Upgrade workers next
- Backup etcd before upgrade
- Review release notes
Control Plane Upgrade Behavior
- API server briefly unavailable
- Worker nodes continue serving traffic
- Applications remain online
- Management operations paused temporarily
4️⃣ Worker Upgrade Strategies
❌ All Nodes Together
- Downtime occurs
- Not recommended
✅ Rolling Upgrade
- Drain node
- Upgrade node
- Restart kubelet
- Uncordon
- Repeat
✅ Blue/Green Nodes
- Add new upgraded nodes
- Migrate workloads
- Remove old nodes
5️⃣ Cluster with kubeadm Upgrade Workflow (v1.33 → v1.34 Example)
This example demonstrates upgrading from v1.33.0 to v1.34.0.
🔹 On Control Plane Node
Drain Node (Before Upgrade)
Tip
Draining safely evicts workloads and prevents new pods from scheduling.
Step 1 — Update Kubernetes APT Repository
Update to:
deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.34/deb/ /
Then:
Step 2 — Verify Available kubeadm Version
Install correct version:
Step 3 — Upgrade Controlplane
Note
This may take a few minutes.
Step 4 — Upgrade kubelet
Verify:
Uncordon Node (After Upgrade)
🔹 On Worker Node (node01)
Login:
Drain Node (Before Upgrade)
Step 1 — Update Repository
Update to:
deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.34/deb/ /
Then:
Step 2 — Upgrade kubeadm
Step 3 — Upgrade Node Configuration
Step 4 — Upgrade kubelet
Exit from worker node:
Uncordon Node (After Upgrade)
Repeat for remaining worker nodes (rolling approach).6️⃣ Production Best Practices
Recommended
- Maintain N+1 capacity
- Use PodDisruptionBudgets
- Upgrade sequentially
- Test in staging first
- Monitor workloads after upgrade
- Keep rollback plan
7️⃣ Production Do & Don’t
✅ DO
Tip
- Upgrade one minor version at a time
- Drain worker nodes before upgrade
- Validate node status after upgrade
- Monitor deprecated APIs
❌ DON'T
Danger
- Don’t skip minor versions
- Don’t upgrade all workers at once
- Don’t ignore version skew rules
- Don’t upgrade without etcd backup
8️⃣ Quick Upgrade Summary
Abstract
- Backup etcd
- Update repo to next minor version
- Upgrade kubeadm
- kubeadm upgrade plan
- kubeadm upgrade apply
- Upgrade kubelet
- Rolling upgrade workers
- Validate cluster health
Final Production Takeaway
Quote
Safe Kubernetes upgrades are planned, sequential, and availability-focused.
Control Plane → Rolling Workers → Validate.