Sanitation cluster planners ask which packages to stage on nodes before kubeadm init. Which set is the standard baseline?
Select an answer to reveal the explanation.
Short Explanation
Before the ceremony, lay out the three tools of the trade: kubeadm, kubelet, and kubectl—and make sure kubelet will start. Helm charts and compose files can wait; they are not the init baseline.
Full Explanation
Sanitation cluster planners staging hosts before kubeadm init should install the standard baseline packages: kubelet, kubeadm, and kubectl, with kubelet enabled so it can start after boot once bootstrap writes its configuration. Those three components are the civic tools of the trade for a kubeadm node; addon CLIs can wait until the platform intentionally installs charts or meshes later. The correct approach is: kubelet, kubeadm, and kubectl, with kubelet enabled to start after boot. Staging only docker-compose, helm, and istioctl skips the node agent and bootstrap tooling kubeadm requires, so init/join cannot establish a Kubernetes node. Placing etcdctl alone on workers while skipping kubelet leaves machines unable to run Pods or register as Nodes—etcdctl is a datastore client, not a node agent. Substituting cri-dockerd and swarmkit for kubelet abandons the kubeadm node model rather than preparing hosts for Kubernetes membership. Exam caveat: Workers still need kubelet; mesh or Helm CLIs are not the pre-init baseline. Operational check: Install kubeadm/kubelet/kubectl from the planned package repository, systemctl enable kubelet, confirm versions match the target minor, then run kubeadm and verify kubelet becomes active with a bootstrap kubeconfig.