Raccogli e visualizza le metriche del piano di controllo

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

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Attiva l'API Google Kubernetes Engine.
    • Abilita l'API Google Kubernetes Engine .
  • Se vuoi utilizzare Google Cloud CLI per questa attività, install e poi initialize con gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.

Requisiti

Invio delle metriche emesse dai componenti del piano di controllo Kubernetes a Cloud Monitoring prevede i seguenti requisiti:

  • Il cluster deve avere metriche di sistema in un bucket con il controllo delle versioni attivo.

Configura la raccolta delle metriche del piano di controllo

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

Console

Puoi abilitare le metriche del piano di controllo per un cluster dal Osservabilità per il cluster o dalla scheda Dettagli per in un cluster Kubernetes. Quando utilizzi la scheda Osservabilità, puoi visualizzare l'anteprima i grafici e le metriche disponibili prima di abilitare il pacchetto di metriche.

Per abilitare le metriche del piano di controllo dalla scheda Osservabilità per il , segui questi passaggi:

  1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes:

    Vai a Cluster Kubernetes

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Kubernetes Engine.

  2. Fai clic sul nome del cluster e seleziona Osservabilità .

  3. Seleziona Piano di controllo dall'elenco delle funzionalità.

  4. Fai clic su Abilita pacchetto.

    Se le metriche del piano di controllo sono già abilitate, vedrai un insieme di grafici per le metriche del piano di controllo.

Per abilitare le metriche del piano di controllo dalla scheda Dettagli per il cluster, procedi nel seguente modo:

  1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes:

    Vai a Cluster Kubernetes

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Kubernetes Engine.

  2. Fai clic sul nome del cluster.

  3. Nella riga Funzionalità con etichetta Cloud Monitoring, Fai clic sull'icona Modifica.

  4. Nella finestra di dialogo Modifica Cloud Monitoring visualizzata, verifica che L'opzione Abilita Cloud Monitoring è selezionata.

  5. Nel menu a discesa Componenti, seleziona i componenti del piano di controllo. da cui vuoi raccogliere le metriche: Server API, Scheduler o Controller Manager.

  6. Fai clic su OK.

  7. Fai clic su Salva modifiche.

gcloud

Aggiorna il cluster per raccogliere le metriche emesse dal server API Kubernetes, Scheduler e gestore del controller:

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

Sostituisci quanto segue:

Terraform

Per configurare la raccolta di metriche del piano di controllo Kubernetes con Terraform, vedi il blocco monitoring_config nella Registro Terraform per google_container_cluster. Per informazioni generali sull'utilizzo di Google Cloud con Terraform, consulta Terraform con Google Cloud.

Quota

Le metriche del piano di controllo consumano le "Richieste di importazione di serie temporali al minuto" quota dell'API Cloud Monitoring. Prima di abilitare i pacchetti di metriche, controllare l'utilizzo massimo recente di quella quota. Se hai molti cluster nello stesso progetto o sono già che stai per raggiungere il limite della quota, puoi richiedere un aumento del limite della quota prima di abilitare uno dei due pacchetti di osservabilità.

Prezzi

Utilizzo delle metriche del piano di controllo GKE Google Cloud Managed Service per Prometheus da caricare in Cloud Monitoring. Cloud Monitoring addebita i costi per l'importazione di queste metriche si basano sul numero di campioni importati. Tuttavia, queste metriche sono gratuiti registrato cluster che appartengono a un progetto con la versione di GKE Enterprise in un bucket con il controllo delle versioni attivo.

Per ulteriori informazioni, vedi Prezzi di Cloud Monitoring.

Formato metrica

Tutte le metriche del piano di controllo Kubernetes Kubernetes scritte in Cloud Monitoring utilizza il tipo di risorsa prometheus_target. Ogni nome della metrica è preceduto dal prefisso prometheus.googleapis.com/ e ha un suffisso che indica Tipo di metrica Prometheus, ad esempio /gauge, /histogram, o /counter. In caso contrario, il nome di ogni 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 tramite Google Cloud Managed Service per Prometheus, È possibile eseguire query sulle metriche del piano di controllo Kubernetes utilizzando Prometheus Query Language (PromQL). Possono anche essere interrogate tramite utilizzando Monitoring Query Language (MQL).

Esecuzione di query sulle metriche

Quando esegui una query sulle metriche del piano di controllo Kubernetes, il nome che utilizzi dipende se usi PromQL o funzionalità basate su Cloud Monitoring, MQL o Metrics Explorer basata su menu.

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

  • Nome metrica PromQL: quando utilizzando PromQL nelle pagine di Cloud Monitoring della console Google Cloud o nei campi PromQL della API Cloud Monitoring, utilizza il nome della metrica PromQL.
  • Nome metrica di Cloud Monitoring Quando si utilizzano altri Funzionalità di Cloud Monitoring; utilizza il nome della metrica di Cloud Monitoring disponibili nelle tabelle seguenti. Questo nome deve essere preceduto dal prefisso prometheus.googleapis.com/, che è stata omessa dalla tabella. le voci nella tabella.

Metriche server API

Questa sezione fornisce un elenco di metriche del server API e altre metriche le informazioni sull'interpretazione e sull'utilizzo delle metriche.

Elenco di metriche del server API

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

I nomi delle metriche di Cloud Monitoring in questa tabella devono essere preceduti dal prefisso prometheus.googleapis.com/. Questo prefisso è stato omesso dalla le voci nella tabella.

Nome metrica PromQL Fase di lancio
Nome metrica di Cloud Monitoring
Tipo, Tipo, Unità
Risorse monitorate
Versione GKE richiesta		 Descrizione
Etichette
apiserver_current_inflight_requests GA
apiserver_current_inflight_requests/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		Numero massimo di richieste in transito attualmente utilizzate 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+ 		Contemporaneità (numero di utenze) occupata dall'attività attualmente in esecuzione (fase iniziale per WATCH, qualsiasi fase altrimenti) richieste nell'API Sottosistema Priorità ed equità.

flow_schema
priority_level
apiserver_flowcontrol_current_inqueue_requests BETA
apiserver_flowcontrol_current_inqueue_requests/gauge
Gauge, Double, 1
prometheus_target
1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ per le versioni secondarie precedenti) 		Numero di richieste attualmente in attesa nelle code dell'API Sottosistema Priorità ed equità.

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

priority_level
apiserver_flowcontrol_rejected_requests_total BETA
apiserver_flowcontrol_rejected_requests_total/counter
Cumulative, Double, 1
prometheus_target
1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ per le versioni secondarie precedenti) 		Numero di richieste rifiutate in base ai requisiti di priorità e equità delle API sottosistema.

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+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ per le versioni secondarie precedenti) 		Tempo di attesa in coda di una richiesta.

execute
flow_schema
priority_level
apiserver_request_duration_seconds GA
apiserver_request_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.23.6+ 		Distribuzione della latenza di risposta in secondi per ogni verbo, valore dry run, gruppo, versione, risorsa, risorsa secondaria, 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+ 		Contatore di richieste apiserver suddiviso per ogni verbo, valore dry run, 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+ 		Distribuzione delle dimensioni della risposta in byte per ogni gruppo, versione, verbo 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+ 		Numero di oggetti archiviati al momento dell'ultimo controllo, suddivisi per gentile.

resource
apiserver_admission_controller_admission_duration_seconds GA
apiserver_admission_controller_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.23.6+ 		Istogramma della latenza del controller di ammissione in secondi, identificato per nome e suddivisi per ciascuna operazione e risorsa e tipo di API (convalida ammettere).

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+ 		Istogramma della latenza dei passaggi secondari di ammissione in secondi, suddiviso per ogni operativa e di risorsa API e tipo di passaggio (convalida o ammetti).

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+ 		Istogramma della latenza del webhook di ammissione in secondi, identificato per nome e per ogni operazione e risorsa dell'API e tipo (convalida ammettere).

name
operation
rejected
type

Le seguenti sezioni forniscono informazioni aggiuntive sul server API metrics.

apiserver_request_duration_seconds

Utilizza questa metrica per monitorare la latenza nel server API. Durata della richiesta registrati da questa metrica include tutte le fasi dell'elaborazione delle richieste, dal momento la richiesta viene ricevuta fino al momento in cui il server completa la risposta alla di alto profilo. In particolare, include il tempo dedicato a quanto segue:

  • Autenticazione e autorizzazione della richiesta.
  • Chiamata ai webhook di terze parti e di sistema associati alla richiesta.
  • Recupero dell'oggetto richiesto da una cache in memoria (per le richieste che specifica un parametro URL resourceVersion) o etcd (per tutte le altre richieste).
  • Puoi utilizzare group, version, resource e subresource per assegnare in modo univoco identificare una richiesta lenta per ulteriori indagini.
  • Scrivere la risposta al cliente e riceverla.

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

Questa metrica ha una cardinalità molto elevata. Se usi questa metrica, devi usare o raggruppamenti per trovare origini specifiche di latenza.

apiserver_admission_controller_admission_duration_seconds

Questa metrica misura la latenza nei webhook di ammissione integrati, non nei da webhook di terze parti. Per diagnosticare i problemi di latenza su Webook di terze parti, utilizza il apiserver_admission_webhook_admission_duration_seconds o una metrica di valutazione.

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 metrica più utile. Per ulteriori informazioni sull'uso di questa consulta Latenza.

apiserver_request_total

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

Questa metrica ha una cardinalità molto elevata. Se usi questa metrica, devi usare 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 attivamente pubblicati nell'ultimo secondo. Per ulteriori informazioni, vedi Saturazione.

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

Monitoraggio del server API

Le metriche del server API possono fornirti insight sugli indicatori principali per il sistema integrità:

  • Latenza: quanto tempo impiega il servizio una richiesta?
  • Traffico: quanta domanda riceve il sistema. che stai riscontrando?
  • Percentuale di errori: quanto spesso 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 latenza delle richieste al server API, utilizza apiserver_request_duration_seconds o una metrica di valutazione. Per identificare in modo più specifico l'origine della latenza, puoi raggruppare 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 1 secondo. Il limite superiore suggerito per l'ambito sia a livello di spazio dei nomi che di cluster Le chiamate LIST durano 30 secondi. Le aspettative del limite superiore sono impostate da SLO definiti dalla community Kubernetes open source; Per ulteriori informazioni, vedi Dettagli SLI/SLO di latenza delle chiamate API.

Se il valore del parametro apiserver_request_duration_seconds aumenta oltre la durata prevista, esamina quanto segue possibili:

  • Il piano di controllo Kubernetes potrebbe essere sovraccarico. Per verificare, guarda l' apiserver_request_total e apiserver_storage_objects metrics.
    • Utilizza l'etichetta code per determinare se le richieste vengono in fase di elaborazione. Per informazioni sul possibile i valori, consulta Codici di stato HTTP.
    • Usa group, version, resource, e subresource per identificare in modo univoco una richiesta.

  • Un webhook di ammissione di terze parti è lento o non reattivo. Se il valore del parametro Metrica apiserver_admission_webhook_admission_duration_seconds è in aumento, alcune parti del dominio i webhook di ammissione definiti dall'utente sono lenti o non reattivi. Latenza in il webhook di ammissione può causare ritardi nella pianificazione dei lavori.

    • Per eseguire query sulla latenza webhook al 99° percentile per istanza di dal piano di controllo Kubernetes, usa 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° percentiles; puoi regolare 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 apiserver_admission_webhook_admission_duration_seconds che ti avvisa quando ti stai avvicinando al timeout del webhook.

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

  • Stai elencando molti oggetti. Si prevede che la latenza Le chiamate LIST aumentano con il numero di oggetti di un determinato tipo (la risposta dimensioni) aumenta.

  • Problemi lato client:

    • Il client potrebbe non disporre di risorse sufficienti per ricevere risposte in modo tempestivo. Per verificare, osserva le metriche di utilizzo della CPU per il client pod.
    • La connessione di rete del client è lenta. Questo può accadere quando di un 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 inaspettatamente, ma la connessione TCP un periodo di timeout in decine di secondi. Prima che la connessione scada, le risorse del server sono bloccate, il che può aumentare la latenza.

Traffico e percentuale di errori

Per misurare il traffico e il numero di richieste riuscite e non riuscite a livello API server, utilizza metrica apiserver_request_total. Per Ad esempio, per misurare il traffico del server API per istanza di usa 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 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 Valori 2xx utilizzando la seguente query PromQL:

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

  • Per interrogare le richieste rifiutate dal server API per ogni istanza del dal piano di controllo Kubernetes, filtra 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 la apiserver_current_inflight_requests e apiserver_storage_objects metrics.

Se il valore apiserver_storage_objects sta aumentando, è possibile che si sia verificato un problema con un che crea oggetti ma non li elimina. Puoi filtrare o raggruppare la metrica in base all'etichetta resource per identificare la risorsa che ha riscontrato/ l'aumento.

Valuta la metrica apiserver_current_inflight_requests in in conformità con le tue impostazioni di priorità e equità delle API; queste impostazioni hanno effetto la priorità delle richieste, quindi non puoi trarre conclusioni dalla metrica i soli valori. Per ulteriori informazioni, vedi Priorità e equità delle API.

Metriche 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 le metriche dello scheduler sono abilitate, tutte le metriche mostrate nella seguente tabella vengono esportate in Cloud Monitoring nello stesso progetto in un cluster Kubernetes.

I nomi delle metriche di Cloud Monitoring in questa tabella devono essere preceduti dal prefisso prometheus.googleapis.com/. Questo prefisso è stato omesso dalla le voci nella tabella.

Nome metrica PromQL Fase di lancio
Nome metrica di Cloud Monitoring
Tipo, Tipo, Unità
Risorse monitorate
Versione GKE richiesta		 Descrizione
Etichette
scheduler_pending_pods GA
scheduler_pending_pods/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		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 pianificabile' indica il numero di pod in unschedulablePods.

queue
scheduler_pod_scheduling_duration_seconds OBSOLETO
scheduler_pod_scheduling_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
Da 1.25.1 a 1.29 (1.22.17-gke.3100+, 1.23.11+, e 1.24.5+ per le versioni secondarie precedenti) 		[Ritirato nella versione 1.29; rimossa nella versione 1.30 e sostituita con scheduler_pod_scheduling_sli_duration_seconds. La latenza E2e per un pod da pianificare, che può includere più tentativi di pianificazione.

attempts
scheduler_pod_scheduling_sli_duration_seconds BETA
scheduler_pod_scheduling_sli_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
Più di 1,30 		La latenza E2e per un pod da pianificare, dal momento in cui il pod entra nella coda di pianificazione, potrebbe comportare più tentativi di pianificazione.

attempts
scheduler_preemption_attempts_total GA
scheduler_preemption_attempts_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		Tentativi di prerilascio totali nel cluster finora
scheduler_preemption_victims GA
scheduler_preemption_victims/histogram
Cumulative, Distribution, 1
prometheus_target
1.22.13+ 		Numero di vittime selezionate per prerilascio
scheduler_scheduling_attempt_duration_seconds GA
scheduler_scheduling_attempt_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.23.6+ 		Latenza dei tentativi di pianificazione in secondi (algoritmo di pianificazione + .

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

profile
result

Le seguenti sezioni forniscono informazioni aggiuntive sul server API metrics.

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 la necessità di ricorrere alle risorse per risolvere problemi di produzione e facilità d'uso. Lo scheduler ha tre code e questa metrica indica il numero di richieste in attesa per coda. Sono supportate le seguenti code:

  • Coda di active
    • Il set di pod che lo scheduler sta tentando di pianificare. il pod con la priorità più alta è in cima alla coda.
  • Coda di backoff
    • Il set di pod non era pianificabile l'ultima volta che lo scheduler ha provato ma che potrebbero essere pianificabili la prossima volta.
    • I pod in questa coda devono attendere un periodo di backoff (massimo 10 secondi), dopodiché vengono spostati nuovamente in active per un altro tentativo di pianificazione. Per ulteriori informazioni sul la gestione della coda backoff vedere la richiesta di implementazione Problema di Kubernetes 75417.

  • unschedulable impostato

    • L'insieme di pod che lo scheduler ha tentato di pianificare, ma che non sono stati pianificabili. Posizionamento in questa coda potrebbe indicare problemi di idoneità o compatibilità nodi o la configurazione dei selettori dei nodi.

      Quando i vincoli delle risorse impediscono la pianificazione dei pod, questi vengono non è soggetta a gestione del backoff. Invece, quando un cluster è pieno, i pod non vengono pianificati e vengono messi in unscheduled in coda.

    • La presenza di pod non pianificati potrebbe indicare che hai risorse insufficienti o problemi di configurazione dei nodi. I pod vengono spostati in backoff o active dopo eventi che modificano lo stato del cluster. Pod in questa coda indicare che non è cambiato nulla nel cluster che renderebbe pianificabili dei pod.

    • Affinità e definire regole per l'assegnazione dei pod ai nodi. L'uso dell'affinità o regole di anti-affinità possono essere motivo di un aumento del traffico non pianificato dei pod.

    • Alcuni eventi, ad esempio AGGIUNTA/AGGIORNAMENTO PVC/servizio, terminazione di un pod o la registrazione di nuovi nodi, sposta alcuni o tutti i nodi non pianificati i pod alla coda backoff o active. Per ulteriori informazioni, vedi Problema di Kubernetes 81214.

Per maggiori informazioni, vedi 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 del scheduler stesso ed è suddiviso in base al risultato: programmato, non pianificabile o . La durata va dal momento in cui lo scheduler recupera un pod fino al momento in cui lo scheduler individua un nodo e posiziona il pod al suo interno, determina che il pod non sia pianificabile o che si verifichi un errore. La durata della pianificazione include il tempo del processo di pianificazione e l'ora di associazione. Associazione è il processo in cui lo scheduler comunica la sua assegnazione dei nodi API di Google Cloud. Per maggiori informazioni, consulta Latenza dello scheduler.

Questa metrica non registra quanto tempo il pod impiega nel controllo di ammissione dei dati.

Per ulteriori informazioni sulla pianificazione, vedi Pianificazione di un pod.

scheduler_schedule_attempts_total

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

Questa metrica è strettamente correlata al scheduler_pending_pods metrica: quando ci sono molti pod in attesa, puoi aspettarti di vedere molti tentativi e pianificare i pod. Per ulteriori informazioni, consulta la sezione Risorse .

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

scheduler_preemption_attempts_total e scheduler_preemptions_victims

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

Potresti avere pod con priorità più alta che non possono essere pianificati perché non sono spazio per loro. In questo caso, lo scheduler libera risorse anticipando una o più pod in esecuzione su un nodo. scheduler_preemption_attempts_total tiene traccia del 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 dell'attributo scheduler_schedule_attempts_total. metrica 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 prerilascio, ma potrebbero esserci tentativi di pianificazione che non vanno a buon fine.

Per maggiori informazioni, 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 scheduler.

Latenza scheduler

L'attività dello scheduler è assicurare che i pod vengano eseguiti, quindi quando lo scheduler è bloccato o rallentato.

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

  • Quando lo scheduler viene eseguito lentamente, esamina i 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 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° posto percentili. La seguente query PromQL recupera i valori del 95° percentile ma possono essere modificate:

      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 Google Cloud. Se il valore del parametro Metrica scheduler_preemption_attempts_total aumenta, quindi controlla il valore scheduler_preemption_victims utilizzando il seguente PromQL query:

scheduler_preemption_victims_sum{cluster="CLUSTER_NAME"}

Il numero di tentativi di prerilascio e il numero di vittime di prerilascio aumentano 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 prerilascio sono stati pianificati, quindi quando noti incrementi nel valore del prerilascio metriche, puoi anche monitorare il valore scheduler_pending_pods metrica. Se il numero di istanze in sospeso è in aumento, ma potresti non avere risorse sufficienti per gestire i pod con priorità più alta; potresti dover fare lo scale up delle risorse disponibili, creare nuovi pod con richieste di risorse ridotte o cambiare il selettore di nodi.

  • Se il numero delle vittime di prerilascio non aumenta, non ci sono pod rimanenti con bassa priorità che possono essere rimossi. In questo caso, ti consigliamo di aggiungere altri nodi in modo che i nuovi pod possano sono state assegnate.

  • Se il numero delle vittime di prerilascio aumenta, allora sono pod con priorità più alta in attesa di essere pianificati, quindi prerilasa alcuni dei pod in esecuzione. Le metriche di prerilascio non indicano se sono stati pianificati pod con priorità più elevata correttamente.

    Per determinare se i pod con priorità più alta sono pianificati, cerca i valori decrescenti di scheduler_pending_pods o una metrica di valutazione. Se il valore di questa metrica aumenta, puoi: aggiungere altri nodi.

È possibile che si verifichino picchi temporanei nei valori relativi ai valori scheduler_pending_pods metrica per i carichi di lavoro pianificato nel cluster, ad esempio durante eventi come aggiornamenti o scale. Se nel cluster disponi di risorse sufficienti, questi picchi sono temporanei. Se il numero di pod in attesa rimane invariato, segui questi passaggi:

  • Controlla che i nodi non siano contrassegnati come non pianificabili. i nodi non pianificati non accettano nuovi pod.
  • Controlla le seguenti istruzioni di pianificazione, che possono essere configurate in modo errato potrebbe rendere un pod non pianificabile:
    • Affinità dei nodi e selettore.
    • Incompatibilità e tolleranze.
    • Vincoli per la diffusione della topologia dei pod.

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

Metriche del gestore del controller

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

I nomi delle metriche di Cloud Monitoring in questa tabella devono essere preceduti dal prefisso prometheus.googleapis.com/. Questo prefisso è stato omesso dalla le voci nella tabella.

Nome metrica PromQL Fase di lancio
Nome metrica di Cloud Monitoring
Tipo, Tipo, Unità
Risorse monitorate
Versione GKE richiesta		 Descrizione
Etichette
node_collector_evictions_total GA
node_collector_evictions_total/counter
Cumulative, Double, 1
prometheus_target
Più di 1,24 		Numero di eliminazioni dei nodi avvenute dall'istanza attuale di NodeController avviato.

zone