Se o seu cluster ainda roda Kubernetes 1.32, o prazo está curto. Em 28 de fevereiro de 2026, essa versão deixa de receber patches de segurança e correções de bugs. Nenhuma CVE nova vai ser corrigida, nenhum hotfix vai ser publicado. A partir dessa data, qualquer vulnerabilidade descoberta no 1.32 fica por conta de quem ainda estiver rodando.

O Kubernetes mantém suporte ativo para as três versões minor mais recentes (política N-2). Com o 1.35 lançado em dezembro de 2025, as versões suportadas passam a ser 1.33, 1.34 e 1.35. O 1.32 cai fora.

O que acontece em 28 de fevereiro

A branch de release do 1.32 congela. Na prática, isso significa:

  • Zero patches de segurança para vulnerabilidades futuras
  • Nenhuma correção de bug, mesmo para problemas conhecidos
  • Providers de cloud (EKS, AKS, GKE) vão começar a deprecar ou forçar upgrade do 1.32 nos meses seguintes

Para times que rodam clusters auto-gerenciados, o risco é direto: uma CVE crítica no kubelet ou no API server não vai ter patch oficial. Para quem usa managed Kubernetes, o provider eventualmente vai forçar a migração, mas o cronograma varia.

O que mudou de 1.33 a 1.35

Três releases separam o 1.32 da versão mais recente. Cada uma trouxe melhorias que valem a atualização.

Kubernetes 1.34 (agosto de 2025) foi onde a Dynamic Resource Allocation (DRA) graduou para GA. DRA padroniza como GPUs, FPGAs e NICs são selecionados, alocados e compartilhados entre pods via ResourceClaim. Se o seu cluster roda workloads de IA/ML que disputam GPU, essa feature muda o jogo. A release também trouxe pod-level resources em beta, permitindo declarar requests e limits no nível do pod inteiro.

Kubernetes 1.35 "Timbernetes" (dezembro de 2025) trouxe 60 enhancements. O destaque é o In-Place Pod Resize em GA: ajustar CPU e memória de um pod em execução sem reiniciar o container. A feature existia em beta desde o 1.33, mas agora com status GA o resize é considerado estável para produção. Para DRA, as Device Binding Conditions avançaram para beta, melhorando a confiabilidade de scheduling em hardware que precisa de setup (GPUs conectadas via fabric, por exemplo).

Como planejar o upgrade

O Kubernetes exige upgrade sequencial: não dá para pular de 1.32 direto para 1.35. O caminho é 1.32 > 1.33 > 1.34 > 1.35, um minor por vez.

Antes de começar:

  1. Verifique se alguma API que você usa foi removida entre 1.33 e 1.35. O kubectl tem um flag útil para isso:
kubectl api-resources --api-group=apps
  1. Rode kubectl get events e revise warnings atuais do cluster. Resolver problemas existentes antes do upgrade evita surpresas
  2. Teste o upgrade em um cluster de staging primeiro. Cada hop de versão pode introduzir mudanças de comportamento em admission controllers, RBAC ou network policies
  3. A boa notícia: o 1.34 não introduziu remoções críticas de API, o que torna o upgrade de 1.33 para 1.34 menos arriscado que a média

Para quem usa managed Kubernetes, EKS, AKS e GKE oferecem upgrade in-place com rollback. Consulte a documentação do seu provider para o procedimento específico.

Conclusão

O deadline é 28 de fevereiro. Se o upgrade para 1.33 não está no sprint atual, deveria estar. Três hops de versão parecem muito, mas o 1.34 tem um caminho de migração limpo, e o 1.35 traz o In-Place Pod Resize que justifica o esforço. Quem roda workloads GPU vai sentir a diferença com DRA em GA.

Referências pesquisadas nesta publicação