CKA Road Trip: Why Would I Schedule a Pod on the Control Plane?
Short answer: you usually wouldn't. But here's why the option exists.
The Default Taint
The control plane node has a taint on it by default:
That means: don't schedule pods here unless they explicitly tolerate it. Without a toleration, the scheduler sees the taint and skips the node silently. No error. Just one less node available.
The Three Legitimate Reasons
Node-level agents that need to run everywhere. A security scanner, log collector, or monitoring agent that must observe every node — including the control plane. If it doesn't run there, you have a blind spot. That's the real production use case for the toleration.
Single or minimal node clusters. In a lab with only a controlplane and one worker, not tolerating the taint means half your cluster is off-limits for scheduling. Fine in prod, painful in a two-node lab.
The exam. KillerKoda and similar environments use minimal setups. You'll hit exercises where pods need to land on the control plane just to satisfy the task.
The Toleration
Add this under spec in your pod or DaemonSet template. Without it the control plane node is invisible to the scheduler.
Why the Taint Exists
The control plane runs etcd, the API server, the scheduler, the controller manager. It's the most critical node in the cluster. Resource contention here means the whole cluster degrades. The taint enforces separation by default — workloads go on workers, infrastructure stays on the control plane.
The control plane components themselves are static pods. The kubelet places them directly, bypassing the scheduler entirely, so the taint doesn't affect them.
The Rule
In production with real worker nodes: leave the taint alone, never schedule workloads on the control plane.
In a lab or for genuine node-level agents: add the toleration and be deliberate about it.