**Contribuisci a migliorare questa pagina**
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Per contribuire a questa guida per l'utente, scegli il GitHub ** link ** Modifica questa pagina su che si trova nel riquadro destro di ogni pagina.
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Risoluzione dei problemi relativi ai nodi ibridi
Questo argomento illustra alcuni errori comuni che si potrebbero verificare durante l’utilizzo di Amazon EKS Hybrid Nodes, e il modo in cui ripararli. Per altre informazioni sulla risoluzione dei problemi, consulta [Risoluzione dei problemi con i cluster e i nodi Amazon EKS](troubleshooting.md) il tag [ Knowledge Center per Amazon EKS ](https://repost.aws/tags/knowledge-center/TA4IvCeWI1TE66q4jEj4Z9zg/amazon-elastic-kubernetes-service) su * AWS * re:POST. Se non riesci a risolvere il problema, contatta l'assistenza. AWS
**Versione node/adm richiesta per il provider di credenziali SSM**
Se si utilizza AWS Systems Manager (SSM) come provider di credenziali per i nodi ibridi, è necessario utilizzare la `nodeadm` versione `1.0.19` o successiva per le nuove installazioni e gli aggiornamenti. Le versioni precedenti di `nodeadm` contengono una chiave di firma SSM obsoleta e hanno esito negativo durante `nodeadm install` e `nodeadm upgrade` con il seguente errore di verifica della firma:
```
"msg":"Command failed","error":"failed to install ssm installer: validating ssm-setup-cli signature: Signature Verification Error: No matching signature"
```
Per risolvere questo errore, [ scarica la versione più recente ](hybrid-nodes-nodeadm.md#hybrid-nodes-nodeadm-download) di `nodeadm` prima di eseguire `nodeadm install` o. `nodeadm upgrade`
**Risoluzione dei problemi dei nodi con `nodeadm debug`**. Puoi eseguire il comando `nodeadm debug` dai nodi ibridi per verificare che i requisiti di rete e le credenziali siano soddisfatti. Per ulteriori informazioni sul comando `nodeadm debug`, consulta [Nodi ibridi di `riferimento nodeadm`](hybrid-nodes-nodeadm.md).
**Rileva i problemi con i tuoi nodi ibridi con le informazioni sul cluster**. Le informazioni sul cluster Amazon EKS includono *controlli approfonditi* che rilevano problemi comuni con la configurazione dei nodi ibridi EKS nel cluster. Puoi visualizzare i risultati di tutti i controlli approfonditi da Console di gestione AWS, AWS CLI e AWS SDK. Per ulteriori informazioni sulle informazioni sul cluster, consulta [Prepararsi agli aggiornamenti delle versioni di Kubernetes e risolvere i problemi di configurazione errata con gli approfondimenti sui cluster](cluster-insights.md).
## Risoluzione dei problemi di installazione dei nodi ibridi
I seguenti argomenti di risoluzione dei problemi riguardano l’installazione delle dipendenze dei nodi ibridi sugli host con il comando `nodeadm install`.
** Comando `nodeadm` non riuscito per `must run as root` **
Il comando `nodeadm install` deve essere eseguito con un utente che dispone di root o privilegi `sudo` sull’host. Se esegui `nodeadm install` con un utente che non dispone di root o privilegi `sudo`, nell’output `nodeadm` verrà visualizzato il seguente errore.
```
"msg":"Command failed","error":"must run as root"
```
**Impossibile connettersi alle dipendenze**
Il comando `nodeadm install` installa le dipendenze richieste per i nodi ibridi. Le dipendenze dei nodi ibridi includono`containerd`, `kubelet``kubectl`, e i componenti AWS SSM o AWS IAM Roles Anywhere. Devi avere accesso da dove stai eseguendo `nodeadm install` per scaricare queste dipendenze. Per ulteriori informazioni sull’elenco delle posizioni a cui devi poter accedere, consulta [Preparazione della rete per i nodi ibridi](hybrid-nodes-networking.md). Se non disponi dell’accesso, nell’output `nodeadm install` verranno visualizzati errori simili ai seguenti.
```
"msg":"Command failed","error":"failed reading file from url: ...: max retries achieved for http request"
```
**Impossibile aggiornare il gestore di pacchetti**
Il comando `nodeadm install` esegue `apt update`, `yum update` o `dnf update` prima dell’installazione delle dipendenze dei nodi ibridi. Se questo passaggio non ha esito positivo, potresti visualizzare errori simili ai seguenti. Per rimediare, puoi eseguire `apt update`, `yum update` o `dnf update` prima di eseguire `nodeadm install` oppure puoi provare a rieseguire `nodeadm install`.
```
failed to run update using package manager
```
**Scadenza di un timeout o di un contesto superata**
Durante l’esecuzione di `nodeadm install`, se riscontri problemi in varie fasi del processo di installazione con errori che indicano che è stata superata la scadenza di un timeout o di un contesto, è possibile che la connessione sia lenta e impedisca l’installazione delle dipendenze dei nodi ibridi prima del raggiungimento dei timeout. Per risolvere questi problemi, puoi provare a utilizzare il flag `--timeout` in `nodeadm` per estendere la durata dei timeout per il download delle dipendenze.
```
nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --timeout {{20m0s}}
```
## Risoluzione dei problemi di connessione dei nodi ibridi
Gli argomenti di risoluzione dei problemi in questa sezione riguardano il processo di connessione dei nodi ibridi ai cluster EKS con il comando `nodeadm init`.
**Errori operativi o schema non supportato**
Durante l’esecuzione di `nodeadm init`, se vedi errori relativi a `operation error` o`unsupported scheme`, controlla `nodeConfig.yaml` per assicurarti che sia formattato e passato correttamente a `nodeadm`. Per ulteriori informazioni sul formato e le opzioni per `nodeConfig.yaml`, consulta [Nodi ibridi di `riferimento nodeadm`](hybrid-nodes-nodeadm.md).
```
"msg":"Command failed","error":"operation error ec2imds: GetRegion, request canceled, context deadline exceeded"
```
**Al ruolo IAM dei nodi ibridi mancano le autorizzazioni per l’azione `eks:DescribeCluster`**
Durante l'esecuzione`nodeadm init`, `nodeadm` tenta di raccogliere informazioni sul cluster EKS richiamando l'azione EKS`DescribeCluster`. Se il ruolo IAM di Hybrid Nodes non dispone dell'autorizzazione per l'`eks:DescribeCluster`azione, devi passare l'endpoint dell'API Kubernetes, il bundle CA del cluster e il CIDR IPv4 del servizio nella configurazione del nodo a cui passi durante l'esecuzione. `nodeadm` `nodeadm init` Per ulteriori informazioni sulle autorizzazioni richieste per il ruolo IAM dei nodi ibridi, consulta [Preparazione delle credenziali per i nodi ibridi](hybrid-nodes-creds.md).
```
"msg":"Command failed","error":"operation error EKS: DescribeCluster, https response error StatusCode: 403 ... AccessDeniedException"
```
**Al ruolo IAM dei nodi ibridi mancano le autorizzazioni per l’azione `eks:ListAccessEntries`**
Durante l'esecuzione`nodeadm init`, `nodeadm` tenta di convalidare se il cluster EKS ha una voce di accesso di tipo `HYBRID_LINUX` associata al ruolo IAM di Hybrid Nodes chiamando l'azione EKS. `ListAccessEntries` Se il ruolo IAM di Hybrid Nodes non dispone dell'autorizzazione per l'`eks:ListAccessEntries`azione, è necessario passare il `--skip cluster-access-validation` flag quando si esegue il `nodeadm init` comando. Per ulteriori informazioni sulle autorizzazioni richieste per il ruolo IAM dei nodi ibridi, consulta [Preparazione delle credenziali per i nodi ibridi](hybrid-nodes-creds.md).
```
"msg":"Command failed","error":"operation error EKS: ListAccessEntries, https response error StatusCode: 403 ... AccessDeniedException"
```
**IP del nodo non presente nella rete di nodi remoti CIDR**
Durante l’esecuzione di `nodeadm init`, potresti riscontrare un errore se l’indirizzo IP del nodo non rientra nei CIDR della rete del nodo remoto specificati. L’aspetto dell’errore sarà simile all’esempio seguente:
```
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]
```
Questo esempio mostra un nodo con IP 10.18.0.1 che tenta di unirsi a un cluster con una rete remota CIDRS 10.0.0. 0/16 e 192.168.0. 0/16. L’errore si verifica perché 10.18.0.1 non rientra in nessuno degli intervalli.
Conferma di aver configurato correttamente i tuoi indirizzi IP `RemoteNodeNetworks` per includere tutti gli indirizzi IP del nodo. Per ulteriori informazioni sulla configurazione delle reti, consulta [Preparazione della rete per i nodi ibridi](hybrid-nodes-networking.md).
+ Esegui il comando seguente nella regione in cui si trova il cluster per verificare le configurazioni `RemoteNodeNetwork`. Verifica che i blocchi CIDR elencati nell’output includano l’intervallo IP del nodo e corrispondano ai blocchi CIDR elencati nel messaggio di errore. Se non corrispondono, conferma che il nome e la regione del cluster `nodeConfig.yaml` corrispondano al cluster desiderato.
```
aws eks describe-cluster --name {{CLUSTER_NAME}} --region REGION_NAME --query cluster.remoteNetworkConfig.remoteNodeNetworks
```
+ Verifica di lavorare con il nodo desiderato:
+ Conferma di essere sul nodo corretto controllando che il nome host e l’indirizzo IP corrispondano a quelli che intendi registrare nel cluster.
+ Verifica che questo nodo si trovi nella rete on-premises corretta (quella il cui intervallo CIDR è stato registrato come `RemoteNodeNetwork` durante la configurazione del cluster).
Se l’IP del nodo non è ancora quello previsto, controlla quanto segue:
+ Se utilizzi IAM Roles Anywhere, `kubelet` esegue una ricerca DNS su IAM Roles Anywhere `nodeName` e utilizza un IP associato al nome del nodo, se disponibile. Se gestisci gli ingressi DNS per i tuoi nodi, conferma che questi punti di ingresso agli IP all’interno dei CIDR della rete del nodo remoto.
+ Se il tuo nodo ha più interfacce di rete, `kubelet` potrebbe selezionare un’interfaccia con un indirizzo IP esterno ai CIDR della rete del nodo remoto come impostazione predefinita. Per utilizzare un’interfaccia diversa, specifica il relativo indirizzo IP utilizzando il flag `--node-ip` `kubelet` nel tuo `nodeConfig.yaml`. Per ulteriori informazioni, consulta [Nodi ibridi di `riferimento nodeadm`](hybrid-nodes-nodeadm.md). Puoi visualizzare le interfacce di rete del tuo nodo e i relativi indirizzi IP eseguendo il seguente comando sul tuo nodo:
```
ip addr show
```
**I nodi ibridi non vengono visualizzati nel cluster EKS**
Se l'hai eseguito `nodeadm init` ed è stato completato ma i nodi ibridi non sono visualizzati nel cluster, potrebbero esserci problemi con la connessione di rete tra i nodi ibridi e il piano di controllo EKS, potresti non avere le autorizzazioni richieste per il gruppo di sicurezza configurate o potresti non avere la mappatura richiesta del ruolo IAM di Hybrid Nodes su Kubernetes Role-Based Access Control (RBAC). Puoi avviare il processo di debug controllando lo stato di `kubelet` e i log `kubelet` con i seguenti comandi. Esegui i seguenti comandi dai nodi ibridi che non sono riusciti a entrare a far parte del cluster.
```
systemctl status kubelet
```
```
journalctl -u kubelet -f
```
**Impossibile comunicare con il cluster**
Se il nodo ibrido non è in grado di comunicare con il piano di controllo del cluster, potresti visualizzare log simili ai seguenti.
```
"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 visualizzi questi messaggi, controlla quanto segue per assicurarti che soddisfi i requisiti dei nodi ibridi descritti in [Preparazione della rete per i nodi ibridi](hybrid-nodes-networking.md).
+ Verifica che il VPC passato al cluster EKS disponga di percorsi verso il tuo Transit Gateway (TGW) o Gateway privato virtuale (VGW) per il nodo on-premises e, facoltativamente, i pod CIDR.
+ Conferma di disporre di un gruppo di sicurezza aggiuntivo per il cluster EKS che disponga di regole in entrata per i CIDR del nodo on-premises e, facoltativamente, per i CIDR del pod.
+ Verifica che il router on-premises sia configurato per consentire il traffico da e verso il piano di controllo EKS.
**Non autorizzato **
Se il nodo ibrido è in grado di comunicare con il piano di controllo EKS ma non è in grado di registrarsi, potresti visualizzare log simili ai seguenti. Nota che la differenza principale nei messaggi di log riportati di seguito è l’errore `Unauthorized`. Ciò indica che il nodo non è stato in grado di eseguire le proprie attività perché non dispone delle autorizzazioni richieste.
```
"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 visualizzi questi messaggi, controlla quanto segue per assicurarti che soddisfi i dettagli dei requisiti dei nodi in [Preparazione delle credenziali per i nodi ibridi](hybrid-nodes-creds.md) e [Preparazione dell’accesso al cluster per i nodi ibridi](hybrid-nodes-cluster-prep.md).
+ Verifica che l’identità dei nodi ibridi corrisponda al ruolo IAM dei nodi ibridi previsto. Questo può essere fatto eseguendo `sudo aws sts get-caller-identity` dai tuoi nodi ibridi.
+ Verifica che il ruolo IAM dei nodi ibridi disponga delle autorizzazioni richieste.
+ Conferma che nel tuo cluster hai una voce di accesso EKS per il tuo ruolo IAM di Hybrid Nodes o conferma di avere una voce per il tuo `aws-auth` ConfigMap ruolo IAM di Hybrid Nodes. Se utilizzi le voci di accesso EKS, conferma che la voce di accesso per il ruolo IAM dei nodi ibridi abbia il tipo di accesso `HYBRID_LINUX`. Se stai utilizzando il `aws-auth` ConfigMap, conferma che la tua voce per il ruolo IAM di Hybrid Nodes soddisfi i requisiti e la formattazione descritti in[Preparazione dell’accesso al cluster per i nodi ibridi](hybrid-nodes-cluster-prep.md).
### I nodi ibridi sono registrati nel cluster EKS ma mostrano lo stato `Non pronti`
Se i nodi ibridi sono registrati correttamente nel cluster EKS, ma mostrano lo stato `Not Ready`, la prima cosa da verificare è lo stato dell’interfaccia CNI (Container Networking Interface). Se non hai installato una CNI, si prevede che i nodi ibridi abbiano lo status `Not Ready`. Quando una CNI è installata e funziona correttamente, i nodi vengono aggiornati allo stato `Ready`. Se hai tentato di installare una CNI ma non funziona correttamente, consulta [Risoluzione dei problemi CNI dei nodi ibridi](#hybrid-nodes-troubleshooting-cni) su questa pagina.
**Le richieste di firma certificati (CSR) sono bloccate su In sospeso**
Dopo aver collegato i nodi ibridi al cluster EKS, se noti che ci sono CSR in sospeso per i nodi ibridi, significa che i nodi ibridi non soddisfano i requisiti per l’approvazione automatica. Le CSR per i nodi ibridi vengono approvate ed emesse automaticamente se le CSR per i nodi ibridi sono state create da un nodo con etichetta `eks.amazonaws.com/compute-type: hybrid` e la CSR ha i seguenti Nomi alternativi oggetto (SAN): almeno una SAN DNS è uguale al nome del nodo e le SAN IP appartengono ai CIDR della rete del nodo remoto.
**Il profilo ibrido esiste già**
Se hai modificato la configurazione `nodeadm` e tenti di registrare nuovamente il nodo con la nuova configurazione, potresti visualizzare un errore che indica che il profilo ibrido esiste già ma il suo contenuto è cambiato. Invece di eseguire l’operazione `nodeadm init` tra le modifiche alla configurazione, esegui `nodeadm uninstall` seguito da `nodeadm install` e `nodeadm init`. Ciò garantisce una corretta pulizia con le modifiche alla configurazione.
```
"msg":"Command failed","error":"hybrid profile already exists at /etc/aws/hybrid/config but its contents do not align with the expected configuration"
```
**Il nodo ibrido non è riuscito a risolvere l’API privata**
Dopo l’esecuzione di `nodeadm init`, se visualizzi un errore nei log `kubelet` che indica che non è stato possibile contattare il server dell’API EKS Kubernetes perché si è verificato `no such host`, potresti dover modificare la voce DNS per l’endpoint dell’API EKS Kubernetes nella rete on-premises o a livello di host. Vedi [ Inoltro di richieste DNS in entrata al tuo ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html) VPC nella documentazione di Route53. * AWS *
```
Failed to contact API server when waiting for CSINode publishing: Get ... no such host
```
**Impossibile visualizzare i nodi ibridi nella console EKS**
Se hai registrato i tuoi nodi ibridi ma non riesci a visualizzarli nella console EKS, controlla le autorizzazioni dell’IAM principale che stai utilizzando per visualizzare la console. L’IAM principale che stai utilizzando deve disporre di autorizzazioni IAM e Kubernetes minime specifiche per visualizzare le risorse nella console. Per ulteriori informazioni, consulta [Visualizza le risorse Kubernetes nel Console di gestione AWS](view-kubernetes-resources.md).
## Risoluzione dei problemi di esecuzione dei nodi ibridi
Se i nodi ibridi che sono stati registrati nel cluster EKS avevano lo stato `Ready` e poi sono passati allo stato `Not Ready`, esistono molti problemi che potrebbero aver contribuito a tale stato di non integrità, ad esempio la mancanza di risorse sufficienti per la CPU, la memoria o lo spazio su disco disponibile del nodo, oppure la disconnessione del nodo dal piano di controllo EKS. Puoi utilizzare i passaggi seguenti per risolvere i problemi dei tuoi nodi e, se non riesci a risolvere il problema, contatta l'assistenza. AWS
Esegui `nodeadm debug` dai nodi ibridi per verificare che i requisiti di rete e le credenziali siano soddisfatti. Per ulteriori informazioni sul comando `nodeadm debug`, consulta [Nodi ibridi di `riferimento nodeadm`](hybrid-nodes-nodeadm.md).
**Ottieni lo stato del nodo**
```
kubectl get nodes -o wide
```
**Controlla le condizioni e gli eventi del nodo**
```
kubectl describe node {{NODE_NAME}}
```
**Ottieni lo stato del pod**
```
kubectl get pods -A -o wide
```
**Controlla le condizioni e gli eventi del pod**
```
kubectl describe pod {{POD_NAME}}
```
**Controlla i log del pod**
```
kubectl logs {{POD_NAME}}
```
**Controlla i log di `kubelet`**
```
systemctl status kubelet
```
```
journalctl -u kubelet -f
```
**Probe liveness del pod non funziona o i webhook non funzionano**
Se le applicazioni, i componenti aggiuntivi o i webhook in esecuzione sui nodi ibridi non si avviano correttamente, potresti riscontrare problemi di rete che bloccano la comunicazione con i pod. Affinché il piano di controllo EKS contatti i webhook in esecuzione su nodi ibridi, è necessario configurare il cluster EKS con una rete pod remota e inserire i percorsi per il POD CIDR locale nella tabella di routing VPC con la destinazione come Transit Gateway (TGW), virtual private gateway (VGW) o altro gateway utilizzato per connettere il VPC alla rete locale. Per ulteriori informazioni sui requisiti di rete per i nodi ibridi, consulta [Preparazione della rete per i nodi ibridi](hybrid-nodes-networking.md). Devi inoltre consentire a questo traffico di entrare nel firewall on-premises e assicurarti che il router sia in grado di instradare correttamente i pod. Consulta [Configurazione di webhook per nodi ibridi](hybrid-nodes-webhooks.md) per ulteriori informazioni sui requisiti per l’esecuzione di webhook su nodi ibridi.
Di seguito è riportato un messaggio di log del pod comune per questo scenario, dove l’indirizzo IP è l’IP del cluster per il servizio Kubernetes.
```
dial tcp :443: connect: no route to host
```
**`kubectl logs`o comandi non funzionanti (comandi API) `kubectl exec` `kubelet` **
Se`kubectl attach`, `kubectl cp` `kubectl exec``kubectl logs`, e `kubectl port-forward` i comandi scadono mentre altri `kubectl` comandi hanno esito positivo, il problema è probabilmente correlato alla configurazione della rete remota. Questi comandi si connettono tramite il cluster all’endpoint `kubelet` sul nodo. Per ulteriori informazioni, consulta [Endpoint `kubelet`](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-kubelet-api).
Verifica che gli IP dei nodi e gli IP dei pod rientrino nei CIDR della rete del nodo remoto e della rete del pod remoto configurati per il cluster. Usa i comandi seguenti per esaminare le assegnazioni IP.
```
kubectl get nodes -o wide
```
```
kubectl get pods -A -o wide
```
Confronta questi IP con i CIDR di rete remota configurati per garantire un routing corretto. Per i requisiti relativi alla configurazione della rete, consulta [Preparazione della rete per i nodi ibridi](hybrid-nodes-networking.md).
## Risoluzione dei problemi CNI dei nodi ibridi
Se riscontri problemi con l’avvio iniziale di Cilium o Calico con nodi ibridi, il più delle volte ciò è dovuto a problemi di rete tra i nodi ibridi o i pod CNI in esecuzione sui nodi ibridi e il piano di controllo EKS. Assicurati che il tuo ambiente soddisfi i requisiti di Preparazione della rete per i nodi ibridi. È utile suddividere il problema in parti.
Configurazione del cluster EKS
Le RemotePodNetwork configurazioni RemoteNodeNetwork e sono corrette?
Configurazione VPC
Esistono percorsi per l' RemoteNodeNetwork e RemotePodNetwork nella tabella di routing del VPC con destinazione Transit Gateway o Virtual Private Gateway?
Configurazione del gruppo di sicurezza
Esistono regole in entrata e in uscita per la destinazione finale? RemoteNodeNetwork RemotePodNetwork
On-premises rete
Esistono percorsi e accessi da e verso il piano di controllo EKS e da e verso i nodi ibridi e i pod in esecuzione sui nodi ibridi?
Configurazione CNI
Se si utilizza una rete overlay, la configurazione del pool IP per il CNI corrisponde a quella RemotePodNetwork configurata per il cluster EKS se si utilizzano webhook?
**Il nodo ibrido ha lo stato `Ready` senza una CNI installata**
Se i nodi ibridi mostrano lo stato `Ready`, ma non è stata installata una CNI sul cluster, è possibile che sui nodi ibridi siano presenti vecchi artefatti CNI. Per impostazione predefinita, quando si disinstallano Cilium e Calico con strumenti come Helm, le risorse su disco non vengono rimosse dalle macchine fisiche o virtuali. Inoltre, le Definizioni delle risorse personalizzate (CRD) per questi CNI potrebbero essere ancora presenti nel cluster da una vecchia installazione. Per ulteriori informazioni, consulta le sezioni Eliminazione Cilium ed Eliminazione Calico di [Configurazione della CNI per nodi ibridi](hybrid-nodes-cni.md).
**Risoluzione dei problemi di Cilium**
Se riscontri problemi nell’esecuzione di Cilium su nodi ibridi, consulta i [passaggi per la risoluzione dei problemi](https://docs.cilium.io/en/stable/operations/troubleshooting/) nella documentazione di Cilium. Le sezioni seguenti trattano i problemi che potrebbero riguardare esclusivamente la distribuzione di Cilium sui nodi ibridi.
**Cilium non si avvia**
Se gli agenti Cilium eseguiti su ciascun nodo ibrido non si avviano, controlla se sono presenti errori nei log dei pod degli agenti Cilium. L’agente Cilium richiede la connettività all’endpoint dell’API EKS Kubernetes per iniziare. L’avvio dell’agente Cilium avrà esito negativo se questa connettività non è configurata correttamente. In questo caso, nei log del pod dell’agente Cilium verranno visualizzati messaggi di registro simili ai seguenti.
```
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"
```
L’agente Cilium viene eseguito sulla rete host. Il cluster EKS deve essere configurato con `RemoteNodeNetwork` per la connettività Cilium. Verifica di avere un gruppo di sicurezza aggiuntivo per il tuo cluster EKS con una regola in entrata per `RemoteNodeNetwork`, di disporre di percorsi nel VPC per `RemoteNodeNetwork` e che la tua rete on-premises sia configurata correttamente per consentire la connettività al piano di controllo EKS.
Se l’operatore Cilium è in esecuzione e alcuni, ma non tutti, dei tuoi agenti Cilium sono in esecuzione, conferma di avere IP pod disponibili da allocare per tutti i nodi del cluster. Configura la dimensione dei pod CIDR allocabili quando utilizzi il pool di cluster IPAM con `clusterPoolIPv4PodCIDRList` nella configurazione Cilium. La dimensione CIDR per nodo è configurata con l’impostazione `clusterPoolIPv4MaskSize` nella configurazione di Cilium. Per ulteriori informazioni, consulta [Expanding the cluster pool](https://docs.cilium.io/en/stable/network/concepts/ipam/cluster-pool/#expanding-the-cluster-pool) nella documentazione di Cilium.
**Cilium BGP non funziona**
Se utilizzi il piano di controllo di Cilium BGP per pubblicizzare i tuoi pod o gli indirizzi di servizio sulla tua rete on-premises, puoi utilizzare i seguenti comandi Cilium CLI per verificare se BGP sta pubblicizzando i percorsi verso le tue risorse. Per i passaggi per installare la CLI di Cilium, consulta [Install the Cilium CLI](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#install-the-cilium-cli) nella documentazione di Cilium.
Se BGP funziona correttamente, dovresti vedere i tuoi nodi ibridi con Session State nell'output. `established` Potresti dover collaborare con il team di rete per identificare i valori corretti per Local AS, Peer AS e Peer Address del proprio ambiente.
```
cilium bgp peers
```
```
cilium bgp routes
```
Se utilizzi Cilium BGP per pubblicizzare gli IP dei Servizi di tipo `LoadBalancer`, devi avere la stessa etichetta sia su `CiliumLoadBalancerIPPool` che su Servizio, che deve essere utilizzata nel selettore di `CiliumBGPAdvertisement`. Di seguito è riportato un esempio. Nota, se utilizzi Cilium BGP per pubblicizzare gli IP dei Services in base al tipo LoadBalancer, le route BGP potrebbero essere interrotte durante il riavvio dell'agente Cilium. Per ulteriori informazioni, consulta [Failure Scenarios](https://docs.cilium.io/en/latest/network/bgp-control-plane/bgp-control-plane-operation/#failure-scenarios) nella documentazione di Cilium.
**Servizio**
```
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 ] }
```
**Risoluzione dei problemi di Calico**
Se riscontri problemi nell’esecuzione di Calico su nodi ibridi, consulta [troubleshooting steps](https://docs.tigera.io/calico/latest/operations/troubleshoot/) nella documentazione di Calico. Le sezioni seguenti trattano i problemi che potrebbero riguardare esclusivamente la distribuzione di Calico sui nodi ibridi.
La tabella seguente riassume i componenti di Calico e se funzionano di default sul nodo o sulla rete di pod. Se hai configurato Calico per utilizzare NAT per il traffico dei pod in uscita, la rete on-premises deve essere configurata per indirizzare il traffico verso il nodo on-premises CIDR e le tabelle di routing VPC devono essere configurate con una route per il nodo on-premises CIDR con il gateway di transito (TGW) o il gateway privato virtuale (VGW) come destinazione. Se non hai configurato Calico per utilizzare il NAT per il traffico dei pod in uscita, la rete on-premises deve essere configurata per indirizzare il traffico verso il pod on-premises CIDR e le tabelle di routing VPC devono essere configurate con una route per il pod on-premises CIDR con il gateway di transito (TGW) o il gateway privato virtuale (VGW) come destinazione.
| Componente | Rete |
| --- | --- |
| Server API Calico | Nodo |
| Controller per Kubernetes di Calico | Pod |
| Agente del nodo di Calico | Nodo |
| Calico `typha` | Nodo |
| Driver del nodo CSI di Calico | Pod |
| Operatore Calico | Nodo |
**Le risorse di Calico sono pianificate o in esecuzione su nodi isolati**
Le risorse Calico che non vengono eseguite come a DaemonSet hanno tolleranze flessibili per impostazione predefinita che consentono di pianificarle su nodi isolati che non sono pronti per la pianificazione o l'esecuzione dei pod. È possibile inasprire le tolleranze per le risorse diverse da DaemonSet Calico modificando l'installazione dell'operatore per includere quanto segue.
```
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
```
## Risoluzione dei problemi relativi alle credenziali
Sia per le attivazioni ibride AWS SSM che per AWS IAM Roles Anywhere, puoi convalidare che le credenziali per il ruolo IAM di Hybrid Nodes siano configurate correttamente sui tuoi nodi ibridi eseguendo il seguente comando dai tuoi nodi ibridi. Conferma che il nome del nodo e il nome del ruolo IAM dei nodi ibridi sono quelli che ti aspetti.
```
sudo aws sts get-caller-identity
```
```
{
"UserId": "ABCDEFGHIJKLM12345678910:",
"Account": "",
"Arn": "arn:aws: sts:::assumed-role/"
}
```
**Risoluzione dei problemi di AWS Systems Manager (SSM)**
Se utilizzi attivazioni ibride AWS SSM per le credenziali dei tuoi nodi ibridi, tieni presente le seguenti directory e artefatti SSM che vengono installati sui tuoi nodi ibridi da. `nodeadm` Per ulteriori informazioni sull'agente SSM, vedere [ Lavorare con l'agente SSM nella Guida per l'utente di Systems Manager. ](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) * AWS *
| Description | Location (Ubicazione) |
| --- | --- |
| Agente SSM | Ubuntu - `/snap/amazon-ssm-agent/current/amazon-ssm-agent` RHEL & AL2023 - `/usr/bin/amazon-ssm-agent` |
| Log di SSM Agent | `/var/log/amazon/ssm` |
| AWS credenziali | `/root/.aws/credentials` |
| CLI di configurazione SSM | `/opt/ssm/ssm-setup-cli` |
**Riavvio dell’agente SSM**
Alcuni problemi possono essere risolti riavviando l’agente SSM. Puoi utilizzare i comandi seguenti per riavviarlo.
**AL2023 e altri sistemi operativi**
```
systemctl restart amazon-ssm-agent
```
**Ubuntu**
```
systemctl restart snap.amazon-ssm-agent.amazon-ssm-agent
```
**Verifica la connettività agli endpoint SSM**
Conferma di poter effettuare la connessione agli endpoint SSM dai nodi ibridi. Per un elenco degli endpoint SSM, consulta [AWS Systems Manager endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/ssm.html). Sostituisci `us-west-2` nel comando seguente la AWS regione per l'attivazione ibrida AWS SSM.
```
ping ssm.us-west-2.amazonaws.com
```
**Visualizza lo stato della connessione delle istanze SSM registrate**
Puoi controllare lo stato della connessione delle istanze registrate con le attivazioni ibride SSM con il seguente comando CLI. AWS Sostituisci l’ID della macchina con quello della macchina dell’istanza.
```
aws ssm get-connection-status --target {{mi-012345678abcdefgh}}
```
**Mancata corrispondenza del checksum CLI di installazione SSM**
Durante l’esecuzione di `nodeadm install`, se riscontri un problema relativo alla mancata corrispondenza del checksum `ssm-setup-cli`, dovresti confermare che non ci siano installazioni SSM precedenti esistenti sul tuo host. Se sul tuo host sono presenti installazioni SSM precedenti, rimuovile ed esegui di nuovo `nodeadm install` per risolvere il problema.
```
Failed to perform agent-installation/on-prem registration: error while verifying installed ssm-setup-cli checksum: checksum mismatch with latest ssm-setup-cli.
```
**`InvalidActivation` SSM**
Se riscontri un errore durante la registrazione della tua istanza con AWS SSM, conferma che i campi e e sono `region` corretti`activationCode`. `activationId` `nodeConfig.yaml` La AWS regione del cluster EKS deve corrispondere alla regione dell'attivazione ibrida SSM. Se questi valori non sono configurati correttamente, potresti visualizzare un errore simile al seguente.
```
ERROR Registration failed due to error registering the instance with AWS SSM. InvalidActivation
```
**`ExpiredTokenException` SSM: Il token di sicurezza incluso nella richiesta è scaduto**
Se l’agente SSM non è in grado di aggiornare le credenziali, potresti visualizzare un `ExpiredTokenException`. In questo scenario, se riesci a connetterti agli endpoint SSM dai tuoi nodi ibridi, potresti dover riavviare l’agente SSM per forzare l’aggiornamento delle credenziali.
```
"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"
```
**Errore SSM nell’esecuzione del comando registra computer**
Se vedi un errore durante la registrazione del computer con SSM, potresti dover eseguire di nuovo `nodeadm install` per assicurarti che tutte le dipendenze SSM siano installate correttamente.
```
"error":"running register machine command: , error: fork/exec /opt/aws/ssm-setup-cli: no such file or directory"
```
**`ActivationExpired` SSM**
Durante l’esecuzione di `nodeadm init`, se vedi un errore durante la registrazione dell’istanza con SSM a causa di un’attivazione scaduta, devi creare una nuova attivazione ibrida SSM, aggiornare `nodeConfig.yaml` con `activationCode` e `activationId` della nuova attivazione ibrida SSM ed eseguire di nuovo `nodeadm init`.
```
"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
```
**SSM non è riuscito ad aggiornare le credenziali memorizzate nella cache**
Se riscontri un errore nell’aggiornamento delle credenziali memorizzate nella cache, il file `/root/.aws/credentials` potrebbe essere stato eliminato sul tuo host. Controlla innanzitutto l’attivazione ibrida SSM e assicurati che sia attiva e che i nodi ibridi siano configurati correttamente per utilizzare l’attivazione. Controlla l’accesso dell’agente SSM a `/var/log/amazon/ssm` ed esegui di nuovo il comando `nodeadm init` una volta risolto il problema sul lato SSM.
```
"Command failed","error":"operation error SSM: DescribeInstanceInformation, get identity: get credentials: failed to refresh cached credentials"
```
**Pulisci la SSM**
Per rimuovere l’agente SSM dal tuo host, puoi eseguire i seguenti comandi.
```
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
```
**Risoluzione problemi AWS IAM Roles Anywhere**
Se utilizzi AWS IAM Roles Anywhere per le credenziali dei tuoi nodi ibridi, tieni presente le seguenti directory e artefatti che vengono installati sui tuoi nodi ibridi da. `nodeadm` Per ulteriori informazioni sulla risoluzione dei problemi di IAM Roles Anywhere, consulta [ Troubleshooting IAM Roles Anywhere identity and access ](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/security_iam_troubleshoot.html) nella AWS IAM Roles Anywhere User Guide * AWS . *
| Description | Location (Ubicazione) |
| --- | --- |
| CLI IAM Roles Anywhere | `/usr/local/bin/aws_signing_helper` |
| Ubicazione e nome predefiniti del certificato | `/etc/iam/pki/server.pem` |
| Posizione e nome predefiniti della chiave | `/etc/iam/pki/server.key` |
**IAM Roles Anywhere non è riuscito ad aggiornare le credenziali memorizzate nella cache**
Se riscontri un errore nell’aggiornamento delle credenziali memorizzate nella cache, esamina il contenuto di `/etc/aws/hybrid/config` e conferma che IAM Roles Anywhere sia stato configurato correttamente nella tua configurazione `nodeadm`. Confermare l’esistenza di `/etc/iam/pki`. Ogni nodo deve avere un certificato e una chiave univoci. Per impostazione predefinita, quando si utilizza IAM Roles Anywhere come fornitore di credenziali, `nodeadm` utilizza `/etc/iam/pki/server.pem` per la posizione e il nome del certificato e `/etc/iam/pki/server.key` per la chiave privata. Potresti dover creare le directory prima di inserire i certificati e le chiavi nelle directory con `sudo mkdir -p /etc/iam/pki`. Puoi verificare il contenuto del certificato con il comando seguente.
```
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 non è autorizzato a eseguire `sts:AssumeRole`**
Nei log `kubelet`, se riscontri un problema di accesso negato all’operazione `sts:AssumeRole` quando utilizzi IAM Roles Anywhere, controlla la policy di fiducia del tuo ruolo IAM dei nodi ibridi per confermare che il principale del servizio IAM Roles Anywhere sia autorizzato ad assumere il ruolo IAM dei nodi ibridi. Verifica inoltre che l’ancora di fiducia ARN sia configurato correttamente nella policy di fiducia del ruolo IAM dei nodi ibridi e che il ruolo IAM dei nodi ibridi sia aggiunto al tuo profilo IAM Roles Anywhere.
```
could not get token: AccessDenied: User: ... is not authorized to perform: sts:AssumeRole on resource: ...
```
**IAM Roles Anywhere non è autorizzato a impostare `roleSessionName` **
Nei log `kubelet`, se riscontri un problema di accesso negato durante l’impostazione di `roleSessionName`, conferma che l’impostazione `acceptRoleSessionName` sia su true per il tuo profilo IAM Roles Anywhere.
```
AccessDeniedException: Not authorized to set roleSessionName
```
## Risoluzione dei problemi del sistema operativo
### RHEL
**Errori di registrazione del gestore dei diritti o degli entitlement**
Se `nodeadm install` è in esecuzione e non è possibile installare le dipendenze dei nodi ibridi a causa di problemi di registrazione degli entitlement, assicurati di aver impostato correttamente il nome utente e la password di Red Hat sull’host.
```
This system is not registered with an entitlement server
```
### Ubuntu
**GLIBC non trovato**
Se utilizzi Ubuntu per il sistema operativo e IAM Roles Anywhere per il provider di credenziali con nodi ibridi e riscontri un problema relativo a GLIBC non trovato, puoi installare la dipendenza manualmente per risolverlo.
```
GLIBC_2.32 not found (required by /usr/local/bin/aws_signing_helper)
```
Esegui i comandi riportati qui di seguito per installare la dipendenza:
```
ldd --version
sudo apt update && apt install libc6
sudo apt install glibc-source
```
### Bottlerocket
Se hai abilitato il container di amministrazione Bottlerocket, puoi accedervi con SSH per il debug avanzato e la risoluzione dei problemi con privilegi elevati. Le seguenti sezioni contengono comandi che devono essere eseguiti nel contesto dell’host Bottlerocket. Una volta che sei nel container di amministrazione, puoi eseguire `sheltie` per ottenere una shell root completa nell’host Bottlerocket.
```
sheltie
```
Puoi anche eseguire i comandi nelle seguenti sezioni dalla shell del container di amministrazione anteponendo a ogni comando il prefisso `sudo chroot /.bottlerocket/rootfs`.
```
sudo chroot /.bottlerocket/rootfs
```
**Utilizzo di logdog per la raccolta dei log**
Bottlerocket fornisce l’utilità `logdog` per raccogliere in modo efficiente log e informazioni di sistema per la risoluzione dei problemi.
```
logdog
```
L’utilità `logdog` raccoglie i log da varie posizioni su un host Bottlerocket e li combina in un tarball. Per impostazione predefinita, il tarball viene creato in `/var/log/support/bottlerocket-logs.tar.gz` ed è accessibile dai contenitori host in `/.bottlerocket/support/bottlerocket-logs.tar.gz`.
**Accesso ai log di sistema con journalctl**
Puoi controllare lo stato dei vari servizi di sistema come `kubelet`, `containerd`, ecc. e visualizzarne i registri con i seguenti comandi. Il flag `-f` seguirà i log in tempo reale.
Per controllare lo stato del servizio `kubelet` e recuperare i log `kubelet`, puoi eseguire:
```
systemctl status kubelet
journalctl -u kubelet -f
```
Per controllare lo stato del servizio `containerd` e recuperare i log per l’istanza orchestrata `containerd`, puoi eseguire:
```
systemctl status containerd
journalctl -u containerd -f
```
Per controllare lo stato del servizio `host-containerd` e recuperare i log per l’istanza host `containerd`, puoi eseguire:
```
systemctl status host-containerd
journalctl -u host-containerd -f
```
Per recuperare i log per i container bootstrap e i container host, puoi eseguire:
```
journalctl _COMM=host-ctr -f
```