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 Cloud de Confiance console, dello kubectl strumento a riga di comando, Cloud Logging e Cloud Monitoring insieme per identificare la causa principale di un OutOfMemory (OOMKilled) errore.

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 Cloud de Confiance by S3NS contenuti, consulta Ruoli e attività comuni degli utenti di GKE.

Lo scenario

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

La tua 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 che esiste un problema e indica che il problema riguarda il carico di lavoro product-catalog.

Conferma il problema nella Cloud de Confiance console

Inizia con una visualizzazione di alto livello dei carichi di lavoro per confermare il problema.

  1. Nella Cloud de Confiance console, vai alla pagina Carichi di lavoro e filtra in base al carico di lavoro product-catalog.
  2. Esamina la colonna dello stato dei pod. Invece del valore integro 3/3, vedi che il valore mostra costantemente uno stato non integro: 2/3. Questo valore indica che uno dei pod dell'app non ha lo stato Ready.
  3. Per approfondire, fai clic sul nome del carico di lavoro product-catalog per accedere alla relativa pagina dei dettagli.
  4. Nella pagina dei dettagli, visualizza la sezione Pod gestiti. Identifichi immediatamente un problema: la colonna Restarts del pod mostra 14, un numero insolitamente elevato.

Questo numero elevato 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.

Trova il motivo con i comandi kubectl

Ora che sai che l'app viene riavviata ripetutamente, devi scoprire perché. Il comando kubectl describe è uno strumento utile per 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. Esamina l'output e trova indizi nelle sezioni Last State ed 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 ha esaurito la memoria. Questo motivo è confermato da Exit Code: 137, che è il codice di uscita Linux standard per un processo che è stato terminato a causa di un consumo eccessivo 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 loop di errori, che è la causa diretta dello stato CrashLoopBackOff che hai visto in precedenza.

Visualizza 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 Cloud de Confiance console, 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: la memoria utilizzata aumenta costantemente, poi scende bruscamente a zero quando il container viene terminato per esaurimento della memoria e riavviato. Questa prova visiva conferma una perdita di memoria o un limite di memoria insufficiente.

Trova la causa principale nei log

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

  1. Nella Cloud de Confiance console, vai a Esplora log.

  2. Scrivi una query per filtrare i log del container specifico da poco prima 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 di messaggi ripetuto subito 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 completamente in memoria, il che alla fine esaurisce il limite di memoria del container.

I risultati

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

  • L'avviso di monitoraggio ti ha informato che si è verificato un problema.
  • La Cloud de Confiance console ti ha mostrato che il problema riguardava 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 o, 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 carico di lavoro.

Passaggi successivi