DevOps · 01/06/2026

Kubernetes 1.36: Mixed Version Proxy em Beta Resolve o Problema Real de Convergência Durante Upgrades de Planos de Controle

A evolução do Mixed Version Proxy de Alpha para Beta em Kubernetes 1.36 substitui StorageVersion API por Aggregated Discovery, eliminando requisições falsas 404 durante upgrades com múltiplas versões de API servers. O impacto: mudança fundamental em como sincronizar estado em clusters heterogêneos.

O que está acontecendo

Kubernetes 1.36 ativa por padrão o Mixed Version Proxy em Beta, fechando um gap de dois anos desde sua introdução como Alpha em 1.28. O problema que resolve é específico: durante upgrades do plano de controle, múltiplos API servers rodando versões diferentes servem conjuntos distintos de recursos. Um cliente que envia uma requisição para um endpoint novo (ex: uma CRD ou versão de API introduzida na versão mais recente) pode cair em um API server antigo que retorna 404 Not Found—tecnicamente falso, pois o recurso existe em outro servidor.

Este comportamento cascata em operações destrutivas: garbage collection mal interpretado, namespace deletion bloqueada, ou falhas silenciosas em aplicações que cachear respostas. A solução original em 1.28 usava StorageVersion API para descobrir quais peers serviam quais recursos. Beta abandona isso por Aggregated Discovery, um mecanismo que os próprios API servers já usam para sincronizar capacidades entre pares.

O segundo componente é Peer-Aggregated Discovery: discovery requests (ex: kubectl api-resources) agora refletem a visão completa do cluster, não apenas do servidor local. Um cliente consulta um API server e recebe a union de todos os recursos disponíveis no plano de controle, não apenas os que esse servidor específico conhece.

Insights e Riscos

• Eliminação de StorageVersion como fonte de verdade: StorageVersion API nunca suportou CRDs e APIs agregadas (exemplo: Kubernetes aggregation layer, ou APIs de terceiros). Migrar para Aggregated Discovery resolve essa lacuna arquitetural, mas redistribui a carga de discovery para cada servidor.

• Trade-off de latência vs correção: Aggregated Discovery requer que cada API server consulte seus peers para compilar a lista completa de recursos. Em planos de controle de alta latência (geo-distribuído, ou com rede congestionada), discovery requests podem sofrer aumento de latência. A alternativa (retornar visão local 404s falsos) era inaceitável, mas agora há custo operacional.

• Proxy-based routing sem fallback silencioso: Quando MVP proxia uma requisição para um peer, ele adiciona header x-kubernetes-peer-proxied para rastreabilidade. Se o peer também não servir o recurso, a requisição falha. Não há cascade de tentativas. Isso força garantias stronger de que a peer lookup é correcta—o que Aggregated Discovery fornece, mas com o custo acima.

• Mutação de identidade durante proxy: Requisições proxiadas preservam o contexto de autenticação original? A documentação não cobre explicitamente, mas a implicação é que o proxy não re-autentica—apenas roteia. Isto simplifica, mas cria superfície de ataque se um API server comprometido pode proxiar para peers sem validação adicional.

• Habilitado por padrão: Ao contrário de Alpha (feature gate opcional), Beta liga automaticamente. Clusters que dependem de fallback 404 para lógica de detecção de capacidade quebram silenciosamente. Auditing de compatibilidade é crítico pré-upgrade.

O que muda na prática

Para Arquitetos de Infraestrutura Kubernetes: Upgrades agora têm comportamento determinístico de discovery durante janelas de mixed-version. Não há mais "descoberta parcial" que força retry logic em aplicações. Mas monitoramento de latência de discovery (p99, p95) torna-se operacional crítico. Se um peer fica lento, toda a discovery sofre.

Para Engenheiros de Plano de Controle: StorageVersion API pode ser descontinuada eventualmente. Migrar cualquier lógica que dependa dela para Aggregated Discovery agora. Testes de upgrade precisam validar que Peer-Aggregated Discovery está respondendo completamente antes de drenagem de tráfego de versões antigas.

Para DevOps/SREs: Metrics críticos: tempo de resposta de discovery por peer, taxa de proxy requests, erros de proxy (peer não consegue servir recurso que Aggregated Discovery disse que poderia). Alertas em "discovery requests pendentes" ou "peers fora de sync em capabilities" precisam existir. Rollback de upgrade é mais seguro agora, mas falha de discovery é mais visível.

Para desenvolvedores de Operadores/Controllers: Evitem cachear resultados de kubectl api-resources ou discovery por períodos longos. A visão muda durante upgrades (novos recursos aparecem conforme peers atualizam). Se seu operador assume visão estática de capabilities, comportamento muda em janelas de upgrade misto.

Conclusão direta

Mixed Version Proxy em Beta elimina uma fonte significativa de falsos negros em upgrades heterogêneos, ao custo de distribuir descoberta de recursos entre peers. Isto é tradeoff correto para confiabilidade de control plane, mas operacionaliza complexidade que antes era invisível. Monitoramento de discovery latency e peer sync deixa de ser "nice to have" para ser obrigatório em ambientes production.

A pergunta que fica: sua pipeline de testes de upgrade valida não apenas "upgrade completa sem erro", mas também "discovery converge para visão unificada em menos de X segundos"? Porque agora isso afeta a velocidade real de detecção de novos recursos pela aplicação.

Fontes

[Fonte: Kubernetes Blog] Kubernetes v1.36: Mixed Version Proxy Graduates to Beta — Feature evolution from StorageVersion API to Aggregated Discovery, Peer-Aggregated Discovery support, and default enablement in 1.36.