Kubernetes Workload Controller Scope

Kubernetes Workload Controller Scope defines the boundary of responsibility that a workload controller, Deployment, ReplicaSet, StatefulSet, DaemonSet, Job, or CronJob, holds over the Pods it manages, and correspondingly what remains outside that responsibility and belongs instead to the scheduler, the kubelet, or a different controller entirely. Establishing this scope clearly is what allows multiple independent control loops to cooperate on a single Pod's overall lifecycle without duplicating or conflicting with one another's work.

What Workload Controllers Own

Desired State Reconciliation

Every workload controller's core scope is maintaining a declared desired state, replica count, ordinal identity, per-node presence, completion count, against observed reality, creating, deleting, or updating Pod objects as needed to close any gap.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: controller-scope-example
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: app
          image: registry.example.com/app:1.0.0

Pod Template Ownership

A workload controller owns the Pod template embedded in its own spec and is the only entity expected to change it; edits to the template trigger the controller's own update logic (a new ReplicaSet for a Deployment, a rolling replacement for a StatefulSet) rather than any external mechanism.

Ownership Reference Assignment

Controllers are responsible for setting ownerReferences on every Pod they create, establishing the object graph that garbage collection later uses to cascade deletions correctly.

What Falls Outside Workload Controller Scope

Node Placement

Deciding which node a Pod lands on is entirely the scheduler's responsibility. A workload controller creates a Pod with spec.nodeName unset and never itself chooses or influences the specific node beyond what constraints are encoded in the Pod template (affinity, tolerations, resource requests).

spec:
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: zone
                    operator: In
                    values: ["us-east-1a"]

Container-Level Execution

Once a Pod is created, starting containers, running probes, handling restarts, and managing termination signals are entirely the kubelet's domain. A workload controller does not intervene in this process and typically only observes its outcome through the Pod's status fields.

Traffic Routing

Directing network traffic to healthy Pods is the scope of Services, Endpoints, and any associated load balancer or ingress controller, not the workload controller that created those Pods.

Scope Boundaries Between Controller Types

Deployment Versus ReplicaSet

A Deployment's scope is managing a history of ReplicaSets to support rollouts and rollbacks; it does not create Pods directly. A ReplicaSet's scope is maintaining a fixed replica count of Pods matching its selector; it has no concept of rollout history or previous revisions.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: controller-scope-example-abc123
  ownerReferences:
    - apiVersion: apps/v1
      kind: Deployment
      name: controller-scope-example
      controller: true

Job Versus CronJob

A Job's scope ends at ensuring a specified number of Pod completions occurs, once. A CronJob's scope is triggering new Job objects on a schedule; it delegates all actual completion tracking to the Jobs it creates rather than tracking Pods itself.

Workload Controller Scope Diagram

Keeping these boundaries distinct is what allows the same Pod object to be simultaneously governed by a workload controller for identity and count, the scheduler for placement, and the kubelet for execution, without any of the three needing awareness of the others' internal logic.