What is a Pod?

How does Kubernetes manage and orchestrate container workloads? When deploying applications, do you place containers directly into the cluster? In this topic, we will explore Pods, the smallest deployable units in Kubernetes.

What is a Pod?

A Pod provides an abstraction that helps Kubernetes manage containers. It is the smallest deployment unit and contains one or more containers. This makes it easy for Kubernetes to do its work (scheduling, monitoring, and more). Think of a Pod as a logical host for your application containers:

A Pod provides a shared environment, giving its containers a single shared IP address, network namespaces, and shared storage volumes. This design means all containers in a Pod can easily communicate with each other, as if they were running on the same physical machine.

In some cases, a Pod will contain only one container. In other cases, a Pod will contain multiple interdependent containers. Regardless, Kubernetes views a Pod as a single unit. Keep in mind that Kubernetes does not manage containers directly; it manages Pods.

Types of containers in a Pod

While a Pod can hold just a single container, you'll often need to run multiple containers that work together to support an application. Your application runs in standard application containers and handles the Pod's main ongoing workload. Other special containers include init, sidecar, and ephemeral containers.

Init containers run and must complete before application containers are allowed to start. These are perfect for running setup scripts, setting permissions, or initializing the database. You can have one or more init containers that the Kubelet runs sequentially. We'll see how to define init containers in your Pod spec later on.

Some advantages of having init containers are:

• They can provide capabilities not present in, or ideal for, your main application image.

• They can be given access to environment variables that app containers should not access.

• They can run tools or code that would make your main application container less secure.

• They can check conditions, such as whether a resource has been created and is available, before the main application container runs.

• A Pod cannot be ready until its init containers succeed.

Next, there are sidecar containers. These are helper containers that run before your main application container, but unlike init containers, they continue to run alongside it. Sidecar containers are designed to provide supporting features, like collecting logs, proxying network traffic, or syncing files.

Finally, Kubernetes supports ephemeral containers. These are temporary containers injected into an already running Pod. They are used strictly for debugging, troubleshooting, and inspecting the application's state. This is useful in cases where the container has crashed or lacks debugging utilities. We'll see how you can create ephemeral containers in future topics.

Pod lifecycle

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

There are 5 phases in a Pod's lifecycle:

• Pending — This is the first stage. Kubernetes has accepted the Pod, but is waiting to schedule it based on factors such as resource availability (CPU, memory) and node affinity. The Pod also stays in this state while fetching container images and running init containers.

• Running — The Pod enters this stage once it is assigned to a Node and remains there for its entire lifetime.

• Succeeded — Some Pods are deployed for specific, short-lived tasks (like fetching data or running calculations). When they complete their work, they exit without errors and will not be restarted.

• Failed — A Pod reaches this state when all of its containers have terminated, and at least one container failed. This happens if a container exits with an error (a non-zero status) or is forcibly terminated by the system.

• Unknown — If Kubernetes loses communication with the node hosting the Pod—usually due to network failures—it can no longer determine the Pod's status and marks it 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 determines a Pod's status by checking whether it passes a condition. The Kubelet manages the following conditions:

• PodScheduled — Kubelet checks whether the Pod is initialized and ready to be deployed on a node in the cluster.

• PodReadyToStartContainers — A Pod's sandbox is created, and networking is configured.

• ContainersReady — All containers in a Pod are in the ready state.

• Initialized — For a Pod with init containers, all init containers have completed.

• DisruptionTarget — The Pod is about to be terminated due to a disruption, such as eviction policies, preemption, or garbage collection.

• Ready — Pod can serve requests.

Important attributes in a condition include a 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 — a Pod provides a single unit of abstraction that allows Kubernetes to manage application containers. 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, and network. 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 in the above diagram represents:

• network namespace: allows the containers to communicate with each other using localhost.

• mnt namespace: allows containers within this Pod to access volumes provided by Kubernetes—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 running, Kubernetes tracks the containers' states to determine the necessary actions to restore them to a healthy state.

Conclusion

Pods are the fundamental units that ensure your Kubernetes workloads operate smoothly. They group your containers, manage their shared resources, and continuously monitor their health. Now that you understand what a Pod consists of, how it moves from creation to termination, and how to interpret its status, you have a clearer view of its function.