What is a pod?

Pod provides an abstraction that helps Kubernetes manage application containers. In this topic, you will learn what a pod is. How is it different from a container? How pods work and the problems a pod solves.

What is a pod?

A pod is the smallest deployment unit in Kubernetes. It contains one or more containers. Pods provide containers with shared storage, inter-process communication (IPC), and network. The containers within a pod can

• communicate with each other using a localhost or an inter-process communication (IPC);
• read and write files from the shared storage.

Difference between pods and containers

You can think of containers as isolated boxes that contain all the necessary libraries, dependencies, and other resources necessary for running an application in isolation.

A pod is a group of one or more containers. It provides an abstraction that allows Kubernetes to manage application containers (such as scheduling, monitoring, and more).

Even though a pod can contain several containers, Kubernetes views a pod as a single unit. Thus simplifying container management.

Lifecycle of a pod

Like any other object in computer memory, a pod follows a well-defined lifecycle starting from the Pending state, moving through Running — if at least one of its primary containers runs as expected. Then through either the Succeeded or Failed states depending on whether any container in the Pod terminated in failure. The lifecycle of a pod helps Kubernetes to take appropriate actions depending on the pod's state.

Consider a scenario when a pod is in the Failed state. Kubernetes tries to schedule a new pod to replace the failed pod. And the failed pod will then be garbage collected automatically.

There are 5 states in the life of a pod:

• Pending — This is the first stage in the life of a pod. This state indicates that Kubernetes accepted the request to create a pod. Whether Kubernetes accepts the pod or not depends on many factors like availability of resources such as CPU, memory, and others requested by the pod, node affinity, etc). It also indicates that containers within the pod are being built(fetching the images, running the init containers, etc).
• Running — A pod progresses into this stage once Kubernetes completes building the containers that make up the pod and assigns the pod to a node in the cluster. A pod continues to be in this state if at least one container is still running, or is in the process of starting or restarting.
• Succeeded — Sometimes pods are deployed to accomplish certain tasks (such as fetching data from the internet or computing something at regular intervals of time). In these scenarios, you do not need to manually terminate pods. Pods will exit with no errors once they accomplish the task. When this happens, a pod is said to be in the succeeded state.
• Failed — A pod enters this state when all containers in the Pod terminate and at least one container either exited with non-zero status or was terminated by the system.
• Unknown — Sometimes Kubernetes is unable to establish a connection to the node on which the pod is running (this can happen due to network failures). As a result, the pod's state can not be determined. Kubernetes declares the pod's state as unknown.

Status of a pod

Pods also have an attribute called PodStatus. This attribute provides information about its status. PodStatus has an array of conditions called PodConditions. Kubernetes decides the status of a pod by determining if that pod passes a condition or not. Kubernetes manages the following conditions:

• PodScheduled — Kubelet checks whether the Pod is initialized and ready to be deployed on a node in the cluster.
• PodHasNetwork — This condition provides information on whether the networking for a pod is configured or not.
• ContainersReady — Kubelet checks whether all the containers in a pod are in the ready state.
• Initialized — For a Pod with init containers (containers that must do certain tasks before the application containers start), kubelet sets the Initialized condition to true after the init containers are successfully completed (which happens after successful sandbox creation and network configuration. Before init containers can do their task, they need successful sandbox creation and networking configuration). For a Pod without init containers, kubelet sets the Initialized condition to true before sandbox creation and network configuration starts.
• Ready — Kubelet checks whether a Pod is able to serve requests.

Each of these conditions has an attribute called status that can have one of the three possible values: true, false, or unknown. The conditions also have a message attribute that describes why the pod failed that condition.

Advantages of pods

Container abstraction — Pod provides an abstraction that allows Kubernetes to manage application containers as a single unit. All the containers in a pod are located on the same node and are scheduled at the same time, this helps in simplifying container management.

Resource sharing — The pod contains partitions of resources(such as CPU, memory, storage, network, etc), the technical term for this partition is Linux Namespace.

The image above represents a pod with multiple partitions like — IPC, network, and mnt. By placing containers in these partitions, the processes in one container can see the same resources as seen by other processes in any other container within that pod. As a result, containers within a pod can communicate with one another.

Here's what each partition represents:

• network namespace: allows the containers to communicate with each other using localhost.
• mnt namespace: allows the containers within this pod to access volumes that kubernetes provides. For example, persistent volumes.
• ipc namespace: allows containers in a pod to communicate with one another using shared memory, message queues, or other resources.

Health monitoring — While the pod is in the running state, Kubernetes tracks the states of containers within the pod to determine the necessary actions to make the pod healthy again.

Disadvantages of pods

Pods can only work with containers. In some scenarios where an entire application is just one single binary, you do not need to containerize the application. Instead, you need an orchestration tool when deploying several instances of this application. In this situation, you need to learn different tools like Nomad (Nomad is an orchestration tool like Kubernetes. It can also run binaries besides containers).

In production, configuring and managing Kubernetes clusters can be complex. Depending on the availability of resources on each node in the cluster, pods may be deployed on different nodes, debugging networking issues between pods can be difficult.

Conclusion

Let's summarize the topic in a few points

• Pods are the smallest deployable units in Kubernetes;
• A pod may contain several containers and provides common resources for these containers to interact with one another;
• A pod has a well-defined lifecycle starting from its creation to either a successful or failed termination;
• PodStatus is a pod attribute that consists of an array of conditions called PodCondition;
• Pods allow container abstraction, resource sharing, and health monitoring which are great advantages;
• Pods are not a solution when you do not need to containerize applications and debugging network issues can be difficult.