☸️Module 17 — Kubernetes, Explained as Plain Linux

cgroup  ipc  mnt  net  pid  pid_for_children  time  time_for_children  user  uts
2                                                (from nproc)

What to read out of it:

• There's nothing new to install to "see" what Kubernetes is built on — your shell already has namespaces, and this machine already has CPUs and memory. Kubernetes doesn't invent new building blocks; it arranges the ones you already have. (The pid_for_children and time_for_children lines that also appear aren't extra namespace types — they just point to the namespace a newly-forked child would get; there are eight real types: cgroup, ipc, mnt, net, pid, time, user, uts.)
• A container is a process given fresh namespaces (its own view). A node is a machine like this one. Kubernetes is the software that decides which processes run on which machines. Keep that three-word map — process, machine, decider — and every fancy term below hangs off it.
• The rest of this module is just: "what does Kubernetes call each Linux thing, and why?" You already know the Linux things. We're only learning the new names.

Kubernetes is a container orchestrator: software that runs and manages containers across many machines for you. You tell it the desired state ("run 3 copies of this app, give each 512 MB, keep them reachable"), and its control loops continuously make the real world match that — restarting crashed containers, replacing them on rolling updates, and scheduling them onto machines with room. Underneath, it runs ordinary Linux containers (processes isolated with namespaces and cgroups); Kubernetes adds the automation, scheduling, and networking to run them at scale.

The details that separate candidates: framing it as declarative (you specify the goal, not the steps) and control-loop-driven (desired vs actual, reconciled forever), and being clear that Kubernetes coordinates Linux container primitives rather than replacing them. Saying "it's a thermostat for containers" shows you actually get the model.

A Node is a single worker machine in a Kubernetes cluster — a VM or physical server running Linux. It runs the kubelet (the agent that starts/stops containers as instructed and reports health back), a container runtime (like containerd, which does the actual namespace/cgroup/rootfs work), and kube-proxy (which programs the node's network rules for Services). The cluster's control plane schedules Pods onto nodes; the nodes are where the containers actually run.

The details that separate candidates: naming the three things on a node (kubelet, runtime, kube-proxy) and what each does, and the key insight that a node is just a Linux box — the containers on it are normal processes you could see with ps and lsns from Module 16 — How Containers Work.

net:[4026531840]
net:[4026531840]

What to read out of it:

• That number in the brackets is the network namespace's identity. Two processes that show the same number are in the same network — same IP, can reach each other on localhost. That is precisely what "containers in one Pod" means at the Linux level.
• Two processes showing different numbers are isolated — separate IPs, must talk over the real network. That's two different Pods. So "are these in the same Pod?" is the same question as "do these processes share a net-namespace ID?" — a thing you can literally check with readlink.
• This is why the classic beginner rule "containers in a Pod talk on localhost, containers in different Pods talk over the network" is true by construction — it falls straight out of the shared-vs-separate network namespace, no Kubernetes magic required.

A container is a single running process, isolated with Linux namespaces and cgroups (Module 16 — How Containers Work). A Pod is Kubernetes' smallest deployable unit: one or more containers that share a network namespace (same IP, reach each other on localhost) and can share storage volumes. Kubernetes never schedules a bare container — it always wraps it in a Pod. Usually a Pod holds one container; multi-container Pods are for tightly-coupled helpers (a "sidecar" that ships logs or proxies traffic) that need to share the app's network and files.

The details that separate candidates: explaining the Pod in Linux terms — shared network namespace and volumes, held open by the hidden "pause" container — and knowing when to use a multi-container Pod (tightly coupled helpers) versus separate Pods (independent services). "A Pod is containers sharing some Linux namespaces" is the answer that lands.

A Kubernetes Namespace is a way to divide one cluster into separate logical groups — a labeled bucket that holds Pods, Services, and other objects so different teams, projects, or environments (dev/staging/prod) don't collide. Names must be unique within a Namespace but can repeat across them, and you can attach resource quotas and access rules per Namespace. It is an organizational tool for multi-team clusters, not a security sandbox at the kernel level.

The details that separate candidates: explicitly distinguishing it from a Linux namespace — "same word, different concept: the Kubernetes one organizes cluster objects; the Linux one isolates a process at the kernel." Interviewers love this question precisely because it catches people who blur the two. Bonus: mention that some cluster-wide objects (Nodes, PersistentVolumes) live outside any Namespace.

9:name=systemd:/
4:memory:/process_api/.../claude-code-bash
0::/

6265896960

What to read out of it:

• You don't need Kubernetes to be in a cgroup — every process already is. Reading the memory ceiling gives a real number of bytes. When Kubernetes runs your container with limits.memory: 512Mi, it writes 536870912 into that container's cgroup memory-limit file. Identical mechanism, Kubernetes just fills in the number from your YAML.
• So "my Pod got OOMKilled" translates to plain Linux as: "the process hit its cgroup memory limit and the kernel killed it" — the same event from Module 14 — Logs, Troubleshooting, and Performance, now triggered by a number you wrote in a Kubernetes file.
• requests behave differently: they're mainly a scheduler reservation (which machine has room), and for CPU a request also becomes the cgroup's relative-share setting (cpu.shares/cpu.weight) — but a request is never a hard cap. Only limits become an actual cgroup ceiling. That's why an under-requested but heavy Pod can crowd a node, and an under-limited one can get OOM-killed — two different knobs, two different jobs.

container now sees the volume at /tmp/poddemo/mnt:
config from a volume

(the last "ls" prints nothing — the mount existed only inside the namespace)

What to read out of it:

• Inside the mount namespace, mount --bind made the data appear at /tmp/poddemo/mnt, and the "container" read the file. That is exactly what Kubernetes does when it attaches a volume: it mounts storage into the container's filesystem at your chosen path. "Volume" is just the Kubernetes word for "a mount I set up for you."
• Back on the host, the same path is empty — the mount lived only inside the namespace. This is why a volume is visible inside the Pod but not scattered across the host: it's mounted into the Pod's own mount namespace, the same isolation from Module 2 — The Filesystem and Module 16 — How Containers Work.
• Swap the source of that bind mount and you get the different volume types: a temp dir → emptyDir; a node folder → hostPath; a mounted network disk → PersistentVolume; a folder of config files → ConfigMap. One Linux mechanism, several Kubernetes names.

A request is the minimum CPU/memory a container needs; the scheduler uses it to place the Pod on a node with enough capacity and reserves that amount. A limit is the maximum it may use; the node enforces it with a cgroup. If a container exceeds its memory limit, the kernel OOM-kills it (you'll see OOMKilled and a restart). Exceeding a CPU limit doesn't kill it — CPU is compressible, so the container is just throttled (slowed) via its cgroup CPU quota.

The details that separate candidates: knowing limits are enforced by cgroups (the same mechanism from Module 16 — How Containers Work/Module 14 — Logs, Troubleshooting, and Performance), and the crucial asymmetry: over-memory = killed, over-CPU = throttled. Bonus: requests affect scheduling, limits affect runtime — mixing them up is a common mistake.

A Volume is storage mounted into a Pod at a chosen path, so data can outlive the container (whose own filesystem is ephemeral) and/or be shared between containers in the Pod. Types include emptyDir (temporary, Pod-lifetime scratch), hostPath (a directory from the node), ConfigMap/Secret (config and secrets delivered as mounted files), and PersistentVolume/PersistentVolumeClaim (durable network/cloud storage that survives Pod rescheduling). Underneath, every volume is a Linux mount into the Pod's mount namespace.

The details that separate candidates: explaining why (the container filesystem is throwaway, from Module 16 — How Containers Work) and naming the right type for the job — emptyDir for scratch, PersistentVolume for a database — plus the insight that it's all just mounts. The classic red flag they probe for: storing database data with no PersistentVolume, so it vanishes on reschedule.

A ReplicaSet ensures a specified number of identical Pod copies are running at all times — if a Pod or its node fails, the ReplicaSet creates a replacement to get back to the desired count (self-healing via a control loop). A Deployment is a higher-level object that manages ReplicaSets for you and adds rolling updates and rollbacks: to ship a new version it gradually replaces old Pods with new ones while keeping the app available, and can revert if something breaks. In practice you create Deployments, and they create/manage the ReplicaSets underneath.

The details that separate candidates: the layering (Deployment → ReplicaSet → Pods), that a Deployment's value-add is safe rollouts/rollbacks, and framing both as control loops (declare the goal; the controller reconciles). Comparing it to systemd keeping a service alive (Module 11 — systemd and Services), but for a group across machines, shows the Linux connection.

Because Pod IPs are not stable — Pods are created and destroyed constantly, each getting a new IP — so you can't rely on a Pod's address. A Service provides a stable virtual IP and DNS name that always routes to the currently healthy Pods behind it, and load-balances across them. Types: ClusterIP (reachable only inside the cluster, the default), NodePort (opens a port on every node), and LoadBalancer (provisions an external cloud load balancer). Under the hood it's kube-proxy programming iptables/IPVS plus cluster DNS.

The details that separate candidates: leading with the real problem (ephemeral Pod IPs), naming the three Service types and when to use each, and knowing the implementation is ordinary Linux networking rules + DNS (Module 13 — Networking) — not a mysterious black box. Bonus: a Service selects its Pods by labels.

Two halves. The control plane (the brain) runs the API server (the entry point for all commands), etcd (a key-value store holding the desired state), the scheduler (assigns new Pods to nodes based on resources), and controllers (control loops that keep actual state matching desired). The worker nodes (the hands) each run the kubelet (starts/stops containers as told, reports health), a container runtime like containerd (does the actual namespace/cgroup/rootfs work), and kube-proxy (network rules for Services). You send desired state to the API server; controllers + scheduler decide; kubelets make it real with plain Linux primitives.

The details that separate candidates: cleanly separating control plane (decides) vs nodes (do the Linux work), naming each component's one job, and connecting the bottom layer back to this whole module — a running Pod is just a process the kubelet started with namespaces, cgroups, and mounts. That closes the loop between "Kubernetes architecture" and "plain Linux."

In plain Linux: the process hit its cgroup memory limit and the kernel killed it. Your Pod has a limits.memory value; Kubernetes turned that into a cgroup memory cap on the container (Part C). The app tried to use more than the cap, so the kernel's OOM killer fired inside that cgroup and killed the process — exactly the event from Module 14 — Logs, Troubleshooting, and Performance and Module 16 — How Containers Work. Then the Deployment's control loop saw "a copy died, I wanted N" and started a fresh one — hence the restart-every-few-minutes cycle.

What to do: decide why it exceeds the limit. If the app genuinely needs more memory, raise limits.memory. If it grows without bound, it's a memory leak — fix it, because raising the limit just delays the next kill. Check actual usage against the limit (kubectl top pod), and make sure the limit has a little headroom. This is the #1 "my Pod keeps restarting" cause, and naming it as a plain cgroup OOM is the answer.

Because containers in one Pod share a single Linux network namespace (Part B, Module 16 — How Containers Work). A network namespace is its own private network stack — one IP, one set of ports, one localhost. When Kubernetes builds a Pod, it puts all the Pod's containers into the same network namespace (held open by the hidden "pause" container). So to the kernel they really are on the same machine's network — container A reaching container B on localhost:8080 is just two processes on one network talking to each other, which needs no routing at all.

The flip side: containers in different Pods are in different network namespaces, so they have different IPs and must talk over the real network (usually via a Service). Strong answer: "same Pod = same net namespace = same localhost; different Pods = different net namespaces = talk over the network." It's the shared-namespace idea, nothing more.

The app was writing to the container's throwaway filesystem, which is discarded when the container is replaced (Module 16 — How Containers Work). A Pod restart makes a fresh container with a fresh empty filesystem, so anything on it is lost. The fix is a Volume (Part C): storage mounted into the Pod that lives outside the container's lifecycle. For data that must survive restarts and rescheduling to another machine, use a PersistentVolume (durable network/cloud storage) via a PersistentVolumeClaim, mounted at the app's data path.

In plain Linux: a volume is a mount you set up so the important files live on separate storage, not on the disposable container layer. emptyDir survives a container restart within the same Pod but not the Pod's deletion; a PersistentVolume survives both. Strong answer names the throwaway container filesystem as the cause and the right volume type as the fix — and notes databases should basically always use a PersistentVolume.

"It's simpler than it looks — it's mostly Linux you already know, run by a robot across many machines." A container is just a process with its own view (namespaces), its own limits (a cgroup), and its own files (an image). A Node is just a Linux machine. Kubernetes is a thermostat: you tell it the goal ("run 3 copies, 512 MB each"), and it keeps reality matching that goal — restarting anything that dies. A Pod is a couple of containers sharing a network namespace (same IP, they talk on localhost). A limit is a cgroup. A volume is a mount. A Deployment is a supervisor keeping N copies alive, like systemd for a group. A Service is a stable name and load balancer built from iptables rules and DNS. The control plane is the brain that decides; the kubelet on each machine does the actual Linux work.

Why this is the answer: it replaces a scary pile of jargon with a short list of familiar Linux ideas plus one automation loop. Anyone who understood the earlier modules can follow it. That translation — jargon back to Linux primitive — is the single most valuable thing to carry into a Kubernetes interview or your first real cluster.