7 Min. Tiempo de lectura

Presionas el Power-Button y segundos después se mueve tu cursor. Lo que ocurre entre medio es el software más subestimado del mundo, y precisamente sobre eso se basa cada pod, cada contenedor y cada Cloud-VM.

Lo más importante en resumen

• Del Power-Button al kernel hay cuatro etapas: Firmware (UEFI) inicia el bootloader, que carga el kernel en la RAM, el kernel pone la CPU en modo protegido y construye su propio mundo. Hasta aquí no existen ni archivos ni procesos.
• La memoria virtual es la mayor mentira en la informática: Cada programa ve su propio espacio de direcciones, la MMU traduce en segundo plano a RAM real. Precisamente esta mentira hace posible el aislamiento de contenedores y los límites de memoria en cgroups.
• Scheduler, syscalls e IPC son los fundamentos de la nube que nadie explica: El scheduler de Linux distribuye procesos en núcleos de CPU, el scheduler de Kubernetes distribuye pods en nodos, el mismo mecanismo un nivel más arriba.

Relacionado:Kubernetes 1.31 Sidecar Containers  /  Container-Runtime im Vergleich

Energía encendida: bootloader y anillos de privilegio

Un sistema operativo no es un programa único, sino una secuencia coreografiada de diez etapas. Quien depura contenedores o planifica clústeres de Kubernetes trabaja cada día con el resultado, normalmente sin saber qué ocurre en la sala de máquinas.

Presionas el Power-Button. La energía llega a la placa base, la CPU se despierta y ejecuta la primera instrucción en una dirección fija. En este punto no hay gestión de memoria ni archivos, solo un único núcleo que ejecuta un firmware. En los equipos modernos se llama UEFI, antes era BIOS.

El firmware despierta justo la cantidad de hardware necesaria para encontrar un disco duro y luego lo entrega al bootloader: Grub en Linux, iBoot en Mac, Boot Manager en Windows. El bootloader tiene una única tarea: cargar el kernel en la RAM. En cuanto ocurre, la CPU funciona en Ring 0, el modo con control total del hardware.

Ring 0 frente a Ring 3 es la línea divisoria más importante de tu ordenador. Las CPUs x86 tienen cuatro anillos, pero en la práctica solo cuentan dos: Ring 0 para el kernel, Ring 3 para todo lo demás. Un error en código de Ring 0 paraliza toda la máquina: la famosa caída de Crowdstrike en el verano de 2024 fue precisamente eso, un controlador defectuoso en Ring 0 que provocó pantallas azules en máquinas Windows de todo el mundo.

La mayor mentira en la informática: Memoria virtual

Cuando un programa solicita una dirección de memoria, esa dirección es casi siempre una mentira. Es una dirección virtual que una componente de hardware llamada MMU (Memory Management Unit) traduce primero a una dirección física real. La traducción se realiza mediante una estructura de datos llamada Page Table, que el kernel mantiene por proceso. La memoria se entrega en páginas de 4‑kilobytes, cada proceso recibe su propio espacio de direcciones virtuales.

Precisamente esa separación es la razón por la que tu navegador no puede leer la memoria de tu gestor de contraseñas. Ambos viven en universos paralelos que solo el kernel puede observar.

La MMU almacena en caché traducciones frecuentes en un pequeño búfer, el TLB. Si un proceso accede a una página que no está en RAM, la MMU genera un Page Fault, el kernel carga la página desde el disco y el proceso continúa como si nada hubiera pasado. Este mismo mecanismo es la base de los límites de memoria en contenedores: cuando un pod supera su límite de cgroup, entra en acción el OOM‑Killer y finaliza el proceso – sin swap, sin advertencias.

Controladores, interrupciones y el primer proceso

Una vez que el kernel conoce la memoria y el sistema de archivos, carga los controladores. Los controladores traducen peticiones genéricas del kernel en órdenes específicas del chip para la GPU, la tarjeta WLAN, el teclado. Se ejecutan en el anillo 0, lo que resulta cómodo para el rendimiento, pero peligroso para la estabilidad. El mencionado incidente de Crowdstrike es el recordatorio de la industria de por qué las revisiones de controladores deben tomarse en serio.

Con los controladores el kernel activa las interrupciones. ¿Cómo sabe un sistema operativo que acabas de pulsar una tecla? No lo pregunta en un bucle infinito. En su lugar, el teclado envía una señal eléctrica que saca a la CPU de su tarea actual y la lleva a un manejador de interrupciones en el kernel. Cada movimiento del ratón, cada paquete WLAN, cada respuesta del disco es una interrupción.

Solo entonces el kernel crea el primer proceso en espacio de usuario: PID 1, en Linux moderno suele ser systemd. PID 1 es el ancestro de todos los demás procesos – si muere PID 1, el kernel entra en pánico y el ordenador se apaga. A partir de ese momento todo se ejecuta en el anillo 3 y debe solicitar permiso al kernel mediante System Calls cada vez que necesita acceder al sistema de archivos, a la red o al hardware.

Multitarea en ocho núcleos para cientos de procesos

Una VM en la nube moderna puede tener ocho o dieciséis vCPUs, pero cientos de procesos. Para que eso funcione, existe el Scheduler. Decide, en intervalos de milisegundos, qué proceso se ejecuta en qué núcleo en cada momento. El scheduler actual de Linux se llama EEVDF (Earliest Eligible Virtual Deadline First) y garantiza a cada proceso su parte justa de CPU.

Si en Kubernetes escribes kubectl get pods, en segundo plano funciona el mismo mecanismo un nivel más arriba: el Kubernetes‑Scheduler distribuye Pods en Nodes, de forma similar a como el scheduler de Linux asigna procesos a núcleos. Las Resource Requests y Limits en K8s son los hermanos de los valores nice y de las cuotas cgroup a nivel del SO.

Dentro de un proceso suele ejecutarse más de una vía – a través de Threads. Los threads comparten memoria, pero tienen sus propias pilas. Es potente, pero peligroso: si dos threads escriben simultáneamente en la misma variable, aparecen condiciones de carrera. Los lenguajes modernos intentan evitarlo, Go mediante gorutinas con Channels, Rust mediante el Borrow Checker, que rechaza el código no seguro para threads ya en la compilación.

Cuando dos procesos completamente independientes deben comunicarse, sirve IPC – Interprocess Communication. La forma más sencilla es la tubería, inventada en 1973 por Doug McIlroy en Bell Labs y que sigue siendo insuperable: cat log.txt | grep ERROR es precisamente eso. Además existen sockets y colas de mensajes – toda la arquitectura de microservicios es, conceptualmente, IPC, solo que extendida a la red.

Qué deben aprender los Cloud‑Engineers de esto

Un contenedor no es un sistema operativo propio. Es un proceso en espacio de usuario sobre un host‑kernel, aislado mediante namespaces y limitado en recursos mediante cgroups. Precisamente por eso los contenedores se inician en milisegundos en lugar de segundos como una VM – el SO subyacente ya está en ejecución. Quien lo comprende, depura Pods OOMKilled, cargas de trabajo latencia‑críticas y arquitecturas Sidecar con una perspectiva totalmente distinta.

El vídeo de Fireship «Every operating system concept in one video» ofrece las diez etapas en once minutos – como curso intensivo visual es una muy buena complementación. Profundizar vale la pena a través de la Linux Kernel Documentation y la lectura clásica «Operating Systems: Three Easy Pieces» de Remzi Arpaci‑Dusseau, disponible gratuitamente en línea. Quien quiera profundizar en las implicaciones de seguridad de los controladores Ring‑0, encontrará en el portal hermano de SecurityToday el análisis de cómo los agentes de IA descubren Zero‑Days del kernel Linux.

Preguntas frecuentes

¿Necesito conocimientos de SO si solo utilizo Kubernetes?

A más tardar en el primer pod OOMKilled, en el primer throttling de CPU o en el primer bug de registro del sidecar. Kubernetes no abstrae el sistema operativo, se coloca encima de él. Los límites de recursos, las sondas de liveness y las políticas de red solo pueden configurarse de forma sensata si entiendes cómo funcionan cgroups, namespaces y el scheduler de Linux bajo él.

¿Son los contenedores más ligeros que las VMs porque no tienen sistema operativo?

Los contenedores sí tienen un sistema operativo, solo comparten el kernel del host. Lo que contiene la imagen del contenedor es el espacio de usuario: bibliotecas, binarios, configuración. Una VM incluye un kernel propio completo, más la sobrecarga del hipervisor. Esa es la razón principal por la que los contenedores se inician en milisegundos y las VMs en segundos.

¿Por qué Linux elimina mi contenedor en lugar de usar swap?

Porque los cgroups imponen límites de memoria estrictos. En cuanto un contenedor supera su límite, el OOM‑killer envía un SIGKILL, sin advertencia y sin intentar usar swap. Es intencional: el rendimiento predecible es más importante en el clúster que la supervivencia bajo best‑effort de pods individuales. Quien quiera eludirlo debe o bien aumentar los límites o realizar un profiling de memoria.

¿Cuál es la diferencia entre kernel space y user space?

El kernel space se ejecuta en el anillo 0 con control total del hardware. Allí residen los controladores, el scheduler y el módulo del sistema de archivos. El user space se ejecuta en el anillo 3, sin acceso directo al hardware. Cada servidor web, cada base de datos, cada contenedor funciona en el user space. Si quiere acceder al hardware o a archivos, solo puede hacerlo mediante system calls, el único puente entre ambos mundos.

¿Qué ocurre realmente durante el apagado?

Al revés que en el arranque: el PID 1 envía a cada proceso un SIGTERM (cortesía para que finalice). Quien no responde, tras un timeout recibe un SIGKILL. Entonces los sistemas de archivos vacían sus journales, los controladores liberan el hardware, el kernel sincroniza la memoria en el disco, desactiva interrupciones y el firmware corta la alimentación. Todo ello en menos de dos segundos en una máquina normal.

Fuente imagen principal: Pexels / Manuel Geissinger (px:2881229)