Kubernetes Workloads

A workload is an application running on Kubernetes. Whether it's one component or several working together, it runs inside a set of Pods — and because Pods are deliberately disposable, Kubernetes gives you workload management objects whose controllers create, replace, and update Pods on your behalf. Choosing the right workload object for each component is one of the most consequential day-one decisions you make on Kubernetes: it determines how your application scales, updates, recovers, and (for stateful systems) whether it keeps its identity across restarts.

The mental model: every workload object is a Pod factory with a policy. You supply a Pod template plus rules — how many copies, how to roll out changes, whether Pods need stable names, whether the work ever finishes — and a controller enforces those rules continuously against reality.

Why workload objects exist

You could create Pods directly, and it would work right up until the first node failure — a bare Pod on a dead node is gone, and nothing recreates it. Workload objects solve this by managing Pods as a set: if a Pod fails or is evicted, the controller observes the gap between declared and actual state and creates a replacement. The same machinery handles the deliberate changes: rolling out a new image version, scaling from three replicas to thirty, running a batch of a thousand work items to completion.

The main workload types

Deployment is the workhorse for stateless applications — web servers, APIs, anything where every replica is interchangeable. A Deployment manages ReplicaSets (which maintain the replica count), and layering rollout logic on top: change the Pod template and the Deployment progressively replaces old Pods with new ones, with the ability to pause, resume, or roll back. You interact with Deployments; ReplicaSets are the implementation detail underneath.

StatefulSet exists for applications where Pods are not interchangeable — databases, message brokers, anything clustered with per-member identity. Each Pod gets a stable, ordinal name (db-0, db-1), a stable network identity backed by a headless Service, and its own persistent storage that survives rescheduling. Rollouts and scaling happen in order. The price is more operational care: storage must be provisioned per Pod, and deleting a StatefulSet does not delete its volumes.

DaemonSet runs one Pod on every node (or every node matching a selector) — the shape of node-level infrastructure: log collectors, monitoring agents, network plugins. Add a node and the DaemonSet controller adds the Pod; no scaling decision needed, the cluster's size is the scale.

Job runs Pods until a specified number of them complete successfully, retrying failures — the tool for batch work, migrations, and one-off tasks. Jobs can run many Pods in parallel and track completions. CronJob creates Jobs on a schedule written in cron syntax, for periodic work like backups and report generation.

Pod lifecycle, briefly

Understanding workloads means understanding what they manage. A Pod moves through phases — Pending (accepted, not yet running), Running, then Succeeded or Failed — and each container within it reports its own state (Waiting, Running, Terminated). Restart policy (Always, OnFailure, Never) governs container restarts within a Pod on the same node; replacing a lost Pod entirely is the workload controller's job. Init containers run to completion before app containers start, and sidecar containers run alongside the main container for the Pod's lifetime — a pattern for log shipping, proxies, and helpers.

Scaling

Kubernetes scales workloads both manually (kubectl scale, or editing replicas) and automatically. The HorizontalPodAutoscaler (HPA) adjusts replica counts based on observed metrics like CPU utilization; the VerticalPodAutoscaler (VPA) adjusts the resources each Pod requests (a separate add-on). Horizontal scaling is the cloud-native default — it requires your application to tolerate copies of itself, which is exactly what the Deployment model already assumes.

Limits and honest caveats

Workload objects automate mechanics, not application semantics. A StatefulSet gives your database stable identity and storage; it does not know how to take a backup, elect a leader, or perform a schema migration — that operational knowledge either stays with humans or moves into an operator (covered later in this series). Rolling updates are only as safe as your readiness probes and your application's ability to run two versions side by side. And Jobs guarantee at least once execution semantics in the face of retries — idempotent work is your responsibility.