Pod is the basic building block of Kubernetes, the smallest deployable unit in the Kubernetes that can be created and managed.

A pod is a group of one or more containers (such as Docker containers) with shared storage/network, and a specification for how to run the containers. It represents a single instance of an application in Kubernetes.

A pod’s contents are always co-located and co-scheduled, and run in a shared context.

Here is the configuration file for the Pod:

apiVersion: v1
kind: Pod
  name: nginx-demo
  - name: shared-data
    emptyDir: {}
  - name: nginx
    image: nginx
    - name: shared-data
      mountPath: /usr/share/nginx/html

Create the Pod:

$ kubectl create -f nginx-demo.yaml
pod "nginx-demo" created

Verify that the Container is running:


$ kubectl get pod nginx-demo
nginx-demo  1/1     Running   0          48s


Pod Lifecycle

Here are the possible values for STATUS:


The Pod has been accepted by the Kubernetes system, but one or more of the Container images has not been created. This includes time before being scheduled as well as time spent downloading images over the network, which could take a while.


The Pod has been bound to a node, and all of the Containers have been created. At least one Container is still running, or is in the process of starting or restarting.


All Containers in the Pod have terminated in success, and will not be restarted.


All Containers in the Pod have terminated, and at least one Container has terminated in failure. That is, the Container either exited with non-zero status or was terminated by the system.


For some reason the state of the Pod could not be obtained, typically due to an error in communicating with the host of the Pod.


The pod has run to completion as there’s nothing to keep it running eg. Completed Jobs.


This means that one of the containers in the pod has exited unexpectedly, and perhaps with a non-zero error code even after restarting due to restart policy.


Pods in a Kubernetes cluster can be used in two main ways:

One container per Pod

It is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly.

Multiple containers per Pod

Pods that run multiple containers that need to work together. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources.

The Pod wraps these containers and storage resources together as a single manageable entity.


Pods and Controllers

A Controller can create and manage multiple Pods for you, handling replication and rollout and providing self-healing capabilities at cluster scope.

For example, if a Node fails, the Controller might automatically replace the Pod by scheduling an identical replacement on a different Node.

Some of Controllers that contain one or more pods:

  • Deployment
  • StatefulSet
  • DaemonSet