Kubernetes 1.35 Timbernetes chega com nova rodada de estabilidade

O Kubernetes 1.35, chamado Timbernetes, chega com uma rodada ampla de melhorias de estabilidade, segurança e operação. A release reúne 60 enhancements, incluindo recursos estáveis, betas e alphas, além de depreciações que administradores precisam acompanhar antes de atualizar clusters de produção.¹

O tom da versão é de maturidade incremental. Kubernetes já é a base de boa parte da infraestrutura cloud native, então cada release precisa equilibrar inovação com compatibilidade. O valor não está em uma única novidade chamativa, mas no acúmulo de melhorias que reduzem atrito em identidade, scheduling, storage, observabilidade e ciclo de vida de workloads.

Identidade, Jobs e Pods ganham avanços estáveis

Entre os destaques, a versão promove recursos ligados a identidade de workloads e controle de Jobs. O suporte a certificados para pods entra como peça importante para simplificar arquiteturas de zero trust e service mesh, reduzindo dependência de controladores externos, CRDs e sidecars apenas para entregar e rotacionar certificados.

O campo managedBy na API de Job chega estável e permite que controladores externos gerenciem sincronização de status. Isso é relevante em cenários multi-cluster, como filas de trabalho que espelham Jobs entre um cluster de gerenciamento e clusters de execução. Em ambientes com processamento distribuído, o Kubernetes continua abrindo espaço para orquestradores especializados sem abandonar a API central.

Outro avanço está nos campos .metadata.generation e .status.observedGeneration para Pods. Eles ajudam controladores e operadores a distinguir o estado desejado do estado já processado pelo kubelet. Em produção, esse tipo de sinal é valioso para debugging, reconciliação e automação confiável.

Betas miram topologia, storage e autoscaling

Na lista de recursos beta, a exposição de labels de topologia via Downward API reduz a necessidade de aplicações consultarem diretamente o API server para descobrir região ou zona. Isso simplifica workloads sensíveis a localidade e diminui permissões RBAC desnecessárias, alinhando melhor segurança e eficiência.

O suporte nativo a storage version migration também avança, trazendo a lógica para dentro do plano de controle. Em clusters grandes, migração de versões de armazenamento é um tema operacional delicado, especialmente quando CRDs e APIs evoluem. Reduzir dependência de ferramentas externas ajuda a padronizar processos de upgrade.

Há ainda melhorias em capacidade mutável de CSI, tolerância configurável no HPA, regras de restart por container, tokens de ServiceAccount para drivers CSI e suporte a gang scheduling por meio de Workload API e PodGroup. São recursos que respondem a dores reais de clusters modernos: workloads com requisitos de topologia, jobs coordenados, volumes com limites dinâmicos e autoscaling que precisa de mais nuance.

Depreciações também entram no plano

Kubernetes 1.35 também traz avisos de direção. O modo ipvs do kube-proxy é deprecado, embora permaneça disponível nesta versão, com recomendação de transição para nftables em nós Linux. A release também marca a última versão com suporte à série containerd 1.x, ponto importante para equipes que mantêm nós antigos ou imagens de base presas a runtimes legados.¹

Para atualizar, o caminho seguro continua sendo leitura das release notes, validação em ambiente de staging, checagem de APIs removidas ou deprecadas, testes de CNI, CSI, ingress, observabilidade e políticas de admissão. Clusters gerenciados podem esconder parte do trabalho, mas não eliminam dependências de workloads e add-ons.

Timbernetes reforça a natureza do Kubernetes em 2025: menos revolução visível, mais refinamento de plataforma. Para quem opera clusters em escala, essa é uma boa notícia. Estabilidade nasce de pequenos controles que fazem reconciliação, scheduling, identidade e armazenamento falharem de forma mais previsível.