Kubernetes Workload Control Boundary

Kubernetes Workload Control Boundary is the precise edge at which a workload controller's authority over its Pods ends and another actor's authority begins, covering the specific mechanisms, PodDisruptionBudgets, shared scale subresources, manual field edits, and external voluntary evictions, that constrain, share, or override what a controller can otherwise do freely within its own reconciliation loop.

The Boundary With Voluntary Disruption

PodDisruptionBudget as an External Veto

A PodDisruptionBudget does not belong to any workload controller and is not created or managed by one, yet it directly constrains what that controller's Pods may have happen to them during voluntary disruptions, node drains, cluster autoscaler scale-downs, and other operator-initiated evictions. The controller's own reconciliation loop cannot override a PDB; eviction requests are rejected by the API server itself if they would violate it.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: control-boundary-example
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: web

Not a Boundary Against Involuntary Disruption

Critically, a PDB has no effect on involuntary disruption, node failure, kernel panic, hardware fault. The control boundary it establishes is specifically around operator-initiated, API-mediated evictions, not the controller's own replacement logic reacting to a Pod that has simply disappeared.

The Boundary With the HorizontalPodAutoscaler

A Shared Field, Not a Shared Decision

The HorizontalPodAutoscaler writes to the same spec.replicas field a workload controller reads from, meaning the two share a boundary at that single field without either having exclusive ownership of it. This shared-write arrangement works because the HPA and the controller have distinct responsibilities, the HPA decides the target count, the controller decides how to reach it, but it also means manually editing replicas while an HPA is active will simply be overwritten on the HPA's next reconciliation pass.

kubectl get hpa control-boundary-hpa -o jsonpath='{.status.currentReplicas}/{.spec.maxReplicas}'

The Boundary With Manual Pod Edits

Direct Pod Modification Outside Controller Awareness

An operator can modify a running Pod directly, for example patching an image field where mutable, without going through the owning controller at all. Because the controller's desired state lives in the Pod template, not in any specific live Pod, such a direct edit persists only until the controller next needs to replace that Pod, at which point the replacement reverts to the template-defined state, silently discarding the manual change.

kubectl edit pod control-boundary-example-abc123

The Boundary With Admission Control

Mutation Before the Controller Ever Sees It

Admission webhooks operate before a Pod created by a controller is ever persisted, meaning a controller's Pod template can be silently altered by cluster-level policy, injected sidecars, default resource limits, security context overrides, without the controller's own logic being aware any mutation occurred. From the controller's perspective, it created exactly the Pod its template specified; the actual boundary of what gets deployed sits further out, at the admission layer.

webhooks:
  - name: sidecar-injector.example.com
    rules:
      - operations: ["CREATE"]
        resources: ["pods"]

Control Boundary Diagram

Recognizing that a workload controller's authority is bounded on multiple sides, some it must respect as a hard constraint, some it shares cooperatively, some it is simply unaware of, is essential for correctly diagnosing behavior that appears to contradict a controller's declared spec but actually originates from outside its control entirely.