Forty production nodes, continuous traffic, and a Kubernetes version approaching end of life. Plan the upgrade with no user-visible downtime.

1. Establish the key fact: running pods keep serving while the control plane is unavailable, because the kubelet and kube-proxy on each node continue with their current state. 2. Derive the ordering from that — control plane first, then workers — so the period of API unavailability costs you scheduling, not serving. 3. Respect version skew rules: the control plane must not be behind the nodes, and upgrades go one minor version at a time. 4. Prepare before touching anything: back up etcd, check deprecated API usage against the target version, and validate that PodDisruptionBudgets and replica counts allow eviction. 5. Upgrade the control plane one node at a time so quorum holds throughout. 6. Roll workers in small batches: cordon, drain honouring budgets, upgrade, uncordon, verify workloads are ready before the next batch. 7. Keep spare capacity so drained pods have somewhere to land — a full cluster cannot be rolled. 8. Handle the stateful and singleton workloads separately, since these are the ones that block a drain. 9. Define the rollback and the abort criteria before starting, and verify with real traffic checks between batches, not just pod status. 10. Prefer immutable node replacement over in-place upgrade where the platform allows it.