Como faço para solucionar problemas do eksctl com clusters e grupos de nós do Amazon EKS?

Breve descrição

Veja a seguir problemas comuns que você pode encontrar ao usar o eksctl para criar ou gerenciar um cluster ou grupo de nós do Amazon EKS:

• Você não sabe como criar um cluster com o eksctl. Consulte Conceitos básicos do Amazon EKS - eksctl e a seção eksctl de Criar um cluster do Amazon EKS.
• Você não sabe como especificar as opções de bootstrap do kubelet para grupos de nós gerenciados. Siga as etapas na seção de resolução Especificar opções de bootstrap do kubelet.
• Você não sabe como alterar o tipo de instância de um grupo de nós existente. Você deve criar um novo grupo de nós. Consulte Migrar para um novo grupo de nós e Nodegroup immutability (Imutabilidade do Nodegroup), no site do eskctl.
• Você atingiu o número máximo de recursos da AWS. Verifique seus recursos para ver se você pode excluir os que não estão sendo usados. Se você ainda precisar de mais capacidade, consulte Solicitar um aumento de cota.
• Você inicia instâncias do ambiente de gerenciamento em uma zona de disponibilidade com capacidade limitada. Consulte How do I resolve cluster creation errors in Amazon EKS? (Como faço para resolver os erros de criação de cluster no Amazon EKS?).
• Seus nós não passam para o estado Pronto. Siga as etapas na seção de resolução Resolver problemas de tempo limite de operação.
• Os valores de exportação não existem para o cluster. Siga as etapas na seção de resolução Criar o grupo de nós em sub-redes privadas.
• Você usou um tipo de instância sem suporte para criar um cluster ou um grupo de nós. Siga as etapas na seção de resolução Verificar se o tipo de instância é compatível.

Resolução

Especificar as opções de bootstrap do kubelet

Por padrão, o eksctl cria um script de bootstrap e o adiciona ao modelo de inicialização que os nós de processamento executam durante o processo de bootstrap. Para especificar suas próprias opções de bootstrap do kubelet, use a especificação overrideBootstrapCommand para substituir o script de bootstrap do eksctl. Use overrideBootstrapCommand para grupos de nós gerenciados e autogerenciados.

Especificação do arquivo de configuração:

managedNodeGroups:
  name: custom-ng
  ami: ami-0e124de4755b2734d
  securityGroups:
    attachIDs: ["sg-1234"]
  maxPodsPerNode: 80
  ssh:
    allow: true
  volumeSize: 100
  volumeName: /dev/xvda
  volumeEncrypted: true
  disableIMDSv1: true
  overrideBootstrapCommand: |
  #!/bin/bash
  /etc/eks/bootstrap.sh managed-cluster --kubelet-extra-args '--node-labels=eks.amazonaws.com/nodegroup=custom-ng,eks.amazonaws.com/nodegroup-image=ami-0e124de4755b2734d'

Observação: Você só poderá usar overrideBootstrapCommand quando estiver usando uma AMI personalizada. Se você não especificar um ID de AMI, a criação do cluster falhará.

Não foi especificado um ID de AMI personalizado

Se você não especificar um ID de AMI personalizado ao criar grupos de nós gerenciados, o Amazon EKS usará por padrão uma AMI otimizada do Amazon EKS e um script de bootstrap. Para usar uma AMI otimizada do Amazon EKS e com dados de usuário personalizados para especificar parâmetros de bootstrap, especifique o ID da AMI na configuração de grupo dos nós gerenciados.

Para obter o ID de AMI mais recente para a AMI otimizada mais recente do Amazon EKS, execute o comando a seguir:

aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.21/amazon-linux-2/recommended/image_id --region Region --query "Parameter.Value" --output text

Observação: Substitua Region pela sua região da AWS.

Resolver problemas de tempo limite de operação

Se você encontrar o seguinte erro ao criar um nó, o grupo de nós pode ter problemas de tempo limite:

waiting for at least 1 node(s) to become ready in "nodegroup"

Quando você cria um grupo de nós do EKS com o eksctl, a CLI do eksctl se conecta ao servidor da API para verificar continuamente o status do nó do Kubernetes. A CLI espera que os nós se movam para o estado Ready (Pronto) e, por fim, expira seu tempo se os nós não forem movidos.

A seguir estão os motivos pelos quais os nós não conseguem se mover para o estado Ready (Pronto):

• O kubelet não consegue se comunicar ou autenticar com o endpoint do servidor da API do EKS durante o bootstrapping.
• Os pods aws-node e kube-proxy não estão no estadoRunning (Executando).
• Os dados do usuário do nó de processamento do Amazon Elastic Compute Cloud (Amazon EC2) não foram executados com sucesso.

O kubelet não consegue se comunicar com o endpoint do servidor da API do EKS

Se o kubelet não puder se comunicar com o endpoint do servidor da API do EKS durante o processo de bootstrapping, obtenha o endpoint do servidor da API do EKS.

Execute o comando a seguir no nó de processamento:

curl -k https://123456DC0A12EC12DE0C12BC312FCC1A.yl4.us-east-1.eks.amazonaws.com
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
    
  },
  "status": "Failure",
  "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
  "reason": "Forbidden",
  "details": {
    
  },
  "code": 403
}

O comando anterior deverá retornar o código de status HTTP 403. Se o comando atingir o tempo limite, pode haver um problema de conectividade de rede entre o servidor da API do EKS e os nós de processamento.

Para resolver o problema de conectividade, conclua uma das seguintes etapas relacionadas ao seu caso de uso:

• Se os nós de processamento estiverem em uma sub-rede privada, certifique-se de que o endpoint do servidor da API do EKS esteja no modo de acesso Privado ou Público e Privado.
• Se o endpoint do servidor da API do EKS estiver definido como Privado, você deverá aplicar certas regras à zona hospedada privada para rotear o tráfego para o servidor da API. Os atributos enableDnsHostnames e enableDnsSupport da Amazon Virtual Private Cloud (Amazon VPC) devem ser definidos como True (Verdadeiro). Além disso, as opções de DHCP definidas para a Amazon VPC devem incluir AmazonProvideDNS em sua lista de domínios.
• Se você criou o grupo de nós em sub-redes públicas, certifique-se de que o atributo de endereçamento público IPv4 das sub-redes esteja definido comoTrue (Verdadeiro). Se você não definir o atributo como True (Verdadeiro), os nós de processamento não receberão um endereço IP público e não poderão acessar a Internet.
• Verifique se o grupo de segurança do cluster do Amazon EKS permite solicitações de entrada para a porta 443 do grupo de segurança do nó de processamento.

O kubelet não consegue se autenticar com o endpoint do servidor da API do EKS

Se o kubelet não consegue se autenticar com o endpoint do servidor da API do EKS durante o processo de bootstrapping, siga as etapas a seguir.

1.    Execute o seguinte comando para verificar se o nó de processamento tem acesso ao endpoint do STS:

telnet sts.region.amazonaws.com 443

Observação: substitua region pela sua região da AWS.

2.    Certifique-se de que o perfil do AWS Identity and Access Management (IAM) do nó de processamento tenha sido adicionado ao ConfigMap do aws-auth.

Por exemplo:

apiVersion:v1 kind:ConfigMap metadata:name:aws-auth namespace:kube-system data:mapRoles:|
    - rolearn: ARN of instance role (not instance profile)
      username: system:node:{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes

Observação: Para grupos de nós do Microsoft Windows, você deve adicionar um grupo RBAC eks:kube-proxy-windows adicional à seção mapRoles para a função do IAM do grupo de nós.

Os pods aws-node e kube-proxy não estão no estado Running (Executando)

Para verificar se os podsaws-node e kube-proxy estão no estado Running (Executando), execute o seguinte comando:

kubectl get pods -n kube-system

Se o pod aws-node estiver no estado Failing (Falhando), verifique a conexão entre o nó de processamento e o endpoint do Amazon EC2:

ec2.region.amazonaws.com

Observação: substitua region pela sua região da AWS.

Verifique se as políticas gerenciadas da AWS AmazonEKSWorkerNodePolicy e AmazonEC2ContainerRegistryReadOnly estão anexadas ao perfil do IAM do grupo de nós.

Se os nós estiverem em uma sub-rede privada, configure os endpoints da VPC do Amazon ECR para permitir imagens puxadas do Amazon Elastic Container Registry (Amazon ECR).

Se você usar o IRSA para a CNI da Amazon VPC, anexe a política gerenciada pela AWS AmazonEKS_CNI_Policy ao perfil do IAM usado pelos pods do aws-node. Você também deve anexar a política à função do IAM do grupo de nós sem IRSA.

Os dados do usuário do nó de processamento do EC2 não foram executados com sucesso

Para verificar se ocorreu algum erro quando os dados do usuário foram executados, revise os logs clod-init em /var/log/cloud-init.log e /var/log/cloud-init-output.log.

Para obter mais informações, execute o script do Coletor de Logs do EKS nos nós de processamento.

Criar o grupo de nós em sub-redes privadas

Se você encontrar o seguinte erro ao criar um grupo de nós, crie o grupo de nós em sub-redes privadas:

No export named eksctl--cluster::SubnetsPublic found. Rollack requested by user

Se você criou o cluster do Amazon EKS com redes PrivateOnly, o AWS CloudFormation não poderá criar sub-redes públicas. Isso significa que os valores de exportação não existirão para sub-redes públicas. Se os valores de exportação não existirem para o cluster, a criação do grupo de nós irá falhar.

Para resolver esse problema, você pode incluir a marcação --node-private-networking ao usar o comandoeksctl em linha. Você também pode usar a especificação privateNetworking: true na configuração do grupo de nós para solicitar a criação do grupo de nós em sub-redes privadas.

Atualize sua versão do eksctl ou especifique a região da AWS correta

Verifique a região da AWS se você receber o seguinte erro:

no eksctl-managed CloudFormation stacks found for "cluster-name"

Se você usar uma versão do eksctl anterior à 0.40.0, só poderá visualizar ou gerenciar os recursos do Amazon EKS criados com o eksctl. Para gerenciar recursos que não foram criados com o eksctl, atualize o eksctl para a versão 0.40.0 ou posterior. Para saber mais sobre os comandos que você pode executar em clusters que não foram criados com o eksctl, consulte Clusters não criados pelo eksctl (no site do eksctl).

Além disso, as pilhas do CloudFormation gerenciadas pelo eksctl não serão encontradas se você especificar uma região da AWS incorreta. Para resolver esse problema, certifique-se de especificar a região correta onde estão localizados seus recursos do Amazon EKS.

Verificar se o tipo da sua instância é compatível

Se você usou um tipo de instância sem suporte para criar um cluster ou nó, receberá o seguinte erro:

You must use a valid fully-formed launch template. The requested configuration is currently not supported. Please check the documentation for supported configurations'

Para verificar se o tipo da sua instância ou outras configurações são compatíveis com uma região específica da AWS, execute o seguinte comando:

aws ec2 describe-instance-type-offerings --region Region --query 'InstanceTypeOfferings[*].{InstanceType:InstanceType}'

Observação: Substitua Region pela sua região da AWS.

---