Adeus containerd 1.x: as novidades que o Kubernetes 1.34 traz para o seu ambiente

E aí, pessoal! Tudo bem com vocês?

Emerson da 4Linux chegando com um tema bem interessante que tem movimentado a comunidade: a nova versão do Kubernetes. Vem comigo para conferir as novidades que estão chegando!

Introdução

O Kubernetes segue evoluindo em ritmo acelerado, e a versão 1.34, lançada em agosto de 2025, chegou repleta de melhorias importantes para desenvolvedores e administradores de clusters. Entre as principais novidades estão o fim do suporte ao containerd 1.x (previsto para a versão 1.35), a estabilização do Dynamic Resource Allocation (DRA) para uso de GPUs e hardwares especializados, novas opções de distribuição de tráfego, a chegada do KYAML como padrão de YAML mais confiável e avanços em observabilidade e escalabilidade.

Se você mantém clusters em produção, é hora de conhecer o que muda e como se preparar para essa nova era do Kubernetes.

Fim do suporte ao containerd 1.x

O Kubernetes 1.34 marca a despedida oficial do containerd 1.x, que deixará de ser suportado já na próxima versão (1.35). Isso significa que é hora de planejar a migração para o containerd 2.0 ou superior.
O impacto será maior para ambientes que ainda não atualizaram o runtime de containers, especialmente clusters legados ou com integrações customizadas.

Eu já comecei a testar o containerd 2.x em ambientes de staging para garantir uma transição tranquila.

Dynamic Resource Allocation (DRA) chega à fase estável

A alocação dinâmica de recursos — como GPUs, FPGAs e outros hardwares especializados — finalmente se tornou um recurso estável no Kubernetes 1.34.
Isso traz mais flexibilidade para workloads que precisam de recursos de alto desempenho, eliminando boa parte da complexidade de configurações manuais.
APIs como ResourceClaim e DeviceClass estão prontas para uso em produção.

Eu comecei a testar o Ollama, uma plataforma open source que permite executar modelos de linguagem grandes (LLMs) localmente, e a novidade do DRA faz toda a diferença nesse tipo de cenário.

Antes, era comum ter que reservar manualmente uma GPU para os pods, o que gerava desperdício de recursos ou falhas quando múltiplos pods tentavam disputar o mesmo dispositivo.
Agora, com o DRA estável, o Kubernetes negocia automaticamente o uso da GPU via ResourceClaim, garantindo que:

• cada pod que roda o Ollama obtenha o hardware necessário para carregar o modelo;
• workloads que não precisam de GPU não “prendam” recursos à toa;
• seja possível rodar múltiplos modelos em paralelo sem conflitos de alocação.

Um exemplo simples de manifesto para esse caso poderia ser:

apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
  name: ollama-gpu-claim
spec:
  devices:
    requests:
    - name: nvidia.com/gpu
      count: 1
---
apiVersion: v1
kind: Pod
metadata:
  name: ollama-pod
spec:
  containers:
  - name: ollama
    image: ollama/ollama:latest
    command: ["ollama", "run", "llama2"]
    resources:
      claims:
      - name: ollama-gpu-claim

Para quem trabalha com IA generativa, machine learning ou inferência em tempo real, o DRA estável é uma das maiores novidades do Kubernetes 1.34.
Em breve trago um post mais específico sobre isso.

Novas opções de distribuição de tráfego

O campo spec.trafficDistribution ganhou duas novidades:

• PreferSameZone (substituindo o antigo PreferClose)
• PreferSameNode, que prioriza manter o tráfego dentro do mesmo nó, caindo para endpoints remotos apenas se necessário.

Essas opções aumentam a eficiência de rede e ajudam a reduzir a latência, especialmente em clusters distribuídos em múltiplas zonas.

KYAML: um novo YAML

Surge o KYAML, um novo “dialeto” de YAML padronizado para manifestos Kubernetes.

Entre as melhorias:

• Strings sempre com aspas duplas.
• Sintaxe consistente para parsing por ferramentas.
• Melhor suporte para versionamento e automação.

Essa novidade promete menos dores de cabeça com erros de indentação e parsing em CI/CD.
Eu particularmente estou me adaptando, mas ainda não vou abandonar o YAML tão cedo.
Seremos agora KYAML Engineers? rsrsrs

Observabilidade e escalabilidade mais inteligentes

• HPA (Horizontal Pod Autoscaler): agora permite ajustes mais finos no comportamento de scale-up/scale-down, definindo tolerâncias customizadas.
• SchedulerAsyncAPICalls (beta): o scheduler pode fazer chamadas assíncronas, tornando o agendamento de pods mais rápido e escalável.
• Novos sinais e métricas de saúde para DRA, facilitando a detecção de problemas em recursos alocados.

O que você precisa fazer agora

1. Planejar a atualização do containerd: comece a migração para a versão 2.0 antes da chegada do Kubernetes 1.35.
2. Testar o DRA: se você usa GPUs ou workloads que dependem de hardware especializado, aproveite que a funcionalidade agora está estável.
3. Revisar manifests YAML: avalie como o KYAML pode impactar seus pipelines de CI/CD. Vale a pena testar.
4. Explorar as opções de tráfego: configure PreferSameZone e PreferSameNode em seus Services para reduzir latência.

Conclusão

O Kubernetes 1.34 não é apenas mais uma versão: ele marca a transição para uma nova fase de runtimes (com a saída do containerd 1.x), ao mesmo tempo em que amadurece recursos críticos como DRA e observabilidade.
Para mais detalhes que talvez eu não tenha abordado neste post e que você possa se interessar, vou deixar os links no final.

Então bora testar!

Por hoje é só, compartilhem em suas redes sociais!

Referências

• https://kubernetes.io/blog/2025/07/28/kubernetes-v1-34-sneak-peek/
• https://kubernetes.io/blog/2025/08/27/kubernetes-v1-34-release/
• https://www.kubernetes.dev/resources/release/