Kubernetes 1.37 já foi publicado: transforme 67 melhorias num gate de upgrade

O sinal e os factos que mudam a decisão

O projeto Kubernetes publicou a versão 1.37, Garhwal, em 26 de agosto. A nota oficial contabiliza 67 melhorias: 16 graduadas para Stable, 23 para Beta, 27 a entrar em Alpha e uma depreciação ou remoção. Isso confirma o artefacto que ainda estava pendente na verificação Velqory de 26 de agosto.

A publicação oficial confirma a versão e a distribuição das 67 melhorias por estado; cada KEP continua a ter condições e limites próprios. A política de skew restringe combinações suportadas entre kube-apiserver, kubelet, kube-proxy e kubectl; saltos devem seguir a sequência oficial.

A documentação de APIs descontinuadas e as notas da distribuição têm de ser lidas em conjunto com a nota geral do projeto. O número de melhorias não mede risco local. Funcionalidades Beta podem estar ativas ou inativas por defeito, distribuições geridas podem atrasar suporte e uma alteração segura no control plane pode falhar por CSI, CNI, webhook, CRD ou política de versão adjacente.

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

Abra o estudo de upgrade, não a promoção automática. Congele uma matriz por cluster com versão, skew suportado, distribuição, add-ons, APIs, feature gates, runtime, etcd, rede, storage, observabilidade, workloads críticos e rollback antes de escolher canários.

O número de melhorias não mede risco local. Funcionalidades Beta podem estar ativas ou inativas por defeito, distribuições geridas podem atrasar suporte e uma alteração segura no control plane pode falhar por CSI, CNI, webhook, CRD ou política de versão adjacente.

Execução e prova de conclusão

A execução deve começar por exportar apis em uso, feature gates, versões de add-ons, políticas de admissão, drivers e requisitos de workloads por cluster. Depois, reproduzir o cluster numa réplica, atualizar pela sequência suportada e medir scheduling, rede, volumes, latência e erros. O fecho exige promover por canário com orçamento de erro, ponto de não retorno e restauração de estado ensaiada.

O upgrade fecha por cluster quando versão e componentes são suportados, os testes críticos mantêm SLOs, não existem APIs removidas em uso e a equipa demonstra rollback ou recuperação dentro do objetivo definido.

• exportar APIs em uso, feature gates, versões de add-ons, políticas de admissão, drivers e requisitos de workloads por cluster.
• reproduzir o cluster numa réplica, atualizar pela sequência suportada e medir scheduling, rede, volumes, latência e erros.
• promover por canário com orçamento de erro, ponto de não retorno e restauração de estado ensaiada.
• O upgrade fecha por cluster quando versão e componentes são suportados, os testes críticos mantêm SLOs, não existem APIs removidas em uso e a equipa demonstra rollback ou recuperação dentro do objetivo definido.