What is a Pod, and why is it the smallest deployable unit rather than a container?
Quick Answer
A Pod is a group of one or more containers that share the same network namespace (one IP address, one port space) and can share storage volumes — it's the smallest unit Kubernetes schedules and manages, not the individual container. This exists because some containers genuinely need to be co-located and tightly coupled (e.g., a main application container plus a logging sidecar that reads its logs from a shared volume), and Kubernetes needed a unit that could represent "these containers must run together, on the same node, sharing network and storage" — a single container can't express that relationship on its own.
Detailed Answer
What a Pod actually is
apiVersion: v1
kind: Pod
metadata:
name: web-with-logger
spec:
containers:
- name: web
image: myapp:1.0
ports:
- containerPort: 8080
- name: log-shipper
image: fluentd:latest
volumeMounts:
- name: shared-logs
mountPath: /var/log/app
volumes:
- name: shared-logs
emptyDir: {}
Both containers in this Pod share: one network namespace (they can reach each other via localhost, and both see the Pod's single IP address from the outside), and, if explicitly configured, shared volumes (both can read/write the same shared-logs volume). Kubernetes schedules, starts, stops, and monitors the Pod as a unit — both containers always land on the same node together, and if the Pod is deleted, both containers go with it.
Why not just schedule individual containers directly
Some containers are only useful together, tightly coupled by design — the sidecar pattern (see that question) is the clearest example: a log-shipping or service-mesh proxy container that needs to share the main application container's network namespace and/or filesystem to do its job. If Kubernetes scheduled and placed containers entirely independently, there'd be no way to guarantee two specific containers always land on the same node, or to let them share localhost networking and volumes — you'd need an entirely separate mechanism just to express "these two things belong together." The Pod is that mechanism, built into the core scheduling unit from the start.
Most Pods have exactly one container
Despite the multi-container capability, the overwhelming majority of Pods in practice contain a single container — the multi-container case is specifically for the sidecar/init-container patterns where genuine tight coupling is needed, not a general-purpose way to bundle unrelated services together. Two unrelated services (e.g., a web frontend and a completely separate backend API) should almost always be separate Pods (typically each managed by its own Deployment), not stuffed into containers within the same Pod — that would incorrectly couple their scaling (you can't scale one container in a Pod independently of the others) and their lifecycle (a crash in one container can affect Pod-level restart behavior for the whole Pod).
Pods are ephemeral and not directly managed in production
You essentially never create bare Pods directly in production — they have no self-healing behavior on their own (a Pod that's deleted or whose node dies is simply gone, with nothing replacing it) and no rollout/rollback mechanism. Instead, you create a higher-level controller — a Deployment, StatefulSet, DaemonSet, or Job (see the following questions) — which manages a template for creating Pods and handles replacing, scaling, and updating them for you. Understanding that Pods are the unit of scheduling and execution, while Deployments/StatefulSets/etc. are the unit of desired state management, is the key distinction this topic is really testing.