What is a Pod, and why doesn't Kubernetes just schedule containers directly?
Quick Answer
A Pod is the smallest deployable unit — one or more containers that share a network namespace (same IP and localhost) and storage volumes, always co-scheduled on one node. K8s schedules Pods, not containers, so tightly-coupled helpers can share context.
Detailed Answer
A Pod wraps one or more containers that must live together: they share the same network namespace (one pod IP, they reach each other on localhost), can share volumes, and are always placed on the same node and scheduled/terminated as a unit. Most pods have a single application container, but the pod abstraction exists so you can attach tightly-coupled helpers — a sidecar that ships logs, an init container that runs setup before the app starts, or an ambassador proxy — without merging them into one image. Kubernetes schedules Pods rather than bare containers because scheduling, networking, and lifecycle are naturally per-group: the helpers need the app's IP and filesystem, and it makes no sense to place them on different nodes. Pods themselves are ephemeral and usually managed by a higher controller (Deployment, StatefulSet) rather than created directly.
Code Example
# Two containers sharing one network namespace + a volume
apiVersion: v1
kind: Pod
metadata: { name: web-with-logger }
spec:
volumes: [{ name: logs, emptyDir: {} }]
containers:
- { name: app, image: myapp, volumeMounts: [{ name: logs, mountPath: /var/log }] }
- { name: log-shipper, image: fluent-bit, volumeMounts: [{ name: logs, mountPath: /var/log }] }Interview Tip
Nail the shared context: 'containers in a pod share the network namespace (localhost) and volumes, and are always co-scheduled.' Then mention you rarely create bare pods — controllers manage them.