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 dal server API Kubernetes, dall'agente di pianificazione e dal gestore dei controller a Cloud Monitoring utilizzando Google Cloud Managed Service per Prometheus. Questa pagina descrive anche come vengono formattate queste metriche quando vengono scritte in Monitoraggio 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à, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.

Requisiti

L'invio delle metriche emesse dai componenti del piano di controllo Kubernetes a Cloud Monitoring presenta i seguenti requisiti:

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 attivare le metriche del piano di controllo per un cluster dalla scheda Osservabilità del cluster o dalla scheda Dettagli del cluster. Quando utilizzi la scheda Osservabilità, puoi visualizzare l'anteprima dei grafici e delle metriche disponibili prima di attivare il pacchetto di metriche.

Per attivare le metriche del piano di controllo dalla scheda Osservabilità per il cluster:

  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 la scheda Osservabilità.

  3. Seleziona Control Plane dall'elenco delle funzionalità.

  4. Fai clic su Attiva pacchetto.

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

Per attivare 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à etichettata Monitoraggio cloud, fai clic sull'icona Modifica.

  4. Nella finestra di dialogo Modifica monitoraggio cloud visualizzata, verifica che sia selezionata l'opzione Abilita monitoraggio cloud.

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

  6. Fai clic su OK.

  7. Fai clic su Salva modifiche.

gcloud

Aggiorna il cluster per raccogliere le metriche emesse dall'API server, dall'scheduler e dal gestore dei controller di Kubernetes:

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

Sostituisci quanto segue:

Terraform

Per configurare la raccolta delle metriche del piano di controllo Kubernetes utilizzando Terraform, consulta il blocco monitoring_config nel registry 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 utilizzano la quota "Richieste di importazione delle serie temporali al minuto" dell'API Cloud Monitoring. Prima di attivare i pacchetti di metriche, controlla l'utilizzo massimo recente della quota. Se hai molti cluster nello stesso progetto o stai già avvicinandoti a questo limite di quota, puoi richiedere un aumento del limite di quota prima di attivare uno dei 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. Gli addebiti di Cloud Monitoring per l'importazione di queste metriche si basano sul numero di campioni importati. Tuttavia, queste metriche sono senza costi per i cluster registrati che appartengono a un progetto in cui è abilitata la versione GKE Enterprise.

Per maggiori informazioni, consulta Prezzi di Cloud Monitoring.

Formato della metrica

Tutte le metriche del piano di controllo Kubernetes scritte in Cloud Monitoring utilizzano il tipo di risorsa prometheus_target. A ogni nome della metrica è associato 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 di Kubernetes vengono importate utilizzando Google Cloud Managed Service per Prometheus, è possibile eseguire query sulle metriche del piano di controllo di Kubernetes utilizzando Prometheus Query Language (PromQL). È anche possibile eseguire query utilizzando Monitoring Query Language (MQL).

Eseguire 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 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 Cloud Monitoring Quando utilizzi altre funzionalità di Cloud Monitoring, utilizza il nome della metrica Cloud Monitoring riportato nelle tabelle seguenti. A questo nome deve essere anteposto il 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 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.

Nome della metrica PromQL Fase di lancio
Nome della metrica Cloud Monitoring
Tipo, Tipo, Unità
Risorse monitorate
Versione GKE obbligatoria		 Descrizione
Etichette
apiserver_current_inflight_requests GA
apiserver_current_inflight_requests/gauge
Gauge, Double, 1
prometheus_target
1.22.13 e versioni successive 		Numero massimo di richieste in attesa attualmente utilizzate 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 		Concorrenza (numero di posti) occupata dalle richieste in esecuzione (fase iniziale per un WATCH, qualsiasi fase in caso contrario) nel sottosistema di priorità e 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+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ per le versioni minori precedenti) 		Numero di richieste attualmente in attesa nelle code del sottosistema di priorità e equità dell'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 o versioni successive (1.26.11 o versioni successive, 1.27.8 o versioni successive per le versioni minori precedenti) 		Numero nominale di sessioni 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+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ per le versioni minori precedenti) 		Numero di richieste rifiutate dal sottosistema di priorità e equità dell'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+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ per le versioni minori precedenti) 		Tempo di attesa di una richiesta nella coda.

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

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 e versioni successive 		Istogramma della latenza del sottopassaggio di ammissione in secondi, suddiviso per ogni operazione, 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 e versioni successive 		Istogramma della latenza dei webhook di ammissione in secondi, identificato per nome e suddiviso per ogni operazione, risorsa e tipo di API (convalida o ammissione).

name
operation
rejected
type

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 fino al momento in cui il server completa la risposta al client. Nello specifico, include il tempo impiegato per:

  • L'autenticazione e l'autorizzazione della richiesta.
  • Chiamate agli 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 da etcd (per tutte le altre richieste).
  • Puoi utilizzare le etichette group, version, resource e subresource per identificare in modo univoco una richiesta lenta da esaminare ulteriormente.
  • Scrivere la risposta al cliente e ricevere la risposta del cliente.

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

Questa metrica ha una cardinalità molto elevata. Quando utilizzi questa metrica, devi utilizzare i filtri o i raggruppamenti per trovare origini specifiche della 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 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 nei webhook di ammissione esterni di terze parti. La metrica apiserver_admission_webhook_admission_duration_seconds è in genere la più utile. Per ulteriori informazioni sull'utilizzo di questa metrica, consulta Latenza.

apiserver_request_total

Utilizza questa metrica per monitorare il traffico delle richieste sul server API. Puoi anche utilizzarlo per determinare i tassi di successo e di errore delle richieste. Per ulteriori informazioni sull'utilizzo di questa metrica, consulta Traffico e tasso di errore.

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

apiserver_storage_objects

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

apiserver_current_inflight_requests

Questa metrica registra il numero massimo di richieste in fase di elaborazione nell'ultima finestra di un secondo. Per ulteriori informazioni, consulta la sezione Saturazione.

La metrica non include le richieste di lunga durata come "watch".

Monitoraggio del server API

Le metriche del server API possono fornirti informazioni sui principali indicatori relativi al funzionamento del sistema:

  • Latenza: quanto tempo occorre per elaborare 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 è sovraccaricato, la latenza delle richieste aumenta. Per misurare la latenza delle richieste al server API, utilizza la metrica apiserver_request_duration_seconds. Per identificare più specificamente la fonte 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 1 secondo. Il limite superiore suggerito per le chiamate LIST con ambito a livello di spazio dei nomi e di cluster è 30 secondi. Le aspettative di limite superiore sono impostate dagli SLO definiti dalla community Kubernetes open source. Per ulteriori informazioni, consulta Dettagli su SLI/SLO relativi alla 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 sovraccaricato. Per verificare, controlla 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 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 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 query sulla latenza del 99° percentile del webhook 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 percentile 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 un avviso quando ti stai avvicinando al timeout del webhook.

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

  • Stai elencando molti oggetti. È normale che la latenza delle chiamate LIST aumenti con l'aumento del 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, controlla le metriche di utilizzo della CPU per il pod del cliente.
    • Il client ha una connessione di rete lenta. Questo può accadere quando il client è in esecuzione su un dispositivo come un cellulare, ma è improbabile che si verifichi 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 ulteriori informazioni, consulta Buone pratiche per l'utilizzo della priorità e dell'equità dell'API nella documentazione di Kubernetes.

Traffico e percentuale di 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 piano di controllo 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 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 del 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 controllo 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 registrando l'aumento.

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

Metriche di Scheduler

Questa sezione fornisce un elenco delle metriche del programmatore e informazioni aggiuntive sull'interpretazione e sull'utilizzo delle metriche.

Elenco delle metriche dello scheduler

Quando le metriche del programmatore 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.

Nome della metrica PromQL Fase di lancio
Nome della metrica Cloud Monitoring
Tipo, Tipo, Unità
Risorse monitorate
Versione GKE obbligatoria		 Descrizione
Etichette
kube_pod_resource_limit GA
kube_pod_resource_limit/gauge
Gauge, Double, 1
prometheus_target
1.31.1-gke.1621000+ 		Limite di risorse per i carichi di lavoro sul cluster, suddiviso per pod. Mostra l'utilizzo delle risorse previsto dallo scheduler e da kubelet per ogni pod per la risorsa, insieme all'eventuale unità della risorsa.

namespace
node
pod
priority
resource
scheduler
unit
kube_pod_resource_request GA
kube_pod_resource_request/gauge
Gauge, Double, 1
prometheus_target
1.31.1-gke.1621000+ 		Risorse richieste dai carichi di lavoro sul cluster, suddivise per pod. Mostra l'utilizzo delle risorse previsto dallo scheduler e da kubelet per ogni pod per la risorsa, insieme all'eventuale unità della risorsa.

namespace
node
pod
priority
resource
scheduler
unit
scheduler_pending_pods GA
scheduler_pending_pods/gauge
Gauge, Double, 1
prometheus_target
1.22.13 e versioni successive 		Numero di pod in attesa, per tipo di coda. "active" indica il numero di pod in activeQ; "backoff" indica il numero di pod in backoffQ; "unschedulable" 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 minori precedenti) 		[Ritirata nella versione 1.29; rimossa nella versione 1.30 e sostituita da scheduler_pod_scheduling_sli_duration_seconds.] Latenza E2E per un pod in fase di pianificazione 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
1.30 e versioni successive 		Latenza E2E per un pod in fase di pianificazione, dal momento in cui il pod entra nella coda di pianificazione e 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 e versioni successive 		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 e versioni successive 		Numero di vittime dell'anticipo selezionate
scheduler_scheduling_attempt_duration_seconds GA
scheduler_scheduling_attempt_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.23.6 e 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 e versioni successive 		Numero di tentativi di pianificazione dei pod, in base al risultato. "Non pianificabile" significa che non è stato possibile pianificare un pod, mentre "errore" significa un problema interno dello scheduler.

profile
result

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 programmatore. 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 coda
    • L'insieme di pod che lo scheduler sta tentando di pianificare. Il pod con la priorità più alta è in testa alla coda.
  • backoff coda
    • 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 Kubernetes 75417.

  • unschedulable impostato

    • L'insieme di pod che lo scheduler ha tentato di pianificare, ma che sono stati ritenuti non pianificabili. La presenza di un placement in questa coda potrebbe indicare problemi di idoneità o compatibilità con i 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 back-off. Invece, quando un cluster è pieno, i nuovi pod non vengono pianificati e vengono inseriti nella coda unscheduled.

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

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

    • Alcuni eventi, ad esempio l'AGGIUNTA/l'AGGIORNAMENTO di PVC/servizi, l'interruzione 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 Kubernetes 81214.

Per ulteriori informazioni, consulta Latenza dell'organizzatore e Problemi relativi alle risorse.

scheduler_scheduling_attempt_duration_seconds

Questa metrica misura la durata di un singolo tentativo di pianificazione all'interno dello stesso programmatore ed è suddivisa in base al risultato: pianificato, non pianificabile o errore. 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 sul nodo, determina che il pod non è pianificabile o rileva un errore. La durata della pianificazione include il tempo del processo di pianificazione e il tempo di vincolo. Il binding è la procedura in cui lo scheduler comunica l'assegnazione dei nodi al server API. Per ulteriori informazioni, consulta Latenza dell'organizzatore.

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

Per ulteriori informazioni sulla pianificazione, consulta 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 il programma è disponibile: se il valore aumenta, significa che il programma è operativo. Puoi utilizzare l'etichetta result per determinare il successo; i pod sono scheduled o unschedulable.

Questa metrica è fortemente correlata alla metrica scheduler_pending_pods: quando sono presenti molti pod in attesa, puoi aspettarti di vedere molti tentativi di pianificazione dei pod. Per ulteriori informazioni, consulta Problemi con le risorse.

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

scheduler_preemption_attempts_total e scheduler_preemptions_victims

Puoi utilizzare le metriche di prelazione 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 risorse sostituendo 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 l'anticipazione dei pod.

La metrica scheduler_preemptions_victims conteggia i pod selezionati per la prelazione.

Il numero di tentativi di prelazione è fortemente 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 non ha nodi, non vengono eseguiti tentativi di prelazione, ma potrebbero verificarsi tentativi di pianificazione non riusciti.

Per ulteriori informazioni, vedi Problemi relativi alle risorse.

Monitoraggio del programmatore

Le metriche del programmatore possono fornirti informazioni sul rendimento del programmatore:

Questa sezione descrive come utilizzare la metrica pianificatore per monitorare il pianificatore.

Latenza dello scheduler

Il compito dello scheduler è garantire l'esecuzione dei pod, quindi devi sapere quando lo scheduler è bloccato o funziona lentamente.

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

  • Quando la pianificazione 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 ai 50° e 95° percentile. La seguente query PromQL recupera i valori del percentile 95, 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 del programmatore 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 prelazione e il numero di vittime della prelazione entrambi aumentano quando ci sono pod con priorità più elevata da pianificare. Le metriche di preemption non indicano se i pod ad alta priorità che hanno attivato le preemption sono stati pianificati, pertanto, quando noti aumenti nel valore delle metriche di preemption, puoi anche monitorare il valore della metrica scheduler_pending_pods. Se anche il numero di pod in attesa è in aumento, potresti non avere risorse sufficienti per gestire i pod con priorità più elevata. 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 della preemption non aumenta, significa che non ci sono pod rimanenti con priorità bassa che possono essere rimossi. In questo caso, valuta la possibilità di aggiungere altri nodi in modo da poter allocare i nuovi pod.

  • Se il numero di vittime della preemption è in aumento, significa che esistono pod con priorità più elevata in attesa di essere pianificati, quindi lo scheduler sta sostituendo alcuni dei pod in esecuzione. Le metriche di prelazione 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 in diminuzione della metrica scheduler_pending_pods. Se il valore di questa metrica è in aumento, potrebbe essere necessario aggiungere altri nodi.

Quando i workload verranno pianificati nel cluster, ad esempio durante eventi come aggiornamenti o ridimensionamenti, puoi aspettarti di vedere picchi temporanei nei valori della metrica scheduler_pending_pods. Se il cluster dispone di risorse sufficienti, questi picchi sono temporanei. Se il numero di pod in attesa non diminuisce, svolgi i seguenti passaggi:

  • Verifica che i nodi non siano messi in isolamento, in quanto 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 di aumentare il numero di nodi.

Metriche di Controller Manager

Quando le metriche del 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.

Nome della metrica PromQL Fase di lancio
Nome della metrica Cloud Monitoring
Tipo, Tipo, Unità
Risorse monitorate
Versione GKE obbligatoria		 Descrizione
Etichette
node_collector_evictions_total GA
node_collector_evictions_total/counter
Cumulative, Double, 1
prometheus_target
1.24 e versioni successive 		Numero di espulsioni di nodi avvenute dall'avvio dell'istanza corrente di NodeController.

zone