EKS com Kubernetes 1.35: o que muda de verdade com resize in-place e image volumes
A AWS adicionou suporte ao Kubernetes 1.35 no EKS em janeiro de 2026. O impacto real aparece em tuning de CPU/memória e entrega de artefatos.
Resumo executivo
A AWS adicionou suporte ao Kubernetes 1.35 no EKS em janeiro de 2026. O impacto real aparece em tuning de CPU/memória e entrega de artefatos.
Ultima atualizacao: 25/02/2026
Resumo executivo
Em 28 de janeiro de 2026, a AWS anunciou suporte ao Kubernetes 1.35 no Amazon EKS. À primeira vista, parece apenas atualização de versão. Na prática, dois pontos mexem diretamente com operação de produção:
- Redimensionamento in-place de CPU/memória em Pods, reduzindo a necessidade de restart só para ajuste de capacidade.
- Image volumes, permitindo montar artefatos OCI (por exemplo bundles de dados/modelo) como volume, sem fluxo paralelo improvisado.
Para times de plataforma, isso significa menos atrito em operação contínua e mais previsibilidade em workloads com variação de carga.
Por que essa versão tem impacto estratégico
Grande parte dos incidentes de upgrade em Kubernetes não vem de API removida. Vem de comportamento operacional mal entendido.
O Kubernetes 1.35 toca exatamente nesses pontos:
- Ajuste de recurso com menos interrupção em caminhos suportados.
- Entrega de artefato com modelo OCI já conhecido pelo ecossistema de containers.
- Melhorias de tráfego/topologia que refinam comportamento de roteamento e alocação.
Quando isso é conectado a SLO e governança de plataforma, o efeito é redução de toil e melhoria de estabilidade em janela de pico.
Resize in-place: ganhos e limites
A promessa é simples: evitar restart evitável ao ajustar requests/limits.
Ganhos operacionais
- Resposta mais rápida a variação de perfil de carga.
- Menor impacto para serviços sensíveis a latência.
- Menos rollout disparado só para tuning de recurso.
Limites que continuam valendo
- Nem todo cenário de mutação de recurso terá o mesmo comportamento.
- Autoscaler, admission policies e guardrails de plataforma continuam determinando o que é seguro.
- Sem política clara, resize frequente pode virar nova fonte de drift.
Resize in-place funciona melhor como ferramenta de precisão, não como substituto de planejamento de capacidade.
Image volumes: OCI também como canal de dados
No 1.35, image volumes seguem avançando em maturidade (beta habilitado por padrão), permitindo montar artefatos OCI como volumes.
Para times de IA e dados, isso pode simplificar dores comuns:
- Entregar artefatos médios/grandes sem rebuild constante da imagem principal.
- Reduzir scripts de bootstrap que baixam dados no startup.
- Reaproveitar governança, rastreabilidade e políticas de registry já adotadas para containers.
Detalhe crítico: compatibilidade de runtime. A orientação upstream cita stack compatível (por exemplo containerd v2.1+) para esse caminho funcionar bem. Isso precisa entrar no checklist pré-upgrade.
Blueprint de rollout no EKS
- Inventariar workloads que exigem ajuste frequente de CPU/memória.
- Mapear workloads que hoje dependem de init/download manual de artefato.
- Validar compatibilidade de runtime e testes de conformidade para resize e image volumes.
- Rodar canário em node groups representativos com monitoramento de SLO.
- Expandir em ondas com critérios de rollback por criticidade de negócio.
Esse rigor é o que separa "cluster atualizado" de "plataforma realmente melhor".
Implicações de engenharia e custo
| Dimensão | Padrão antes do 1.35 | Com adoção disciplinada do 1.35 |
|---|---|---|
| Ajuste de recurso | Mudança com restart frequente | Tuning mais granular, com menos interrupção |
| Distribuição de artefato | Scripts customizados e canais paralelos | Caminho OCI mais padronizado |
| Carga operacional | Mais intervenção manual | Espaço para padronização operacional |
| Risco | Drift de comportamento em pico | Limites de política e teste mais explícitos |
O ganho financeiro tende a ser indireto, mas relevante: menos incidente evitável, menos churn de runbook e melhor uso de infraestrutura.
Conclusão
O valor do EKS 1.35 está em melhorar dois problemas difíceis de produção: resize com menor interrupção e entrega de artefato mais previsível.
A pergunta para liderança de plataforma não é se o Kubernetes 1.35 traz boas features. A pergunta é se o modelo operacional do time consegue transformar essas features em confiabilidade mensurável e eficiência de custo.
Em muitos projetos reais, o gargalo não é o comando de upgrade. É a maturidade de plataforma necessária para operar as novas capacidades com segurança.