A court cluster must prepare for later HA expansion. What should be set during initial kubeadm planning for a stable API endpoint?
Select an answer to reveal the explanation.
Short Explanation
Pick the courthouse’s permanent street address before you add more front doors. A stable controlPlaneEndpoint—DNS or VIP—keeps certificates and join clients sane when HA arrives. Ephemeral node IPs make every expansion painful.
Full Explanation
A court cluster preparing for later HA expansion should configure a stable controlPlaneEndpoint—DNS name or VIP—during initial kubeadm planning. Pick the courthouse’s permanent street address before adding more front doors so certificates and join clients remain valid when HA arrives. Using each control-plane node’s ephemeral DHCP IP as the only advertised API address forever forces painful certificate and client churn on every lease change. Pointing controlPlaneEndpoint at a random worker NodePort that changes every join is unstable and incorrect for the API endpoint. Omitting the endpoint and telling clients to round-robin raw etcd peer URLs confuses the Kubernetes API with the etcd peer protocol. Exam caveat: Set controlPlaneEndpoint early—retrofitting HA addressing is harder after certs are issued. Operational check: Define VIP/DNS before init, place it in ClusterConfiguration, generate certs with appropriate SANs, and validate kubectl and workers target that stable name. In municipal platform operations, document this decision in the change record so the next on-call engineer understands why the chosen control exists and which failure modes the rejected options would introduce for city services that depend on this cluster behavior.