Print or save as PDF

Choose “Save as PDF” as the destination in your browser's print dialog.

Back

UXAtom Learn · Kubernetes

Pods and workloads

The smallest deployable unit, and the controllers that manage sets of them.

Updated August 4, 2026 · 25 min · 2 pages

Summary

A pod is one or more containers sharing a network namespace and a lifecycle. You rarely create one directly — Deployments, StatefulSets, DaemonSets and Jobs each manage pods with different guarantees about identity, ordering and replacement. Choosing the wrong controller is the root of a surprising number of production problems, because the guarantee you assumed was never offered.

Contents

  1. 01The pod
  2. 02Choosing a controller

The pod

Kubernetes does not schedule containers. It schedules pods.

A pod is a group of containers that share a network namespace, share IPC, and can share volumes. They are always placed on the same node, always started together, and always terminated together.

What sharing a network namespace means

Every container in a pod sees the same IP address and the same port space. They reach each other over localhost, and they cannot both bind the same port.

apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  containers:
    - name: app
      image: myapp:1.4
      ports:
        - containerPort: 8080
    - name: metrics-proxy
      image: proxy:2.0
      ports:
        - containerPort: 9090

The proxy scrapes http://localhost:8080 — no service discovery, no DNS, no network hop. This is the sidecar pattern, and the shared namespace is the whole reason it works.

Init containers

Init containers run to completion, in order, before any app container starts. If one fails, the pod restarts according to its policy and the sequence begins again.

spec:
  initContainers:
    - name: wait-for-db
      image: busybox:1.36
      command: ['sh', '-c', 'until nc -z db 5432; do sleep 1; done']

They are the correct place for migrations, waiting on a dependency, or fetching configuration — anything that must be finished before the app process begins.

Restart policy is per pod, not per container

restartPolicy applies to the pod as a whole: Always, OnFailure or Never. Deployments require Always. Jobs require one of the other two.

A crashing container is restarted in place by the kubelet, with exponential backoff up to five minutes. That backoff is what CrashLoopBackOff means — the pod is not broken beyond repair, the kubelet is simply waiting before its next attempt.

Choosing a controller

Each workload controller manages pods. They differ in what they promise about identity, ordering and placement.

ControllerUse whenGuarantee
DeploymentStateless replicasInterchangeable pods, rolling updates
StatefulSetStateful membersStable name, stable storage, ordered rollout
DaemonSetNode-level agentsOne pod per matching node
JobRun to completionRetries until the success count is met
CronJobScheduled workCreates Jobs on a schedule

Deployments give you no identity

Deployment pods get random name suffixes and are replaced freely. Nothing about a given pod persists across a restart — not its name, not its storage, not its position in a cluster.

This is exactly right for a web server and exactly wrong for a database replica.

StatefulSets trade speed for identity

A StatefulSet gives each pod an ordinal name (db-0, db-1), a stable DNS entry via a headless Service, and its own PersistentVolumeClaim that survives rescheduling.

Rollouts happen one pod at a time, in reverse ordinal order, waiting for each to become ready before continuing.

Jobs and the completion count

apiVersion: batch/v1
kind: Job
metadata:
  name: migrate
spec:
  backoffLimit: 3
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: migrate
          image: myapp:1.4
          command: ['./migrate']

backoffLimit counts failed pods, not failed containers. With restartPolicy: Never a failure creates a new pod; with OnFailure the container restarts inside the existing pod. The two produce different pod counts for the same number of failures, which makes debugging confusing if you are not expecting it.

Pods and workloads — uxatom.com/learn/en/courses/pods