Skip to main content

Kubernetes Pod Lifecycle

From Birth to Death

Think of a Kubernetes Pod like a firecracker 🧨. It is designed to be lit, do its job (sparkle or bang), and then it is finished. You don't try to "fix" a burnt-out firecracker; you just get a new one.

Unlike a Virtual Machine (VM) which you might reboot to fix, a Pod is designed to be disposable. It is born, it serves its purpose, and it dies. If a Pod "dies," Kubernetes doesn't resurrect it; it replaces it with a new one.

  • "Pods don't heal, they are replaced." -  If a Pod dies, the controller creates a new one with a new ID and IP.

  • "Pending means Waiting." - Usually waiting for a Node to open up or an image to download.

  • "Unknown is scary but usually just network lag." – The Master has lost contact with the Worker Node; the Pod might actually be fine.

  • "Running ≠\neq`````` Ready." – Just because the engine is on (Running) doesn't mean the car is ready to drive (Ready to take traffic).

  • Ephemeral Nature: Pods are disposable entities.

  • Phase vs. State: "Phase" is the high-level summary (e.g., Running), while "Container State" is the low-level detail (e.g., CrashLoopBackOff).

  • Graceful Termination: Kubernetes gives Pods 30 seconds (default) to pack up and leave before force-killing them.

The 5 Phases of a Pod​

PhaseAnalogyWhat's Happening?Common Error/StatusPendingThe Waiting Room ⏳API accepted it, but it's not on a Node yet.ErrImagePull, ImagePullBackOff, PendingRunningThe Active Job 🏃‍♂️Assigned to a Node, container process started.CrashLoopBackOff, RunningSucceededMission Accomplished ✅All containers finished successfully (Exit Code 0).Completed (Common in CronJobs)FailedThe Crash 💥Containers stopped, at least one failed.Error, OOMKilled (Out of Memory)UnknownThe Ghost 👻Master cannot talk to the Worker Node (Kubelet).Unknown (Network partition)

  • Pending (The Waiting Room): The API Server has created the Pod object, but it hasn't been scheduled or started yet.

  • Scheduling: The Scheduler is looking for a Node with sufficient resources (CPU/RAM).

  • Image Pulling: The Node is currently downloading the container image (this can take time for large images).

  • Running (The Active State): The Pod has been assigned to a Node, and at least one container inside it is active or in the process of starting / restarting.

  • Crucial Distinction: Running ≠\neq`````` Ready.

  • Running means the container process has started.

  • Ready means the application is actually capable of accepting traffic (passed its Readiness Probe).

  • Succeeded (The "Job Done" State): All containers in the Pod have terminated successfully (Exit Code 0) and will not restart.

  • Use Case: This is common for Batch Jobs or CronJobs (e.g., a database backup script that runs, finishes, and stops).

  • Failed (The Crash): All containers have terminated, and at least one terminated with an error (Exit Code ≠\neq``````** **0).

  • Implication: The application crashed or the process was killed. Depending on your restartPolicy, Kubernetes may try to create a new Pod to replace it.

  • Unknown (The Mystery): The Control Plane (Master) cannot retrieve the status of the Pod.

  • Common Cause: Usually a network partition where the Kubelet on the Worker Node cannot communicate with the API Server. The Pod might still be running, but the Master doesn't know.

The Death of a Pod​

Graceful Shutdown When you delete a Pod, Kubernetes doesn't just kill it instantly. It gives it a "Grace Period" (default 30s) to finish up work.

  • Pod status turns to Terminating.

  • Service Endpoint Removed: Traffic stops being sent to this Pod immediately.

  • PreStop Hook: If defined, a script runs (e.g., nginx -s quit) to save state.

  • SIGTERM: The main process is told to stop.

  • SIGKILL: If it's still running after 30s, Kubernetes forces it dead.

Pro Tip: If your app takes 60s to shut down, you must increase terminationGracePeriodSeconds in your YAML!

Container States vs. Pod Phases​

"Why is my Pod Running but my Container Waiting?"

  • Pod Phase: The wrapper status (e.g., Running).

  • Container State: The process status inside (e.g., Waiting, Running, Terminated).

Common Scenario:

  • Pod Phase: Running (Because the Pod is scheduled on a node).

  • Container State: Waiting (Reason: CrashLoopBackOff or ErrImagePull).

  • Always check kubectl describe pod to see the Container State details if something looks wrong.