Before we go deep, let us agree on what a pod is and what we mean by its lifecycle.

The short answer

A pod is the smallest unit that Kubernetes runs. It wraps one or more containers, which are lightly packaged boxes that each hold a program and everything the program needs. The containers in a pod share one network address and can share storage, so they behave like a tiny household living under one roof. A cluster is the group of machines, called nodes, on which pods run.

The pod lifecycle is the complete journey of one pod: it is requested, accepted, given a home on a node, prepared, started, kept healthy, and finally stopped and removed. Kubernetes tracks this journey in three layers of information, which we will study one by one: the pod phase, the state of each container, and a list of conditions.

The most important idea: pods do not come back

A pod is ephemeral, which means short-lived and disposable by design. Kubernetes never repairs a broken pod and never moves a running pod from one node to another. If a pod is lost, a controller creates a brand-new pod to take its place. The new pod has a new name suffix, a new unique ID, and usually a new IP address. This is why your applications must never depend on one particular pod staying alive.

To understand how a pod’s life unfolds, it helps to know what a pod is made of and who looks after it.

A pod is described by a small document called the pod specification, usually written in YAML, a simple text format for structured data. The specification says what you want: which container images to run, how much CPU and memory they need, which storage to attach, how to check their health, and what to do if they stop. Kubernetes stores this wish and then works to make it true.

Next to the specification lives the status. The specification is written by you; the status is written by Kubernetes. It records what is actually happening: which node the pod landed on, its IP address, its phase, its conditions, and the state of each container. The whole lifecycle is really a story of the status catching up with the specification.

What lives inside a pod

• Init containers run first, one at a time, to prepare the ground. Each must finish successfully before the next begins.
• App containers are the main programs. They start after all init containers are done.
• Sidecar containers are helper programs that run alongside the main program, such as a log shipper or a network proxy.
• Volumes are folders that containers in the pod can share and that can outlive a single container restart.

Who looks after a pod?

You can create a lone pod by hand, called a bare pod, but in real systems pods are almost always created and watched by a controller. A controller is a small program that keeps comparing what you asked for with what exists, and fixes any difference.

Every pod also carries an identity. It has a name, a namespace (a named area used to organize resources), and a unique ID that is never reused. When a controller replaces a pod, the ID changes. That is how Kubernetes tells “the old pod” and “its replacement” apart.

The phase is the simplest summary of a pod’s life. It answers one question: roughly where in its journey is this pod?

stateDiagram-v2
    [*] --> Pending: Pod accepted by the API server
    Pending --> Running: Placed on a node and containers started
    Pending --> Failed: Could not be started
    Running --> Succeeded: All containers exit with code 0
    Running --> Failed: A container fails and will not restart
    Succeeded --> [*]
    Failed --> [*]
    

Read the diagram from the top. Every pod is born into Pending. From there it normally moves to Running. Pods that are meant to run forever, like web servers, stay in Running until someone or something removes them. Pods that are meant to finish, like a nightly report job, move on to Succeeded when they end cleanly, or to Failed if something goes wrong. Succeeded and Failed are terminal: once a pod reaches one of them, it never goes back to Running.

Words that look like phases but are not

Terminating is shown in the pod list when a pod has been asked to stop, but it is not a phase. The pod is usually still in the Running phase while it shuts down. Completed is just the friendly name shown for a pod in the Succeeded phase. Evicted describes a pod that the node removed to protect itself; its phase is Failed, with a reason attached. And if a node is lost, the pod list may print Unknown in the status column, even though the modern way to express this is through the Ready condition, which we cover soon.

A pod is a group. Each member of the group has its own small life, and Kubernetes tracks it separately.

Each container in a pod is always in exactly one of three states. The pod’s phase is calculated from these individual states.

The reasons behind the states

The status words you see every day are really reasons attached to these three states.

Reading exit codes

When a container terminates, it leaves behind an exit code, a number that explains how it ended. Code 0 means success. Code 1 and most small numbers mean the application reported an error. Numbers above 128 mean a signal stopped it: 137 means the process was forcibly killed, which is what happens on an out-of-memory kill, and 143 means it received a polite stop request and exited. Kubernetes also remembers the previous state and the total restart count, so you can see what happened before the latest restart.

If the phase is the headline, conditions are the checklist that explains it.

A condition is a single question with a true, false, or unknown answer, together with a reason, a message, and the time it last changed. Together they show exactly how far the pod has progressed on its way to being useful.

Running is not the same as Ready

This is the most useful lesson in the whole guide. A pod can be in the Running phase, with every container alive, and still be not ready. Perhaps the application is still loading data, or a health check is failing. Kubernetes keeps such a pod alive but stops sending it traffic. Once the checks pass, the Ready condition turns true and traffic starts to flow. This is what lets a new version of an app warm up safely before users reach it.

Readiness gates

Sometimes a pod is not truly ready until something outside the pod is also finished. A readiness gate lets you add an extra condition that an external program must set to true. For example, the AWS Load Balancer Controller can use a readiness gate so that a pod only counts as ready after the cloud load balancer has registered it and marked it healthy. This avoids the gap where Kubernetes thinks a pod is ready but the load balancer has not caught up.

A pod’s life starts long before any container runs. It begins with a request, a series of checks, and a search for a home.

How the scheduler decides

Scheduling has two steps. Filtering throws out nodes that cannot work: those with too little free CPU or memory, those marked with a taint the pod does not tolerate, or those that do not match the labels the pod asked for. Scoring then ranks what is left, favouring nodes that balance load or spread copies of the same app across different machines and zones. The highest score wins.

Why a pod stays Pending

If no node passes the filters, the pod remains in Pending, and its PodScheduled condition says false with the reason Unschedulable. The scheduler keeps trying whenever the cluster changes. The pod’s event list tells you exactly why.

The scheduler has one more trick. Every pod can have a priority. If an important pod cannot fit anywhere, the scheduler may decide to remove less important pods from a node to make room. This is called preemption, and we return to it when we discuss how pods end.

Once a pod has a home, the node’s local manager, the kubelet, takes over and turns the plan into running programs.

The kubelet is a background program on every node. It watches the API server for pods assigned to its node and makes them real. It does this with the help of a container runtime, the software that downloads images and starts containers. Here is the full path from request to a pod that receives traffic.

sequenceDiagram
    participant U as User or Controller
    participant A as kube-apiserver
    participant E as etcd
    participant S as kube-scheduler
    participant K as kubelet
    participant R as Container runtime
    participant EP as EndpointSlice controller
    U->>A: Create Pod
    A->>A: Authenticate, authorize, admit, validate
    A->>E: Save Pod as Pending
    S->>A: Watch for unscheduled pods
    S->>A: Bind Pod to a node
    K->>A: Notice Pod assigned to my node
    K->>R: Create sandbox and attach network
    K->>R: Pull images
    K->>R: Run init containers one by one
    K->>R: Start app containers
    K->>A: Report Running
    K->>K: Run startup and readiness probes
    K->>A: Report Ready
    A->>EP: Pod is Ready
    EP->>A: Add Pod to Service endpoints
    

Notice how many separate helpers take part. The API server records, the scheduler chooses, the kubelet prepares, the runtime executes, and finally the endpoint controller adds the pod to the list of destinations behind its Service. No single component does everything, which is what keeps the system reliable.

What the node prepares, in order

Image pull policy

Downloading images is often the slowest step. The image pull policy decides when the node should download.

A pod’s startup is not one leap. It is a short, ordered sequence, and you can hook your own steps into it.

Init containers

An init container is a short-lived helper that runs before the main program and must finish first. Typical jobs include waiting until a database is reachable, downloading a configuration file, or preparing a folder with the right permissions. Init containers run strictly one after another. If one fails, it is retried according to the pod’s restart policy, and the app containers never start until every init container has succeeded. While this happens, the pod list shows statuses such as Init:0/2, meaning none of two init containers has finished.

Sidecar containers

A sidecar is a helper that runs for the whole life of the pod, next to the main program. Common examples are a proxy that handles encrypted traffic, or an agent that ships logs. Sidecars used to cause trouble: an ordinary sidecar might start after the main program, and in a Job it could keep the pod alive forever after the main work ended. Recent Kubernetes versions solve this with native sidecars, which are init containers marked to keep running. They start before the app containers, stay up for the whole life of the pod, and are stopped after the app containers have exited.

Lifecycle hooks

A hook is a small action that Kubernetes runs at a chosen moment in a container’s life. There are two.

A running container is not always a healthy one. Probes let Kubernetes ask the application how it feels.

A probe is a small check that the kubelet repeats at regular intervals. It can send a web request to a path, try to open a network port, run a command inside the container, or call a gRPC health service. Depending on the answer, Kubernetes takes different actions. There are three kinds of probe, and each has its own job.

The settings that matter

Each probe has a few knobs. The initial delay waits before the first check. The period sets how often to check, by default every 10 seconds. The timeout sets how long to wait for an answer, by default 1 second. The failure threshold sets how many misses in a row count as a real failure, by default 3. Together they decide how quickly a problem is noticed and how likely a healthy but busy application is to be wrongly punished.

Programs crash. What Kubernetes does next depends on one small setting and one clever delay.

Every pod has a restart policy. It tells the kubelet what to do when a container stops.

An important detail: the restart policy applies to containers, not to the pod. The kubelet restarts the failed container inside the same pod, on the same node. The pod itself is not rescheduled elsewhere just because a container crashed.

Why crash loops get slower

Imagine a container that crashes the moment it starts, for example because of a wrong setting. If Kubernetes restarted it instantly, over and over, it would waste CPU and flood the logs. Instead the kubelet uses exponential backoff: it waits 10 seconds before the first restart, then 20, then 40, doubling each time until it reaches a ceiling of five minutes. During those waits the pod shows CrashLoopBackOff. If the container then runs healthily for ten minutes, the timer resets.

A good ending matters as much as a good start. Kubernetes gives every pod time to finish its work before it is stopped.

Pods end for many reasons: a new version is rolled out, a scaling rule removes extra copies, a person deletes it, or a node is drained for maintenance. In every case the same shutdown routine applies.

sequenceDiagram
    participant U as User or Controller
    participant A as kube-apiserver
    participant EP as EndpointSlice controller
    participant K as kubelet
    participant C as Container
    U->>A: Delete Pod
    A->>A: Set deletion time and grace period
    par Traffic side
        A->>EP: Pod is terminating
        EP->>A: Remove Pod from Service endpoints
    and Node side
        K->>A: Notice Pod is terminating
        K->>C: Run preStop hook
        K->>C: Send SIGTERM
    end
    Note over K,C: Wait up to the grace period, 30 seconds by default
    K->>C: Send SIGKILL if still running
    K->>A: Confirm containers stopped
    A->>A: Remove Pod object
    

The classic race, and how to avoid it

Removing the pod from Service destinations and stopping the container happen in parallel, so for a brief moment some routers may still send a request to a pod that has just begun shutting down. Those requests fail. The usual cure is a short preStop pause of a few seconds, giving the network time to catch up before SIGTERM arrives. Your application should also stop accepting new work on SIGTERM, finish requests already in progress, close connections, and exit.

Stuck in Terminating

A pod may remain in Terminating for a long time. Common reasons are a finalizer, which is a marker that stops deletion until some cleanup finishes, a node that is unreachable so no one can confirm the containers have stopped, or a volume that will not detach. A force delete removes the record immediately without waiting for confirmation. Use it rarely, because it can leave a container still running on a lost node, and for stateful applications that can mean two copies writing to the same data.

Not every pod ends because you asked. Some are removed to protect the node, to make room for something more important, or by plain bad luck.

flowchart TB
    P["Running Pod"]
    P --> V["Voluntary disruptions - planned"]
    P --> I["Involuntary disruptions - unplanned"]
    V --> V1["Rolling update replaces the Pod"]
    V --> V2["Node drain evicts the Pod"]
    V --> V3["Scale down removes the Pod"]
    V --> V4["Higher priority Pod preempts it"]
    I --> I1["Node hardware or VM failure"]
    I --> I2["Node pressure eviction by the kubelet"]
    I --> I3["Availability zone outage"]
    I --> I4["Cloud provider reclaims a spot machine"]
    V2 --> PDB["PodDisruptionBudget can slow or block it"]
    

The safety net: PodDisruptionBudget

A PodDisruptionBudget is a promise you make to the cluster: “no matter what maintenance you do, keep at least this many copies of my app running.” The cluster will pause a drain rather than break that promise. It only protects against voluntary disruptions. Hardware failure, of course, ignores every budget.

Cleaning up the leftovers

Pods that reach Succeeded or Failed are not deleted at once, because you may want to read their logs. Eventually a garbage collector removes the oldest ones when the count grows too large; by default, that limit is 12,500 finished pods. Jobs can also set a time-to-live so that finished pods clean themselves up.

Individual pods come and go. Controllers turn that constant churn into a stable, reliable service.

Most of the time you never create pods directly. You create a Deployment, and it creates a ReplicaSet, which in turn creates and watches the pods. The ReplicaSet has one job: make sure the requested number of matching pods exists. If a pod disappears for any reason, it creates another. This is called a reconciliation loop: compare wish to reality, fix the gap, repeat.

Rolling updates

When you change the pod template, for example to use a new image version, the Deployment creates a second ReplicaSet and gradually shifts pods from the old one to the new one. Two settings control the pace: maxSurge says how many extra pods may exist above the target, and maxUnavailable says how many may be missing. Both default to 25 percent. A new pod must become Ready before an old pod is removed, so the readiness probe from Chapter 9 is what makes rolling updates safe. If the new version never becomes ready, the rollout stalls and the old pods keep serving users.

Now that you know the stages, every symptom becomes a clue that points to one of them.

A calm debugging routine

Every stage of a pod’s life is a chance to enforce safety, and every stage leaves traces you can measure.

Security at each stage

Observability at each stage

Good alerts focus on things users would feel: pods stuck in Pending for more than a few minutes, restart counts rising quickly, and deployments whose ready pod count is below target. Alerting on every single restart creates noise, because restarts are a normal, healthy part of Kubernetes life.

Teams that handle pod lifecycles well share a few habits. Teams that struggle share a few mistakes.

Patterns that work

Anti-patterns to avoid

A short checklist that applies to almost any workload, followed by the slips that catch teams most often.

Best practices

Common mistakes

These examples show how the lifecycle ideas matter when systems get large.