Como soluciono problemas comuns com falhas de atualização de grupos de nós do Amazon EKS?

Breve descrição

As versões mais recentes do Amazon EKS também incluem novas versões das AMIs da Amazon para atualizações de grupos de nós. Clientes com sua workload implantada em vários grupos de nós enfrentam o desafio de atualizar seus nós para acompanhar o ciclo de lançamento.

Quando você inicia uma atualização de grupos de nós gerenciados, o Amazon EKS atualiza automaticamente seus nós para você. Se você estiver usando uma AMI otimizada para o Amazon EKS, ele aplica automaticamente os patches de segurança e as atualizações do sistema operacional mais recentes aos seus nós como parte da versão de lançamento mais recente da AMI. Para implementar a atualização, o AWS Auto Scaling lança os nós em todas as zonas de disponibilidade em que os nós estão presentes no grupo de nós. Esse serviço também reequilibra a zona de disponibilidade. Como os nós existentes são drenados apenas uma vez, a etapa de lançamento é bem-sucedida. A fase de redução diminui o tamanho máximo e o tamanho desejado do grupo do Auto Scaling em um para retornar aos valores antes da atualização. Consulte “Fase de redução de escala vertical” em Comportamento das atualizações dos nós gerenciados para obter mais informações.

Resolução

Durante esse processo de atualização, você pode ver alguns dos erros a seguir que exigem suas próprias etapas de mitigação. Estar ciente desses problemas com antecedência permite minimizar o tempo de inatividade. Consulte Comportamento de atualização de nós gerenciados para obter mais informações sobre erros de atualização.

A atualização falhou devido a PodEvictionFailure

Error message : Reached max retries while trying to evict pods from nodes in node group.

Esse erro indica que a atualização está bloqueada por PodEvictionFailure. Se os pods não saírem do nó em 15 minutos e não houver nenhum sinal de força, a fase de atualização falhará com um erro PodEvictionFailure.

A seguir estão os motivos do erro PodEvictionFailure na fase de atualização:

Pod Disruption Budget (PDB – Orçamento de interrupção de pods) agressivo

O PDB agressivo é definido no pod quando há vários PDBs apontando para o mesmo pod.

O PDB indica o número de interrupções que podem ser toleradas em um determinado momento para uma classe de cápsulas (um orçamento de falhas). Sempre que uma interrupção voluntária faz com que os pods de um serviço caiam abaixo do orçamento, a operação é interrompida até conseguir manter o orçamento. O evento de drenagem de nós é interrompido temporariamente até que mais pods estejam disponíveis, para que o orçamento não seja ultrapassado com o despejo dos pods. Para obter mais informações, consulte Disruptions (Interrupções) no site do Kubernetes.

Para confirmar uma atualização tranquila do grupo de nós gerenciados, você deve remover temporariamente os orçamentos de interrupção de pods ou usar a opção “force” para atualizar. Essa opção não respeita os orçamentos de interrupção de pods. Em vez disso, essa opção implementa as atualizações forçando a reinicialização dos nós.

Observação: se a aplicação for baseada em Quorum, a opção “force” poderá fazer com que a aplicação fique temporariamente indisponível.

Execute o comando a seguir para confirmar que você tem PDBs configurados em seu cluster:

$ kubectl get pdb --all-namespaces

Ou, se você ativou o registro de auditoria no console do Amazon EKS, siga estas etapas:

1.    Na guia Clusters, escolha o cluster desejado (por exemplo, rpam-eks-qa2-control-plane) na lista.

2.    Na guia Registro, escolha Audit (Auditoria). Isso redireciona você para o console do Amazon CloudWatch.

3.    No console do CloudWatch, escolha Logs. Em seguida, escolha Log Insights e execute a seguinte consulta:

fields @timestamp, @message
| filter @logStream like "kube-apiserver-audit"
| filter ispresent(requestURI)
| filter objectRef.subresource = "eviction" 
| display @logStream, requestURI, responseObject.message
| stats count(*) as retry by requestURI, responseObject.message

4.    Selecione Custom (Personalizado) no canto superior direito para identificar a data da atualização. Se houver uma falha na atualização do grupo de nós devido ao PDB agressivo, resposeObject.message descreve o motivo da falha na remoção do pod.

5.    Se o PDB causou a falha, modifique o PDB usando o comando a seguir. Em seguida, atualize o grupo de nós novamente:

$ kubectl edit pdb pdb_name;

Implantação que tolera todos os “taints”

Depois que cada pod é despejado, o nó fica vazio porque foi recebeu um “taint” nas etapas anteriores. No entanto, se a implantação tolerar todos os “taints”, é mais provável que o nó não esteja vazio, causando uma falha na remoção do pod. Consulte Taints and tolerations (Taints e tolerâncias) no site do Kubernetes para obter mais informações.

A atualização falhou devido a uma versão de lançamento inválida

Error Message: Requested release version 1.xx is not valid for kubernetes version 1.xx.

Para resolver esse problema, execute o comando de atualização novamente. Esse comando atualiza os grupos de nós para a mesma versão da versão do Kubernetes do ambiente de gerenciamento:

eksctl upgrade nodegroup --name=test --cluster=test --kubernetes-version=1.xx

Observação: substitua a versão 1.xx pela versão compatível com o ambiente de gerenciamento do Amazon EKS.

A atualização falhou porque o grupo de nós tem problemas de integridade

Error message: Nodegroup has health issue other than [ AsgInstanceLaunchFailures, InstanceLimitExceeded, InsufficientFreeAddresses, ClusterUnreachable]

Essa falha ocorre se você modificou manualmente o grupo do Auto Scaling do grupo de nós para usar uma versão diferente do modelo de inicialização do Amazon Elastic Compute Cloud (Amazon EC2). Ou talvez você tenha excluído a versão do modelo associada ao grupo de nós. O grupo de nós do EKS usa um modelo de inicialização padrão que entra em conflito com o modelo de execução do grupo do Auto Scaling. Esse modelo de inicialização faz com que o EKS mostre o grupo de nós como degradado.

Se você ainda não excluiu o modelo de execução, altere manualmente a versão do modelo de execução do grupo do Auto Scaling para a versão apropriada. Essa ação reverte o grupo de nós para um estado íntegro e ativo. Agora você pode reiniciar o processo de atualização.

---