**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.
# Entenda cada fase das atualizações de nós
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 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.
1. Ele atualiza o grupo do Auto Scaling para usar a versão mais recente do modelo de execução.
1. 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](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateNodegroupConfig.html#API_UpdateNodegroupConfig_RequestSyntax) 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](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage) 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é duas vezes o número de zonas de disponibilidade 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.
1. 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`
1. Ele marca os nós como não agendáveis para evitar o agendamento de novos pods. Também rotula os nós com `node.kubernetes.io/exclude-from-external-load-balancers=true` para remover os nós antigos dos balanceadores de carga antes de encerrá-los.
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 [Service Quotas do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) no *Guia do usuário do Amazon Elastic Compute Cloud para instâncias 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 obter mais informações, consulte [Especificar uma AMI](launch-templates.md#launch-template-custom-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`.
**Cada nó deve inicializar em até 15 minutos**
Se algum nó levar mais de 15 minutos para inicializar e ingressar no cluster, isso fará com que a atualização atinja o tempo limite. Este é o runtime total para inicializar um novo nó, calculado desde quando um novo nó é necessário até quando ele se junta ao cluster. Ao atualizar um grupo de nós gerenciados, o contador de tempo começa assim que o tamanho do grupo do Auto Scaling aumenta.
## Fase de atualização
A fase de atualização se comporta de duas maneiras diferentes, dependendo da *estratégia de atualização*. Há duas estratégias de atualização: **padrão** e **mínima**.
Recomendamos a estratégia padrão na maioria dos cenários. Ela cria novos nós antes de encerrar os antigos para que a capacidade disponível seja mantida durante a fase de atualização. A estratégia mínima é útil em cenários em que você está limitado a recursos ou custos, por exemplo, com aceleradores de hardware, como GPUs. Ela encerra os nós antigos antes de criar os novos para que a capacidade total nunca aumente além da quantidade configurada.
A estratégia de atualização *padrão* tem as seguintes etapas:
1. Ela aumenta a quantidade de nós (contagem desejada) no grupo do Auto Scaling, fazendo com que o grupo de nós crie nós adicionais.
1. Ele seleciona aleatoriamente um nó que precisa ser atualizado, até o máximo indisponível configurado para o grupo de nós.
1. Drena os pods do nó. Se os pods não saírem do nó em até 15 minutos e não houver um sinalizador de força, a fase de atualização falhará com um erro `PodEvictionFailure`. Para tal cenário, você pode aplicar o sinalizador de força com a solicitação `update-nodegroup-version` para excluir os pods.
1. 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.
1. Ele envia uma solicitação de encerramento para o grupo do Auto Scaling do nó isolado.
1. 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 estratégia de atualização *mínima* tem as seguintes etapas:
1. Ele isola todos os nós do grupo de nós no início para que o controlador de serviço não envie novas solicitações para esses nós.
1. Ele seleciona aleatoriamente um nó que precisa ser atualizado, até o máximo indisponível configurado para o grupo de nós.
1. Ele drena os pods dos nós selecionados. Se os pods não saírem do nó em até 15 minutos e não houver um sinalizador de força, a fase de atualização falhará com um erro `PodEvictionFailure`. Para tal cenário, você pode aplicar o sinalizador de força com a solicitação `update-nodegroup-version` para excluir os pods.
1. Depois que cada pod é removido e aguarda 60 segundos, ele envia uma solicitação de encerramento para o grupo do Auto Scaling dos nós selecionados. O grupo do Auto Scaling cria novos nós (o mesmo número de nós selecionados) para substituir a capacidade ausente.
1. 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.
### Erros `PodEvictionFailure` durante a fase de atualizaçã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 todos os pods são removidos, espera-se que o nó fique vazio porque o nó [sofreu taints](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) 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 dos pods.
## 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.