Node, Pod, and Container relationship

WHAT THIS TESTS This checks whether you understand the layering of compute units and the rationale for the Pod abstraction.

A GOOD ANSWER COVERS A Node is a worker machine in the cluster, virtual or physical, running a kubelet and a container runtime. A Container is a running image instance. A Pod sits between them: it is the smallest deployable and schedulable object, wrapping one or more containers that are tightly coupled. Containers in a Pod share a network namespace, so they have one IP and can talk over localhost, and they can share storage volumes. Kubernetes schedules Pods onto Nodes, not bare containers, because the Pod gives a stable unit for networking, co-locating sidecars or init containers, sharing data, and managing a shared lifecycle. Running containers directly would lose this grouping, the shared IP, and the consistent unit that controllers and the scheduler operate on. Most Pods run a single container; multi-container Pods exist for helper patterns like a sidecar proxy.

COMMON WRONG ANSWERS Saying a Pod is just another word for a container. Claiming every Pod has many containers. Ignoring the shared network namespace and volumes. Thinking Nodes schedule individual containers.

LIKELY FOLLOW-UPS What is the pause container? When do you use multiple containers in a Pod? How do containers in a Pod communicate? What is an init container?

ONE CONCRETE EXAMPLE A web app Pod runs the app container plus a sidecar that ships logs. Both share the Pod's IP and a shared emptyDir volume where the app writes logs and the sidecar reads them. Kubernetes schedules this whole Pod onto a Node; the two containers always live and die together on the same machine, which would be awkward to coordinate if Kubernetes scheduled containers individually.