**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.
# Solução de problemas de nós híbridos
Este tópico aborda alguns erros comuns que você poderia encontrar ao usar o Amazon EKS Hybrid Nodes e como resolvê-los. Para obter outras informações sobre solução de problemas, consulte [Solucionar problemas com clusters e nós do Amazon EKS](troubleshooting.md) e [Conteúdo do Centro de Conhecimento para o Amazon EKS](https://repost.aws/tags/knowledge-center/TA4IvCeWI1TE66q4jEj4Z9zg/amazon-elastic-kubernetes-service) no *AWS re:Post*. Caso não consiga resolver o problema, entre em contato com o AWS Support.
**Solução de problemas de nós com `nodeadm debug`** Você pode executar o comando `nodeadm debug` dos nós híbridos para validar se os requisitos de rede e credenciais foram atendidos. Para obter mais informações sobre o comando `nodeadm debug`, consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md).
**Detectar problemas com os nós híbridos com insights de clusters** Os insights de clusters do Amazon EKS incluem *verificações de insights* que detectam problemas comuns com a configuração do EKS Hybrid Nodes no cluster. Você pode ver os resultados de todas as verificações de insights no Console de gerenciamento da AWS, na AWS CLI e nos SDKs da AWS. Para obter mais informações sobre insights de clusters, consulte [Prepare-se para as atualizações da versão e a solução de problemas de configurações incorretas do Kubernetes com insights do cluster](cluster-insights.md).
## Instalar a solução de problemas de nós híbridos
Os tópicos de solução de problemas a seguir estão relacionados à instalação das dependências dos nós híbridos nos hosts com o comando `nodeadm install`.
** `nodeadm` Falha no comando `must run as root` **
O comando `nodeadm install` deve ser executado com um usuário que tenha privilégios de usuário-raiz ou `sudo` no host. Caso execute `nodeadm install` com um usuário que não tenha privilégios de usuário-raiz ou `sudo`, você verá o erro a seguir na saída de `nodeadm`.
```
"msg":"Command failed","error":"must run as root"
```
**Não é possível conectar às dependências**
O comando `nodeadm install` instala as dependências necessárias para os nós híbridos. As dependências dos nós híbridos incluem `containerd`, `kubelet`, `kubectl` e componentes do AWS SSM ou do AWS IAM Roles Anywhere. Você deve ter acesso do local em que está executando `nodeadm install` para baixar essas dependências. Para obter mais informações sobre a lista de locais que você deve poder acessar, consulte [Preparar a rede para nós híbridos](hybrid-nodes-networking.md). Caso não tenha acesso, você verá erros semelhantes ao apresentado a seguir na saída de `nodeadm install`.
```
"msg":"Command failed","error":"failed reading file from url: ...: max retries achieved for http request"
```
**Falha ao atualizar o gerenciador de pacotes**
O comando `nodeadm install` executa `apt update` ou `yum update` ou `dnf update` antes de instalar as dependências dos nós híbridos. Se essa etapa não tiver êxito, erros semelhantes aos abaixo poderão ocorrer. Para corrigir, é possível executar `apt update` ou `yum update` ou `dnf update` antes de executar `nodeadm install`. Também é possível tentar executar `nodeadm install` novamente.
```
failed to run update using package manager
```
**Tempo limite ou prazo de contexto excedido**
Ao executar `nodeadm install`, se você observar problemas em várias etapas do processo de instalação com erros que indicam que houve um tempo limite ou que o prazo do contexto foi excedido, você pode ter uma conexão lenta que está impedindo a instalação das dependências dos nós híbridos antes que os tempos limite sejam atingidos. Para contornar esses problemas, você pode tentar usar o sinalizador `--timeout` em `nodeadm` para estender a duração dos tempos limite para baixar as dependências.
```
nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --timeout {{20m0s}}
```
## Solução de problemas de conexão de nós híbridos
Os tópicos de solução de problemas nesta seção estão relacionados ao processo de conexão de nós híbridos a clusters do EKS com o comando `nodeadm init`.
**Erros de operação ou esquema não compatível**
Ao executar `nodeadm init`, se você encontrar erros relacionados a `operation error` ou `unsupported scheme`, verifique o `nodeConfig.yaml` para garantir que esteja formatado corretamente e tenha sido passado para `nodeadm`. Para obter mais informações sobre o formato e as opções para `nodeConfig.yaml`, consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md).
```
"msg":"Command failed","error":"operation error ec2imds: GetRegion, request canceled, context deadline exceeded"
```
**Perfil do IAM de nós híbridos sem permissões para a ação `eks:DescribeCluster`**
Durante a execução do `nodeadm init`, o `nodeadm` tenta obter informações sobre seu cluster do EKS ao chamar a ação `DescribeCluster` do EKS. Se o perfil do IAM do Hybrid Nodes não tiver permissão para realizar a ação `eks:DescribeCluster`, será necessário informar o endpoint da API do Kubernetes, o pacote da CA do cluster e o intervalo CIDR IPv4 do serviço na configuração do nó que você transmite ao `nodeadm` ao executar `nodeadm init`. Para obter mais informações sobre as permissões necessárias para o perfil do IAM de nós híbridos, consulte [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md).
```
"msg":"Command failed","error":"operation error EKS: DescribeCluster, https response error StatusCode: 403 ... AccessDeniedException"
```
**Perfil do IAM de nós híbridos sem permissões para a ação `eks:ListAccessEntries`**
Durante a execução do `nodeadm init`, o `nodeadm` tenta validar se o seu cluster do EKS contém uma entrada de acesso do tipo `HYBRID_LINUX` associada ao perfil do IAM do Hybrid Nodes ao chamar a ação `ListAccessEntries` do EKS. Se o perfil do IAM do Hybrid Nodes não tiver permissão para realizar a ação `eks:ListAccessEntries`, será necessário informar o sinalizador `--skip cluster-access-validation` ao executar o comando `nodeadm init`. Para obter mais informações sobre as permissões necessárias para o perfil do IAM de nós híbridos, consulte [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md).
```
"msg":"Command failed","error":"operation error EKS: ListAccessEntries, https response error StatusCode: 403 ... AccessDeniedException"
```
**O IP do nó não está no CIDR da rede do nó remoto**
Ao executar `nodeadm init`, você poderá encontrar um erro se o endereço IP do nó não estiver dentro dos CIDRs da rede do nó remoto especificado. O erro será semelhante ao seguinte exemplo:
```
node IP 10.18.0.1 is not in any of the remote network CIDR blocks [10.0.0.0/16 192.168.0.0/16]
```
Este exemplo mostra um nó com IP 10.18.0.1 tentando ingressar em um cluster com os CIDRs de rede remota 10.0.0.0/16 e 192.168.0.0/16. O erro ocorre porque 10.18.0.1 não faz parte de nenhum dos intervalos.
Confirme se você configurou corretamente o seu `RemoteNodeNetworks` para incluir todos os endereços IP de nós. Para obter mais informações sobre a configuração da rede, consulte [Preparar a rede para nós híbridos](hybrid-nodes-networking.md).
+ Execute o comando a seguir na região em que seu cluster está localizado para verificar suas configurações de `RemoteNodeNetwork`. Verifique se os blocos CIDR listados na saída incluem o intervalo de IP do seu nó e são iguais aos blocos CIDR listados na mensagem de erro. Se eles não corresponderem, confirme se o nome do cluster e a região em seu cluster do `nodeConfig.yaml` correspondem ao cluster pretendido.
```
aws eks describe-cluster --name {{CLUSTER_NAME}} --region REGION_NAME --query cluster.remoteNetworkConfig.remoteNodeNetworks
```
+ Verifique se você está trabalhando com o nó pretendido:
+ Confirme se você está no nó correto verificando se o nome do host e o endereço IP correspondem aos que você pretende registrar no cluster.
+ Confirme se esse nó está na rede on-premises correta (aquela cujo intervalo de CIDR foi registrado como `RemoteNodeNetwork` durante a configuração do cluster).
Se o IP do seu nó ainda não for o esperado, verifique o seguinte:
+ Se você estiver usando o IAM Roles Anywhere, o `kubelet` realizará uma pesquisa de DNS em `nodeName` do IAM Roles Anywhere e usará um IP associado ao nome do nó, se disponível. Se você mantiver entradas de DNS para seus nós, confirme se essas entradas apontam para IPs pertencentes aos CIDRs da rede dos nós remotos.
+ Se seu nó tiver várias interfaces de rede, `kubelet` poderá selecionar uma interface com um endereço IP fora dos CIDRs de rede do nó remoto como padrão. Para usar uma interface diferente, especifique seu endereço IP usando o sinalizador `--node-ip` do `kubelet` em seu `nodeConfig.yaml`. Para obter mais informações, consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md). É possível visualizar as interfaces de rede do seu nó e seus endereços IP executando o seguinte comando no nó:
```
ip addr show
```
**Os nós híbridos não estão aparecendo no cluster do EKS**
Se você executou `nodeadm init` e ele foi concluído, mas os nós híbridos não aparecem no cluster, pode haver problemas com a conexão de rede entre os nós híbridos e o ambiente de gerenciamento do EKS, você pode não ter as permissões de grupo de segurança necessárias configuradas ou você pode não ter o mapeamento necessário do perfil do IAM de nós híbridos para o controle de acesso por perfil (RBAC) do Kubernetes. Você pode iniciar o processo de depuração verificando o status do `kubelet` e os logs do `kubelet` com os comandos a seguir. Execute os comandos a seguir nos nós híbridos que não conseguiram se unir ao cluster.
```
systemctl status kubelet
```
```
journalctl -u kubelet -f
```
**Não é possível se comunicar com o cluster**
Se o nó híbrido não conseguiu se comunicar com o ambiente de gerenciamento do cluster, talvez você veja logs semelhantes aos abaixo.
```
"Failed to ensure lease exists, will retry" err="Get ..."
```
```
"Unable to register node with API server" err="Post ..."
```
```
Failed to contact API server when waiting for CSINode publishing ... dial tcp : i/o timeout
```
Se você vir essas mensagens, verifique as informações abaixo para garantir que atenda aos requisitos de nós híbridos detalhados em [Preparar a rede para nós híbridos](hybrid-nodes-networking.md).
+ Confirme se a VPC passada para o cluster do EKS tem rotas para o gateway de trânsito (TGW) ou o gateway privado virtual (VGW) para seu nó on-premises e, opcionalmente, CIDRs de pods.
+ Confirme se você tem um grupo de segurança adicional para o cluster do EKS com regras de entrada para os CIDRs de nós on-premises e, opcionalmente, para CIDRs de pods.
+ Confirme se o roteador on-premises está configurado para permitir o tráfego de e para o ambiente de gerenciamento do EKS.
**Não autorizado**
Se o nó híbrido conseguiu se comunicar com o ambiente de gerenciamento do EKS, mas não conseguiu se registrar, você poderá ver logs semelhantes aos a seguir. Observe que a principal diferença nas mensagens de logs abaixo é o erro `Unauthorized`. Isso indica que o nó não conseguiu realizar suas tarefas porque não tem as permissões necessárias.
```
"Failed to ensure lease exists, will retry" err="Unauthorized"
```
```
"Unable to register node with API server" err="Unauthorized"
```
```
Failed to contact API server when waiting for CSINode publishing: Unauthorized
```
Se você vir essas mensagens, verifique as informações a seguir para garantir que atenda aos requisitos de nós híbridos detalhados em [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md) e [Preparar o acesso ao cluster para nós híbridos](hybrid-nodes-cluster-prep.md).
+ Confirme se a identidade dos nós híbridos corresponde ao perfil do IAM de nós híbridos esperado. Isso pode ser feito executando `sudo aws sts get-caller-identity` nos nós híbridos.
+ Confirme se o perfil do IAM de nós híbridos tem as permissões necessárias.
+ Confirme se em seu cluster você tem uma entrada de acesso ao EKS para o perfil do IAM de nós híbridos, ou confirme se o ConfigMap `aws-auth` tem uma entrada para o perfil do IAM de nós híbridos. Se você estiver usando entradas de acesso ao EKS, confirme se a entrada de acesso do perfil do IAM de nós híbridos tem o tipo de acesso `HYBRID_LINUX`. Se você estiver usando o ConfigMap `aws-auth`, confirme se a entrada para o perfil do IAM de nós híbridos atende aos requisitos e à formatação detalhados em [Preparar o acesso ao cluster para nós híbridos](hybrid-nodes-cluster-prep.md).
### Nós híbridos registrados no cluster do EKS, mas mostram o status `Not Ready`
Se os nós híbridos tiverem sido registrados com êxito no cluster do EKS, mas mostrarem o status `Not Ready`, a primeira coisa a verificar é o status da interface de rede de contêineres (CNI). Se você não instalou uma CNI, é esperado que os nós híbridos tenham o status `Not Ready`. Depois que uma CNI é instalada e executada com êxito, os nós são atualizados para o status `Ready`. Se você tentou instalar uma CNI, mas ela não está sendo executada com êxito, consulte [Solução de problemas da CNI em nós híbridos](#hybrid-nodes-troubleshooting-cni) nesta página.
**As solicitações de assinatura de certificado (CSRs) estão pendentes**
Depois de conectar os nós híbridos ao cluster do EKS, se você perceber que há CSRs pendentes para os nós híbridos, isso significa que eles não estão atendendo aos requisitos de aprovação automática. As CSRs para nós híbridos serão aprovadas e emitidas automaticamente se tiverem sido criadas por um nó com o rótulo `eks.amazonaws.com/compute-type: hybrid` e tiverem os seguintes nomes alternativos de assunto (SANs): pelo menos um SAN DNS igual ao nome do nó e os SANs IP pertencerem aos CIDRs da rede remota de nós.
**O usuário híbrido já existe**
Caso tenha alterado a configuração do `nodeadm` e registrado novamente o nó com a nova configuração, você poderá ver um erro informando que o usuário híbrido já existe, mas que seu conteúdo foi alterado. Em vez de executar `nodeadm init` entre as alterações de configuração, execute `nodeadm uninstall` seguido de um `nodeadm install` e `nodeadm init`. Isso garante uma limpeza adequada com as alterações na configuração.
```
"msg":"Command failed","error":"hybrid profile already exists at /etc/aws/hybrid/config but its contents do not align with the expected configuration"
```
**O nó híbrido falhou ao resolver a API privada**
Após executar `nodeadm init`, se você observar um erro nos logs do `kubelet` que mostra falhas ao contatar o servidor da API do Kubernetes do EKS porque há `no such host`, talvez seja necessário alterar sua entrada de DNS para o endpoint da API do Kubernetes do EKS na rede on-premises ou no nível do host. Consulte [Forwarding inbound DNS queries to your VPC](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html) na *documentação do AWS Route 53*.
```
Failed to contact API server when waiting for CSINode publishing: Get ... no such host
```
**Não é possível visualizar nós híbridos no console do EKS**
Se você registrou os nós híbridos, mas não consegue visualizá-los no console do EKS, verifique as permissões da entidade principal do IAM que você está usando para visualizar o console. A entidade principal do IAM que você está usando deve ter permissões mínimas específicas do IAM e do Kubernetes para visualizar os recursos no console. Para obter mais informações, consulte [Visualize os recursos do Kubernetes na seção Console de gerenciamento da AWS](view-kubernetes-resources.md).
## Solução de problemas de execução de nós híbridos
Se os nós híbridos registrados no cluster do EKS tinham o status `Ready` e depois passaram para o status `Not Ready`, há uma ampla gama de problemas que podem ter contribuído para o status de não íntegro, como a falta de recursos suficientes para CPU, memória ou espaço em disco disponível, ou o nó está desconectado do ambiente de gerenciamento do EKS. Você pode usar as etapas abaixo para solucionar problemas nos nós e, se não conseguir resolver o problema, entre em contato com o AWS Support.
Execute `nodeadm debug` nos nós híbridos para validar se os requisitos de rede e credenciais foram atendidos. Para obter mais informações sobre o comando `nodeadm debug`, consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md).
**Obter status do nó**
```
kubectl get nodes -o wide
```
**Verificar condições e eventos do nó**
```
kubectl describe node {{NODE_NAME}}
```
**Obter status do pod**
```
kubectl get pods -A -o wide
```
**Verificar condições e eventos do pod**
```
kubectl describe pod {{POD_NAME}}
```
**Verificar logs do pod**
```
kubectl logs {{POD_NAME}}
```
**Verificar os logs do `kubectl`**
```
systemctl status kubelet
```
```
journalctl -u kubelet -f
```
**Falha nas sondas de liveness do pod ou os webhooks não estão funcionando**
Se as aplicações, os complementos ou os webhooks executados nos nós híbridos não estiverem iniciando corretamente, você poderá observar problemas de rede que bloqueiam a comunicação com os pods. Para que o ambiente de gerenciamento do EKS faça contato com os webhooks em execução nos nós híbridos, você deve configurar o cluster do EKS com uma rede remota de pod e ter rotas para o CIDR de pods on-premises na tabela de roteamento da VPC com o destino como o gateway de trânsito (TGW), o gateway privado virtual (VGW) ou outro gateway que você esteja usando para conectar a VPC à rede on-premises. Para obter mais informações sobre os requisitos de rede para nós híbridos, consulte [Preparar a rede para nós híbridos](hybrid-nodes-networking.md). Além disso, você deve permitir esse tráfego no firewall on-premises e garantir que o roteador possa rotear adequadamente para os pods. Consulte [Configurar webhooks para nós híbridos](hybrid-nodes-webhooks.md) para obter mais informações sobre os requisitos para executar webhooks em nós híbridos.
Uma mensagem comum de log de pod para esse cenário é mostrada abaixo, em que ip-address é o IP do cluster para o serviço do Kubernetes.
```
dial tcp :443: connect: no route to host
```
**Comandos `kubectl logs` ou `kubectl exec` não estão funcionando (comandos da API do `kubelet`)**
Se os comandos `kubectl attach`, `kubectl cp`, `kubectl exec`, `kubectl logs` e `kubectl port-forward` atingirem o tempo limite, enquanto outros comandos `kubectl` funcionam com êxito, o problema provavelmente está relacionado à configuração da rede remota. Esses comandos se conectam por meio do cluster ao endpoint `kubelet` no nó. Para obter mais informações, consulte [Endpoint do `kubelet`](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-kubelet-api).
Verifique se seus IPs de nó e IPs de pod se enquadram na rede de nós remotos e nos CIDRs da rede de pods remotos configurados para seu cluster. Use os comandos abaixo para examinar as atribuições de IP.
```
kubectl get nodes -o wide
```
```
kubectl get pods -A -o wide
```
Compare esses IPs com seus CIDRs de rede remota configurados para garantir o roteamento adequado. Para requisitos de configuração de rede, consulte [Preparar a rede para nós híbridos](hybrid-nodes-networking.md).
## Solução de problemas da CNI em nós híbridos
Se, a princípio, você encontrar problemas ao iniciar o Cilium ou o Calico com nós híbridos, geralmente é devido a problemas de rede entre os nós híbridos ou os pods da CNI executados em nós híbridos e o ambiente de gerenciamento do EKS. Certifique-se de que seu ambiente atenda aos requisitos em Preparar a rede para nós híbridos. É útil dividir o problema em partes.
Configuração do cluster do EKS
As configurações de RemoteNodeNetwork e RemotePodNetwork estão corretas?
Configuração de VPC
Há rotas para RemoteNodeNetwork e RemotePodNetwork na tabela de roteamento da VPC com o destino do gateway de trânsito ou do gateway privado virtual?
Configuração do security group
Existem regras de entrada e saída para RemoteNodeNetwork e RemotePodNetwork?
Rede on-premises
Existem rotas e acesso de e para o ambiente de gerenciamento do EKS e de e para os nós híbridos e os pods executados em nós híbridos?
Configuração da CNI
Se estiver usando uma rede de sobreposição, a configuração do grupo de IPs para a CNI corresponderá à RemotePodNetwork configurada para o cluster do EKS se estiver usando webhooks?
**O nó híbrido tem o status `Ready` sem uma CNI instalada**
Se os nós híbridos estiverem mostrando o status `Ready`, mas você não instalou uma CNI no cluster, é possível que haja artefatos de CNI antigos nos nós híbridos. Por padrão, quando você desinstala o Cilium e o Calico com ferramentas como o Helm, os recursos em disco não são removidos das máquinas físicas ou virtuais. Além disso, as definições de recursos personalizados (CRDs) dessas CNIs ainda podem estar presentes no cluster de uma instalação antiga. Para obter mais informações, consulte as seções Excluir Cilium e Excluir Calico de [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md).
**Solução de problemas do Cilium**
Caso esteja tendo problemas ao executar o Cilium em nós híbridos, consulte [as etapas de solução de problemas](https://docs.cilium.io/en/stable/operations/troubleshooting/) na documentação do Cilium. As seções abaixo abordam problemas que podem ser exclusivos da implantação do Cilium em nós híbridos.
**O Cilium não está iniciando**
Se os agentes do Cilium que são executados em cada nó híbrido não estiverem iniciando, verifique os logs dos pods do agente do Cilium em busca de erros. O agente do Cilium requer conectividade com o endpoint da API do Kubernetes do EKS para iniciar. A inicialização do agente do Cilium falhará se essa conectividade não estiver configurada corretamente. Nesse caso, você verá mensagens de log semelhantes às abaixo nos logs do pod do agente do Cilium.
```
msg="Unable to contact k8s api-server"
level=fatal msg="failed to start: Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout"
```
O agente do Cilium é executado na rede do host. O cluster do EKS deve ser configurado com `RemoteNodeNetwork` para a conectividade do Cilium. Confirme se você tem um grupo de segurança adicional para o cluster do EKS com uma regra de entrada para `RemoteNodeNetwork`, se você tem rotas na VPC para `RemoteNodeNetwork` e se a rede on-premises está configurada corretamente para permitir a conectividade com o ambiente de gerenciamento do EKS.
Se o operador do Cilium estiver em execução, e alguns dos agentes do Cilium estiverem em execução, mas não todos, confirme se você tem IPs de pods disponíveis para alocar para todos os nós do cluster. Você configura o tamanho dos CIDRs de pods alocáveis ao usar o IPAM do grupo de clusters com `clusterPoolIPv4PodCIDRList` na configuração do Cilium. O tamanho do CIDR por nó é configurado com a definição de `clusterPoolIPv4MaskSize` na configuração do Cilium. Consulte [Expanding the cluster pool](https://docs.cilium.io/en/stable/network/concepts/ipam/cluster-pool/#expanding-the-cluster-pool) na documentação do Cilium para obter mais informações.
**O BGP do Cilium não está funcionando**
Se você estiver usando o ambiente de gerenciamento do BGP do Cilium para anunciar os endereços de pod ou serviço na rede on-premises, você poderá usar os comandos a seguir da CLI do Cilium para verificar se o BGP está anunciando as rotas para os recursos. Para obter as etapas de instalação da CLI do Cilium, consulte [Install the Cilium CLI](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#install-the-cilium-cli) na documentação do Cilium.
Caso o BGP esteja funcionando corretamente, você deverá ver os nós híbridos com o estado da sessão `established` na saída. Talvez seja necessário trabalhar com a equipe de rede para identificar os valores corretos para o AS local, AS do par e Endereço do par do ambiente.
```
cilium bgp peers
```
```
cilium bgp routes
```
Se você estiver usando o BGP do Cilium para anunciar os IPs dos serviços com o tipo `LoadBalancer`, você deverá ter o mesmo rótulo tanto em `CiliumLoadBalancerIPPool` quanto no serviço, que deve ser usado no seletor de `CiliumBGPAdvertisement`. Um exemplo é mostrado abaixo. Observe que, se você estiver usando o BGP do Cilium para anunciar os IPs dos serviços com o tipo LoadBalancer, as rotas do BGP poderão ser interrompidas durante a reinicialização do agente do Cilium. Para obter mais informações, consulte [Failure Scenarios](https://docs.cilium.io/en/latest/network/bgp-control-plane/bgp-control-plane-operation/#failure-scenarios) na documentação do Cilium.
**Serviço**
```
kind: Service
apiVersion: v1
metadata:
name: guestbook
labels:
app: guestbook
spec:
ports:
- port: 3000
targetPort: http-server
selector:
app: guestbook
type: LoadBalancer
```
**CiliumLoadBalancerIPPool**
```
apiVersion: cilium.io/v2alpha1
kind: CiliumLoadBalancerIPPool
metadata:
name: guestbook-pool
labels:
app: guestbook
spec:
blocks:
- cidr:
serviceSelector:
matchExpressions:
- { key: app, operator: In, values: [ guestbook ] }
```
**CiliumBGPAdvertisement**
```
apiVersion: cilium.io/v2alpha1
kind: CiliumBGPAdvertisement
metadata:
name: bgp-advertisements-guestbook
labels:
advertise: bgp
spec:
advertisements:
- advertisementType: "Service"
service:
addresses:
- ExternalIP
- LoadBalancerIP
selector:
matchExpressions:
- { key: app, operator: In, values: [ guestbook ] }
```
**Solução de problemas do Calico**
Se você estiver tendo problemas ao executar o Calico em nós híbridos, consulte [as etapas de solução de problemas](https://docs.tigera.io/calico/latest/operations/troubleshoot/) na documentação do Calico. As seções abaixo abordam problemas que podem ser exclusivos da implantação do Calico em nós híbridos.
A tabela abaixo resume os componentes do Calico e se eles são executados na rede de nós ou de pods por padrão. Se você configurou o Calico para usar NAT para tráfego de saída de pods, a rede on-premises deve estar configurada para rotear o tráfego para o CIDR de nós on-premises, e as tabelas de roteamento da VPC devem ser configuradas com uma rota para o CIDR de nós on-premises com o gateway de trânsito (TGW) ou o gateway privado virtual (VGW) como destino. Se você não estiver configurando o Calico para usar NAT para tráfego de saída de pods, a rede on-premises deverá estar configurada para rotear o tráfego para o CIDR de pod on-premises, e as tabelas de roteamento da VPC devem ser configuradas com uma rota para o CIDR de pods on-premises com o gateway de trânsito (TGW) ou o gateway privado virtual (VGW) como destino.
| Componente | Rede |
| --- | --- |
| Servidor da API do Calico | Nó |
| Calico Controllers for Kubernetes | Pod |
| Agente de nós do Calico | Nó |
| Calico `typha` | Nó |
| Driver de nós da CSI do Calico | Pod |
| Operador do Calico | Nó |
**Recursos do Calico são programados ou executados em nós isolados**
Os recursos do Calico que não são executados como um DaemonSet têm tolerâncias flexíveis por padrão que permitem que sejam programados em nós isolados que não estão prontos para programar ou executar pods. Você pode restringir as tolerâncias para os recursos do Calico que não são DaemonSet alterando a instalação do operador para incluir o abaixo.
```
installation:
...
controlPlaneTolerations:
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
calicoKubeControllersDeployment:
spec:
template:
spec:
tolerations:
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
typhaDeployment:
spec:
template:
spec:
tolerations:
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
```
## Solução de problemas de credenciais
Para ativações híbridas do AWS SSM e AWS IAM Roles Anywhere, você pode validar se as credenciais do perfil do IAM de nós híbridos estão configuradas corretamente nos nós híbridos ao executar o comando a seguir nos nós híbridos. Confirme se o nome do nó e o nome do perfil do IAM de nós híbridos são os esperados.
```
sudo aws sts get-caller-identity
```
```
{
"UserId": "ABCDEFGHIJKLM12345678910:",
"Account": "",
"Arn": "arn:aws:sts:::assumed-role/"
}
```
** AWS Solução de problemas do Systems Manager (SSM**
Se você estiver usando ativações híbridas do AWS SSM para as credenciais de nós híbridos, esteja ciente dos diretórios e artefatos do SSM a seguir que são instalados nos nós híbridos pelo `nodeadm`. Para obter mais informações sobre o SSM Agente, consulte [Trabalhar com o SSM Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) no *Guia do usuário do AWS Systems Manager*.
| Descrição | Local |
| --- | --- |
| SSM agent | Ubuntu: `/snap/amazon-ssm-agent/current/amazon-ssm-agent` RHEL e AL2023: `/usr/bin/amazon-ssm-agent` |
| Registros de atendentes do SSM | `/var/log/amazon/ssm` |
| Credenciais AWS | `/root/.aws/credentials` |
| CLI de configuração do SSM | `/opt/ssm/ssm-setup-cli` |
**Reiniciar o SSM Agent**
Alguns problemas podem ser resolvidos ao reiniciar o SSM Agent. Você pode usar os comandos abaixo para reiniciá-lo.
**AL2023 e outros sistemas operacionais**
```
systemctl restart amazon-ssm-agent
```
**Ubuntu**
```
systemctl restart snap.amazon-ssm-agent.amazon-ssm-agent
```
**Verificar a conectividade com os endpoints do SSM**
Confirme se você pode se conectar aos endpoints do SSM nos nós híbridos. Para obter uma lista de endpoints do SSM, consulte [AWS Systems Manager endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/ssm.html). Substitua `us-west-2` no comando abaixo pela região da AWS para sua ativação híbrida do AWS SSM.
```
ping ssm.us-west-2.amazonaws.com
```
**Visualizar o status da conexão das instâncias registradas do SSM**
Você pode verificar o status da conexão das instâncias registradas com ativações híbridas do SSM com o comando da AWS CLI a seguir. Substitua o ID da máquina pelo ID da máquina da sua instância.
```
aws ssm get-connection-status --target {{mi-012345678abcdefgh}}
```
**Incompatibilidade da soma de verificação da CLI de configuração do SSM**
Caso encontre um problema com a incompatibilidade da soma de verificação `ssm-setup-cli` ao executar `nodeadm install`, você deve confirmar que não há instalações mais antigas do SSM existentes no host. Se houver instalações mais antigas do SSM no host, remova-as e execute novamente `nodeadm install` para resolver o problema.
```
Failed to perform agent-installation/on-prem registration: error while verifying installed ssm-setup-cli checksum: checksum mismatch with latest ssm-setup-cli.
```
**do SSM `InvalidActivation` **
Se você vir um erro ao registrar a instância com o AWS SSM, confirme se `region`, `activationCode` e `activationId` em `nodeConfig.yaml` estão corretos. A região da AWS para o cluster do EKS deve corresponder à região da ativação híbrida do SSM. Se esses valores estiverem configurados incorretamente, você verá um erro semelhante ao abaixo.
```
ERROR Registration failed due to error registering the instance with AWS SSM. InvalidActivation
```
**`ExpiredTokenException` do SSM: o token de segurança incluído na solicitação está expirado**
Se o SSM Agent não conseguir atualizar as credenciais, você poderá observar um `ExpiredTokenException`. Nesse cenário, se você conseguir se conectar aos endpoints do SSM nos nós híbridos, talvez seja necessário reiniciar o SSM Agent para forçar uma atualização da credencial.
```
"msg":"Command failed","error":"operation error SSM: DescribeInstanceInformation, https response error StatusCode: 400, RequestID: eee03a9e-f7cc-470a-9647-73d47e4cf0be, api error ExpiredTokenException: The security token included in the request is expired"
```
**Erro do SSM ao executar o comando de registro de máquina**
Se você observar um erro ao registrar a máquina com o SSM, talvez seja necessário executar `nodeadm install` novamente para garantir que todas as dependências do SSM estejam instaladas corretamente.
```
"error":"running register machine command: , error: fork/exec /opt/aws/ssm-setup-cli: no such file or directory"
```
**do SSM `ActivationExpired` **
Durante a execução de `nodeadm init`, se você vir um erro ao registrar a instância com o SSM devido a uma ativação expirada, você precisará criar uma ativação híbrida do SSM, atualizar `nodeConfig.yaml` com `activationCode` e `activationId` da nova ativação híbrida do SSM e executar `nodeadm init` novamente.
```
"msg":"Command failed","error":"SSM activation expired. Please use a valid activation"
```
```
ERROR Registration failed due to error registering the instance with AWS SSM. ActivationExpired
```
**O SSM falhou ao atualizar as credenciais em cache**
Se você perceber uma falha na atualização das credenciais em cache, o arquivo `/root/.aws/credentials` pode ter sido excluído do host. Primeiro, verifique a ativação híbrida do SSM e certifique-se de que ela esteja ativa e que os nós híbridos estejam configurados corretamente para usar a ativação. Verifique os logs do SSM Agent em `/var/log/amazon/ssm` e execute novamente o comando `nodeadm init` depois de resolver o problema no lado do SSM.
```
"Command failed","error":"operation error SSM: DescribeInstanceInformation, get identity: get credentials: failed to refresh cached credentials"
```
**Limpar o SSM**
Para remover o SSM Agent do host, você pode executar os comandos a seguir.
```
dnf remove -y amazon-ssm-agent
sudo apt remove --purge amazon-ssm-agent
snap remove amazon-ssm-agent
rm -rf /var/lib/amazon/ssm/Vault/Store/RegistrationKey
```
** AWS Solução de problemas do IAM Roles Anywhere**
Se você estiver usando o AWS IAM Roles Anywhere para as credenciais dos nós híbridos, esteja ciente dos diretórios e artefatos a seguir que são instalados nos nós híbridos pelo `nodeadm`. Para obter mais informações sobre a solução de problemas do IAM Roles Anywhere, consulte [Troubleshooting AWS IAM Roles Anywhere identity and access](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/security_iam_troubleshoot.html) no *Guia do usuário do AWS IAM Roles Anywhere*.
| Descrição | Local |
| --- | --- |
| CLI do IAM Roles Anywhere | `/usr/local/bin/aws_signing_helper` |
| Local e nome padrão do certificado | `/etc/iam/pki/server.pem` |
| Local e nome padrão da chave | `/etc/iam/pki/server.key` |
**O IAM Roles Anywhere falhou ao atualizar as credenciais em cache**
Se você observar uma falha na atualização das credenciais em cache, revise o conteúdo de `/etc/aws/hybrid/config` e confirme se o IAM Roles Anywhere foi configurado corretamente na sua configuração do `nodeadm`. Confirme se `/etc/iam/pki` existe. Cada nó deve ter um certificado e uma chave exclusivos. Por padrão, ao usar o IAM Roles Anywhere como provedor de credenciais, o `nodeadm` usa `/etc/iam/pki/server.pem` para o local e o nome do certificado e `/etc/iam/pki/server.key` para a chave privada. Talvez seja necessário criar os diretórios antes de colocar os certificados e as chaves nos diretórios com `sudo mkdir -p /etc/iam/pki`. Você pode verificar o conteúdo do certificado com o comando abaixo.
```
openssl x509 -text -noout -in server.pem
```
```
open /etc/iam/pki/server.pem: no such file or directory
could not parse PEM data
Command failed {"error": "... get identity: get credentials: failed to refresh cached credentials, process provider error: error in credential_process: exit status 1"}
```
**IAM Roles Anywhere não autorizado a executar `sts:AssumeRole` **
Nos logs do `kubelet`, se você vir um problema de acesso negado para a operação `sts:AssumeRole` ao usar o IAM Roles Anywhere, verifique a política de confiança do perfil do IAM de nós híbridos para confirmar se a entidade principal do serviço do IAM Roles Anywhere tem permissão para assumir o perfil do IAM de nós híbridos. Além disso, confirme se o ARN da âncora de confiança está configurado corretamente na política de confiança do perfil do IAM de nós híbridos, e se este foi adicionado ao seu usuário do IAM Roles Anywhere.
```
could not get token: AccessDenied: User: ... is not authorized to perform: sts:AssumeRole on resource: ...
```
**IAM Roles Anywhere não autorizado a definir `roleSessionName` **
Nos logs do `kubelet`, se você vir um problema de acesso negado para definir `roleSessionName`, confirme que você definiu `acceptRoleSessionName` como true para seu usuário do IAM Roles Anywhere.
```
AccessDeniedException: Not authorized to set roleSessionName
```
## Solução de problemas do sistema operacional
### RHEL
**Falhas no registro do gerenciador de direitos ou assinaturas**
Se você estiver executando `nodeadm install` e encontrar uma falha na instalação das dependências dos nós híbridos devido a problemas de registro de direitos, certifique-se de ter definido corretamente a senha e o nome de usuário do Red Hat no host.
```
This system is not registered with an entitlement server
```
### Ubuntu
**GLIBC não encontrado**
Se estiver usando o Ubuntu como o sistema operacional e o IAM Roles Anywhere como o provedor de credenciais com nós híbridos e verificar um problema com o GLIBC não encontrado, você poderá instalar essa dependência manualmente para resolver o problema.
```
GLIBC_2.32 not found (required by /usr/local/bin/aws_signing_helper)
```
Execute os seguintes comandos para instalar a dependência:
```
ldd --version
sudo apt update && apt install libc6
sudo apt install glibc-source
```
### Bottlerocket
Se o contêiner de administração do Bottlerocket estiver habilitado, você poderá acessá-lo via SSH para depuração avançada e solução de problemas com privilégios elevados. As seções a seguir contêm comandos que precisam ser executados no contexto do host do Bottlerocket. Quando estiver no contêiner de administração, você poderá executar `sheltie` para abrir um shell com privilégios totais de usuário-raiz no host do Bottlerocket.
```
sheltie
```
Você também pode executar os comandos nas seções a seguir a partir do shell do contêiner de administração prefixando cada comando com `sudo chroot /.bottlerocket/rootfs`.
```
sudo chroot /.bottlerocket/rootfs
```
**Usar o logdog para coletar logs**
O Bottlerocket fornece o utilitário `logdog` para coletar logs e informações do sistema de forma eficiente para fins de solução de problemas.
```
logdog
```
O utilitário `logdog` reúne logs de vários locais em um host do Bottlerocket e os combina em um arquivo tarball. Por padrão, o arquivo tarball será criado em `/var/log/support/bottlerocket-logs.tar.gz` e pode ser acessado via contêineres do host em `/.bottlerocket/support/bottlerocket-logs.tar.gz`.
**Acessar logs do sistema com journalctl**
Você pode verificar o status dos vários serviços do sistema, como `kubelet`, `containerd`, etc., e visualizar seus logs com os comandos a seguir. A flag `-f` acompanhará os logs em tempo real.
Para verificar o status do serviço `kubelet` e recuperar logs do `kubelet`, execute:
```
systemctl status kubelet
journalctl -u kubelet -f
```
Para verificar o status do serviço `containerd` e recuperar os logs da instância orquestrada do `containerd`, execute:
```
systemctl status containerd
journalctl -u containerd -f
```
Para verificar o status do serviço `host-containerd` e recuperar os logs da instância host do `containerd`, execute:
```
systemctl status host-containerd
journalctl -u host-containerd -f
```
Para recuperar os logs dos contêineres de bootstrap e contêineres de host, execute:
```
journalctl _COMM=host-ctr -f
```