Introduzione alla risoluzione dei problemi di GKE

Questa pagina introduce le tecniche di risoluzione dei problemi fondamentali per Google Kubernetes Engine (GKE). Questa pagina è rivolta agli utenti che non hanno mai utilizzato Kubernetes e GKE e che vogliono imparare pratiche efficaci per la risoluzione dei problemi.

Questa pagina fornisce una panoramica dei seguenti strumenti e tecniche per monitorare, diagnosticare e risolvere i problemi relativi a GKE:

• Controlla l'integrità del cluster e del workload nella Google Cloud console: ottieni una panoramica di alto livello per identificare rapidamente i potenziali problemi con i cluster e le app.
• Esamina lo stato del cluster con lo kubectl strumento a riga di comando: utilizza questi comandi per visualizzare lo stato in tempo reale delle risorse come nodi e pod.
• Esegui analisi storiche con Cloud Logging: esegui query sui dati dei log storici ed esamina gli eventi per identificare la causa principale degli errori.
• Esegui il monitoraggio proattivo con Cloud Monitoring: monitora le metriche di rendimento nel tempo, visualizza le tendenze e crea avvisi per rilevare e rispondere ai problemi prima che influiscano sugli utenti.
• Accelera la diagnosi con Gemini Cloud Assist: analizza messaggi di errore complessi, ricevi indicazioni passo passo per la risoluzione dei problemi e analizza automaticamente i problemi.
• Metti tutto insieme: scenario di risoluzione dei problemi di esempio: scopri come utilizzare questi strumenti insieme in una procedura dettagliata passo passo per diagnosticare e risolvere un errore comune dell'app nel mondo reale.

Comprendere i concetti principali

Se non hai familiarità con Kubernetes e GKE, è essenziale comprendere i concetti di base, come l'architettura del cluster e la relazione tra pod e nodi, prima di iniziare a risolvere i problemi. Se vuoi saperne di più, consulta Inizia a scoprire GKE.

È anche utile capire quali parti di GKE sono di tua responsabilità e quali sono di responsabilità di Google Cloud . Per maggiori informazioni, consulta Responsabilità condivisa di GKE.

Esamina l'integrità del cluster e del workload nella console Google Cloud

La Google Cloud console è un buon punto di partenza per la risoluzione dei problemi perché fornisce una rapida panoramica dell'integrità dei cluster e dei carichi di lavoro. L'integrità del cluster si riferisce all'integrità dell'infrastruttura GKE sottostante, come nodi e rete, mentre l'integrità del workload si riferisce allo stato e alle prestazioni delle tue app in esecuzione sul cluster.

Le sezioni seguenti descrivono le pagine del cluster e del workload. Per fornire un quadro completo dello stato della tua app, la console ti dà accesso anche a potenti strumenti di logging e monitoraggio, che ti consentono di analizzare la causa principale dei problemi passati e prevenirne proattivamente quelli futuri. Google Cloud Per saperne di più su questi strumenti, consulta le sezioni Eseguire analisi storiche con Cloud Logging e Eseguire il monitoraggio proattivo con Cloud Monitoring.

Trovare i problemi del cluster

La pagina Cluster Kubernetes fornisce una panoramica dell'integrità dei tuoi cluster. Per identificare i problemi relativi a uno dei tuoi cluster, inizia da questa pagina.

• Per iniziare, nella console Google Cloud , vai alla pagina Cluster Kubernetes.

  Vai ai cluster Kubernetes

Ecco alcuni esempi di come puoi utilizzare questa pagina per la risoluzione dei problemi:

• Per suggerimenti su come migliorare l'integrità del cluster, la strategia di upgrade e l'ottimizzazione dei costi, fai clic su Visualizza consigli.
• Per identificare i cluster non integri, esamina la colonna Stato. Qualsiasi cluster senza segno di spunta verde richiede attenzione.
• Per visualizzare i potenziali problemi, controlla la colonna Notifiche. Fai clic su uno dei messaggi di notifica per ulteriori informazioni.

Eseguire accertamenti su un cluster specifico

Dopo aver rilevato un problema con un cluster, esplora la pagina Dettagli del cluster per informazioni approfondite che ti aiutano a risolvere i problemi del cluster e a comprenderne la configurazione.

Per andare alla pagina Dettagli di un cluster:

1. Vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Esamina la colonna Nome e fai clic sul nome del cluster che vuoi esaminare.

Ecco alcuni esempi di come utilizzare la pagina Dettagli del cluster per risolvere i problemi del cluster:

• Per i controlli di integrità generali, prova le seguenti opzioni:

  • Per visualizzare le dashboard a livello di cluster, vai alla scheda Osservabilità. Per impostazione predefinita, GKE abilita Cloud Monitoring quando crei un cluster. Quando Cloud Monitoring è abilitato, GKE configura automaticamente le dashboard in questa pagina. Ecco alcune delle visualizzazioni che potresti trovare più utili per la risoluzione dei problemi:

    • Panoramica: visualizza un riepilogo di alto livello dell'integrità, dell'utilizzo delle risorse e degli eventi chiave del cluster. Questa dashboard ti aiuta a valutare rapidamente lo stato generale del cluster e a identificare potenziali problemi.
    • Metriche sul traffico: visualizza le metriche di networking basate sui nodi per gli insight sul traffico tra i workload Kubernetes.
    • Stato del carico di lavoro: visualizza lo stato di deployment, pod e container. Identifica le istanze non integre o in errore e rileva i vincoli delle risorse.

    • Piano di controllo: visualizza l'integrità e le prestazioni del piano di controllo. Questa dashboard ti consente di monitorare le metriche chiave di componenti come kube-apiserver e etcd, identificare i colli di bottiglia delle prestazioni e rilevare i guasti dei componenti.

  • Per visualizzare gli errori recenti delle app, vai alla scheda Errori app. Le informazioni in questa scheda possono aiutarti a dare la priorità agli errori e a risolverli mostrando il numero di occorrenze, quando è apparso per la prima volta un errore e quando si è verificato l'ultima volta.

    Per esaminare ulteriormente un errore, fai clic sul messaggio di errore per visualizzare un report dettagliato, inclusi i link ai log pertinenti.

• Se stai risolvendo problemi dopo un recente upgrade o modifica, controlla la sezione Nozioni di base sui cluster nella scheda Dettagli del cluster. Verifica che la versione elencata nel campo Versione sia quella che ti aspetti. Per ulteriori approfondimenti, fai clic su Mostra cronologia degli upgrade nella sezione Upgrade.

• Se utilizzi un cluster Standard e i tuoi pod sono bloccati nello stato Pending o sospetti che i nodi siano sovraccarichi, controlla la scheda Nodi. La scheda Nodi non è disponibile per i cluster Autopilot perché GKE gestisce i nodi per te.

  • Nella sezione Pool di nodi, verifica che la scalabilità automatica sia configurata correttamente e che il tipo di macchina sia appropriato per i tuoi carichi di lavoro.
  • Nella sezione Nodi, cerca i nodi con uno stato diverso da Ready. Lo stato NotReady indica un problema con il nodo stesso, ad esempio la pressione delle risorse o un problema con kubelet (l'agente che viene eseguito su ogni nodo per gestire i container).

Trovare problemi relativi ai workload

Quando sospetti che ci sia un problema con un'app specifica, ad esempio un deployment non riuscito, vai alla pagina Workload nella console Google Cloud . Questa pagina fornisce una visualizzazione centralizzata di tutte le app eseguite nei cluster.

• Per iniziare, nella console Google Cloud , vai alla pagina Workload.

  Vai a Carichi di lavoro

Ecco alcuni esempi di come puoi utilizzare questa pagina per la risoluzione dei problemi:

• Per identificare i carichi di lavoro non integri, esamina la colonna Stato. Qualsiasi carico di lavoro senza segno di spunta verde richiede attenzione.
• Se un'app non risponde, controlla la colonna Pod. Ad esempio, uno stato come 1/3 indica che è in esecuzione solo una delle tre repliche dell'app, il che indica un problema.

Eseguire accertamenti su un workload specifico

Dopo aver identificato un workload problematico dalla panoramica, esplora la pagina Dettagli del workload per iniziare a isolare la causa principale.

Per andare alla pagina Dettagli di un workload:

1. Vai alla pagina Workload.

   Vai a Carichi di lavoro

2. Visualizza la colonna Nome e fai clic sul nome del workload che vuoi esaminare.

Ecco alcuni esempi di come utilizzare la pagina Dettagli del workload per risolvere i problemi relativi ai workload:

• Per controllare la configurazione del workload, utilizza le schede Panoramica e Dettagli del workload. Puoi utilizzare queste informazioni per verificare eventi come se è stato eseguito il deployment del tag immagine container corretto o controllare le richieste e i limiti delle risorse del workload.

• Per trovare il nome di un pod specifico che genera arresti anomali, vai alla sezione Pod gestiti. Queste informazioni potrebbero servirti per i comandi kubectl. Questa sezione elenca tutti i pod controllati dal workload, insieme ai relativi stati. Per visualizzare una cronologia delle modifiche recenti a un workload, vai alla scheda Cronologia delle revisioni. Se noti problemi di rendimento dopo un nuovo deployment, utilizza questa sezione per identificare la revisione attiva. A questo punto, puoi confrontare le configurazioni della revisione attuale con quelle precedenti per individuare l'origine del problema. Se questa scheda non è visibile, il carico di lavoro è di un tipo che non utilizza le revisioni o non ha ancora ricevuto aggiornamenti.

• Se un deployment sembra non essere riuscito, vai alla scheda Eventi. Questa pagina è spesso la fonte di informazioni più preziosa perché mostra gli eventi a livello di Kubernetes.

• Per esaminare i log dell'app, fai clic sulla scheda Log. Questa pagina ti aiuta a capire cosa succede all'interno del tuo cluster. Qui puoi trovare messaggi di errore e analisi dello stack che possono aiutarti a diagnosticare i problemi.

• Per verificare esattamente cosa è stato eseguito il deployment, visualizza la scheda YAML. Questa pagina mostra il manifest YAML live per il workload così come esiste nel cluster. Queste informazioni sono utili per trovare eventuali discrepanze rispetto ai manifest controllati dall'origine. Se visualizzi il manifest YAML di un singolo pod, questa scheda mostra anche lo stato del pod, che fornisce informazioni sugli errori a livello di pod.

Esamina lo stato del cluster con lo strumento a riga di comando kubectl

Sebbene la console Google Cloud ti aiuti a capire se c'è un problema, lo strumento a riga di comando kubectl è essenziale per scoprire perché. Comunicando direttamente con il control plane Kubernetes, lo strumento a riga di comando kubectl ti consente di raccogliere le informazioni dettagliate necessarie per risolvere i problemi del tuo ambiente GKE.

Le sezioni seguenti ti presentano alcuni comandi essenziali che rappresentano un ottimo punto di partenza per la risoluzione dei problemi di GKE.

Prima di iniziare

Prima di iniziare, esegui le seguenti operazioni:

• Installa kubectl.

• Configura lo strumento a riga di comando kubectl per comunicare con il cluster:

  gcloud container clusters get-credentials CLUSTER_NAME \
      --location=LOCATION
  

  Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del tuo cluster.
  • LOCATION: la posizione di Compute Engine del control plane del cluster. Fornisci una regione per i cluster regionali o una zona per i cluster zonali.

• Rivedi le tue autorizzazioni. Per verificare se disponi delle autorizzazioni necessarie per eseguire i comandi kubectl, utilizza il comando kubectl auth can-i. Ad esempio, per verificare se hai l'autorizzazione per eseguire kubectl get nodes, esegui il comando kubectl auth can-i get nodes.

  Se disponi delle autorizzazioni richieste, il comando restituisce yes; in caso contrario, il comando restituisce no.

  Se non disponi dell'autorizzazione per eseguire un comando kubectl, potresti visualizzare un messaggio di errore simile al seguente:

  Error from server (Forbidden): pods "POD_NAME" is forbidden: User
  "USERNAME@DOMAIN.com" cannot list resource "pods" in API group "" in the
  namespace "default"
  

  Se non disponi delle autorizzazioni richieste, chiedi all'amministratore del cluster di assegnarti i ruoli necessari.

Visualizzare una panoramica di ciò che è in esecuzione

Il comando kubectl get ti aiuta a visualizzare una panoramica di ciò che sta accadendo nel tuo cluster. Utilizza i seguenti comandi per visualizzare lo stato di due dei componenti del cluster più importanti, ovvero nodi e pod:

1. Per verificare l'integrità dei nodi, visualizza i dettagli di tutti i nodi e i relativi stati:

   kubectl get nodes
   

   L'output è simile al seguente:

   NAME                                        STATUS   ROLES    AGE     VERSION
   
   gke-cs-cluster-default-pool-8b8a777f-224a   Ready    <none>   4d23h   v1.32.3-gke.1785003
   gke-cs-cluster-default-pool-8b8a777f-egb2   Ready    <none>   4d22h   v1.32.3-gke.1785003
   gke-cs-cluster-default-pool-8b8a777f-p5bn   Ready    <none>   4d22h   v1.32.3-gke.1785003
   

   Qualsiasi stato diverso da Ready richiede ulteriori accertamenti.

2. Per verificare se i pod sono integri, visualizza i dettagli di tutti i pod e i relativi stati:

   kubectl get pods --all-namespaces
   

   L'output è simile al seguente:

   NAMESPACE   NAME       READY   STATUS      RESTARTS   AGE
   kube-system netd-6nbsq 3/3     Running     0          4d23h
   kube-system netd-g7tpl 3/3     Running     0          4d23h
   

   Qualsiasi stato diverso da Running richiede ulteriori accertamenti. Di seguito sono riportati alcuni stati comuni che potresti visualizzare:

   • Running: uno stato di esecuzione integro.
   • Pending: il pod è in attesa di essere pianificato su un nodo.
   • CrashLoopBackOff: i container nel pod vanno in arresto anomalo ripetutamente in un ciclo perché l'app si avvia, esce con un errore e viene riavviata da Kubernetes.
   • ImagePullBackOff: il pod non può estrarre l'immagine del container.

I comandi precedenti sono solo due esempi di come puoi utilizzare il comando kubectl get. Puoi anche utilizzare il comando per saperne di più su molti tipi di risorse Kubernetes. Per un elenco completo delle risorse che puoi esplorare, consulta kubectl get nella documentazione di Kubernetes.

Scopri di più su risorse specifiche

Dopo aver identificato un problema, devi ottenere maggiori dettagli. Un esempio di problema potrebbe essere un pod con stato diverso da Running. Per ulteriori dettagli, utilizza il comando kubectl describe.

Ad esempio, per descrivere un pod specifico, esegui questo comando:

kubectl describe pod POD_NAME -n NAMESPACE_NAME

Sostituisci quanto segue:

• POD_NAME: il nome del pod che presenta problemi.
• NAMESPACE_NAME: lo spazio dei nomi in cui si trova il pod. Se non sai qual è lo spazio dei nomi, esamina la colonna Namespace dell'output del comando kubectl get pods.

L'output del comando kubectl describe include informazioni dettagliate sulla risorsa. Di seguito sono riportate alcune delle sezioni più utili da esaminare quando risolvi i problemi di un Pod:

• Status: lo stato attuale del pod.
• Conditions: lo stato generale e la preparazione del pod.
• Restart Count: il numero di riavvii dei container nel pod. Numeri elevati possono essere motivo di preoccupazione.
• Events: un log degli eventi importanti che si sono verificati per questo pod, come la pianificazione su un nodo, il pull dell'immagine del container e l'eventuale presenza di errori. La sezione Events è spesso il luogo in cui puoi trovare gli indizi diretti sul motivo per cui un pod non funziona.

Come il comando kubectl get, puoi utilizzare il comando kubectl describe per scoprire di più su più tipi di risorse. Per un elenco completo delle risorse che puoi esplorare, consulta kubectl describe nella documentazione di Kubernetes.

Eseguire analisi storiche con Cloud Logging

Sebbene lo strumento a riga di comando kubectl sia prezioso per esaminare lo stato live degli oggetti Kubernetes, la sua visualizzazione è spesso limitata al momento attuale. Per comprendere la causa principale di un problema, spesso devi esaminare cosa è successo nel tempo. Quando hai bisogno di questo contesto storico, utilizza Cloud Logging.

Cloud Logging aggrega i log dei cluster GKE, delle app containerizzate e di altri servizi. Google Cloud

Comprendere i tipi di log chiave per la risoluzione dei problemi

Cloud Logging raccoglie automaticamente diversi tipi di log GKE che possono aiutarti a risolvere i problemi:

• Log di nodi e runtime (kubelet, containerd): i log dei servizi dei nodi sottostanti. Poiché kubelet gestisce il ciclo di vita di tutti i pod sul nodo, i suoi log sono essenziali per la risoluzione dei problemi come avvii dei container, eventi di esaurimento della memoria, errori dei probe e errori di montaggio dei volumi. Questi log sono fondamentali anche per diagnosticare problemi a livello di nodo, ad esempio un nodo con stato NotReady.

  Poiché containerd gestisce il ciclo di vita dei container, incluso il pull delle immagini, i suoi log sono fondamentali per la risoluzione dei problemi che si verificano prima che kubelet possa avviare il container. I log di containerd ti aiutano a diagnosticare i problemi a livello di nodo in GKE, in quanto documentano le attività specifiche e i potenziali errori del runtime del container.

• Log dell'app (stdout, stderr): i flussi di output ed errori standard dai processi containerizzati. Questi log sono essenziali per il debug di problemi specifici dell'app, come arresti anomali, errori o comportamenti imprevisti.

• Audit log: questi log rispondono alla domanda "chi ha fatto cosa, dove e quando?" per il tuo cluster. Monitorano le azioni amministrative e le chiamate API effettuate al server API Kubernetes, il che è utile per diagnosticare i problemi causati da modifiche alla configurazione o accessi non autorizzati.

Scenari comuni di risoluzione dei problemi

Dopo aver identificato un problema, puoi eseguire query su questi log per scoprire cosa è successo. Per aiutarti a iniziare, la revisione dei log può aiutarti a risolvere questi problemi:

• Se un nodo ha lo stato NotReady, esamina i relativi log. I log kubelet e containerd spesso rivelano la causa sottostante, ad esempio problemi di rete o vincoli di risorse.
• Se un nuovo nodo non viene sottoposto al provisioning e non entra a far parte del cluster, esamina i log della porta seriale del nodo. Questi log acquisiscono l'attività di avvio fase iniziale di avvio e di avvio di kubelet prima che gli agenti di logging del nodo siano completamente attivi.
• Se un pod non è stato avviato in passato, esamina i log dell'app per verificare la presenza di arresti anomali. Se i log sono vuoti o il pod non può essere pianificato, controlla i log di controllo per gli eventi pertinenti o i log dei nodi sul nodo di destinazione per indizi sulla pressione delle risorse o sugli errori di pull delle immagini.
• Se un deployment critico è stato eliminato e nessuno sa perché, esegui una query negli audit log Attività di amministrazione. Questi log possono aiutarti a identificare l'utente o il service account che ha emesso la chiamata API di eliminazione, fornendo un punto di partenza chiaro per la tua indagine.

Come accedere ai log

Utilizza Esplora log per eseguire query, visualizzare e analizzare i log GKE nella console Google Cloud . Esplora log offre potenti opzioni di filtro che ti aiutano a isolare il problema.

Per accedere a Esplora log e utilizzarlo, segui questi passaggi:

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

   Vai a Esplora log

2. Nel riquadro della query, inserisci una query. Utilizza il linguaggio di query di Logging per scrivere query mirate. Ecco alcuni filtri comuni per iniziare:

   Tipo di filtro	Descrizione	Valore di esempio
   resource.type	Il tipo di risorsa Kubernetes.	k8s_cluster, k8s_node, k8s_pod, k8s_container
   log_id	Il flusso di log della risorsa.	stdout, stderr
   resource.labels.RESOURCE_TYPE.name	Filtra le risorse con un nome specifico. Sostituisci RESOURCE_TYPE con il nome della risorsa per cui vuoi eseguire una query. Ad esempio, namespace o pod.	example-namespace-name, example-pod-name
   severity	Il livello di gravità del log.	DEFAULT, INFO, WARNING, ERROR, CRITICAL
   jsonPayload.message=~	Una ricerca con espressione regolare per il testo all'interno del messaggio di log.	scale.down.error.failed.to.delete.node.min.size.reached

   Ad esempio, per risolvere i problemi relativi a un pod specifico, potresti voler isolare i relativi log degli errori. Per visualizzare solo i log con gravità ERROR per quel pod, utilizza la seguente query:

   resource.type="k8s_container"
   resource.labels.pod_name="POD_NAME"
   resource.labels.namespace_name="NAMESPACE_NAME"
   severity=ERROR
   

   Sostituisci quanto segue:

   • POD_NAME: il nome del pod che presenta problemi.
   • NAMESPACE_NAME: lo spazio dei nomi in cui si trova il pod. Se non sai qual è lo spazio dei nomi, esamina la colonna Namespace dell'output del comando kubectl get pods.

   Per altri esempi, consulta Query correlate a Kubernetes nella documentazione di Google Cloud Observability.

3. Fai clic su Esegui query.

4. Per visualizzare il messaggio di log completo, inclusi il payload JSON, i metadati e il timestamp, fai clic sulla voce di log.

Per maggiori informazioni sui log di GKE, consulta Informazioni sui log di GKE.

Eseguire il monitoraggio proattivo con Cloud Monitoring

Dopo che si è verificato un problema, la revisione dei log è un passaggio fondamentale per la risoluzione dei problemi. Tuttavia, un sistema veramente resiliente richiede anche un approccio proattivo per identificare i problemi prima che causino un'interruzione.

Per identificare in modo proattivo i problemi futuri e monitorare gli indicatori chiave di prestazione nel tempo, utilizza Cloud Monitoring. Cloud Monitoring fornisce dashboard, metriche e funzionalità di avviso. Questi strumenti ti aiutano a trovare tassi di errore in aumento, latenza crescente o vincoli di risorse, il che ti aiuta ad agire prima che gli utenti vengano interessati.

Esaminare le metriche utili

GKE invia automaticamente un insieme di metriche a Cloud Monitoring. Le sezioni seguenti elencano alcune delle metriche più importanti per la risoluzione dei problemi:

• Metriche di rendimento e integrità del contenitore
• Metriche di rendimento e integrità dei nodi
• Metriche di rendimento e salute del pod

Per un elenco completo delle metriche GKE, consulta Metriche di sistema di GKE.

Metriche di integrità e rendimento dei container

Inizia con queste metriche quando sospetti un problema con un'app specifica. Queste metriche ti aiutano a monitorare l'integrità della tua app, ad esempio a scoprire se un container si riavvia frequentemente, esaurisce la memoria o viene limitato dai limiti della CPU.

Metriche di integrità e prestazioni dei nodi

Esamina queste metriche quando devi diagnosticare problemi relativi all'infrastruttura GKE sottostante. Queste metriche sono fondamentali per comprendere lo stato e la capacità complessivi dei nodi, aiutandoti a verificare se il nodo non è integro o è sotto pressione o se ha memoria sufficiente per pianificare nuovi pod.

Metriche di salute e rendimento del pod

Queste metriche ti aiutano a risolvere i problemi relativi all'interazione di un pod con il suo ambiente, ad esempio la rete e l'archiviazione. Utilizza queste metriche quando devi diagnosticare pod con avvio lento, esaminare potenziali problemi di connettività di rete o gestire in modo proattivo lo spazio di archiviazione per evitare errori di scrittura dovuti a volumi pieni.

Visualizzare le metriche con Metrics Explorer

Per visualizzare lo stato del tuo ambiente GKE, crea grafici basati sulle metriche con Metrics Explorer.

Per utilizzare Metrics Explorer, completa i seguenti passaggi:

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

   Vai a Esplora metriche

2. Nel campo Metriche, seleziona o inserisci la metrica che vuoi esaminare.

3. Visualizza i risultati e osserva le tendenze nel tempo.

Ad esempio, per esaminare il consumo di memoria dei pod in uno spazio dei nomi specifico, puoi procedere nel seguente modo:

1. Nell'elenco Seleziona una metrica, scegli la metrica kubernetes.io/container/memory/used_bytes e fai clic su Applica.
2. Fai clic su Aggiungi filtro e seleziona namespace_name.
3. Nell'elenco Valore, seleziona lo spazio dei nomi che vuoi esaminare.
4. Nel campo Aggregazione, seleziona Somma > pod_name e fai clic su Ok. Questa impostazione mostra una linea di serie temporale separata per ogni pod.
5. Fai clic su Salva grafico.

Il grafico risultante mostra l'utilizzo della memoria per ogni pod nel tempo, il che può aiutarti a identificare visivamente i pod con un consumo di memoria insolitamente elevato o con picchi.

Metrics Explorer offre una grande flessibilità nella creazione delle metriche che vuoi visualizzare. Per ulteriori informazioni sulle opzioni avanzate di Metrics Explorer, consulta Creare grafici con Esplora metriche nella documentazione di Cloud Monitoring.

Crea avvisi per il rilevamento proattivo dei problemi

Per ricevere notifiche quando si verificano problemi o quando le metriche superano determinate soglie, configura criteri di avviso in Cloud Monitoring.

Ad esempio, per configurare un criterio di avviso che ti avvisi quando il limite di CPU del container supera l'80% per cinque minuti, segui questi passaggi:

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

   Vai ad Avvisi

2. Fai clic su Crea criterio.

3. Nella casella Seleziona una metrica, filtra per CPU limit utilization e poi seleziona la seguente metrica: kubernetes.io/container/cpu/limit_utilization.

4. Fai clic su Applica.

5. Lascia vuoto il campo Aggiungi un filtro. Questa impostazione attiva un avviso quando un cluster viola la soglia.

6. Nella sezione Trasforma i dati, segui questi passaggi:

   1. Nell'elenco Finestra temporale continua, seleziona 1 minuto. Questa impostazione indica che Google Cloud calcola un valore medio ogni minuto.

   2. Nell'elenco Funzione finestra temporale continua, seleziona Media.

      Entrambe queste impostazioni calcolano la media dell'utilizzo del limite di CPU per ogni container ogni minuto.

7. Fai clic su Avanti.

8. Nella sezione Configura avviso, segui questi passaggi:

   1. In Tipo di condizione, seleziona Soglia.
   2. Per Attivatore di avvisi, seleziona Qualsiasi violazione della serie temporale.
   3. In Posizione soglia, seleziona Sopra la soglia.
   4. In Valore soglia, inserisci 0.8. Questo valore rappresenta la soglia dell'80% che vuoi monitorare.
   5. Fai clic su Opzioni avanzate.
   6. Nell'elenco Finestra di ripetizione del test, seleziona 5 min. Questa impostazione significa che l'avviso viene attivato solo se l'utilizzo della CPU rimane superiore all'80% per un periodo continuo di cinque minuti, il che riduce i falsi allarmi dovuti a picchi brevi.
   7. Nel campo Nome condizione, assegna alla condizione un nome descrittivo.
   8. Fai clic su Avanti.

9. Nella sezione Configura le notifiche e finalizza l'avviso, segui questi passaggi:

   1. Nell'elenco Canali di notifica, seleziona il canale in cui vuoi ricevere l'avviso. Se non hai un canale, fai clic su Gestisci canali di notifica per crearne uno.
   2. Nel campo Assegna un nome alla policy di avviso, assegna alla policy un nome chiaro e descrittivo.
   3. Lascia invariati i valori predefiniti degli altri campi.
   4. Fai clic su Avanti.

10. Esamina le norme e, se tutto sembra corretto, fai clic su Crea norma.

Per scoprire altri modi per creare avvisi, consulta la panoramica degli avvisi nella documentazione di Cloud Monitoring.

Accelerare la diagnosi con Gemini Cloud Assist

A volte, la causa del problema non è immediatamente ovvia, anche quando hai utilizzato gli strumenti descritti nelle sezioni precedenti. L'analisi di casi complessi può richiedere molto tempo e competenze approfondite. Per scenari come questo, Gemini Cloud Assist può aiutarti. Può rilevare automaticamente pattern nascosti, anomalie di superficie e fornire riepiloghi per aiutarti a individuare rapidamente una causa probabile.

Accedere a Gemini Cloud Assist

Per accedere a Gemini Cloud Assist, completa i seguenti passaggi:

1. Nella console Google Cloud , vai a una pagina qualsiasi.

2. Nella barra degli strumenti della console Google Cloud , fai clic su spark Apri o chiudi la chat di Gemini Cloud Assist.

   Si apre il riquadro Cloud Assist. Puoi fare clic sui prompt di esempio se vengono visualizzati oppure puoi inserire un prompt nel campo Inserisci un prompt.

Esplora i prompt di esempio

Per aiutarti a capire come Gemini Cloud Assist può esserti d'aiuto, ecco alcuni prompt di esempio:

Per maggiori informazioni, consulta le seguenti risorse:

• Scopri come scrivere prompt migliori.
• Scopri come utilizzare il riquadro Gemini Cloud Assist.
• Leggi la panoramica di Gemini per Google Cloud .
• Scopri in che modo Gemini per Google Cloud utilizza i tuoi dati.

Utilizzare le indagini di Gemini Cloud Assist

Oltre alla chat interattiva, Gemini Cloud Assist può eseguire analisi più approfondite e automatizzate tramite le indagini di Gemini Cloud Assist. Questa funzionalità è integrata direttamente in flussi di lavoro come Esplora log ed è un potente strumento di analisi delle cause principali.

Quando avvii un'indagine da un errore o da una risorsa specifica, Gemini Cloud Assist analizza log, configurazioni e metriche. Utilizza questi dati per produrre osservazioni e ipotesi classificate sulle probabili cause principali, quindi ti fornisce i passaggi successivi consigliati. Puoi anche trasferire questi risultati a una richiesta di assistenza Google Cloud per fornire un contesto prezioso che può aiutarti a risolvere il problema più rapidamente.

Per saperne di più, consulta la sezione Indagini di Gemini Cloud Assist nella documentazione di Gemini.

Riepilogo: scenario di esempio per la risoluzione dei problemi

Questo esempio mostra come utilizzare una combinazione di strumenti GKE per diagnosticare e comprendere un problema comune del mondo reale: un container che si arresta in modo anomalo ripetutamente a causa di memoria insufficiente.

Lo scenario

Sei l'ingegnere di reperibilità 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 relativa 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 contenitore 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

• Per consigli sulla risoluzione di problemi specifici, consulta le guide alla risoluzione dei problemi di GKE.

• 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.