A library cluster finished control-plane init and must add workers using the printed join instructions. What is the correct action on each worker?
Select an answer to reveal the explanation.
Short Explanation
Workers do not throw their own init party—they join the one already started. Use the kubeadm join line from init output (token plus CA hash) on each worker. A second init makes a splinter cluster, not a bigger library.
Full Explanation
After a library cluster finishes control-plane init, each worker must run the kubeadm join command against the control-plane endpoint with the provided token and discovery hash. Workers do not throw their own init party; they join the ceremony already started so the library gains capacity instead of splinter clusters. Running kubeadm init again on every worker forms independent clusters rather than expanding the existing one. Copying admin.conf to workers and starting only the scheduler there does not perform a proper worker join or install kubelet node identity correctly. Applying a Deployment that mounts the control-plane etcd data directory is dangerous and unrelated to joining workers. Exam caveat: init once for the control plane; join for additional nodes. Operational check: Use the printed join command on each worker, verify kubelet starts, and confirm kubectl get nodes shows the new workers as Ready after CNI is present. 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.