Not Just a Container
The most common misconception about Kubernetes is that it manages containers directly. It does not. The smallest, most basic deployable object in Kubernetes is a Pod.
Think of a Pod as a logical host for one or more containers. Just as processes on a physical machine share the same network interface and filesystem, containers inside a Pod share the same network namespace and can share storage volumes.
- Single-container Pod: This is the most common case — a Pod wrapping exactly one container (like your Node.js API server). The terms "Pod" and "container" are often used interchangeably in casual conversation, but they are distinct concepts.
- Multi-container Pod: Sometimes two containers are so tightly coupled that separating them would be artificial. A classic example is the sidecar pattern: a web server container paired with a log-shipping container that reads the web server's log files and forwards them to a centralized logging system. Both containers need to share the same log directory, so they live in the same Pod.
Key characteristics of a Pod:
- All containers in a Pod share the same network IP address and port space. Container A can reach Container B via localhost:8080.
- All containers in a Pod can mount the same storage volumes, enabling file sharing between them.
- Pods are ephemeral — they are not designed to be long-lived. When a Pod dies, it is replaced by a new one with a new identity and IP address.
A minimal Pod definition names the container image to run and the port it listens on, plus labels used to identify it. Applying that definition to a cluster is enough for Kubernetes to schedule it onto a node, pull the image, and start the container.
Interviewers frequently ask: "What is the difference between a Pod and a container?" The answer: a Pod is a Kubernetes abstraction that wraps one or more containers and provides them with a shared network namespace and optional shared storage. Kubernetes schedules Pods, not containers. A follow-up question is often: "Why does Kubernetes use Pods instead of managing containers directly?" — the answer is that the Pod abstraction allows Kubernetes to remain container-runtime agnostic (it works with containerd, CRI-O, etc.) and enables the sidecar pattern without requiring the orchestrator to understand inter-container relationships.