View a markdown version of this page

Solucionar problemas de clusters locais do Amazon EKS no AWS Outposts configurado com o armazenamento de instância do EC2 - Amazon EKS

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.

Solucionar problemas de clusters locais do Amazon EKS no AWS Outposts configurado com o armazenamento de instância do EC2

Este tópico aborda erros comuns que você pode encontrar ao usar clusters locais do Amazon EKS no AWS Outposts com armazenamento de instância do EC2 e como solucioná-los.

Se ocorrer o seguinte erro depois de executar aws eks update-kubeconfig:

Either parameter --cluster-name or --cluster-id must be specified.

Ou:

couldn't get current server API group list: getting credentials: exec: executable aws failed with exit code 1

Verifique se kubeconfig (~/.kube/config) especifica --cluster-name nos argumentos exec, não --cluster-id:

      args:
        - --region
        - region-code
        - eks
        - get-token
        - --cluster-name
        - my-cluster
        - --output
        - json
      command: aws

Se os nós não aparecerem quando você executa kubectl get nodes:

  1. Verifique os logs do kubelet no nó. Acesse o nó com SSM ou SSH e execute:

    systemctl status kubelet -l

  2. Verifique se há erros de falta de autorização. Erros de falta de autorização podem indicar a falta de permissões de perfil de nó ou problemas no ConfigMap do aws-auth. Verifique se o perfil de instância do nó está mapeado corretamente no ConfigMap do aws-auth.

  3. Verifique o status da CSR. Verifique se a solicitação de assinatura do certificado do nó foi aprovada:

    kubectl get csr

    Se a CSR estiver no estado Pending, aprove-a:

    kubectl certificate approve node-csr-EXAMPLE

Se o cluster entrar no status de FALHA:

  • Capacidade insuficiente: verifique se o outpost tem capacidade virtualizada suficiente para seis instâncias do ambiente de gerenciamento (três etcd + três servidores de API) dos tipos de instância especificados. Os tipos de instância devem estar alocados no outposts.

  • A topologia de distribuição não pode ser atendida: se você especificou um spreadLevel de host, verifique se pelo menos três hosts estão configurados com o tipo de instância escolhido. Se você especificou o rack, verifique se pelo menos três racks têm hosts com o tipo de instância escolhido.

  • Problemas de sub-rede: verifique se as sub-redes que você especificou estão na zona de disponibilidade na qual o outpost está hospedado e se cada sub-rede tem pelo menos três endereços IP disponíveis. Consulte Criar uma VPC e sub-redes para clusters locais do Amazon EKS no AWS Outposts configurado com armazenamento de instância do EC2.

Se o cluster permanecer no estado UPDATING durante uma atualização de versão do Kubernetes ou de versão da plataforma:

  • Capacidade insuficiente: durante as atualizações, as instâncias do ambiente de gerenciamento são excluídas antes da reinstanciação. Se a capacidade liberada for consumida por outra workload antes que a instância substituta seja provisionada, a atualização é interrompida. Verifique se o outpost tem capacidade disponível para os tipos de instância do ambiente de gerenciamento.

Se você não conseguir mais realizar operações de API do Kubernetes e o outpost for desconectado:

  • O etcd pode ter perdido o quórum. Isso ocorre se mais de uma instância do etcd ficar indisponível durante uma desconexão.

  • As workloads que já estão em execução continuam operando, mas as operações de API do Kubernetes não estão disponíveis.

  • Quando a conectividade é restaurada, o Amazon EKS recupera o estado do cluster a partir do snapshot mais recente do etcd.

Entre em contato com o AWS Support Center.