Kubernetes Internals (Part 3): How a Pod Actually Runs
One-line summary: A Pod is a shared sandbox of namespaces, storage, and lifecycle—this post traces its path from scheduling to termination.
Goal
- Explain what a Pod really is at runtime (sandbox + shared namespaces + volumes).
- Walk through the exact lifecycle from scheduling to steady state and shutdown.
- Show where kubelet, CRI, CNI, and probes fit into the flow.
Prerequisites
- Basic familiarity with
kubectland the idea of a Deployment or Pod. - Access to any Kubernetes cluster (local or managed).
Mental model: a Pod is a sandbox
A Pod is not just “one container.” It is a sandbox that groups containers so they share:
- Network namespace (one IP, one set of ports)
- IPC/PID/UTS namespaces (depending on configuration)
- Volumes (shared filesystem mounts)
Most runtimes implement the sandbox with a lightweight “pause” container that holds the namespaces alive even when app containers restart. This exists because Kubernetes wants multiple tightly‑coupled containers (sidecars) to behave like a single unit: one IP, one lifecycle, one scheduling decision.
