7 min read<\/p>\n
You press the power button and seconds later your cursor moves. What happens in between is the most underrated software in the world\u2014and the foundation every pod, container, and cloud VM relies on.<\/strong><\/p>\n Related:<\/span>Kubernetes 1.31 Sidecar Containers \/<\/span> Container Runtime Comparison<\/p>\n An operating system isn\u2019t a single program; it\u2019s a choreographed sequence of ten stages. Anyone debugging containers or planning Kubernetes clusters works with the outcome every day\u2014usually without knowing what\u2019s happening in the engine room.<\/p>\n You press the power button. Power flows to the motherboard, the CPU wakes up, and executes the very first instruction at a hard-wired address. At this moment there\u2019s no memory management, no files\u2014just a single core running firmware. On modern machines it\u2019s called UEFI; back then it was BIOS.<\/p>\n The firmware wakes just enough hardware to find a disk, then hands off to the bootloader: GRUB on Linux, iBoot on Mac, Boot Manager on Windows. The bootloader\u2019s sole job is to load the kernel into RAM. Once that\u2019s done, the CPU runs in Ring 0<\/strong>, the mode with full hardware control.<\/p>\n Ring 0 vs. Ring 3 is the most important dividing line on your computer. x86 CPUs have four rings, but in practice only two matter: Ring 0 for the kernel, Ring 3 for everything else. A bug in Ring 0 code can take down the entire machine\u2014the famous CrowdStrike outage in summer 2024 was exactly that: a faulty driver in Ring 0 that blue-screened Windows machines worldwide.<\/p>\n\n When a program requests a memory address, that address is almost always a lie. It\u2019s a virtual address that a hardware component called the MMU (Memory Management Unit) translates into a real physical address. The translation happens via a data structure called the Page Table, which the kernel maintains for each process. Memory is delivered in 4-kilobyte pages, and every process gets its own virtual address space.<\/p>\n The MMU caches frequent translations in a tiny buffer called the TLB. When a process accesses a page that isn\u2019t in RAM, the MMU triggers a page fault, the kernel loads the page from disk, and the process continues as if nothing happened. This very mechanism underpins container memory limits: when a pod exceeds its cgroup limit, the OOM killer steps in and shoots the process\u2014no swap, no warning.<\/p>\n Once the kernel understands memory and the file system, it loads drivers. Drivers translate generic kernel requests into chip-specific commands for GPUs, Wi\u2011Fi cards, keyboards. They run in Ring 0, which is convenient for performance but perilous for stability. The CrowdStrike incident serves as a stark reminder of why driver reviews must be taken seriously.<\/p>\n With the drivers in place, the kernel activates interrupts<\/strong>. How does an operating system know you just pressed a key? It doesn\u2019t poll in an endless loop. Instead, the keyboard fires an electrical signal that yanks the CPU from its current task and jumps into an interrupt handler inside the kernel. Every mouse movement, every Wi\u2011Fi packet, every disk response is an interrupt.<\/p>\n Only now does the kernel spawn the first user-space process: PID 1, on modern Linux usually systemd<\/strong>. PID 1 is the progenitor of all other processes\u2014if PID 1 dies, the kernel panics and the machine goes down. From this moment on, everything runs in Ring 3 and must ask the kernel for permission via system calls<\/strong> whenever it wants to touch the file system, the network, or hardware.<\/p>\n A modern cloud VM may have eight or sixteen vCPUs, but it\u2019s juggling hundreds of processes. That\u2019s where the scheduler<\/strong> comes in. It decides every few milliseconds which process runs on which core. The current Linux scheduler is called EEVDF (Earliest Eligible Virtual Deadline First) and guarantees every process its fair CPU share.<\/p>\n When you type kubectl get pods<\/strong> in Kubernetes, the same mechanism is running one level higher: the Kubernetes scheduler distributes pods across nodes, much like the Linux scheduler distributes processes across cores. Resource requests and limits in K8s are the siblings of nice<\/strong> values and cgroup quotas at the OS level.<\/p>\n Inside a single process there\u2019s often more than one path\u2014via threads<\/strong>. Threads share memory but keep their own stacks. That\u2019s powerful, yet perilous: if two threads write to the same variable at once, race conditions appear. Modern languages try to prevent this\u2014Go with goroutines and channels, Rust with the borrow checker that rejects non-thread-safe code at compile time.<\/p>\n When two entirely separate processes need to talk, IPC<\/strong>\u2014inter-process communication\u2014steps in. The simplest form is the pipe, invented in 1973 by Doug McIlroy at Bell Labs and still unbeaten: cat log.txt | grep ERROR<\/strong> is exactly that. Beyond pipes there are sockets and message queues\u2014the entire microservice architecture is conceptually IPC, just stretched across the network.<\/p>\n A container isn\u2019t its own operating system. It\u2019s a userspace process on a host kernel, isolated through namespaces and capped in resources via cgroups. That\u2019s why containers boot in milliseconds instead of seconds like a VM\u2014the real OS is already running. Once you grasp this, you debug OOMKilled pods, latency-critical workloads, and sidecar architectures with an entirely different perspective.<\/p>\n The Fireship video \u201cEvery operating system concept in one video\u201d<\/a> delivers ten stages in eleven minutes\u2014a visual crash course and a great companion. For deeper study, dive into the Linux Kernel Documentation<\/a> and the classic \u201cOperating Systems: Three Easy Pieces\u201d by Remzi Arpaci-Dusseau, freely available online. If you want to dig into the security implications of Ring-0 drivers, the SecurityToday sister portal<\/a> analyzes how AI agents find Linux kernel zero-days.<\/p>\n Certainly by the time you see your first OOMKilled pod, your first CPU throttling issue, or your first sidecar logging bug. Kubernetes doesn\u2019t remove the operating system\u2014it sits on top of it. You can only set Resource Limits, Liveness Probes, and Network Policies effectively if you understand how cgroups, namespaces, and the Linux scheduler work underneath.<\/p> <\/details> Containers do have an operating system\u2014they just share the host\u2019s kernel. What lives inside the container image is userspace: libraries, binaries, configuration. A VM brings its own complete kernel plus hypervisor overhead. That\u2019s why containers boot in milliseconds while VMs take seconds.<\/p> <\/details> Because cgroups enforce hard memory limits. Once a container exceeds its limit, the OOM killer fires a SIGKILL\u2014no warning, no swap attempt. That\u2019s intentional: predictable performance across the cluster trumps best-effort survival of individual pods. To bypass this, raise limits or run memory profiling.<\/p> <\/details> Kernel space runs in Ring 0 with full hardware control\u2014drivers, the scheduler, the filesystem module all live here. User space runs in Ring 3 without direct hardware access. Every web server, every database, every container lives in user space. To touch hardware or files, it must go through system calls\u2014the only bridge between the two worlds.<\/p> <\/details> The reverse of startup: PID 1 sends every process a SIGTERM (a polite request to exit). Processes that don\u2019t respond get a SIGKILL after a timeout. Then filesystems flush their journals, drivers release hardware, the kernel syncs memory to disk, disables interrupts, and firmware cuts the power\u2014all in under two seconds on a normal machine.<\/p> <\/details>\n Image source: AI-generated (May 2026), C2PA certificate embedded in image<\/em><\/p>","protected":false},"excerpt":{"rendered":"You press the power button, and seconds later your cursor moves. What happens in between is the most underrated software in the world\u2014and exactly what\u2026","protected":false},"author":31,"featured_media":40983,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_yoast_wpseo_meta-robots-noindex":"","_yoast_wpseo_meta-robots-nofollow":"","_yoast_wpseo_meta-robots-adv":"","_yoast_wpseo_canonical":"","_yoast_wpseo_opengraph-title":"","_yoast_wpseo_opengraph-description":"","_yoast_wpseo_opengraph-image":"","_yoast_wpseo_opengraph-image-id":0,"_yoast_wpseo_twitter-title":"","_yoast_wpseo_twitter-description":"","_yoast_wpseo_twitter-image":"","_yoast_wpseo_twitter-image-id":0,"pre_headline":"","bildquelle":"","teasertext":"","language":"de","_evm_slot_owner":"","_evm_translation_lang":"","featured_post":0,"featured_post_sortierung":0,"_wp_old_slug":[],"footnotes":""},"categories":[931],"tags":[],"industry":[],"class_list":["post-40347","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-data-centers"],"evm_reading_time_minutes":8,"wpml_language":"en","wpml_translation_of":40253,"acf":[],"yoast_head":"\nKey Takeaways<\/h2>\n
\n
Power On: Bootloaders and Privilege Rings<\/h2>\n
The Biggest Lie in Computing: Virtual Memory<\/h2>\n
\nThis separation is precisely why your browser can\u2019t rummage through the memory of your password manager. Both live in parallel universes that only the kernel can oversee.\n<\/blockquote>\n
Drivers, Interrupts, and the First Process<\/h2>\n
Eight-core multitasking for hundreds of processes<\/h2>\n
What cloud engineers should take away<\/h2>\n
Frequently Asked Questions<\/h2>
Do I need OS knowledge if I only use Kubernetes?<\/strong><\/summary>
Are containers lighter than VMs because they don\u2019t have an operating system?<\/strong><\/summary>
Why does Linux kill my container instead of using swap?<\/strong><\/summary>
What\u2019s the difference between kernel space and user space?<\/strong><\/summary>
What actually happens during shutdown?<\/strong><\/summary>