El 6 de junio de 2014 Joe Beda hizo el primer commit público de lo que se convertiría en Kubernetes: 250 archivos, 47.501 líneas de Go, Bash y Markdown. Cuatro días después Eric Brewer anunció el proyecto en DockerCon. Un año más tarde, el 21 de julio de 2015, salió la 1.0 — y Google anunció que donaría el código a la recién creada Cloud Native Computing Foundation. Doce años después, Kubernetes 1.37.0 (26 de agosto de 2026), apodado Garhwal, sigue siendo la forma estándar de orquestar contenedores en producción.
Años 2000: Borg, Omega y un prototipo en Java
Antes del timón existía el Borg. Desde mediados de los años 2000 Google ya ejecutaba jobs en un clúster interno que nadie de fuera veía. Omega (2013) intentó el siguiente paso: un scheduler más compartido, menos monolito. Nada de esto salía del campus. Fuera, en 2013, el mundo de la nube todavía era script bash, imagen de VM inmutable al estilo Netflix y muy poca orquestación de contenedores.
Quién cambió el enfoque fue el Docker. Brendan Burns, Craig McLuckie y Joe Beda, en Google Cloud, vieron el runtime de una sola máquina y entendieron el vacío: faltaba el orquestador de la flota. Burns hizo un prototipo en Java. Lo reescribieron en Go. Llegaron Ville Aikas, Tim Hockin, Dawn Chen, Brian Grant y Daniel Smith. Aún se llamaba Task; el nombre cambió dos días antes del anuncio, en el commit 8 de junio.
El nombre clave interno, puesto por Burns, era Seven of Nine: el Borg más accesible de Star Trek. De ahí el heptágono del logo: siete lados, siete rayos en el timón. Kubernetes, en griego, es el timonel — el piloto del barco. k8s es el mismo truco que i18n: ocho letras en medio.
Junio de 2014: el commit y la DockerCon
El primer commit público es del 6 de junio de 2014, 16:40:48 hora del Pacífico. Beda limpió el repositorio para el lanzamiento; el trabajo anterior ya existía. El 10 de junio Brewer subió al escenario del primer DockerCon. El mensaje era sencillo: Docker empaqueta; falta alguien que esparza el paquete en decenas de máquinas, que replique, que descubra el servicio y que cure lo que muere.
El “orquestador mínimo viable” que querían tenía cuatro piezas: replicación, balanceo y descubrimiento de servicio, health check con autorreparación, y un scheduler que trata la flota como un pool. El resto — Ingress, CRD, Operators, sidecar — vino después, de la comunidad.
Julio de 2015: la 1.0, la OSCON y la CNCF
Red Hat llegó pronto y trajo lo que faltaba: la experiencia de vender software a empresas grandes, acumulada en OpenShift. Sin ese enfoque del mundo real — multi-tenancy, actualización sin downtime, autorización que sobrevive a una auditoría — la 1.0 no salía. Un RBAC de verdad solo llegaría en la 1.6, en 2017. El 21 de julio de 2015, en OSCON, el Kubernetes 1.0 fue declarado listo para producción. Ese mismo día Google cedió el control: nacía la Cloud Native Computing Foundation, brazo de la Linux Foundation, con AT&T, Cisco, Docker, IBM, Intel, Red Hat, Twitter, VMware y una decena más.
El proyecto solo entró de hecho como hosted project de la CNCF el 10 de marzo de 2016 — el primero. El 6 de marzo de 2018 fue el primero en graduarse. Apache 2.0, Go, API declarativa: tú describes el estado deseado; el control loop intenta llegar allí. ReplicaSet, Deployment, Service, Namespace. Después Job, DaemonSet, StatefulSet, Ingress, CRD.
Lo que el timón copió del Borg — y lo que no copió
El Pod es la unidad atómica: uno o más contenedores que comparten red y volumen, programados juntos. En Borg esto ya existía. Label y selector, el Service como VIP estable frente a Pods que mueren, el kubelet en cada nodo, etcd como fuente de la verdad — ese es el diseño. Lo que Borg no tenía, y Kubernetes apostó por ello, fue la API abierta y la extensibilidad: Custom Resource Definition, admission webhook, Container Runtime Interface.
El runtime, por cierto, nunca fue “Docker obligatorio”. El dockershim (el puente que hablaba con el demonio de Docker) se marcó como deprecated en 1.20 y se eliminó en 1.24 (mayo de 2022). Quien aún piense que “Kubernetes = Docker” lleva cuatro años de retraso, en el mejor de los casos. CRI-O y containerd hablan CRI directamente. El motor de Docker, por debajo, también usa containerd. La historia de la ballena está en el post hermano.
Kubernetes y Linux: la deuda que nadie menciona
Kubernetes solo existe porque el kernel Linux obtuvo, años antes, las dos primitivas que hacen posible el contenedor — y una de ellas salió del mismo sitio.
- Los Namespaces responden a “¿qué ve este proceso?”. El primer tipo entró en el kernel 2002 (mount); el conjunto clásico — PID, red, IPC, UTS, usuario — solo se completó en 2013, con el user namespace en el kernel 3.8. El cgroup namespace vendría después en 2016, y el de tiempo en 2020.
- cgroups responden a “¿qué puede consumir este proceso?”. Fueron escritos por Paul Menage e Rohit Seth, de Google, a partir de 2006, y entraron en la línea principal del kernel 2.6.24, publicado en enero de 2008. El nombre original era process containers — cambiado porque “container” ya estaba sobrecargado en el ecosistema Linux: Solaris Zones, Linux-VServer, OpenVZ.
Dos ingenieros de Google tocando el límite de CPU y memoria en 2006 no es casualidad: la empresa ya ejecutaba todo en un clúster compartido, el linaje que desembocaría en Borg. El mismo campus que produjo Borg donó al kernel la pieza que, cinco años después, Docker empaquetó y Kubernetes orquestó. El timón no inventó el aislamiento — programó, a escala, un aislamiento que Linux ya sabía hacer.
Esto aparece en el día a día: el limit de un Pod se convierte en cgroup en el nodo (cpu.max, memory.max) y el request de CPU se convierte en peso de planificación (cpu.weight) — el request de memoria solo se convierte en cgroup con Memory QoS activado. El kubelet es un proceso común leyendo y escribiendo en /sys/fs/cgroup. Y el cgroup v2 (estándar en las distribuciones actuales) trajo el controlador de memoria unificado — memory.min, memory.low, memory.high, memory.max —, que frena la carga de trabajo en lugar de matarla en el límite. Es bajo la jerarquía de v2 que el kernel expone el PSI (pressure stall information, kernel 4.20, diciembre de 2018) por cgroup; el kubelet lee esa señal de forma estable desde la 1.36. Quien entiende el kernel de debajo depura Kubernetes mucho más rápido que quien solo sabe YAML.
2016–2017: la guerra que Swarm perdió
Mientras el timón crecía, Docker apostó por Swarm como orquestador nativo — más sencillo de aprender, integrado en el producto que todo el mundo ya tenía instalado. En 2017 la propia Docker, Inc. tiró la toalla y anunció soporte para Kubernetes. Mesos, Nomad, Cattle — todos sobrevivieron en nichos. El patrón de hecho se quedó con el heptágono. No porque el YAML sea bonito (no lo es), sino porque todo proveedor de nube pasó a vender el mismo objeto: un cluster Kubernetes gestionado. GKE, EKS, AKS, el OpenShift de Red Hat, el Rancher. La API se convirtió en el Linux de la nube: nadie la ama, todo el mundo la habla.
2016–2018: qué pasó con quienes lo crearon
Los tres salieron de Google, cada uno a su tiempo. Brendan Burns se fue a Microsoft en julio de 2016 y ayudó a construir Azure Kubernetes Service. Joe Beda ya había salido en 2015; Craig McLuckie salió a finales de 2016, y ambos fundaron Heptio en noviembre, en Seattle, para vender Kubernetes a empresas. VMware anunció la compra en noviembre de 2018 por aproximadamente $ 550 millones de USD y la cerró en diciembre; Heptio se convirtió en uno de los pilares de Tanzu — Velero, Sonobuoy, Contour, el TKG. El proyecto quedó donde debía: en una fundación, con gobernanza abierta y cientos de empresas empujando.
2026: Garhwal, kube-dns y la limpieza del legado
Kubernetes 1.37.0 salió el 26 de agosto de 2026, ciclo de 15 semanas, release lead Dipesh Rawat. Apodo Garhwal (गढ़वाल), región del Himalaya en Uttarakhand. 67 mejoras: 16 estables, 23 beta, 27 alpha, una deprecación. Aspectos destacados que importan en el clúster de verdad:
- Dynamic Resource Allocation cerró el paquete: solicitud de recurso extendido mediante driver, taint e toleration de dispositivo y el atributo
resource.kubernetes.io/numaNodese volvieron Stable. El núcleo de DRA ya era GA desde la 1.34: es lo que sacó a la GPU, la FPGA y el dispositivo de IA del apaño de Device Plugin. - kube-dns está deprecated. CoreDNS es el DNS por defecto desde la 1.13; no se debe publicar un nuevo paquete de kube-dns después de la 1.40.
- El modo IPVS de kube-proxy ya venía deprecated desde la 1.35; el camino es iptables o, preferentemente, nftables: el modo desaparece por completo en la 1.43.
- HPA scale-to-zero entró en beta, activado por defecto: el autoscale ahora puede dejar a cero la réplica.
- Un nodo en cgroup v1 ya no arranca: el
failCgroupV1del kubelet estruepor defecto desde la 1.35. Sin cgroup v2 no hay Memory QoS, swap ni métrica de PSI: la deuda con el kernel se convirtió en requisito operativo.
Las versiones con soporte activo en septiembre de 2026 son 1.37, 1.36 y 1.35; la 1.34 aún recibe correcciones hasta el 27 de octubre. La 1.37.1 está marcada para el 15 de septiembre. El etcd y las implementaciones de CRI y CNI siguen fuera del binario: el timón orquesta; quien ejecuta el contenedor es otro proceso.
Probar hoy, sin clúster y sin nube
Doce años después, levantar un Kubernetes para estudiar es cuestión de minutos en una sola máquina. Tres caminos, del más desechable al más parecido a producción:
# kind — cluster dentro de containers, o mais rápido de jogar fora
kind create cluster --name estudo
kubectl get nodes
# minikube — VM ou container, com addons (dashboard, ingress, registry)
minikube start
minikube addons enable ingress
# k3s — leve, criado pela Rancher (hoje SUSE) e doado à CNCF em 2020; roda de verdade em Raspberry Pi
curl -sfL https://get.k3s.io | sh -
sudo k3s kubectl get nodesO kind y el minikube son laboratorio. El k3s es otra cosa: un único binario, con etcd sustituido por SQLite por defecto (etcd vuelve solo en HA con varios servidores), utilizado en el borde y en entornos pequeños de producción. Si la idea es tener un clúster de verdad en un servidor casero, empiece por él.
Línea de tiempo
- Mediados de los años 2000 — Google ya ejecuta trabajos en Borg, un clúster interno que nadie de fuera ve.
- 2006–2008 — Paul Menage y Rohit Seth, de Google, escriben los cgroups; la funcionalidad llega al kernel 2.6.24 en enero de 2008.
- 2013 — Omega intenta el siguiente paso dentro de Google; fuera de allí, Docker hace que el contenedor sea evidente.
- 6 de junio de 2014 — primer commit público: 250 archivos, 47.501 líneas.
- 10 de junio de 2014 — Eric Brewer anuncia el proyecto en el primer DockerCon.
- 21 de julio de 2015 — Kubernetes 1.0 no OSCON; el mismo día nace la CNCF y Google anuncia que cederá el control.
- 10 de marzo de 2016 — primer proyecto alojado de la CNCF.
- 2016 — Burns se va a Microsoft; McLuckie y Beda fundan Heptio.
- 2017 — Docker, Inc. anuncia soporte para Kubernetes; la disputa con Swarm termina.
- 6 de marzo de 2018 — primer proyecto en graduarse en la CNCF.
- Noviembre de 2018 — VMware compra Heptio por aproximadamente US$ 550 millones.
- Mayo de 2022 — dockershim se elimina en la versión 1.24; containerd y CRI-O toman el relevo.
- 26 de agosto de 2026 — 1.37.0 “Garhwal”: kube-dns obsoleto, HPA scale-to-zero en beta, DRA completo, cgroup v1 bloqueado en kubelet.
Cierre
Tres ingenieros en Google Cloud, un tiempo de ejecución de una máquina, un clúster interno que nadie veía. El resultado es el plano de control que la industria copió. El heptágono en la portada es el mismo de 2014. El YAML también — para bien y para mal.
La ballena que hizo obvio el contenedor está en A história do Docker. El hipervisor de servidor, en Proxmox e Xen. El kernel debajo de todo, en Linux cumple 35 años e La historia de Linus Torvalds.
De Borg a Garhwal: el timonel sigue al mando. 1.37.0, Apache 2.0, CRI, nftables. Siete radios, doce años, y el YAML que a nadie le gusta escribir, pero todo el mundo commitea.