7 Min. Tiempo de lectura<\/p>\n
Presionas el Power-Button y segundos despu\u00e9s se mueve tu cursor. Lo que ocurre entre medio es el software m\u00e1s subestimado del mundo, y precisamente sobre eso se basa cada pod, cada contenedor y cada Cloud-VM.<\/strong><\/p>\n Relacionado:<\/span>Kubernetes 1.31 Sidecar Containers \/<\/span> Container-Runtime im Vergleich<\/p>\n Un sistema operativo no es un programa \u00fanico, sino una secuencia coreografiada de diez etapas. Quien depura contenedores o planifica cl\u00fasteres de Kubernetes trabaja cada d\u00eda con el resultado, normalmente sin saber qu\u00e9 ocurre en la sala de m\u00e1quinas.<\/p>\n Presionas el Power-Button. La energ\u00eda llega a la placa base, la CPU se despierta y ejecuta la primera instrucci\u00f3n en una direcci\u00f3n fija. En este punto no hay gesti\u00f3n de memoria ni archivos, solo un \u00fanico n\u00facleo que ejecuta un firmware. En los equipos modernos se llama UEFI, antes era BIOS.<\/p>\n 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 \u00fanica tarea: cargar el kernel en la RAM. En cuanto ocurre, la CPU funciona en Ring 0<\/strong>, el modo con control total del hardware.<\/p>\n Ring\u202f0 frente a Ring\u202f3 es la l\u00ednea divisoria m\u00e1s importante de tu ordenador. Las CPUs x86 tienen cuatro anillos, pero en la pr\u00e1ctica solo cuentan dos: Ring\u202f0 para el kernel, Ring\u202f3 para todo lo dem\u00e1s. Un error en c\u00f3digo de Ring\u202f0 paraliza toda la m\u00e1quina: la famosa ca\u00edda de Crowdstrike en el verano de 2024 fue precisamente eso, un controlador defectuoso en Ring\u202f0 que provoc\u00f3 pantallas azules en m\u00e1quinas Windows de todo el mundo.<\/p>\n\n Cuando un programa solicita una direcci\u00f3n de memoria, esa direcci\u00f3n es casi siempre una mentira. Es una direcci\u00f3n virtual que una componente de hardware llamada MMU (Memory Management Unit) traduce primero a una direcci\u00f3n f\u00edsica real. La traducci\u00f3n se realiza mediante una estructura de datos llamada Page Table, que el kernel mantiene por proceso. La memoria se entrega en p\u00e1ginas de 4\u2011kilobytes, cada proceso recibe su propio espacio de direcciones virtuales.<\/p>\n La MMU almacena en cach\u00e9 traducciones frecuentes en un peque\u00f1o b\u00fafer, el TLB. Si un proceso accede a una p\u00e1gina que no est\u00e1 en RAM, la MMU genera un Page Fault, el kernel carga la p\u00e1gina desde el disco y el proceso contin\u00faa como si nada hubiera pasado. Este mismo mecanismo es la base de los l\u00edmites de memoria en contenedores: cuando un pod supera su l\u00edmite de cgroup, entra en acci\u00f3n el OOM\u2011Killer y finaliza el proceso \u2013 sin swap, sin advertencias.<\/p>\n Una vez que el kernel conoce la memoria y el sistema de archivos, carga los controladores. Los controladores traducen peticiones gen\u00e9ricas del kernel en \u00f3rdenes espec\u00edficas del chip para la GPU, la tarjeta WLAN, el teclado. Se ejecutan en el anillo\u202f0, lo que resulta c\u00f3modo para el rendimiento, pero peligroso para la estabilidad. El mencionado incidente de Crowdstrike es el recordatorio de la industria de por qu\u00e9 las revisiones de controladores deben tomarse en serio.<\/p>\n Con los controladores el kernel activa las interrupciones<\/strong>. \u00bfC\u00f3mo sabe un sistema operativo que acabas de pulsar una tecla? No lo pregunta en un bucle infinito. En su lugar, el teclado env\u00eda una se\u00f1al el\u00e9ctrica que saca a la CPU de su tarea actual y la lleva a un manejador de interrupciones en el kernel. Cada movimiento del rat\u00f3n, cada paquete WLAN, cada respuesta del disco es una interrupci\u00f3n.<\/p>\n Solo entonces el kernel crea el primer proceso en espacio de usuario: PID\u202f1, en Linux moderno suele ser systemd<\/strong>. PID\u202f1 es el ancestro de todos los dem\u00e1s procesos \u2013 si muere PID\u202f1, el kernel entra en p\u00e1nico y el ordenador se apaga. A partir de ese momento todo se ejecuta en el anillo\u202f3 y debe solicitar permiso al kernel mediante System Calls<\/strong> cada vez que necesita acceder al sistema de archivos, a la red o al hardware.<\/p>\n Una VM en la nube moderna puede tener ocho o diecis\u00e9is vCPUs, pero cientos de procesos. Para que eso funcione, existe el Scheduler<\/strong>. Decide, en intervalos de milisegundos, qu\u00e9 proceso se ejecuta en qu\u00e9 n\u00facleo 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.<\/p>\n Si en Kubernetes escribes kubectl get pods<\/strong>, en segundo plano funciona el mismo mecanismo un nivel m\u00e1s arriba: el Kubernetes\u2011Scheduler distribuye Pods en Nodes, de forma similar a como el scheduler de Linux asigna procesos a n\u00facleos. Las Resource Requests y Limits en K8s son los hermanos de los valores nice<\/strong> y de las cuotas cgroup a nivel del SO.<\/p>\n Dentro de un proceso suele ejecutarse m\u00e1s de una v\u00eda \u2013 a trav\u00e9s de Threads<\/strong>. Los threads comparten memoria, pero tienen sus propias pilas. Es potente, pero peligroso: si dos threads escriben simult\u00e1neamente 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\u00f3digo no seguro para threads ya en la compilaci\u00f3n.<\/p>\n Cuando dos procesos completamente independientes deben comunicarse, sirve IPC<\/strong> \u2013 Interprocess Communication. La forma m\u00e1s sencilla es la tuber\u00eda, inventada en 1973 por Doug McIlroy en Bell Labs y que sigue siendo insuperable: cat log.txt | grep ERROR<\/strong> es precisamente eso. Adem\u00e1s existen sockets y colas de mensajes \u2013 toda la arquitectura de microservicios es, conceptualmente, IPC, solo que extendida a la red.<\/p>\n Un contenedor no es un sistema operativo propio. Es un proceso en espacio de usuario sobre un host\u2011kernel, 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 \u2013 el SO subyacente ya est\u00e1 en ejecuci\u00f3n. Quien lo comprende, depura Pods OOMKilled, cargas de trabajo latencia\u2011cr\u00edticas y arquitecturas Sidecar con una perspectiva totalmente distinta.<\/p>\n El v\u00eddeo de Fireship \u00abEvery operating system concept in one video\u00bb<\/a> ofrece las diez etapas en once minutos \u2013 como curso intensivo visual es una muy buena complementaci\u00f3n. Profundizar vale la pena a trav\u00e9s de la Linux Kernel Documentation<\/a> y la lectura cl\u00e1sica \u00abOperating Systems: Three Easy Pieces\u00bb de Remzi Arpaci\u2011Dusseau, disponible gratuitamente en l\u00ednea. Quien quiera profundizar en las implicaciones de seguridad de los controladores Ring\u20110, encontrar\u00e1 en el portal hermano de SecurityToday el an\u00e1lisis de c\u00f3mo los agentes de IA descubren Zero\u2011Days del kernel Linux<\/a>.<\/p>\n A m\u00e1s 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 \u00e9l. Los l\u00edmites de recursos, las sondas de liveness y las pol\u00edticas de red solo pueden configurarse de forma sensata si entiendes c\u00f3mo funcionan cgroups, namespaces y el scheduler de Linux bajo \u00e9l.<\/p>\n<\/details>\n Los contenedores s\u00ed 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\u00f3n. Una VM incluye un kernel propio completo, m\u00e1s la sobrecarga del hipervisor. Esa es la raz\u00f3n principal por la que los contenedores se inician en milisegundos y las VMs en segundos.<\/p>\n<\/details>\n Porque los cgroups imponen l\u00edmites de memoria estrictos. En cuanto un contenedor supera su l\u00edmite, el OOM\u2011killer env\u00eda un SIGKILL, sin advertencia y sin intentar usar swap. Es intencional: el rendimiento predecible es m\u00e1s importante en el cl\u00faster que la supervivencia bajo best\u2011effort de pods individuales. Quien quiera eludirlo debe o bien aumentar los l\u00edmites o realizar un profiling de memoria.<\/p>\n<\/details>\n El kernel space se ejecuta en el anillo 0 con control total del hardware. All\u00ed residen los controladores, el scheduler y el m\u00f3dulo 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 \u00fanico puente entre ambos mundos.<\/p>\n<\/details>\n Al rev\u00e9s que en el arranque: el PID\u202f1 env\u00eda a cada proceso un SIGTERM (cortes\u00eda para que finalice). Quien no responde, tras un timeout recibe un SIGKILL. Entonces los sistemas de archivos vac\u00edan sus journales, los controladores liberan el hardware, el kernel sincroniza la memoria en el disco, desactiva interrupciones y el firmware corta la alimentaci\u00f3n. Todo ello en menos de dos segundos en una m\u00e1quina normal.<\/p>\n<\/details>\n Fuente imagen principal: Pexels \/ Manuel Geissinger (px:2881229)<\/p>\n\n Fuente de imagen: generada por IA (mayo de 2026), certificado C2PA integrado en la imagen<\/em><\/p>","protected":false},"excerpt":{"rendered":"Presionas el bot\u00f3n de encendido y, unos segundos despu\u00e9s, tu cursor se mueve. Lo que sucede en medio es el software m\u00e1s subestimado del mundo \u2014 y\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":[957],"tags":[],"industry":[],"class_list":["post-40355","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-centros-de-datos"],"evm_reading_time_minutes":10,"wpml_language":"es","wpml_translation_of":40253,"acf":[],"yoast_head":"\nLo m\u00e1s importante en resumen<\/h2>\n
\n
Energ\u00eda encendida: bootloader y anillos de privilegio<\/h2>\n
La mayor mentira en la inform\u00e1tica: Memoria virtual<\/h2>\n
\nPrecisamente esa separaci\u00f3n es la raz\u00f3n por la que tu navegador no puede leer la memoria de tu gestor de contrase\u00f1as. Ambos viven en universos paralelos que solo el kernel puede observar.\n<\/blockquote>\n
Controladores, interrupciones y el primer proceso<\/h2>\n
Multitarea en ocho n\u00facleos para cientos de procesos<\/h2>\n
Qu\u00e9 deben aprender los Cloud\u2011Engineers de esto<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfNecesito conocimientos de SO si solo utilizo Kubernetes?<\/strong><\/summary>\n
\u00bfSon los contenedores m\u00e1s ligeros que las VMs porque no tienen sistema operativo?<\/strong><\/summary>\n
\u00bfPor qu\u00e9 Linux elimina mi contenedor en lugar de usar swap?<\/strong><\/summary>\n
\u00bfCu\u00e1l es la diferencia entre kernel space y user space?<\/strong><\/summary>\n
\u00bfQu\u00e9 ocurre realmente durante el apagado?<\/strong><\/summary>\n