Esta semana em cloud (16–22/mar): a véspera da KubeCon e o relógio do Ingress-NGINX

TL;DR: Foi a semana de véspera da KubeCon Europe: a CNCF publicou os deep-dives dos eventos co-localizados (KyvernoCon, CiliumCon, Platform Engineering, Soberania) e o Ingress2Gateway 1.0 transformou a aposentadoria do Ingress-NGINX, marcada para março de 2026, em tarefa com prazo. Em paralelo, GKE Inference Gateway, Valkey 9.0 e o NVIDIA GTC mostraram a fatura de IA na infra, enquanto ransomware e o exploit DarkSword reforçaram que resiliência virou pré-requisito.

A KubeCon + CloudNativeCon Europe começa dia 23 de março em Amsterdã, e a semana que a antecede tem um ritmo próprio: a CNCF abre a agenda dos eventos co-localizados, e cada deep-dive funciona como um mapa de prioridades da comunidade para o ano. Desta vez o mapa veio nítido — KyvernoCon, CiliumCon, Platform Engineering Day e Open Sovereign Cloud Day, quatro eixos que dizem onde o cloud native acha que está o trabalho pesado de 2026.

Mas a notícia que dá urgência a todo o resto não saiu de um palco de conferência. Foi o lançamento do Ingress2Gateway 1.0, no blog do Kubernetes, porque ele coloca prazo numa decisão que muita gente vinha empurrando: a aposentadoria do Ingress-NGINX, oficializada para março de 2026. A borda do cluster, aquela camada que decide quem entra, deixou de ser plumbing comoditizado e voltou a ser pauta de arquitetura.

Por baixo dessas duas frentes corre a mesma corrente que move o setor inteiro: a IA generativa não pediu paradigmas novos, ela cobrou maturidade nos antigos. Rede, governança, custo e segurança — os mesmos pilares de sempre, agora com uma fatura de inferência pendurada em cada um. E, do lado adversário, ransomware e exploits de iOS deixaram claro que a janela para reagir encolheu. A leitura para quem opera infra no Brasil é direta: a semana foi um inventário do que precisa estar de pé antes de a IA virar produção.

Por que o Ingress2Gateway 1.0 é o anúncio mais operacional da semana?

Porque ele tem data. A aposentadoria do Ingress-NGINX foi oficializada para março de 2026, e isso transforma uma migração que parecia opcional em risco de segurança concreto: um controlador de entrada em fim de vida, exposto na borda do cluster, é superfície de ataque sem dono. O Ingress2Gateway 1.0, lançado nesta semana, é a resposta da comunidade para o gap operacional dessa transição.

Convém ser honesto sobre o que a ferramenta é e o que ela não é. Ela não é um "um clique e pronto". É um assistente de migração que faz duas coisas bem: inventário e tradução de manifestos. A melhoria crítica do 1.0 é o suporte expandido a mais de 30 annotations comuns do Ingress-NGINX — CORS, backend TLS, path rewriting — exatamente as configurações proprietárias que tornavam o Ingress legado difícil de abandonar. O comando ingress2gateway print --providers=ingress-nginx gera um template de Gateway API, mas o sucesso depende de ler os logs de erro, não de confiar no output.

Três pontos merecem disciplina de quem opera produção no Brasil. Primeiro, a ferramenta valida comportamento em tempo de execução, não só YAML — porque validação estática de manifesto não pega o que quebra em runtime. Segundo, ela emite warnings explícitos sobre o que não traduziu (proxy-body-size, timeouts, normalização de URL); tratar esse output como definitivo é receita de incidente. Terceiro, nunca troque o controlador de uma vez: use weighted DNS ou traffic shifting no load balancer para deslocar tráfego gradualmente. O objetivo final não é só migrar — é eliminar a dependência de annotations customizadas e adotar as políticas nativas da Gateway API, removendo dívida técnica em vez de transportá-la.

Precisa planejar a saída do Ingress-NGINX antes do prazo de 2026 ou validar uma migração segura para a Gateway API? Fale com os especialistas em Cloud Native da Nuvem Online.

A agenda da KubeCon: governança, eBPF e plataforma como os eixos do ano

Os deep-dives co-localizados publicados pela CNCF nesta semana são, na prática, a declaração de prioridades da comunidade. E o que eles dizem, juntos, é que a fase do "como adotar" acabou — o assunto agora é "como escalar com disciplina".

O eixo de governança aparece duas vezes, o que não é coincidência. A KyvernoCon marca a transição de firewalls perimetrais para um modelo de Policy-as-Code (PaC) nativo no orquestrador, e o tema técnico central é a integração de políticas ao ciclo de desenvolvimento — o shift-left, onde pipelines de CI/CD validam artefatos contra políticas do Kyverno antes do deployment, não só em runtime. O artigo de aprofundamento sobre o projeto reforça a aposta na CEL (Common Expression Language), que dá lógica complexa sem a barreira de aprender Rego, e detalha o full stack de automação: além de Validate, o Kyverno faz Mutate (correções automáticas), Generate (criação de recursos anexos como NetworkPolicy de default deny) e Cleanup. É governança declarativa em YAML nativo, versionada no Git.

O eixo de rede é a CiliumCon, que celebra uma década do projeto. A leitura aqui é de maturidade: o Cilium deixou de ser promessa e virou o CNI de referência, e a versão v1.19 reforça observabilidade com flow aggregation — visibilidade granular para FinOps e SecOps sem sacrificar throughput. O destaque é o Tetragon redefinindo segurança em tempo de execução via eBPF, com casos como o da Roche validando a substituição de appliances legados de load balancer. Para quem opera multi-cluster no Brasil, é a chance de unificar observabilidade e segurança numa única stack e reduzir o número de agentes privilegiados rodando nos nós.

Os dois eixos restantes fecham o quadro estratégico. O Platform Engineering Day, em sua quinta edição, consolidou a engenharia de plataforma como alicerce — não mais "manter clusters estáveis", mas construir Internal Developer Platforms (IDPs) com abstrações inteligentes e guardrails nativos, tratando a plataforma como um produto para o desenvolvedor. E o Open Sovereign Cloud Day inverteu a perspectiva: partir do objetivo de soberania para desenhar o deployment, repensando IAM, persistência e observability — com o open source como camada de proteção contra o vendor lock-in. Essa última pauta ressoa especialmente aqui: portabilidade de workload e controle sobre onde o dado trafega deixaram de ser discussão política para virar requisito de engenharia.

A conta da IA não vem em GPU: inferência, custo e o stack que a sustenta

Enquanto o holofote fica no modelo, o gargalo real está na infraestrutura ao redor — e a semana entregou peças concretas desse quebra-cabeça. A primeira é o multi-cluster GKE Inference Gateway, que estende a Gateway API para tratar vários clusters do Google Kubernetes Engine como um pool unificado de inferência. O diferencial não é load balancing por latência, e sim roteamento model-aware: via GCPBackendPolicy e métricas customizadas como o estado da KV cache, o tráfego vai para o backend mais preparado naquele milissegundo. Os CRDs InferencePool (agrupa pods com o mesmo perfil de hardware) e InferenceObjective (define prioridades, separando tarefas sensíveis a latência das de batch) resolvem o gargalo do cluster único — falha regional, escassez de GPU/TPU numa zona, silos de hardware — com bursting entre clusters.

A segunda peça veio do NVIDIA GTC 2026, onde o Google detalhou a evolução do AI Hypercomputer. O anúncio mais relevante para FinOps são as G4 VMs fracionadas (em preview), que usam vGPU para particionar a GPU em frações de 1/2, 1/4 e 1/8 — combinadas com container binpacking no GKE, é o right-sizing definitivo para inferência e transcoding, em vez de superdimensionar ambientes. Há ainda as G4 VMs completas com NVIDIA RTX Pro 6000 e precisão FP4, e o roadmap para a plataforma Vera Rubin NVL72 (sucessora da Blackwell), que sinaliza onde estará o gargalo do futuro: não a GPU isolada, mas a largura de banda de interconexão e o plano de controle definido por software.

A terceira peça é menos glamourosa e mais imediata: a GA do Valkey 9.0 no Memorystore. Caching e mensageria são o tecido conjuntivo de qualquer arquitetura de baixa latência, e a versão 9.0 entrega ganhos de hardware reais — pipeline memory prefetching (até 40% mais throughput), zero copy responses (até 20% em requisições grandes) e otimizações SIMD que chegam a 200% em operações como BITCOUNT e HyperLogLog. Para o desenvolvedor, novidades como HEXPIRE (TTL por campo de hash), consultas geoespaciais por polígono e o DELIFEQ para distributed locking seguro eliminam workarounds em Lua. O ponto que importa para o Brasil, num cenário de tráfego volátil em e-commerce e finanças: upgrades in-place sem downtime, num projeto aberto, removem a maior barreira de adoção. É a mesma lição do resto da semana — a IA cobra que a base de dados, cache e rede esteja afiada antes de o modelo entrar.

Resiliência virou pré-requisito: ransomware acelerando e o exploit DarkSword

Nenhuma dessas frentes importa se o adversário chegar primeiro — e dois relatórios da semana mostraram que a janela para reagir encolheu. A análise de ransomware de 2025 do Google Threat Intelligence Group traz um paradoxo: apesar de um recorde de vítimas publicadas em Data Leak Sites (alta de 50% ante 2024, com novos players como Qilin e Akira ocupando o vácuo de LockBit e ALPHV), a lucratividade caiu, porque mais empresas conseguem restaurar a partir de backups. A resposta dos atacantes foi mudar de tática: 77% dos ataques envolveram roubo de dados (contra 57% em 2024), e o foco em virtualização — automatizar o desligamento de VMs, habilitar SSH no ESXi e deletar snapshots e backups — chegou a 43% dos incidentes. O vetor de entrada preferencial segue sendo a exploração de CVEs em VPNs e firewalls (Fortinet, SonicWall, Palo Alto, Citrix), agora com uso mais frequente de zero-days.

A prova viva desse último ponto foi o DarkSword, exploit chain full-chain para iOS documentado pelo mesmo GTIG. Ele combina seis vulnerabilidades zero-day para comprometer dispositivos em nível de kernel, é compatível com iOS 18.4 a 18.7 e, desde novembro de 2025, foi adotado por fornecedores de vigilância comercial e grupos suspeitos de espionagem estatal — com campanhas ativas mapeadas na Ucrânia, Arábia Saudita, Turquia e Malásia. Três famílias de malware (GHOSTBLADE, GHOSTKNIFE, GHOSTSABER) operam após o comprometimento. A Apple corrigiu as falhas no iOS 26.3, e a recomendação é patching imediato; onde isso não for possível, o Lockdown Mode é a mitigação primária.

A conclusão amarra as duas frentes e o resto da semana: resiliência operacional é o melhor inibidor de resgate, e isso é decisão arquitetural, não reação. Backups imutáveis ou isolados retiram a alavancagem do criminoso; patching rápido fecha a porta de entrada; e a postura de assume breach — monitorar comportamento anômalo, isolar o que é crítico — é mandatória para quem opera com exposição global. É o complemento natural da pauta de governança da KubeCon: Policy-as-Code de pouco adianta se o backup e o hypervisor estiverem desprotegidos.

O que levar desta semana

A véspera da KubeCon não trouxe paradigma novo — trouxe a fatura de maturidade de quatro frentes que já existiam, agora com prazo. Rede: o Ingress-NGINX tem data de aposentadoria (março de 2026) e o Ingress2Gateway 1.0 é o ferramental para sair com método, não no susto — tratar isso como troca mecânica de controlador é desperdiçar a chance de adotar a Gateway API nativa. Governança e cultura: os deep-dives da CNCF (Kyverno em PaC, Cilium/Tetragon em eBPF, Platform Engineering como produto, soberania como requisito) são o mapa do que a comunidade vai cobrar maturidade neste ano. IA na infra: GKE Inference Gateway, G4 fracionadas e Valkey 9.0 mostram que a conta da IA é de rede, custo e dados afiados, não de GPU isolada. Segurança: ransomware mirando virtualização e o DarkSword provam que resiliência — backup imutável, patching rápido, assume breach — é o pré-requisito que sustenta todo o resto. Quem entrar na KubeCon com essas frentes em ordem colhe a inteligência sem pagar a estabilidade. Quem só assistir ao keynote vai descobrir, no primeiro incidente ou na primeira fatura, que IA em produção é, antes de tudo, infraestrutura cloud native bem operada.

Perguntas Frequentes

O Ingress-NGINX vai ser descontinuado mesmo? Tenho que migrar agora?
Sim. A aposentadoria do Ingress-NGINX foi oficializada para março de 2026, e manter um controlador de borda em fim de vida é exposição de segurança, não só dívida técnica. O lançamento do Ingress2Gateway 1.0 nesta semana endereça o gap de migração: ele faz inventário e traduz manifestos, com suporte expandido a mais de 30 annotations comuns do Ingress-NGINX (CORS, backend TLS, path rewriting). Mas não é botão mágico — comece pelo inventário de annotations e valide o comportamento, não só o YAML.

O Ingress2Gateway 1.0 migra tudo automaticamente?
Não. A própria ferramenta emite warnings sobre o que não pôde ser traduzido — por exemplo proxy-body-size, timeouts e normalização de URL — e a validação manual é obrigatória. O recomendado é nunca trocar o controlador de uma vez: use weighted DNS ou traffic shifting no load balancer para migrar tráfego gradualmente. O objetivo final é remover a dependência de annotations customizadas e adotar as políticas nativas da Gateway API, reduzindo dívida técnica futura.

Por que a CNCF publicou tantos artigos de evento nesta semana?
Porque a KubeCon + CloudNativeCon Europe 2026 acontece em Amsterdã a partir de 23 de março, e a fundação usa a semana anterior para divulgar os deep-dives dos eventos co-localizados (KyvernoCon, CiliumCon, Platform Engineering Day, Open Sovereign Cloud Day). É um mapa de prioridades: governança via Policy-as-Code, rede via eBPF, plataformas internas e soberania digital são os eixos que a comunidade elegeu para o ano.

O que muda na prática com o GKE Inference Gateway multi-cluster?
Ele estende a Gateway API para tratar vários clusters GKE como um pool unificado de inferência. Em vez de load balancing só por latência, o roteamento é model-aware: via GCPBackendPolicy e métricas customizadas como o estado da KV cache, o tráfego vai para o backend mais preparado naquele milissegundo. Resolve o gargalo do cluster único — falha regional, escassez de GPU/TPU numa zona e silos de hardware — com bursting entre clusters e alta disponibilidade global.

Qual a lição de segurança da semana para quem opera infraestrutura?
Que resiliência operacional é o melhor inibidor de resgate. A análise de ransomware de 2025 mostrou que 77% dos ataques envolveram roubo de dados e 43% miraram virtualização (ESXi), com automação de deleção de snapshots e backups para piorar o RTO. Em paralelo, o exploit chain DarkSword provou que zero-days de iOS viraram commodity de vigilância. A defesa é arquitetural: backups imutáveis ou isolados, patching rápido e a postura de assume breach.

Fontes: