Kubernetes 1.37: o upgrade começa pelas depreciações e pelos defaults, não pelas novidades

O sinal e os factos que mudam a decisão

A versão 1.37 reúne melhorias Stable, Beta e Alpha, mas a alteração operacional aparece nos estados e valores por defeito. A nota oficial inclui funcionalidades Beta ativadas por defeito, funcionalidades ainda opt-in e uma depreciação ou remoção; cada cluster precisa de comparar configuração atual com a final.

A nota 1.37 declara 16 graduações Stable, 23 Beta, 27 entradas Alpha e uma depreciação ou remoção. O suporte de etcd RangeStream entra em Beta ativo por defeito e requer etcd 3.7 ou fallback automático, segundo a nota oficial.

Outras funções, como PodAndContainerStatsFromCRI, continuam Beta mas desativadas por defeito; maturidade não determina sozinha o comportamento. Um manifesto pode continuar válido no schema e falhar por um controlador, driver ou webhook incompatível. Ativar uma Beta em produção apenas porque está disponível mistura avaliação de release com mudança funcional e aumenta a superfície do rollback.

Decisão, limites e condição de bloqueio

Produza um diff de comportamento: feature gates que mudam, APIs removidas ou descontinuadas, requisitos de etcd, kube-proxy, cgroups, SELinux, webhooks, CSI e métricas. Só teste novas capacidades depois de provar que o caminho existente continua suportado.

Um manifesto pode continuar válido no schema e falhar por um controlador, driver ou webhook incompatível. Ativar uma Beta em produção apenas porque está disponível mistura avaliação de release com mudança funcional e aumenta a superfície do rollback.

Execução e prova de conclusão

A execução deve começar por capturar flags e versões reais do control plane, nodes, etcd, runtime, cni, csi, admission e observabilidade. Depois, executar scanners de apis e testes de compatibilidade com a mesma carga e plugins da produção. O fecho exige manter novas features desligadas na primeira vaga salvo necessidade aprovada, isolando a mudança de versão da mudança de produto.

O gate fecha quando o diff de defaults está aprovado, não existem APIs removidas, todos os add-ons declaram compatibilidade e os testes de canário confirmam comportamento e métricas equivalentes antes de qualquer feature adicional.

• capturar flags e versões reais do control plane, nodes, etcd, runtime, CNI, CSI, admission e observabilidade.
• executar scanners de APIs e testes de compatibilidade com a mesma carga e plugins da produção.
• manter novas features desligadas na primeira vaga salvo necessidade aprovada, isolando a mudança de versão da mudança de produto.
• O gate fecha quando o diff de defaults está aprovado, não existem APIs removidas, todos os add-ons declaram compatibilidade e os testes de canário confirmam comportamento e métricas equivalentes antes de qualquer feature adicional.