É possível configurar um cluster do Google Kubernetes Engine (GKE) para enviar determinadas métricas emitidas pelo servidor da API Kubernetes, pelo programador e pelo gerenciador do controlador paraCloud Monitoring usando Google Cloud Managed Service para Prometheus. Neste documento, descrevemos como essas métricas são formatadas quando são gravadas no Cloud Monitoring e como consultá-las. Neste documento, também fornecemos tabelas que listam as métricas em cada conjunto e informações sobre como você pode usar essas métricas.
Antes de usar as métricas do plano de controle, é necessário ativar a coleta delas.
Formato da métrica
Todas as métricas do plano de controle do Kubernetes gravadas no Cloud Monitoring usam o tipo de recurso
prometheus_target.
Cada nome de métrica é prefixado com
prometheus.googleapis.com/ e tem um sufixo indicando o
tipo de métrica do Prometheus, como /gauge, /histogram
ou /counter. Caso contrário, cada nome de métrica será
idêntico ao nome da métrica exposto pelo Kubernetes de código aberto.
Como exportar do Cloud Monitoring
As métricas do plano de controle podem ser exportadas do Cloud Monitoring usando a API Cloud Monitoring. Como todas as métricas do plano de controle são ingeridas usando Google Cloud Managed Service para Prometheus, as métricas do plano de controle podem ser consultadas usando o Prometheus Query Language (PromQL). Elas também podem ser consultadas usando a linguagem de consulta do Monitoring (MQL, na sigla em inglês).
Métricas de consulta
Quando você consulta as métricas do plano de controle, o nome usado depende do uso dos recursos baseados no PromQL ou Cloud Monitoring, como o MQL ou o Metrics Explorer interface de menu do Google Analytics.
As tabelas de métricas do plano de controle a seguir mostram duas versões do nome de cada métrica:
- Nome da métrica do PromQL: ao usar o PromQL em páginas do Cloud Monitoring do console do Google Cloud ou em campos do PromQL do API Cloud Monitoring, use o nome da métrica do PromQL.
- Nome da métrica do Cloud Monitoring: ao usar outros
recursos do Monitoring, use o nome de métrica do Cloud Monitoring nas
tabelas abaixo. Esse nome precisa ser prefixado com
prometheus.googleapis.com/, que foi omitido das entradas na tabela.
Métricas do servidor de API
Nesta seção, apresentamos uma lista das métricas do servidor de API e mais informações sobre como interpretar e usar as métricas.
Lista de métricas do servidor de API
Quando as métricas do servidor de API estão ativadas, todas as métricas mostradas na tabela a seguir são exportadas para o Cloud Monitoring no mesmo projeto que o cluster do GKE.
Os nomes das métricas do Cloud Monitoring nesta tabela precisam ser prefixados com
prometheus.googleapis.com/. Esse prefixo foi omitido das
entradas na tabela.
| Nome da métrica do PromQL Estágio de lançamento Nome da métrica do Cloud Monitoring |
|
|---|---|
|
Tipo, Classe, Unidade
Recursos monitorados Versão obrigatória do GKE |
Descrição Rótulos |
apiserver_current_inflight_requests
GAapiserver_current_inflight_requests/gauge
|
|
Gauge, Double, 1
prometheus_target 1.22.13+ |
Número máximo de limites de solicitações em andamento atualmente
do apiserver para cada tipo de solicitação no último segundo.request_kind
|
apiserver_flowcontrol_current_executing_seats
BETAapiserver_flowcontrol_current_executing_seats/gauge
|
|
Gauge, Double, 1
prometheus_target 1.28.3+ |
Simultaneidade (número de licenças por usuário) ocupada pelas solicitações em execução
no momento (estágio inicial para WATCH; caso contrário, qualquer estágio) no subsistema de
prioridade e imparcialidade da 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+ para versões secundárias anteriores) |
Número de solicitações pendentes no momento nas filas do subsistema
de prioridade e imparcialidade da API.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+ para versões secundárias anteriores) |
Número nominal de licenças de execução por usuário configuradas para cada nível de
prioridade.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+ para versões secundárias anteriores) |
Número de solicitações rejeitadas pelo subsistema de prioridade e imparcialidade
da 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+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ para versões secundárias anteriores) |
Tempo que uma solicitação ficou aguardando na fila.execute
flow_schema
priority_level
|
apiserver_request_duration_seconds
GAapiserver_request_duration_seconds/histogram
|
|
Cumulative, Distribution, s
prometheus_target 1.23.6+ |
Distribuição de latência da resposta em segundos para cada verbo, valor de simulação,
grupo, versão, recurso, sub-recurso, escopo 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+ |
Contador de solicitações de apiserver dividido para cada verbo, valor de simulação,
grupo, versão, recurso, escopo, componente e código de resposta 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+ |
Distribuição do tamanho da resposta em bytes para cada grupo, versão, verbo,
recurso, sub-recurso, escopo e componente.component
group
resource
scope
subresource
verb
version
|
apiserver_storage_objects
GAapiserver_storage_objects/gauge
|
|
Gauge, Double, 1
prometheus_target 1.22.13+ |
Número de objetos armazenados no momento da última verificação dividido por
tipo.resource
|
apiserver_admission_controller_admission_duration_seconds
GAapiserver_admission_controller_admission_duration_seconds/histogram
|
|
Cumulative, Distribution, s
prometheus_target 1.23.6+ |
Histograma de latência do controlador de admissão em segundos, identificado por nome
e detalhado para cada operação e tipo e recurso da API (validar ou
permitir).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+ |
Histograma de latência da subetapa de entrada em segundos, detalhado para cada
operação e tipo de etapa e recurso da API (validar ou permitir).operation
rejected
type
|
apiserver_admission_webhook_admission_duration_seconds
GAapiserver_admission_webhook_admission_duration_seconds/histogram
|
|
Cumulative, Distribution, s
prometheus_target 1.22.13+ |
Histograma de latência do webhook de entrada em segundos, identificado por nome e
detalhado para cada operação e tipo e recurso da API (validar ou
permitir).name
operation
rejected
type
|
As seções a seguir fornecem mais informações sobre as métricas do servidor da API.
apiserver_request_duration_seconds
Use essa métrica para monitorar a latência no servidor de API. A duração da solicitação registrada por essa métrica inclui todas as fases de processamento de solicitação, desde o momento em que a solicitação é recebida até o momento em que o servidor conclui a resposta ao cliente. Especificamente, ele inclui o tempo gasto no seguinte:
- A autenticação e autorização da solicitação.
- Chamar os webhooks de terceiros e do sistema associados à solicitação.
- Buscar o objeto solicitado de um cache na memória (para solicitações
que especificam um parâmetro de URL
resourceVersion) ou deetcd(para todas as outras solicitações). - Você pode usar os rótulos
group,version,resourceesubresourcepara identificar exclusivamente uma solicitação lenta para uma investigação mais aprofundada. - Escrever a resposta para o cliente e receber a resposta dele.
Para mais informações sobre como usar essa métrica, consulte Latência.
Essa métrica tem cardinalidade muito alta. Ao usar essa métrica, é preciso usar filtros ou agrupamento para encontrar fontes específicas de latência.
apiserver_admission_controller_admission_duration_seconds
Essa métrica mede a latência em webhooks de admissão integrados, não em webhooks de terceiros. Para diagnosticar problemas de latência com webooks de terceiros,
use a métrica
apiserver_admission_webhook_admission_duration_seconds.
apiserver_admission_webhook_admission_duration_seconds e
apiserver_admission_step_admission_duration_seconds
Essas métricas medem a latência em webhooks de admissão externa e de terceiros.
A métrica apiserver_admission_webhook_admission_duration_seconds
geralmente é a mais útil. Para mais informações sobre como usar essa
métrica, consulte Latência.
apiserver_request_total
Use essa métrica para monitorar o tráfego de solicitação no servidor de API. Também é possível usá-la para determinar as taxas de sucesso e falha das suas solicitações. Para mais informações sobre como usar essa métrica, consulte Taxa de tráfego e erro.
Essa métrica tem cardinalidade muito alta. Ao usar essa métrica, é preciso usar filtros ou agrupamento para identificar fontes de erros.
apiserver_storage_objects
Use essa métrica para detectar a saturação do sistema e identificar possíveis vazamentos de recursos. Para ver mais informações, consulte Saturação.
apiserver_current_inflight_requests
Essa métrica registra o número máximo de solicitações que estavam sendo ativamente atendidas na última janela de um segundo. Para ver mais informações, consulte Saturação.
A métrica não inclui solicitações de longa duração, como "relógio".
Como monitorar o servidor de API
As métricas do servidor de API podem fornecer insights sobre os principais sinais de integridade do sistema:
- Latência: quanto tempo leva para atender a uma solicitação?
- Tráfego: quanta demanda o sistema está passando?
- Taxa de erro: com que frequência as solicitações falham?
- Saturação: quão cheio está o sistema?
Nesta seção, descrevemos como usar as métricas do servidor de API para monitorar a integridade dele.
Latência
Quando a API do servidor está sobrecarregada, a latência da solicitação aumenta. Para medir a latência das solicitações para o servidor de API, use a métrica apiserver_request_duration_seconds. Para identificar a origem da latência de maneira mais específica, é possível agrupar as métricas pelo rótulo verb ou resource.
O limite superior sugerido para uma chamada de recurso único, como GET, POST ou PATCH, é de um segundo. O limite superior sugerido para chamadas LIST com escopo de namespace e de cluster é de 30 segundos. As expectativas de limite superior são definidas pelos SLOs definidos pela comunidade de código aberto do Kubernetes. Para mais informações, consulte Detalhes dos SLIs/SLOs de latência da chamada de API.
Se o valor da métrica
apiserver_request_duration_seconds
estiver aumentando além da duração esperada, investigue as seguintes
possíveis causas:
- O plano de controle do Kubernetes pode estar sobrecarregado. Para verificar isso, observe as métricas
apiserver_request_totaleapiserver_storage_objects.- Use o rótulo
codepara determinar se as solicitações estão sendo processadas. Para ver informações sobre os valores possíveis, consulte Códigos de status HTTP. - Use os rótulos
group,version,resourceesubresourcepara identificar exclusivamente uma solicitação.
- Use o rótulo
Um webhook de admissão de terceiros é lento ou não responde. Se o valor da métrica
apiserver_admission_webhook_admission_duration_secondsestiver aumentando, alguns webhooks de admissão de terceiros ou definidos pelo usuário são lentos ou não respondem. A latência no webhook de admissão pode causar atrasos na programação de jobs.Para consultar a latência do webhook do percentil 99 por instância do plano de controle do Kubernetes, use a seguinte consulta PromQL:
sum by (instance) (histogram_quantile(0.99, rate(apiserver_admission_webhook_admission_duration_seconds_bucket{cluster="CLUSTER_NAME"}[1m])))Recomendamos também analisar os percentis 50, 90, 95 e 99.9. É possível ajustar a consulta modificando o valor de
0.99.Os webhooks externos têm um tempo limite aproximado de 10 segundos. É possível definir políticas de alertas na métrica
apiserver_admission_webhook_admission_duration_secondspara avisar quando você estiver se aproximando do tempo limite do webhook.Também é possível agrupar a métrica
apiserver_admission_webhook_admission_duration_secondsno rótulonamepara diagnosticar possíveis problemas com webhooks específicos.
Você está listando muitos objetos. Espera-se que a latência de chamadas de LIST aumente conforme o número de objetos de um determinado tipo (o tamanho de resposta).
Problemas no lado do cliente:
- O cliente pode não ter recursos suficientes para receber respostas em tempo hábil. Verifique as métricas de uso de CPU do pod cliente.
- O cliente tem uma conexão de rede lenta. Isso pode acontecer quando o cliente é executado em um dispositivo como um smartphone, mas é improvável que os clientes sejam executados em uma rede do Compute Engine.
- O cliente foi encerrado inesperadamente, mas a conexão TCP tem um tempo limite em dezenas de segundos. Antes do tempo limite da conexão, os recursos do servidor são bloqueados, o que pode aumentar a latência.
Taxa de tráfego e erros
Para medir o tráfego e o número de solicitações bem-sucedidas e com falha
no servidor de API, use a métrica
apiserver_request_total. Por exemplo, para medir o tráfego do servidor de API por instância do plano de controle do Kubernetes, use a seguinte consulta PromQL:
sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME"}[1m]))
Para consultar as solicitações malsucedidas, filtre o rótulo
codepelos valores 4xx e 5xx usando a seguinte consulta PromQL:sum(rate(apiserver_request_total{code=~"[45].."}[5m]))Para consultar as solicitações bem-sucedidas, filtre o rótulo
codepor valores 2xx usando a seguinte consulta PromQL:sum(rate(apiserver_request_total{code=~"2.."}[5m]))Para consultar as solicitações rejeitadas pelo servidor de API por instância do plano de controle do Kubernetes, filtre o rótulo
codepelo valor 429 (http.StatusTooManyRequests) usando a seguinte consulta PromQL:sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME", code="429"}[1m]))
Saturação
É possível medir a saturação no sistema usando as métricas
apiserver_current_inflight_requests
e apiserver_storage_objects .
Se o valor da métrica
apiserver_storage_objects
estiver aumentando, você pode estar tendo um problema em um controlador
personalizado que cria objetos, mas não os exclui. É possível filtrar ou agrupar a métrica pelo rótulo resource para identificar o recurso que está tendo o aumento.
Avalie a métrica apiserver_current_inflight_requests
de acordo com as configurações de prioridade de imparcialidade da API. Essas configurações
afetam como as solicitações são priorizadas. Portanto, não é possível tirar conclusões somente
dos valores de métricas. Para mais informações, consulte Prioridade e imparcialidade da API.
Métricas do programador
Nesta seção, apresentamos uma lista das métricas do programador e informações adicionais sobre como interpretar e usar as métricas.
Lista de métricas do programador
Quando as métricas do programador estão ativadas, todas as métricas mostradas na tabela a seguir são exportadas para o Cloud Monitoring no mesmo projeto que o cluster do GKE.
Os nomes das métricas do Cloud Monitoring nesta tabela precisam ser prefixados com
prometheus.googleapis.com/. Esse prefixo foi omitido das
entradas na tabela.
| Nome da métrica do PromQL Estágio de lançamento Nome da métrica do Cloud Monitoring |
|
|---|---|
|
Tipo, Classe, Unidade
Recursos monitorados Versão obrigatória do GKE |
Descrição Rótulos |
scheduler_pending_pods
GAscheduler_pending_pods/gauge
|
|
Gauge, Double, 1
prometheus_target 1.22.13+ |
Número de pods pendentes por tipo de fila. "active" significa o número de pods
em activeQ; "backoff" significa o número de pods em backoffQ; "unschedulable"
indica o número de pods em unschedulablePods.queue
|
scheduler_pod_scheduling_duration_seconds
DESCONTINUADOscheduler_pod_scheduling_duration_seconds/histogram
|
|
Cumulative, Distribution, 1
prometheus_target 1.25.1 a 1.29 (1.22.17-gke.3100+ , 1.23.11+ e 1.24.5+ para versões secundárias anteriores) |
[Descontinuado na v. 1.29; removido na v. 1.30 e substituído por
scheduler_pod_scheduling_sli_duration_seconds.]
Latência E2e de um pod sendo programado, o que pode incluir várias tentativas de programação.attempts
|
scheduler_pod_scheduling_sli_duration_seconds
BETAscheduler_pod_scheduling_sli_duration_seconds/histogram
|
|
Cumulative, Distribution, 1
prometheus_target 1.30+ |
Latência E2e de um pod sendo programado, desde o momento em que o pod entra na fila de programação, e pode envolver várias tentativas de programação.attempts
|
scheduler_preemption_attempts_total
GAscheduler_preemption_attempts_total/counter
|
|
Cumulative, Double, 1
prometheus_target 1.22.13+ |
Total de tentativas de preempção no cluster até o momento |
scheduler_preemption_victims
GAscheduler_preemption_victims/histogram
|
|
Cumulative, Distribution, 1
prometheus_target 1.22.13+ |
Número de vítimas de preempção selecionadas |
scheduler_scheduling_attempt_duration_seconds
GAscheduler_scheduling_attempt_duration_seconds/histogram
|
|
Cumulative, Distribution, 1
prometheus_target 1.23.6+ |
Latência de tentativa da programação em segundos (algoritmo de programação +
vinculação).profile
result
|
scheduler_schedule_attempts_total
GAscheduler_schedule_attempts_total/counter
|
|
Cumulative, Double, 1
prometheus_target 1.22.13+ |
O número de tentativas de programar pods por resultado. "unschedulable"
significa que um pod não pode ser programado, enquanto "error" significa um problema interno
do programador.profile
result
|
As seções a seguir fornecem mais informações sobre as métricas do servidor da API.
scheduler_pending_pods
É possível usar a métrica scheduler_pending_pods para monitorar a carga
no programador. O aumento dos valores nessa métrica pode indicar problemas de recursos. O programador tem três filas, e essa métrica informa o
número de solicitações pendentes por fila. As seguintes filas são compatíveis:
- Fila
active- O conjunto de pods que o programador está tentando programar. O pod com a prioridade mais alta está no cabeçalho da fila.
- Fila
backoff- O conjunto de pods não estava programável na última vez que o programador tentou, mas que pode ser programado na próxima vez.
- Os pods nessa fila precisam aguardar um período de espera (máximo de 10
segundos). Depois disso, eles são movidos de volta para a fila
activepara outra tentativa de programação. Para mais informações sobre o gerenciamento da filabackoff, consulte a solicitação de implementação, Problema do Kubernetes 75417.
Conjunto
unschedulableO conjunto de pods que o programador tentou programar, mas que foram determinados como não programáveis. A posição nesta fila pode indicar problemas de prontidão ou compatibilidade com os nós ou a configuração dos seletores de nós.
Quando as restrições de recursos impedem que os pods sejam programados, os pods não estão sujeitos ao tratamento de espera. Em vez disso, quando um cluster está cheio, novos pods não são programados e são colocados na fila
unscheduled.A presença de pods não programados pode indicar que você tem recursos insuficientes ou um problema de configuração do nó. Os pods são movidos para a fila
backoffouactiveapós eventos que alteram o estado do cluster. Os pods nessa fila indicam que nada mudou no cluster que tornaria os pods programáveis.Afinidades definem regras de atribuição de pods aos nós. O uso de regras de afinidade ou antiafinidade pode ser um motivo para um aumento nos pods não programados.
Alguns eventos, por exemplo, ADD/UPDATE de PVC/serviço, término de um pod ou o registro de novos nós, movem alguns ou todos os pods não programados para a fila
backoffouactive. Para saber mais, consulte Problema do Kubernetes 81214.
Para saber mais, consulte Latência do programador e Problemas de recursos.
scheduler_scheduling_attempt_duration_seconds
Essa métrica mede a duração de uma única tentativa de programação no próprio programador e é dividida pelo resultado: programado, não programável ou erro. A duração vai do momento em que o programador pega um pod até o momento em que o programador localiza um nó e o coloca no nó, determina que o pod não é programável ou encontra um erro. A duração da programação inclui o tempo do processo de programação e o tempo de vinculação. Vinculação é o processo em que o programador comunica a atribuição de nó ao servidor da API. Para mais informações, consulte Latência do programador.
Essa métrica não captura o tempo que o pod gasta no controle de admissão ou na validação.
Para mais informações sobre programação, consulte Como programar um pod.
scheduler_schedule_attempts_total
Esta métrica mede o número de tentativas de agendamento cada tentativa de programar um pod aumenta o valor. Use essa métrica para determinar se o programador está disponível: se o valor está aumentando, então o programador está operacional. Você pode usar o rótulo result para determinar o
sucesso. Os pods são scheduled ou unschedulable.
Essa métrica está altamente correlacionada com a métrica scheduler_pending_pods: quando há muitos pods pendentes, você pode esperar muitas tentativas para programar os pods. Para saber mais, consulte Problemas de recursos.
Essa métrica não aumentará se o programador não tiver pods a serem programados, o que poderá ser o caso se você tiver um programador secundário personalizado.
scheduler_preemption_attempts_total e scheduler_preemptions_victims
Use as métricas de preempção para ajudar a determinar se você precisa adicionar recursos.
Talvez você tenha pods de maior prioridade que não podem ser programados porque não há espaço para eles. Nesse caso, o programador libera recursos
interrompendo temporariamente um ou mais pods em execução em um nó. A métrica scheduler_preemption_attempts_total rastreia o
número de vezes que o programador tentou forçar a interrupção de pods.
A métrica scheduler_preemptions_victims conta os pods selecionados para preempção.
O número de tentativas de preempção tem uma forte correlação com o valor da métrica scheduler_schedule_attempts_total quando o valor do identificador result é unschedulable.
Os dois valores não são equivalentes: por exemplo, se um cluster tem 0 nós,
não há tentativas de preempção, mas pode haver tentativas de programação que
falham.
Para saber mais, consulte Problemas de recursos.
Como monitorar o programador
As métricas do programador podem fornecer insights sobre o desempenho dele:
- Latência do programador: o programador está em execução? Quanto tempo leva para programar pods?
- Problemas de recursos: as tentativas de programar pods atendem às restrições de recursos?
Nesta seção, descrevemos como usar a métrica do programador para monitorá-lo.
Latência do programador
A tarefa do programador é garantir que os pods sejam executados. Portanto, é importante saber quando o programador está travado ou em execução lenta.
- Para verificar se o programador está em execução e programando pods, use a métrica
scheduler_schedule_attempts_total. Quando o programador estiver lento, investigue as seguintes causas possíveis:
O número de pods pendentes está aumentando. Use a métrica
scheduler_pending_podspara monitorar o número de pods pendentes. A seguinte consulta PromQL retorna o número de pods pendentes por fila em um cluster:sum by (queue) (delta(scheduler_pending_pods{cluster="CLUSTER_NAME"}[2m]))Tentativas individuais de programar pods são lentas. Use a métrica
scheduler_scheduling_attempt_duration_secondspara monitorar a latência das tentativas de agendamento.Recomendamos observar essa métrica pelo menos nos percentis 50 e 95. A consulta PromQL a seguir recupera valores do percentil 95, mas pode ser ajustada:
sum by (instance) (histogram_quantile(0.95, rate( scheduler_scheduling_attempt_duration_seconds_bucket{cluster="CLUSTER_NAME"}[5m])))
Problemas com recursos
As métricas do programador também podem ajudar você a avaliar se você tem recursos
suficientes. Se o valor da métrica
scheduler_preemption_attempts_total
estiver aumentando, verifique o valor de
scheduler_preemption_victims usando a seguinte consulta
PromQL:
scheduler_preemption_victims_sum{cluster="CLUSTER_NAME"}
O número de tentativas de preempção e o número de vítimas de preempção
aumentam quando há pods de prioridade mais alta a serem programados. As métricas de preempção
não informam se os pods de alta prioridade que acionaram
as preempções foram programados. Portanto, quando você vê aumentos no valor das
métricas de preempção, também é possível monitorar o valor da métrica scheduler_pending_pods. Se o número de pods
pendentes também estiver aumentando, é possível que você não tenha recursos suficientes
para lidar com os pods de maior prioridade. Pode ser necessário escalonar verticalmente os recursos disponíveis, criar novos pods com declarações de recursos reduzidas ou alterar o seletor de nós.
Se o número de vítimas de preempção não estiver aumentando, não haverá pods restantes com baixa prioridade que possam ser removidos. Nesse caso, considere adicionar mais nós para que os novos pods possam ser alocados.
Se o número de vítimas de preempção estiver aumentando, isso significa que há pods de maior prioridade aguardando a programação, então o programador interrompe alguns pods em execução. As métricas de preempção não informam se os pods de prioridade mais alta foram programados com sucesso.
Para determinar se os pods de maior prioridade estão sendo programados, procure diminuir os valores da métrica
scheduler_pending_pods. Se o valor dessa métrica estiver aumentando, talvez seja necessário adicionar mais nós.
É possível que haja picos temporários nos valores da métrica
scheduler_pending_pods quando as cargas de trabalho forem programadas
no cluster, por exemplo, durante eventos como atualizações ou escalonamentos.
Se você tiver recursos suficientes no cluster, esses picos serão temporários.
Se o número de pods pendentes não diminuir, faça o seguinte:
- Verifique se os nós não estão limitados. Nós limitados não aceitam novos pods.
- Verifique as diretivas de programação a seguir, que podem ser configuradas incorretamente e
podem tornar um pod não programável:
- Afinidade e seletor de nós.
- Taints e tolerâncias
- Restrições de propagação de topologia de pods.
Se não for possível programar os pods devido à insuficiência de recursos, libere alguns dos nós atuais ou aumente o número de nós.
Métricas do Controller Manager
Quando as métricas do gerenciador do controlador estão ativadas, todas as métricas mostradas na tabela a seguir são exportadas para o Cloud Monitoring no mesmo projeto que o cluster do GKE.
Os nomes das métricas do Cloud Monitoring nesta tabela precisam ser prefixados com
prometheus.googleapis.com/. Esse prefixo foi omitido das
entradas na tabela.
| Nome da métrica do PromQL Estágio de lançamento Nome da métrica do Cloud Monitoring |
|
|---|---|
|
Tipo, Classe, Unidade
Recursos monitorados Versão obrigatória do GKE |
Descrição Rótulos |
node_collector_evictions_total
GAnode_collector_evictions_total/counter
|
|
Cumulative, Double, 1
prometheus_target 1.24+ |
Número de remoções de nós que ocorreram desde que a instância atual do
NodeController foi iniciada.zone
|