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 la modalità automatica EKS, AWS si assume maggiori responsabilità per EC2 le istanze presenti nel tuo AWS account. 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 AWS e APIs 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 Enable node auto repair and investigate node health issues.

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

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

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

Ottieni i log dei nodi utilizzando i container di debug e kubectl CLI

Il modo consigliato per recuperare i log da un nodo della modalità automatica di EKS prevede l’utilizzo della 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 alla modalità automatica EKS nella console AWS

È 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 stato Pending e non vengono pianificati su un nodo Auto Mode, verifica se il pod o il manifesto di implementazione dispone di un nodeSelector. 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

EKS Auto Mode configura automaticamente le nuove EC2 istanze 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:

Rilevare i problemi di connettività dei nodi con il 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 EKS Auto Mode avvii un' EC2 istanza. 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, puoi eseguire l’analisi s. Per prima cosa, accedi a VPC Reachability Analyzer in Console di gestione AWS.

Condivisione di volumi tra pod

I nodi EKS Auto Mode sono SELinux configurati con una modalità di applicazione che fornisce un maggiore isolamento tra i Pod in esecuzione sullo stesso nodo. Quando SELinux è abilitata, alla maggior parte dei pod non privilegiati 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 gli eventi relativi a Karpenter, utilizza la seguente query Logs Insights: CloudWatch

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 eventi specifici relativi a Karpenter nei log di auditi 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 mostreranno una cronologia degli eventi correlati a Karpenter, aiutandoti a risolvere i problemi e a comprendere il comportamento della modalità automatica di EKS nel 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: