Pod Lifecycle and Status
Introduction: Beyond the Happy Path
In the previous lesson, you created Pods that worked correctly on the first try. You wrote a YAML manifest, applied it, and saw your Pod running smoothly. That's the happy path, and it's important to understand, but real-world Kubernetes operations involve troubleshooting failures just as often as creating working resources.
Pods don't always start successfully. Images might not exist, containers might crash immediately, or network issues might prevent image downloads. Understanding how Kubernetes manages Pods through their entire lifecycle — from creation through running to termination and failure — is essential for operating applications reliably. In this lesson, you'll learn how to read Pod status, interpret events, diagnose common failures, and observe what happens when Pods are deleted. By the end, you'll be able to troubleshoot broken Pods confidently and understand what Kubernetes is doing behind the scenes.
Pod Phases: The Journey of a Pod
Every Pod goes through a series of phases during its lifetime. A phase is a high-level summary of where the Pod is in its lifecycle. Kubernetes tracks five possible phases: Pending, Running, Succeeded, Failed, and Unknown.
When you first create a Pod, it enters the Pending phase. This means Kubernetes has accepted the Pod definition and is working to schedule it onto a node and pull the container images. The Pod stays in Pending until all containers have been created and at least one container starts running. During this phase, Kubernetes is finding a suitable node, pulling images from registries, and preparing the environment.
Once at least one container in the Pod starts running, the phase changes to Running. This doesn't mean all containers are healthy or ready to serve traffic, just that they've started. The Pod remains in Running as long as at least one container is still running or restarting. Most long-lived applications, like web servers, stay in the Running phase indefinitely.
The Succeeded phase applies to Pods that are designed to run to completion, like batch jobs or one-time tasks. When all containers in the Pod terminate successfully (exit code 0) and won't be restarted, the Pod enters Succeeded. You won't see this phase often with typical web applications because they're meant to run continuously.
If all containers in a Pod have terminated and at least one terminated with a failure (non-zero exit code), the Pod enters the Failed phase. This indicates something went wrong — the application crashed or a configuration error caused the container to exit uncleanly. Failed Pods stay in this phase and don't automatically recover unless a higher-level controller (like a Deployment) recreates them.
Finally, the Unknown phase means Kubernetes lost contact with the node where the Pod was running and can't determine the Pod's actual state. This is rare and usually indicates a serious infrastructure problem, like a node failure or network partition. Understanding these phases helps you quickly assess what's happening with your Pods and where to focus your troubleshooting efforts.
