Workload Types

First PublishedFeb 16, 2026ByAtif Alam

Kubernetes has several workload controllers, each designed for a different pattern. Choosing the right one depends on whether your workload is stateless, stateful, per-node, or a one-off task.

Deployments

Use for: Stateless applications (web servers, APIs, workers).

• Manages a ReplicaSet that keeps the desired number of identical pods running.
• Supports rolling updates and rollbacks.
• Pods are interchangeable — any replica can handle any request.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.25

StatefulSets

Use for: Stateful applications (databases, caches, message brokers).

• Each pod gets a stable, unique identity (e.g. db-0, db-1, db-2).
• Pods are created and deleted in order (0, 1, 2 on scale-up; 2, 1, 0 on scale-down).
• Each pod can have its own persistent volume (using volumeClaimTemplates).
• A headless Service gives each pod a stable DNS name (e.g. db-0.db-svc).

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db-svc
  replicas: 3
  selector:
    matchLabels:
      app: db
  template:
    metadata:
      labels:
        app: db
    spec:
      containers:
        - name: postgres
          image: postgres:16
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 10Gi

DaemonSets

Use for: One pod per node (log collectors, monitoring agents, node-level networking).

• Kubernetes ensures exactly one pod runs on every (or selected) node.
• When a new node joins the cluster, the DaemonSet automatically schedules a pod on it.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-agent
spec:
  selector:
    matchLabels:
      app: log-agent
  template:
    metadata:
      labels:
        app: log-agent
    spec:
      containers:
        - name: fluentd
          image: fluentd:v1.16

Common examples: Fluentd/Fluent Bit (logging), Node Exporter (Prometheus metrics), kube-proxy, CNI plugins.

Jobs

Use for: One-off or batch tasks that run to completion.

• A Job creates one or more pods and ensures they succeed (exit code 0).
• Once complete, the pods stay (for log inspection) until you delete them.

apiVersion: batch/v1
kind: Job
metadata:
  name: data-migration
spec:
  template:
    spec:
      containers:
        - name: migrate
          image: my-app:migrate
          command: ["python", "migrate.py"]
      restartPolicy: Never
  backoffLimit: 3

CronJobs

Use for: Scheduled tasks (backups, reports, cleanup).

• A CronJob creates Jobs on a schedule (cron syntax).

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-backup
spec:
  schedule: "0 2 * * *"     # every day at 2:00 AM
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: backup
              image: my-app:backup
          restartPolicy: OnFailure

Quick Reference

Workload	Use Case	Pod Identity	Scaling
Deployment	Stateless apps	Interchangeable	Horizontal (replicas)
StatefulSet	Stateful apps (DBs)	Stable, ordered	Ordered (0, 1, 2…)
DaemonSet	Per-node agents	One per node	Automatic per node
Job	One-off tasks	Run to completion	Parallelism setting
CronJob	Scheduled tasks	Run to completion	Schedule-based