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 della modalità automatica di EKS

Con EKS Auto Mode, AWS ti assumi maggiori responsabilità per le istanze EC2 presenti nel tuo account. AWS EKS si assume la responsabilità del runtime dei container sui nodi, del sistema operativo sui nodi e di determinati controller. Ciò include un controller per l’archiviazione a blocchi, uno per il bilanciamento del carico e uno di elaborazione.

È necessario utilizzare le API AWS Kubernetes per risolvere i problemi dei nodi. Puoi:

Potresti riscontrare i seguenti problemi che hanno soluzioni specifiche per i componenti della modalità automatica di EKS:

Puoi utilizzare i seguenti metodi per risolvere i problemi relativi ai componenti della modalità automatica di EKS:

Agente di monitoraggio del nodo

modalità automatica di EKS include l’agente di monitoraggio dei nodi di Amazon EKS. Puoi utilizzare questo agente per visualizzare le informazioni di risoluzione dei problemi e di debug relative ai nodi. L’agente di monitoraggio dei nodi pubblica gli events di Kubernetes e le conditions del nodo. Per ulteriori informazioni, consulta Rileva i problemi di integrità dei nodi e abilita la riparazione automatica dei nodi.

Ottieni l'output della console da un'istanza gestita da EC2 utilizzando AWS CLI EC2

Questa procedura aiuta a risolvere problemi in fase di avvio o a livello di kernel.

Innanzitutto, devi determinare l’ID dell’istanza EC2 dell’istanza associata al carico di lavoro. In secondo luogo, utilizzate la AWS CLI per recuperare l'output della console.

Ottieni i log dei nodi utilizzando contenitori di debug e la CLI kubectl

Il modo consigliato per recuperare i log da un nodo EKS Auto Mode consiste nell'utilizzare una risorsa. NodeDiagnostic Per la procedura, consulta Recuperare i log dei nodi per un nodo gestito usando kubectl e S3.

Tuttavia, puoi eseguire lo streaming dei log in tempo reale da un’istanza utilizzando il comando kubectl debug node. Questo comando avvia un nuovo Pod sul nodo di cui desideri eseguire il debug, che puoi quindi utilizzare in modo interattivo.

Per motivi di sicurezza, l’immagine del container di Amazon Linux non installa molti file binari per impostazione predefinita. Puoi utilizzare il comando yum whatprovides per identificare il pacchetto da installare al fine di fornire un determinato file binario.

yum whatprovides ps

Last metadata expiration check: 0:03:36 ago on Thu Jan 16 14:49:17 2025.
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo        : @System
Matched from:
Filename    : /usr/bin/ps
Provide    : /bin/ps

procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo        : amazonlinux
Matched from:
Filename    : /usr/bin/ps
Provide    : /bin/ps

Visualizza le risorse associate a EKS Auto Mode in AWS Console

È possibile utilizzare la AWS console per visualizzare lo stato delle risorse associate al cluster EKS Auto Mode.

Visualizza gli errori IAM nel tuo AWS account

Cerca gli errori relativi al cluster EKS. Utilizza i messaggi di errore per aggiornare le voci di accesso EKS, il ruolo IAM del cluster o il ruolo IAM del nodo. Potresti dover allegare una nuova policy a questi ruoli con autorizzazioni per la modalità automatica di EKS.

Risolvere i problemi relativi alla mancata pianificazione dei Pod sul nodo Auto Mode

Se i pod rimangono nello Pending stato e non vengono programmati su un nodo in modalità auto, verifica se il tuo pod o il manifesto di distribuzione dispone di unnodeSelector. Se è presente un nodeSelector, assicurati che utilizzi eks.amazonaws.com/compute-type: auto per essere pianificato sui nodi creati dalla modalità automatica di EKS. Per ulteriori informazioni sulle etichette dei nodi utilizzate dalla modalità automatica di EKS, consulta Controllare se un carico di lavoro viene implementato sui nodi di EKS Auto Mode.

Risolvere i problemi del nodo che non si unisce al cluster

La modalità automatica di EKS configura automaticamente le nuove istanze EC2 con le informazioni corrette per unirsi al cluster, inclusi l’endpoint del cluster e l’autorità di certificazione (CA) del cluster. Tuttavia, queste istanze possono ancora non riuscire a unirsi al cluster EKS sotto forma di nodo. Esegui i seguenti comandi per identificare le istanze che non si sono unite al cluster:

Messaggi di errore comuni:

Rileva i problemi di connettività dei nodi con VPC Reachability Analyzer

Un motivo per cui un’istanza non si è unita al cluster è un problema di connettività di rete che impedisce di raggiungere il server API. Per diagnosticare questo problema, puoi utilizzare VPC Reachability Analyzer per eseguire un’analisi della connettività tra un nodo che non riesce a unirsi al cluster e al server API. Avrai bisogno di due informazioni:

Per ottenere l’ID dell’istanza, dovrai creare un carico di lavoro sul cluster per far sì che modalità automatica di EKS avvii un’istanza EC2. Questo crea anche un oggetto NodeClaim nel cluster che avrà l’ID dell’istanza. Esegui kubectl get nodeclaim -o yaml per stampare tutte le NodeClaims del cluster. Ciascuna NodeClaim contiene l’ID dell’istanza come campo e di nuovo nel providerID:

kubectl get nodeclaim -o yaml

Di seguito viene riportato un output di esempio.

    nodeName: i-01234567890123456
    providerID: aws:///us-west-2a/i-01234567890123456

Puoi determinare l’endpoint del server dell’API Kubernetes eseguendo kubectl get endpoint kubernetes -o yaml. Gli indirizzi si trovano nel campo degli indirizzi:

kubectl get endpoints kubernetes -o yaml

Di seguito viene riportato un output di esempio.

apiVersion: v1
kind: Endpoints
metadata:
  name: kubernetes
  namespace: default
subsets:
- addresses:
  - ip: 10.0.143.233
  - ip: 10.0.152.17
  ports:
  - name: https
    port: 443
    protocol: TCP

Con queste due informazioni, è possibile eseguire l'analisi. Per prima cosa, accedi a VPC Reachability Analyzer in Console di gestione AWS.

Condivisione di volumi tra pod

I nodi della modalità automatica di EKS sono configurati con SELinux in modalità di applicazione che fornisce un maggiore isolamento tra i Pod in esecuzione sullo stesso nodo. Quando SELinux è abilitato, alla maggior parte dei pod senza privilegi verrà applicata automaticamente la propria etichetta di sicurezza multicategoria (MCS). Questa etichetta MCS è unica per ogni Pod ed è progettata per garantire che un processo in un Pod non possa manipolare uno in un altro Pod o sull’host. Anche se un Pod etichettato viene eseguito come root e ha accesso al filesystem host, non sarà in grado di manipolare i file, effettuare chiamate di sistema sensibili sull’host, accedere al runtime del container oppure ottenere il materiale delle chiavi segrete di kubelet.

Per questo motivo, potresti riscontrare problemi durante il tentativo di condividere dati tra Pod. Ad esempio, una PersistentVolumeClaim con una modalità di accesso di ReadWriteOnce non consentirà comunque a più Pod di accedere contemporaneamente al volume.

Per abilitare questa condivisione tra i Pod, puoi usare i Pod seLinuxOptions per configurare la stessa etichetta MCS su quei Pod. In questo esempio, assegniamo le tre categorie c123,c456,c789 al Pod. Ciò non entrerà in conflitto con le categorie assegnate automaticamente ai Pod sul nodo, poiché a esse verranno assegnate solo due categorie.

securityContext:
  seLinuxOptions:
    level: "s0:c123,c456,c789"

Visualizzare gli eventi di Karpenter nei log del piano di controllo

Per i cluster EKS con i log del piano di controllo abilitati, puoi ottenere informazioni sulle azioni e sul processo decisionale di Karpenter interrogando i log. Ciò può essere particolarmente utile per risolvere i problemi della modalità automatica di EKS relativi al provisioning, al dimensionamento e alla terminazione dei nodi. Per visualizzare Karpenter-related gli eventi, utilizza la seguente query CloudWatch Logs Insights:

fields @timestamp, @message
| filter @logStream like /kube-apiserver-audit/
| filter @message like 'DisruptionBlocked'
or @message like 'DisruptionLaunching'
or @message like 'DisruptionTerminating'
or @message like 'DisruptionWaitingReadiness'
or @message like 'Unconsolidatable'
or @message like 'FailedScheduling'
or @message like 'NoCompatibleInstanceTypes'
or @message like 'NodeRepairBlocked'
or @message like 'Disrupted'
or @message like 'Evicted'
or @message like 'FailedDraining'
or @message like 'TerminationGracePeriodExpiring'
or @message like 'TerminationFailed'
or @message like 'FailedConsistencyCheck'
or @message like 'InsufficientCapacityError'
or @message like 'UnregisteredTaintMissing'
or @message like 'NodeClassNotReady'
| sort @timestamp desc

Questa query filtra gli Karpenter-related eventi specifici nei log di controllo di kube-apiserver. Gli eventi includono vari stati di interruzione, errori di pianificazione, problemi di capacità e problemi relativi ai nodi. Analizzando questi log, puoi comprendere meglio:

Per utilizzare questa query:

I risultati ti mostreranno una cronologia degli Karpenter-related eventi, ti aiuteranno a risolvere i problemi e a comprendere il comportamento di EKS Auto Mode nel tuo cluster. Per esaminare le azioni di Karpenter su un nodo specifico, puoi aggiungere il seguente filtro di riga che specifica l’ID dell’istanza alla suddetta query:

|filter @message like /[.replaceable]`i-12345678910123456`/

Risolvere i problemi relativi ai controller inclusi in Auto Mode

Se hai un problema con un controller, dovresti cercare:

Risorse correlate

Utilizza questi articoli di re:POST per procedure avanzate di AWS risoluzione dei problemi: