**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
<a name="eks-outposts-instance-store-troubleshooting"></a>

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.

## O `kubectl` não funciona depois da configuração de `kubeconfig`
<a name="eks-outposts-instance-store-troubleshooting-kubectl"></a>

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
```

## Os nós não entram no cluster
<a name="eks-outposts-instance-store-troubleshooting-nodes-not-joining"></a>

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
   ```

1.  **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`.

1.  **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
   ```

## O cluster está paralisado no estado `CREATING`
<a name="eks-outposts-instance-store-troubleshooting-creating"></a>

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](eks-outposts-instance-store-vpc-subnet-requirements.md).

## O cluster está paralisado no estado `UPDATING`
<a name="eks-outposts-instance-store-troubleshooting-updating"></a>

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.

## Perda de quórum do `etcd`
<a name="eks-outposts-instance-store-troubleshooting-etcd-quorum"></a>

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](https://console.aws.amazon.com/support/home).