Kubernetes Workload Resources: When to Use Deployments, StatefulSets, DaemonSets, and Jobs

The six workload types and what they promise

Every Kubernetes workload wraps a pod template. The workload type controls how many instances run, how they're replaced, and what guarantees are made about identity and storage.

| Resource | Pods | Identity | Storage | Use case | |---|---|---|---|---| | Deployment | N interchangeable | Random names | Shared or none | Stateless services | | StatefulSet | N ordered | Stable names | Per-pod PVCs | Databases, brokers | | DaemonSet | 1 per node | Per-node | Host path or none | Log agents, monitoring | | Job | 1+ to completion | Temporary | Temporary | Batch processing | | CronJob | Job on schedule | Temporary | Temporary | Scheduled tasks | | ReplicaSet | N (rarely direct) | Random | Shared or none | Managed by Deployment |

Deployment: the right choice for stateless services

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1     # at least 2 pods available during update
      maxSurge: 1           # at most 4 pods total during update
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: myapp:1.2.3
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits:
            cpu: "1000m"
            memory: "1Gi"
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

Deployments are the right choice when: all pods are equivalent, storage is external (RDS, Redis, S3), and the service can be load-balanced across any instance.

StatefulSet: stable identity for stateful applications

StatefulSets make three guarantees Deployments don't:

1. Stable, predictable pod names: postgres-0, postgres-1, postgres-2
2. Ordered startup (0 before 1 before 2) and ordered shutdown (reverse)
3. Per-pod persistent volume claims that survive pod replacement

The stable DNS names are the critical feature for distributed systems. A PostgreSQL replica can be configured to replicate from postgres-0.postgres-headless.default.svc.cluster.local — this DNS name resolves to the same pod regardless of restarts and rescheduling.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres-headless  # must exist as a headless Service
  replicas: 3
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:15
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:           # each pod gets its own PVC
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: gp3
      resources:
        requests:
          storage: 100Gi

DaemonSet: one pod per node

DaemonSets ensure exactly one pod runs on every node (or every node matching a node selector). When new nodes join the cluster, the DaemonSet controller automatically schedules a pod on them.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-collector
spec:
  selector:
    matchLabels:
      app: log-collector
  template:
    metadata:
      labels:
        app: log-collector
    spec:
      tolerations:
      - key: node-role.kubernetes.io/control-plane
        effect: NoSchedule    # run on control plane nodes too if needed
      containers:
      - name: fluentd
        image: fluentd:v1.16
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: dockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: dockercontainers
        hostPath:
          path: /var/lib/docker/containers

DaemonSets use hostPath volumes to access node-local paths. This is why they need DaemonSet — a Deployment doesn't guarantee one pod per node, and wouldn't have access to per-node paths in a predictable way.

apiVersion: batch/v1
kind: Job
metadata:
  name: db-migration
spec:
  completions: 1            # run 1 successful completion
  parallelism: 1            # run 1 pod at a time
  backoffLimit: 3           # retry up to 3 times on failure
  template:
    spec:
      restartPolicy: OnFailure   # required for Jobs (Never or OnFailure only)
      containers:
      - name: migrate
        image: myapp:1.2.3
        command: ["python", "manage.py", "migrate"]
        envFrom:
        - secretRef:
            name: db-credentials

apiVersion: batch/v1
kind: CronJob
metadata:
  name: cleanup
spec:
  schedule: "0 2 * * *"          # 2 AM daily
  concurrencyPolicy: Forbid       # don't start new Job if previous is still running
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
          - name: cleanup
            image: myapp:1.2.3
            command: ["python", "cleanup.py"]

HorizontalPodAutoscaler: scaling based on metrics

HPAs automatically adjust Deployment (or StatefulSet) replica counts based on observed metrics:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70    # scale up when average CPU > 70%
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30    # react quickly to traffic spikes
    scaleDown:
      stabilizationWindowSeconds: 300   # wait 5 min before scaling down

HPAs require resource requests to be set on containers — without them, CPU utilization percentage is undefined and HPA won't work.