Kubernetes 1.34: as novidades da versão e o que esperar
Aprofundamento CEVIU
Aprofundamento
O Kubernetes 1.34, lançado em 27 de agosto de 2025 com o nome 'Of Wind & Will', trouxe 58 aprimoramentos, 23 em estável (GA), 22 em beta e 13 em alfa. Diferente de versões anteriores, não houve depreciações críticas de API. O Dynamic Resource Allocation (DRA) para GPUs e hardware especializado atingiu GA e está habilitado por padrão, resolvendo fragmentação de GPUs e cegueira de topologia com novos tipos de API como ResourceClaim e DeviceClass. O rastreamento avançado com OpenTelemetry também foi promovido para GA, oferecendo visibilidade de ponta a ponta no ciclo de vida dos Pods. O KYAML, dialeto seguro de YAML com sintaxe estrita e suporte a comentários, entrou como recurso alfa, e já é consumível via kubectl get -o kyaml.
O suporte a certificados X.509 em Pods (via PodCertificateRequests) e a exclusão estruturada de namespaces (agora GA) são marcos de segurança: o primeiro permite mTLS nativo sem sidecars, o segundo corrige riscos como a CVE-2024-7598. As novas ContainerRestartRules (alfa) permitem reinício condicional por código de saída, essencial para jobs de ML que precisam de recuperação rápida sem recriar o Pod inteiro.
Por que isso importa
A versão 1.34 é um ponto de virada para infraestrutura de IA/ML no Kubernetes. O DRA GA elimina a necessidade de operadores personalizados para alocação de GPUs, agora é nativo, declarativo e integrado ao scheduler. O Gang Scheduling ainda não existe na 1.34, mas sua ausência é justamente o que torna o DRA e as ContainerRestartRules tão relevantes: são os primeiros pilares para orquestração confiável de cargas distribuídas. A migração do rastreamento para OpenTelemetry GA significa que equipes podem usar ferramentas como Tempo, Jaeger ou Grafana Alloy sem adaptações. E o KYAML, embora alfa, sinaliza uma mudança realista na direção de manifestos mais previsíveis, algo que devops enfrenta diariamente com erros sutis de coerção de tipo no YAML tradicional.
Impacto para desenvolvedores
Para devs e SREs, a 1.34 reduz a complexidade operacional em três frentes: segurança, observabilidade e portabilidade. Com certificados X.509 nativos, você retira sidecars como cert-manager ou SPIFFE no nível do Pod. Com o rastreamento GA, basta configurar um exportador OpenTelemetry, sem instrumentar código. E o DRA GA permite declarar solicitações de GPU como resources.requests.nvidia.com/gpu: 1, sem depender de CRDs externos. A única pegadinha: o KYAML exige adaptação de pipelines CI/CD, strings devem estar entre aspas duplas, listas usam [], e vírgulas à direita são obrigatórias. Já as ContainerRestartRules exigem atualização do kubelet e do scheduler para funcionar, e só rodam com o feature gate ContainerRestartPolicy ativado.
Perguntas frequentes
O que é o Dynamic Resource Allocation (DRA) no Kubernetes 1.34?
O DRA é um recurso em disponibilidade geral (GA) no Kubernetes 1.34 que permite alocar hardware especializado, como GPUs, FPGAs e aceleradores customizados, de forma nativa, segura e declarativa. Ele introduz APIs como DeviceClass e ResourceClaim, resolve fragmentação de recursos e permite compartilhamento fino de dispositivos via DRAConsumableCapacity (recurso alfa).
KYAML no Kubernetes 1.34: o que muda para quem escreve manifests?
O KYAML é um dialeto estrito de YAML introduzido como recurso alfa na 1.34. Ele exige strings entre aspas duplas, usa {} para objetos e [] para listas, aceita comentários e vírgulas à direita. Não é compatível com YAML tradicional, mas pode ser usado via kubectl get -o kyaml ou em ferramentas que suportam o formato.
Quando o Gang Scheduling foi introduzido no Kubernetes?
O Gang Scheduling foi introduzido como recurso alfa no Kubernetes 1.35, lançado em 17 de dezembro de 2025. Ele não está presente na versão 1.34. Na 1.36 (maio de 2026), migrou para beta. O recurso usa a API scheduling.k8s.io/v1alpha1 e visa jobs de treinamento distribuído em PyTorch, TensorFlow e Ray.
O que mudou nas políticas de reinício de containers no Kubernetes 1.34?
A versão 1.34 introduziu as ContainerRestartRules como recurso alfa. Elas permitem definir regras de reinício específicas para cada container dentro de um Pod, anulando a restartPolicy global. É possível configurar reinícios condicionais por código de saída, útil para cargas de ML que exigem recuperação rápida sem recriar o Pod inteiro.
Links relacionados
- Categoria
- CEVIU DevOps
- Publicado
- 13 de junho de 2026
- Fonte
- CEVIU DevOps
