Risolvere i problemi relativi agli eventi CrashLoopBackOff

Questa pagina ti aiuta a risolvere i problemi relativi ai pod che riscontrano eventi CrashLoopBackOff in Google Kubernetes Engine (GKE).

Questa pagina è rivolta agli sviluppatori di applicazioni che vogliono identificare problemi a livello di app, come errori di configurazione o bug correlati al codice, che causano l'arresto anomalo dei container. È anche per gli amministratori e gli operatori della piattaforma che devono identificare le cause principali a livello di piattaforma per i riavvii dei container, come esaurimento delle risorse, interruzioni dei nodi o probe di attività configurati in modo errato. Per maggiori informazioni sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta Ruoli utente e attività comuni di GKE. Trusted Cloud by S3NS

Comprendere un evento CrashLoopBackOff

Quando il pod è bloccato nello stato CrashLoopBackOff, un container al suo interno viene avviato e arrestato o chiuso ripetutamente. Questo CrashLoop attiva Kubernetes per tentare di riavviare il container rispettando il suo restartPolicy. A ogni riavvio non riuscito, il ritardo BackOff prima del tentativo successivo aumenta in modo esponenziale (ad esempio, 10 secondi, 20 secondi, 40 secondi), fino a un massimo di cinque minuti.

Sebbene questo evento indichi un problema all'interno del contenitore, è anche un prezioso segnale diagnostico. Un evento CrashLoopBackOff conferma che molti passaggi fondamentali della creazione del pod, come l'assegnazione a un nodo e il pull dell'immagine container, sono già stati completati. Queste informazioni ti consentono di concentrare l'indagine sull'app o sulla configurazione del container, anziché sull'infrastruttura del cluster.

Lo stato CrashLoopBackOff si verifica a causa del modo in cui Kubernetes, in particolare kubelet, gestisce l'arresto dei container in base alle norme di riavvio del pod. Il ciclo in genere segue questo schema:

1. Il container viene avviato.
2. Il container esce.
3. kubelet osserva il container arrestato e lo riavvia in base al restartPolicy del pod.
4. Questo ciclo si ripete, con il container riavviato dopo un ritardo di backoff esponenziale crescente.

Il restartPolicy del Pod è la chiave di questo comportamento. La policy predefinita, Always, è la causa più comune di questo ciclo perché riavvia un container se esce per qualsiasi motivo, anche dopo un'uscita riuscita. La policy OnFailure ha meno probabilità di causare un loop perché si riavvia solo con codici di uscita diversi da zero, mentre la policy Never evita completamente il riavvio.

Identificare i sintomi di un evento CrashLoopBackOff

Un pod con lo stato CrashLoopBackOff è l'indicazione principale di un evento CrashLoopBackOff.

Tuttavia, potresti riscontrare alcuni sintomi meno evidenti di un evento CrashLoopBackOff:

• Zero repliche integre per un workload.
• Una forte diminuzione delle repliche integre.
• I workload con la scalabilità automatica orizzontale dei pod abilitata vengono scalati lentamente o non riescono a scalare.

Se un carico di lavoro system (ad esempio, un agente di logging o delle metriche) ha lo stato CrashLoopBackOff, potresti notare anche i seguenti sintomi:

• Alcune metriche di GKE non vengono segnalate.
• Alcune dashboard e grafici GKE presentano lacune.
• Problemi di connettività nel networking a livello di pod.

Se noti uno di questi sintomi meno evidenti, il passaggio successivo è verificare se si è verificato un evento CrashLoopBackOff.

Confermare un evento CrashLoopBackOff

Per confermare e analizzare un evento CrashLoopBackOff, raccogli prove dagli eventi Kubernetes e dai log delle app del container. Queste due fonti forniscono visioni diverse, ma complementari, del problema:

• Gli eventi Kubernetes confermano che un pod sta generando errori irreversibili.
• I log delle app del container possono mostrare perché il processo all'interno del container non va a buon fine.

Per visualizzare queste informazioni, seleziona una delle seguenti opzioni:

Utilizzare il playbook interattivo per i pod con arresto anomalo in loop

Dopo aver confermato un evento CrashLoopBackOff, inizia a risolvere i problemi con il playbook interattivo:

1. Nella Trusted Cloud console, vai alla pagina Playbook interattivo GKE - Pod con arresto anomalo in loop.

   Vai a Pod in loop di arresto anomalo

2. Nell'elenco Cluster, seleziona il cluster di cui vuoi risolvere i problemi. Se non riesci a trovare il cluster, inserisci il nome del cluster nel campo Filtro.

3. Nell'elenco Spazio dei nomi, seleziona lo spazio dei nomi per cui vuoi risolvere i problemi. Se non riesci a trovare il tuo spazio dei nomi, inseriscilo nel campo Filtro.

4. Esamina ogni sezione per rispondere alle seguenti domande:

   1. Identifica gli errori dell'app: quali container sono in fase di riavvio?
   2. Analizza i problemi di memoria insufficiente: esiste un errore di configurazione o relativo all'app?
   3. Analizza le interruzioni del nodo: le interruzioni nella risorsa del nodo causano il riavvio del container?
   4. Esamina gli errori dei probe di attività: i probe di attività stanno arrestando i container?
   5. Correla eventi di modifica: cosa è successo durante il periodo in cui è iniziato l'arresto anomalo dei container?

5. (Facoltativo) Per ricevere notifiche sugli eventi futuri di CrashLoopBackOff, nella sezione Suggerimenti per la mitigazione futura, seleziona Crea un avviso.

Se il problema persiste dopo aver utilizzato il playbook, leggi il resto della guida per ulteriori informazioni sulla risoluzione degli eventi CrashLoopBackOff.

Risolvere un evento CrashLoopBackOff

Le sezioni seguenti ti aiutano a risolvere le cause più comuni degli eventi CrashLoopBackOff:

• Esaurimento delle risorse (OOMKilled)
• Errore del probe di attività
• App con configurazione errata

Risolvi l'esaurimento delle risorse

Un evento CrashLoopBackOff è spesso causato da un problema di esaurimento della memoria. Puoi confermare se questa è la causa se l'output di kubectl describe mostra quanto segue:

Last State: Terminated
  Reason: OOMKilled

Per informazioni su come diagnosticare e risolvere gli eventi OOM, vedi Risolvere i problemi relativi agli eventi OOM.

Risolvi gli errori dei probe di attività

Un probe di attività è un controllo di integrità periodico eseguito da kubelet. Se il probe non riesce a un numero specificato di volte (il numero predefinito è tre), kubelet riavvia il container, causando potenzialmente un evento CrashLoopBackOff se gli errori del probe continuano.

Confermare se la causa è un probe di attività

Per verificare se gli errori del probe di attività attivano l'evento CrashLoopBackOff, esegui una query nei log di kubelet. Questi log spesso contengono messaggi espliciti che indicano errori di sonda e riavvii successivi.

1. Nella console Trusted Cloud , vai alla pagina Esplora log.

   Vai a Esplora log

2. Nel riquadro della query, filtra i riavvii correlati al probe di attività inserendo la seguente query:

   resource.type="k8s_node"
   log_id("kubelet")
   jsonPayload.MESSAGE:"failed liveness probe, will be restarted"
   resource.labels.cluster_name="CLUSTER_NAME"
   

   Sostituisci CLUSTER_NAME con il nome del cluster.

3. Rivedi l'output. Se un errore del probe di attività è la causa degli eventi CrashLoopBackOff, la query restituisce messaggi di log simili ai seguenti:

   Container probe failed liveness probe, will be restarted
   

Dopo aver confermato che i probe di attività sono la causa dell'evento CrashLoopBackOff, procedi alla risoluzione dei problemi relativi alle cause comuni:

• Esamina la configurazione del probe di attività.
• Controlla l'utilizzo di CPU e I/O del disco.
• Gestire deployment di grandi dimensioni.
• Errori temporanei dell'indirizzo.
• Indirizzare il consumo di risorse di Probe.

Rivedi la configurazione del probe di attività

Le sonde configurate in modo errato sono una causa frequente di eventi CrashLoopBackOff. Controlla le seguenti impostazioni nel manifest della sonda:

• Verifica il tipo di probe: la configurazione del probe deve corrispondere al modo in cui la tua app segnala il suo stato. Ad esempio, se la tua app ha un URL di controllo di integrità (come /healthz), utilizza il tipo di probe httpGet. Se il suo stato di integrità è determinato dall'esecuzione di un comando, utilizza il tipo di probe exec. Ad esempio, per verificare se una porta di rete è aperta e in ascolto, utilizza il tipo di probe tcpSocket.
• Controlla i parametri del probe:
  • Percorso (per il tipo di probe httpGet): assicurati che il percorso HTTP sia corretto e che la tua app esegua i controlli di integrità.
  • Porta: verifica che la porta configurata nel probe sia effettivamente utilizzata ed esposta dall'app.
  • Comando (per il tipo di probe exec): assicurati che il comando esista all'interno del contenitore, restituisca un codice di uscita 0 in caso di esito positivo e venga completato entro il periodo timeoutSeconds configurato.
  • Timeout: assicurati che il valore di timeoutSeconds sia sufficiente per consentire all'app di rispondere, soprattutto durante l'avvio o sotto carico.
  • Ritardo iniziale (initialDelaySeconds): verifica che il ritardo iniziale sia sufficiente per l'avvio dell'app prima dell'inizio dei probe.

Per ulteriori informazioni, consulta la sezione Configurare i probe di attività, idoneità e avvio nella documentazione di Kubernetes.

Ispeziona l'utilizzo di CPU e I/O del disco

La contesa delle risorse comporta timeout del probe, che è una delle principali cause di errori del probe di attività. Per verificare se l'utilizzo delle risorse è la causa dell'errore del probe di attività, prova le seguenti soluzioni:

• Analizza l'utilizzo della CPU: monitora l'utilizzo della CPU del container interessato e del nodo su cui è in esecuzione durante gli intervalli di probe. Una metrica fondamentale da monitorare è kubernetes.io/container/cpu/core_usage_time. L'utilizzo elevato della CPU sul container o sul nodo può impedire all'app di rispondere al probe in tempo.
• Monitora l'I/O del disco: controlla le metriche di I/O del disco per il nodo. Puoi utilizzare la metrica compute.googleapis.com/guest/disk/operation_time per valutare la quantità di tempo dedicata alle operazioni su disco, che sono classificate in letture e scritture. Un I/O del disco elevato può rallentare notevolmente l'avvio del container, l'inizializzazione dell'app o le prestazioni complessive dell'app, causando timeout del probe.

Gestire deployment di grandi dimensioni

In scenari in cui viene eseguito il deployment di un numero elevato di pod contemporaneamente (ad esempio, da uno strumento CI/CD come ArgoCD), un improvviso aumento dei nuovi pod può sovraccaricare le risorse del cluster, causando l'esaurimento delle risorse del control plane. Questa mancanza di risorse ritarda l'avvio dell'app e può causare il ripetuto fallimento dei probe di attività prima che le app siano pronte.

Per risolvere il problema, prova le seguenti soluzioni:

• Implementa deployment scaglionati: implementa strategie per eseguire il deployment dei pod in batch o per un periodo di tempo più lungo per evitare di sovraccaricare le risorse dei nodi.
• Riconfigura o scala i nodi: se i deployment scaglionati non sono fattibili, valuta l'upgrade dei nodi con dischi più veloci o più grandi o con Persistent Volume Claims per gestire meglio l'aumento della domanda di I/O. Assicurati che lo scaling automatico del cluster sia configurato correttamente.
• Attendi e osserva: in alcuni casi, se il cluster non è gravemente sottoutilizzato, i workload potrebbero essere sottoposti a deployment dopo un ritardo significativo (a volte 30 minuti o più).

Errori temporanei dell'indirizzo

L'app potrebbe riscontrare errori temporanei o rallentamenti durante l'avvio o l'inizializzazione, causando l'esito negativo iniziale del test. Se l'app alla fine recupera, valuta la possibilità di aumentare i valori definiti nei campi initialDelaySeconds o failureThreshold nel manifest del probe di attività.

Affronta il consumo di risorse del probe

In rari casi, l'esecuzione del probe di attività stesso potrebbe consumare risorse significative, il che potrebbe attivare vincoli di risorse che potrebbero portare alla terminazione del container a causa di un errore OOM. Assicurati che i comandi di probing siano leggeri. È più probabile che una sonda leggera venga eseguita in modo rapido e affidabile, il che le consente di segnalare con maggiore precisione lo stato effettivo della tua app.

Risolvi gli errori di configurazione delle app

Le configurazioni errate delle app causano molti eventi CrashLoopBackOff. Per capire perché la tua app si arresta, il primo passo è esaminare il codice di uscita. Questo codice determina il percorso di risoluzione dei problemi:

• Il codice di uscita 0 indica un'uscita riuscita, il che è inatteso per un servizio a lunga esecuzione e indica problemi con il punto di ingresso del container o con la progettazione dell'app.
• Un codice di uscita diverso da zero segnala un arresto anomalo dell'app, indirizzando l'attenzione verso errori di configurazione, problemi di dipendenza o bug nel codice.

Trovare il codice di uscita

Per trovare il codice di uscita della tua app:

1. Descrivi il pod:

   kubectl describe pod POD_NAME -n NAMESPACE_NAME
   

   Sostituisci quanto segue:

   • POD_NAME: il nome del pod problematico.
   • NAMESPACE_NAME: lo spazio dei nomi del pod.

2. Nell'output, esamina il campo Exit Code che si trova nella sezione Last State per il contenitore pertinente. Se il codice di uscita è 0, consulta Risolvere i problemi relativi alle uscite riuscite (codice di uscita 0). Se il codice di uscita è un numero diverso da 0, consulta Risolvere i problemi relativi agli arresti anomali delle app (codice di uscita diverso da zero).

Risolvere i problemi relativi alle uscite riuscite (codice di uscita 0)

Un codice di uscita 0 in genere indica che il processo del container è terminato correttamente. Sebbene questo sia il risultato che vuoi per un job basato su attività, può segnalare un problema per un controller a esecuzione prolungata come un Deployment, uno StatefulSet o un ReplicaSet.

Questi controller funzionano per garantire che un pod sia sempre in esecuzione, quindi considerano qualsiasi uscita come un errore da correggere. kubelet impone questo comportamento rispettando restartPolicy del pod (che per impostazione predefinita è Always), riavviando il container anche dopo un'uscita riuscita. Questa azione crea un loop che alla fine attiva lo stato CrashLoopBackOff.

I motivi più comuni per le uscite riuscite impreviste sono i seguenti:

• Il comando del container non avvia un processo permanente: un container rimane in esecuzione solo finché è in esecuzione il processo iniziale (command o entrypoint). Se questo processo non è un servizio a esecuzione prolungata, il container esce non appena il comando viene completato. Ad esempio, un comando come ["/bin/bash"] viene chiuso immediatamente perché non ha script da eseguire. Per risolvere il problema, assicurati che il processo iniziale del container avvii un processo che viene eseguito continuamente.

• L'app worker esce quando una coda di lavoro è vuota: molte app worker sono progettate per controllare una coda per un'attività e uscire in modo pulito se la coda è vuota. Per risolvere il problema, puoi utilizzare un controller Job (progettato per le attività che vengono eseguite fino al completamento) o modificare la logica dell'app per eseguirla come servizio persistente.

• Uscita dell'app a causa di una configurazione mancante o non valida: la tua app potrebbe uscire immediatamente se mancano le istruzioni di avvio richieste, ad esempio argomenti della riga di comando, variabili di ambiente o un file di configurazione critico.

  Per risolvere il problema, esamina innanzitutto i log della tua app per individuare messaggi di errore specifici relativi al caricamento della configurazione o ai parametri mancanti. Quindi, verifica quanto segue:

  • Argomenti o ambiente dell'app: assicurati che tutti gli argomenti della riga di comando e le variabili di ambiente necessari vengano passati correttamente al container come previsto dalla tua app.
  • Presenza del file di configurazione: verifica che tutti i file di configurazione richiesti siano presenti nei percorsi previsti all'interno del container.
  • Contenuti del file di configurazione: convalida i contenuti e il formato dei file di configurazione per verificare la presenza di errori di sintassi, campi obbligatori mancanti o valori errati.

  Un esempio comune di questo problema si verifica quando un'app è configurata per leggere da un file montato con un volume ConfigMap. Se ConfigMap non è allegato, è vuoto o contiene chiavi con nomi errati, un'app progettata per uscire quando la sua configurazione è mancante potrebbe arrestarsi con un codice di uscita 0. In questi casi, verifica le seguenti impostazioni: - Il nome di ConfigMap nella definizione del volume del pod corrisponda al suo nome effettivo. - Le chiavi all'interno di ConfigMap corrispondono a ciò che la tua app si aspetta di trovare come nomi file nel volume montato.

Risolvere i problemi relativi agli arresti anomali delle app (codice di uscita diverso da zero)

Quando un container esce con un codice diverso da zero, Kubernetes lo riavvia. Se il problema sottostante che ha causato l'errore è persistente, l'app si arresta di nuovo in modo anomalo e il ciclo si ripete, culminando in uno stato CrashLoopBackOff.

Il codice di uscita diverso da zero è un segnale chiaro che si è verificato un errore all'interno dell'app stessa, che indirizza i tuoi sforzi di debug verso il suo funzionamento interno e l'ambiente. I seguenti problemi spesso causano questa interruzione:

• Errori di configurazione: un codice di uscita diverso da zero spesso indica problemi con la configurazione dell'app o con l'ambiente in cui viene eseguita. Controlla la tua app per questi problemi comuni:

  • File di configurazione mancante: l'app potrebbe non essere in grado di trovare o accedere a un file di configurazione obbligatorio.
  • Configurazione non valida: il file di configurazione potrebbe contenere errori di sintassi, valori errati o impostazioni incompatibili, causando l'arresto anomalo dell'app.
  • Problemi di autorizzazioni: l'app potrebbe non disporre delle autorizzazioni necessarie per leggere o scrivere il file di configurazione.
  • Variabili di ambiente: variabili di ambiente errate o mancanti possono causare il malfunzionamento o l'impossibilità di avviare l'app.
  • entrypoint o command non valido: il comando specificato nel campo entrypoint o command del contenitore potrebbe non essere corretto. Questo problema può verificarsi con immagini appena implementate in cui il percorso dell'eseguibile è errato o il file stesso non è presente nell'immagine del container. Questa configurazione errata spesso genera il codice di uscita 128.

  • Aggiornamenti incontrollati delle immagini (tag :latest): se le immagini del tuo workload utilizzano il tag :latest, i nuovi pod potrebbero estrarre una versione aggiornata dell'immagine che introduce modifiche che causano errori.

    Per garantire coerenza e riproducibilità, utilizza sempre tag immagine specifici e immutabili (ad esempio v1.2.3) o digest SHA (ad esempio sha256:45b23dee08...) negli ambienti di produzione. Questa pratica contribuisce a garantire che i contenuti delle immagini vengano recuperati ogni volta.

• Problemi di dipendenza: la tua app potrebbe arrestarsi in modo anomalo se non riesce a connettersi agli altri servizi da cui dipende o se l'autenticazione non riesce o se non dispone di autorizzazioni sufficienti per accedervi.

  • Servizio esterno non disponibile: l'app potrebbe dipendere da servizi esterni (ad esempio database o API) non raggiungibili a causa di problemi di connettività di rete o interruzioni del servizio. Per risolvere questo problema, connettiti al pod. Per saperne di più, consulta Debug dei pod in esecuzione nella documentazione di Kubernetes.

    Dopo aver eseguito la connessione al pod, puoi eseguire comandi per verificare l'accesso a file, database o per testare la rete. Ad esempio, puoi utilizzare uno strumento come curl per provare a raggiungere l'URL di un servizio. Questa azione ti aiuta a determinare se un problema è causato da criteri di rete, DNS o dal servizio stesso.

  • Errori di autenticazione: l'app potrebbe non essere in grado di autenticarsi con servizi esterni a causa di credenziali errate. Esamina i log del container per messaggi come 401 Unauthorized (credenziali non valide) o 403 Forbidden (autorizzazioni insufficienti), che spesso indicano che il account di servizio per il pod non dispone dei ruoli IAM necessari per effettuare chiamate di servizio Trusted Cloud by S3NS esterne.

    Se utilizzi la federazione delle identità per i carichi di lavoro GKE, verifica che l'identificatore principale disponga delle autorizzazioni richieste per l'attività. Per ulteriori informazioni sulla concessione dei ruoli IAM alle entità utilizzando Workload Identity Federation per GKE, consulta Configurare l'autorizzazione e le entità. Devi anche verificare che l'utilizzo delle risorse di GKE Metadata Server non abbia superato i limiti.

  • Timeout: l'app potrebbe subire timeout durante l'attesa di risposte da servizi esterni, causando arresti anomali.

• Errori specifici dell'app: se la configurazione e le dipendenze esterne sembrano corrette, l'errore potrebbe trovarsi nel codice dell'app. Controlla i log dell'app per questi errori interni comuni:

  • Eccezioni non gestite: i log dell'app potrebbero contenere stack trace o messaggi di errore che indicano eccezioni non gestite o altri bug correlati al codice.
  • Deadlock o livelock: l'app potrebbe essere bloccata in un deadlock, in cui più processi sono in attesa del completamento reciproco. In questo scenario, l'app potrebbe non uscire, ma smette di rispondere a tempo indeterminato.
  • Conflitti di porta: l'app potrebbe non avviarsi se tenta di eseguire il binding a una porta già in uso da un altro processo.
  • Librerie incompatibili: l'app potrebbe dipendere da librerie o dipendenze mancanti o incompatibili con l'ambiente di runtime.

  Per trovare la causa principale, esamina i log del container per un messaggio di errore specifico o una analisi dello stack. Queste informazioni ti aiutano a decidere se correggere il codice dell'app, modificare i limiti delle risorse o correggere la configurazione dell'ambiente. Per maggiori informazioni sui log, consulta Informazioni sui log di GKE.

Passaggi successivi

• Se non riesci a trovare una soluzione al tuo problema nella documentazione, consulta la sezione Richiedere assistenza per ulteriore aiuto, inclusi consigli sui seguenti argomenti:

  • Aprire una richiesta di assistenza contattando l'assistenza clienti cloud.
  • Ricevere assistenza dalla community ponendo domande su StackOverflow e utilizzando il tag google-kubernetes-engine per cercare problemi simili. Puoi anche unirti al canale Slack #kubernetes-engine per ulteriore assistenza della community.
  • Apertura di bug o richieste di funzionalità utilizzando lo strumento di monitoraggio dei problemi pubblico.