Skip to content

Pods and Deployments

Pods are the runtime unit. Deployments are the lifecycle controller.

If you remember one rule, remember this: in production, you almost never run standalone pods. You run pods through a controller, usually a Deployment.

Pod fundamentals

A pod is one or more containers that share:

  • one network namespace (same IP, localhost communication)
  • declared storage volumes
  • one scheduling decision

Most pods should contain one main application container. Add sidecars only when they provide clear value, such as logging, proxying, or telemetry.

Pod lifecycle

A pod moves through several phases during its lifetime:

stateDiagram-v2
    [*] --> Pending : created
    Pending --> Running : scheduled and containers start
    Running --> Succeeded : all containers exit 0
    Running --> Failed : container exits non-zero
    Running --> Unknown : node communication lost
  • Pending: accepted by the API server but not yet scheduled or images not yet pulled.
  • Running: at least one container is running or starting.
  • Succeeded: all containers exited successfully (common for Jobs).
  • Failed: at least one container exited with non-zero status.
  • Unknown: the node cannot be reached.

Why pods alone are not enough

Pods are disposable. They can disappear during node failure, eviction, rescheduling, or rollout. A naked pod does not self-heal.

That is why controllers exist.

What Deployments do

A Deployment manages a ReplicaSet, and the ReplicaSet manages pods.

Deployment responsibilities:

  • keep the desired replica count running
  • perform rolling updates
  • support rollback to prior revisions
  • expose rollout status and history
graph TD
  A[Apply Deployment] --> B[Deployment controller]
  B --> C[ReplicaSet]
  C --> D[Pods]
  D --> E[Node failure or pod crash]
  E --> C

Example Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: ghcr.io/example/web:v1.2.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            periodSeconds: 5

Rolling update behavior

During an update, Kubernetes incrementally creates new pods and removes old pods according to strategy settings.

Key controls:

  • maxUnavailable: how many old pods can be unavailable during rollout
  • maxSurge: how many extra new pods can be created temporarily

Use conservative values for critical services, and always pair rollouts with readiness probes.

Standalone pod use cases

Standalone pods are still useful for short-lived debugging:

kubectl run debug-shell --image=busybox:1.36 --restart=Never -it -- sh

Do not use this pattern for long-running applications.

Graceful shutdown

When a pod is deleted, Kubernetes sends SIGTERM to containers and waits terminationGracePeriodSeconds (default 30s) before sending SIGKILL. Use the preStop lifecycle hook to drain connections cleanly before the signal arrives, especially for servers that need time to finish in-flight requests.

lifecycle:
  preStop:
    exec:
      command: ["/bin/sh", "-c", "sleep 5"]

If your application needs more than 30 seconds to shut down, increase terminationGracePeriodSeconds.

Common mistakes

  • Deploying applications with kubectl run and no controller
  • Missing resources.requests, which hurts scheduling quality
  • Missing readiness probes, which can route traffic to not-ready pods
  • Using mutable image tags like latest in production
  • Setting imagePullPolicy: Always without understanding it pulls on every pod start, even for immutable tags
  • Not setting terminationGracePeriodSeconds long enough for slow-draining services

Quick operations checklist

kubectl get deploy,rs,pods -l app=web
kubectl rollout status deploy/web
kubectl rollout history deploy/web
kubectl rollout undo deploy/web

Summary

Pods execute containers. Deployments enforce application availability and safe change management. For production services, Deployment should be the default starting point.