Ajudar a melhorar esta página

Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.

Reversão de clusters do Modo Automático do EKS

Quando você inicia uma reversão de versão em um cluster executando o Modo Automático do EKS, o Amazon EKS gerencia automaticamente a reversão dos nós de processamento do Modo Automático antes de reverter o ambiente de gerenciamento. Esta página explica como a reversão de nós no Modo Automático funciona, como acelerá-la e como cancelá-la, se necessário.

Para obter informações gerais sobre a reversão de versão, incluindo os pré-requisitos, as verificações de insights e o processo geral de reversão, consulte Reverter um cluster para uma versão anterior do Kubernetes.

Como funciona a reversão do Modo Automático

O Modo Automático do EKS usa um sistema baseado no Karpenter para gerenciar a infraestrutura do nó de processamento, incluindo atualizações e reversões de versões do Kubernetes. Quando você chama UpdateClusterVersion com a versão anterior (N-1) em um cluster com o Modo Automático habilitado, o EKS executa a seguinte sequência:

O ambiente de gerenciamento permanece na versão atual (mais recente) e continua fornecendo tráfego normalmente enquanto os nós estão revertendo. A política de desvio de versão do Kubernetes permite que os nós executem até três versões secundárias anteriores ao kube-apiserver, portanto, esse estado intermediário é válido.

Status do cluster durante a reversão

O status do cluster permanece ACTIVE durante a fase de reversão dos nós. Use ListUpdates ou DescribeUpdate para determinar se uma reversão está em andamento. No console do Amazon EKS, navegue até seu cluster e abra a guia Histórico de atualizações para visualizar o status do ID de atualização associado à reversão.

Para acompanhar o progresso de cada nó durante a reversão, verifique a versão do Kubernetes dos nós no Modo Automático:

kubectl get nodes -l karpenter.sh/nodepool=<nodepool-name> -o wide

Controles de interrupção

A reversão do Modo Automático respeita todos os controles de interrupção existentes. Esses controles determinam a rapidez com que os nós podem ser substituídos e podem afetar significativamente a duração da reversão.

Orçamentos de interrupção do NodePool

Os orçamentos de interrupção do NodePool controlam quantos nós podem ser interrompidos simultaneamente. Durante a reversão, o Karpenter respeita esses orçamentos ao transferir os nós para a versão anterior.

Exemplo de NodePool com um orçamento de interrupção que permite que 10% dos nós sejam substituídos por vez:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    budgets:
      - nodes: "10%"
        reasons:
          - Drifted

Para obter mais informações sobre como configurar os orçamentos de interrupção do NodePool, consulte Criar um grupo de nós para o Modo Automático do EKS e orçamentos de interrupção do Karpenter.

PodDisruptionBudgets

Os PodDisruptionBudgets do Kubernetes são respeitados durante a substituição dos nós. Se um PDB impedir a remoção do pod, a interrupção do nó será atrasada até o TerminationGracePeriod.

Para obter mais informações, consulte Proteger workloads críticas com um PDB e a documentação do PDB do Kubernetes.

Anotações de não interrupção

A anotação karpenter.sh/do-not-disrupt pode ser definida em nós ou pods:

Nos nós: bloqueia a interrupção dos nós indefinidamente. Isso aciona um insight de ERROR e deve ser removido antes que a reversão possa continuar nesse nó.

Em pods: atrasa a interrupção do nó até o TerminationGracePeriod. Isso aciona um insight de WARNING, mas não bloqueia permanentemente a reversão.

Para obter mais informações sobre o comportamento de interrupção do Karpenter, consulte a documentação de interrupção do Karpenter.

Aceleração da reversão

Se a reversão estiver demorando mais do que o esperado, você poderá ajustar os controles de interrupção enquanto a reversão estiver em andamento.

Aumentar os orçamentos de interrupção do NodePool

Edite o recurso NodePool para permitir mais substituições simultâneas de nós:

kubectl edit nodepool default

Altere o orçamento para um valor maior:

spec:
  disruption:
    budgets:
      - nodes: "50%"
        reasons:
          - Drifted

Remover as anotações de não interrupção dos nós

Liste os nós com a anotação e remova-a:

# List nodes with the annotation
kubectl get nodes -o json | jq '.items[] | select(.metadata.annotations["karpenter.sh/do-not-disrupt"] == "true") | .metadata.name'

# Remove from a specific node
kubectl annotate node <node-name> karpenter.sh/do-not-disrupt-

Ajustar PodDisruptionBudgets

Se os PDBs estiverem retardando a remoção do pod, ajuste-os temporariamente:

kubectl edit pdb <pdb-name> -n <namespace>

Para obter mais informações sobre o gerenciamento de controles de interrupção, consulte Prevenção de interrupção de pods e nós no Modo Automático do EKS.

Cancelar uma reversão

Uma reversão só poderá ser cancelada enquanto os nós estiverem revertendo. Você pode usar CancelUpdate durante essa fase para interromper a operação.

aws eks cancel-update \
  --name my-cluster \
  --update-id <update-id> \
  --region us-west-2

Comportamento de cancelamento

Após o cancelamento

Após o cancelamento bem-sucedido, os nós retornam para a versão atual do cluster como de costume. A atualização faz a transição de Cancelling para Cancelled.

Após o cancelamento, você pode imediatamente:

Quando o cancelamento não é possível

O cancelamento falhará se a reversão dos nós já estiver concluída e a reversão do ambiente de gerenciamento tiver sido iniciada, ou se a atualização já tiver sido concluída com o status Successful ou Failed.

Tempo limite de reversão

A reversão dos nós no Modo Automático tem um tempo limite configurável controlado pelo parâmetro timeoutMinutes em rollbackConfig. O tempo limite padrão é de 720 minutos (12 horas). Você pode definir um valor entre 120 minutos (2 horas) e 10.080 minutos (7 dias). O tempo limite é uma propriedade de limite mínimo, o que significa que o tempo limite não ocorre antes do tempo especificado, mas pode ocorrer um pouco depois.

aws eks update-cluster-version \
  --name my-cluster \
  --kubernetes-version 1.30 \
  --rollback-config timeoutMinutes=1440 \
  --region us-west-2

Se todos os nós não tiverem concluído a reversão dentro do tempo limite especificado:

Depois de um tempo limite, você pode tentar novamente a reversão se ainda estiver dentro da janela de elegibilidade de reversão de sete dias da atualização original. Na prática, se a reversão dos nós expirar no dia 7, a janela de elegibilidade para reversão provavelmente também expirou, pois ambas são de sete dias.

Para evitar tempos limite, analise os insights de prontidão para a reversão antes de iniciar a reversão. Esses insights alertam sobre orçamentos ou anotações de interrupção que podem retardar o processo de reversão dos nós.

O sinalizador --force e o Modo Automático

O sinalizador --force em UpdateClusterVersion apenas ignora as verificações de insights do cluster. Não tem efeito no comportamento de interrupção do nó do Modo Automático.

Mesmo com --force:

A única maneira de acelerar a reversão dos nós é ajustar os próprios controles de interrupção. Para mais detalhes, consulte Aceleração da reversão.

Conflitos de tempo limite do IaC

As ferramentas de infraestrutura como código têm limites de tempo que podem entrar em conflito com a duração da reversão do Modo Automático. O CloudFormation permite até 36 horas por recurso. Se a operação expirar, o CloudFormation a tratará como uma operação sem efeito, o que pode levar o cluster a um estado de divergência em que o modelo não reflete a versão efetiva do cluster. A reversão da versão deve ser iniciada explicitamente. O Terraform Enterprise/Cloud tem um tempo limite de aproximadamente 24 horas, embora os tempos limite do lado do cliente possam variar dependendo da expiração da credencial e de outros fatores.

Para alinhar a duração da reversão com sua ferramenta IaC, use o parâmetro timeoutMinutes em rollbackConfig para definir um tempo limite apropriado. Se sua ferramenta de IaC atingir o tempo limite, use a API CancelUpdate diretamente para recuperar o controle. Se você tiver orçamentos de interrupção restritivos, considere iniciar a reversão diretamente por meio da CLI ou da API em vez da IaC.

Atualizações do sistema durante a reversão dos nós

Enquanto os nós do Modo Automático estão revertendo, o EKS continua a manter o ambiente de gerenciamento seguro e disponível.

As atualizações acionadas pelo cliente (como UpdateClusterVersion ou UpdateClusterConfig) são bloqueadas enquanto a reversão dos nós está em andamento. Se você precisar realizar uma atualização de alta prioridade, cancele a reversão primeiro usando CancelUpdate, depois execute sua atualização e reinicie a reversão se ainda estiver dentro da janela de elegibilidade.

Recursos relacionados