Utilizza le metriche del piano di controllo

Puoi configurare un cluster Google Kubernetes Engine (GKE) per inviare determinate metriche emesse dal server API Kubernetes, dallo scheduler e dal gestore del controller a Cloud Monitoring utilizzando Google Cloud Managed Service per Prometheus. Questo documento descrive come queste metriche vengono formattate quando vengono scritte in Cloud Monitoring e come eseguire query. Questo documento fornisce anche tabelle che elencano le metriche di ogni set e fornisce informazioni su come puoi utilizzarle.

Prima di poter utilizzare le metriche del piano di controllo, devi abilitare la relativa raccolta.

Formato delle metriche

Tutte le metriche del piano di controllo Kubernetes scritte in Cloud Monitoring utilizzano il tipo di risorsa prometheus_target. Ogni nome di metrica è preceduto dal prefisso prometheus.googleapis.com/ e ha un suffisso che indica il tipo di metrica Prometheus, ad esempio /gauge, /histogram o /counter. Altrimenti, il nome di ogni metrica è identico a quello esposto da Kubernetes open source.

Esportazione da Cloud Monitoring

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

Esecuzione di query sulle metriche

Quando esegui query sulle metriche del piano di controllo, il nome da utilizzare varia a seconda che tu stia utilizzando funzionalità basate su PromQL o Cloud Monitoring come MQL o l' interfaccia basata su menu di Metrics Explorer.

Le seguenti tabelle di metriche del piano di controllo mostrano due versioni di ciascun 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 di Cloud Monitoring Quando utilizzi altre funzionalità di Cloud Monitoring, usa il nome della metrica di Cloud Monitoring nelle tabelle seguenti. Questo nome deve essere preceduto dal 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 informazioni aggiuntive sull'interpretazione e sull'utilizzo delle metriche.

Elenco delle metriche del server API

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

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

Nome metrica PromQL Fase di lancio
Nome metrica Cloud Monitoring
Tipo, Tipo, Unità
Risorse monitorate
Versione di GKE obbligatoria		 Descrizione
Etichette
apiserver_current_inflight_requests GA
apiserver_current_inflight_requests/gauge
Gauge, Double, 1
prometheus_target
1.22.13 o superiore 		Numero massimo di limiti di richieste in corso attualmente in uso di questo apiserver per tipo di richiesta nell'ultimo secondo.

request_kind
apiserver_flowcontrol_current_executing_seats BETA
apiserver_flowcontrol_current_executing_seats/gauge
Gauge, Double, 1
prometheus_target
1.28.3 o versioni successive 		Contemporaneità (numero di utenze) occupata dalle richieste attualmente in esecuzione (fase iniziale per uno smartwatch, qualsiasi fase altrimenti) nel sottosistema Priorità ed equità dell'API.

flow_schema
priority_level
apiserver_flowcontrol_current_inqueue_requests BETA
apiserver_flowcontrol_current_inqueue_requests/gauge
Gauge, Double, 1
prometheus_target
1.28.3 e versioni successive (1.25.16-gke.1360000 e versioni successive, 1.26.11 e versioni successive, 1.27.8 e versioni successive per le versioni secondarie precedenti) 		Numero di richieste attualmente in attesa in coda del sottosistema Priorità ed Equità delle API.

flow_schema
priority_level
apiserver_flowcontrol_nominal_limit_seats BETA
apiserver_flowcontrol_nominal_limit_seats/gauge
Gauge, Double, 1
prometheus_target
1.28.3 e versioni successive (1.26.11 e versioni successive, 1.27.8 e versioni successive per le versioni secondarie precedenti) 		Numero nominale di utenze di esecuzione configurate per ogni livello di priorità.

priority_level
apiserver_flowcontrol_rejected_requests_total BETA
apiserver_flowcontrol_rejected_requests_total/counter
Cumulative, Double, 1
prometheus_target
1.28.3 e versioni successive (1.25.16-gke.1360000 e versioni successive, 1.26.11 e versioni successive, 1.27.8 e versioni successive per le versioni secondarie precedenti) 		Numero di richieste rifiutate dal sottosistema Priorità ed equità delle API.

flow_schema
priority_level
reason
apiserver_flowcontrol_request_wait_duration_seconds BETA
apiserver_flowcontrol_request_wait_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.28.3 e versioni successive (1.25.16-gke.1360000 e versioni successive, 1.26.11 e versioni successive, 1.27.8 e versioni successive per le versioni secondarie precedenti) 		Tempo di attesa di una richiesta in coda.

execute
flow_schema
priority_level
apiserver_request_duration_seconds GA
apiserver_request_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.23.6 o versioni successive 		Distribuzione della latenza di risposta in secondi per ogni verbo, valore di prova, gruppo, versione, risorsa, sottorisorsa, ambito e componente.

component
dry_run
group
resource
scope
subresource
verb
version
apiserver_request_total GA
apiserver_request_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13 o superiore 		Contatore delle richieste apiserver suddivise per ogni verbo, valore di prova, gruppo, versione, risorsa, ambito, componente e codice di risposta HTTP.

code
component
dry_run
group
resource
scope
subresource
verb
version
apiserver_response_sizes GA
apiserver_response_sizes/histogram
Cumulative, Distribution, 1
prometheus_target
1.22.13 o superiore 		Distribuzione delle dimensioni delle risposte in byte per ogni gruppo, versione, verbo, risorsa, risorsa, sottorisorsa, ambito e componente.

component
group
resource
scope
subresource
verb
version
apiserver_storage_objects GA
apiserver_storage_objects/gauge
Gauge, Double, 1
prometheus_target
1.22.13 o superiore 		Numero di oggetti archiviati al momento dell'ultimo controllo, suddivisi per tipo.

resource
apiserver_admission_controller_admission_duration_seconds GA
apiserver_admission_controller_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.23.6 o versioni successive 		Istogramma della latenza del controller di ammissione in secondi, identificato per nome e suddiviso per ogni operazione, risorsa e tipo di API (convalida o ammetti).

name
operation
rejected
type
apiserver_admission_step_admission_duration_seconds GA
apiserver_admission_step_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.22.13 o superiore 		Istogramma della latenza del passaggio secondario di ammissione in secondi, suddiviso per ogni operazione e tipo di risorsa API e tipo di passaggio (convalida o ammissione).

operation
rejected
type
apiserver_admission_webhook_admission_duration_seconds GA
apiserver_admission_webhook_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.22.13 o superiore 		Istogramma della latenza webhook di ammissione in secondi, identificato per nome e suddiviso per ogni operazione, risorsa e tipo di API (convalida o ammette).

name
operation
rejected
type

Le sezioni seguenti forniscono informazioni aggiuntive 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 dell'elaborazione della richiesta, dal momento in cui la richiesta viene ricevuta fino al momento in cui il server completa la sua risposta al client. In particolare, include il tempo dedicato a:

  • L'autenticazione e l'autorizzazione della richiesta.
  • Chiamata ai webhook di sistema e di terze parti associati alla richiesta.
  • Recupero dell'oggetto richiesto da una cache in memoria (per le richieste che specificano un parametro URL resourceVersion) o da 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.
  • Scrittura della risposta per il client e ricezione della risposta del client.

Per ulteriori informazioni sull'uso di questa metrica, consulta Latenza.

Questa metrica ha una cardinalità molto alta. Quando usi questa metrica, devi usare filtri o raggruppamenti per trovare sorgenti di latenza specifiche.

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 webook 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 in webhook di ammissione esterni di terze parti. La metrica apiserver_admission_webhook_admission_duration_seconds è in genere la metrica più utile. Per ulteriori informazioni sull'utilizzo di questa metrica, consulta Latenza.

apiserver_request_total

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

Questa metrica ha una cardinalità molto alta. Quando usi questa metrica, devi usare 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 maggiori informazioni, consulta Saturazione.

apiserver_current_inflight_requests

Questa metrica registra il numero massimo di richieste pubblicate attivamente nell'ultimo secondo. Per maggiori informazioni, consulta Saturazione.

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

Monitoraggio del server API

Le metriche del server API possono fornirti insight sui segnali principali per l'integrità del sistema:

  • Latenza: quanto tempo è necessario per gestire una richiesta?
  • Traffico: quanta domanda sta ricevendo il sistema?
  • Percentuale 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 risorsa singola come GET, POST o PATCH è di 1 secondo. Il limite superiore suggerito per le chiamate LIST con ambito cluster e spazio dei nomi è di 30 secondi. Le aspettative al limite superiore sono impostate dagli SLO definiti dalla community open source Kubernetes; per ulteriori informazioni, consulta Dettagli sugli SLI/SLO di 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, osserva le metriche apiserver_request_total e apiserver_storage_objects.
    • Utilizza l'etichetta code per determinare se le richieste vengono elaborate correttamente. Per informazioni sui possibili valori, consulta la pagina relativa ai 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 aumenta, alcuni dei webhook 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 una query sulla latenza di webhook al 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 il 50°, 90°, 95° e 99, 9° percentile; 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 nella metrica apiserver_admission_webhook_admission_duration_seconds per ricevere un avviso quando stai per raggiungere il timeout del webhook.

    • Puoi anche raggruppare la metrica apiserver_admission_webhook_admission_duration_seconds nell'etichetta name per diagnosticare possibili problemi relativi a webhook specifici.

  • Stai elencando molti oggetti. Si prevede che la latenza delle chiamate LIST aumenti all'aumentare del numero di oggetti di un determinato tipo (la dimensione della risposta).

  • Problemi lato client:

    • Il cliente potrebbe non disporre di risorse sufficienti per ricevere risposte tempestive. Per verificare, guarda le metriche di utilizzo della CPU per il pod client.
    • La connessione di rete del client è lenta. Questo può accadere quando il client è in esecuzione su un dispositivo come un cellulare, ma è improbabile per i client in esecuzione su una rete Compute Engine.
    • Il client si è chiuso in modo imprevisto, 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.

Percentuale di traffico ed errori

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

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

  • Per eseguire una 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 una query sulle richieste riuscite, filtra l'etichetta code in base a 2xx valori utilizzando la seguente query PromQL:

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

  • Per eseguire una query sulle richieste rifiutate dal server API per ogni istanza del piano di controllo 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 sistema utilizzando le metriche apiserver_current_inflight_requests e apiserver_storage_objects .

Se il valore della metrica apiserver_storage_objects aumenta, 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 o è aumentata.

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

Metriche dello scheduler

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

Elenco delle metriche dello scheduler

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

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

Nome metrica PromQL Fase di lancio
Nome metrica Cloud Monitoring
Tipo, Tipo, Unità
Risorse monitorate
Versione di GKE obbligatoria		 Descrizione
Etichette
scheduler_pending_pods GA
scheduler_pending_pods/gauge
Gauge, Double, 1
prometheus_target
1.22.13 o superiore 		Numero di pod in attesa, per tipo di coda. "attivo" indica il numero di pod in activeQ; "backoff" indica il numero di pod in backoffQ; "non pianificabili" indica il numero di pod in pod non pianificabili.

queue
scheduler_pod_scheduling_duration_seconds GA
scheduler_pod_scheduling_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.25.1 e versioni successive (1.22.17-gke.3100 e versioni successive, 1.23.11 e versioni successive e 1.24.5 e successive per le versioni secondarie precedenti) 		Latenza E2e per un pod in fase di pianificazione, che può includere più tentativi di pianificazione.

attempts
scheduler_preemption_attempts_total GA
scheduler_preemption_attempts_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13 o superiore 		Numero totale di tentativi di prerilascio nel cluster finora
scheduler_preemption_victims GA
scheduler_preemption_victims/histogram
Cumulative, Distribution, 1
prometheus_target
1.22.13 o superiore 		Numero di vittime di prerilascio selezionate
scheduler_scheduling_attempt_duration_seconds GA
scheduler_scheduling_attempt_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.23.6 o versioni successive 		Latenza del tentativo di pianificazione in secondi (algoritmo di pianificazione + associazione).

profile
result
scheduler_schedule_attempts_total GA
scheduler_schedule_attempts_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13 o superiore 		Numero di tentativi di pianificazione dei pod in base al risultato. "non pianificabile" significa che non è stato possibile pianificare un pod, mentre "errore" indica un problema con lo scheduler interno.

profile
result

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

scheduler_pending_pods

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

  • Coda active
    • L'insieme di pod che lo scheduler sta tentando di pianificare; il pod con la priorità più alta è in cima alla coda.
  • Coda backoff
    • Il set di pod non era pianificabile l'ultima volta che lo scheduler ha provato, ma che potrebbe essere pianificabile la volta successiva.
    • I pod in questa coda devono attendere un periodo di backoff (massimo 10 secondi), dopodiché vengono riportati nella coda active per un altro tentativo di pianificazione. Per saperne di più sulla gestione della coda backoff, consulta la richiesta di implementazione Problema di Kubernetes 75417.

  • unschedulable impostato

    • L'insieme di pod che lo scheduler ha tentato di pianificare, ma che è stato stabilito essere non pianificabili. Il posizionamento su questa coda potrebbe indicare problemi di idoneità o compatibilità con i tuoi nodi o con la configurazione dei selettori dei nodi.

      Quando i vincoli delle risorse impediscono la pianificazione dei pod, questi non sono soggetti a gestione del backoff. Quando un cluster è pieno, i nuovi pod non possono essere pianificati e vengono posizionati sulla coda unscheduled.

    • La presenza di pod non pianificati potrebbe indicare che le risorse sono insufficienti o che hai 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 renda pianificabili i pod.

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

    • Alcuni eventi, come PVC/Service ADD/UPDATE, la terminazione di un pod o la registrazione di nuovi nodi, trasferiscono alcuni o tutti i pod non pianificati nella coda backoff o active. Per maggiori informazioni, consulta Problema di Kubernetes 81214.

Per ulteriori informazioni, 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 strumento di pianificazione stesso ed è suddivisa in base al risultato: pianificato, non pianificabile o errore. La durata va dal momento in cui lo scheduler seleziona un pod fino al momento in cui lo scheduler individua un nodo e lo posiziona sul nodo, determina che il pod non è pianificabile o riscontra un errore. La durata della pianificazione include il tempo nel processo di pianificazione e il tempo di associazione. L'associazione è il processo in cui lo scheduler comunica la sua assegnazione dei nodi al server API. Per ulteriori informazioni, consulta Latenza dello scheduler.

Questa metrica non acquisisce il tempo impiegato dal pod per il controllo o la convalida di ammissione.

Per maggiori informazioni sulla pianificazione, consulta Pianificazione di un pod.

scheduler_schedule_attempts_total

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

Questa metrica è strettamente 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, consulta Problemi delle 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 prerilascio per determinare se è necessario aggiungere risorse.

Potresti avere pod con priorità più alta che non possono essere pianificati perché non c'è spazio per questi pod. In questo caso, lo scheduler libera risorse prerilasciando 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 prerilasciare i pod.

La metrica scheduler_preemptions_victims conteggia i pod selezionati per il prerilascio.

Il numero di tentativi di prerilascio è 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 vengono effettuati tentativi di prerilascio, ma potrebbero verificarsi tentativi di pianificazione che non vanno a buon fine.

Per saperne di più, consulta Problemi relativi alle risorse.

Monitoraggio dello scheduler

Le metriche dello scheduler possono fornirti informazioni sulle prestazioni del tuo scheduler:

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

Latenza scheduler

L'attività dello scheduler è garantire che i pod vengano eseguiti, in modo da sapere quando lo scheduler è bloccato o è in esecuzione lentamente.

  • Per verificare che lo scheduler sia in esecuzione e pianificando 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 pianificazione dei 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 aumenta, controlla il valore di scheduler_preemption_victims utilizzando la seguente query PromQL:

scheduler_preemption_victims_sum{cluster="CLUSTER_NAME"}

Il numero di tentativi di prerilascio e il numero di vittime di prerilascio aumentano entrambi quando ci sono pod con priorità più alta da pianificare. Le metriche di prerilascio non indicano se i pod ad alta priorità che hanno attivato i prerilasci sono stati pianificati, pertanto, quando rilevi un aumento del valore delle metriche di prerilascio, puoi anche monitorare il valore della metrica scheduler_pending_pods. Se aumenta anche il numero di pod in attesa, potresti non disporre di risorse sufficienti per gestire i pod con priorità più alta. Potresti dover fare lo scale up delle risorse disponibili, creare nuovi pod con attestazioni di risorse ridotte o cambiare il selettore di nodi.

  • Se il numero di vittime del prerilascio non aumenta, non ci sono altri pod con priorità bassa che possono essere rimossi. In questo caso, valuta la possibilità di aggiungere più nodi in modo da poter allocare i nuovi pod.

  • Se il numero di vittime del prerilascio aumenta, ci sono pod con priorità più alta in attesa di essere pianificati, quindi lo scheduler prerilascia alcuni dei pod in esecuzione. Le metriche di prerilascio non indicano se i pod con priorità più elevata sono stati pianificati correttamente.

    Per determinare se i pod con priorità più alta sono in fase di pianificazione, cerca valori decrescenti della metrica scheduler_pending_pods. Se il valore di questa metrica aumenta, potrebbe essere necessario aggiungere altri nodi.

Puoi aspettarti di vedere picchi temporanei nei valori per la metrica scheduler_pending_pods quando verranno pianificati i carichi di lavoro nel tuo cluster, ad esempio durante eventi come aggiornamenti o scale. Se disponi di risorse sufficienti nel cluster, questi picchi sono temporanei. Se il numero di pod in attesa non diminuisce:

  • Verifica che i nodi non siano contrassegnati come non pianificabili; quelli contrassegnati non accettano nuovi pod.
  • Controlla le seguenti istruzioni di pianificazione, che potrebbero essere configurate in modo errato e rendere un pod non pianificabile:
    • Affinità dei nodi e selettore.
    • Incompatibilità e tolleranze.
    • vincoli di diffusione della topologia dei pod.

Se non è possibile pianificare i pod a causa di risorse insufficienti, considera la possibilità di liberare alcuni dei nodi esistenti o di aumentare il numero di nodi.

Metriche del Gestore controller

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

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

Nome metrica PromQL Fase di lancio
Nome metrica Cloud Monitoring
Tipo, Tipo, Unità
Risorse monitorate
Versione di GKE obbligatoria		 Descrizione
Etichette
node_collector_evictions_total GA
node_collector_evictions_total/counter
Cumulative, Double, 1
prometheus_target
almeno 1,24 		Numero di rimozioni dei nodi che si sono verificate dall'avvio dell'istanza attuale di NodeController.

zone