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

Phase	Analogy	What’s Happening?	Common Error/Status
Pending	The Waiting Room ⏳	API accepted it, but it’s not on a Node yet.	ErrImagePull, ImagePullBackOff, Pending
Running	The Active Job 🏃‍♂️	Assigned to a Node, container process started.	CrashLoopBackOff, Running
Succeeded	Mission Accomplished ✅	All containers finished successfully (Exit Code 0).	Completed (Common in CronJobs)
Failed	The Crash 💥	Containers stopped, at least one failed.	Error, OOMKilled (Out of Memory)
Unknown	The Ghost 👻	Master cannot talk to the Worker Node (Kubelet).	Unknown (Network partition)

1. 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).
2. 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).
3. 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).
4. 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.
5. 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.

1. Pod status turns to Terminating.
2. Service Endpoint Removed: Traffic stops being sent to this Pod immediately.
3. PreStop Hook: If defined, a script runs (e.g., nginx -s quit) to save state.
4. SIGTERM: The main process is told to stop.
5. 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.

---