Once a Pod manifest is submitted to the Kubernetes API server, the Pod does not simply appear; it progresses through a distinct lifecycle. Understanding this lifecycle is fundamental to managing and troubleshooting your applications. Kubernetes tracks the state of a Pod primarily through a phase field in its status object. This phase is a high-level summary of where the Pod is from creation to termination.
Every Pod in a cluster exists in one of five possible phases. These phases represent the aggregate state of the containers within the Pod.
Pending: The Pod has been accepted by the Kubernetes cluster, but one or more of its container images have not been created and are not yet running. This delay can occur for several reasons, such as the scheduler waiting to find a suitable node with enough resources, or the node taking time to download a large container image.
Running: The Pod has been bound to a node, and all of its containers have been created. At least one container is still running, or is in the process of starting or restarting. It is important to note that a Pod in the Running phase does not necessarily mean the application inside is healthy or ready to serve requests. It only means the container processes have been started.
Succeeded: All containers in the Pod have terminated with a status code of 0, indicating successful completion. These Pods will not be restarted. This phase is common for short-lived tasks or batch jobs that are designed to run once and then exit.
Failed: All containers in the Pod have terminated, and at least one container has terminated with a non-zero status code, indicating failure. This phase indicates that an error occurred within one of the Pod's containers.
Unknown: The state of the Pod could not be obtained. This typically happens when the control plane loses communication with the Kubelet on the node where the Pod is supposed to be running.
The following diagram illustrates the primary transitions between these phases.
The lifecycle of a Kubernetes Pod, showing the progression from Pending to a terminal state of Succeeded or Failed.
While the phase gives a quick summary, it can sometimes mask the underlying details. For a more granular view, Kubernetes uses a set of conditions within the Pod's status field. Each condition is a boolean (True, False, or Unknown) that represents a specific aspect of the Pod's state.
The most significant conditions include:
Ready condition is True only when ContainersReady is True.A common scenario is a Pod in the Running phase but with its Ready condition set to False. This tells you that while the container processes are active, the application inside may still be starting up, loading data, or failing its health checks.
Drilling down even further, Kubernetes also tracks the state of each individual container inside a Pod. A container can be in one of three states:
Waiting: The container is not running. It might be in this state because it is pulling its image, running pre-start hooks, or waiting for secrets to be available. The reason for the Waiting state is provided in the Pod's status. A common reason you might see is ImagePullBackOff, which means Kubernetes is having trouble fetching the container image.
Running: The container is executing without issues.
Terminated: The container has completed its execution and stopped. It can be in this state either because it finished its task successfully or because it failed. Details such as the exit code and reason are available. A container that repeatedly fails and is restarted by Kubernetes might show a reason of CrashLoopBackOff.
You can inspect all these details using the kubectl describe pod command. The output provides a comprehensive view, including the Pod's current phase, its conditions, and the state of each of its containers. This level of detail is invaluable when you need to diagnose why a Pod isn't behaving as expected.
For example, observing a Pod stuck in Pending might lead you to check the PodScheduled condition, which could be False. The events section in the kubectl describe output would then likely tell you why the scheduler couldn't place it, such as insufficient CPU or memory on all available nodes.
Was this section helpful?
© 2026 ApX Machine LearningEngineered with