O Oracle Container Engine for Kubernetes (OKE) acaba de oficializar o suporte ao Kubernetes 1.35, apelidado pela comunidade como "Timbernetes" (ou release World Tree). Para times de engenharia e operações, esta não é apenas uma atualização de rotina; trata-se de um movimento que prioriza a modernização dos defaults do sistema e a eficiência operacional. No entanto, o ganho técnico traz inovações que exigem planejamento rigoroso para evitar indisponibilidades em ambientes de produção.
O que muda na prática?
A versão 1.35 consolida uma mudança de paradigma rumo a padrões mais maduros e seguros. Para garantir um upgrade bem-sucedido no OKE, nossa análise aponta três pilares de atenção: a migração obrigatória de node pools para OL8 ou superior (devido ao suporte exclusivo ao cgroup v2), o fim do suporte ao modo IPVS no kube-proxy e a transição necessária na gestão de Ingress. Ignorar esses aspectos significa converter um processo de manutenção em um incidente de infraestrutura.
1) Resize de Pods sem restart
Uma das entregas mais aguardadas é a atualização in-place de recursos. Agora, você pode ajustar CPU e memory requests/limits sem a necessidade de reiniciar o Pod. Isso reduz drasticamente o impacto em workloads stateful e serviços sensíveis a latência, permitindo otimizações de recursos em tempo real — uma excelente notícia para times que buscam eficiência constante via FinOps sem sacrificar a estabilidade.
2) Delegação de controle de Jobs
Com a introdução do campo managedBy em Jobs, a delegação para controladores externos torna-se mais limpa e organizada. Em cenários multi-cluster, isso simplifica o orchestrator, evitando conflitos na sincronização de status e facilitando modelos de execução de batch mais complexos.
3) Rastreabilidade de updates com .metadata.generation
Para ferramentas de SRE e automação, a inclusão de .metadata.generation permite verificar com precisão se o kubelet processou a última versão do spec. Isso elimina o viés de "spec pendente" vs. "spec aplicado", aumentando a previsibilidade em rollouts automatizados.
O que exige atenção imediata?
- O fim do cgroup v1: O Kubernetes 1.35 exige
cgroup v2. Se você ainda utiliza node pools baseados em OL7, okubeletsimplesmente não iniciará após o upgrade. A migração para OL8 ou superior é, portanto, o primeiro item de qualquer checklist de atualização. - Networking em transição: A aposentadoria do NGINX Ingress (projeto mantido pela comunidade) e a depreciação do modo IPVS no
kube-proxycolocam a rede no centro da estratégia de upgrade. O uso denftablespassa a ser a recomendação, enquanto oiptablespermanece como alternativa para sistemas legados. Validar a substituição do seu ingress controller deve ser prioridade antes de tocar no cluster. - Ciclos de vida acelerados: Com o suporte ao Kubernetes 1.32 chegando ao fim 30 dias após o lançamento do 1.35+, a gestão de versões no OKE precisa ser ágil. O suporte a três versões menores exige um planejamento rigoroso de upgrades sequenciais para não comprometer o SLA dos seus serviços.
Recomendações estratégicas
- Inventário e Atualização do OS: Audite todos os seus node pools. Se encontrar versões baseadas em OL7, a migração para OL8 é mandatória.
- Upgrade Estruturado: Utilize o ciclo de vida de suporte do OKE a seu favor. Valide em ambientes de desenvolvimento (non-prod) e meça o comportamento antes da virada em produção.
- Review de Networking: Verifique se sua stack de rede atual (Ingress e modos de proxy) está alinhada às novas diretrizes. O custo de retrabalho pós-upgrade é sempre superior ao custo de uma validação prévia.
Artigo originalmente publicado em cloud-infrastructure.
