Salta al contenuto
Usando AWS re:Post, accetti AWS re:Post Termini di utilizzo
AWS re:Postre:Post
Informazioni su re:Post

Come posso risolvere i problemi dei pod Kubernetes in Amazon EKS?

8 minuti di lettura
0

I pod Kubernetes nel mio cluster Amazon Elastic Kubernetes Service (Amazon EKS) generano errori. Desidero identificare la causa principale dell'errore dei pod.

Risoluzione

Identifica l'errore che causa il problema del pod

  1. Per ottenere informazioni sui pod, esegui questo comando kubectl describe:

    kubectl describe pod YOUR_POD_NAME -n YOUR_NAMESPACE

    Nota: sostituisci YOUR_POD_NAME con il nome del tuo pod e YOUR_NAMESPACE il tuo namespace.

  2. Identifica il messaggio di errore nella sezione Events dell'output del comando.

    Esempio di output:

    Events:
  Type     Reason            Age                From               Message
  ----     ------            ----               ----               -------
  Warning  FailedScheduling  24s                default-scheduler  no nodes available to schedule pods
  Warning  FailedScheduling  19s (x2 over 22s)  default-scheduler  no nodes available to schedule pods

In base al messaggio di errore che ricevi, utilizza la seguente procedura di risoluzione dei problemi per risolvere il problema del pod.

Problemi di montaggio dei volumi EBS

L'esempio seguente è l'output di un comando kubectl describe pod ebs-pod. L'output mostra un errore di affinità del nodo del volume relativo al montaggio del volume Amazon Elastic Block Store (Amazon EBS):

Name:         ebs-pod
...
Status:       Pending
...
Events:
  Type     Reason            Age                 From               Message
  ----     ------            ----                ----               -------
  Warning FailedScheduling 88s (x20 over 96m) default-scheduler 0/2 nodes are available 2 node(s) had volume node affinity conflict

L'errore precedente si verifica quando pianifichi Persistent Volume Claim (PVC) per un pod in più zone di disponibilità. Non puoi pianificare il pod perché questo non riesce a connettersi al volume da un'altra zona di disponibilità. Per risolvere il problema, devi pianificare le richieste PVC in una zona di disponibilità.

Per risolvere l'errore precedente, completa i seguenti passaggi:

  1. Per ottenere informazioni su tutte le richieste PVC presenti nel namespace, esegui questo comando kubectl get pvc:

    kubectl get pvc -n YOUR_NAMESPACE

    Nota: sostituisci YOUR_NAMESPACE con il tuo namespace.

  2. Per ottenere informazioni sul Persistent Volume (PV), esegui questo comando kubectl get pv:

    kubectl get pv

  3. Per trovare il PV che corrisponde a una richiesta PVC, esegui questo comando kubectl describe pv:

    kubectl describe pv your_PV

    Nota: sostituisci your_PV con il nome del tuo PV.

  4. Verifica che l'ID del volume ricevuto dal comando precedente sia associato alla zona di disponibilità corretta.

  5. Controlla il nodo in cui si trova la zona di disponibilità.

Se si verifica un conflitto di affinità del nodo del volume, intraprendi una delle seguenti azioni:

  • Utilizza taint e tolleranze per assicurarti che i pod che utilizzano il montaggio di Amazon EBS vengano pianificati sul nodo corretto. Il nodo deve trovarsi nella zona di disponibilità in cui si trova il volume EBS. Per ulteriori informazioni, consulta Taints and Tolerations (Taint e tolleranze) sul sito web Kubernetes.
  • Utilizza StatefulSet invece di una distribuzione per creare un volume EBS univoco nella stessa zona di disponibilità per ogni pod nello StatefulSet. Per ulteriori informazioni, consulta StatefulSets (StatefulSet) sul sito web Kubernetes.

Il pod o lo StatefulSet potrebbe essere bloccato nello stato In sospeso. Questo è vero anche quando il pod o lo StatefulSet si trova nella stessa zona di disponibilità del volume EBS. Per risolvere il problema, esegui questo comando kubectl logs per controllare i log dei pod del driver CSI di Amazon EBS:

kubectl logs your-ebs-csi-controller -n your-kube-system -c your-csi-provisioner

Nota: sostituisci your-ebs-csi-controller con il tuo controller CSI di Amazon EBS. Inoltre, sostituisci your-kube-system con il tuo namespace predefinito e your-csi-provisioner con il nome di un container che utilizzi per estrarre i log.

Errore di stato ContainerCreating

Il seguente messaggio di errore si verifica quando il pod è bloccato nello stato ContainerCreating e networkPlugin: cni non gli assegna un indirizzo IP:

"Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "0fdf25254b1888afeda8bf89bc1dcb093d0661ae2c8c65a4736e473c73714c65" network for pod "test": networkPlugin cni failed to set up pod "test" network: add cmd: failed to assign an IP address to container."

Per risolvere l'errore di stato ContainerCreating, intraprendi le seguenti azioni:

Errore di stato CrashLoopBackOff

Ricevi il messaggio di errore "Back-Off restarting failed container".

Il messaggio di errore precedente si verifica perché il container non si avvia ripetutamente, quindi entra nello stato CrashLoopBackOff e si riavvia in modo persistente all'interno del pod.

Il mancato avvio ripetuto del container può essere causato dai seguenti problemi:

  • Memoria insufficiente
  • Sovraccarico di risorse
  • Errori di distribuzione
  • Problemi di dipendenze esterne come errori DNS
  • Dipendenze di terze parti
  • Errori a livello di container causati da conflitti tra porte

Per ottenere gli errori nei log del pod corrente, esegui questo comando kubectl logs:

kubectl logs YOUR_POD_NAME -n YOUR_NAMESPACE

Nota: sostituisci YOUR_POD_NAME con il nome del tuo pod e YOUR_NAMESPACE il tuo namespace.

Per ottenere gli errori nei log del pod precedente che si è bloccato, esegui questo comando kubectl logs --previous:

kubectl logs --previous YOUR_POD_NAME -n YOUR_NAMESPACE

Nota: sostituisci YOUR_POD_NAME con il nome del tuo pod e YOUR_NAMESPACE il tuo namespace.

Errori di controllo

Quando un pod si blocca, viene visualizzato un errore di controllo a causa di una connessione rifiutata o di un timeout del client.

Risolvi i problemi relativi a una connessione rifiutata

Se un controllo fallisce a causa di una connessione rifiutata, potresti ricevere uno dei seguenti messaggi di errore:

  • "Liveness probe failed: Get https://$POD_IP:8080/<healthcheck_path>: dial tcp POD_IP:8080: connect: connection refused."
  • "Readiness probe failed: Get https://$POD_IP:8080/<healthcheck_path>: dial tcp POD_IP:8080: connect: connection refused."

Per risolvere i problemi di connessione, completa i seguenti passaggi:

  1. Per ottenere manualmente il percorso di controllo dell'integrità definito nel manifesto del pod dal nodo worker, esegui questo comando:

    [ec2-user@ip-10-5-1-12 ~]$ curl -ikv podIP:8080//your_healthcheck_path

    Nota: sostituisci podIP con l'indirizzo IP del tuo pod e your_healthcheck_path con il nome del tuo percorso.

  2. Controlla il percorso di controllo dell'integrità definito nel manifesto del pod per il pod che non ha superato il controllo Liveness o il controllo Readiness. Per verificare il percorso di controllo dell'integrità, esegui questo comando:

    local@bastion-host ~ % kubectl exec YOUR_POD_NAME -- curl -ikv "http://localhost:8080/your_healthcheck_path"

    Nota: sostituisci YOUR_POD_NAME con il nome del tuo pod.

  3. Esegui la stessa immagine del container sull'host bastione.

  4. Verifica se riesci a ottenere il percorso di controllo dell'integrità definito per i controlli nel manifesto. Quindi verifica i log del container per individuare eventuali problemi, errori o timeout.

  5. Per verificare la presenza di errori nei log del kubelet del nodo worker su cui viene eseguito il pod, utilizza questo comando journalctl:

    [ec2-user@ip-10-5-1-12 ~]$ journalctl -u kubelet //optionally 'grep' with pod name

Risolvi i problemi relativi al timeout di un client

Se un controllo non viene superato a causa di un timeout del client, potresti ricevere uno dei seguenti messaggi di errore:

  • "Liveness probe failed: Get "http://podIP:8080/<healthcheck_path> ": context deadline exceeded (Client.Timeout exceeded while awaiting headers)."
  • "Readiness probe failed: Get "http://podIP:8080/<healthcheck_path> ": context deadline exceeded (Client.Timeout exceeded while awaiting headers)."

Per risolvere i problemi relativi al timeout del client, controlla se la configurazione è corretta per i controlli Liveness e Readiness dei pod dell'applicazione.

Se per i pod utilizzi un gruppo di sicurezza e ENABLE_POD_ENI=true, devi disattivare TCP early demux. Questa azione consente al kubelet di connettersi ai pod sulle interfacce di rete delle branch che utilizzano TCP.

Per disattivare TCP early demux, esegui questo comando kubectl patch:

kubectl patch daemonset aws-node -n kube-system \-p '{"spec": {"template": {"spec": {"initContainers": [{"env":[{"name":"DISABLE_TCP_EARLY_DEMUX","value":"true"}],"name":"aws-vpc-cni-init"}]}}}}'

Errore ImagePullBackOff

L'errore ImagePullbackoff si verifica quando un container in esecuzione in un pod non riesce a estrarre l'immagine richiesta da un registro del container.

L'errore può essere causato dai seguenti problemi:

  • Problemi di connettività di rete
  • Nome o tag dell'immagine non corretti
  • Credenziali mancanti
  • Autorizzazioni insufficienti

Per determinare la causa del problema, procedi nel seguente modo:

  1. Per verificare lo stato del pod, esegui questo comando:

    kubectl get pods -n YOUR_NAMESPACE

    Nota: sostituisci YOUR_NAMESPACE con il tuo namespace.

  2. Per ottenere i dettagli dell'errore del pod, esegui questo comando:

    kubectl describe pod YOUR_POD_NAME -n YOUR_NAMESPACE

    Nota: sostituisci YOUR_POD_NAME con il nome del tuo pod e YOUR_NAMESPACE il tuo namespace.

    Esempio di output:

    Events:
Type     Reason     Age                From                Message
----     ------     ----               ----                -------
Normal   Scheduled  18m                default-scheduler   Successfully assigned kube-system/kube-proxy-h4np6 to XXX.XXX.eu-west-1.compute.internal
Normal   Pulling    16m (x4 over 18m)  kubelet             Pulling image "<account-id>.dkr.ecr.eu-west-1.amazonaws.com/eks/kube-proxy:v1.21.5-eksbuild.2"
Warning  Failed     16m (x4 over 18m)  kubelet             Failed to pull image "<account-d>.dkr.ecr.eu-west-1.amazonaws.com/eks/kube-proxy:v1.21.5-eksbuild.2": rpc error: code = Unknown desc = Error response from daemon: manifest for <account-id>.dkr.ecr.eu-west-1.amazonaws.com/eks/kube-proxy:v1.21.5-eksbuild.2 not found: manifest unknown: Requested image not found

Per risolvere l'errore ImagePullbackoff, consulta Come posso risolvere gli errori di stato del pod ErrImagePull e ImagePullbackoff in Amazon EKS?

Argomenti
Containers
Tag
Amazon Elastic Kubernetes Service
Lingua
Italiano
AWS UFFICIALEAggiornata 2 mesi fa

Contenuto pertinente