Esta semana em cloud (27/jul–02/ago): o Kubernetes começou a remover o que você ainda usa

Q: O que muda para static pods no v1.37?

Static pods deixam de poder referenciar Secrets e ConfigMaps via `configMapRef` ou `secretRef`. A premissa é que um pod gerenciado pelo kubelet a partir de arquivo no disco não deveria ler recursos da API — e o feature gate transitório `PreventStaticPodAPIReferences` foi removido, o que torna o comportamento definitivo. Na prática isso atinge quem montou control plane ou daemons de nó com manifests estáticos que puxavam configuração da API. A correção é materializar a configuração no próprio arquivo do static pod ou promover o componente a um DaemonSet de verdade.

Q: Densidade de agentes é mesmo um problema de plataforma e não de modelo?

Os números do GKE sugerem que sim. Partindo de um baseline de 61 agentes por nó com microVMs, o Agent Sandbox (isolamento em user-space via gVisor) chega a 88; com warm pools em perfil de performance, 133; e em perfil otimizado para custo, 274 agentes — mais de 3,5x o baseline, com startup abaixo de 5 segundos e custo por agente até 75% menor. O truque não está no modelo: está em suspender agente ocioso via pod snapshot, devolvendo CPU e memória ao cluster, com restore em milissegundos. É decisão de orquestração, tomada por time de plataforma.

Q: Por que meu scale-to-zero nunca funciona de verdade?

Provavelmente porque suas próprias sondas estão acordando o serviço. O material da CNCF sobre o ProbeResponse do KubeElasti descreve o ciclo: load balancer, service mesh e monitoramento externo batem no health check, o tráfego chega ao resolver, o resolver escala o pod para atender — e o workload nunca fica genuinamente idle. A correção é responder à sonda no próprio resolver com 200 OK, sem disparar scale-up. Para quem paga GPU por hora ou licença por instância ativa, a diferença entre 'quase zero' e zero é a fatura inteira.

Q: Vale a pena adotar Fleet Manager ou multicluster mesh agora?

Vale quando o número de clusters passa do que uma pessoa consegue atualizar na mão — e a resposta certa depende do que você quer federar. O Resource Placement do Azure Kubernetes Fleet Manager entrou em GA para distribuir e manter recursos consistentes entre clusters, e o novo Maximum Allowed Failures (em preview) resolve um problema operacional concreto: uma falha pontual em dois clusters travar o rollout da frota inteira. Já a extensão multicluster do Linkerd resolve outra camada — tráfego entre clusters, com escolha por serviço via label entre modo federado (failover automático), flat mirror e gateway mirror. Frota e malha são complementares, não substitutas.

Banner - Esta semana em cloud (27/jul–02/ago): o Kubernetes começou a remover o que você ainda usa

TL;DR — O sneak peek do Kubernetes v1.37 é uma lista de remoções, não de features: kube-proxy em modo IPVS foi deprecado, cgroup v1 já derruba o kubelet por padrão e static pods perderam acesso a Secrets. Na mesma semana, GKE mostrou 274 agentes por nó com gVisor e snapshots, a CNCF aceitou o CoHDI e o AKS ganhou frota e imagens pré-preparadas. A dívida de plataforma venceu — e cobrar inventário é tarefa de agora.

Toda semana o feed de cloud entrega alguma coisa nova para instalar. Esta entregou uma lista do que desinstalar — e essa é a notícia mais consequente do período para quem opera Kubernetes em produção no Brasil.

Na quinta-feira, o projeto Kubernetes publicou o sneak peek do v1.37. Diferente do que circulou em resumos de segunda mão, o post não é sobre GPUs nem sobre IA: é um aviso de deprecações e remoções. E o item mais pesado dessa lista está no caminho crítico de rede de muitos clusters brasileiros.

O que o v1.37 está tirando do seu cluster?

Quatro mudanças, em ordem de dor:

Mudança	Estágio	Prazo publicado
`kube-proxy` em modo `ipvs`	Deprecado (KEP-5495)	Desabilitado por padrão no v1.40; removido no v1.43
Static pods com `secretRef`/`configMapRef`	Removido	Já no v1.37 — gate `PreventStaticPodAPIReferences` eliminado
cgroup v1	Em remoção	`failCgroupV1` já é `true` por padrão desde o v1.35
`kubectl run --filename/-f`	Deprecado	—

O caso do IPVS merece atenção especial porque a justificativa é estrutural: a API de IPVS do kernel não consegue implementar por completo a semântica de Services do Kubernetes. Não é abandono por falta de mantenedor, é reconhecimento de que o modelo não fecha. Quem escolheu IPVS anos atrás por causa de degradação do iptables em clusters com muitos Services está com uma migração no horizonte — para nftables ou para um data plane em eBPF — e o prazo, embora confortável, já está datado.

O item do cgroup v1 é mais silencioso e mais perigoso: ele não espera o v1.37. Desde o v1.35, o kubelet falha ao iniciar em nó com cgroup v1, a menos que alguém tenha colocado failCgroupV1: false na configuração como paliativo. Se esse override existe no seu ambiente, ele é uma dívida com data de vencimento, não uma solução.

A leitura honesta: o Kubernetes está fechando o ciclo de compatibilidade da década anterior. Isso é saudável para o projeto e desconfortável para quem tratou upgrade como tarefa de manutenção, e não como produto interno. Se você mantém uma camada de roteamento herdada, o mesmo raciocínio se aplica ao Ingress — o caminho de saída para o Gateway API como substituto do nginx-ingress é a mesma conversa, um andar acima.

Por que a IA está reformando a plataforma por baixo?

Enquanto o núcleo remove, as bordas empurram. E o empurrão desta semana veio todo do mesmo lugar: densidade.

O Google publicou os números do GKE Agent Sandbox e eles são específicos o suficiente para servir de referência de arquitetura. Partindo de 61 agentes por nó com microVMs, o Agent Sandbox — isolamento em user-space com gVisor, em GA desde maio — leva a 88. Com warm pools em perfil de performance, 133. Em perfil otimizado para custo, 274 agentes no mesmo hardware: mais de 3,5x o baseline, startup abaixo de 5 segundos e custo por agente até 75% menor. O componente que faz a diferença é o pod snapshot: congelar o agente ocioso, devolver CPU e memória ao cluster, restaurar em milissegundos.

Na CNCF, o CoHDI entrou como projeto Sandbox atacando o mesmo problema pelo hardware. Usando Dynamic Resource Allocation, ele anexa e desanexa dispositivos PCIe — GPUs, principalmente — a nós sem reboot. A consequência prática para quem roda inferência é alocar recurso por fase da carga (prefill e decode têm perfis diferentes) em vez de dimensionar o nó pelo pico.

E a CNCF publicou também o diagnóstico mais irônico da semana: suas health checks estão sabotando seu scale-to-zero. Load balancer, service mesh e monitoramento externo batem na sonda, o tráfego chega ao resolver, o resolver acorda o pod — e o workload nunca fica realmente ocioso. O ProbeResponse do KubeElasti responde à sonda no próprio resolver, com 200 OK, sem disparar scale-up. Para quem paga GPU por hora, a diferença entre "quase zero" e zero é a fatura inteira. Vale como complemento a quem já levou KEDA e HPA do lab para produção — e a CNCF reforçou o argumento com um guia de escala por profundidade de fila do Amazon SQS, onde CPU e memória simplesmente não representam a pressão real do sistema.

Do lado do AKS, a Prepared Image Specification (preview) ataca o mesmo gargalo pela inicialização: imagens de node pré-configuradas com container images e tarefas de bootstrap embutidas, para cargas de GPU, IA e Windows. O caso da Subaru, apresentado na CNCF, mostra o tamanho do problema quando ignorado: pull de imagens de mais de 30 GB caiu de 3 horas para 3 minutos depois do redesenho de rede e padronização de deploy.

Quer saber quanto do seu cluster está preso em compatibilidade antiga? Podemos levantar isso com você.

A frota virou a unidade de operação?

Se a unidade desceu do nó para o dispositivo, ela também subiu do cluster para a frota.

O Azure Kubernetes Fleet Manager levou o Resource Placement para GA — distribuição e consistência de recursos entre múltiplos clusters sem aplicação manual — e adicionou em preview o Maximum Allowed Failures, que resolve uma dor bem específica de quem opera dezenas de clusters: hoje, uma falha pontual em dois deles trava o update run inteiro. Poder tolerar um percentual de falha antes de abortar é a diferença entre atualizar a frota semanalmente e adiar o upgrade por trimestres.

A CNCF cobriu a camada de tráfego com um guia prático de Linkerd multicluster, e a parte útil é a taxonomia: modo federado (failover automático entre clusters), flat mirror (roteamento explícito, para data locality) e gateway mirror (conectividade sem rede plana entre clusters). A escolha é por serviço, via label, e os três modos coexistem na mesma malha. Isso desmonta a falsa escolha entre "federar tudo" e "não federar nada".

Frota e malha resolvem problemas diferentes — configuração e tráfego — e quem tenta usar uma para fazer o trabalho da outra normalmente descobre o erro durante um incidente.

O que mais mereceu atenção

Segurança. O Cloud KMS colocou em GA as assinaturas digitais pós-quânticas ML-DSA e SLH-DSA, incluindo variantes external-µ que evitam o gargalo de banda típico de PQC ao assinar grandes volumes. A inteligência de ameaças do Google publicou orientação sobre a escalada de ataques à cadeia de suprimentos em PyPI, npm e Docker Hub, com um conjunto de defesas que dá para começar já: SBOM, período de cooldown antes de adotar versão nova de pacote, isolamento de pipeline e tokens de curta duração. E a Best Buy detalhou a eliminação de service accounts via workforce identity federation — o padrão que troca credencial estática por identidade federada e auditoria individualizada, tema que já tratamos em IAM unificado sem lock-in.

Rede. Três movimentos práticos: NAT64 no NAT Gateway StandardV2 da Azure, que permite sair com IPv6 sem exigir dual-stack completo até o destino; Route-Maps no Azure Route Server (preview), com filtragem e modificação de rotas BGP em cenário híbrido — leia-se: menos risco de blackholing; e resolução de DNS bidirecional privada entre Azure e OCI para Exadata dedicado, eliminando forwarders e zonas mantidos à mão entre nuvens.

Custo. O Google Cloud adicionou detecção precoce de anomalias e spend caps no Billing, com bloqueio automático ao atingir o limite — defesa direta contra o pico de gasto de IA que só aparece na fatura. A Azure anunciou que, a partir de fevereiro de 2027, acaba a troca de reservas para serviços cobertos por savings plans; quem trata reserva como instrumento flexível precisa refazer a conta agora. E uma análise de token economics colocou número na intuição: a mesma tarefa pode variar até 30x em custo por conta da variabilidade estocástica do agente, o que torna "preço por token" uma métrica enganosa frente a custo por tarefa aceita.

O que isso muda para quem opera infra no Brasil?

Três tarefas que cabem numa segunda-feira:

Levante o inventário de remoção. Modo do kube-proxy, presença de failCgroupV1: false, static pods lendo Secrets. São três comandos e definem o tamanho do seu próximo ciclo de upgrade.
Meça densidade antes de comprar nó. Se a resposta padrão para carga de IA é adicionar máquina, os números do GKE mostram que há 3x de folga em orquestração — e o scale-to-zero que "não funciona" provavelmente está sendo acordado pela sua própria sonda.
Trate upgrade como produto, não como manutenção. O prazo do IPVS é confortável só para quem começar a olhar agora. Quem descobrir a deprecação no dia do upgrade vai pagar em janela de indisponibilidade.

O tema de fundo é o mesmo que a comunidade vem chamando de dívida operacional cloud native: durante anos foi mais barato adicionar uma peça do que remover uma. Esta semana o projeto começou a remover pelas duas pontas — o que é obsoleto embaixo e o que é desperdício em cima. A conta chega para quem não tem inventário.

Perguntas Frequentes

Meu cluster roda kube-proxy em modo IPVS. Preciso migrar amanhã?
Amanhã não, mas o prazo está publicado. O KEP-5495 deprecia o modo ipvs no v1.37; a expectativa registrada é que seja desabilitado por padrão no v1.40 (ainda selecionável por feature gate) e removido no v1.43. O motivo é técnico: a API de IPVS do kernel não implementa por completo a semântica de Services. Descubra seu modo atual com kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:' e planeje a saída para nftables ou eBPF. Quem adotou IPVS por escala de Services precisa validar comportamento sob carga antes do upgrade, não durante.

O que muda para static pods no v1.37?
Eles deixam de poder referenciar Secrets e ConfigMaps via configMapRef ou secretRef. A premissa é que um pod lido do disco pelo kubelet não deveria depender da API — e o feature gate transitório PreventStaticPodAPIReferences foi removido, tornando o comportamento definitivo. Atinge principalmente control planes e daemons de nó montados com manifests estáticos. A correção é materializar a configuração no próprio arquivo ou promover o componente a DaemonSet.

Densidade de agentes é mesmo um problema de plataforma e não de modelo?
Os números do GKE sugerem que sim: de 61 agentes por nó com microVMs para 88 com Agent Sandbox (gVisor), 133 com warm pools em perfil de performance e 274 em perfil otimizado para custo — startup abaixo de 5 segundos e custo por agente até 75% menor. O ganho vem de suspender agente ocioso via pod snapshot e restaurar em milissegundos. É decisão de orquestração, não de escolha de modelo.

Por que meu scale-to-zero nunca funciona de verdade?
Porque suas próprias sondas acordam o serviço. Load balancer, service mesh e monitoramento batem no health check, o tráfego chega ao resolver e o pod sobe para responder — o workload nunca fica genuinamente idle. O ProbeResponse do KubeElasti responde à sonda no resolver, com 200 OK, sem disparar scale-up. Para quem paga GPU por hora ou licença por instância ativa, a diferença entre "quase zero" e zero é a fatura inteira.

Vale a pena adotar Fleet Manager ou multicluster mesh agora?
Vale quando o número de clusters passa do que uma pessoa atualiza na mão — e depende do que você quer federar. O Resource Placement do Fleet Manager (GA) mantém recursos consistentes entre clusters, e o Maximum Allowed Failures (preview) evita que falha pontual trave o rollout da frota. A extensão multicluster do Linkerd resolve outra camada: tráfego entre clusters, com escolha por serviço via label entre modo federado, flat mirror e gateway mirror. São complementares, não substitutas.

Fontes: