Pods Explained: The Smallest Deployable Unit in Kubernetes

If you’re new to Kubernetes, the first surprise is usually this: you never actually run a container. You run a Pod.

A Pod is the smallest deployable unit in Kubernetes. It wraps one or more containers that share the same network namespace, the same IP address, and can share storage volumes. Most of the time a Pod holds exactly one container — but the “one or more” part is what makes Kubernetes powerful.

Why not just schedule containers directly?

Kubernetes needed a unit of scheduling that could express “these things must live together, on the same node, sharing the same network.” A single container isn’t enough to express that. A Pod is.

Think of a Pod as a logical host for a group of tightly-coupled containers — like a lightweight VM that only exists to run those containers together.

The sidecar pattern

The most common reason to run more than one container in a Pod is the sidecar pattern. A sidecar is a helper container that supports the main application container — a log shipper, a proxy, a certificate rotator.

apiVersion: v1
kind: Pod
metadata:
  name: web-with-sidecar
spec:
  containers:
    - name: app
      image: my-app:latest
      ports:
        - containerPort: 8080
    - name: log-shipper
      image: fluent-bit:latest

Both containers share localhost — the sidecar can reach the app on 127.0.0.1:8080 with zero extra networking config.

Pods are disposable

Here’s the part that trips people up: Pods are not durable. When a Pod dies, Kubernetes does not resurrect that exact Pod — it creates a brand new one, with a new IP address and a new identity.

This is why you almost never create bare Pods in production. Instead, you use a controller — a Deployment, StatefulSet, or DaemonSet — that manages Pod lifecycle for you and guarantees the desired number of replicas keeps running.

The secret ingredient

The mental model that makes Kubernetes click: Pods are cattle, not pets. Design your application to expect any Pod to disappear at any time, and let the control plane worry about keeping the herd at the right size.

Next up: we’ll look at how Deployments and ReplicaSets actually keep that herd alive.