Pods and workload objects

A pod is one or more containers that share a network address and volumes, and run together on one node. You rarely create pods directly. You create a workload object that makes pods for you and keeps them running. Each object has a different rule, so pick the one that matches your app.

The big idea

Pods are disposable. If a node dies, its pods are gone. A controller then creates new pods from a template, with new names and new IPs. Anything you build must assume a pod can vanish at any time.

Containers in one pod share fate. A sidecar, such as a log shipper or Envoy proxy, lives in the same pod as the app. If the pod is killed, both restart together.

Deployment and ReplicaSet

A ReplicaSet keeps N identical pods running. A Deployment owns a ReplicaSet and adds rolling updates, rollbacks and a history of revisions. For a stateless HTTP API, a Deployment is the default choice.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout
spec:
  replicas: 3
  selector:
    matchLabels:
      app: checkout
  template:
    metadata:
      labels:
        app: checkout
    spec:
      containers:
        - name: api
          image: registry.example.com/checkout:sha-a1b2c3d
          ports:
            - containerPort: 8080

This is a manifest. Apply it with kubectl apply -f checkout.yaml. The expected output is deployment.apps/checkout created.

Change the image tag, and the Deployment creates a new ReplicaSet. It then replaces old pods gradually, within the limits set by maxSurge and maxUnavailable.

Choosing the right object

Jobs need limits

A Job without limits can hammer the cluster forever. Set backoffLimit to cap retries. Set ttlSecondsAfterFinished so finished pods do not pile up. For a CronJob that must not overlap, use concurrencyPolicy: Forbid.

Common mistakes

• Running naked pods. No controller recreates them when they die.
• Using a StatefulSet for a stateless app. You get ordering and storage you do not need.
• Leaving a Job with no backoffLimit. A broken job retries without end.

Check yourself

1. Which object gives each pod a stable name and its own storage? A StatefulSet.
2. You change the image tag on a Deployment. What happens? It creates a new ReplicaSet and replaces old pods gradually, within maxSurge and maxUnavailable.

Key takeaways

• A pod is disposable. Design for it to vanish.
• Deployments fit stateless apps. StatefulSets fit sticky identity and storage.
• DaemonSets cover one-per-node agents. Jobs cover finite work.
• Always set a retry cap and a cleanup policy on Jobs.

Further learning

Next, see how clients reach a pod whose IP keeps changing in services and DNS.