Rollback de versão no EKS: como funciona e as pegadinhas

Já fiz upgrade de EKS em ambiente PCI, num cluster de gateway de pagamento, com o prazo do compliance achatado. Não podia dar problema e, ao mesmo tempo, precisava acontecer logo. Quem já viveu isso sabe o peso: até pouco tempo atrás, atualizar a versão de um cluster EKS era uma viagem só de ida. Deu ruim? Não existia botão de voltar: era abrir chamado, mitigar workload por workload e rezar para o impacto ser mínimo.

Em julho de 2026 a AWS finalmente mudou essa conversa: o EKS agora suporta rollback de versão do cluster. Atualizou e algo ficou estranho? Dá para reverter o control plane para a versão anterior em até 7 dias, sem custo adicional, em todas as regiões.

Só que, como quase tudo em Kubernetes gerenciado, o diabo mora nos detalhes. O rollback cobre bem menos do que o nome sugere, e a ordem das operações importa. Vamos ao que interessa.

O que a AWS lançou, em uma linha

Reverter a versão minor do control plane (só de N para N-1, ex.: de 1.34 para 1.33) em até 7 dias após um upgrade in-place, via console, CLI ou SDK. Antes de liberar, o EKS roda verificações de prontidão (compatibilidade de API, version skew, add-ons, saúde do cluster) e bloqueia o rollback se encontrar problema sério.

Dois limites que já eliminam alguns cenários: o cluster precisa ter sido atualizado para a versão atual (cluster criado direto nela não reverte), e não dá para pular versões. Quem passou anos acumulando upgrades sabe que N-1 não salva ninguém de dívida técnica de versão: na empresa onde trabalho, já sofri a maratona de sair do 1.21 e ir degrau por degrau até o 1.27.

O que é revertido (e o que fica de fora)

O rollback devolve a versão do API server e dos componentes do control plane, junto com a platform version. E preserva o que importa: dados do etcd, seus workloads, volumes persistentes. Nada disso é tocado.

A lista do que não é revertido é onde mora o risco real:

A exceção é o EKS Auto Mode: nele, a AWS reverte os worker nodes automaticamente antes do control plane. Para todo o resto, o “rollback do cluster” é, na verdade, rollback do control plane, e o plano de dados é problema seu.

Se você usa Karpenter (como a gente), atenção aqui

Nos clusters que gerencio usamos Karpenter para provisionamento de nós. Inclusive já escrevi sobre pods travados em ContainerCreating com Karpenter. E aqui vai o ponto que a documentação trata como nota de rodapé: nó de Karpenter não é Managed Node Group nem Auto Mode. Ou seja, no rollback ele cai na categoria “self-managed”: ninguém reverte por você.

Por que isso importa? Version skew. O Kubernetes suporta kubelet até três minors mais velho que o API server, mas nunca mais novo. Se os seus nós já subiram na versão nova e você reverte o control plane, fica com kubelet N falando com API server N-1: cenário não suportado. Na prática, você precisa garantir que os NodePools/EC2NodeClass voltem a apontar para a AMI da versão anterior e reciclar os nós (o drift do Karpenter ajuda aqui, mas valide o comportamento no seu setup antes de contar com isso em produção).

Antes de reverter: consulte os insights de ROLLBACK_READINESS

O EKS expõe a prontidão de rollback pela mesma API de insights usada nos upgrades (doc oficial):

aws eks list-insights \
  --cluster-name meu-cluster \
  --filter '{"categories": ["ROLLBACK_READINESS"]}'

aws eks describe-insight \
  --cluster-name meu-cluster \
  --id <insight-id>

No meu cluster de lab, a checagem de version skew passou e o vpc-cni levantou um aviso de downgrade. É exatamente o tipo de coisa que você quer descobrir ANTES de apertar o botão.

PASSING e WARNING deixam o rollback seguir; ERROR e UNKNOWN bloqueiam, a menos que você use --force, aceitando o risco por escrito. Um detalhe que merece respeito: os insights são uma foto do momento. Mudou algo no cluster depois da checagem? A foto está velha.

O passo a passo, na ordem certa

A ordem é o contrário do upgrade: plano de dados desce primeiro.

# 1. Managed Node Groups de volta à versão anterior
aws eks update-nodegroup-version \
  --cluster-name meu-cluster \
  --nodegroup-name meu-nodegroup \
  --kubernetes-version 1.33

# 2. Add-ons incompatíveis: downgrade manual
aws eks update-addon \
  --cluster-name meu-cluster \
  --addon-name vpc-cni \
  --addon-version <versao-compativel>

# 3. Control plane por último
aws eks update-cluster-version \
  --name meu-cluster \
  --kubernetes-version 1.33

# 4. Acompanhar
aws eks describe-update --name meu-cluster --update-id <id>

As pegadinhas que vão te pegar

• Extended support volta a cobrar. Se a versão de destino do rollback já está em extended support, a cobrança extra é ativada, e a política de upgrade do cluster precisa estar como EXTENDED. Aqui atualizamos justamente antes de qualquer cluster cair no extended support, pelos custos e pela segurança; um rollback que te joga de volta para uma versão paga anula metade do benefício.
• Fargate trava o rollback. Pods Fargate na versão do control plane precisam ser deletados antes, ou você força e assume o rebuild.
• --force não é atalho mágico. Ele pula os insights, mas não a janela de 7 dias, nem a regra do N-1, nem PDBs e disruption budgets no Auto Mode.
• CloudFormation não dispara rollback. Reverter a stack não reverte a versão do cluster; a chamada tem que ser explícita.

Onde isso entra no runbook de quem opera EKS de verdade

Na empresa onde trabalho gerenciamos mais de seis clusters EKS, cada um rodando na faixa de 15 a 25 microsserviços. Nosso fluxo de upgrade sempre foi: develop primeiro, valida, depois os ambientes seguintes, como fazemos desde os tempos de criar cluster EKS via Terraform com Blueprint. Em anos operando assim, nunca precisei de um rollback de emergência. E é exatamente por isso que gosto da feature.

Rollback de versão é rede de segurança, não estratégia. Se o seu processo de upgrade depende de reverter para sobreviver, o problema não é a versão nova, é o processo. O valor real está em outro lugar: tirar o peso psicológico da janela de manutenção. Aquele upgrade PCI com prazo achatado teria sido outra experiência com um plano B nativo de 7 dias no bolso.

Minha leitura: a feature não muda como atualizar (develop primeiro, sempre), mas muda quando. Dá para subir a versão em produção mais cedo e com mais calma, manter a rotina de nunca encostar no extended support, e deixar o botão de voltar quietinho lá, sem nunca apertar. Que é como todo bom plano de rollback deveria terminar.