Em 6 de junho de 2014 Joe Beda fez o primeiro commit público do que viraria o Kubernetes: 250 arquivos, 47.501 linhas de Go, Bash e Markdown. Quatro dias depois Eric Brewer anunciou o projeto no DockerCon. Um ano depois, em 21 de julho de 2015, saiu a 1.0 — e o Google doou o código para a recém-criada Cloud Native Computing Foundation. Doze anos depois o Kubernetes 1.37.0 (26 de agosto de 2026), apelido Garhwal, ainda é o jeito padrão de orquestrar container em produção.
Borg, Omega e um protótipo em Java
Antes do leme existia o Borg. Por volta de 2003 o Google já rodava jobs em um cluster interno que ninguém de fora via. O Omega (2013) tentou o próximo passo: um scheduler mais compartilhado, menos monolito. Nada disso saía do campus. Lá fora, em 2013, o mundo de nuvem ainda era script bash, imagem de VM imutável à la Netflix e pouquíssima orquestração de container.
Quem mudou o recorte foi o Docker. Brendan Burns, Craig McLuckie e Joe Beda, no Google Cloud, viram o runtime de uma máquina só e entenderam o buraco: faltava o orquestrador da frota. Burns fez um protótipo em Java — McLuckie chamava de “uma célula pessoal do Borg”. Reescreveram em Go. Vieram Ville Aikas, Tim Hockin, Dawn Chen, Brian Grant e Daniel Smith. Pod ainda se chamava Task; o nome mudou no dia anterior ao anúncio.
O nome de código interno, dado por Burns, era Seven of Nine: a Borg mais acessível de Star Trek. Daí o heptágono de sete raios do logo. Kubernetes, em grego, é o timoneiro — o piloto do navio. k8s é o mesmo truque do i18n: oito letras no meio.
Junho de 2014: o commit e o DockerCon
O primeiro commit público é de 6 de junho de 2014, 16:40:48 no Pacífico. Beda limpou o repositório para o lançamento; o trabalho anterior já existia. Em 10 de junho Brewer subiu no palco do primeiro DockerCon. O recado era simples: Docker empacota; falta alguém para espalhar o pacote em dezenas de máquinas, replicar, descobrir serviço e curar o que morre.
O “orquestrador mínimo viável” que eles queriam tinha quatro peças: replicação, balanceamento e descoberta de serviço, health check com autorreparo, e um scheduler que trata a frota como um pool. O resto — Ingress, CRD, Operators, sidecar — veio depois, da comunidade.
1.0, OSCON e a CNCF
Red Hat chegou cedo, com a experiência de empresa do OpenShift. Sem esse recorte de mundo real a 1.0 não saía. Em 21 de julho de 2015, no OSCON, o Kubernetes 1.0 foi declarado pronto para produção. No mesmo dia o Google cedeu o controle: nascia a Cloud Native Computing Foundation, braço da Linux Foundation, com AT&T, Cisco, Docker, IBM, Intel, Red Hat, Twitter, VMware e uma dezena de outros.
O projeto só entrou de fato como hosted project da CNCF em 10 de março de 2016 — o primeiro. Em 6 de março de 2018 foi o primeiro a graduar. Apache 2.0, Go, API declarativa: você descreve o estado desejado; o control loop tenta chegar lá. ReplicaSet, Deployment, Service, Namespace. Depois Job, DaemonSet, StatefulSet, Ingress, CRD.
O que o leme copiou do Borg — e o que não copiou
Pod é a unidade atômica: um ou mais containers que compartilham rede e volume, agendados juntos. No Borg isso já existia. Label e seletor, o Service como VIP estável na frente de Pods que morrem, o kubelet em cada nó, o etcd como fonte da verdade — isso é o desenho. O que o Borg não tinha, e o Kubernetes apostou, foi a API aberta e o extensibility: Custom Resource Definition, admission webhook, Container Runtime Interface.
O runtime, aliás, nunca foi “Docker obrigatório”. O dockershim (a ponte que falava com o daemon do Docker) foi marcado como deprecated no 1.20 e removido no 1.24 (maio de 2022). Quem ainda acha que “Kubernetes = Docker” está dois anos atrasado na melhor hipótese. CRI-O e containerd falam CRI direto. O Engine do Docker, por baixo, também usa containerd. A história da baleia está no post irmão.
A guerra que o Swarm perdeu
Enquanto o leme crescia, o Docker apostou no Swarm como orquestrador nativo. Em 2017 a própria Docker, Inc. anunciou suporte a Kubernetes. Mesos, Nomad, Cattle — todos sobreviveram em nicho. O padrão de fato ficou o heptágono. Não porque o YAML seja bonito (não é), mas porque todo provedor de nuvem passou a vender o mesmo objeto: um cluster Kubernetes gerenciado. GKE, EKS, AKS, o OpenShift da Red Hat, o Rancher. A API virou o Linux da nuvem: ninguém ama, todo mundo fala.
2026: Garhwal, kube-dns e o DRA
O Kubernetes 1.37.0 saiu em 26 de agosto de 2026, ciclo de 15 semanas, release lead Dipesh Rawat. Apelido Garhwal (गढ़वाल), região himalaia de Uttarakhand. 67 melhorias: 16 estáveis, 23 beta, 27 alpha, uma depreciação. Destaques que importam no cluster de verdade:
- O núcleo do Dynamic Resource Allocation (DRA) virou Stable — GPU, FPGA e dispositivo de IA deixam de ser gambiarra de Device Plugin.
- kube-dns está deprecated. CoreDNS é o DNS default desde o 1.13; pacote novo do kube-dns não deve sair depois do 1.40.
- O modo IPVS do kube-proxy já vinha deprecated desde o 1.35; o caminho é nftables.
- HPA scale-to-zero entrou em beta, ligado por default — o autoscale agora pode zerar réplica.
As versões com suporte em setembro de 2026 são 1.37, 1.36 e 1.35. A 1.37.1 está marcada para 15 de setembro. O etcd, o CRI e o CNI continuam fora do binário: o leme orquestra; quem remarca o container é outro processo.
O que ficou
Três engenheiros no Google Cloud, um runtime de uma máquina, um cluster interno que ninguém via. O resultado é o plano de controle que a indústria copiou. O heptágono na capa é o mesmo de 2014. O YAML, também — para o bem e para o mal.
A baleia que tornou o container óbvio está em A história do Docker. O hipervisor de servidor, em Proxmox e Xen. O kernel embaixo de tudo, em Linux faz 35 anos e A história de Linus Torvalds.
Do Borg ao Garhwal: o timoneiro ainda está no leme. 1.37.0, Apache 2.0, CRI, nftables. Sete raios, doze anos, e o YAML que ninguém gosta de escrever mas todo mundo commita.