Pods: The Smallest Deployable Unit

In one line

Kubernetes never schedules a container directly — it schedules a POD, a thin wrapper around one or more containers that always share the same network address and lifecycle.

0/4 · 0%

Think of it like this

A shipping container versus the pallet it's loaded onto — Kubernetes doesn't move individual containers around the cluster, it moves PODS, which are the actual unit of scheduling, exactly like a forklift moves a whole pallet, not individual boxes stacked on it.

Key ideas

01
A POD is the smallest deployable unit in Kubernetes — it wraps ONE OR MORE containers that are guaranteed to run on the SAME node, share the SAME network address (and therefore localhost), and share the SAME lifecycle (they start together, and if the pod is deleted, every container in it is deleted together).
02
The overwhelming majority of real pods contain exactly ONE container — the multi-container case exists specifically for tightly-coupled 'sidecar' patterns (a logging agent that reads a shared volume alongside your app, a proxy that handles TLS termination for your app) where two processes genuinely need to share a network namespace and lifecycle, not for running unrelated applications together.
03
Because containers in the same pod share a network namespace, they can reach each other over localhost at whatever port each one listens on — this is a fundamentally different, TIGHTER relationship than two separate pods communicating, which always happens over the cluster's real network (Phase 3), never localhost.
04
Pods are, by design, EPHEMERAL and DISPOSABLE — Kubernetes can and will destroy and recreate a pod at any time (a node failure, a rolling update, a scaling event), assigning it a brand new IP address and name each time. You almost never create a raw pod directly in real usage; instead, you describe a DESIRED set of pods via a Deployment (Phase 1), which handles creating, replacing, and healing the actual pods for you.
05
Every pod gets a LIVENESS PROBE and READINESS PROBE (optional but genuinely important to configure) — a liveness probe tells Kubernetes 'is this container still working, or should it be restarted,' while a readiness probe tells it 'is this container ready to receive real traffic yet.' A container can be alive (not needing a restart) while still not ready (still starting up, or temporarily overloaded) — these are deliberately separate, distinct signals.

In your stack

→
A Spring Boot application's Actuator library exposes /actuator/health/liveness and /actuator/health/readiness endpoints specifically designed to be wired directly into a pod's liveness and readiness probes — Spring Boot's own health-check model maps almost one-to-one onto Kubernetes' probe design, since both were built around the same underlying idea of distinguishing 'crashed' from 'not ready yet.'

Code & diagrams

PodSharedNetworkdiagram

Containers in the SAME pod share localhost; separate pods never do.

Rendering diagram…

first-pod.yamlmarkdown

The simplest possible pod definition — you'll almost never write one this directly in real usage (Phase 1 covers the real way).

# first-pod.yaml — a single-container pod, for learning the shape
apiVersion: v1
kind: Pod
metadata:
  name: hello-pod
spec:
  containers:
    - name: hello
      image: nginx:alpine
      ports:
        - containerPort: 80
      livenessProbe:
        httpGet:
          path: /
          port: 80
        initialDelaySeconds: 5
        periodSeconds: 10
      readinessProbe:
        httpGet:
          path: /
          port: 80
        periodSeconds: 5

pods.shmarkdown

Create, inspect, and understand a pod's ephemeral nature.

# Create the pod from the YAML above
kubectl apply -f first-pod.yaml

# See it running, and note its assigned IP
kubectl get pods -o wide

# Inspect its full details, including probe status
kubectl describe pod hello-pod

# Delete it — and notice NOTHING recreates it (a raw pod has no controller watching it)
kubectl delete pod hello-pod
kubectl get pods
# hello-pod is genuinely gone — this is exactly why Phase 1's Deployments exist

Explain it without notes

Why does Kubernetes schedule pods rather than scheduling individual containers directly?

A container in a pod is technically alive and running, but a liveness probe would still show it as failing. What's the difference between liveness and readiness, and why does this distinction matter?

Practice

Create the example pod from this topic's YAML, confirm it's running with kubectl get pods -o wide, and note its assigned IP address.

Delete that pod directly and confirm with kubectl get pods that nothing recreates it — this is the exact gap Phase 1's Deployments exist to close.

Trade-offs

↔
Multi-container pods are powerful for genuinely tightly-coupled sidecar patterns, but cramming unrelated applications into the same pod purely for convenience is a real anti-pattern — it forces them to scale together (you can't run 3 copies of one container and 5 of another within the same pod) and restarts both if either one needs to restart, which is almost never actually what you want for genuinely independent applications.

Done when you can

I understand a pod, not a container, is the smallest unit Kubernetes actually schedules.
I can explain when a multi-container pod genuinely makes sense versus when it doesn't.
I understand the difference between a liveness probe and a readiness probe.

Command Palette