Riepilogo: scenario di esempio per la risoluzione dei problemi

Comprendere i singoli strumenti di risoluzione dei problemi per Google Kubernetes Engine (GKE) è utile, ma vederli utilizzati insieme per risolvere un problema reale può aiutarti a consolidare le tue conoscenze.

Segui un esempio guidato che combina l'utilizzo della console Google Cloud , dello strumento a riga di comandokubectl, di Cloud Logging e di Cloud Monitoring per identificare la causa principale di un errore OutOfMemory (OOMKilled).

Questo esempio è utile per chiunque voglia vedere un'applicazione pratica delle tecniche di risoluzione dei problemi descritte in questa serie, in particolare per gli amministratori e gli operatori della piattaforma e per gli sviluppatori di applicazioni. Per ulteriori informazioni sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti diGoogle Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Lo scenario

Sei l'ingegnere di turno per un'app web denominata product-catalog che viene eseguita in GKE.

L'indagine inizia quando ricevi un avviso automatico da Cloud Monitoring:

Alert: High memory utilization for container 'product-catalog' in 'prod' cluster.

Questo avviso ti informa dell'esistenza di un problema e indica che il problema riguarda il carico di lavoro product-catalog.

Conferma il problema nella console Google Cloud

Inizia con una visualizzazione di alto livello dei tuoi workload per confermare il problema.

  1. Nella console Google Cloud , vai alla pagina Workload e filtra in base al tuo workload product-catalog.
  2. Esamina la colonna dello stato Pod. Anziché il valore integro 3/3, vedrai il valore che mostra costantemente uno stato non integro: 2/3. Questo valore indica che uno dei Pod della tua app non ha lo stato Ready.
  3. Vuoi approfondire, quindi fai clic sul nome del workload product-catalog per andare alla pagina dei dettagli.
  4. Nella pagina dei dettagli, visualizza la sezione Pod gestiti. Identifichi immediatamente un problema: la colonna Restarts per il tuo pod mostra 14, un numero insolitamente elevato.

Questo elevato numero di riavvii conferma che il problema sta causando instabilità dell'app e suggerisce che un container non supera i controlli di integrità o si arresta in modo anomalo.

Trovare il motivo con i comandi kubectl

Ora che sai che l'app viene riavviata ripetutamente, devi scoprire il motivo. Il comando kubectl describe è uno strumento utile a questo scopo.

  1. Ottieni il nome esatto del pod instabile:

    kubectl get pods -n prod

    L'output è il seguente:

    NAME                             READY  STATUS            RESTARTS  AGE
product-catalog-d84857dcf-g7v2x  0/1    CrashLoopBackOff  14        25m
product-catalog-d84857dcf-lq8m4  1/1    Running           0         2h30m
product-catalog-d84857dcf-wz9p1  1/1    Running           0         2h30m

  2. Descrivi il pod instabile per ottenere la cronologia dettagliata degli eventi:

    kubectl describe pod product-catalog-d84857dcf-g7v2x -n prod

  3. Esamini l'output e trovi indizi nelle sezioni Last State e Events:

    Containers:
  product-catalog-api:
    ...
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Mon, 23 Jun 2025 10:50:15 -0700
      Finished:     Mon, 23 Jun 2025 10:54:58 -0700
    Ready:          False
    Restart Count:  14
...
Events:
  Type     Reason     Age                           From                Message
  ----     ------     ----                          ----                -------
  Normal   Scheduled  25m                           default-scheduler   Successfully assigned prod/product-catalog-d84857dcf-g7v2x to gke-cs-cluster-default-pool-8b8a777f-224a
  Normal   Pulled     8m (x14 over 25m)             kubelet             Container image "us-central1-docker.pkg.dev/my-project/product-catalog/api:v1.2" already present on machine
  Normal   Created    8m (x14 over 25m)             kubelet             Created container product-catalog-api
  Normal   Started    8m (x14 over 25m)             kubelet             Started container product-catalog-api
  Warning  BackOff    3m (x68 over 22m)             kubelet             Back-off restarting failed container

    L'output fornisce due indizi fondamentali:

    • Innanzitutto, la sezione Last State mostra che il container è stato terminato con Reason: OOMKilled, il che indica che la memoria è esaurita. Questo motivo è confermato da Exit Code: 137, che è il codice di uscita Linux standard per un processo che è stato interrotto a causa dell'eccessivo consumo di memoria.
    • In secondo luogo, la sezione Events mostra un evento Warning: BackOff con il messaggio Back-off restarting failed container. Questo messaggio conferma che il container si trova in un ciclo di errori, che è la causa diretta dello stato CrashLoopBackOff visualizzato in precedenza.

Visualizzare il comportamento con le metriche

Il comando kubectl describe ti ha detto cosa è successo, ma Cloud Monitoring può mostrarti il comportamento del tuo ambiente nel tempo.

  1. Nella console Google Cloud , vai a Esplora metriche.
  2. Seleziona la metrica container/memory/used_bytes.
  3. Filtra l'output in base al cluster, allo spazio dei nomi e al nome del pod specifici.

Il grafico mostra un pattern distinto: l'utilizzo della memoria aumenta costantemente, poi scende bruscamente a zero quando il container viene interrotto per errore OOM e riavviato. Questa prova visiva conferma una perdita di memoria o un limite di memoria insufficiente.

Trovare la causa principale nei log

Ora sai che il container sta esaurendo la memoria, ma non sai ancora esattamente il motivo. Per scoprire la causa principale, utilizza Esplora log.

  1. Nella console Google Cloud , vai a Esplora log.

  2. Scrivi una query per filtrare i log del tuo container specifico da poco prima dell'ora dell'ultimo arresto anomalo (che hai visto nell'output del comando kubectl describe):

    resource.type="k8s_container"
resource.labels.cluster_name="example-cluster"
resource.labels.namespace_name="prod"
resource.labels.pod_name="product-catalog-d84857dcf-g7v2x"
timestamp >= "2025-06-23T17:50:00Z"
timestamp < "2025-06-23T17:55:00Z"

  3. Nei log, trovi un pattern ripetuto di messaggi appena prima di ogni arresto anomalo:

    {
  "message": "Processing large image file product-image-large.jpg",
  "severity": "INFO"
},
{
  "message": "WARN: Memory cache size now at 248MB, nearing limit.",
  "severity": "WARNING"
}

Queste voci di log indicano che l'app sta tentando di elaborare file di immagini di grandi dimensioni caricandoli interamente in memoria, il che alla fine esaurisce il limite di memoria del container.

I risultati

Utilizzando gli strumenti insieme, avrai un quadro completo del problema:

  • L'avviso di monitoraggio ti ha comunicato che si è verificato un problema.
  • La console Google Cloud ti ha mostrato che il problema interessava gli utenti (riavvii).
  • I comandi kubectl hanno individuato il motivo esatto dei riavvii (OOMKilled).
  • Metrics Explorer ha visualizzato il pattern di perdita di memoria nel tempo.
  • Esplora log ha rivelato il comportamento specifico che causa il problema di memoria.

Ora puoi implementare una soluzione. Puoi ottimizzare il codice dell'app per gestire i file di grandi dimensioni in modo più efficiente oppure, come soluzione a breve termine, aumentare il limite di memoria del container (in particolare, il valore spec.containers.resources.limits.memory) nel manifest YAML del workload.

Passaggi successivi