After a parks booking platform joins its first worker pool with kubeadm, operators need a second pool of GPU nodes for GIS jobs without re-running kubeadm init. What is the correct admin approach?
Select an answer to reveal the explanation.
Short Explanation
Think of the cluster like a club already open—you don’t rebuild the building to add a VIP room; you badge new members in and tag them. Join the GPU boxes with kubeadm join, then slap on Node labels the scheduler can match. Init is a one-time birth certificate, not something you redo every time you hire more hardware.
Full Explanation
kubeadm init bootstraps the control plane once; expanding capacity uses kubeadm join for new nodes. Labels applied to Node objects after join drive scheduling decisions such as GPU GIS workloads via nodeSelector or affinity. Re-initializing destroys cluster identity and is unnecessary for adding labeled worker pools.