The Lifecycle of a Pod in Kubernetes: From Creation to Termination

Last Updated : 21 Jan, 2026

Kubernetes, or K8s is an open-sourced container orchestration technology that is used to automate the manual processes of deploying, managing and scaling applications by the help of containers. Kubernetes was originally developed by engineers at Google and In 2015, it was donated to CNCF (Cloud Native Computing Foundation).

Kubernetes Pod

A Pod is the smallest or fundamental component of a Kubernetes architecture. One very important feature of Pod is that it is ephemeral. This means that if a Pod fails, then Kubernetes can automatically create a new replica. A pod is an abstraction over a container. Pod creates a running environment or a layer on top of the Container. This is also so that we don't have to work directly with Docker or whatever container technology we use in Kubernetes. so we only interact with the Kubernetes layer.

Pod's Job

The job of a Pod is to run multiple containers inside it that need to work together. The pod is usually meant to run one application container inside of it. You can run multiple containers inside one pod, but usually, it's only the case if you have one main application container and a helper container or some side service that has to run inside of that pod.

For example: You can use the main container in a Pod to run your web application, or you can use a helper container that would support the main container by providing services that tail log files for the web application container.

Scheduling and Initialization of a Pod

Scheduling: When a new Pod is added to the cluster, Kubernetes scheduler decides the Node where the Pod will be scheduled, the Kubernetes scheduler decides this on the basis of various factors like resource requirements, Node availability, and any configured scheduling constraints or affinity rules. Once the scheduler finds a suitable Node, it assigns the Pod to that Node. the Pod will remain unscheduled until a suitable Node is available for it to be assigned.

After the Pod is scheduled on a Node, Kubernetes executes some initialization steps so that the containers inside the Pod start running, like executing Init Containers. Init Containers are executed so to perform the setup tasks for the Pod, for example - initializing a database, configuring volumes, etc.

Types Of Pod

In Kubernetes, there are two types of Pods:

Single Container Pods: Single Container Pods are the simplest type of Pod with one container per Pod. These are the most common type of Pods. Following is an example of a single container Pod:

apiVersion: v1
kind: Pod
metadata:
 name: Tomcat
spec:
 containers:
 - name: Tomcat
 image: tomcat: 8.0
 ports:
containerPort: 7500
 imagePullPolicy: Always

Multi Container Pods: Multi Container Pods are the Pods with multiple containers inside it. They are a more complex compared to single container Pods but they are used in cases like we discussed above where we want a primary application container and a helper container that needs to run along with the primary application container. These helper containers are used to provide logging or monitoring services.

apiVersion: v1
kind: Pod
metadata:
 name: Tomcat
spec:
 containers:
 - name: Tomcat
 image: tomcat: 8.0
 ports:
containerPort: 7500
 imagePullPolicy: Always
 -name: Database
 Image: mongoDB
 Ports:
containerPort: 7501
 imagePullPolicy: Always

Key Terminologies

Pod lifetime

The Pod lifetime is the entire timeline of existence of a Pod from the point when the Pod is created to the point when it is terminated. The pod lifetime is not a liner journey where the Pod is created and then terminated when its use is over, in Pod lifetime the Pod may be created and then run for a while, it may fail, it may be recreated and so on.

There are various factors that influence the Pod lifetime, some of these factors are the restart policy of the Pod, the health of Pod's containers and the overall state of the Kubernetes cluster where Pod is running.

Container states

We will later discuss the Pod phases in detail, but before that we should know that like Pods have phases, individual containers inside those Pods have their own states too. These states gives us a summary of what is happening inside the Pod. Following are the possible container states:

  • Waiting: the container in this state is not yet ready, it is running operations to get to the 'Running' state.
  • Running: This is the state where execution happens and the container is executing without any issues or failures.
  • Terminated: Once the execution is completed or if any failure occurs, then the container goes into this state.

How Pods handle problems with containers:

In Kubernetes, If the container fails for some reasons Pods have the ability to fix these failures by restarting the container. All this depends in the restart policy of the Pod:

  1. Always: If the container goes down, Kubernetes will attempt to restart it. This is the default restart policy in Kubernetes.
  2. OnFailure: If the container goes down, Kubernetes will attempt to restart the container if and only if it exits with a non-zero status code.
  3. Never: As the name suggests Kubernetes will not restart the container if it fails.

Pod conditions

Pod conditions are booleans that tell us about the condition of the Pod. Pod conditions are of five types:

  1. PodScheduled: tells if the Pod has been scheduled to a node or not.
  2. PodReadyToStartContainers: this is a beta feature that tells whether the Pod sandbox has been successfully created and configured or not.
  3. Ready: tells if the containers inside the Pod are ready or not.
  4. Initialized: is true if all the 'init' containers of that Pod have completed successfully.
  5. ContainersReady: tells if all containers in that Pod are ready or not.

Container probes

Probe refers to the health checks that Kubernetes provides in order to monitor and take action on the state of Pods or containers. container probes are used to make sure that the traffic is served only by the healthy Pods. These health checks are used to detect those containers that haven't started yet, container that are under full capacity and containers that are dead, all these type of containers are unfit for serving traffic. There are three types of Container probes:

  • Liveness probes: Liveness probes indicates whether the container is running or not.
  • Readiness probes: Readiness probes indicate whether the container is ready to serve requests or not.
  • Startup probes: Startup probes are used to indicate whether the application within the container has started or not.

The Lifecycle of a Pod in Kubernetes

Like other Kubernetes objects, a Pod in Kubernetes goes through various phases during its lifecycle. Let's discuss each of its phases in detail:

1. Pending Phase

In Kubernetes, when you create a new Pod, the Pod is accepted by the cluster but containers inside it have are not ready to run yet, then the Pod is in Pending Phase. The Pod will remain in the Pending phase until and unless it is scheduled and all the containers inside it are created and are in ready to run state.

Pending Phase = time taken by Pod to get scheduled + time taken by Pod in downloading container images.

2. Running Phase

A Pod is comes in the running phase when it is linked to a node and all the containers inside it have been created. When the Pod is scheduled and all of its containers inside it are active (are created) then the Pod moves from the Pending phase to the Running phase. The Pod will stay in the Running phase until:

  • Either the Pod is deleted.
  • or all containers inside the Pod terminate on their own.
  • or if the Node's hosting containers fails.

3. Succeeded Phase

Under normal circumstances, Succeeded Phase is the final phase in the Pod's lifecycle where all the containers within it terminate successfully and will not be restarted. This means that the containers that were supposed to run have run successfully and have exited with a success code.

4. Failed Phase

A Pod enters the Failed phase if at least one of the containers within it has terminated with a failure code. Once a Pod is in the Failed phase it cannot go to any other phase. The Pod would go to the failed state when:

  • Either the container exits with non zero status.
  • or when the container was terminated by the system.

5. Unknown Phase

When the the state of the Pod is not able to be obtained by the Kubernetes cluster, it is said to be in Unknown Phase. Unknown Phase is usually caused by some error in communicating with the node where the Pod in running. Once the communication error is fixes, you will find the appropriate phase of the Pod.

Note :- When a Pod is being deleted, it is shown as "Terminating" by kubectl but the Terminating status is not one of the Pod phases. It goes to a Pod lifecycle phase after some time.

Tutorial: Using Kubernetes Pod

In this tutorial, we will see how to create a Pod and witness its lifecycle phases. We will be using Minikube to create a local Kubernetes cluster.

Step 1: Enter the following command to start the Kubernetes cluster:

minikube start

Minikube is an open-source tool that is basically like a one node cluster where the master processes and the work processes both run on one node. This node must have a Docker container runtime pre-installed to run the containers or pods with containers on this node. If you are logged in as a root user you might get an error message:

Exiting due to DRV_AS_ROOT: The "docker" driver should not be used with root privileges.

This is because the default driver in the Docker driver and it should not be used with root privileges. For fixing this we should log in as a different user that the root user. Make sure to login as a different user. After the installation is complete, you will get a similar result:

minikube start

Step 2: Create a configuration file for our Pod:

In order to have a look at some of the phases of a Pod lifecycle, Let's create a config file for creating a simple Pod with a single container. For that you have to create a file named gfg-pod.yaml:

touch gfg-pod.yaml

and paste the following code inside it:

apiVersion: v1
kind: Pod
metadata:
  name: gfg-pod
spec:
  containers:
  - name: gfg-container
    image: nginx
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"

Step 3: Creating the Pod

Now that we have created our config file, we can use the following command to apply the config file to create the Pod:

 kubectl apply -f gfg-pod.yaml
Creating the Pod

And the Pod called "gfg-pod" will be created.

Step 4: Checking the Pod Status

In order to see the list of Pods running in your cluster and also to check the status of the Pod you can use the following command:

Checking the Pod Status

Since we took some time, our gfg-pod has already reahed the "Running" phase.

Step 5: Delete the Pod and create it again

To delete our current gfg-pod, enter the following command:

kubectl delete pod gfg-pod

this will delete your pod and you will get a similar result:

Delete the Pod and create it again

Now if you check the list of Pods present in the cluster:

kubectl get pods

you will see that there are no Pods running:

kubectl get pods

Let's now create the Pod again and as soon as you create a Pod, check the list of pod:

 kubectl apply -f gfg-pod.yaml

And quickly, enter the following command:

kubectl get pods

You will see that the Pod is in 'ContainerCreating' state:

kubectl get pods

And with that you complete your tutorial about Pod lifecycle. You can delete the Pod as well as the Kubernetes Cluster.

Comment

Explore