Kubernetes 1.34: o que a versão trouxe de novidades e o fim do seu suporte

O Kubernetes 1.34, lançado em 27 de agosto de 2025 com o codinome 'Of Wind & Will' (O' WaW), trouxe 58 aprimoramentos, 23 em estável (GA), 22 em beta e 13 em alpha. Diferentemente de versões anteriores, não introduziu mudanças disruptivas, o que facilita atualizações em produção. A estabilização da Alocação Dinâmica de Recursos (DRA) é o destaque técnico: as APIs ResourceClaim e ResourceSlice agora estão em GA, permitindo que Pods solicitem recursos especializados, como GPUs, TPUs e NICs, de forma nativa e sem dependência de operadores ou webhooks externos. Também alcançaram GA a deleção ordenada de Namespaces e a API VolumeAttributesClass, essencial para ajuste dinâmico de parâmetros de volume CSI, como IOPS provisionados.

O rastreamento (tracing) via OpenTelemetry no kubelet e no API Server foi promovido para estável, oferecendo visibilidade ponta a ponta real em ambientes de produção, algo crítico para depuração de latência e análise de causa raiz. Já os tokens de ServiceAccount para pull de imagens do kubelet estão em beta e ativados por padrão, substituindo credenciais estáticas por tokens efêmeros com escopo de Pod. O KYAML, novo dialeto YAML focado em Kubernetes, foi introduzido para evitar armadilhas clássicas do YAML, como conversões implícitas de tipo e significância de espaços em branco, mas ainda não é o padrão do kubectl, apenas uma opção experimental na saída de comandos como `kubectl get -o kyaml`.

Manter clusters em versões suportadas é obrigatório para segurança operacional: o Kubernetes 1.34 terá suporte até 27 de outubro de 2026, data de seu End-of-Life. Após essa data, não haverá mais patches de segurança, correções de bugs nem atualizações de dependências críticas. Como o projeto mantém apenas os três últimos branches minor (1.36, 1.35 e 1.34), qualquer cluster em 1.34 após outubro de 2026 ficará fora do ciclo oficial de manutenção, o que aumenta riscos em ambientes regulados ou com SLAs rigorosos. Além disso, ferramentas de observabilidade, CI/CD e políticas de governança (como OPA ou Kyverno) dependem de APIs estáveis: usar versões desatualizadas pode quebrar integrações ou forçar workarounds temporários que acumulam débito técnico.

Para equipes de infraestrutura e SREs, a DRA em GA reduz a necessidade de operadores personalizados para gerenciar hardware acelerado, basta declarar um ResourceClaim no manifesto do Pod. O tracing estável via OpenTelemetry permite integrar diretamente com backends como Jaeger ou Tempo sem adaptações. Para devs, os tokens de ServiceAccount ativados por padrão simplificam o uso de registros privados (ex.: ECR, GCR, JFrog) sem configurar secrets manualmente. Já o KYAML não muda o fluxo de trabalho imediatamente, mas sinaliza uma direção clara: o projeto está priorizando formatos mais previsíveis para manipulação programática de manifests. Equipes que usam kustomize ou GitOps devem monitorar a evolução do KYAML, pois futuras versões podem adotá-lo como formato padrão para exportação estruturada.