10.25 Kubernetes Workload Control Boundary
Kubernetes Workload Control Boundary defines how workloads are isolated and managed within cluster resources, ensuring secure and efficient operations.
Kubernetes Workload Control Boundary is the precise line separating what a workload controller is directly responsible for reconciling from what falls under the authority of other cluster components, other controllers, or manual operator action, clarifying where a given controller's automated decision-making stops and where external systems or human judgment must take over.
Boundary With the Scheduler
Controllers Create, the Scheduler Places
A workload controller's boundary ends the moment it creates a Pod object; it plays no role whatsoever in deciding which node that Pod is placed on, since that decision belongs entirely to the scheduler, operating as a fully separate component reacting independently to newly created, unscheduled Pods.
No Controller Awareness of Placement Outcomes
Because this boundary is strict, a workload controller does not adjust its behavior based on where its Pods end up being scheduled, meaning considerations such as balancing Pods across specific nodes are expressed through the Pod template itself, via topology spread constraints or affinity rules, rather than through any logic internal to the controller.
Boundary With the Kubelet
No Controller Involvement in Node-Local Execution
Once a Pod has been scheduled, everything related to actually starting its containers, evaluating probes, and applying restart policy falls under the kubelet's authority on the assigned node, entirely outside the scope of the workload controller, which continues to observe only the Pod's reported status rather than directly influencing its execution.
Controllers React to Kubelet-Reported Outcomes
The workload controller's only interaction with this node-local execution is indirect, through observing the Pod's status as reported back through the API server, using that information to decide whether the Pod counts toward its desired state or requires replacement, without any direct control over the execution details themselves.
Boundary Between Layered Controllers
Deployment Boundary Stops at ReplicaSet Creation
A Deployment's control boundary extends only to creating, scaling, and eventually retiring ReplicaSets; it does not directly create or delete Pods, deferring all Pod-level reconciliation entirely to the ReplicaSet it has created, marking a clean separation of concerns between rollout orchestration and replica maintenance.
CronJob Boundary Stops at Job Creation
Similarly, a CronJob's boundary extends only to creating Job objects according to its schedule; all subsequent execution, retry, and completion tracking for that specific task instance falls entirely within the Job controller's boundary, with the CronJob playing no further role until the next scheduled trigger.
Boundary With Manual Operator Actions
Controllers Do Not Override Deliberate Manual Changes Indefinitely
While reconciliation will correct many manual changes that conflict with declared desired state, certain manual actions, such as directly deleting a specific Pod, are respected as legitimate triggers for the controller's own replacement logic rather than being treated as errors to be reverted, illustrating that the boundary accommodates rather than fights certain categories of manual intervention.
Escalation Points Requiring Human Judgment
Certain failure conditions, such as a Job repeatedly failing and exhausting its retry budget, or a Deployment rollout exceeding its progress deadline, are surfaced through status conditions specifically because they cross the boundary of what automated reconciliation alone can resolve, requiring human judgment to diagnose the underlying cause and decide on corrective action.
Namespace as an Absolute Boundary
No Cross-Namespace Reconciliation
Every workload controller's boundary is strictly confined to its own namespace; regardless of how broadly a selector might otherwise be defined, no workload controller reconciles or manages objects residing in a different namespace, making namespace isolation an absolute, structurally enforced boundary rather than merely a convention.