Esta semana em cloud (23/fev–01/mar): a borda do cluster recebeu data de validade

TL;DR: A descontinuação do Ingress-NGINX, marcada para março de 2026, virou o assunto operacional da semana: o blog do Kubernetes listou 5 comportamentos que quebram na migração e a Microsoft confirmou o fim do add-on NGINX no AKS, empurrando todo mundo para a Gateway API. No outro eixo, o agente de IA entrou em produção pela porta do MCP — Azure SRE Agent, GitLab Duo com Claude — enquanto Claude 4.6, Gemini 3.1 e Nano Banana 2 renovaram os modelos.

Fevereiro terminou sem keynote de palco grande, mas com um aviso que tem peso de prazo de produção: a borda do cluster — aquela camada de rede que decide quem entra — recebeu data de validade. Na mesma semana, dois movimentos independentes cravaram o ponto. O blog oficial do Kubernetes publicou um guia detalhando os comportamentos do Ingress-NGINX que podem derrubar uma migração mal planejada, e a Microsoft oficializou a descontinuação do add-on de NGINX Ingress no AKS. Os dois apontam para o mesmo destino — a Gateway API — e para o mesmo calendário: março de 2026.

O contraponto da semana veio do outro lado da pilha. Enquanto a infraestrutura de rede entrava em modo de transição, o agente de IA finalmente saiu da apresentação e entrou na operação — e quase sempre pela mesma porta: o Model Context Protocol (MCP). Foi MCP no Azure SRE Agent (PagerDuty, Datadog, Atlassian Rovo), MCP no Azure Logic Apps, MCP no GitLab Duo com Claude, MCP no Bedrock e no Kiro da AWS. O padrão criado pela Anthropic deixou de ser curiosidade de blog e virou o encaixe que conecta a IA à stack que já existe.

A leitura para quem opera infra no Brasil é direta: 2026 não está pedindo paradigmas novos, está cobrando a fatura de maturidade dos antigos. Rede, governança, observabilidade e modelos — todos avançaram na mesma semana, e todos com a mesma exigência de rigor operacional. Quem tratar a saída do NGINX como troca mecânica de controlador, ou o agente de IA como brinquedo de demo, vai descobrir o custo no primeiro incidente.

Por que a saída do Ingress-NGINX não é "só trocar de controlador"?

A descontinuação do Ingress-NGINX, anunciada pelo projeto Kubernetes em novembro de 2025 e marcada para março de 2026, deixou de ser um item distante de roadmap e virou planejamento urgente. O blog oficial do Kubernetes foi cirúrgico ao mostrar por quê: traduzir a configuração para a Gateway API parecendo correto não é garantia de que ela vai se comportar igual. O artigo lista cinco armadilhas, e nenhuma é teórica.

A primeira é o regex: no Ingress-NGINX, matches de expressão regular são por padrão case-insensitive e baseados em prefixo, então um padrão como /[A-Z]{3} casa qualquer caminho que apenas comece com três letras. Implementações de Gateway API sobre Envoy — Istio, Envoy Gateway, Kgateway — fazem o match estrito e sensível ao caso; sem ajustar o padrão para algo como (?i)/[a-zA-Z]{3}.*, requisições que funcionavam viram 404. A segunda é pior por ser invisível: ativar use-regex: "true" num único Ingress contamina todos os outros que compartilham o mesmo hostname, fazendo um path Exact ser tratado como regex prefixado. A terceira é a rewrite-target, que liga o modo regex silenciosamente. A quarta é o redirecionamento automático de trailing slash via 301, que a Gateway API não faz sem um filtro requestRedirect explícito. E a quinta é a normalização de URL conforme a RFC 3986, cujos detalhes variam entre implementações.

A Microsoft acertou o mesmo relógio. A descontinuação do add-on 'Application Routing' baseado em NGINX no AKS — motivada justamente pela depreciação do projeto upstream — encerra as atualizações de suporte em março de 2026, com patches de segurança garantidos só até 30 de novembro de 2026. Para quem roda AKS, isso transforma o NGINX gerenciado de espinha dorsal confortável em dívida com prazo. As alternativas citadas pela própria Microsoft — Application Gateway Ingress Controller, service meshes como Istio ou Linkerd, ou gateways baseados em Envoy — exigem change management de verdade, não um helm upgrade.

O recado para o Brasil, onde estabilidade de produção é inegociável e equipe de plataforma é enxuta, é claro: a janela para fazer isso com calma é agora. A recomendação técnica que se repete nas fontes é começar pelo inventário de annotations e usar o Ingress2Gateway para traduzir o que der, validando comportamento com testes de carga antes de tocar o tráfego real. A migração para Gateway API traz ganho real — separação de papéis entre quem cuida da borda (SRE) e quem define rotas (dev), canary e traffic mirroring nativos, fim do emaranhado de annotations de vendor —, como o próprio caso do SpinKube exposto via Gateway API demonstrou esta semana. Mas é mudança de plano de dados, não de sintaxe.

Precisa planejar a saída do Ingress-NGINX no AKS ou estruturar a migração para Gateway API sem outage? Fale com os especialistas em Cloud Native da Nuvem Online.

O agente de IA entrou na operação — e o MCP foi a fechadura

Se a semana teve um segundo fio condutor, foi este: o agente de IA parou de ser demonstração e virou peça de operação, quase sempre conectado pela mesma interface. O Model Context Protocol (MCP), criado pela Anthropic para padronizar como agentes descobrem e invocam ferramentas externas, apareceu em produto atrás de produto. O Azure SRE Agent ganhou servidores MCP para PagerDuty, Datadog e Atlassian Rovo — permitindo triagem e resolução de incidentes em linguagem natural, sem alternar entre o console do Azure e a ferramenta de on-call. O Azure Logic Apps lançou um assistente que expõe fluxos existentes como servidores MCP, tratando conectores corporativos como ferramentas auto-descobríveis por frameworks de agentes. E a AWS reforçou o padrão no Bedrock, no Kiro e nos novos Agent Plugins.

A camada de plataforma seguiu junto. A GitLab Duo Agent Platform integrou o Claude diretamente na pipeline de DevSecOps, com agentes que vão da issue ao merge request — gerando aplicação full-stack, atuando como revisor de código com análise de segurança e até montando o Dockerfile e o pipeline de CI/CD com push para o registry. O Google, do seu lado, publicou um guia de engenharia para levar agentes à produção que vale como referência de arquitetura: o loop Think → Act → Observe, a camada de orquestração com memória de curto e longo prazo, e os dois protocolos que evitam vendor lock-in — o próprio MCP e o Agent2Agent (A2A), do Google, para comunicação entre agentes.

Mas o anúncio mais honesto da semana não foi de capacidade, foi de disciplina. Um artigo do Google Cloud cravou que basear a confiabilidade de um agente em "vibe checks" — conversar manualmente e achar que "parece certo" — é receita de desastre em escala, porque um prompt com 99% de precisão hoje pode cair para 92% amanhã com um leve shift na distribuição de pesos. A proposta é Continuous Evaluation: dataset versionado como código (prompt, ground truth e trajetória esperada), avaliadores automatizados medindo GROUNDING e TOOL_USE_QUALITY, e shadow deployments no Cloud Run com a flag --no-traffic, onde o pipeline ataca a revisão de sombra e só migra tráfego se os scores passarem. É SRE aplicado a um sistema probabilístico — exatamente a mentalidade que falta na maioria dos PoCs.

Para o decisor brasileiro, a tradução é de custo. Cada uma dessas integrações tem um eixo de FinOps embutido: o QueryPagerDutyIncidentChat consome créditos do PagerDuty Advance, o Provisioned Throughput no Vertex AI exige planejamento de capacidade para não estourar a fatura, e analisar a trajetória do agente — não só o output — é o que evita throughput desnecessário pago em dólar. Agente em produção não é só engenharia, é orçamento.

Quem governa o risco quando a IA escreve o código?

A pergunta deixou de ser retórica nesta semana, e foi a Anthropic quem acendeu o estopim: o anúncio do Claude Code Security, capaz de identificar vulnerabilidades e sugerir correções, fez ações de empresas de cibersegurança oscilarem sob o receio de que a IA tornasse obsoletas as ferramentas tradicionais de AppSec. A resposta mais lúcida veio de um artigo do GitLab, e ela é estrutural: se a segurança fosse só escanear código atrás de falhas, a resposta seria "sim, está com os dias contados". Mas nunca foi.

O argumento se sustenta numa distinção que todo time de plataforma precisa internalizar: um LLM vê o código, uma plataforma vê o contexto. Decisões de risco dependem de variáveis que o modelo isolado não enxerga — quem assinou a mudança, quão crítica é a aplicação, se a vulnerabilidade é explorável em produção ou está numa dependência que nunca executa. Sem esse contexto, a detecção vira ruído e falso positivo, desacelerando o desenvolvimento em vez de protegê-lo. A IA, sozinha, não impõe política corporativa nem define nível de risco aceitável; cabe a humanos estabelecer os guardrails, a segregação de funções e as trilhas de auditoria dentro das quais o agente opera. Confiança em agente autônomo não vem da capacidade de agir, vem da governança clara definida por pessoas.

A mesma lição apareceu vinda do Google, em registro de segurança defensiva: o Google Threat Intelligence Group alertou sobre ataques de destilação, experimentação e integração contra modelos, e a discussão sobre potencializar defensores na cyber kill chain assumiu que o atacante também usa IA. O fio que costura tudo é o mesmo da borda do cluster: scans estáticos não acompanham risco dinâmico. Dependências mudam, ambientes evoluem, e a segurança corporativa exige assurance contínuo embutido no fluxo — não uma foto tirada uma vez. Para quem opera no Brasil, com a LGPD na régua e codebase cada vez mais montado por IA e fontes externas, o recado é que a governança virou pré-requisito de qualquer adoção de agente, não etapa opcional depois do deploy.

A camada de modelos se renovou — e a observabilidade subiu de altitude

Por baixo de toda essa operação, a semana também trocou peças na base. No eixo dos modelos, três movimentos se encaixaram. O Claude Sonnet 4.6 chegou ao Amazon Bedrock entregando inteligência próxima à do Opus 4.6 com custo reduzido — o novo sweet spot de custo-benefício para escalar GenAI sem estourar orçamento. No Google Cloud, Claude Opus 4.6 e Sonnet 4.6 ficaram GA no Vertex AI, reforçando a estratégia multi-model, ao lado do Gemini 3.1 Pro em preview, focado em reasoning complexo e acessível via Gemini API, Android Studio e Gemini CLI. E o Nano Banana 2 levou geração de imagem de nível Pro à velocidade de Flash na Vertex AI, com upscaling 2K/4K, consistência de até 5 personagens e 14 objetos, e — o detalhe que importa para SecOps — procedência via SynthID e Credenciais de Conteúdo C2PA.

A AWS completou o quadro de infraestrutura para essa carga: instâncias EC2 Hpc8a com AMD EPYC de 5ª geração entregando até 40% mais performance e networking de 300 Gbps via Elastic Fabric Adapter, SageMaker Inference com auto-scaling e concorrência configuráveis para modelos Nova customizados, e criptografia server-side por padrão em todos os novos clusters Aurora. São as fundações que tornam o modelo do parágrafo anterior viável em produção, não só em notebook.

E a observabilidade subiu de altitude para acompanhar. O Grafana 12.4 foi a peça mais concreta: amadureceu o Git Sync (autenticação via GitHub App, seleção de branch alinhada a CI/CD) para tratar dashboard como código, lançou os Dynamic Dashboards baseados na biblioteca Scenes — abas flexíveis, show/hide de painéis por variável, auto grid layout — e, no eixo de identidade, levou o provisionamento via SCIM a GA no Cloud e Enterprise, eliminando o gargalo do primeiro login e automatizando o offboarding de acesso. No horizonte mais especulativo, o debate da Grafana Labs sobre IA agêntica na observabilidade apontou para o próximo passo: agentes que fazem root cause analysis sobre grafos de dependência e, citando as evidências do próprio raciocínio (grounding), reduzem o MTTR sem que o engenheiro precise confiar cegamente. Mesmo padrão da seção anterior: a IA só entra em produção quando prova o que afirma.

O que levar desta semana

A virada de fevereiro para março não trouxe um paradigma — trouxe quatro contas de maturidade vencendo ao mesmo tempo. Rede: o Ingress-NGINX tem data de validade em março de 2026, no upstream e no AKS, e migrar para Gateway API é mudança de comportamento do plano de dados, não de sintaxe — inventarie annotations e teste antes. Operação com IA: o agente entrou em produção pela porta do MCP, mas só com Continuous Evaluation e shadow deployment ele para de pé; vibe check não escala. Governança: quando a IA escreve o código, quem governa o risco é a plataforma que vê o contexto, não o LLM que vê o trecho — e isso virou pré-requisito, não opcional. Base: Claude 4.6, Gemini 3.1 e Nano Banana 2 renovaram os modelos, mas é a infra em volta — EC2 HPC, SageMaker, Grafana 12.4 com GitOps e SCIM — que separa demo de plataforma. Quem operar essas quatro frentes com disciplina colhe a inteligência sem pagar com estabilidade. Quem só consumir os anúncios vai descobrir, no primeiro 404 da borda ou na primeira fatura de inferência, que IA em produção é, antes de tudo, infraestrutura cloud native bem operada.

Perguntas Frequentes

O Ingress-NGINX vai mesmo ser descontinuado? Quando preciso migrar?
Sim. O projeto Kubernetes anunciou em novembro de 2025 que descontinua oficialmente o Ingress-NGINX em março de 2026. Quem usa o add-on gerenciado no AKS tem um prazo paralelo: a Microsoft encerra as atualizações de suporte em março de 2026 e garante apenas patches de segurança até 30 de novembro de 2026. O destino recomendado é a Gateway API, mas a migração não é troca de sintaxe YAML — comece pelo inventário de annotations e teste com o Ingress2Gateway antes de mexer em produção.

Por que a migração para Gateway API pode causar outage se eu só traduzir as regras?
Porque o Ingress-NGINX tem comportamentos implícitos que a Gateway API não reproduz. O blog do Kubernetes listou cinco: regex que casa por prefixo e é case-insensitive (vira 404 em implementações Envoy estritas), a annotation use-regex que vaza para todos os Ingresses do mesmo host, o rewrite-target que liga regex silenciosamente, o redirecionamento automático de trailing slash via 301 e a normalização de URL. Cada um desses precisa ser reescrito explicitamente em HTTPRoute, ou tráfego legítimo passa a falhar.

O que é o MCP e por que ele apareceu em tantos produtos esta semana?
O Model Context Protocol (MCP), criado pela Anthropic, padroniza como agentes de IA descobrem e invocam ferramentas e fontes de dados externas, evitando integração customizada para cada serviço. Esta semana ele virou a cola entre operação e IA: o Azure SRE Agent ganhou servidores MCP para PagerDuty, Datadog e Atlassian Rovo; o Azure Logic Apps lançou um assistente para expor fluxos como servidores MCP; e a AWS reforçou o padrão no Bedrock e no Kiro. É o protocolo que tira o agente da demo e o pluga na stack real.

Claude Sonnet 4.6, Gemini 3.1 Pro e Nano Banana 2 — o que mudou de fato?
Claude Sonnet 4.6 chegou ao Amazon Bedrock entregando inteligência próxima ao Opus 4.6 com custo menor, e Claude Opus 4.6 e Sonnet 4.6 ficaram GA no Vertex AI. O Gemini 3.1 Pro entrou em preview no Vertex AI e no Gemini Enterprise com foco em reasoning complexo. O Nano Banana 2 trouxe geração de imagem de nível Pro com velocidade de Flash, com upscaling 2K/4K, consistência de até 5 personagens e 14 objetos, SynthID e Credenciais de Conteúdo C2PA para procedência.

Grafana 12.4 muda alguma coisa para quem opera observabilidade no Brasil?
Muda o eixo de governança. O Grafana 12.4 amadureceu o Git Sync (autenticação via GitHub App, seleção de branch melhor) para tratar dashboards como código, lançou os Dynamic Dashboards baseados em Scenes (abas flexíveis, show/hide por variável, auto grid) e levou o provisionamento de usuários via SCIM a GA no Cloud e Enterprise. Para quem escala em multi-cloud, é a chance de tirar dashboard da UI manual e colocá-lo no fluxo de GitOps, com offboarding de acesso automático.

Fontes: