Containers & Kubernetes
Compiling a static binary is only half the story. In production that binary does not run directly: it is packed into a container, the container runs as a pod, the pod is scheduled by Kubernetes onto a node, and the node's resources are sliced among dozens of such pods by cgroups. Each layer changes what your process sees and feels — and each layer brings its own set of traps.
The core misconception this topic dismantles: "a container is a lightweight virtual machine." It is not. A container is an ordinary process on the host kernel, given an isolated view through namespaces and bounded resources through cgroups. Everything else follows from that: why a container starts in milliseconds, why ps inside a pod sees only its own processes, why a process can be OOM-killed while the host still has gigabytes free, and why a container's main process is PID 1 with all the special duties that come with it. This topic walks the operations layer top to bottom — from the container to the pod process model.
Topic map
- Containers — why a container is a process on the host kernel, not a virtual machine with a guest OS.
- Linux namespaces — how the kernel gives a process group an isolated view of PIDs, network, filesystem, and hostname.
- Cgroups — how control groups limit and account for a process group's CPU, memory, and I/O, and where the OOM killer fits.
- Kubernetes basics — the container orchestrator, the pod as the smallest unit, Deployment, ReplicaSet, and Service.
- The Kubernetes process model — why a container's main process is PID 1 and what duties that places on it.
Common mistakes and traps
| Mistake | Consequence |
|---|---|
| Believing a container runs its own kernel | Wrong cost model — cannot explain why a container is lighter than a VM |
| Thinking a container is only a packaging format with no isolation | Misses the role of namespaces and cgroups that actually make a container |
| Confusing namespaces with cgroups | namespaces isolate visibility, cgroups limit resources — different mechanisms |
| Thinking one namespace covers all resources at once | Each namespace isolates one class of kernel resource |
| Believing a memory limit breach is merely logged | The kernel runs the OOM killer inside the cgroup and terminates a process |
| Thinking a pod is always exactly one container | A pod can hold several containers sharing a network namespace |
| Confusing a Deployment with a pod | A Deployment manages a ReplicaSet and rolling updates |
| Treating a container's main process as an ordinary PID | It is PID 1 and must reap zombies and handle SIGTERM |
Interview relevance
DevOps questions in a Go interview test not your knowledge of kubectl commands but your understanding of which infrastructure layer your process lives on and what follows from it. The interviewer wants a working mental model: container → namespaces + cgroups → pod → Kubernetes.
What interviewers check:
- How a container differs from a virtual machine — a shared host kernel versus a full guest OS.
- What Linux namespaces isolate and what cgroups limit — two distinct mechanisms.
- What happens when a cgroup memory limit is breached — the OOM killer inside the group.
- What a pod, Deployment, ReplicaSet, and Service are in Kubernetes.
- Why a container's main process is PID 1 and what duties that places on it.
A typical wrong answer: "a container is a virtual machine, just lighter." That opens a discussion of how a container has no kernel and no hypervisor of its own — it is an ordinary process given an isolated view through namespaces and bounded resources through cgroups by the host kernel.