**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** 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' AWS assistenza.
**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 [Riferimento `nodeadm` dei nodi ibridi](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. È possibile visualizzare i risultati di tutti i controlli approfonditi da Console di gestione AWS, AWS CLI e. AWS SDKs 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 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 [Riferimento `nodeadm` dei nodi ibridi](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 servizio IPv4 CIDR 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 verificare se il cluster EKS dispone di una voce di accesso di tipo `HYBRID_LINUX` associata al ruolo IAM di Hybrid Nodes richiamando 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`nodeadm init`, potresti riscontrare un errore se l'indirizzo IP del nodo non si trova all'interno della rete di nodi remoti specificata CIDRs. 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 la 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 conservi le voci DNS per i tuoi nodi, verifica che queste voci puntino all'interno della tua rete di nodi remoti. IPs CIDRs
+ Se il tuo nodo ha più interfacce di rete, `kubelet` potresti selezionare un'interfaccia con un indirizzo IP esterno alla rete del nodo remoto CIDRs 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 [Riferimento `nodeadm` dei nodi ibridi](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 hai eseguito `nodeadm init` ed è stato completato ma i nodi ibridi non compaiono nel cluster, potrebbero esserci problemi con la connessione di rete tra i nodi ibridi e il piano di controllo EKS, potresti non avere configurato le autorizzazioni richieste per i gruppi di sicurezza o potresti non avere la mappatura richiesta del ruolo IAM di dei nodi ibridi sul controllo degli accessi basato su ruoli (RBAC) di Kubernetes. 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 abbia percorsi verso il tuo Transit Gateway (TGW) o Virtual Private Gateway (VGW) per il nodo locale e, facoltativamente, il pod. CIDRs
+ Conferma di disporre di un gruppo di sicurezza aggiuntivo per il cluster EKS che disponga di regole in entrata per il nodo locale e, facoltativamente, per il pod. CIDRs CIDRs
+ 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.
+ Verifica che nel tuo cluster sia presente una voce di accesso EKS per il tuo ruolo IAM Hybrid Nodes o conferma di avere una voce per il `aws-auth` ConfigMap tuo ruolo IAM 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 utilizzi il `aws-auth` ConfigMap, conferma che la voce immessa per il ruolo IAM Hybrid Nodes soddisfa 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 `Not Ready`
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 dei certificati (CSRs) sono bloccate In sospeso**
Dopo aver collegato i nodi ibridi al cluster EKS, se noti che ci sono nodi ibridi in sospeso CSRs , significa che i nodi ibridi non soddisfano i requisiti per l'approvazione automatica. CSRs per i nodi ibridi vengono approvati ed emessi automaticamente se i nodi CSRs per i nodi ibridi sono stati creati da un nodo con `eks.amazonaws.com/compute-type: hybrid` etichetta e il CSR ha i seguenti nomi alternativi del soggetto (SANs): almeno una SAN DNS uguale al nome del nodo e l'IP SANs appartengono alla rete del nodo remoto. CIDRs
**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 delle query DNS in entrata al tuo VPC nella documentazione di](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html) 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 nodi e, se non riesci a risolvere il problema, contatta il supporto 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 [Riferimento `nodeadm` dei nodi ibridi](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 `kubectl`**
```
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 possa contattare i webhook in esecuzione su nodi ibridi, devi configurare il cluster EKS con una rete di pod remota e disporre di percorsi per il pod CIDR on-premises nella tabella di routing VPC con l’obiettivo come Transit Gateway (TGW), gateway privato virtuale (VPW) o altro gateway che si utilizza per connettere il VPC alla rete on-premises. 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 `kubectl exec` comandi non funzionanti (comandi `kubelet` API)**
Se`kubectl attach`,, `kubectl cp` `kubectl exec``kubectl logs`, e `kubectl port-forward` i comandi scadono mentre gli 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 il nodo IPs e il pod IPs rientrino nella rete di nodi remoti e nella rete di pod remoti CIDRs configurati per il cluster. Usa i comandi seguenti per esaminare le assegnazioni IP.
```
kubectl get nodes -o wide
```
```
kubectl get pods -A -o wide
```
Confrontali IPs con la rete remota configurata CIDRs 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 configurazioni RemoteNodeNetwork e le RemotePodNetwork configurazioni sono corrette?
Configurazione VPC
Esistono percorsi per RemoteNodeNetwork e RemotePodNetwork nella tabella di routing VPC con la destinazione del Transit Gateway o del Virtual Private Gateway?
Configurazione del gruppo di sicurezza
Esistono regole in entrata e in uscita per il e? RemoteNodeNetwork RemotePodNetwork
Rete locale
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 i 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 relative definizioni di risorse personalizzate (CRDs) CNIs potrebbero essere ancora presenti nel cluster a partire 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 dei vostri agenti Cilium sono in esecuzione ma non tutti, confermate di avere un pod disponibile IPs da allocare per tutti i nodi del cluster. Configurate la dimensione del vostro Pod allocabile CIDRs quando utilizzate il cluster pool IPAM nella configurazione di Cilium. `clusterPoolIPv4PodCIDRList` 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 avere dei nodi ibridi con `established` come stato della sessione nell’output. 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 utilizzate Cilium BGP per pubblicizzare i Servizi con tipo`LoadBalancer`, dovete avere la IPs stessa etichetta sia su voi che su Service, che deve essere utilizzata nel selettore del vostro`CiliumLoadBalancerIPPool`. `CiliumBGPAdvertisement` Di seguito è riportato un esempio. Nota, se utilizzi Cilium BGP per pubblicizzare i Servizi con tipo, i percorsi BGP potrebbero essere interrotti durante il riavvio IPs dell' LoadBalanceragente 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**
Per impostazione predefinita, le risorse Calico che non funzionano come unità DaemonSet hanno tolleranze flessibili che ne consentono la pianificazione 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 in modo da 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 verificare 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 [Working with the SSM agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) nella * AWS Systems Manager User* Guide.
| Description | Location (Ubicazione) |
| --- | --- |
| Agente SSM | Ubuntu - `/snap/amazon-ssm-agent/current/amazon-ssm-agent` RHEL e 023 - AL2 `/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 con 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 AWS CLI. 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 vedi un errore durante la registrazione dell'istanza con AWS SSM, conferma che, e i tuoi dati 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 identità e accesso a IAM Roles Anywhere, consulta [Risoluzione dei problemi di identità e accesso a AWS IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/security_iam_troubleshoot.html) nella Guida per l'utente di * AWS IAM Roles* Anywhere.
| 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
```