Kubernetes 1.37 era previsto para hoje: sem artefacto final, o upgrade continua bloqueado

O sinal e os factos que mudam a decisão

O projeto Kubernetes tinha planeado a versão 1.37 para 26 de agosto. Na verificação editorial desta edição, a página oficial de releases ainda mostrava 1.36 como linha mais recente e o blogue não continha o anúncio final de 1.37. O sneak peek continua útil para preparar testes, mas avisa que funcionalidades e estado podiam mudar antes da release real.

O sneak peek previa depreciação do modo IPVS no kube-proxy, com desativação por defeito esperada em 1.40 e remoção em 1.43; o estado final deve ser confirmado no changelog. Também previa a proibição de referências a Secrets ou ConfigMaps em static Pods e a continuação da transição de cgroup v1 para v2.

SELinuxMount era esperado como GA e ativo por defeito quando o CSI driver opta por seLinuxMount; volumes partilhados por Pods com labels diferentes podem exigir seLinuxChangePolicy Recursive ou redesenho. Automação baseada apenas no calendário pode buscar artefactos inexistentes, release candidates ou mirrors incompletos. Mesmo após a publicação, mudanças previstas em static Pods, kube-proxy IPVS, cgroup v1 e SELinux volumes exigem testes por configuração, não apenas por versão.

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

Não transforme a data prevista em facto de lançamento. Prepare inventário e testes agora, mas só abra a vaga de upgrade quando versão, changelog, checksums, imagens e documentação finais aparecerem nos canais oficiais e forem compatíveis com a distribuição gerida.

Automação baseada apenas no calendário pode buscar artefactos inexistentes, release candidates ou mirrors incompletos. Mesmo após a publicação, mudanças previstas em static Pods, kube-proxy IPVS, cgroup v1 e SELinux volumes exigem testes por configuração, não apenas por versão.

Execução e prova de conclusão

A execução deve começar por inventariar versão, kube-proxy mode, cgroup, static pods, selinux, csi drivers, volume sharing, apis e skew por cluster. Depois, criar testes de pré-upgrade para cada mudança prevista e manter os resultados como hipóteses até ao changelog final. O fecho exige após release oficial, verificar assinatura/checksum, testar numa réplica, promover por canário e conservar rollback e observabilidade.

O gate abre apenas com prova oficial da release e fecha por cluster com compatibilidade de skew, add-ons, API, rede, storage e workload, mais rollback ensaiado; até lá, o estado correto é ‘planeado, ainda não confirmado’.

• inventariar versão, kube-proxy mode, cgroup, static Pods, SELinux, CSI drivers, volume sharing, APIs e skew por cluster.
• criar testes de pré-upgrade para cada mudança prevista e manter os resultados como hipóteses até ao changelog final.
• após release oficial, verificar assinatura/checksum, testar numa réplica, promover por canário e conservar rollback e observabilidade.
• O gate abre apenas com prova oficial da release e fecha por cluster com compatibilidade de skew, add-ons, API, rede, storage e workload, mais rollback ensaiado; até lá, o estado correto é ‘planeado, ainda não confirmado’.