Raccogliere e visualizzare le metriche del piano di controllo

Questa pagina descrive come configurare un cluster Google Kubernetes Engine (GKE) per inviare le metriche emesse dall'API Kubernetes Server, dallo scheduler e dal controller Manager a Cloud Monitoring utilizzando Google Cloud Managed Service per Prometheus. Questa pagina descrive anche come vengono formattate queste metriche quando vengono scritte in Monitoring e come eseguire query sulle metriche.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

• Attiva l'API Google Kubernetes Engine.
Attiva l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.

Requisiti

L'invio delle metriche emesse dai componenti del control plane Kubernetes a Cloud Monitoring presenta i seguenti requisiti:

• Nel cluster devono essere abilitate le metriche di sistema.

Configura la raccolta delle metriche del control plane

Puoi abilitare le metriche del control plane in un cluster GKE esistente utilizzando la console Google Cloud , gcloud CLI o Terraform.

gcloud container clusters update CLUSTER_NAME \     --location=COMPUTE_LOCATION \     --monitoring=SYSTEM,API_SERVER,SCHEDULER,CONTROLLER_MANAGER 

Quota

Le metriche del control plane consumano la quota "Richieste di importazione di serie temporali al minuto" dell'API Cloud Monitoring. Prima di attivare i pacchetti di metriche, controlla il picco di utilizzo recente di questa quota. Se hai molti cluster nello stesso progetto o ti stai già avvicinando al limite di quota, puoi richiedere un aumento del limite di quota prima di attivare uno dei due pacchetti di osservabilità.

Prezzi

Le metriche del piano di controllo GKE utilizzano Google Cloud Managed Service per Prometheus per caricare le metriche in Cloud Monitoring. I costi di Cloud Monitoring per l'importazione di queste metriche si basano sul numero di campioni importati. Tuttavia, queste metriche sono gratuite per i cluster registrati che appartengono a un progetto in cui è abilitata l'edizione GKE Enterprise.

Per maggiori informazioni, consulta la pagina Prezzi di Cloud Monitoring.

Formato metrica

Tutte le metriche del control plane Kubernetes scritte in Cloud Monitoring utilizzano il tipo di risorsa prometheus_target. Ogni nome della metrica ha il prefisso prometheus.googleapis.com/ e un suffisso che indica il tipo di metrica Prometheus, ad esempio /gauge, /histogram o /counter. In caso contrario, ogni nome della metrica è identico al nome della metrica esposto da Kubernetes open source.

Esportazione da Cloud Monitoring

Le metriche del piano di controllo Kubernetes possono essere esportate da Cloud Monitoring utilizzando l'API Cloud Monitoring. Poiché tutte le metriche del piano di controllo Kubernetes vengono importate utilizzando Google Cloud Managed Service per Prometheus, è possibile eseguire query sulle metriche del piano di controllo Kubernetes utilizzando Prometheus Query Language (PromQL). Possono anche essere sottoposti a query utilizzando Monitoring Query Language (MQL).

Esecuzione di query sulle metriche

Quando esegui query sulle metriche del piano di controllo Kubernetes, il nome che utilizzi dipende dal fatto che tu stia utilizzando PromQL o funzionalità basate su Cloud Monitoring come MQL o l'interfaccia basata su menu di Metrics Explorer.

Le seguenti tabelle delle metriche del piano di controllo Kubernetes mostrano due versioni di ogni nome di metrica:

• Nome della metrica PromQL: quando utilizzi PromQL nelle pagine di Cloud Monitoring della console Google Cloud o nei campi PromQL dell'API Cloud Monitoring, utilizza il nome della metrica PromQL.
• Nome della metrica Cloud Monitoring. Quando utilizzi altre funzionalità di Cloud Monitoring, utilizza il nome della metrica Cloud Monitoring nelle tabelle seguenti. Questo nome deve avere come prefisso prometheus.googleapis.com/, che è stato omesso dalle voci della tabella.

Metriche del server API

Questa sezione fornisce un elenco delle metriche del server API e ulteriori informazioni sull'interpretazione e l'utilizzo delle metriche.

Elenco delle metriche del server API

Quando le metriche del server API sono abilitate, tutte le metriche mostrate nella tabella seguente vengono esportate in Cloud Monitoring nello stesso progetto del cluster GKE.

I nomi delle metriche di Cloud Monitoring in questa tabella devono avere il prefisso prometheus.googleapis.com/. Questo prefisso è stato omesso dalle voci della tabella.

Le seguenti sezioni forniscono ulteriori informazioni sulle metriche del server API.

apiserver_request_duration_seconds

Utilizza questa metrica per monitorare la latenza nel server API. La durata della richiesta registrata da questa metrica include tutte le fasi di elaborazione della richiesta, dal momento in cui la richiesta viene ricevuta al momento in cui il server completa la risposta al client. Nello specifico, include il tempo trascorso su:

• L'autenticazione e l'autorizzazione della richiesta.
• Chiamata dei webhook di terze parti e di sistema associati alla richiesta.
• Recupero dell'oggetto richiesto da una cache in memoria (per le richieste che specificano un parametro URL resourceVersion) o dal database dello stato del cluster basato su etcd o Spanner chiamando l'API etcd (per tutte le altre richieste).
• Puoi utilizzare le etichette group, version, resource e subresource per identificare in modo univoco una richiesta lenta per ulteriori indagini.
• Scrivere la risposta al cliente e ricevere la sua risposta.

Per saperne di più sull'utilizzo di questa metrica, consulta la sezione Latenza.

Questa metrica ha una cardinalità molto elevata. Quando utilizzi questa metrica, devi utilizzare filtri o raggruppamenti per trovare fonti specifiche di latenza.

apiserver_admission_controller_admission_duration_seconds

Questa metrica misura la latenza nei webhook di ammissione integrati, non nei webhook di terze parti. Per diagnosticare i problemi di latenza con i webhook di terze parti, utilizza la metrica apiserver_admission_webhook_admission_duration_seconds.

apiserver_admission_webhook_admission_duration_seconds e
apiserver_admission_step_admission_duration_seconds

Queste metriche misurano la latenza nei webhook di ammissione esterni di terze parti. La metrica apiserver_admission_webhook_admission_duration_seconds è generalmente la più utile. Per saperne di più sull'utilizzo di questa metrica, consulta la sezione Latenza.

apiserver_request_total

Utilizza questa metrica per monitorare il traffico delle richieste sul server API. Puoi anche utilizzarlo per determinare le percentuali di successo ed errore delle tue richieste. Per ulteriori informazioni sull'utilizzo di questa metrica, consulta Tasso di traffico ed errori.

Questa metrica ha una cardinalità molto elevata. Quando utilizzi questa metrica, devi utilizzare filtri o raggruppamenti per identificare le origini degli errori.

apiserver_storage_objects

Utilizza questa metrica per rilevare la saturazione del sistema e identificare possibili perdite di risorse. Per ulteriori informazioni, vedi Saturazione.

apiserver_current_inflight_requests

Questa metrica registra il numero massimo di richieste gestite attivamente nell'ultimo secondo. Per ulteriori informazioni, vedi Saturazione.

La metrica non include richieste a esecuzione prolungata come "watch".

Monitoraggio del server API

Le metriche del server API possono fornire informazioni sui principali indicatori dello stato del sistema:

• Latenza: quanto tempo è necessario per gestire una richiesta?
• Traffico: quanta domanda sta registrando il sistema?
• Tasso di errore: con quale frequenza le richieste non vanno a buon fine?
• Saturazione: quanto è pieno il sistema?

Questa sezione descrive come utilizzare le metriche del server API per monitorare l'integrità del server API.

Latenza

Quando il server API è sovraccarico, la latenza delle richieste aumenta. Per misurare la latenza delle richieste al server API, utilizza la metrica apiserver_request_duration_seconds. Per identificare in modo più specifico l'origine della latenza, puoi raggruppare le metriche in base all'etichetta verb o resource.

Il limite superiore suggerito per una chiamata a una singola risorsa come GET, POST o PATCH è di un secondo. Il limite superiore suggerito per le chiamate LIST con ambito spazio dei nomi e con ambito cluster è di 30 secondi. Le aspettative del limite superiore sono stabilite dagli SLO definiti dalla community open source di Kubernetes. Per ulteriori informazioni, consulta Dettagli degli indicatori/obiettivi di livello di servizio della latenza delle chiamate API.

Se il valore della metrica apiserver_request_duration_seconds aumenta oltre la durata prevista, esamina le seguenti possibili cause:

• Il piano di controllo Kubernetes potrebbe essere sovraccarico. Per verificare, esamina le metriche apiserver_request_total e apiserver_storage_objects.
  • Utilizza l'etichetta code per determinare se le richieste vengono elaborate correttamente. Per informazioni sui valori possibili, consulta Codici di stato HTTP.
  • Utilizza le etichette group, version, resource e subresource per identificare in modo univoco una richiesta.

• Un webhook di ammissione di terze parti è lento o non risponde. Se il valore della metrica apiserver_admission_webhook_admission_duration_seconds è in aumento, alcuni dei tuoi webhook di controllo di ammissione di terze parti o definiti dall'utente sono lenti o non rispondono. La latenza nel webhook di ammissione può causare ritardi nella pianificazione dei job.

  • Per eseguire query sulla latenza del webhook del 99° percentile per istanza del piano di controllo Kubernetes, utilizza la seguente query PromQL:

     sum by (instance) (histogram_quantile(0.99, rate(apiserver_admission_webhook_admission_duration_seconds_bucket{cluster="CLUSTER_NAME"}[1m]))) 

    Ti consigliamo di esaminare anche i percentili 50°, 90°, 95° e 99, 9°; puoi modificare questa query modificando il valore 0.99.

  • I webhook esterni hanno un limite di timeout di circa 10 secondi. Puoi impostare criteri di avviso per la metrica apiserver_admission_webhook_admission_duration_seconds per ricevere avvisi quando ti avvicini al timeout del webhook.

  • Puoi anche raggruppare la metrica apiserver_admission_webhook_admission_duration_seconds sull'etichetta name per diagnosticare possibili problemi con webhook specifici.

• Stai elencando molti oggetti. È previsto che la latenza delle chiamate LIST aumenti man mano che aumenta il numero di oggetti di un determinato tipo (le dimensioni della risposta).

• Problemi lato client:

  • Il client potrebbe non disporre di risorse sufficienti per ricevere risposte in modo tempestivo. Per verificare, esamina le metriche di utilizzo della CPU per il pod client.
  • Il client ha una connessione di rete lenta. Ciò può accadere quando il client viene eseguito su un dispositivo come un cellulare, ma è improbabile per i client in esecuzione su una rete Compute Engine.
  • Il client è uscito inaspettatamente, ma la connessione TCP ha un periodo di timeout di decine di secondi. Prima del timeout della connessione, le risorse del server vengono bloccate, il che può aumentare la latenza.

Per saperne di più, consulta Best practice per l'utilizzo di API Priority and Fairness nella documentazione di Kubernetes.

Percentuale di traffico ed errori

Per misurare il traffico e il numero di richieste riuscite e non riuscite sul server API, utilizza la metrica apiserver_request_total. Ad esempio, per misurare il traffico del server API per istanza del control plane Kubernetes, utilizza la seguente query PromQL:

 sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME"}[1m])) 

• Per eseguire query sulle richieste non riuscite, filtra l'etichetta code per i valori 4xx e 5xx utilizzando la seguente query PromQL:

   sum(rate(apiserver_request_total{code=~"[45].."}[5m])) 

• Per eseguire query sulle richieste riuscite, filtra l'etichetta code per i valori 2xx utilizzando la seguente query PromQL:

   sum(rate(apiserver_request_total{code=~"2.."}[5m])) 

• Per eseguire query sulle richieste rifiutate dal server API per istanza del control plane Kubernetes, filtra l'etichetta code per il valore 429 (http.StatusTooManyRequests) utilizzando la seguente query PromQL:

   sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME", code="429"}[1m])) 

Saturazione

Puoi misurare la saturazione nel tuo sistema utilizzando le metriche apiserver_current_inflight_requests e apiserver_storage_objects .

Se il valore della metrica apiserver_storage_objects è in aumento, potresti riscontrare un problema con un controller personalizzato che crea oggetti ma non li elimina. Puoi filtrare o raggruppare la metrica in base all'etichetta resource per identificare la risorsa che sta riscontrando l'aumento.

Valuta la metrica apiserver_current_inflight_requests in base alle impostazioni di priorità e correttezza dell'API. Queste impostazioni influiscono sulla priorità delle richieste, quindi non puoi trarre conclusioni solo dai valori della metrica. Per ulteriori informazioni, consulta la sezione Priorità e correttezza dell'API.

Metriche di Scheduler

Questa sezione fornisce un elenco delle metriche dello scheduler e ulteriori informazioni sull'interpretazione e l'utilizzo delle metriche.

Elenco delle metriche dello scheduler

Quando le metriche dello scheduler sono abilitate, tutte le metriche mostrate nella tabella seguente vengono esportate in Cloud Monitoring nello stesso progetto del cluster GKE.

I nomi delle metriche di Cloud Monitoring in questa tabella devono avere il prefisso prometheus.googleapis.com/. Questo prefisso è stato omesso dalle voci della tabella.

Le seguenti sezioni forniscono ulteriori informazioni sulle metriche del server API.

scheduler_pending_pods

Puoi utilizzare la metrica scheduler_pending_pods per monitorare il carico sul tuo scheduler. L'aumento dei valori in questa metrica può indicare problemi di risorse. Lo scheduler ha tre code e questa metrica riporta il numero di richieste in attesa per coda. Sono supportate le seguenti code:

• active queue
  • L'insieme di pod che lo scheduler sta tentando di pianificare; il pod con la priorità più alta si trova all'inizio della coda.
• backoff queue
  • L'insieme di pod non era pianificabile l'ultima volta che lo scheduler ha provato, ma potrebbe esserlo la prossima volta.
  • I pod in questa coda devono attendere un periodo di backoff (massimo 10 secondi), dopodiché vengono spostati di nuovo nella coda active per un altro tentativo di pianificazione. Per ulteriori informazioni sulla gestione della coda backoff, consulta la richiesta di implementazione, Problema 75417 di Kubernetes.

• unschedulable set

  • Il set di pod che lo scheduler ha tentato di pianificare, ma che sono risultati non pianificabili. Il posizionamento in questa coda potrebbe indicare problemi di compatibilità o preparazione con i tuoi nodi o con la configurazione dei selettori di nodi.

    Quando i vincoli delle risorse impediscono la pianificazione dei pod, questi non sono soggetti alla gestione del backoff. Quando un cluster è pieno, i nuovi pod non vengono programmati e vengono inseriti nella coda unscheduled.

  • La presenza di pod non pianificati potrebbe indicare che hai risorse insufficienti o un problema di configurazione dei nodi. I pod vengono spostati nella coda backoff o active dopo gli eventi che modificano lo stato del cluster. I pod in questa coda indicano che nel cluster non è cambiato nulla che li renda pianificabili.

  • Affinità definiscono le regole per l'assegnazione dei pod ai nodi. L'utilizzo di regole di affinità o anti-affinità può essere un motivo di aumento dei pod non pianificati.

  • Alcuni eventi, ad esempio l'aggiunta/l'aggiornamento di PVC/servizio, la terminazione di un pod o la registrazione di nuovi nodi, spostano alcuni o tutti i pod non pianificati nella coda backoff o active. Per ulteriori informazioni, consulta il problema 81214 di Kubernetes.

Per saperne di più, consulta Latenza dello scheduler e Problemi relativi alle risorse.

scheduler_scheduling_attempt_duration_seconds

Questa metrica misura la durata di un singolo tentativo di pianificazione all'interno dello scheduler stesso ed è suddivisa in base al risultato: pianificato, non pianificabile o errore. La durata va dal momento in cui lo scheduler preleva un pod fino al momento in cui lo scheduler individua un nodo e posiziona il pod sul nodo, determina che il pod non è pianificabile o si verifica un errore. La durata della programmazione include il tempo della procedura di programmazione e il tempo di binding. Il binding è il processo in cui lo scheduler comunica l'assegnazione del nodo al server API. Per ulteriori informazioni, vedi Latenza dello scheduler.

Questa metrica non acquisisce il tempo che il pod trascorre nel controllo di ammissione o nella convalida.

Per ulteriori informazioni sulla pianificazione, vedi Pianificare un pod.

scheduler_schedule_attempts_total

Questa metrica misura il numero di tentativi di pianificazione; ogni tentativo di pianificazione di un pod aumenta il valore. Puoi utilizzare questa metrica per determinare se lo scheduler è disponibile: se il valore è in aumento, lo scheduler è operativo. Puoi utilizzare l'etichetta result per determinare la riuscita: i pod sono scheduled o unschedulable.

Questa metrica è fortemente correlata alla metrica scheduler_pending_pods: quando ci sono molti pod in attesa, puoi aspettarti di vedere molti tentativi di pianificazione dei pod. Per ulteriori informazioni, vedi Problemi relativi alle risorse.

Questa metrica non aumenta se lo scheduler non ha pod da pianificare, il che può verificarsi se hai uno scheduler secondario personalizzato.

scheduler_preemption_attempts_total e scheduler_preemptions_victims

Puoi utilizzare le metriche di preemptive per determinare se devi aggiungere risorse.

Potresti avere pod con priorità più elevata che non possono essere pianificati perché non c'è spazio per loro. In questo caso, lo scheduler libera le risorse eseguendo la preemption di uno o più pod in esecuzione su un nodo. La metrica scheduler_preemption_attempts_total monitora il numero di volte in cui lo scheduler ha tentato di eseguire la preemption dei pod.

La metrica scheduler_preemptions_victims conteggia i pod selezionati per la preemption.

Il numero di tentativi di preemption è strettamente correlato al valore della metrica scheduler_schedule_attempts_total quando il valore dell'etichetta result è unschedulable. I due valori non sono equivalenti: ad esempio, se un cluster ha 0 nodi, non ci sono tentativi di preempt, ma potrebbero esserci tentativi di pianificazione non riusciti.

Per ulteriori informazioni, vedi Problemi relativi alle risorse.

Monitoraggio dello scheduler

Le metriche dello scheduler possono fornire informazioni sul rendimento dello scheduler:

• Latenza scheduler: lo scheduler è in esecuzione? Quanto tempo ci vuole per pianificare i pod?
• Problemi relativi alle risorse: i tentativi di pianificare i pod sono soggetti a vincoli delle risorse?

Questa sezione descrive come utilizzare la metrica dello scheduler per monitorare lo scheduler.

Latenza dello scheduler

Il compito dello scheduler è garantire l'esecuzione dei pod, quindi vuoi sapere quando lo scheduler è bloccato o rallentato.

• Per verificare che lo scheduler sia in esecuzione e pianifichi i pod, utilizza la metrica scheduler_schedule_attempts_total.

• Quando lo scheduler funziona lentamente, esamina le seguenti possibili cause:

  • Il numero di pod in attesa è in aumento. Utilizza la metrica scheduler_pending_pods per monitorare il numero di pod in attesa. La seguente query PromQL restituisce il numero di pod in attesa per coda in un cluster:

     sum by (queue) (delta(scheduler_pending_pods{cluster="CLUSTER_NAME"}[2m])) 

  • I singoli tentativi di pianificare i pod sono lenti. Utilizza la metrica scheduler_scheduling_attempt_duration_seconds per monitorare la latenza dei tentativi di pianificazione.

    Ti consigliamo di osservare questa metrica almeno al 50° e al 95° percentile. La seguente query PromQL recupera i valori del 95° percentile, ma può essere modificata:

     sum by (instance) (histogram_quantile(0.95, rate( scheduler_scheduling_attempt_duration_seconds_bucket{cluster="CLUSTER_NAME"}[5m]))) 

Problemi relativi alle risorse

Le metriche dello scheduler possono anche aiutarti a valutare se disponi di risorse sufficienti. Se il valore della metrica scheduler_preemption_attempts_total è in aumento, controlla il valore di scheduler_preemption_victims utilizzando la seguente query PromQL:

 scheduler_preemption_victims_sum{cluster="CLUSTER_NAME"} 

Il numero di tentativi di preempt e il numero di vittime di preempt aumentano entrambi quando ci sono pod con priorità più elevata da pianificare. Le metriche di preemptive non indicano se i pod ad alta priorità che hanno attivato le preemptive sono stati pianificati, quindi quando vedi aumenti nel valore delle metriche di preemptive, puoi anche monitorare il valore della metrica scheduler_pending_pods. Se anche il numero di pod in attesa è in aumento, potresti non disporre di risorse sufficienti per gestire i pod con priorità più alta. Potresti dover aumentare le risorse disponibili, creare nuovi pod con richieste di risorse ridotte o modificare il selettore di nodi.

• Se il numero di vittime di preemptive non aumenta, non ci sono altri pod con priorità bassa che possono essere rimossi. In questo caso, valuta la possibilità di aggiungere altri nodi in modo che i nuovi pod possano essere allocati.

• Se il numero di vittime di preemption è in aumento, significa che ci sono pod con priorità più elevata in attesa di essere pianificati, quindi lo scheduler sta eseguendo la preemption di alcuni dei pod in esecuzione. Le metriche di preemption non indicano se i pod con priorità più elevata sono stati pianificati correttamente.

  Per determinare se i pod con priorità più elevata vengono pianificati, cerca valori decrescenti della metrica scheduler_pending_pods. Se il valore di questa metrica è in aumento, potresti dover aggiungere altri nodi.

Puoi aspettarti di vedere picchi temporanei nei valori della metrica scheduler_pending_pods quando i carichi di lavoro verranno pianificati nel cluster, ad esempio durante eventi come aggiornamenti o scalabilità. Se hai risorse sufficienti nel cluster, questi picchi sono temporanei. Se il numero di pod in attesa non diminuisce, procedi nel seguente modo:

• Verifica che i nodi non siano isolati; i nodi isolati non accettano nuovi pod.
• Controlla le seguenti direttive di pianificazione, che possono essere configurate in modo errato e potrebbero rendere un pod non pianificabile:
  • Affinità e selettore dei nodi.
  • Incompatibilità e tolleranze.
  • Vincoli di distribuzione della topologia dei pod.

Se i pod non possono essere pianificati a causa di risorse insufficienti, valuta la possibilità di liberare alcuni dei nodi esistenti o aumentare il numero di nodi.

Metriche di Gestore del controller

Quando le metriche di Controller Manager sono abilitate, tutte le metriche mostrate nella tabella seguente vengono esportate in Cloud Monitoring nello stesso progetto del cluster GKE.

I nomi delle metriche di Cloud Monitoring in questa tabella devono avere il prefisso prometheus.googleapis.com/. Questo prefisso è stato omesso dalle voci della tabella.