<aside> ☸️
Module 17 (Bonus) — Kubernetes, Explained as Plain Linux
Kubernetes looks huge and scary. It has a hundred new words and everyone talks about it like it's rocket science. Here's the secret this module gives you: almost every part of Kubernetes is a Linux idea you already learned — just done by robots, across many machines. A container is a process. A limit is a cgroup. A volume is a mount. Once you can translate the fancy Kubernetes word back into the plain Linux thing underneath, the whole system stops being magic and starts making sense. That's the entire goal here: give you the translation key.
Legend used throughout: 🧠 concept → 🧩 analogy → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (hidden)
</aside>
<aside> 🚦
Before you start
This is the victory lap of the whole track — it only makes sense because you did the earlier modules. You need Module 16 — How Containers Work most of all (a container is just a process with namespaces, cgroups, and a root filesystem — Kubernetes runs those), plus Module 2 — The Filesystem (mounts, for volumes), Module 13 — Networking (networking, for Services), Module 8 — Processes (processes), and Module 11 — systemd and Services (systemd keeping a service alive — the same idea as a Deployment). You do not need a Kubernetes cluster to follow along; the exercises run the Linux primitives that Kubernetes uses, right on one Ubuntu machine. The wording here is kept deliberately plain — this module is about understanding, not jargon.
</aside>
<aside> ℹ️
This page uses a Mermaid diagram block. Notion shows them as code by default — click the block and set it to Preview to see the diagram. This reminder appears once per page.
</aside>
<aside> 📖
Official docs: Kubernetes Overview
</aside>
🧠 Start with the one sentence that unlocks everything: a container is just a Linux process (you proved this in Module 16 — How Containers Work — a process with its own namespaces, a cgroup, and its own root filesystem). Kubernetes does not change that at all. Kubernetes is simply a robot that runs lots of those processes across lots of machines, and keeps them alive for you. That's the whole job. Everything else — Pods, Services, Deployments — is just organizing, naming, and automating that one thing.
🧠 The way the robot works is called a control loop, and it's as simple as a thermostat. You tell Kubernetes what you want ("I want 3 copies of my app running"). Kubernetes constantly checks what is actually true right now, compares it to what you asked for, and does whatever it takes to close the gap. One copy crashed? It starts a new one. You asked for 5 instead of 3? It starts 2 more. You never tell it the steps — you tell it the goal, and it works backwards. This "desired state vs actual state, fix the difference, forever" idea is the heart of Kubernetes.
<aside> 🧩
Real-world analogy — a thermostat
You don't tell a thermostat "turn on the heater for 12 minutes." You tell it the goal: "I want 21°C." It checks the room temperature, compares it to your goal, and turns the heater on or off to close the gap — over and over, all day, without you thinking about it. Kubernetes is a thermostat for running programs: you set the goal ("3 copies alive"), and it keeps nudging reality toward that goal forever.
Where the analogy stops working. A thermostat controls one simple number (temperature). Kubernetes juggles many goals at once — how many copies, how much memory each gets, which machine each lands on, how they find each other — all at the same time. And a thermostat only reacts; Kubernetes also plans ahead (it picks which machine has room before it starts a program). So it's a thermostat with a scheduler and a filing system bolted on — but the core "set a goal, keep reality matching it" instinct is exactly right, and it's the thing to hold onto.
</aside>
🧪 Exercise A1.1 — Remind yourself a container is just a process (read-only, safe anywhere)
ls /proc/self/ns/ # the namespaces your shell already has — a container is a process with DIFFERENT ones
nproc # how many CPUs this one machine has — a "node" is just a machine like this
<aside> 📖
Official docs: Nodes · kubelet
</aside>
🧠 A Node is one Linux computer — a virtual machine in the cloud, or a physical server. A Kubernetes cluster is just a bunch of these Linux machines working together. Nothing exotic: each node runs a normal Linux kernel, exactly like the ones you've been using all track.
🧠 On every node runs one small, important program called the kubelet. Its whole job is: "wait to be told which containers I should be running, then run them." When the kubelet is told to run a container, it hands the work to a container runtime (usually containerd), which does the exact Linux steps you learned in Module 16 — How Containers Work: make new namespaces, set up a cgroup with the resource limits, put the image's files as the root filesystem, and start the process. So "Kubernetes ran my container" really means "the kubelet on some machine asked containerd to unshare + set a cgroup + pivot_root + run a process." Same Linux, one program deep.
<aside> 🧠
The thing that surprises beginners: Kubernetes itself never actually "runs" your container — it just tells a Linux machine to. People imagine Kubernetes as one giant engine that holds all the containers. It isn't. Kubernetes is mostly a brain that makes decisions and keeps notes; the actual running of containers happens on ordinary Linux nodes, done by the kubelet and containerd using the plain kernel features from earlier modules. That split — a brain (the control plane, Part D) that decides, and hands (the kubelets on each node) that do the Linux work — is the whole architecture in one picture. If you can hold "brain decides, nodes do real Linux," you already understand Kubernetes better than most people who use it daily.
</aside>