CKA — Verify Upgrade
Post-Upgrade Verification
After upgrading all nodes, run these checks to confirm the cluster is healthy.
Check Node Versions
kubectl get nodes
All nodes should show the target version:
NAME STATUS ROLES AGE VERSION
controlplane Ready control-plane 30d v1.30.0
worker01 Ready <none> 30d v1.30.0
worker02 Ready <none> 30d v1.30.0
Check System Pods
kubectl get pods -n kube-system
All Pods should be Running. Pay special attention to:
- kube-apiserver
- etcd
- kube-scheduler
- kube-controller-manager
- coredns
- kube-proxy
Check Component Versions
# API server version
kubectl version
# kubelet version on each node
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}: {.status.nodeInfo.kubeletVersion}{"\n"}{end}'
Check Application Health
# Verify all deployments are available
kubectl get deployments -A
# Check for any unhealthy pods
kubectl get pods -A | grep -v Running | grep -v Completed
Common Upgrade Issues
| Issue | Cause | Fix |
|---|---|---|
| kubeadm upgrade plan fails | kubeadm binary not yet upgraded | Upgrade kubeadm binary first |
| Node still shows old version | kubelet not yet upgraded | Install new kubelet and restart |
| Pods not rescheduled after drain | No other nodes available | Add more nodes or uncordon another first |
| cannot evict pod error | PodDisruptionBudget blocks eviction | Check PDB, scale up, then retry |
| kubelet won’t start | Config mismatch | Run kubeadm upgrade node on worker |
Rollback Considerations
Kubernetes does not officially support rolling back kubeadm upgrades. If an upgrade fails:
- etcd backup — Restore from backup taken before upgrade (see etcd Backup & Restore)
- Component manifests — Revert static Pod manifests to previous versions
- Downgrade binaries — Install previous version of kubeadm, kubelet, kubectl
- Re-initialize — In worst case, kubeadm reset and rebuild
Best practice: Always take an etcd backup before upgrading and test upgrades in a non-production environment first.
Next: Hands-On Lab ->
