Getting Started With Kubernetes Pods

With the advent of microservices, containerization has come to the forefront of app development. With containers, we can run multiple instances of our application inside the same host by efficiently using hardware resources without the instances impacting each other's processes. 

However, managing the process of deploying, managing, updating, and monitoring in complex solutions can be challenging. Thus, container orchestration platforms were created to overcome these challenges. Container orchestration platforms help manage and deploy container workloads. One of the most popular container orchestration platforms is Kubernetes.

Kubernetes is an open-source, production-ready container orchestration platform that is maintained by the CNCF (Cloud Native Computing Foundation). It comes in handy for a plethora of tasks, like scaling deployed containers as per the demand, and managing rollbacks and rollouts. While getting started with Kubernetes, various components and objects may sound new to you, but they are essential to kickstarting your journey in Kubernetes. In this article, we will focus on pods, which are the smallest building block in Kubernetes.

What are Pods?

Pods are the smallest, deployable units of computing that you can create and manage in Kubernetes.

In simpler terms, a Pod is like a logical host inside which an instance of our containerized application is running. Pods consist of one or more tightly coupled containers. Each pod is designed to run only one instance of an application. And if we want to scale out our application instance, we can do so by using multiple pods for each instance. This process of scaling out is known as replication and is handled by controllers in Kubernetes.

A pod usually consists of its unique IP address, persistent storage volumes, and configuration information, which define how the container will run. Pods are created by controllers that handle the process of rollouts and replications and manage the health of the pods in the cluster. Controllers use the information present in the pod template to create pods. Pod templates are YAML scripts that can be reused in other objects as well to manage pod deployment. 

Let’s consider a scenario where one of the nodes of our cluster is not working. In such a case, the controller will check for the failed pods inside the node and create replacement pods in other nodes based on the pod template.

Types of Pods

Depending on the number of containers running inside it, pods are classified into two types:

  1. One-container pods: As the name suggests, such pods consist of only one container. The pod acts as a wrapper for a container instance. This is one of the most commonly used pod types. 
  2. Multi-container pods: In such pods, we run two or more container instances in the same pod. The instances are tightly coupled to share resources and work as a single cohesive unit. In multi-container pods, communication and data sharing between the container instances are simplified as both can locate and communicate with each other via localhost.

Pod Lifecycle Phases

Pod lifecycle phases refer to the various states a pod usually goes through. A pod's current phase can be found in the status field of the PodStatus API object. Below are the different pod lifecycle phases.


This phase indicates that the cluster accepted the pod, but one or more containers are not running yet. Normally, we get this status when our pod is being scheduled in a healthy node or when the container image is being downloaded over the network.


This phase indicates that our pod has been scheduled in a healthy node, all the containers have been created, and at least one of the container instances is running. 


This phase indicates that the pod has terminated successfully after completing its intended task.


This phase indicates that all the containers in the pod have terminated, and one or more of the containers has terminated in failure. The failure can be due to a variety of reasons. We consider a container as failed if it exits with a non-zero status.


This phase indicates that the state of the pods is non-deterministic.

Note, sometimes you may see the status of your pods as CrashLoopBackOff error. This may happen if the pods start running and then terminate unexpectedly, then restarted and fails again and again. The Crashloopbackoff error can happen for various reasons. We can identify the root cause by exploring the exit codes.


Pods are the smallest execution unit in Kubernetes inside of which our application instance runs. Just like cells are the building blocks of humans, pods are the building blocks of Kubernetes. 

There are two types of pods: single container pods and multi-container pods, as mentioned above. Pods have 5 broad lifecycle phases: running, failed, succeeded, pending, and unknown. 

Pods can also communicate with other pods in Kubernetes by exposing certain ports. This article gives us an introduction to pods, how they are created, and their features.