Containers & Orchestration
A container is not a "lightweight VM" but an ordinary host process that the kernel has given an isolated view of the system. Grasping that difference separates the engineer who confidently fixes production from the one who repeats myths about "a separate kernel in every container". Here we cover what actually provides isolation, how an image differs from a container, how an image is built, and how containers talk over the network.
Then comes orchestration. One container starts with a command; a hundred containers surviving node failures and rollouts needs Kubernetes. We move from a single container up to the Pod, Deployment, and Service objects, naming the interview traps along the way: the reversed -p host:container order, the roles of ENTRYPOINT and CMD, and the stable IP living on the Service, not the Pod.
Topic map
- What a container is — isolation via namespaces, limits via cgroups, the shared host kernel, and how it differs from a virtual machine.
- Image versus container — an immutable layered template versus a running instance with a thin writable layer.
- Dockerfile — ENTRYPOINT and CMD — how an image is built and how
ENTRYPOINTfixes the program whileCMDsupplies overridable defaults. - Container networking — the default
bridgenetwork, name-based DNS, publishing a port with-p, andhostmode. - Kubernetes objects —
Pod,Deployment, andService, and how they split the duties of running, replicating, and networking.
Common traps
| Mistake | Consequence |
|---|---|
| Calling a container a virtual machine | Expecting its own kernel and full isolation where the kernel is shared and isolation is weaker |
| Thinking writes inside a container persist into the image | Data is lost when the container is removed; the image stays unchanged |
Confusing the roles of ENTRYPOINT and CMD | The container runs the wrong program or ignores docker run arguments |
Writing -p container:host instead of -p host:container | The wrong port is published and the service is unreachable |
Expecting name-based DNS on the default bridge network | The name does not resolve; connectivity works only on a user-defined network |
Thinking a Pod has a stable IP | Clients target an ephemeral address that changes when the pod is recreated |
Interview relevance
Containers are asked as a test of your mental model: do you understand what happens at the kernel level, or are you reciting marketing? A candidate who says "a container is a process with namespaces for isolation and cgroups for limits, sharing the host kernel" immediately gets ahead of one who calls a container a "fast VM".
Typical checks:
- The difference between an image and a container and where writes go on removal.
- The roles of
ENTRYPOINTandCMDand whatdocker runarguments override. - How containers communicate by default and how to publish a port.
- What a
Pod,Deployment, andServiceare, and why the stable address comes from theService.
Common wrong answer: "a container is more isolated than a virtual machine because it has its own kernel". In reality a container shares the host kernel, isolation is usually weaker than a VM's, and it has no "own kernel" — which is exactly the source of both its lightness and its security boundary.