A county must upgrade a kubeadm cluster from an N-2 minor release toward the current supported minor. Which upgrade ordering principle should platform ops follow?
Select an answer to reveal the explanation.
Short Explanation
Cluster upgrades are like remodeling the front desk before the warehouse—the brains have to move first within the rules. Bring the control plane forward with kubeadm’s documented steps, then roll the workers, and stay inside Kubernetes’ supported skew. Flipping workers ahead of the API is how you invent mystery bugs.
Full Explanation
When a county upgrades a kubeadm cluster from an N-2 minor toward the current supported minor, platform ops should upgrade the control plane first following kubeadm’s documented component cadence, then upgrade workers while respecting supported version skew. Remodel the front desk before the warehouse so the API brain leads within policy. Upgrading every worker kubelet first so the API speaks an older version than nodes risks unsupported skew and broken registration. Skipping kubeadm upgrades and only bumping containerd ignores Kubernetes minor skew limits and leaves apiserver/kubelet mismatched. Upgrading etcd to a major version ahead of kube-apiserver so the API can lag indefinitely violates supported pairing and upgrade guides. Exam caveat: Control plane first, then workers, inside published skew windows. Operational check: Take etcd snapshot, kubeadm upgrade plan/apply on control plane, verify versions, then drain/upgrade workers rolling, confirming kubectl get nodes versions after each batch. In municipal platform operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services.