Kubernetes Pods: The Atomic Unit of Deployment

Why it exists

Kubernetes needs a higher-level abstraction than a single container. Real-world applications often require multiple, tightly-coupled processes to run together. A Pod provides a way to group these containers, manage them as a single unit, and guarantee they are co-located and can share resources easily.

The mental model

Think of a Pod as a small, logical server. It's not the container itself, but a wrapper that holds one or more containers. All containers within a single Pod share the same network namespace (one IP address, one set of ports), can communicate via localhost, and can share storage volumes. They are always scheduled to run on the same physical or virtual machine (Node).

How it works

You define a Pod's contents in a manifest file, specifying the container images to run. Kubernetes' scheduler finds a suitable Node with enough resources and assigns the Pod to it. The kubelet on that Node then pulls the specified container images and runs them. Kubernetes manages the Pod's lifecycle as a whole, not the individual containers directly. If a container crashes, the Pod's restart policy determines if it gets restarted.

When to use it

You always use Pods to run your containers in Kubernetes; it's the base unit. The specific pattern of using multi-container Pods is for tightly coupled helper processes. This includes sidecars (like service mesh proxies or log collectors that run alongside the main app), init containers (which run to completion before the main containers start, to set up the environment), and adapters that standardize an application's output.

When not to use it

Avoid putting multiple, independent applications into a single Pod. If two components have different scaling requirements or lifecycles, they should be in separate Pods, likely managed by separate Deployments. For example, your API backend and your database should never be in the same Pod. The footgun is that a Pod is a unit of scaling; all containers in it scale up or down together.

One canonical example

A common pattern is a web server container serving traffic, running alongside a log-shipping sidecar container in the same Pod. The web server writes its access logs to a shared volume. The sidecar container reads from that same volume and forwards the logs to a centralized logging service. They are managed as one unit but perform separate, cooperative tasks.