Esta semana em cloud (26/jan–01/fev): a borda do cluster recebe um aviso de despejo

TL;DR: Semana enxuta de início de ano, mas com um aviso difícil de ignorar: o Ingress NGINX foi marcado para aposentadoria em março de 2026 — e ele sustenta cerca de metade dos clusters do mundo. Gateway API no kind e Cluster API v1.12 amadureceram a migração. Por baixo, a nova fórmula de CPU do cgroup v2 e o Git 2.53.0 ajustaram detalhes de produção, e a AWS levou a Blackwell ao EC2.

Janeiro fechando, calendário ainda meio vazio, poucas fontes na mesa — uma semana típica de começo de ano, dessas em que o volume de anúncios cai e dá para respirar. Só que, no meio do silêncio, veio o tipo de recado que estraga o feriado de quem opera infraestrutura: o Ingress NGINX ganhou data de aposentadoria. E não é um projeto qualquer. Ele está na borda de cerca de metade dos clusters Kubernetes em produção no mundo.

O detalhe que transforma a notícia em urgência é o prazo: março de 2026. São poucas semanas para sair de um componente que, em muitos ambientes, foi instalado anos atrás via Helm chart genérico e nunca mais foi tocado. A boa notícia é que, na mesma semana, dois movimentos do ecossistema deram contorno ao caminho de saída — a Gateway API ganhou um roteiro prático de teste local e o Cluster API v1.12 reduziu a fricção de mexer no ciclo de vida dos clusters.

A leitura para quem opera no Brasil é direta: esta não é semana de novidade brilhante, é semana de fazer o dever de casa. Inventariar a borda do cluster, validar a Gateway API num laboratório e revisar os detalhes de runtime que mudaram sob o capô vale mais, agora, do que qualquer keynote. Abaixo, os três destaques que sobraram de uma semana curta — e por que nenhum deles é opcional.

Por que o aviso de aposentadoria do Ingress NGINX é o evento da semana?

O comunicado partiu de duas instâncias que não costumam falar à toa: o Kubernetes Steering Committee e o Security Response Committee. Juntos, eles marcaram a aposentadoria oficial do Ingress NGINX para março de 2026. A partir dessa data, acabam as correções de bug e, mais grave, os patches de segurança. Os deployments existentes não param de funcionar do dia para a noite, mas entram num estado de degradação de segurança contínua: qualquer vulnerabilidade nova descoberta depois disso fica aberta, indefinidamente, num componente exposto à internet.

O que torna o caso emblemático é o contraste entre dependência e sustentação. O projeto está em cerca de 50% dos ambientes Kubernetes globalmente — e, mesmo assim, foi mantido por anos por apenas um ou dois profissionais em tempo livre. Some a isso um débito técnico acumulado: decisões de design antigas que davam flexibilidade viraram vetores de vulnerabilidade difíceis de mitigar sob padrões modernos de SecOps. A aposentadoria é, no fundo, o reconhecimento de que manter o projeto seguro ficou insustentável. É a versão cloud native de uma lição velha: software crítico mantido por voluntariado é risco de continuidade, não economia.

Não existe substituto drop-in de um para um, e é importante encarar isso de frente. A comunidade aponta a Gateway API como evolução natural do Ingress — um modelo mais expressivo e orientado a papéis, separando o que é responsabilidade de infra, de cluster e de aplicação. Como destino de implementação, os controladores maduros baseados em Envoy e companhia (Cilium, Istio, Envoy Gateway, Traefik, Kong) são as escolhas óbvias. O primeiro passo, porém, não é escolher a ferramenta: é descobrir onde o Ingress NGINX está. Em muitos clusters ele entrou de carona em pacotes de terceiros ou charts genéricos. Um kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx já revela a dependência.

Precisa inventariar a borda do seu cluster e planejar a saída do Ingress NGINX antes de março? Fale com os especialistas em Cloud Native da Nuvem Online.

Como dá para ensaiar a migração sem quebrar produção?

A pressa de março assusta, mas a semana também trouxe as ferramentas para encarar a transição com método em vez de pânico. A primeira é um roteiro de laboratório: dá para subir a Gateway API localmente com o kind (Kubernetes in Docker) somado ao cloud-provider-kind. Esse provider simula recursos de nuvem — entrega Service do tipo LoadBalancer e, principalmente, instala um Gateway API controller que cria as CRDs automaticamente e já provisiona uma GatewayClass. A partir daí, você define recursos Gateway e HTTPRoute, sobe uma aplicação de eco e valida o roteamento com um curl --resolve. É ambiente de aprendizado, não de produção — mas é exatamente onde a equipe internaliza o modelo de papéis (o time de infra cuida do Gateway, os times de produto cuidam de suas HTTPRoutes) antes de tocar no cluster real.

A segunda ferramenta atua uma camada abaixo, no ciclo de vida do próprio cluster: o Cluster API v1.12. Ele ataca duas das maiores dores de quem opera Kubernetes em escala. Os in-place updates rompem com o dogma da infraestrutura estritamente imutável — historicamente, qualquer mudança no spec de uma Machine disparava um rollout que criava uma máquina nova e deletava a antiga. Agora, via update extensions, o Cluster API consegue modificar a máquina existente para mudanças que não exigem drain de nó nem reinício de pods, como atualizar credenciais e certificados. Em ambientes bare metal, onde o drain é demorado, isso é redução direta de impacto no SLA.

O complemento são os chained upgrades. Antes, atualizar exigia o passo a passo rigoroso entre versões menores. Com a v1.12, o operador declara a versão final desejada partindo de uma bem anterior, e o Cluster API computa o plano de migração e executa os saltos intermediários — pulando versões nos worker machines sempre que a política de version skew do Kubernetes permitir, mantendo o control plane em segurança. Um alerta honesto que vale repetir, e que a própria release reforça: chained upgrade resolve o atraso, mas não substitui o patching frequente. Quem usa o recurso para sair do buraco precisa sair também do hábito de deixar a versão envelhecer.

O que mais mexeu sob o capô: cgroup v2, Git 2.53.0 e a Blackwell no EC2

Em semana curta, os detalhes de baixo nível ganham o palco que normalmente não têm — e três deles importam. O primeiro é uma mudança discreta com efeito real em produção: a nova fórmula de conversão de CPU do cgroup v2. A transição original (KEP-2254) usava uma fórmula linear que convertia 1 CPU de request — cpu.shares = 1024 no cgroup v1 — para um cpu.weight de apenas cerca de 39, contra o padrão de mercado 100 do cgroup v2. Na prática, ao migrar de runtime, seus workloads perdiam força de prioridade contra os daemons do sistema, com risco de resource starvation. A nova fórmula troca a reta por uma curva que mapeia o valor padrão 1024 exatamente para 100 (com 2 mapeando para 1 e 262144 para 10.000). O ponto operacional que merece atenção: a mudança vive no runtime de container (OCI), não no binário do Kubernetes — ela chega no runc a partir da 1.3.2 e no crun a partir da 1.23. Atualizar runtime em produção sem passar por staging, observando workloads de request baixo, é receita de surpresa.

O segundo é o Git 2.53.0, com forte contribuição da engenharia do GitLab e relevância para quem mantém monorepos e pipelines de CI/CD pesados. O destaque é a reconciliação entre geometric repacking e partial clones: antes, esses dois recursos conflitavam, forçando estratégias de repack menos eficientes em repositórios massivos. A 2.53.0 passa a reconhecer e isolar os promisor packfiles, aplicando a progressão geométrica de forma segregada. Para a cadeia de suprimentos de software, veio o modo strip-if-invalid na opção --signed-commits do git-fast-import: em reescritas de histórico em larga escala (típicas do git-filter-repo), o Git agora descarta só as assinaturas que de fato foram invalidadas pela reescrita, preservando as dos objetos intactos — auditabilidade sem o tudo-ou-nada de antes. Há ainda o git repo structure somando o tamanho de objetos alcançáveis, útil para quem faz FinOps de armazenamento de repositório.

O terceiro destaque é o único do lado de hardware bruto: a AWS colocou a arquitetura NVIDIA Blackwell no EC2 com as instâncias G7e em disponibilidade geral, equipadas com GPUs RTX PRO 6000 Blackwell Server Edition. O número que chama atenção é até 2,3x de performance de inferência sobre as G6e, com suporte a até 768 GB de memória de GPU — o suficiente para rodar um modelo de até 70B de parâmetros em precisão FP8 numa única GPU, simplificando arquiteturas que antes exigiam clusters multi-GPU. Na mesma rodada semanal, a AWS soltou os patches trimestrais do Amazon Corretto (versões 25, 21, 17, 11 e 8) e habilitou cross-repository layer sharing no Amazon ECR, que reaproveita camadas comuns entre repositórios via blob mounting — menos tempo de push e menos custo de storage redundante. Detalhe que ainda dói para o Brasil: a expansão do CloudWatch Database Insights chegou a novas regiões (incluindo o México), mas não a São Paulo.

O que levar desta semana

Foi uma semana de poucas manchetes, mas a que veio carrega peso de prazo. A borda do cluster precisa de atenção agora: o Ingress NGINX tem data para virar passivo de segurança — março de 2026 — e tratar isso como manutenção opcional é aceitar risco de continuidade num componente que está em metade dos clusters do mundo. A migração tem caminho, não só ameaça: a Gateway API é testável de graça no kind antes de qualquer mudança real, e o Cluster API v1.12 reduz a dor de operar o ciclo de vida com in-place updates e chained upgrades. E os detalhes de runtime mandam mais do que parecem: a nova fórmula de CPU do cgroup v2 muda a prioridade dos seus pods conforme a versão de runc/crun, e o Git 2.53.0 melhora a vida de quem opera repositórios grandes — nenhum dos dois aparece em keynote, mas ambos aparecem no incidente. No fim, a mensagem de uma semana enxuta é a mais barata de seguir e a mais cara de ignorar: começo de ano é hora de inventário, não de adiar.

Perguntas Frequentes

O Ingress NGINX vai mesmo ser aposentado? Quando e por quê?
Sim. O comunicado conjunto do Kubernetes Steering Committee e do Security Response Committee marcou a aposentadoria oficial do Ingress NGINX para março de 2026. A partir daí, o projeto deixa de receber correção de bugs e patches de segurança. O motivo é estrutural: apesar de sustentar cerca de 50% dos ambientes Kubernetes, ele era mantido por apenas um ou dois voluntários e acumulou um débito técnico de design que virou vetor de vulnerabilidade. Manter um controlador em fim de vida na borda do cluster é exposição de segurança, não só dívida técnica.

Existe um substituto drop-in para o Ingress NGINX?
Não há substituição direta de um para um. A comunidade aponta a Gateway API como evolução natural do Ingress, com um modelo mais expressivo e orientado a papéis (infra, cluster e app). Como destino de implementação, controladores baseados em Envoy e afins — Cilium, Istio, Envoy Gateway, Traefik, Kong — são as opções maduras. A migração exige tempo de engenharia: comece inventariando suas regras e annotations atuais antes de escolher o destino.

Dá para testar a Gateway API sem mexer em produção?
Dá, e é o caminho recomendado para começar. Com o kind (Kubernetes in Docker) mais o cloud-provider-kind, você sobe um cluster local que já provisiona um Gateway API controller e instala as CRDs automaticamente, além de uma GatewayClass pronta. A partir daí você cria recursos Gateway e HTTPRoute e valida o roteamento com curl. É um laboratório de aprendizado, não um ambiente de produção, mas serve para a equipe internalizar o modelo antes da migração real.

O que muda na prática com o Cluster API v1.12?
Duas dores grandes de operar Kubernetes em escala foram atacadas. Os in-place updates permitem alterar uma máquina existente sem destruí-la e recriá-la, útil para mudanças que não exigem drain de nó, como rotação de credenciais e certificados, reduzindo impacto no SLA. Já os chained upgrades deixam você declarar a versão final desejada partindo de uma bem anterior, e o Cluster API computa e executa os passos intermediários. Atenção: chained upgrade não é desculpa para negligenciar o patching frequente.

A nova fórmula de CPU do cgroup v2 pode afetar meus workloads?
Pode, em cenários de disputa de recursos. A fórmula linear anterior convertia 1 CPU de request (1024 shares no cgroup v1) para um cpu.weight de cerca de 39, contra o padrão de mercado 100 do cgroup v2 — ou seja, seus pods perdiam força de prioridade contra daemons do sistema. A nova fórmula usa uma curva que mapeia o valor padrão 1024 exatamente para 100. A mudança vive no runtime de container (OCI), não no Kubernetes: chega no runc a partir da 1.3.2 e no crun a partir da 1.23. Teste em staging antes de atualizar runtime em produção.

Fontes: