Questa pagina descrive come configurare un cluster Google Kubernetes Engine (GKE) per inviare a Cloud Monitoring le metriche emesse dal server API, dallo scheduler e dal gestore del controller Kubernetes utilizzando Google Cloud Managed Service per Prometheus. Questa pagina descrive anche la formattazione di queste metriche quando vengono scritte in Monitoring e come eseguire query sulle metriche.
Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti attività:
- Abilita l'API Google Kubernetes Engine. Abilita l'API Google Kubernetes Engine
- Se vuoi utilizzare Google Cloud CLI per questa attività, installa e quindi initialize 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 prevede i seguenti requisiti:
- Nel cluster devono essere abilitate 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 dalla scheda Osservabilità per il cluster o dalla scheda Dettagli per il cluster. Quando utilizzi la scheda Osservabilità, puoi visualizzare l'anteprima dei grafici e delle metriche disponibili prima di abilitare il pacchetto di metriche.
Per abilitare le metriche del piano di controllo dalla scheda Osservabilità per il cluster, segui questi passaggi:
-
Nella console Google Cloud, vai alla pagina Cluster Kubernetes:
Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato il cui sottotitolo è Kubernetes Engine.
Fai clic sul nome del cluster e seleziona la scheda 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 abilitare le metriche del piano di controllo dalla scheda Dettagli per il cluster, segui questi passaggi:
-
Nella console Google Cloud, vai alla pagina Cluster Kubernetes:
Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato il cui 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 Cloud Monitoring visualizzata, verifica che sia selezionata l'opzione Abilita Cloud Monitoring.
Nel menu a discesa Componenti, seleziona i componenti del piano di controllo da cui vuoi raccogliere le metriche: Server API, Scheduler o Controller Manager.
Fai clic su Ok.
Fai clic su Salva modifiche.
gcloud
Aggiorna il cluster per raccogliere le metriche emesse dal server API, dallo scheduler e dal gestore del controller 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
: la località Compute Engine del cluster.
Terraform
Per configurare la raccolta delle metriche del piano di controllo Kubernetes mediante Terraform, consulta il blocco monitoring_config
nel
registro Terraform per google_container_cluster
.
Per informazioni generali sull'utilizzo di Google Cloud con Terraform, consulta
Terraform with Google Cloud.
Quota
Le metriche del piano di controllo consumano la quota "Richieste di importazione di serie temporali al minuto" dell'API Cloud Monitoring. Prima di abilitare i pacchetti di metriche, controlla l'utilizzo recente recente di quella quota. Se hai molti cluster nello stesso progetto o se stai già raggiungendo il limite di quota, puoi richiedere un aumento del limite della quota prima di abilitare uno dei due pacchetti di osservabilità.
Prezzi
Le metriche del piano di controllo GKE utilizzano Google Cloud Managed Service per Prometheus per caricare le metriche in Cloud Monitoring. Gli addebiti di Cloud Monitoring per l'importazione di queste metriche si basano sul numero di campioni importati. Tuttavia, queste metriche sono gratuite per i cluster registrati che appartengono a un progetto in cui è abilitata la versione di GKE Enterprise.
Per ulteriori informazioni, consulta i prezzi di Cloud Monitoring.
Formato metrica
Tutte le metriche del piano di controllo Kubernetes Kubernetes scritte in Cloud Monitoring
utilizzano il tipo di risorsa
prometheus_target
.
Ogni nome della metrica è preceduto dal prefisso prometheus.googleapis.com/
e da un suffisso che indica il tipo di metrica Prometheus, ad esempio /gauge
, /histogram
o /counter
. In caso contrario, ogni nome di metrica è identico a quello 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). È inoltre possibile eseguire query utilizzando tramite Monitoring Query Language (MQL).
Esecuzione di query sulle metriche
Quando esegui una query sulle metriche del piano di controllo Kubernetes, il nome da utilizzare dipende dall'utilizzo di funzionalità basate su PromQL o 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 del nome di ogni metrica:
- Nome 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 metrica di Cloud Monitoring Se usi altre
funzionalità di Cloud Monitoring, usa il nome della metrica
nelle tabelle riportate di seguito. Questo nome deve essere preceduto dal prefisso
prometheus.googleapis.com/
, che è stato omesso dalle voci della tabella.
Metriche server API
Questa sezione fornisce un elenco di 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 seguente tabella vengono esportate in Cloud Monitoring nello stesso progetto del 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 Cloud Monitoring |
|
---|---|
Tipo, Tipo, Unità
Risorse monitorate Versione GKE richiesta |
Descrizione Etichette |
apiserver_current_inflight_requests
GAapiserver_current_inflight_requests/gauge
|
|
Gauge , Double , 1
prometheus_target 1.22.13 o versioni successive |
Numero massimo di limiti di richieste in corso attualmente in uso di questo apiserver per tipo di richiesta nell'ultimo secondo.request_kind
|
apiserver_flowcontrol_current_executing_seats
BETAapiserver_flowcontrol_current_executing_seats/gauge
|
|
Gauge , Double , 1
prometheus_target 1.28.3 o versioni successive |
Richieste di contemporaneità (numero di utenze) occupate dalle richieste attualmente in esecuzione (fase iniziale per un WATCH, qualsiasi fase altrimenti) nel sottosistema Priorità e Equità delle API.flow_schema
priority_level
|
apiserver_flowcontrol_current_inqueue_requests
BETAapiserver_flowcontrol_current_inqueue_requests/gauge
|
|
Gauge , Double , 1
prometheus_target 1.28.3 e versioni successive (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ per le versioni secondarie precedenti) |
Numero di richieste attualmente in attesa nelle code del sottosistema Priorità e Equità delle API.flow_schema
priority_level
|
apiserver_flowcontrol_nominal_limit_seats
BETAapiserver_flowcontrol_nominal_limit_seats/gauge
|
|
Gauge , Double , 1
prometheus_target 1.28.3 e versioni successive (1.26.11 e versioni successive, 1.27.8 e versioni successive per le versioni secondarie precedenti) |
Numero nominale di utenze di esecuzione configurate per ogni livello di priorità.priority_level
|
apiserver_flowcontrol_rejected_requests_total
BETAapiserver_flowcontrol_rejected_requests_total/counter
|
|
Cumulative , Double , 1
prometheus_target 1.28.3 e versioni successive (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ per le versioni secondarie precedenti) |
Numero di richieste rifiutate dal sottosistema Priorità e Equità delle API.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 e versioni successive (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 o versioni successive |
Distribuzione della latenza di risposta in secondi per ogni verbo, valore dry run, gruppo, versione, risorsa, sottorisorsa, 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 o versioni successive |
Contatore di richieste apiserver suddivise per 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
GAapiserver_response_sizes/histogram
|
|
Cumulative , Distribution , 1
prometheus_target 1.22.13 o 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
GAapiserver_storage_objects/gauge
|
|
Gauge , Double , 1
prometheus_target 1.22.13 o versioni successive |
Numero di oggetti archiviati al momento dell'ultimo controllo, suddivisi per tipo.resource
|
apiserver_admission_controller_admission_duration_seconds
GAapiserver_admission_controller_admission_duration_seconds/histogram
|
|
Cumulative , Distribution , s
prometheus_target 1.23.6 o versioni successive |
Istogramma della latenza del controller di ammissione in secondi, identificato per nome e suddiviso per ciascuna operazione e risorsa e tipo 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 o versioni successive |
Istogramma della latenza dei passaggi secondari di ammissione in secondi, suddiviso per
ciascuna operazione e risorsa API e tipo di passaggio (convalida o ammissione).operation
rejected
type
|
apiserver_admission_webhook_admission_duration_seconds
GAapiserver_admission_webhook_admission_duration_seconds/histogram
|
|
Cumulative , Distribution , s
prometheus_target 1.22.13 o versioni successive |
Istogramma della latenza del webhook di ammissione in secondi, identificato per nome e suddiviso per ciascuna operazione e risorsa e tipo dell'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 dell'elaborazione della richiesta, dal momento in cui la richiesta viene ricevuta fino a quando il server completa la risposta al client. Nello specifico, include il tempo dedicato a:
- 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 specificano un parametro URL
resourceVersion
) o daetcd
(per tutte le altre richieste). - Puoi utilizzare le etichette
group
,version
,resource
esubresource
per identificare in modo in modo univoco una richiesta lenta per ulteriori indagini. - Scrivere la risposta al cliente e riceverla.
Per ulteriori informazioni sull'utilizzo di questa metrica, consulta Latenza.
Questa metrica ha una cardinalità molto elevata. Quando utilizzi questa metrica, devi usare filtri o raggruppamenti per trovare specifiche sorgenti 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 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.
In genere, la metrica apiserver_admission_webhook_admission_duration_seconds
è quella più utile. Per ulteriori informazioni sull'utilizzo di questa metrica, consulta Latenza.
apiserver_request_total
Utilizza questa metrica per monitorare il traffico delle richieste al server API. Puoi utilizzarlo anche per determinare le percentuali di successo e di errore delle tue richieste. Per scoprire di più sull'utilizzo di questa metrica, consulta Traffico ed errori.
Questa metrica ha una cardinalità molto elevata. Quando utilizzi questa metrica, devi usare filtri o raggruppamenti per identificare le origini degli errori.
apiserver_storage_objects
Utilizza questa metrica per rilevare la saturazione del sistema e identificare possibili perdite di risorse. Per ulteriori informazioni, consulta la sezione Saturazione.
apiserver_current_inflight_requests
Questa metrica registra il numero massimo di richieste pubblicate attivamente nell'ultimo secondo. Per ulteriori informazioni, consulta la sezione 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 l'integrità del sistema:
- Latenza: quanto tempo è necessario per gestire una richiesta?
- Traffico: quanta domanda sta subendo il sistema?
- 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 la latenza delle richieste al server API, utilizza la metrica apiserver_request_duration_seconds
. Per identificare l'origine della latenza in modo più specifico, 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 cluster è di 30 secondi. Le aspettative superiori sono impostate da SLO definiti dalla community open source Kubernetes; per ulteriori informazioni, consulta Dettagli SLI/SLO di latenza delle chiamate API.
Se il valore della metrica apiserver_request_duration_seconds
aumenta oltre la durata prevista, verifica le seguenti possibili cause:
- Il piano di controllo Kubernetes potrebbe essere sovraccarico. Per controllare, osserva le metriche
apiserver_request_total
eapiserver_storage_objects
.- Utilizza l'etichetta
code
per determinare se le richieste vengono elaborate correttamente. Per informazioni sui possibili valori, consulta la pagina sui codici di stato HTTP. - Utilizza le etichette
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
aumenta, alcuni dei webhook di ammissione di terze parti o definiti dall'utente sono lenti o non adattabili. La latenza nel webhook di ammissione può causare ritardi nella pianificazione dei job.Per eseguire query sulla latenza webhook al 99° percentile per istanza del piano di controllo Kubernetes, utilizza la seguente query PromQL:
sum by (instance) (histogram_quantile(0.99, rate(apiserver_admission_webhook_admission_duration_seconds_bucket{cluster="CLUSTER_NAME"}[1m])))
Ti consigliamo di esaminare anche il 50°, 90°, 95° e 99, 9° percentile.Puoi modificare questa query modificando il valore
0.99
.I webhook esterni hanno un limite di timeout di circa 10 secondi. Puoi impostare criteri di avviso nella metrica
apiserver_admission_webhook_admission_duration_seconds
per ricevere un avviso quando ti stai avvicinando al timeout del webhook.Puoi anche raggruppare la metrica
apiserver_admission_webhook_admission_duration_seconds
sull'etichettaname
per diagnosticare possibili problemi con webhook specifici.
Stai elencando molti oggetti. Si prevede 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 cliente potrebbe non disporre di risorse sufficienti per ricevere risposte tempestive. Per verificarlo, guarda le metriche di utilizzo della CPU per il pod client.
- La connessione di rete del client è lenta. Questo può accadere quando il client è in esecuzione su un dispositivo come un cellulare, ma è improbabile per i client in esecuzione su una rete Compute Engine.
- Il client si è chiuso inaspettatamente, ma la connessione TCP ha un periodo di timeout di decine di secondi. Prima che la connessione scada, le risorse del server vengono 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 al
server API, utilizza la
metrica apiserver_request_total
. Ad esempio, per misurare il traffico del server API per istanza del piano di controllo Kubernetes, utilizza la seguente query PromQL:
sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME"}[1m]))
Per eseguire una query sulle richieste non riuscite, filtra l'etichetta
code
in base ai 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
in base ai 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 ogni istanza del piano di controllo Kubernetes, filtra l'etichetta
code
in base al valore 429 (http.StatusTooManyRequests
) utilizzando la seguente query PromQL:sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME", code="429"}[1m]))
Saturazione
Puoi misurare la saturazione nel sistema utilizzando le metriche apiserver_current_inflight_requests
e apiserver_storage_objects
.
Se il valore della metrica apiserver_storage_objects
aumenta, è possibile che tu stia riscontrando un problema con un controller personalizzato che crea oggetti ma non li elimina. Puoi filtrare o raggruppare la metrica in base all'etichetta resource
per identificare la risorsa che sta riscontrando o ha aumentato l'aumento.
Valuta la metrica apiserver_current_inflight_requests
in base alle tue impostazioni di Priorità e Equità delle API. Queste impostazioni influiscono sulla modalità di assegnazione della priorità delle richieste, pertanto non puoi trarre conclusioni dai soli valori della metrica. Per maggiori informazioni, consulta
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 del 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 Cloud Monitoring |
|
---|---|
Tipo, Tipo, Unità
Risorse monitorate Versione GKE richiesta |
Descrizione Etichette |
scheduler_pending_pods
GAscheduler_pending_pods/gauge
|
|
Gauge , Double , 1
prometheus_target 1.22.13 o 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; "non pianificabili" 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 versioni successive, e 1.24.5+ per le versioni secondarie precedenti) |
[Deprecata nella v. 1.29; rimossa nella v. 1.30 e sostituita da
scheduler_pod_scheduling_sli_duration_seconds .]
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 almeno 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
GAscheduler_preemption_attempts_total/counter
|
|
Cumulative , Double , 1
prometheus_target 1.22.13 o versioni successive |
Tentativi di prerilascio totali nel cluster finora |
scheduler_preemption_victims
GAscheduler_preemption_victims/histogram
|
|
Cumulative , Distribution , 1
prometheus_target 1.22.13 o versioni successive |
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 o versioni successive |
Pianificazione della latenza dei tentativi 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 o 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" indica un problema
dello scheduler interno.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
sullo scheduler. L'aumento dei valori in questa metrica può indicare problemi di gestione delle risorse. Lo scheduler ha tre code e questa metrica indica il numero di richieste in attesa per coda. Sono supportate le seguenti code:
- Coda
active
- Il set di pod che lo scheduler sta tentando di pianificare. Il pod con la priorità più alta si trova in cima alla coda.
- Coda
backoff
- L'insieme di pod non era pianificabile l'ultima volta che lo scheduler ha provato, ma potrebbe esserlo la volta successiva.
- I pod in questa coda devono attendere un periodo di backoff (massimo 10 secondi), dopodiché vengono riportati nella coda
active
per un altro tentativo di pianificazione. Per ulteriori informazioni sulla gestione della codabackoff
, consulta la richiesta di implementazione, problema di Kubernetes 75417.
unschedulable
impostatoL'insieme di pod che lo scheduler ha tentato di pianificare, ma che sono stati determinati come non pianificabili. Il posizionamento in questa coda potrebbe indicare problemi di idoneità o compatibilità con i nodi o con la configurazione dei selettori dei nodi.
Quando i vincoli delle risorse impediscono la pianificazione dei pod, questi non sono soggetti a gestione del backoff. Quando un cluster è pieno, i nuovi pod non 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 dei nodi. I pod vengono spostati nella coda
backoff
oactive
dopo eventi che modificano lo stato del cluster. I pod in questa coda indicano che nel cluster non è stato modificato nulla che renderebbe i pod pianificabili.Le affinità definiscono le regole per l'assegnazione dei pod ai nodi. L'uso di regole di affinità o anti-affinità può essere una delle cause di un aumento dei pod non pianificati.
Alcuni eventi, ad esempio ADD/UPDATE PVC/Service, la terminazione di un pod o la registrazione di nuovi nodi, spostano alcuni o tutti i pod non pianificati nella coda
backoff
oactive
. Per ulteriori informazioni, vedi Problema di Kubernetes 81214.
Per ulteriori informazioni, consulta Latenza dello scheduler e problemi relativi alle risorse.
scheduler_scheduling_attempt_duration_seconds
Questa metrica misura la durata di un singolo tentativo di pianificazione all'interno dello strumento di pianificazione e viene 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 se il pod non è pianificabile o riscontra un errore. La durata della pianificazione include il tempo del processo di pianificazione e l'ora di associazione. L'associazione è il processo in cui lo scheduler comunica la propria assegnazione dei nodi al server API. Per maggiori informazioni, consulta Latenza dello scheduler.
Questa metrica non registra il tempo impiegato dal pod per il controllo di ammissione o la convalida.
Per ulteriori informazioni sulla pianificazione, consulta Pianificazione di un pod.
scheduler_schedule_attempts_total
Questa metrica misura il numero di tentativi di pianificazione. Ogni tentativo di pianificare un pod aumenta il valore. Puoi utilizzare questa metrica per determinare se lo scheduler è disponibile: se il valore aumenta, lo scheduler è operativo. Puoi
utilizzare l'etichetta result
per determinare l'esito positivo; i pod sono
scheduled
o unschedulable
.
Questa metrica è strettamente correlata alla metrica scheduler_pending_pods
: quando i pod in attesa sono molti, è probabile che si verifichino molti tentativi di pianificazione dei pod. Per ulteriori informazioni, consulta Problemi relativi alle risorse.
Questa metrica non aumenta se lo scheduler non ha pod da pianificare, come può verificarsi se hai uno scheduler secondario personalizzato.
scheduler_preemption_attempts_total
e scheduler_preemptions_victims
Puoi utilizzare le metriche di prerilascio per determinare se devi aggiungere risorse.
Potresti avere pod con priorità più elevata che non possono essere pianificati perché non c'è spazio per questi pod. In questo caso, lo scheduler libera risorse prerilasciando uno o più pod in esecuzione su un nodo. La metrica scheduler_preemption_attempts_total
monitora il numero di volte in cui lo scheduler ha tentato di prerilasciare i pod.
La metrica scheduler_preemptions_victims
conteggia i pod selezionati
per il prerilascio.
Il numero di tentativi di prerilascio è strettamente correlato al valore della metrica scheduler_schedule_attempts_total
quando il valore dell'etichetta result
è unschedulable
.
I due valori non sono equivalenti: ad esempio, se un cluster ha 0 nodi, non sono previsti tentativi di prerilascio ma potrebbero verificarsi 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 dello scheduler:
- Latenza dello scheduler: lo scheduler è in esecuzione? Quanto tempo richiede la pianificazione dei pod?
- Problemi relativi alle risorse: i tentativi di pianificare i pod che colpiscono i vincoli delle risorse?
Questa sezione descrive come utilizzare la metrica dello scheduler per monitorare il tuo scheduler.
Latenza scheduler
L'attività dello scheduler è garantire che i pod vengano eseguiti, quindi vuoi sapere quando lo scheduler è bloccato o viene eseguito lentamente.
- Per verificare che lo scheduler sia in esecuzione e stia pianificando i pod, utilizza la metrica
scheduler_schedule_attempts_total
. Quando lo scheduler viene eseguito lentamente, esamina le seguenti possibili cause:
Il numero di pod in attesa è in aumento. Utilizza la metrica
scheduler_pending_pods
per monitorare il numero di pod in attesa. La seguente query PromQL restituisce il numero di pod in attesa per coda in un cluster:sum by (queue) (delta(scheduler_pending_pods{cluster="CLUSTER_NAME"}[2m]))
I singoli tentativi di pianificare i pod sono lenti. Utilizza la metrica
scheduler_scheduling_attempt_duration_seconds
per monitorare la latenza dei tentativi di pianificazione.Ti consigliamo di osservare questa metrica almeno al 50° e al 95° percentile. La seguente query PromQL recupera i valori del 95° percentile, ma può essere modificata:
sum by (instance) (histogram_quantile(0.95, rate( scheduler_scheduling_attempt_duration_seconds_bucket{cluster="CLUSTER_NAME"}[5m])))
Problemi relativi alle risorse
Le metriche dello scheduler possono anche aiutarti a valutare se disponi di risorse sufficienti. Se il valore della metrica scheduler_preemption_attempts_total
aumenta, verifica il valore di scheduler_preemption_victims
utilizzando la seguente query PromQL:
scheduler_preemption_victims_sum{cluster="CLUSTER_NAME"}
Il numero di tentativi di prerilascio e il numero di vittime di prerilascio aumentano entrambi quando è necessario pianificare pod con priorità più elevata. Le metriche di prerilascio
non indicano se i pod con priorità elevata che hanno attivato i prerilascio
sono stati pianificati, quindi quando noti aumenti del valore delle metriche
di prerilascio, puoi anche monitorare il valore della metrica
scheduler_pending_pods
. Se aumenta anche il numero di pod in attesa, potresti non avere risorse sufficienti per gestire i pod con priorità più elevata; potresti dover fare lo scale up delle risorse disponibili, creare nuovi pod con richieste di risorse ridotte o modificare il selettore di nodi.
Se il numero di vittime di prerilascio non aumenta, non ci sono altri pod con priorità bassa che possono essere rimossi. In questo caso, valuta la possibilità di aggiungere altri nodi in modo da allocare i nuovi pod.
Se il numero di vittime di prerilascio aumenta, ci sono pod con priorità più elevata in attesa di essere pianificati, quindi lo scheduler sta prerilasciando alcuni pod in esecuzione. Le metriche di prerilascio non indicano se i pod con priorità più elevata sono stati pianificati correttamente.
Per determinare se vengono pianificati i pod con priorità più elevata, cerca i valori decrescenti della metrica
scheduler_pending_pods
. Se il valore di questa metrica aumenta, potrebbe essere necessario aggiungere altri nodi.
È possibile che si verifichino picchi temporanei nei valori della metrica scheduler_pending_pods
quando i carichi di lavoro verranno pianificati nel cluster, ad esempio durante eventi come aggiornamenti o scalabilità.
Se 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 pianificati; i nodi non accettano nuovi pod.
- Controlla le seguenti istruzioni di pianificazione, che potrebbero essere configurate in modo errato e rendere un pod non pianificabile:
- Affinità dei nodi e selettore.
- Incompatibilità e tolleranze.
- Vincoli per la diffusione della topologia dei pod.
Se non è possibile pianificare i pod 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 del controller 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 essere preceduti dal prefisso prometheus.googleapis.com/
. Questo prefisso è stato omesso
dalle voci della tabella.
Nome metrica PromQL Fase di lancio Nome metrica Cloud Monitoring |
|
---|---|
Tipo, Tipo, Unità
Risorse monitorate Versione GKE richiesta |
Descrizione Etichette |
node_collector_evictions_total
GAnode_collector_evictions_total/counter
|
|
Cumulative , Double , 1
prometheus_target almeno 1,24 |
Numero di eliminazioni dei nodi avvenute dall'avvio dell'istanza attuale di NodeController.zone
|