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
Kubernetes documents how many minor versions a kubelet may lag the kube-apiserver and disallows kubelets newer than the API server beyond supported policy. Lifecycle work that bumps kubelet must stay inside that skew so nodes remain supported and compatible. Ignoring skew can break node authorization, APIs, and supportability.