After the first kubeadm init, a municipal team must expand to additional control-plane nodes. Which join pattern applies?
Select an answer to reveal the explanation.
Short Explanation
Adding another control-plane node is a special VIP join—not a second init ceremony. kubeadm join --control-plane (with the right certs and endpoint) badges the new brain into the existing cluster. A plain worker join won’t install the control-plane stack.
Full Explanation
After the first kubeadm init, expanding to additional municipal control-plane nodes uses kubeadm join with the control-plane workflow—including --control-plane—plus the cluster’s certificate key and endpoint details. Adding another brain is a special VIP join, not a second init ceremony. Running kubeadm init again on each new host with a unique cluster-name forms divergent clusters/federation myths rather than HA membership. Labeling workers control-plane=true alone does not install control-plane components. Copying only the admin kubeconfig to new hosts without kubeadm join does not bootstrap control-plane members. Exam caveat: Worker join ≠ control-plane join; --control-plane and certificate key matter. Operational check: Upload certs/certificate-key as documented, run kubeadm join --control-plane against controlPlaneEndpoint, and confirm new CP pods and etcd membership. 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.