Comportamento das atualizações dos nós gerenciados - Amazon EKS

Ajudar a melhorar esta página

Quer contribuir para este guia do usuário? Role até o final desta página e selecione Editar esta página no GitHub. Suas contribuições ajudarão a tornar nosso guia do usuário melhor para todos.

Comportamento das atualizações dos nós gerenciados

A estratégia de atualização do nó de processamento gerenciado do Amazon EKS tem quatro fases diferentes descritas nas seções a seguir.

Fase de configuração

A fase de configuração contém estas etapas:

  1. Ele cria uma nova versão do modelo de execução do Amazon EC2 para o grupo do Auto Scaling que estiver associado ao grupo de nós. A nova versão do modelo de inicialização usa a AMI de destino ou uma versão do modelo de inicialização personalizado para a atualização.

  2. Ele atualiza o grupo do Auto Scaling para usar a versão mais recente do modelo de execução.

  3. Ele determina a quantidade máxima de nós a serem atualizados em paralelo usando a propriedade updateConfig do grupo de nós. O máximo indisponível tem uma cota de 100 nós. O valor padrão é um nó. Para obter mais informações, consulte a propriedade updateConfig na Referência da API do Amazon EKS.

Fase de aumento de escala vertical

Na atualização de nós em um grupo de nós gerenciados, os nós atualizados são iniciados na mesma zona de disponibilidade daqueles que estão sendo atualizados. Para garantir esse posicionamento, usamos o rebalanceamento de zonas de disponibilidade do Amazon EC2. Para obter mais informações, consulte Rebalanceamento de zonas de disponibilidade no Guia do usuário do Amazon EC2 Auto Scaling. Para atender a esse requisito, é possível a inicialização de até duas instâncias por zona de disponibilidade no grupo de nós gerenciados.

A fase de aumento de escala vertical tem estas etapas:

  1. Ele aumenta o tamanho máximo do grupo do Auto Scaling e o tamanho desejado pelo que for maior:

    • Até uma a duas vezes o número de zonas de disponibilidade na região em que o grupo do Auto Scaling está implantado.

    • O máximo indisponível de atualização.

      Por exemplo, se o grupo de nós tiver cinco zonas de disponibilidade e maxUnavailable como um, o processo de atualização poderá iniciar no máximo dez nós. No entanto, se maxUnavailable for 20 (ou qualquer valor superior a 10), o processo iniciaria 20 novos nós.

  2. Depois de escalar o grupo do Auto Scaling, ele verifica se os nós que usam a configuração mais recente estão presentes no grupo de nós. Essa etapa só é concluída corretamente quando atende a estes critérios:

    • Pelo menos um novo nó é iniciado em todas as zonas de disponibilidade em que o nó existe.

    • Cada novo nó deve estar no estado Ready.

    • Os novos nós devem ter rótulos aplicados ao Amazon EKS.

      São os rótulos do Amazon EKS aplicados aos nós de processamento em um grupo de nós regulares:

      • eks.amazonaws.com/nodegroup-image=$amiName

      • eks.amazonaws.com/nodegroup=$nodeGroupName

      São os rótulos do Amazon EKS aplicados aos nós de processamento em um modelo de execução personalizado ou em um grupo de nós da AMI:

      • eks.amazonaws.com/nodegroup-image=$amiName

      • eks.amazonaws.com/nodegroup=$nodeGroupName

      • eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId

      • eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion

  3. Ele marca os nós como não programáveis para evitar o agendamento de novos Pods. Ele também rotula os nós node.kubernetes.io/exclude-from-external-load-balancers=true para remover os nós dos balanceadores de carga antes de encerrar os nós.

A seguir, estão os motivos conhecidos que causam um erro NodeCreationFailure nesta fase:

Capacidade insuficiente na zona de disponibilidade

Existe a possibilidade de que a zona de disponibilidade não tenha capacidade dos tipos de instância solicitados. É recomendável configurar vários tipos de instância ao criar um grupo de nós gerenciados.

Limites de instâncias do EC2 na sua conta

Pode ser necessário aumentar o número de instâncias do Amazon EC2 que a conta pode executar simultaneamente usando o Service Quotas. Para obter mais informações, consulte EC2 Service Quotas no Guia do usuário do Amazon Elastic Compute Cloud para instâncias do Linux.

Dados de usuário personalizados

Os dados de usuário personalizados às vezes podem interromper o processo de bootstrap. Esse cenário pode fazer com que o kubelet não seja iniciado no nó ou com que os nós não recebam os rótulos esperados do Amazon EKS. Para ter mais informações, consulte Especificar uma AMI.

Quaisquer alterações que prejudiquem a integridade ou a prontidão de um nó

Pressão no disco do nó, pressão na memória e condições semelhantes podem impedir que um nó passe para o estado Ready.

Fase de atualização

A fase de atualização contém estas etapas:

  1. Ele seleciona aleatoriamente um nó que precisa ser atualizado, até o máximo indisponível configurado para o grupo de nós.

  2. Ele drena os Pods do nó. Se os Pods não saírem do nó em 15 minutos e não houver um sinalizador de força, a fase de atualização falhará com um erro PodEvictionFailure. Nesse cenário, você pode aplicar o sinalizador de força com a solicitação de update-nodegroup-version para excluir os Pods.

  3. Ele isola o nó após cada Pod ser removido e aguarda 60 segundos. Isso é feito para que o controlador de serviço não envie novas solicitações para este nó e remova esse nó da lista de nós ativos.

  4. Ele envia uma solicitação de encerramento para o grupo do Auto Scaling do nó isolado.

  5. Ele repete as etapas de atualização anteriores até que não haja nós no grupo de nós implantados com a versão anterior do modelo de execução.

A seguir, estão os motivos conhecidos que causam um erro PodEvictionFailure nesta fase:

PDB agressivo

Um PDB agressivo está definido no Pod ou há vários PDBs apontando para o mesmo Pod.

Implantação que tolera todas as taints

Depois que todo Pod é removido, espera-se que o nó fique vazio porque o nó sofreu taints nas etapas anteriores. Porém, se a implantação tolerar todos os taints, é mais provável que o nó não esteja vazio, causando falha na remoção do Pod.

Fase de redução de escala vertical

A fase de redução de escala vertical diminui o tamanho máximo do grupo do Auto Scaling e o tamanho desejado para retornar aos valores anteriores ao início da atualização.

Se o fluxo de trabalho Upgrade determinar que o Cluster Autoscaler está aumentando a escala na vertical do grupo de nós durante a fase de redução de escala na vertical do fluxo de trabalho, ele será encerrado imediatamente sem trazer o grupo de nós de volta ao tamanho original.