What is a Pod and why is it the smallest deployable unit in Kubernetes?

Question

IT Interview Practice · Accepted Answer

A **Pod** is the smallest deployable unit in Kubernetes: a wrapper around **one or more containers** that share the same network namespace (one IP) and can share storage volumes. You don't deploy containers directly — you deploy Pods.

## What is inside a Pod

```text
┌───────────────── Pod (has ONE shared IP) ─────────────────┐
│                                                            │
│   ┌──────────────┐   ┌──────────────┐   shared:           │
│   │  container A  │   │  container B  │    • network (IP)   │
│   │  (app)        │   │  (sidecar)    │    • localhost      │
│   └──────────────┘   └──────────────┘    • volumes         │
│         │ talk to each other via localhost:port            │
└────────────────────────────────────────────────────────────┘
```

Containers in the same Pod are **always co-located** on the same node, scheduled together, and can reach each other over `localhost`.

## A minimal Pod

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: web
  labels: { app: web }
spec:
  containers:
    - name: web
      image: nginx:1.27
      ports:
        - containerPort: 80
```

## Why a Pod, not just a container?

```text
The Pod is an abstraction that lets a "logical application" be more than one
container that MUST run together and share resources:
  → a main app container + a helper "sidecar" (log shipper, proxy, etc.)
  → they share the same IP and can use shared volumes for exchanging files
Most Pods hold a SINGLE container. Multi-container Pods are for tight coupling only.
```

## Pods are ephemeral — don't manage them directly

```text
A Pod is DISPOSABLE:
  → it gets a new IP each time it is (re)created
  → if the node dies, the Pod is GONE (not rescheduled by itself)
→ You almost never create bare Pods in production.
→ Instead a controller (Deployment / StatefulSet / Job) creates and REPLACES
  Pods for you, keeping the desired count alive.
```

```bash
kubectl get pods -o wide          # see Pods, their node and IP
kubectl describe pod web          # events, status, restarts
kubectl logs web -c web           # logs of a specific container
kubectl exec -it web -- sh        # shell into the container
```

## Why it matters

The Pod is the fundamental building block of Kubernetes, so understanding what it is and why it exists is essential, must-know knowledge. Kubernetes does not schedule bare containers; it schedules **Pods** — a thin wrapper around one or more containers that share a network namespace (a single IP, reachable among themselves over `localhost`) and can share storage volumes. Understanding that containers in a Pod are **always co-located and co-scheduled** on one node explains what a Pod is *for*: grouping containers that must run together and share resources, such as a main application plus a tightly-coupled **sidecar** (a log shipper, proxy, or adapter) — while recognizing that most Pods in practice hold just a single container. Equally important is grasping that Pods are **ephemeral and disposable**: they get a new IP on each recreation and are not resurrected on their own if a node dies, which is exactly why you rarely create bare Pods and instead rely on higher-level controllers (**Deployments**, **StatefulSets**, **Jobs**) that create and replace Pods to maintain a desired state. This distinction — the Pod as the atomic unit, managed by controllers rather than by hand — is the conceptual bridge from single containers to real Kubernetes workloads, and everyday knowledge for anyone deploying, debugging (via `kubectl logs`, `describe`, `exec`), or reasoning about applications on a cluster.

What is inside a Pod

A minimal Pod

Why a Pod, not just a container?

Pods are ephemeral — don't manage them directly

Why it matters

Related questions