Kubernetes Pods: The Atomic Unit of Deployment

Why it exists

Containers are designed to run a single process, but applications often require multiple cooperating processes. Kubernetes needed a higher-level construct to group these processes, providing a shared execution environment without forcing developers to merge multiple concerns into a single container image. The Pod provides this co-location and shared context as the atomic unit of scheduling.

The mental model

Think of a Pod as a small, logical host machine dedicated to a single application instance. The containers inside are like processes running on that machine. They all share the same network interface (the same IP address and port space) and can share storage volumes mounted to the Pod. This makes them tightly coupled, but isolated from containers in other Pods.

How it works

Kubernetes manages Pods, not containers directly. When you define a Pod, you specify which container images to run. The scheduler assigns the Pod to a healthy Node. The kubelet on that Node then instructs the container runtime (like containerd) to pull the images and run the containers. All containers in a Pod are always co-located and co-scheduled on the same machine and share a lifecycle: when the Pod is created, its containers are started; when it's destroyed, all its containers are terminated.

When to use it

The primary use case is running a single containerized application; the "one container per Pod" model is the most common. Use multiple containers in a single Pod only when they are very tightly coupled. A classic example is the "sidecar" pattern: a main application container with a helper container for tasks like logging, monitoring, or acting as a network proxy. These helpers augment the main application without being part of its codebase.

When not to use it

Do not group unrelated applications into a single Pod, like your web server and database. Pods are scaled as a unit; if the web server needs 10 replicas and the database needs 2, they must be in separate Pods managed by separate controllers (like Deployments). Pods are also ephemeral and can be replaced at any time. Never rely on a Pod's IP address; use a Kubernetes Service for a stable endpoint.

One canonical example

A web server container serves traffic on port 80. A second "sidecar" container in the same Pod reads the web server's log files from a shared volume and forwards them to a central logging service. The two containers can communicate as if they were on the same host. The sidecar can scrape metrics from the web server by making a request to localhost:8080/metrics.