A city wants three control-plane nodes reachable through a stable VIP for API high availability. What kubeadm HA building block is required?
Select an answer to reveal the explanation.
Short Explanation
HA for the API is like giving City Hall one published phone number that rings a pool of operators—not three sticky notes with different digits. Put a VIP or DNS name in controlPlaneEndpoint, run multiple control-plane nodes, and let the load balancer spread the calls. Workers should dial that stable address forever.
Full Explanation
For three control-plane nodes reachable through a stable VIP, kubeadm HA requires a load-balanced controlPlaneEndpoint (VIP/DNS) and joining multiple control-plane nodes behind it. Give City Hall one published phone number that rings a pool of operators—not three sticky notes with different digits. Pointing every worker at a different control-plane IP permanently without a shared endpoint recreates SPOFs and client sprawl. Running three kube-schedulers on one node is not a highly available control plane. Replacing kube-apiserver with a single NodePort Service on a worker is not a kubeadm HA building block. Exam caveat: Multiple control-plane processes still need a stable shared endpoint for clients and workers. Operational check: Configure LB/VIP health checks to 6443, set controlPlaneEndpoint, join additional --control-plane nodes, and verify kubectl continues through the VIP when one member is stopped. 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.