Questa pagina è stata tradotta dall'API Cloud Translation.

Risolvere i problemi relativi ai carichi di lavoro di cui è stato eseguito il deployment

Autopilot Standard

Questa pagina mostra come risolvere gli errori relativi ai carichi di lavoro di cui è stato eseguito il deployment in Google Kubernetes Engine (GKE).

Per consigli più generali sulla risoluzione dei problemi delle tue applicazioni, consulta la sezione Risoluzione dei problemi. Applicazioni nel documentazione di Kubernetes.

Tutti gli errori: controlla lo stato del pod

In caso di problemi con i pod di un carico di lavoro, Kubernetes aggiorna lo stato dei pod. con un messaggio di errore. Visualizza questi errori controllando lo stato di un pod utilizzando la console Google Cloud o lo strumento a riga di comando kubectl.

Console

Procedi nel seguente modo:

Nella console Google Cloud, vai alla pagina Carichi di lavoro.

Vai a Carichi di lavoro
Seleziona il carico di lavoro che vuoi esaminare. La scheda Panoramica mostra lo stato del carico di lavoro.
Nella sezione Pod gestiti, fai clic su un messaggio di stato di errore.

kubectl

Per visualizzare tutti i pod in esecuzione nel tuo cluster, esegui questo comando:

kubectl get pods

L'output è simile al seguente:

NAME       READY  STATUS             RESTARTS  AGE
POD_NAME   0/1    CrashLoopBackOff   23        8d

I potenziali errori sono elencati nella colonna Status.

Per ottenere maggiori dettagli su un pod specifico, esegui questo comando: :

kubectl describe pod POD_NAME

Sostituisci POD_NAME con il nome del pod che vuoi esaminare.

Nell'output, il campo Events mostra ulteriori informazioni sugli errori.

Per saperne di più, visualizza i log dei container:

kubectl logs POD_NAME

Questi log possono aiutarti a identificare se un comando o un codice nel contenitore ha causato un arresto anomalo del pod.

Dopo aver identificato l'errore, prova a risolvere il problema utilizzando le sezioni seguenti risolvere il problema.

Errore: CrashLoopBackOff

Lo stato CrashLoopBackOff non significa che c'è un errore specifico, indica che un container si arresta ripetutamente in modo anomalo dopo il riavvio. Quando un container si arresta in modo anomalo o si chiude poco dopo l'avvio (CrashLoop), Kubernetes tenta di riavviare il container. Con ogni errore riavvio, il ritardo (BackOff) prima del tentativo successivo aumenta in modo esponenziale (10, 20, 40, ecc.), fino a un massimo di 5 minuti.

Le sezioni seguenti ti aiutano a identificare il motivo per cui il container potrebbe avere un arresto anomalo.

Utilizzare il playbook interattivo sui pod con arresto anomalo in loop

Per iniziare a risolvere i problemi che causano uno stato CrashLoopBackOff, utilizza il playbook interattivo nella console Google Cloud:

Vai al playbook interattivo sui pod con arresto anomalo in loop:

Vai al Playbook
Nell'elenco a discesa Cluster, seleziona il cluster di cui vuoi risolvere i problemi. Se non riesci a trovare il cluster, inserisci il nome. nel filtro .
Nell'elenco a discesa Spazio dei nomi, seleziona lo spazio dei nomi a cui risolvere i problemi. Se non riesci a trovare lo spazio dei nomi, inseriscilo nel campo Filtra.
Esamina ogni sezione per identificarne la causa:
1. Identifica gli errori dell'applicazione
2. Esamina i problemi di memoria
3. Analisi delle interruzioni del nodo
4. Esamina gli errori dei probe di attività
5. Correla eventi di modifica
(Facoltativo) Per ricevere notifiche su errori CrashLoopBackOff futuri, nella sezione Suggerimenti per la mitigazione futura, seleziona Crea un avviso.

Ispeziona i log

Un container potrebbe arrestarsi in modo anomalo per diversi motivi e la verifica dei log di un pod può aiutarti a risolvere il problema alla radice.

Puoi controllare i log con la console Google Cloud o lo strumento a riga di comando kubectl.

Console

Procedi nel seguente modo:

Vai alla pagina Carichi di lavoro nella console Google Cloud.

Vai a Carichi di lavoro
Seleziona il carico di lavoro che vuoi esaminare. La scheda Panoramica mostra lo stato del carico di lavoro.
Nella sezione Pod gestiti, fai clic sul pod problematico.
Nel menu del pod, fai clic sulla scheda Log.

kubectl

Visualizza tutti i pod in esecuzione nel cluster:
```
kubectl get pods
```
Nell'output del comando precedente, cerca un pod con CrashLoopBackOff errore nella colonna Status.
Recupera i log del pod:
```
kubectl logs POD_NAME
```
Sostituisci POD_NAME con il nome del pod problematico.

Puoi anche passare il flag -p per ottenere i log per l'istanza precedente del contenitore di un pod, se esistente.

Controlla il codice di uscita del contenitore in crash

Per capire meglio il motivo dell'arresto anomalo del contenitore, individua il codice di uscita:

Descrivi il pod:
```
kubectl describe pod POD_NAME
```
Sostituisci POD_NAME con il nome del problema all'interno del pod.
Controlla il valore nel containers: CONTAINER_NAME: last state: exit code campo:
- Se il codice di uscita è 1, il container ha subito un arresto anomalo a causa dell'arresto anomalo dell'applicazione.
- Se il codice di uscita è 0, controlla per quanto tempo è stata in esecuzione l'app. Container all'uscita dal processo principale dell'applicazione. Se l'app termina molto rapidamente, il container potrebbe continuare a riavviarsi. Se si verifica questo errore, una soluzione è impostare il campo restartPolicy su OnFailure. Dopo aver apportato questa modifica, l'app si riavvia solo quando il codice di uscita non è 0.

Connettiti a un container in esecuzione

Per eseguire comandi bash dal contenitore in modo da poter testare la rete o controllare se hai accesso a file o database utilizzati dalla tua applicazione, apri una shell per il pod:

kubectl exec -it POD_NAME -- /bin/bash

Se nel pod è presente più di un container, aggiungi -c CONTAINER_NAME.

Errori: ImagePullBackOff ed ErrImagePull

Lo stato ImagePullBackOff o ErrImagePull indica che l'immagine utilizzata di un container non possono essere caricati dal registro di immagini.

Puoi verificare questo problema utilizzando la console Google Cloud o lo strumento a riga di comando kubectl.

Console

Procedi nel seguente modo:

Nella console Google Cloud, vai alla pagina Carichi di lavoro.

Vai a Carichi di lavoro
Seleziona il carico di lavoro che vuoi esaminare. La scheda Panoramica mostra lo stato del carico di lavoro.
Nella sezione Pod gestiti, fai clic sul pod problematico.
Nel menu del pod, fai clic sulla scheda Eventi.

kubectl

Per ottenere maggiori informazioni sull'immagine container di un pod, esegui questo comando: :

kubectl describe pod POD_NAME

Problema: l'immagine non è stata trovata

Se l'immagine non viene trovata, completa i seguenti passaggi:

Verifica che il nome dell'immagine sia corretto.
Verifica che il tag dell'immagine sia corretto. (Prova :latest o nessun tag per esegui il pull dell'immagine più recente).
Se l'immagine ha un percorso del registry completo, verifica che esista nel registro Docker che stai utilizzando. Se fornisci solo il nome dell'immagine, controlla il registro Docker Hub.
Nei cluster GKE Standard, prova a eseguire il pull dell'immagine Docker manualmente:
1. Utilizza SSH per connetterti al nodo:
  
  Ad esempio, per utilizzare SSH per connetterti a una VM, esegui questo comando:
```
gcloud compute ssh VM_NAME --zone=ZONE_NAME
```
  Sostituisci quanto segue:
  - VM_NAME: il nome della VM.
  - ZONE_NAME: un Zona di Compute Engine.
2. Genera un file di configurazione in /home/[USER]/.docker/config.json:
```
docker-credential-gcr configure-docker
```
  Assicurati che il file di configurazione in /home/[USER]/.docker/config.json includa il registry dell'immagine nel campo credHelpers. Ad esempio, il seguente file include le informazioni di autenticazione per le immagini ospitate su asia.gcr.io, eu.gcr.io, gcr.io, marketplace.gcr.io e us.gcr.io:
```
{
"auths": {},
"credHelpers": {
  "asia.gcr.io": "gcr",
  "eu.gcr.io": "gcr",
  "gcr.io": "gcr",
  "marketplace.gcr.io": "gcr",
  "us.gcr.io": "gcr"
}
}
```
3. Prova a eseguire il pull dell'immagine:
```
docker pull IMAGE_NAME
```
Se il pull dell'immagine funziona manualmente, probabilmente dovrai specificare ImagePullSecrets in un pod. I pod possono fare riferimento ai secret di estrazione delle immagini solo nel proprio spazio dei nomi, quindi questa procedura deve essere eseguita una volta per spazio dei nomi.

Errore: autorizzazione negata

Se ti viene mostrata un'"autorizzazione negata" o "nessun accesso pull" verifica che hai effettuato l'accesso e hai accesso all'immagine. Prova uno dei seguenti metodi, a seconda del registry in cui ospiti le immagini.

Artifact Registry

Se l'immagine è in Artifact Registry, account di servizio del pool di nodi richiede l'accesso in lettura al repository che contiene l'immagine.

Concedi il ruolo artifactregistry.reader all'account di servizio:

gcloud artifacts repositories add-iam-policy-binding REPOSITORY_NAME \
    --location=REPOSITORY_LOCATION \
    --member=serviceAccount:SERVICE_ACCOUNT_EMAIL \
    --role="roles/artifactregistry.reader"

Sostituisci quanto segue:

REPOSITORY_NAME: il nome del tuo Artifact Registry repository Git.
REPOSITORY_LOCATION: la regione del repository Artifact Registry.
SERVICE_ACCOUNT_EMAIL: l'indirizzo email del Account di servizio IAM associato al pool di nodi.

Container Registry

Se l'immagine si trova in Container Registry, il service account del pool di nodi ha bisogno dell'accesso in lettura al bucket Cloud Storage che contiene l'immagine.

Concedi il ruolo roles/storage.objectViewer all'account di servizio in modo che possa leggere dal bucket:

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
    --member=serviceAccount:SERVICE_ACCOUNT_EMAIL \
    --role=roles/storage.objectViewer

Sostituisci quanto segue:

SERVICE_ACCOUNT_EMAIL: l'indirizzo email dell'account servizio associato al tuo pool di nodi. Puoi elencare tutti gli account di servizio nel tuo progetto utilizzando gcloud iam service-accounts list.
BUCKET_NAME: il nome del bucket Cloud Storage che contiene le immagini. Puoi elencare tutti i bucket nel progetto utilizzando gcloud storage ls.

Se l'amministratore del registry ha configurato repository gcr.io in Artifact Registry per archiviare le immagini per il dominio gcr.io anziché in Container Registry, devi concedere l'accesso in lettura ad Artifact Registry anziché a Container Registry.

Registry privato

Se l'immagine si trova in un registry privato, potresti aver bisogno di chiavi per accedere alle immagini. Per ulteriori informazioni, vedi Utilizzo dei registri privati nella documentazione di Kubernetes.

Errore 401 Unauthorized: Cannot pull images from private container registry repository

Quando esegui il pull di un'immagine da un repository privato di Container Registry:

gcr.io/PROJECT_ID/IMAGE:TAG: rpc error: code = Unknown desc = failed to pull and
unpack image gcr.io/PROJECT_ID/IMAGE:TAG: failed to resolve reference
gcr.io/PROJECT_ID/IMAGE]:TAG: unexpected status code [manifests 1.0]: 401 Unauthorized

Warning  Failed     3m39s (x4 over 5m12s)  kubelet            Error: ErrImagePull
Warning  Failed     3m9s (x6 over 5m12s)   kubelet            Error: ImagePullBackOff
Normal   BackOff    2s (x18 over 5m12s)    kubelet            Back-off pulling image

Per risolvere l'errore:

Identifica il nodo su cui è in esecuzione il pod:

kubectl describe pod POD_NAME | grep "Node:"

Verifica che il nodo identificato nel passaggio precedente disponga dello spazio di archiviazione ambito:

gcloud compute instances describe NODE_NAME \
    --zone=COMPUTE_ZONE --format="flattened(serviceAccounts[].scopes)"

L'ambito di accesso del nodo deve contenere almeno uno dei seguenti ambiti:

serviceAccounts[0].scopes[0]: https://www.googleapis.com/auth/devstorage.read_only
serviceAccounts[0].scopes[0]: https://www.googleapis.com/auth/cloud-platform

Se il nodo non contiene uno di questi ambiti, ricrea il pool di nodi.

Ricrea il pool di nodi a cui appartiene il nodo con un ambito sufficiente. Tu non possono modificare i nodi esistenti, devi ricrearlo con l'ambito di attività.

Consigliato: crea un nuovo pool di nodi con l'ambito gke-default:

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --zone=COMPUTE_ZONE \
    --scopes="gke-default"

Crea un nuovo pool di nodi con ambito di archiviazione:

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --zone=COMPUTE_ZONE \
    --scopes="https://www.googleapis.com/auth/devstorage.read_only"

Errore: pod non pianificabile

Uno stato PodUnschedulable indica che il pod non può essere pianificato per motivi di risorse insufficienti o per un errore di configurazione.

Se disponi metriche configurate del piano di controllo, puoi trovare ulteriori informazioni su questi errori in metriche dello strumento di pianificazione e server API metriche.

Usa il playbook interattivo per i pod non pianificabili

Puoi risolvere gli errori relativi a PodUnschedulable utilizzando il playbook interattivo nella console Google Cloud:

Vai al playbook interattivo sui pod non pianificabili:

Vai al Playbook
Nell'elenco a discesa Cluster, seleziona il cluster a cui vuoi risolvere i problemi. Se non riesci a trovare il cluster, inserisci il nome. nel filtro .
Nell'elenco a discesa Spazio dei nomi, seleziona lo spazio dei nomi a cui risolvere i problemi. Se non riesci a trovare lo spazio dei nomi, inseriscilo nel campo Filtra.
Per aiutarti a identificare la causa, analizza ciascuna delle sezioni della guida pratica:
1. Esamina CPU e memoria
2. Esamina il numero massimo di pod per nodo
3. Esamina il comportamento del gestore della scalabilità automatica
4. Esamina altre modalità di errore
5. Correla eventi di modifica
(Facoltativo) Per ricevere notifiche su PodUnschedulable in futuro errori, nella sezione Suggerimenti per la mitigazione futura, seleziona Crea un avviso .

Errore: risorse insufficienti

È possibile che si verifichi un errore che indica una mancanza di CPU, memoria o altro risorsa. Ad esempio: No nodes are available that match all of the predicates: Insufficient cpu (2), che indica che su due nodi non c'è abbastanza CPU disponibili per soddisfare le richieste di un pod.

Se le richieste di risorse del pod superano quelle di un singolo nodo di qualsiasi pool di nodi idoneo, GKE non pianifica il pod e non attiva lo scale up per aggiungere un nuovo nodo. Per consentire a GKE di pianificare il pod, devi richiedere meno risorse per il pod o creare un nuovo pool di nodi con risorse sufficienti.

Puoi anche attivare provisioning automatico dei nodi in modo che GKE possa creare automaticamente pool di nodi con nodi possono essere eseguiti i pod non pianificati.

La richiesta di CPU predefinita è 100 m o il 10% di una CPU (o un core). Se vuoi richiedere più o meno risorse, specifica il valore nella specifica del pod in spec: containers: resources: requests.

Errore: MatchNodeSelector

MatchNodeSelector indica che non sono presenti nodi corrispondenti al selettore di etichette del pod.

Per verificare, controlla le etichette specificate nel campo nodeSelector della specifica del pod in spec: nodeSelector.

Per vedere come sono etichettati i nodi del cluster, esegui il seguente comando:

kubectl get nodes --show-labels

Per collegare un'etichetta a un nodo, esegui questo comando:

kubectl label nodes NODE_NAME LABEL_KEY=LABEL_VALUE

Sostituisci quanto segue:

NODE_NAME: il nodo a cui vuoi aggiungere un'etichetta.
LABEL_KEY: la chiave dell'etichetta.
LABEL_VALUE: il valore dell'etichetta.

Per ulteriori informazioni, consulta Assegnazione di pod ai nodi nella documentazione di Kubernetes.

Errore: PodToleratesNodeTaints

PodToleratesNodeTaints indica che il pod non può essere pianificato su alcun nodo perché il pod non ha tolleranze che corrispondono incompatibilità dei nodi.

Per verificare che sia così, esegui questo comando:

kubectl describe nodes NODE_NAME

Nell'output, controlla il campo Taints, in cui sono elencate le coppie chiave-valore e di programmazione degli effetti.

Se l'effetto elencato è NoSchedule, nessun pod può essere pianificato su quel nodo a meno che non abbia una tolleranza corrispondente.

Un modo per risolvere il problema è rimuovere l'incompatibilità. Ad esempio, per rimuovere una Incompatibilità NoSchedule, esegui questo comando:

kubectl taint nodes NODE_NAME key:NoSchedule-

Errore: PodFitsHostPorts

PodFitsHostPorts indica che una porta che un nodo sta tentando di utilizzare è sono già in uso.

Per risolvere il problema, controlla il valore hostPort della specifica del pod in spec: containers: ports: hostPort. Potresti dover modificare questo valore impostando un'altra porta.

Errore: non ha disponibilità minima

Se un nodo dispone di risorse adeguate, ma visualizzi ancora il messaggio Does not have minimum availability, controlla lo stato del pod. Se lo stato è SchedulingDisabled o Cordoned, il nodo non può pianificare nuovi pod. Puoi controllare lo stato di un utilizzando la console Google Cloud o lo strumento a riga di comando kubectl.

Console

Procedi nel seguente modo:

Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

Vai a Google Kubernetes Engine
Seleziona il cluster che vuoi esaminare. La scheda Nodi mostra i nodi e il relativo stato.

Per abilitare la pianificazione sul nodo, segui questi passaggi:

Nell'elenco, fai clic sul nodo che vuoi esaminare.
Nella sezione Dettagli nodo, fai clic su Non pianificabile.

kubectl

Per ottenere gli stati dei nodi, esegui il seguente comando:

kubectl get nodes

Per attivare la pianificazione sul nodo, esegui:

kubectl uncordon NODE_NAME

Errore: limite massimo di pod per nodo raggiunto

Se il valore del campo Numero massimo di pod per nodo raggiunto da tutti i nodi nel cluster, i pod rimarranno bloccati Stato non pianificabile. Nella scheda Eventi del pod, viene visualizzato un messaggio inclusa la frase Too many pods.

Per risolvere questo errore, completa i seguenti passaggi:

Controlla la configurazione di Maximum pods per node dalla scheda Nodi nei dettagli del cluster GKE nella console Google Cloud.
Recupera un elenco di nodi:
```
kubectl get nodes
```
Per ogni nodo, verifica il numero di pod in esecuzione sul nodo:
```
kubectl get pods -o wide | grep NODE_NAME | wc -l
```
Se il limite viene raggiunto, aggiungi un nuovo pool di nodi o altri nodi al pool di nodi esistente.

Problema: raggiungere la dimensione massima del pool di nodi con il gestore della scalabilità automatica dei cluster abilitato

Se il pool di nodi ha raggiunto il numero massimo dimensioni in base alla configurazione del gestore della scalabilità automatica dei cluster, fai lo scale up per il pod che altrimenti verrebbe pianificato con questo nodo piscina. Se vuoi che il pod venga pianificato con questo pool di nodi, modifica gestore della scalabilità automatica dei cluster configurazione.

Problema: raggiungere la dimensione massima del pool di nodi con il gestore della scalabilità automatica dei cluster disabilitato

Se il pool di nodi ha raggiunto il numero massimo di nodi e il gestore della scalabilità automatica dei cluster è disabilitato, GKE non può pianificare il pod con il pool di nodi. Aumenta le dimensioni del pool di nodi o abilita la scalabilità automatica del cluster per consentire a GKE di ridimensionare automaticamente il cluster.

Errore: PersistentVolumeClaim non assegnati

Unbound PersistentVolumeClaims indica che il pod fa riferimento a un PersistentVolumeClaim non associato. Questo errore può verificarsi se le tue Impossibile eseguire il provisioning del PersistentVolume. Puoi verificare che il provisioning non sia riuscito ottenere gli eventi per PersistentVolumeClaim ed esaminarli errori.

Per ottenere gli eventi, esegui il seguente comando:

kubectl describe pvc STATEFULSET_NAME-PVC_NAME-0

Sostituisci quanto segue:

STATEFULSET_NAME: il nome dell'oggetto StatefulSet.
PVC_NAME: il nome dell'oggetto PersistentVolumeClaim.

Ciò può accadere anche se si è verificato un errore di configurazione durante il pre-provisioning manuale di un volume permanente e la relativa associazione a una richiesta di volume permanente.

Per risolvere questo errore, prova a eseguire di nuovo il pre-provisioning del volume.

Errore: quota insufficiente

Verifica che il tuo progetto disponga di una quota Compute Engine sufficiente per consentire a GKE di eseguire l'upgrade del cluster. Se GKE tenta di un nodo per pianificare il pod e lo scale up supererebbe quota disponibile per il progetto, ricevi l'errore scale.up.error.quota.exceeded per creare un nuovo messaggio email.

Per saperne di più, consulta Errori di ScaleUp.

Problema: API deprecate

Assicurati di non utilizzare API ritirate che vengono rimosse con la versione minore del tuo cluster. Per saperne di più, vedi Ritiri di GKE.

Passaggi successivi

Se hai bisogno di ulteriore assistenza, contatta Assistenza clienti Google Cloud.