10 Kubernetes Workload Controllers

Kubernetes Workload Controllers is the family of higher-level API objects that manage the creation, replacement, and scaling of Pods on behalf of users, encoding common operational patterns such as maintaining a stable number of replicas, running one Pod per node, or executing a task to completion, so that individual Pods do not need to be managed by hand.

Why Controllers Exist

Pods Alone Are Not Self-Healing

A Pod created directly, without a controller managing it, is not recreated if it is deleted or if the node it runs on fails. Workload controllers exist specifically to close this gap, continuously watching over the Pods they own and recreating them whenever the observed state deviates from the declared desired state.

A Shared Reconciliation Pattern

Every workload controller follows the same underlying reconciliation pattern: compare the desired number and specification of Pods against what actually exists, then create, delete, or update Pods as needed to close the gap.

ReplicaSets

Purpose

A ReplicaSet ensures that a specified number of identical Pod replicas are running at any given time, using a label selector to identify which Pods it is responsible for and a Pod template describing what new replicas should look like.

Relationship to Deployments

ReplicaSets are rarely created directly by users; instead, they are managed indirectly through Deployments, which use ReplicaSets internally to implement rolling updates.

Deployments

Rolling Updates

A Deployment manages ReplicaSets on behalf of the user and provides declarative updates to Pods, meaning changing the Pod template in a Deployment triggers a new ReplicaSet to be created and gradually scaled up while the old ReplicaSet is scaled down, achieving a rolling update with configurable rate and surge.

Rollbacks

Because Deployments retain a history of previous ReplicaSets, a Deployment can be rolled back to a prior revision if a new rollout proves problematic, restoring the earlier Pod template and triggering the same rolling mechanism in reverse.

StatefulSets

Stable Identity

StatefulSets manage Pods that require a stable, predictable identity across restarts and rescheduling, assigning each Pod an ordinal index and a consistent network name, which is essential for applications like databases that depend on stable peer addressing.

Ordered Operations

Unlike Deployments, StatefulSets create, scale, and update Pods in a defined order, one at a time, which respects dependencies between ordered replicas such as a primary node needing to exist before replicas join it.

DaemonSets

One Pod per Node

A DaemonSet ensures that a copy of a specific Pod runs on every node, or on a selected subset of nodes, matching automatically as nodes are added to or removed from the cluster. This pattern is commonly used for node-level agents such as log collectors, monitoring agents, or network plugins.

Jobs and CronJobs

Run-to-Completion Workloads

A Job creates one or more Pods and ensures a specified number of them terminate successfully, retrying failed Pods according to a configured policy, which suits batch processing or one-off tasks rather than long-running services.

Scheduled Execution

A CronJob wraps a Job with a schedule expressed in cron syntax, creating new Job objects automatically at the specified times, enabling recurring tasks such as backups or report generation without external scheduling infrastructure.

Choosing a Controller

Each controller type targets a distinct operational shape, and choosing the right one depends on whether the workload is stateless, requires stable identity, must run on every node, or is expected to terminate rather than run indefinitely.