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

8 minuto de leitura
0

Quero atualizar meus grupos de nós do Amazon Elastic Kubernetes Service (Amazon EKS) usando as versões mais recentes da imagem de máquina da Amazon (AMI).

Breve descrição

Quando você inicia uma atualização gerenciada de grupo de nós, o Amazon EKS atualiza os nós automaticamente. Se você usa uma AMI otimizada para Amazon EKS, o Amazon EKS aplica automaticamente os patches de segurança e as atualizações do sistema operacional mais recentes aos seus nós.

Durante esse processo de atualização, você pode receber qualquer um dos seguintes erros. Siga as etapas de solução de problemas relevantes para o erro que você encontrar. Para obter mais informações sobre erros de atualização, consulte Comportamento das atualizações dos nós gerenciados.

Resolução

A atualização falhou devido a PodEvictionFailure

O erro a seguir indica que uma falha PodEvictionFailure está bloqueando a atualização:

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

Se os pods não saírem do nó em 15 minutos e não houver sinalização para execução forçada, a fase de atualização falhará com um erro de PodEvictionFailure.

Um erro de PodEvictionFailure pode ocorrer por qualquer um dos seguintes motivos:

Orçamento de interrupção de pods (PDB) agressivo

Quando há vários PDBs que apontam para o mesmo pod, o pod tem uma definição de PDB agressivo.

O PDB indica o número de interrupções que uma classe de pods pode tolerar em um determinado momento (ou um "orçamento de falhas"). Quando uma interrupção voluntária faz com que os pods de um serviço fiquem abaixo do orçamento, a operação é interrompida até que ela possa manter o orçamento. O evento de drenagem de nós é interrompido temporariamente até que mais pods estejam disponíveis. Isso garante que você não exceda o orçamento removendo os pods. Para obter mais informações, consulte Disruptions no site do Kubernetes.

Para confirmar uma atualização tranquila do grupo de nós gerenciados, remova temporariamente os orçamentos de interrupção de pods ou use a opção de execução forçada para atualizar. Essa opção não respeita os orçamentos de interrupção de pods. Em vez disso, ela força os nós a reiniciarem e, portanto, implementarem as atualizações.

Observação: se o aplicativo for baseado em Quorum, a opção de execução forçada poderá fazer com que o aplicativo fique temporariamente indisponível.

Para confirmar se os PDBs estão configurados no seu cluster, execute o seguinte comando:

$ kubectl get pdb --all-namespaces

Ou, se você ativou o registro de auditoria em log 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 em log, escolha Auditoria. Essa ação 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. Escolha Personalizado 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 de pods.

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

    $ kubectl edit pdb pdb_name;

Implantação tolerando todos os taints

Depois que todos os pods forem removidos, o nó fica vazio porque recebeu propriedade taint nas etapas anteriores. No entanto, se a implantação tolerar todos os taints, é mais provável que o nó não esteja vazio. Isso resulta em uma falha na remoção de pods. Para obter mais informações, consulte Taints and tolerations no site do Kubernetes.

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

Se você tiver uma versão de lançamento inválida, poderá receber o seguinte erro:

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

Para resolver esse problema, execute o comando upgrade 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

Se seu grupo de nós tiver problemas de integridade, uma falha na atualização retornará o seguinte erro:

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

Isso indica que o grupo do Auto Scaling do grupo de nós não consegue encontrar a versão esperada de seu modelo de execução do Amazon Elastic Compute Cloud (Amazon EC2). Esse erro ocorre se você modificar ou excluir manualmente a versão do modelo associada ao grupo de nós. Isso faz com que o EKS mostre o grupo de nós como degradado.

Se você 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 saudável e ativo, e você pode reiniciar o processo de atualização.

A atualização falhou porque novos nós não estão se juntando ao grupo de nós

Esse problema ocorre se os novos nós do grupo de nós não puderem se juntar ao cluster. Como resultado, o grupo de nós reverte para sua versão anterior. Nesse caso, você pode receber o seguinte erro:

“NodeCreationFailure
Couldn't proceed with upgrade process as new nodes are not joining node group ng-backend”

Há vários motivos pelos quais os nós atualizados não podem ingressar no cluster:

Você alterou uma regra do grupo de segurança que o grupo de nós existente usa

Verifique se as regras de saída do grupo de segurança do nó permitem a porta 443 ao grupo de segurança do cluster.

O grupo de segurança do cluster não permite tráfego a partir do grupo de segurança do nó

Verifique se as regras de entrada do grupo de segurança do cluster permitem a porta 443 do grupo de segurança do nó. Para obter mais informações, consulte Considerações e requisitos sobre grupos de segurança do Amazon EKS.

Você criou seu grupo de nós com um modelo de execução personalizado

Se você estiver atualizando um modelo de execução personalizado, a nova versão do modelo deverá ter os dados corretos do usuário. Além disso, se você usar uma AMI personalizada, certifique-se de ter configurado corretamente a AMI para ingressar no cluster.

Para solucionar problemas com o modelo de execução, crie um novo grupo de nós com o mesmo modelo de execução. Certifique-se de que o modelo use a versão mais recente da AMI personalizada. Em seguida, veja se o nó ingressa com êxito no cluster. Se o nó não ingressar no cluster, conecte-se à instância do nó com SSH e verifique os logs do kubelet.

Faltam permissões do IAM

Verifique se o perfil do AWS Identity and Access Management (IAM) para o grupo de nós tem as permissões necessárias.

ACLs negam tráfego

A lista de controle de acesso (ACL) da sub-rede de um nó pode negar tráfego de saída para a porta 443 ou tráfego de entrada para uma porta efêmera. Certifique-se de permitir essas regras para a sub-rede do nó.

Da mesma forma, a ACL da sub-rede de um cluster pode negar tráfego de entrada para a porta 443. Certifique-se de permitir esse tráfego para as sub-redes do seu cluster.

Novos nós não conseguem adicionar um plugin

Um plugin CNI da Amazon Virtual Private Cloud (Amazon VPC) ou um complemento kube-proxy pode não aparecer em novos nós. Para obter mais informações, consulte Como resolvo problemas no kubelet ou plugin CNI do Amazon EKS?

Uma sub-rede tem problemas de conectividade

A sub-rede em que o Amazon EKS cria nós pode não ter conectividade com os endpoints necessários. Esses endpoints podem incluir o Amazon Elastic Container Registry (Amazon ECR), o Amazon Simple Storage Service (Amazon S3) ou o Amazon EC2. A conectividade pode falhar através da Internet ou de endpoints da VPC. Para endpoints da VPC, verifique os grupos de segurança dos nós e endpoints para garantir que eles permitam o tráfego necessário. Se você usa um gateway NAT ou um gateway da Internet, verifique se a regra de roteamento está correta na tabela de rotas da sub-rede. Além disso, verifique se o gateway NAT ou gateway da Internet correspondente existe.

AWS OFICIAL
AWS OFICIALAtualizada há 10 meses