Emergency-management builds a single-node kubeadm lab and needs application Pods to schedule on the control-plane node. What must they understand about the default control-plane taint?
Select an answer to reveal the explanation.
Short Explanation
By default the control plane is like a locked server room—workloads aren’t invited unless you unlock the door. kubeadm stamps a NoSchedule taint on that node, so app Pods bounce elsewhere (or stay Pending on a single-node lab). For a throwaway lab you can remove the taint on purpose; just don’t treat that as everyday production advice.
Full Explanation
Emergency-management’s single-node kubeadm lab must account for the default NoSchedule control-plane taint: workload Pods are blocked until that taint is intentionally removed or tolerated. By default the control plane is a locked server room; for a throwaway lab you may unlock it on purpose, but that is not everyday production HA advice. Control-plane nodes do receive taints under typical kubeadm defaults; Pods do not schedule there automatically for general workloads. Removing the control-plane taint does not delete the kube-apiserver static Pod, and removing it is not required in every production HA cluster—usually the opposite. The default taint is not limited to DaemonSets; Deployments without matching tolerations are also affected. Exam caveat: Know when labs remove taints versus when production keeps control-plane isolation. Operational check: kubectl describe node | grep Taints, remove or tolerate deliberately for the lab, schedule a test Deployment, then restore taints if the node will mimic production later. 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.