Como soluciono problemas de nós que não conseguem se juntar aos clusters do Amazon EKS Anywhere?

Breve descrição

Antes de começar a solucionar problemas, certifique-se de que sua configuração atende aos seguintes requisitos:

• Você tem uma máquina administrativa para executar as operações de ciclo de vida do cluster.
• Sua máquina administrativa, ambiente de gerenciamento e nós de processamento estão na mesma rede de camada 2.
• Sua rede oferece suporte a DHCP.
  Observação: é uma prática recomendada configurar sua rede para excluir endereços IP específicos do ambiente de gerenciamento e dos nós de processamento.
• Você reservou endereços IP estáticos para o endpoint do ambiente de gerenciamento e outros nós do cluster e excluiu endereços IP estáticos do intervalo DHCP.
• Seu servidor tem no mínimo duas vCPUs, 8 GB de RAM e 25 GB de armazenamento para cada nó.
• Sua interface de rede elástica suporta um ambiente de execução de pré-inicialização (Preboot eXecution Environment, PXE).
• Você tem o VMware vSphere 7 ou 8 e o VMware vCenter Server.
• Você tem a capacidade de implantar de 6 a 10 máquinas virtuais (VMs). Além disso, você está executando um serviço DHCP na rede VM primária do seu cluster de workload.
• Sua rede vSphere permite acesso ao vCenter Server, e você reservou e excluiu os endereços IP necessários do DHCP.

Resolução

Erro de registro de nó

Você recebe a seguinte mensagem de erro quando não aplica o mapa de configuração do AWS IAM Authenticator para Kubernetes (aws-auth ConfigMap) a um cluster:

"Unable to register node with API server err=Unauthorized."

Observação: o mapa de configuração fornece as permissões de controle de acesso baseado em perfil (role-based access control, RBAC) system:bootstrappers e system:nodes para que os nós se registrem no cluster.

Para solucionar um erro de registro de nó, adicione seu perfil do AWS Identity and Access Management (AWS IAM) ao aws-auth ConfigMap.

Erro “unauthorized”

Você recebe uma mensagem de erro “unauthorized” ao excluir um grupo de nó gerenciado e a entrada do perfil do nó é posteriormente excluída do aws-auth ConfigMap. É possível identificar esse erro ao revisar as solicitações da API kubelet para o servidor da API em seus logs do kubelet.

Para solucionar um erro não autorizado, adicione seu perfil do IAM ao aws-auth ConfigMap novamente.

Erros de dependência do Kubelet

Erro no arquivo CA

Você recebe a seguinte mensagem de erro quando um nó não consegue recuperar o arquivo da autoridade de certificação (CA) de um cluster ou quando o script /etc/eks/bootstrap.sh é executado:

"Failed to construct kubelet dependencies" err="unable to load client CA file /etc/kubernetes/pki/ca.crt: open /etc/kubernetes/pki/ca.crt: no such file or directory."

Para solucionar um erro de dependência do Kubelet, conclua as seguintes etapas:

1. Verifique o fluxo /var/log/cloud-init-output.log em seus logs do cloud-init para encontrar a seguinte mensagem de erro:
   "Connect timeout on endpoint URL: https://eks.us-east-1.amazonaws.com/clusters/vg-xx-uat Exited with error on line 291"

2. Execute o seguinte comando curl -vk para verificar se é possível acessar o endpoint da API do Amazon EKS:

   curl -vk https://eks.us-east-1.amazonaws.com/

3. Exclua o endpoint do Amazon EKS.

Se não for possível acessar o endpoint, execute as seguintes ações:

• Para endpoints privados, coloque o nó na mesma nuvem privada virtual (VPC) ou rede conectada. Os endpoints privados não são acessíveis ao público.
• Configure seus grupos de segurança, tabelas de rotas e lista de controle de acesso à rede (ACL da rede) para endpoints públicos. Grupos de segurança, tabelas de rotas e ACLs da rede devem permitir tráfego HTTPS (TCP 443) de saída para o endpoint do Amazon EKS. Para obter mais informações, consulte Considerações sobre VPC e sub-rede.
• Para nós em sub-redes privadas, certifique-se de ter um gateway NAT ou um endpoint da VPC para acesso de saída à internet.
• Defina enableDnsHostnames e enableDnsSupport como verdadeiro em sua VPC.
• Certifique-se de que o conjunto de opções DHCP inclui AmazonProvidedDNS.

Erros de validação

Você recebe a seguinte mensagem de erro de validação quando o Kubernetes não consegue encontrar o recurso do ambiente de gerenciamento "kubeadmcontrolplanes.controlplane.cluster.x-k8s.io" no cluster de workload:

"Validation failed: kubeadmcontrolplanes.controlplane.cluster.x-k8s.io 'eksa-sit' not found; no CAPI cluster objects present on workload cluster 'eksa-sit'..."

Para solucionar um erro de validação, conclua as seguintes etapas:

1. Acesse o nó do ambiente de gerenciamento no qual o processo kubeadm está sendo executado.

2. Execute o seguinte comando journalctl para obter informações de solução de problemas dos logs de serviço do kubelet:

   journalctl -u kubelet -f

3. Na saída do log, identifique o componente do cluster que está causando o erro de validação.

Erro no token de bootstrap

Você enfrenta um erro no token de bootstrap devido a um bug na versão 1.0.2 dos clusters do Amazon EKS Anywhere. Para obter mais informações, consulte bootstrap tokens can expire before they can be used if the bootstrap cluster's time is sufficiently behind the workload cluster (tokens de bootstrap podem expirar antes de serem usados se o tempo do cluster de bootstrap estiver suficientemente atrasado em relação ao cluster de workload) no site do GitHub.

Para solucionar esse erro, consulte Fix to enable bootstrap secret rotation if the secret itself missing (Corrigir para habilitar a rotação secreta do bootstrap se o segredo em si estiver ausente) no site do GitHub.

Erro de segredo do token de bootstrap ausente

É possível receber uma mensagem de erro ao executar o comando eksctl anywhere upgrade cluster -f cluster.yaml. O erro ocorre porque um segredo do token de bootstrap está ausente devido a um bug no fluxo de trabalho. O bug bloqueia novos nós que tentam se juntar ao seu cluster.

Para solucionar esse erro, realize as etapas a seguir:

1. Exclua manualmente sua nova máquina provisionada para atualizar o token de bootstrap.
2. Quando o cluster estiver em um estado íntegro, faça backup da Kubernetes Cluster API (CAPI) e mova os componentes da CAPI para o cluster de gerenciamento. Para obter instruções, consulte Cluster upgrade fails with management components on bootstrap cluster (Falha no upgrade do cluster com componentes de gerenciamento no cluster de bootstrap).

Erros internos

Você recebe a seguinte mensagem de erro interno quando o serviço de validação de webhook apresenta problemas de conectividade:

"Error from server (InternalError): Internal error occurred: failed calling webhook..."

Para solucionar um erro interno, conclua as seguintes etapas:

1. Execute o seguinte comando kubectl get pods para encontrar seu pod eks-controller-manager:

   kubectl get pods -n kube-system | grep eks-controller-manager

2. Execute o seguinte comando kubectl logs para visualizar os logs do pod:

   kubectl logs eksa-controller-manager-pod-name -n kube-system

   Observação: substitua eksa-controller-manager-pod-name pelo nome do seu pod eksa-controller-manager.

3. Use as informações da saída do log para solucionar o problema.

Você recebe a seguinte mensagem de erro interno quando o processo de eleição do líder no ambiente de gerenciamento do Kubernetes atinge o tempo limite:

"Failed to update lock: etcdserver: request timed out failed to renew lease eksa-system/f64ae69e.eks.amazonaws.com: timed out waiting for the condition Error setup problem running manager {'error': 'leader election lost'}..."

Também é possível receber essa mensagem de erro quando o processo de eleição do líder não consegue renovar a concessão de um bloqueio de recursos no etcd.

As causas principais do erro incluem atrasos na rede, indisponibilidade de etcd ou problemas de contenção de recursos.

Para solucionar esse erro interno, exclua o pod eksa-controller-manager. Um pod substituto é iniciado e passa para o estado Em execução.

Observação: erros internos podem ocorrer nas versões 1.21 ou anteriores dos clusters do Amazon EKS Anywhere. Para evitar esse erro, é uma prática recomendada atualizar seu cluster para a versão mais recente do Kubernetes.

Erro PLEG

Você recebe a seguinte mensagem de erro quando o Pod Lifecycle Event Generator (PLEG) apresenta um problema:

"PLEG is not healthy: pleg was last seen active."

Para solucionar um erro de PLEG, execute as seguintes ações:

• Verifique e solucione a latência ou os tempos limite do runtime do contêiner, como degradação do desempenho, deadlock ou bugs, que ocorrem durante solicitações remotas.
• Evite ter muitos pods em execução em recursos do host ou muitos pods em execução em hosts de alta especificação.
• Solucione problemas de recursos no nó.

Para obter mais informações sobre o PLEG, consulte Pod Lifecycle Event Generator: Understanding the "PLEG is not healthy" issue in Kubernetes (Pod Lifecycle Event Generator: Entendendo o problema “PLEG não é íntegro” no Kubernetes) no site do Red Hat Developer.

Erro NotReady,SchedulingDisabled

Você recebe um erro quando um dos nós no cluster do Amazon EKS Anywhere está no estado NotReady,SchedulingDisabled. Isso ocorre porque a máquina física na qual a vSphere VM estava sendo executada não existe mais. Seu cluster fica preso na fase de escalabilidade e seus novos nós não conseguem inicializar.

Para resolver um erro de estado NotReady,SchedulingDisabled, conclua as seguintes etapas:

1. Remova o finalizador da máquina.
2. Execute o seguinte comando kubectl delete node para excluir o nó pendente do Amazon EKS e permitir que um novo nó inicialize:

   kubectl delete node your_node_name

   Observação: substitua your_node_name pelo nome do nó que você deseja excluir.

Informações relacionadas

What is EKS Anywhere? (O que é o EKS Anywhere?)

A rede de runtime do contêiner não está pronta