Public-works plans to restart kubelets after a config change and wants to avoid unsupported version skew with the API server. What constraint should they respect?
Select an answer to reveal the explanation.
Short Explanation
Kubelets and the API server are dance partners—they only stay in step within a published skew window. Don’t let workers leapfrog the control plane version, or you invent “unsupported” night shifts. Config restarts are fine; wild version gaps are not.
Full Explanation
When public-works restarts kubelets after a config change, they must keep kubelet versions within Kubernetes’ supported skew relative to kube-apiserver—kubelets must not be newer than the API server beyond policy. Kubelets and the API server are dance partners; wild version gaps invent unsupported night shifts for civic ops. Running kubelets two major versions ahead of kube-apiserver to preview APIs early violates skew and supportability. Matching every kubelet to a different patch so skew “averages out” creates an inconsistent, hard-to-support fleet. Version skew limits are not only for kubectl clients; kubelets are explicitly constrained relative to apiserver. Exam caveat: Never let workers leapfrog the control-plane minor beyond supported skew. Operational check: kubectl version / get nodes versions before and after changes, upgrade control plane before workers when bumping minors, and block rollout if skew would break policy. 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. Re-validate after the next maintenance window that the same control still holds under the cluster’s current minor version and addon revisions used by the civic platform team.