Contribuisci a migliorare questa pagina

Per contribuire a questa guida per l’utente, seleziona il link Edit this page on GitHub che si trova nel riquadro destro di ogni pagina.

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 e il Contenuto del centro conoscenze contrassegnato con Servizio Amazon Elastic Kubernetes su AWS re:Post. Se non riesci a risolvere il problema, contatta il Supporto AWS.

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.

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 dagli SDK AWS. 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.

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 SSM AWS o IAM Roles Anywhere AWS. 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. 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 ounsupported 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.

"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 di nodeadm init, nodeadm tenta di raccogliere informazioni sul cluster EKS chiamando Descrivi cluster. Se il ruolo IAM dei nodi ibridi non dispone dell’autorizzazione per l’azione eks:DescribeCluster. Per ulteriori informazioni sulle autorizzazioni richieste per il ruolo IAM dei nodi ibridi, consulta Preparazione delle credenziali per i nodi ibridi.

"msg":"Command failed","error":"operation error EKS: DescribeCluster, 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 i CIDR di rete remoti 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.

aws eks describe-cluster --name CLUSTER_NAME --region REGION_NAME --query cluster.remoteNetworkConfig.remoteNodeNetworks

Se l’IP del nodo non è ancora quello previsto, controlla quanto segue:

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 <ip address>: 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.

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 e Preparazione dell’accesso al cluster per i nodi ibridi.

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 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. Consulta Forwarding inbound DNS queries to your VPC nella documentazione di AWS Route53.

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 Visualizzazione delle risorse Kubernetes in Console di gestione AWS.

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

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. 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 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 <ip-address>:443: connect: no route to host

I comandi kubectl logs o kubectl exec non funzionano

Se i comandi kubectl logs o kubectl exec scadono mentre gli altri comandi kubectl hanno esito positivo, è probabile che il problema sia correlato alla configurazione della rete remota. Questi comandi si connettono tramite il cluster all’endpoint kubelet sul nodo. Per ulteriori informazioni, consulta Endpoint kubelet.

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.

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.

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.

Risoluzione dei problemi di Cilium

Se riscontri problemi nell’esecuzione di Cilium su nodi ibridi, consulta i passaggi per la risoluzione dei problemi 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://<k8s-cluster-ip>:443/api/v1/namespaces/kube-system\": dial tcp <k8s-cluster-ip>: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 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 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 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 Servizi di tipo LoadBalancer, i percorsi BGP potrebbero essere interrotti durante il riavvio dell’agente Cilium. Per ulteriori informazioni, consulta 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: <CIDR to advertise>
  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 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.

Le risorse di Calico sono pianificate o in esecuzione su nodi isolati

Le risorse di Calico che non funzionano come DaemonSet hanno, per impostazione predefinita, tolleranze flessibili che ne consentono la pianificazione su nodi isolati che non sono pronti per la pianificazione o l’esecuzione dei pod. Puoi rafforzare le tolleranze per le risorse Calico non DaemonSet 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 dei nodi ibridi siano configurate correttamente sui nodi ibridi eseguendo il seguente comando dagli stessi. 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:<node-name>",
    "Account": "<aws-account-id>",
    "Arn": "arn:aws:sts::<aws-account-id>:assumed-role/<hybrid-nodes-iam-role/<node-name>"
}

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, consulta Working with the SSM agent nella Guida per l’utente di AWS Systems Manager.

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. Sostituisci us-west-2 nel comando seguente con la Regione AWS 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 vedi un errore durante la registrazione dell’istanza con AWS SSM, conferma che region, activationCode e activationId in nodeConfig.yaml siano corretti. La Regione AWS 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 directory e gli artefatti seguenti 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 Troubleshooting AWS IAM Roles Anywhere identity and access nella Guida per l’utente di AWS IAM Roles Anywhere.

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

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