✦ For everyone, free.

Practical knowledge for real and everyday life

Home

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.