kube-apiserver
N (Baseline)
Central API server - always upgrade first
kubelet
N to N-2
Worker node agent - gradual upgrade
kubectl
N+1 to N-1
CLI tool - flexible versioning
kube-controller-manager
kube-scheduler
N to N-1
Control plane components
Compatibility Matrix
| Component |
|
|
|
|
| kube-apiserver |
✗ |
✗ |
✓ |
✗ |
| kubelet |
✓ |
✓ |
✓ |
✗ |
| kubectl |
✗ |
✓ |
✓ |
✓ |
| kube-controller-manager |
✗ |
✓ |
✓ |
✗ |
| kube-scheduler |
✗ |
✓ |
✓ |
✗ |
Incompatible (Not Supported)
Version Combination Examples
✓ Valid Combinations
- Scenario 1: API v1.28, kubelet v1.27, kubectl v1.28
- Scenario 2: API v1.28, kubelet v1.26, kubectl v1.29
- Scenario 3: API v1.28, all components v1.28
✗ Invalid Combinations
- Error 1: API v1.28, kubelet v1.29 (kubelet ahead)
- Error 2: API v1.28, kubelet v1.25 (3 versions behind)
- Error 3: API v1.28, kubectl v1.25 (2 versions behind)
Best Practices for Kubernetes Upgrades
- Upgrade Order: Always upgrade kube-apiserver first, then controller-manager/scheduler, then kubelet, finally kubectl
- Sequential Upgrades: Only upgrade one minor version at a time (e.g., 1.27 → 1.28 → 1.29)
- Never Skip Versions: Kubernetes does not support skipping minor versions during upgrades
- Gradual Node Upgrades: Upgrade worker nodes one at a time using drain/cordon to minimize disruption
- Test First: Always test upgrades in staging environment before production
- Backup etcd: Create etcd snapshots before any control plane upgrade