Risolvere i problemi relativi agli eventi CrashLoopBackOff

Se i tuoi pod in Google Kubernetes Engine (GKE) sono bloccati in uno stato CrashLoopBackOff, significa che uno o più container vengono avviati ed escono ripetutamente. Questo comportamento probabilmente rende le tue app instabili o completamente non disponibili.

Utilizza questa pagina per diagnosticare e risolvere le cause sottostanti, che spesso rientrano in categorie come limitazioni delle risorse, problemi con i probe di attività, errori dell'app o errori di configurazione. La risoluzione dei problemi consente di garantire che le tue app funzionino in modo affidabile e rimangano disponibili per i tuoi utenti.

Queste informazioni sono importanti per gli sviluppatori di applicazioni che vogliono identificare e risolvere problemi a livello di app, come errori di codifica, punti di ingresso errati, problemi con i file di configurazione o problemi di connessione alle dipendenze. Gli amministratori e gli operatori della piattaforma possono identificare e risolvere i problemi relativi alla piattaforma, come l'esaurimento delle risorse (OOMKilled), le interruzioni dei nodi o i probe di attività configurati in modo errato. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli utente e attività comuni di GKE.

Informazioni su 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 criterio 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 container, è anche un indicatore diagnostico prezioso. 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 segue in genere questo schema:

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

La chiave di questo comportamento è il restartPolicy del pod. La policy predefinita, Always, è la causa più comune di questo ciclo perché riavvia un container se si chiude per qualsiasi motivo, anche dopo un'uscita riuscita. La policy OnFailure ha meno probabilità di causare un loop perché si riavvia solo in caso di 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 workload system (ad esempio un agente di logging o di metriche) ha lo stato CrashLoopBackOff, potresti notare anche i seguenti sintomi:

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

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

Conferma un evento CrashLoopBackOff

Per confermare ed esaminare 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 si sta arrestando in modo anomalo.
  • I log dell'app del container possono mostrare il motivo per cui il processo all'interno del container non va a buon fine.

Per visualizzare queste informazioni, seleziona una delle seguenti opzioni:

Console

Per visualizzare gli eventi Kubernetes e i log delle app:

  1. Nella console Google Cloud , vai alla pagina Workload.

    Vai a Carichi di lavoro

  2. Seleziona il workload che vuoi esaminare. La scheda Panoramica o Dettagli mostra ulteriori informazioni sullo stato del workload.

  3. Nella sezione Pod gestiti, fai clic sul nome del pod problematico.

  4. Nella pagina dei dettagli del pod, esamina quanto segue:

    • Per visualizzare i dettagli sugli eventi Kubernetes, vai alla scheda Eventi.
    • Per visualizzare i log delle app del container, vai alla scheda Log. In questa pagina trovi messaggi di errore o analisi dello stack specifici dell'app.

kubectl

Per visualizzare gli eventi Kubernetes e i log delle app:

  1. Visualizza lo stato di tutti i pod in esecuzione nel cluster:

    kubectl get pods

    L'output è simile al seguente:

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

    Nell'output, esamina le seguenti colonne:

    • Ready: controlla quanti container sono pronti. In questo esempio, 0/1 indica che zero dei container previsti sono in stato pronto. Questo valore è un chiaro segnale di un problema.
    • Status: cerca i pod con stato CrashLoopBackOff.
    • Restarts: un valore elevato indica che Kubernetes tenta ripetutamente di avviare il container senza riuscirci.

  2. Dopo aver identificato un pod in errore, descrivilo per visualizzare gli eventi a livello di cluster correlati allo stato del pod:

    kubectl describe pod POD_NAME -n NAMESPACE_NAME

    Sostituisci quanto segue:

    • POD_NAME: il nome del pod che hai identificato nell'output del comando kubectl get.
    • NAMESPACE_NAME: lo spazio dei nomi del pod.

    L'output è simile al seguente:

    Containers:
container-name:
...
  State:          Waiting
    Reason:       CrashLoopBackOff
  Last State:     Terminated
    Reason:       StartError
    Message:      failed to create containerd task: failed to create shim task: context deadline exceeded: unknown
    Exit Code:    128
    Started:      Thu, 01 Jan 1970 00:00:00 +0000
    Finished:     Fri, 27 Jun 2025 16:20:03 +0000
  Ready:          False
  Restart Count:  3459
...
Conditions:
Type                        Status
PodReadyToStartContainers   True
Initialized                 True
Ready                       False
ContainersReady             False
PodScheduled                True
...
Events:
Type     Reason   Age                     From     Message
----     ------   ----                    ----     -------
Warning  Failed   12m (x216 over 25h)     kubelet  Error: context deadline exceeded
Warning  Failed   8m34s (x216 over 25h)   kubelet  Error: context deadline exceeded
Warning  BackOff  4m24s (x3134 over 25h)  kubelet  Back-off restarting failed container container-name in pod failing-pod(11111111-2222-3333-4444-555555555555)

    Nell'output, esamina i seguenti campi per individuare eventuali segni di un evento CrashLoopBackOff:

    • State: lo stato del container mostra probabilmente Waiting con il motivo CrashLoopBackOff.
    • Last State: lo stato del container terminato in precedenza. Cerca uno stato Terminated ed esamina il codice di uscita per verificare se si è verificato un arresto anomalo (codice di uscita diverso da zero) o un'uscita riuscita imprevista (codice di uscita zero).
    • Events: azioni intraprese dal cluster stesso. Cerca i messaggi relativi all'avvio del container, seguiti da errori del probe di attività o avvisi di backoff come Back-off restarting failed container.

  3. Per scoprire di più sul motivo per cui il pod non è riuscito, visualizza i log dell'app:

    kubectl logs POD_NAME --previous

    Il flag --previous recupera i log dal container precedente terminato, in cui puoi trovare l'analisi dello stack o il messaggio di errore specifico che rivela la causa dell'arresto anomalo. Il container corrente potrebbe essere troppo recente per aver registrato dei log.

    Nell'output, cerca gli errori specifici dell'app che causerebbero l'uscita dal processo. Se utilizzi un'app personalizzata, gli sviluppatori che l'hanno scritta sono i più qualificati per interpretare questi messaggi di errore. Se utilizzi un'app predefinita, queste app spesso forniscono le proprie istruzioni di debug.

Utilizza 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 console Google Cloud , 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 di 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. Esamina i problemi di memoria: esiste una configurazione errata o un errore 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 CrashLoopBackOfffuturi, 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.

Risolvi un evento CrashLoopBackOff

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

Risolvi l'esaurimento delle risorse

Un evento CrashLoopBackOff è spesso causato da un problema di out of memory (OOM). Puoi verificare 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, consulta Risolvere i problemi relativi agli eventi OOM.

Risolvi gli errori dei probe di attività

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

Verifica 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 kubelet. Questi log spesso contengono messaggi espliciti che indicano errori della sonda e riavvii successivi.

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

    Vai a Esplora log

  2. Nel riquadro delle query, filtra i riavvii correlati ai 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 tuo 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 verificato 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à

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

  • Verifica il tipo di probe: la configurazione del probe deve corrispondere al modo in cui l'app segnala il proprio stato. Ad esempio, se la tua app ha un URL di controllo di integrità (come /healthz), utilizza il tipo di probe httpGet. Se la sua integrità è determinata 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 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 per indicare la riuscita 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 Configura i probe di attività, idoneità e avvio nella documentazione di Kubernetes.

Ispeziona l'utilizzo della CPU e dell'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 contenitore o sul nodo può impedire all'app di rispondere alla sonda in tempo.

    Se la carenza di CPU del container causa errori di probe durante l'inizializzazione, puoi utilizzare l'incremento dell'avvio della CPU per allocare temporaneamente più risorse della CPU. Per saperne di più, consulta Accelerare l'avvio delle applicazioni utilizzando il boost di avvio della CPU.

  • 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 dei 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 di 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 la possibilità di eseguire l'upgrade dei nodi con dischi più veloci o più grandi o con Persistent Volume Claim per gestire meglio l'aumento della domanda di I/O. Assicurati che lo scaling automatico del cluster sia configurato in modo appropriato.
  • Attendi e osserva: in alcuni casi, se il cluster non è gravemente sottoutilizzato, i carichi di lavoro potrebbero essere distribuiti dopo un ritardo significativo (a volte 30 minuti o più).

Errori temporanei dell'indirizzo

L'app potrebbe riscontrare errori o rallentamenti temporanei durante l'avvio o l'inizializzazione che causano l'errore iniziale del probe. 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 stessa del probe di attività potrebbe consumare risorse significative, il che potrebbe attivare vincoli delle risorse che potrebbero portare alla terminazione del container a causa di un arresto per memoria esaurita (OOM). Assicurati che i comandi di probing siano leggeri. È più probabile che una sonda leggera venga eseguita in modo rapido e affidabile, fornendo una fedeltà superiore nella segnalazione accurata dello stato effettivo della tua app.

Risolvi gli errori di configurazione delle app

Le configurazioni errate delle app causano molti eventi CrashLoopBackOff. Per capire perché l'app si arresta, il primo passaggio consiste nell'esaminare il codice di uscita. Questo codice determina il percorso di risoluzione dei problemi:

  • Il codice di uscita 0 indica un'uscita riuscita, che non è prevista per un servizio a lunga esecuzione e indica problemi con l'entry point del container o il design 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.

Trova 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 container 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 indica in genere che il processo del container è stato completato 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 Deployment, StatefulSet o ReplicaSet.

Questi controller funzionano per garantire che un pod sia sempre in esecuzione, quindi considerano qualsiasi uscita come un errore da correggere. kubelet applica questo comportamento rispettando restartPolicy del pod (il cui valore predefinito è 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 persistente: un container rimane in esecuzione solo finché è in esecuzione il processo iniziale (command o entrypoint). Se questo processo non è un servizio a lunga esecuzione, il container esce non appena il comando viene completato. Ad esempio, un comando come ["/bin/bash"] esce 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 si chiude quando una coda di lavoro è vuota: molte app worker sono progettate per controllare se una coda contiene un'attività e chiudersi correttamente se la coda è vuota. Per risolvere il problema, puoi utilizzare un controller di job (progettato per le attività che vengono eseguite fino al completamento) o modificare la logica dell'app per eseguirla come servizio persistente.

  • Uscite dell'app dovute a 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 dell'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 è collegato, è vuoto o contiene chiavi con nomi errati, un'app progettata per uscire quando manca la configurazione potrebbe arrestarsi con un codice di uscita 0. In questi casi, verifica le seguenti impostazioni: - Il nome 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.

Risolvi i problemi di arresto anomalo dell'app (codice di uscita diverso da zero)

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

Il codice di uscita diverso da zero è un chiaro segnale che si è verificato un errore all'interno dell'app stessa, il 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 verificare la presenza di 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 container 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 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 ogni volta vengano recuperati esattamente gli stessi contenuti delle immagini.

  • Problemi di dipendenza: la tua app potrebbe arrestarsi in modo anomalo se non riesce a connettersi agli altri servizi da cui dipende o se non riesce ad autenticarsi o 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 Running Pods 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 policy 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 esterne Google Cloud.

      Se utilizzi la federazione delle identità per i workload GKE, verifica che l'identificatore principale disponga delle autorizzazioni richieste per l'attività. Per saperne di più sulla concessione dei ruoli IAM alle entità utilizzando la federazione delle identità per i workload di 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 analisi dello stack 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 l'uno dell'altro per essere completati. 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, controlla i log del container per individuare un messaggio di errore o un'analisi dello stack specifici. Queste informazioni ti aiutano a decidere se correggere il codice dell'app, modificare i limiti delle risorse o correggere la configurazione dell'ambiente. Per saperne di più sui log, consulta Informazioni sui log di GKE.

Passaggi successivi