What Is a Pod Lifecycle in Kubernetes? Explained Simply (2026)

When you deploy something to Kubernetes, you're creating Pods. But a Pod doesn't just appear and run — it goes through a lifecycle of phases, from creation to termination.

Understanding this lifecycle helps you debug why a pod is stuck, why it keeps restarting, and what "Pending" or "Terminating" actually means.

What Is a Pod?

A Pod is the smallest deployable unit in Kubernetes. It wraps one or more containers and provides them with shared networking and storage.

When you create a Deployment, Kubernetes creates Pods. When you delete a Deployment, Kubernetes deletes those Pods. The Pod is the thing that actually runs your application.

Pod Phases

Every Pod has a phase — a high-level summary of where it is in its lifecycle:

kubectl get pod my-pod -o wide
# NAME      READY   STATUS    RESTARTS   AGE
# my-pod    1/1     Running   0          5m

The phases:

Pending

The Pod has been accepted by Kubernetes but is not yet running. It's waiting for something.

Possible reasons:

• Not scheduled yet — No node has been selected. Maybe no node has enough CPU/memory, or there's a taint/toleration mismatch
• Image being pulled — The container image is downloading from the registry
• Init containers running — Init containers run before the main container and must complete first

# See why a pod is Pending
kubectl describe pod my-pod | grep -A 10 Events

Running

The Pod has been scheduled to a node, all containers have been created, and at least one container is running (or starting/restarting).

Running doesn't mean healthy. A pod can be Running but not ready — its readiness probe might be failing.

# Running but not ready
NAME      READY   STATUS    RESTARTS
my-pod    0/1     Running   0        # 0/1 = container not ready

Succeeded

All containers in the Pod have terminated successfully (exit code 0) and will not be restarted.

This is the normal end state for Jobs and batch tasks — they run, complete successfully, and become Succeeded.

Failed

All containers in the Pod have terminated, and at least one exited with a non-zero exit code or was killed by the system.

This is the end state for Jobs that crash, or pods with restartPolicy: Never that fail.

Unknown

The state of the Pod cannot be determined — usually because the node the Pod was running on is unreachable (network partition, node failure).

Container States Within a Pod

Each container inside a Pod has its own state:

Waiting

The container is not running yet. It's:

• Pulling the image
• Waiting for init containers to finish
• ContainerCreating — waiting for the runtime to start it

kubectl describe pod my-pod | grep -A 5 "State:"
# State:          Waiting
#   Reason:       ContainerCreating

Running

The container is executing normally. The startedAt timestamp shows when it began.

Terminated

The container finished — either successfully (exit code 0) or with an error.

# State:          Terminated
#   Reason:       Error
#   Exit Code:    1
#   Started:      Mon, 19 May 2026 10:00:00
#   Finished:     Mon, 19 May 2026 10:00:05

The Full Pod Lifecycle: Step by Step

Here's what happens from kubectl apply to pod running:

kubectl apply -f deployment.yaml
        │
        ▼
1. API Server accepts the Pod spec
        │
        ▼
2. Scheduler assigns Pod to a Node
   (checks CPU/memory, taints, affinity)
        │
        ▼
3. kubelet on that Node sees the assignment
        │
        ▼
4. Init containers run (if any)
   Must complete successfully before main containers start
        │
        ▼
5. Container runtime (containerd) pulls image
        │
        ▼
6. Main container starts
        │
        ▼
7. postStart hook runs (if configured)
        │
        ▼
8. Readiness probe starts checking
   Pod added to Service endpoints only when probe passes
        │
        ▼
9. Liveness probe starts checking
   Container restarted if probe fails
        │
        ▼
10. Pod is Running and serving traffic

Init Containers

Init containers run before the main container and must complete successfully. They're used for:

• Waiting for a database to be ready
• Downloading config files
• Running database migrations
• Setting up permissions

spec:
  initContainers:
    - name: wait-for-db
      image: busybox
      command: ['sh', '-c', 'until nc -z postgres 5432; do sleep 2; done']
  containers:
    - name: app
      image: myapp:v1

If an init container fails, the Pod stays in Pending (with status Init:0/1).

# Pod stuck in init
NAME      READY   STATUS     RESTARTS
my-pod    0/1     Init:0/1   0

Probes

Kubernetes uses probes to check container health. There are three types:

Startup Probe

Checks if the container has started successfully. While this probe is running, liveness and readiness probes are disabled. Useful for slow-starting applications.

Readiness Probe

Checks if the container is ready to receive traffic. A failing readiness probe removes the pod from the Service's endpoint list — requests stop going to it.

Liveness Probe

Checks if the container is alive. A failing liveness probe triggers a container restart.

readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  failureThreshold: 3
 
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  failureThreshold: 3

Restart Policies

restartPolicy controls what happens when a container exits:

• Always (default for Deployments) — Always restart, regardless of exit code. Used for long-running services.
• OnFailure — Restart only if exit code is non-zero. Used for Jobs.
• Never — Never restart. Used for one-shot tasks.

Kubernetes uses exponential backoff between restarts: 10s, 20s, 40s, 80s... up to 5 minutes. This is the CrashLoopBackOff status you see when a container keeps failing.

# CrashLoopBackOff = container keeps crashing, K8s waiting before restarting
NAME      READY   STATUS             RESTARTS   AGE
my-pod    0/1     CrashLoopBackOff   5          10m

Pod Termination: The Graceful Shutdown

When you delete a Pod (or scale down a Deployment), this is what happens:

kubectl delete pod my-pod
        │
        ▼
1. Pod enters "Terminating" state
   Removed from Service endpoints immediately — no new traffic
        │
        ▼
2. preStop hook runs (if configured)
        │
        ▼
3. SIGTERM sent to container
   Application should start graceful shutdown
        │
        ▼
4. terminationGracePeriodSeconds countdown (default: 30s)
        │
        ▼
5. If container still running after grace period → SIGKILL
        │
        ▼
6. Pod removed from API server

Why this matters: If your application doesn't handle SIGTERM, it gets force-killed after 30 seconds — ongoing requests get dropped, database connections aren't closed cleanly.

spec:
  terminationGracePeriodSeconds: 60  # Give app more time to drain
  containers:
    - name: app
      lifecycle:
        preStop:
          exec:
            command: ["/bin/sh", "-c", "sleep 5"]  # Let load balancer drain

Common Pod Status Reference

Understanding the Pod lifecycle is foundational for debugging Kubernetes. Most issues — stuck pods, restart loops, traffic problems — trace back to one of these lifecycle phases.

Related: Kubernetes Troubleshooting Guide | What is a Readiness vs Liveness Probe