Upgrading Your K8s Clusters: Key Considerations for a Smooth Transition
summary
Kubernetes upgrades require concrete actions not platitudes: you cannot skip minor upgrades so go 1.21→1.22→1.23, you must migrate deprecated APIs like batch/v1beta1→batch/v1 for CronJob in 1.25 and networking.k8s.io/v1beta1→v1 for Ingress in 1.22, and check third‑party compatibility such as picking an nginx ingress release (example 1.4.0) that supports both current and target versions. Ensure cloud quotas for extra nodes, upgrade control plane first, test in a lower env, and set PDB minAvailable=2 for 3‑replica apps.
AI-written summary · about
chapters (6)
- 0:00Kubernetes upgrades intro
- 3:14API deprecations before upgrade
- 7:21Third-party software compatibility
- 11:20Quota and node limits in K8s
- 13:07PDBs to minimize downtime
- 15:42Best practices for K8s upgrades
related talks
46mEnd-Users Won't Even Notice, Painless Kubernetes Upgrades
05mUpgrading K8s: run as fast as we can, just to stay in place
25mAutomating Kubernetes Upgrades for Zero Downtime
06mNever ever upgrade
23mHow To Migrate Kubernetes Cluster With Zero Downtime
18mKubernetes Project Update
30mNavigating the Inevitable: Kubernetes Breaking Changes Behind the Scenes
35mSafely Upgrading Kubernetes Clusters