How Modern Software Really Runs on a CPU

Before anything else here makes sense: the CPU doesn't run Python. It runs this.

A CPU executes exactly one language: machine code, opcodes read one at a time in a fetch-decode-execute loop. Every abstraction in every language you write eventually reduces to this tiny vocabulary — demonstrated here with a real compiled function and its disassembly across six languages.

How the code you actually wrote turns into the instructions from step one.

"Python is interpreted, Go is compiled" is why Go starts instantly and Python spins up a virtual machine first. Covers what a compiler and an interpreter actually do to your source before a single instruction from step one ever runs.

Every process believes it owns all the RAM. Here's the lie, and who's telling it.

Every process believes it owns all the RAM on the machine, starting at zero — a fiction the OS maintains via the MMU and page tables, translating each process's private addresses to real physical RAM. That translation is the actual mechanism behind process isolation, and the reason a stack overflow has a hard, fixed ceiling.

Kernel mode, user mode, and the syscall that separates them.

CPU privilege rings, not politeness, are what stop your code from touching hardware directly — user-space code reaches the kernel only through the single, audited door of a system call. A real strace walkthrough shows what that boundary costs, and why buffering writes instead of calling one at a time is measurable advice, not folklore.

The unit the OS actually schedules — and what it costs to switch between them.

A process is fully isolated and expensive to create; a thread shares its process's memory and is cheap — that one difference is the entire trade between them. Context switching is what makes many of them look simultaneous on too few cores, and it isn't free either.

Thousands of processes, one CPU. The algorithm that decides who runs next.

Linux's CFS scheduler always runs whichever runnable thread has received the least CPU time so far — a real, checkable value called vruntime, not a vague priority suggestion. This is the exact shape of problem Kubernetes solves again a few steps later, across a fleet of machines instead of one core.

The theory made concrete: ps, kill, and the process tree on a real machine.

ps, kill, signals, and process states made concrete on a real machine — the operating-system theory from the last several steps, now something you can run yourself and read the output of.

How one kernel convinces a process it's alone on the machine.

Namespaces control what a process can see; cgroups control how much it can use — the same two kernel mechanisms, stacked together, are what make a container a container, long before Docker or Kubernetes existed.

What happens when the memory a process was promised runs out.

When RAM and swap are both exhausted, the kernel's OOM killer picks a victim by oom_score and terminates it on purpose — not a crash, a deliberate decision, and the exact mechanism behind a Kubernetes Pod going OOMKilled a few steps later.

Namespaces and cgroups, wearing a name and a registry tag.

A container isn't a lightweight VM — it's a normal process on the same kernel as everything else, wearing the namespace and cgroup isolation from the last two steps as a disguise the kernel agrees to maintain.

Who's actually deciding anything, across a fleet of these machines.

A working mental model of a cluster: the control plane that decides, the nodes that run your Pods, and the reconcile loop tying them together — just enough machinery to make the rest of this pathway's Kubernetes steps precise.

The exact handoff from kubelet to the container runtime underneath.

kubelet never talks to containerd or CRI-O directly — it goes through the Container Runtime Interface, a deliberate abstraction that is why "Docker support removed" never actually broke anything. The full chain from kubectl apply to a running Linux process, named end to end.

The same problem as step 6, at cluster scale: which machine runs this next?

Every unscheduled Pod goes through filtering (which Nodes even qualify) then scoring (which qualifying Node is best) — the same shape of problem as the OS scheduler a few steps back, solved across a fleet instead of one CPU. Taints, tolerations, and node affinity are how you shape that decision on purpose.

Close the loop: this YAML field is a cgroup CPU quota.

The payoff for the whole pathway: resources.limits.cpu and resources.limits.memory are a cgroup CPU quota and memory ceiling in a YAML costume, the exact Linux mechanisms from earlier steps. Includes the specific reason a Pod gets CPU-throttled while its usage graph looks perfectly calm.

When placement or limits go wrong, this is what it looks like from the outside.

CrashLoopBackOff, Pending, ImagePullBackOff, and OOMKilled each point to a different failure — different subsystems, different fixes — and kubectl describe pod's Events section almost always names the exact cause directly, once you know where to look.

How any of this got scheduled onto a CPU in the first place.

How a Pod's spec — including every resource limit from the last few steps — actually reaches the cluster: a CI pipeline builds a versioned OCI artifact, Flux reconciles it, and 'did it deploy' has a real, checkable answer instead of a guess.