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 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:
- Nel cluster devono essere attivate le metriche di sistema.
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 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:
-
Nella console Google Cloud, vai alla pagina Cluster Kubernetes:
Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Kubernetes Engine.
Fai clic sul nome del cluster e seleziona Osservabilità .
Seleziona Piano di controllo dall'elenco delle funzionalità.
Fai clic su Abilita 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:
-
Nella console Google Cloud, vai alla pagina Cluster Kubernetes:
Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Kubernetes Engine.
Fai clic sul nome del cluster.
Nella riga Funzionalità con etichetta Cloud Monitoring, Fai clic sull'icona Modifica.
Nella finestra di dialogo Modifica monitoraggio cloud visualizzata, verifica che sia selezionata l'opzione Abilita monitoraggio cloud.
Nel menu a discesa Componenti, seleziona i componenti del piano di controllo da cui vuoi raccogliere le metriche: API Server, Scheduler o Controller Manager.
Fai clic su OK.
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:
CLUSTER_NAME
: il nome del cluster.COMPUTE_LOCATION
: il Località di Compute Engine nel cluster.
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
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 senza costi per i cluster registrati che appartengono a un progetto in cui è abilitata la versione GKE Enterprise.
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
.
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, 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). È 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 ogni nome di 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 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 server API
Questa sezione fornisce un elenco delle metriche del server API e informazioni aggiuntive 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 dalle voci della tabella.
Nome metrica PromQL Fase di lancio Nome metrica di Cloud Monitoring |
|
---|---|
Tipo, Tipo, Unità
Risorse monitorate Versione GKE obbligatoria |
Descrizione Etichette |
apiserver_current_inflight_requests
GAapiserver_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
BETAapiserver_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
BETAapiserver_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
BETAapiserver_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 sessioni di esecuzione configurate per ogni livello di priorità.priority_level
|
apiserver_flowcontrol_rejected_requests_total
BETAapiserver_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
BETAapiserver_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
GAapiserver_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
GAapiserver_request_total/counter
|
|
Cumulative , Double , 1
prometheus_target 1.22.13 e versioni successive |
Contatore delle richieste di 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
GAapiserver_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, sottorisorsa, ambito e componente.component
group
resource
scope
subresource
verb
version
|
apiserver_storage_objects
GAapiserver_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
GAapiserver_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
GAapiserver_admission_step_admission_duration_seconds/histogram
|
|
Cumulative , Distribution , s
prometheus_target 1.22.13 e versioni successive |
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
GAapiserver_admission_webhook_admission_duration_seconds/histogram
|
|
Cumulative , Distribution , s
prometheus_target 1.22.13 e versioni successive |
Istogramma della latenza del webhook di ammissione in secondi, identificato dal nome e
per ogni operazione e risorsa dell'API e tipo (convalida
ammettere).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:
- Autenticazione e 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 daetcd
(per tutte le altre richieste). - Puoi utilizzare le etichette
group
,version
,resource
esubresource
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. 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
webhook di terze parti. Per diagnosticare i problemi di latenza su Webook di terze parti, utilizza
il
apiserver_admission_webhook_admission_duration_seconds
in un file di dati.
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 al server API. Puoi anche utilizzarlo per determinare le percentuali 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 il raggruppamento per identificare le sorgenti di errore.
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 gestire 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 è sovraccaricato, 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
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 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, guarda l'
apiserver_request_total
eapiserver_storage_objects
metriche di valutazione.- 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
, esubresource
per identificare in modo univoco una richiesta.
- Utilizza l'etichetta
Un webhook di ammissione di terze parti è lento o non reattivo. 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 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 per la metrica
apiserver_admission_webhook_admission_duration_seconds
per ricevere un avviso quando ti stai avvicinando al timeout del webhook.Puoi anche raggruppare
apiserver_admission_webhook_admission_duration_seconds
sull'etichettaname
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, 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 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.
Per ulteriori informazioni, consulta Buone pratiche per l'utilizzo di Priorità e 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 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 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 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
metriche di valutazione.
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 sta registrando 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, consulta
Priorità e equità dell'API.
Metriche 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 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 obbligatoria |
Descrizione Etichette |
kube_pod_resource_limit
GAkube_pod_resource_limit/gauge
|
|
Gauge , Double , 1
prometheus_target 1.31.1-gke.1621000+ |
Limite di risorse per i carichi di lavoro sul cluster, suddivisi per pod.
Mostra l'utilizzo delle risorse previsto dallo scheduler e da kubelet per ogni pod per la risorsa, nonché l'eventuale unità della risorsa.namespace
node
pod
priority
resource
scheduler
unit
|
kube_pod_resource_request
GAkube_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 che lo scheduler e il kubelet si aspettano per pod
e l'eventuale unità della risorsa.namespace
node
pod
priority
resource
scheduler
unit
|
scheduler_pending_pods
GAscheduler_pending_pods/gauge
|
|
Gauge , Double , 1
prometheus_target 1.22.13+ |
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
OBSOLETOscheduler_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
BETAscheduler_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
GAscheduler_preemption_attempts_total/counter
|
|
Cumulative , Double , 1
prometheus_target 1.22.13 e versioni successive |
Tentativi di prerilascio totali nel cluster finora |
scheduler_preemption_victims
GAscheduler_preemption_victims/histogram
|
|
Cumulative , Distribution , 1
prometheus_target 1.22.13+ |
Numero di vittime selezionate per prerilascio |
scheduler_scheduling_attempt_duration_seconds
GAscheduler_scheduling_attempt_duration_seconds/histogram
|
|
Cumulative , Distribution , 1
prometheus_target 1.23.6+ |
Latenza del tentativo di pianificazione in secondi (algoritmo di pianificazione +
associazione).profile
result
|
scheduler_schedule_attempts_total
GAscheduler_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 "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 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:
active
coda- 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
- 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 nuovamente in
active
per un altro tentativo di pianificazione. Per ulteriori informazioni sul la gestione della codabackoff
vedere la richiesta di implementazione Problema di Kubernetes 75417.
unschedulable
impostatoL'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 vengono non sono soggette a gestione del backoff. 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 problemi di configurazione dei nodi. I pod vengono spostati nella coda
backoff
oactive
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
oactive
. 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 l'ora di associazione. Il binding è la procedura in cui lo scheduler comunica l'assegnazione dei nodi al server API. Per maggiori informazioni, consulta Latenza dello scheduler.
Questa metrica non acquisisce il tempo che 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 è 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 la sezione 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 prerilascio 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 anticipando una
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 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 non ha nodi, non vengono eseguiti tentativi di prelazione, ma potrebbero verificarsi tentativi di pianificazione non riusciti.
Per ulteriori informazioni, consulta Problemi relativi alle risorse.
Monitoraggio dello scheduler
Le metriche del programmatore possono fornirti informazioni sul rendimento del programmatore:
- Latenza dello scheduler: lo scheduler è in esecuzione? Quanto tempo occorre per pianificare i pod?
- Problemi relativi alle risorse: sono tentativi di pianificare i pod rispetto ai vincoli delle risorse?
Questa sezione descrive come utilizzare la metrica pianificatore per monitorare il pianificatore.
Latenza 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
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 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 prelazione e il numero di vittime della prelazione entrambi
aumentano quando ci sono pod con priorità più elevata 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 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 dei nodi.
Se il numero delle vittime di prerilascio non aumenta, 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 schedulatore sta sostituendo 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ù elevata vengono pianificati, cerca i valori in diminuzione della metrica
scheduler_pending_pods
. Se il valore di questa metrica è in aumento, potrebbe essere necessario 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 non diminuisce, svolgi i seguenti passaggi:
- Controlla che i nodi non siano contrassegnati come non pianificabili. i nodi non pianificati 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 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 avere il prefisso prometheus.googleapis.com/
. Questo prefisso è stato omesso dalle voci della tabella.
Nome metrica PromQL Fase di lancio Nome metrica di Cloud Monitoring |
|
---|---|
Tipo, Tipo, Unità
Risorse monitorate Versione GKE obbligatoria |
Descrizione Etichette |
node_collector_evictions_total
GAnode_collector_evictions_total/counter
|
|
Cumulative , Double , 1
prometheus_target 1.24 e versioni successive |
Numero di eliminazioni dei nodi avvenute dall'istanza attuale di
NodeController avviato.zone
|