Pocas tecnologías han cambiado tanto la forma de operar infraestructura como Kubernetes. Empezó siendo un proyecto interno de Google y hoy es el estándar de facto para desplegar aplicaciones en contenedores. Y todo descansa sobre los cimientos del kernel Linux. ¿Cómo consigue una sola plataforma manejar miles de contenedores repartidos en decenas de máquinas sin que un humano vigile cada uno? La respuesta tiene nombre: orquestación.
De Borg a Kubernetes
Kubernetes salió de la experiencia de Google ejecutando contenedores a una escala que pocas organizaciones alcanzan. Durante años, Google gestionó sus cargas internas con un sistema llamado Borg, desarrollado a mediados de la década de 2000. De ese conocimiento acumulado surgió Kubernetes, que Google anunció como proyecto de código abierto el 6 de junio de 2014, fecha que muchos toman como su cumpleaños oficial.
El proyecto creció rápido. Coincidiendo con la versión 1.0, en 2015 Google donó Kubernetes a la recién creada Cloud Native Computing Foundation (CNCF), bajo el paraguas de la Linux Foundation. Esa cesión a una fundación neutral marcó la diferencia: dio una gobernanza independiente de cualquier fabricante y atrajo a una comunidad enorme. El nombre, que muchos abrevian como K8s (la K, ocho letras y la s), viene del griego para “timonel” o “piloto”. Encaja con algo que dirige flotas de contenedores.
Por qué todo depende del kernel Linux
Aquí está el detalle que mucha gente pasa por alto: Kubernetes no inventa el aislamiento de procesos. Se apoya en las mismas primitivas que cualquier contenedor Linux usa desde hace años. Los namespaces del kernel aíslan lo que cada contenedor puede ver (procesos, red, sistema de archivos, identificadores de usuario), y los cgroups (control groups) limitan y contabilizan los recursos que consume: CPU, memoria, entrada/salida.
Un contenedor, en el fondo, es un proceso Linux normal con estas barreras aplicadas. Kubernetes opera un nivel por encima: decide en qué máquina arranca cada contenedor, cuántas copias mantener vivas y cómo conectarlas entre sí. Por eso los nodos de trabajo de un clúster son, casi siempre, máquinas Linux. Distribuciones como Ubuntu y Debian abundan en estos nodos, y en entornos empresariales con soporte comercial es muy común RHEL o su base comunitaria AlmaLinux y Rocky Linux.
Anatomía de un clúster
Un clúster de Kubernetes se divide en dos planos. El plano de control es el cerebro: contiene el servidor de API con el que hablas, el planificador que decide dónde colocar cada carga, el almacén de estado (etcd) y los controladores que vigilan que la realidad coincida con lo que pediste. Los nodos de trabajo son los músculos: ejecutan los contenedores reales mediante un agente llamado kubelet.
La unidad mínima de despliegue no es el contenedor suelto, sino el pod: un grupo de uno o más contenedores que comparten red y almacenamiento. Sobre los pods se construyen abstracciones de más alto nivel como los Deployments, que mantienen un número deseado de réplicas y permiten actualizaciones graduales sin cortar el servicio.
Despliegue, escalado y auto-reparación
La gracia de Kubernetes está en su modelo declarativo. No le ordenas paso a paso qué hacer; le describes el estado final que quieres (“quiero cinco réplicas de esta aplicación”) y el sistema trabaja sin descanso para llegar a él y mantenerlo. Si un nodo se cae, Kubernetes reprograma sus pods en otra máquina sana. Si un contenedor se bloquea, lo reinicia. Eso es la auto-reparación.
El escalado funciona en ambas direcciones: puedes añadir réplicas a mano o configurar un autoescalador que reaccione a la carga real, levantando más copias cuando sube el tráfico y retirándolas cuando baja. Para entornos con recursos ajustados o imágenes minimalistas, Alpine Linux es una elección popular como base de contenedores por su tamaño reducido, que acelera descargas y arranques.
Container runtimes: el motor bajo el capó
Kubernetes no ejecuta contenedores directamente; delega esa tarea en un container runtime que cumpla la interfaz CRI (Container Runtime Interface). Durante años el más conocido fue Docker, pero el proyecto se movió hacia runtimes más livianos y alineados con el estándar. En la versión 1.24, lanzada en mayo de 2022, Kubernetes quitó definitivamente el componente dockershim, el adaptador que permitía usar Docker directamente.
Hoy las opciones dominantes son containerd (el mismo motor que Docker usaba internamente) y CRI-O, diseñado a medida para Kubernetes. Da igual que tus imágenes se construyeran con Docker: siguen funcionando, porque cumplen el formato OCI estándar. Quienes necesitaban conservar Docker como runtime pasaron a un adaptador llamado cri-dockerd.
Dónde practicar sin romper nada
No hace falta un centro de datos para aprender Kubernetes. Herramientas como Minikube o kind levantan un clúster completo en tu propia máquina dentro de contenedores. Sobre cualquier distribución de escritorio moderna, ya sea Fedora, openSUSE o Pop!_OS, puedes experimentar con despliegues, escalados y fallos simulados sin coste ni riesgo.
Kubernetes no sustituye a Linux: lo amplifica. Toma las piezas que el kernel lleva décadas puliendo y las orquesta a una escala que sería imposible de gestionar a mano. Entender esa relación es el primer paso para manejar la infraestructura moderna.