Sanitation ops configures kubelets and admin kubeconfigs after building an HA control plane. Where should they point API clients?
Select an answer to reveal the explanation.
Short Explanation
Give everyone the published City Hall number—the VIP—not Bob’s desk phone that vanishes when Bob’s on vacation. Workers and kubeconfigs should use controlPlaneEndpoint so losing one control-plane host doesn’t mean rewriting every node. Hard-coding one IP quietly undoes your HA work.
Full Explanation
After building an HA control plane, sanitation ops should point kubelets and admin kubeconfigs at the stable HA controlPlaneEndpoint (VIP or DNS), not a single control-plane node IP. Publish City Hall’s number—the VIP—not Bob’s desk phone that vanishes on vacation. Hard-coding whichever CP IP ran kubeadm init first recreates a SPOF and breaks during that node’s maintenance. Random worker NodePorts to kube-apiserver on 10250 confuse kubelet ports with the API listener. Localhost-only on each worker is insufficient for cluster-wide HA client configuration. Exam caveat: HA work is undone if clients still pin to one node IP. Operational check: Update kubeconfigs and node bootstrap to the VIP/DNS, break one CP node in a test window, and confirm kubectl and kubelets still reach the API. 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. Keep the verification evidence—command output or config snippets—with the municipal runbook so audits can prove the control was applied as designed.