Kubernetes Workload Controllers

Kubernetes Workload Controllers are the higher-level objects that manage the creation, scaling, and lifecycle of Pods on behalf of a user, rather than requiring Pods to be created and tracked individually. Each controller type encodes a distinct set of assumptions about how its Pods should be treated, whether they are interchangeable and stateless, tied to stable identity and storage, or run to completion rather than indefinitely, and continuously reconciles the number and configuration of Pods it manages against that model.

The Controller Pattern

Reconciliation Loop

Every workload controller follows the same general pattern: it watches the API server for changes to its own resource type and to the Pods it manages, compares the observed set of Pods against what its specification requires, and issues create or delete operations against the API server until the two match. This loop runs continuously, not just at creation time, giving each controller type its self-healing behavior.

Ownership References

Pods created by a controller carry an ownerReference pointing back to the controller that created them. This reference is used both to route deletion, deleting a controller by default deletes its owned Pods (cascading deletion), and to allow the controller to distinguish Pods it is responsible for from unrelated Pods that might otherwise match its selector.

Deployment

Purpose

Deployment manages stateless, interchangeable Pod replicas. It does not manage Pods directly but instead manages a ReplicaSet, which in turn manages the Pods themselves, an extra layer of indirection that enables Deployment's signature feature: controlled, revisioned rollouts.

Rolling Updates and Rollbacks

When a Deployment's Pod template changes, a new ReplicaSet is created and gradually scaled up while the old ReplicaSet is scaled down, according to configurable maxSurge and maxUnavailable parameters, producing a gradual transition with no downtime. Because prior ReplicaSets are retained, a Deployment can be rolled back to a previous revision by simply re-activating an earlier ReplicaSet.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: codartium-api
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: codartium-api
  template:
    metadata:
      labels:
        app: codartium-api
    spec:
      containers:
        - name: api
          image: codartium/api:4.1.0

kubectl rollout status deployment/codartium-api
kubectl rollout undo deployment/codartium-api
kubectl rollout history deployment/codartium-api

ReplicaSet

A ReplicaSet's sole responsibility is to maintain a stable number of Pods matching a given selector and template at all times. It has no concept of revisions or rollout strategy; that logic belongs to Deployment. ReplicaSets are rarely created directly by users, since Deployment provides the same guarantee with additional rollout management.

StatefulSet

Purpose

StatefulSet manages Pods that require stable, unique identities and stable storage across rescheduling, characteristics needed by workloads such as databases and distributed coordination services.

Ordinal Identity and Stable Network Names

Each Pod created by a StatefulSet receives a predictable, ordinal-based name (web-0, web-1, web-2) and a stable DNS name derived from that ordinal, which persists even if the Pod is rescheduled to a different node.

Ordered Deployment and Scaling

Unlike a Deployment's Pods, which are created and terminated without a defined order, a StatefulSet creates Pods sequentially, waiting for each to become ready before starting the next, and scales down in reverse order, properties important for workloads with startup or shutdown dependencies between replicas.

Persistent Storage per Replica

Through volumeClaimTemplates, a StatefulSet provisions a dedicated PersistentVolumeClaim for each Pod, which remains bound to that Pod's ordinal identity across rescheduling, ensuring each replica retains its own durable storage.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: codartium-db
spec:
  serviceName: codartium-db
  replicas: 3
  selector:
    matchLabels:
      app: codartium-db
  template:
    metadata:
      labels:
        app: codartium-db
    spec:
      containers:
        - name: db
          image: codartium/db:9.4
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 10Gi

DaemonSet

DaemonSet ensures that a copy of a specified Pod runs on every node, or on a selected subset of nodes matching a node selector, in the cluster. It is used for node-level infrastructure workloads, such as log collectors, monitoring agents, or network plugins, that must be present on every machine rather than scaled independently of the node count. As nodes are added to the cluster, the DaemonSet controller automatically schedules its Pod onto them; as nodes are removed, their DaemonSet Pods are garbage collected.

Job and CronJob

Job

A Job creates one or more Pods and tracks them until a specified number complete successfully, retrying failed Pods according to a backoff policy. Unlike Deployment or ReplicaSet, a Job's Pods are expected to terminate, and the controller's goal is successful completion rather than indefinite availability.

CronJob

A CronJob creates Jobs on a repeating schedule expressed in cron syntax, managing the creation of each scheduled Job instance and enforcing concurrency and history-retention policies across runs.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: codartium-report
spec:
  schedule: "0 3 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: report
              image: codartium/report:1.0.0
          restartPolicy: OnFailure

Choosing a Controller

The choice among these controllers follows directly from the nature of the workload: stateless and interchangeable favors Deployment; requiring stable identity or per-replica storage favors StatefulSet; needing presence on every node favors DaemonSet; and running to completion, once or on a schedule, favors Job or CronJob respectively.