Introduction
Kubernetes components can each run their own versions. For example:| Component | Example version |
|---|---|
| kube-apiserver | v1.32.0 |
| kube-scheduler | v1.32.0 |
| kubelet | v1.32.0 |
| kube-proxy | v1.32.0 |
| controller-manager | v1.32.0 |
| etcd | v3.5.17 |
| coredns | v1.12.0 |
It is not mandatory for all components to share the same version. However,
kube-apiserver is the primary component — all other components like kube-scheduler, kubelet, kube-proxy, and controller-manager must be at a version less than or equal to the kube-apiserver version to avoid compatibility issues. The etcd and coredns versions are independent.kubeadm, you can use it to plan and execute the upgrade:
Upgrade process
This example upgrades a cluster with one master and two worker nodes fromv1.21.0 to v1.22.0. Replace version numbers with your actual target version.
Upgrade the master node
When the master node is being upgraded, control plane components (
kube-apiserver, kube-scheduler, kube-controller-manager) go down temporarily. Worker nodes continue to run their existing workloads, but you cannot deploy, modify, or delete resources while the control plane is unavailable.Upgrade the worker nodes
There are three strategies for upgrading worker nodes:The following commands upgrade one worker node at a time. Repeat for each worker node.
All at once
Upgrade all worker nodes simultaneously. Simple, but causes downtime as all pods are evicted at once.
One at a time
Upgrade nodes sequentially. Pods are rescheduled to remaining nodes. No downtime, but takes longer.
Add new nodes
Provision new nodes with the new version, move workloads to them, then remove the old nodes. Best for cloud providers. No downtime.