Recolha e veja métricas do plano de controlo

Esta página descreve como configurar um cluster do Google Kubernetes Engine (GKE) para enviar métricas emitidas pelo servidor da API Kubernetes, pelo programador e pelo gestor do controlador para o Cloud Monitoring através do Google Cloud Managed Service for Prometheus. Esta página também descreve como estas métricas são formatadas quando são escritas no Monitoring e como consultar métricas.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

  • Ative a API Google Kubernetes Engine.
    • Ative a API Google Kubernetes Engine
  • Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.

Requisitos

O envio de métricas emitidas por componentes do painel de controlo do Kubernetes para o Cloud Monitoring tem os seguintes requisitos:

Configure a recolha de métricas do plano de controlo

Pode ativar as métricas do plano de controlo num cluster do GKE existente através da Google Cloud consola, da CLI gcloud ou do Terraform.

Consola

Pode ativar as métricas do plano de controlo para um cluster a partir do separador Observabilidade do cluster ou do separador Detalhes do cluster. Quando usa o separador Observabilidade, pode pré-visualizar os gráficos e as métricas disponíveis antes de ativar o pacote de métricas.

Para ativar as métricas do plano de controlo no separador Observability do cluster, faça o seguinte:

  1. Na Google Cloud consola, aceda à página Clusters do Kubernetes:

    Aceda a Clusters do Kubernetes

    Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cujo subtítulo é Kubernetes Engine.

  2. Clique no nome do cluster e, de seguida, selecione o separador Observabilidade.

  3. Selecione Plano de controlo na lista de funcionalidades.

  4. Clique em Ativar pacote.

    Se as métricas do plano de controlo já estiverem ativadas, é apresentado um conjunto de gráficos para as métricas do plano de controlo.

Para ativar as métricas do plano de controlo no separador Detalhes do cluster, faça o seguinte:

  1. Na Google Cloud consola, aceda à página Clusters do Kubernetes:

    Aceda a Clusters do Kubernetes

    Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cujo subtítulo é Kubernetes Engine.

  2. Clique no nome do cluster.

  3. Na linha Funcionalidades com a etiqueta Cloud Monitoring, clique no ícone Editar.

  4. Na caixa de diálogo Editar monitorização na nuvem apresentada, confirme que a opção Ativar monitorização na nuvem está selecionada.

  5. No menu pendente Componentes, selecione os componentes do plano de controlo a partir dos quais quer recolher métricas: Servidor de API, Programador ou Gestor de controladores.

  6. Clique em OK.

  7. Clique em Guardar alterações.

gcloud

Atualize o cluster para recolher métricas emitidas pelo servidor da API Kubernetes, Scheduler e Controller Manager:

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

Substitua o seguinte:

Terraform

Para configurar a recolha de métricas do plano de controlo do Kubernetes através do Terraform, consulte o bloco monitoring_config no registo do Terraform para google_container_cluster. Para informações gerais sobre a utilização do Google Cloud com o Terraform, consulte Terraform com o Google Cloud.

Quota

As métricas do plano de controlo consomem a quota "Pedidos de carregamento de séries cronológicas por minuto" da API Cloud Monitoring. Antes de ativar os pacotes de métricas, verifique a sua utilização máxima recente dessa quota. Se tiver muitos clusters no mesmo projeto ou já se estiver a aproximar desse limite de quota, pode pedir um aumento do limite de quota antes de ativar qualquer um dos pacotes de observabilidade.

Preços

As métricas do plano de controlo do GKE usam o Google Cloud Managed Service for Prometheus para carregar métricas no Cloud Monitoring. Os custos do Cloud Monitoring para a ingestão destas métricas baseiam-se no número de amostras ingeridas.

Para mais informações, consulte os preços do Cloud Monitoring.

Formato da métrica

Todas as métricas do plano de controlo do Kubernetes escritas no Cloud Monitoring usam o tipo de recurso prometheus_target. Cada nome de métrica tem o prefixo prometheus.googleapis.com/ e um sufixo que indica o tipo de métrica do Prometheus, como /gauge, /histogram ou /counter. Caso contrário, cada nome de métrica é idêntico ao nome de métrica exposto pelo Kubernetes de código aberto.

Exportar a partir do Cloud Monitoring

As métricas do plano de controlo do Kubernetes podem ser exportadas do Cloud Monitoring através da API Cloud Monitoring. Uma vez que todas as métricas do plano de controlo do Kubernetes são carregadas através do Google Cloud Managed Service for Prometheus, as métricas do plano de controlo do Kubernetes podem ser consultadas através da linguagem de consulta do Prometheus (PromQL). Também podem ser consultados através da linguagem de consulta de monitorização (MQL).

Consultar métricas

Quando consulta as métricas do plano de controlo do Kubernetes, o nome que usa depende de estar a usar o PromQL ou funcionalidades baseadas no Cloud Monitoring, como o MQL ou o Explorador de métricas, uma interface orientada por menus.

As tabelas seguintes de métricas do plano de controlo do Kubernetes mostram duas versões de cada nome de métrica:

  • Nome da métrica PromQL: quando usa o PromQL nas páginas do Cloud Monitoring da Google Cloud consola ou nos campos PromQL da API Cloud Monitoring, use o nome da métrica PromQL.
  • Nome da métrica do Cloud Monitoring Quando usar outras funcionalidades do Cloud Monitoring, use o nome da métrica do Cloud Monitoring nas tabelas abaixo. Este nome tem de ter o prefixo prometheus.googleapis.com/, que foi omitido das entradas na tabela.

Métricas do servidor da API

Esta secção fornece uma lista das métricas do servidor da API e informações adicionais sobre a interpretação e a utilização das métricas.

Lista de métricas do servidor da API

Quando as métricas do servidor da API estão ativadas, todas as métricas apresentadas na tabela seguinte 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 têm de ter o prefixo prometheus.googleapis.com/. Esse prefixo foi omitido das entradas na tabela.

Nome da métrica PromQL Fase de lançamento
Nome da métrica do Cloud Monitoring
Kind, Type, Unit
Recursos monitorizados
Versão do GKE obrigatória		 Descrição
Etiquetas
apiserver_current_inflight_requests GA
apiserver_current_inflight_requests/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		Número máximo do limite de pedidos em curso atualmente usado deste apiserver por tipo de pedido no último segundo.

request_kind
apiserver_flowcontrol_current_executing_seats BETA
apiserver_flowcontrol_current_executing_seats/gauge
Gauge, Double, 1
prometheus_target
1.28.3+ 		Concorrência (número de posições) ocupada pelos pedidos atualmente em execução (fase inicial para um WATCH, qualquer fase para outro tipo de pedido) no subsistema Priority and Fairness da API.

flow_schema
priority_level
apiserver_flowcontrol_current_inqueue_requests BETA
apiserver_flowcontrol_current_inqueue_requests/gauge
Gauge, Double, 1
prometheus_target
1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ para versões secundárias anteriores) 		Número de pedidos atualmente pendentes nas filas do subsistema de prioridade e equidade da API.

flow_schema
priority_level
apiserver_flowcontrol_nominal_limit_seats BETA
apiserver_flowcontrol_nominal_limit_seats/gauge
Gauge, Double, 1
prometheus_target
1.28.3+ (1.26.11+, 1.27.8+ para versões secundárias anteriores) 		Número nominal de posições de execução configuradas para cada nível de prioridade.

priority_level
apiserver_flowcontrol_rejected_requests_total BETA
apiserver_flowcontrol_rejected_requests_total/counter
Cumulative, Double, 1
prometheus_target
1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ para versões secundárias anteriores) 		Número de pedidos rejeitados pelo subsistema de prioridade e equidade da API.

flow_schema
priority_level
reason
apiserver_flowcontrol_request_wait_duration_seconds BETA
apiserver_flowcontrol_request_wait_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ para versões secundárias anteriores) 		Tempo que um pedido passou à espera na respetiva fila.

execute
flow_schema
priority_level
apiserver_request_duration_seconds GA
apiserver_request_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.23.6+ 		Distribuição da latência de resposta em segundos para cada verbo, valor de teste, grupo, versão, recurso, sub-recurso, âmbito e componente.

component
dry_run
group
resource
scope
subresource
verb
version
apiserver_request_total GA
apiserver_request_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		Contador de pedidos do apiserver discriminados para cada verbo, valor de teste, grupo, versão, recurso, âmbito, componente e código de resposta HTTP.

code
component
dry_run
group
resource
scope
subresource
verb
version
apiserver_response_sizes GA
apiserver_response_sizes/histogram
Cumulative, Distribution, 1
prometheus_target
1.22.13+ 		Distribuição do tamanho da resposta em bytes para cada grupo, versão, verbo, recurso, sub-recurso, âmbito e componente.

component
group
resource
scope
subresource
verb
version
apiserver_storage_objects GA
apiserver_storage_objects/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		Número de objetos armazenados no momento da última verificação, dividido por tipo.

resource
apiserver_admission_controller_admission_duration_seconds GA
apiserver_admission_controller_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.23.6+ 		Histograma da latência do controlador de admissão em segundos, identificado por nome e discriminado para cada operação e recurso e tipo de API (validar ou admitir).

name
operation
rejected
type
apiserver_admission_step_admission_duration_seconds GA
apiserver_admission_step_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.22.13+ 		Histograma da latência do subpasso de admissão em segundos, discriminado para cada operação, recurso da API e tipo de passo (validar ou admitir).

operation
rejected
type
apiserver_admission_webhook_admission_duration_seconds GA
apiserver_admission_webhook_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.22.13+ 		Histograma da latência do webhook de admissão em segundos, identificado por nome e discriminado para cada operação e recurso e tipo de API (validar ou admitir).

name
operation
rejected
type

As secções seguintes fornecem informações adicionais sobre as métricas do servidor da API.

apiserver_request_duration_seconds

Use esta métrica para monitorizar a latência no servidor da API. A duração do pedido registada por esta métrica inclui todas as fases do processamento de pedidos, desde o momento em que o pedido é recebido até ao momento em que o servidor conclui a respetiva resposta ao cliente. Especificamente, inclui o tempo gasto no seguinte:

  • A autenticação e a autorização do pedido.
  • Chamar os webhooks de terceiros e do sistema associados ao pedido.
  • Obter o objeto pedido a partir de uma cache na memória (para pedidos que especifiquem um parâmetro de URL resourceVersion) ou a partir da base de dados de estado do cluster baseada em etcd ou Spanner chamando a API etcd (para todos os outros pedidos).
  • Pode usar as etiquetas group, version, resource e subresource para identificar de forma exclusiva um pedido lento para investigação adicional.
  • Escrever a resposta ao cliente e receber a resposta do cliente.

Para mais informações sobre a utilização desta métrica, consulte o artigo Latência.

Esta métrica tem uma cardinalidade muito elevada. Quando usar esta métrica, tem de usar filtros ou agrupamentos para encontrar origens específicas de latência.

apiserver_admission_controller_admission_duration_seconds

Esta métrica mede a latência nos webhooks de admissão incorporados e não nos webhooks de terceiros. Para diagnosticar problemas de latência com webhooks 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

Estas métricas medem a latência nos webhooks de admissão externos de terceiros. Geralmente, a métrica apiserver_admission_webhook_admission_duration_seconds é a mais útil. Para mais informações sobre a utilização desta métrica, consulte o artigo Latência.

apiserver_request_total

Use esta métrica para monitorizar o tráfego de pedidos no seu servidor de API. Também pode usá-lo para determinar as taxas de êxito e falha dos seus pedidos. Para mais informações sobre a utilização desta métrica, consulte o artigo Taxa de tráfego e de erros.

Esta métrica tem uma cardinalidade muito elevada. Quando usar esta métrica, tem de usar filtros ou agrupamentos para identificar as origens dos erros.

apiserver_storage_objects

Use esta métrica para detetar a saturação do seu sistema e identificar possíveis fugas de recursos. Para mais informações, consulte o artigo Saturação.

apiserver_current_inflight_requests

Esta métrica regista o número máximo de pedidos que estavam a ser ativamente servidos no último intervalo de um segundo. Para mais informações, consulte o artigo Saturação.

A métrica não inclui pedidos de longa duração, como "watch".

Monitorizar o servidor da API

As métricas do servidor da API podem dar-lhe informações sobre os principais sinais para a integridade do sistema:

  • Latência: quanto tempo demora a processar um pedido?
  • Tráfego: qual é o volume de procura que o sistema está a registar?
  • Taxa de erros: com que frequência os pedidos falham?
  • Saturação: qual é o nível de preenchimento do sistema?

Esta secção descreve como usar as métricas do servidor da API para monitorizar o estado do servidor da API.

Latência

Quando o servidor da API está sobrecarregado, a latência dos pedidos aumenta. Para medir a latência dos pedidos ao servidor da API, use a métrica apiserver_request_duration_seconds. Para identificar a origem da latência de forma mais específica, pode agrupar as métricas pela etiqueta 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 ao nível do espaço de nomes e ao nível do cluster é de 30 segundos. As expetativas máximas são definidas pelos SLOs definidos pela comunidade Kubernetes de código aberto. Para mais informações, consulte os detalhes dos SLIs/SLOs de latência de chamadas de API.

Se o valor da métrica apiserver_request_duration_seconds estiver a aumentar além da duração esperada, investigue as seguintes possíveis causas:

  • O painel de controlo do Kubernetes pode estar sobrecarregado. Para verificar, consulte as métricas apiserver_request_total e apiserver_storage_objects.
    • Use a etiqueta code para determinar se os pedidos estão a ser processados com êxito. Para ver informações sobre os valores possíveis, consulte o artigo Códigos de estado HTTP.
    • Use as etiquetas group, version, resource e subresource para identificar exclusivamente um pedido.

  • Um webhook de admissão de terceiros está lento ou não responde. Se o valor da métrica apiserver_admission_webhook_admission_duration_seconds estiver a aumentar, significa que alguns dos seus webhooks de admissão de terceiros ou definidos pelo utilizador estão lentos ou não respondem. A latência no webhook de admissão pode causar atrasos no agendamento de tarefas.

    • Para consultar a latência do webhook do percentil 99 por instância do plano de controlo 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 que consulte também os percentis 50, 90, 95 e 99, 9.Pode ajustar esta consulta modificando o valor de 0.99.

    • Os webhooks externos têm um limite de tempo limite de aproximadamente 10 segundos. Pode definir políticas de alerta na métrica apiserver_admission_webhook_admission_duration_seconds para receber um alerta quando se estiver a aproximar do limite de tempo do webhook.

    • Também pode agrupar a métrica na etiqueta name para diagnosticar possíveis problemas com webhooks específicos.apiserver_admission_webhook_admission_duration_seconds

  • Está a listar muitos objetos. Espera-se que a latência das chamadas LIST aumente à medida que o número de objetos de um determinado tipo (o tamanho da resposta) aumenta.

  • Problemas do lado do cliente:

    • O cliente pode não ter recursos suficientes para receber respostas atempadamente. Para verificar, consulte as métricas de utilização da CPU para o pod do cliente.
    • O cliente tem uma ligação de rede lenta. Isto pode acontecer quando o cliente é executado num dispositivo, como um telemóvel, mas é improvável que aconteça com clientes executados numa rede do Compute Engine.
    • O cliente terminou inesperadamente, mas a ligação TCP tem um período de tempo limite de dezenas de segundos. Antes de o tempo limite da ligação expirar, os recursos do servidor são bloqueados, o que pode aumentar a latência.

Para mais informações, consulte as boas práticas para usar a prioridade e a equidade da API na documentação do Kubernetes.

Tráfego e taxa de erros

Para medir o tráfego e o número de pedidos bem-sucedidos e com falhas no servidor da API, use a métrica apiserver_request_total. Por exemplo, para medir o tráfego do servidor da API por instância do plano de controlo do Kubernetes, use a seguinte consulta PromQL:

sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME"}[1m]))

  • Para consultar os pedidos sem êxito, filtre a etiqueta code para valores 4xx e 5xx através da seguinte consulta PromQL:

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

  • Para consultar os pedidos bem-sucedidos, filtre a etiqueta code para valores 2xx através da seguinte consulta PromQL:

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

  • Para consultar os pedidos rejeitados pelo servidor da API por instância do plano de controlo do Kubernetes, filtre a etiqueta code para o valor 429 (http.StatusTooManyRequests) através da seguinte consulta PromQL:

    sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME", code="429"}[1m]))

Saturação

Pode medir a saturação no seu sistema através das métricas apiserver_current_inflight_requests e apiserver_storage_objects .

Se o valor da métrica apiserver_storage_objects estiver a aumentar, pode estar a ter um problema com um controlador personalizado que cria objetos, mas não os elimina. Pode filtrar ou agrupar a métrica pela etiqueta resource para identificar o recurso que está a ter/ aumentar.

Avalie a métrica apiserver_current_inflight_requests de acordo com as definições de prioridade e equidade da API. Estas definições afetam a forma como os pedidos são priorizados, pelo que não pode tirar conclusões apenas dos valores das métricas. Para mais informações, consulte o artigo Prioridade e equidade da API.

Métricas do programador

Esta secção apresenta uma lista das métricas do programador e informações adicionais sobre a interpretação e a utilização das métricas.

Lista de métricas do programador

Quando as métricas do agendador estão ativadas, todas as métricas apresentadas na tabela seguinte 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 têm de ter o prefixo prometheus.googleapis.com/. Esse prefixo foi omitido das entradas na tabela.

Nome da métrica PromQL Fase de lançamento
Nome da métrica do Cloud Monitoring
Kind, Type, Unit
Recursos monitorizados
Versão do GKE obrigatória		 Descrição
Etiquetas
kube_pod_resource_limit GA
kube_pod_resource_limit/gauge
Gauge, Double, 1
prometheus_target
1.31.1-gke.1621000+ 		Limite de recursos para cargas de trabalho no cluster, discriminado por pod. Isto mostra a utilização de recursos que o programador e o kubelet esperam por pod para o recurso, juntamente com a unidade do recurso, se aplicável.

namespace
node
pod
priority
resource
scheduler
unit
kube_pod_resource_request GA
kube_pod_resource_request/gauge
Gauge, Double, 1
prometheus_target
1.31.1-gke.1621000+ 		Recursos pedidos por cargas de trabalho no cluster, discriminados por pod. Isto mostra a utilização de recursos que o programador e o kubelet esperam por pod para o recurso, juntamente com a unidade do recurso, se aplicável.

namespace
node
pod
priority
resource
scheduler
unit
scheduler_pending_pods GA
scheduler_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" significa o número de pods em unschedulablePods.

queue
scheduler_pod_scheduling_duration_seconds DEPRECATED
scheduler_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) 		[Obsoleto na v. 1.29; removido na v. 1.30 e substituído por scheduler_pod_scheduling_sli_duration_seconds.] Latência de ponta a ponta para um pod a ser agendado, que pode incluir várias tentativas de agendamento.

attempts
scheduler_pod_scheduling_sli_duration_seconds BETA
scheduler_pod_scheduling_sli_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.30 ou superior 		Latência de ponta a ponta para um pod a ser agendado, desde o momento em que o pod entra na fila de agendamento, e pode envolver várias tentativas de agendamento.

attempts
scheduler_preemption_attempts_total GA
scheduler_preemption_attempts_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		Total de tentativas de substituição no cluster até agora
scheduler_preemption_victims GA
scheduler_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 GA
scheduler_scheduling_attempt_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.23.6+ 		Latência da tentativa de agendamento em segundos (algoritmo de agendamento + associação).

profile
result
scheduler_schedule_attempts_total GA
scheduler_schedule_attempts_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		Número de tentativas de agendamento de pods, por resultado. "unschedulable" significa que não foi possível agendar um pod, enquanto "error" significa um problema interno do agendador.

profile
result

As secções seguintes fornecem informações adicionais sobre as métricas do servidor da API.

scheduler_pending_pods

Pode usar a métrica scheduler_pending_pods para monitorizar a carga no seu programador. O aumento dos valores nesta métrica pode indicar problemas de recursos. O agendador tem três filas e esta métrica indica o número de pedidos pendentes por fila. As seguintes filas são suportadas:

  • active queue
    • O conjunto de pods que o programador está a tentar agendar; o pod com a prioridade mais alta está no início da fila.
  • backoff queue
    • O conjunto de pods não foi agendável na última vez que o agendador tentou, mas pode ser agendável na próxima vez.
    • Os pods nesta fila têm de aguardar um período de recuo (um máximo de 10 segundos), após o qual são movidos novamente para a fila active para outra tentativa de agendamento. Para mais informações sobre a gestão da fila backoff, consulte o pedido de implementação, Kubernetes issue 75417.

  • unschedulable definido

    • O conjunto de pods que o programador tentou agendar, mas que foram determinados como não agendáveis. O posicionamento nesta fila pode indicar problemas de disponibilidade ou compatibilidade com os seus nós ou a configuração dos seus seletores de nós.

      Quando as restrições de recursos impedem o agendamento de pods, os pods não estão sujeitos ao processamento de recuo. Em alternativa, quando um cluster está cheio, não é possível agendar novos pods, que são colocados na fila unscheduled.

    • A presença de pods não agendados pode indicar que tem recursos insuficientes ou que tem um problema de configuração do nó. Os pods são movidos para a fila backoff ou active após eventos que alteram o estado do cluster. Os pods nesta fila indicam que nada mudou no cluster que tornaria os pods agendáveis.

    • Afinidades definem regras sobre como os agrupamentos são atribuídos aos nós. A utilização de regras de afinidade ou anti-afinidade pode ser um motivo para um aumento nos pods não agendados.

    • Alguns eventos, por exemplo, PVC/Service ADD/UPDATE, rescisão de um pod ou o registo de novos nós, movem alguns ou todos os pods não agendados para a fila backoff ou active. Para mais informações, consulte o problema 81214 do Kubernetes.

Para mais informações, consulte os artigos Latência do programador e Problemas de recursos.

scheduler_scheduling_attempt_duration_seconds

Esta métrica mede a duração de uma única tentativa de agendamento no próprio agendador e é discriminada pelo resultado: agendado, não agendável ou erro. A duração decorre desde o momento em que o programador seleciona um pod até ao momento em que o programador localiza um nó e coloca o pod no nó, determina que o pod não é programável ou encontra um erro. A duração do agendamento inclui o tempo no processo de agendamento, bem como o tempo de associação. A associação é o processo no qual o programador comunica a respetiva atribuição de nós ao servidor de API. Para mais informações, consulte o artigo Latência do programador.

Esta métrica não capta o tempo que o pod passa no controlo de admissão ou na validação.

Para mais informações sobre o agendamento, consulte o artigo Agendar um pod.

scheduler_schedule_attempts_total

Esta métrica mede o número de tentativas de agendamento. Cada tentativa de agendar um grupo de anúncios aumenta o valor. Pode usar esta métrica para determinar se o programador está disponível: se o valor estiver a aumentar, significa que o programador está operacional. Pode usar a etiqueta result para determinar o sucesso. Os pods são scheduled ou unschedulable.

Esta métrica está fortemente correlacionada com a métrica scheduler_pending_pods: quando existem muitos pods pendentes, pode esperar ver muitas tentativas de agendar os pods. Para mais informações, consulte o artigo Problemas de recursos.

Esta métrica não aumenta se o programador não tiver pods para agendar, o que pode acontecer se tiver um programador secundário personalizado.

scheduler_preemption_attempts_total e scheduler_preemptions_victims

Pode usar as métricas de antecipação para ajudar a determinar se precisa de adicionar recursos.

Pode ter pods de prioridade mais elevada que não podem ser agendados porque não há espaço para eles. Neste caso, o programador liberta recursos ao antecipar um ou mais pods em execução num nó. A métrica scheduler_preemption_attempts_total monitoriza o número de vezes que o programador tentou antecipar pods.

A métrica scheduler_preemptions_victims contabiliza os pods selecionados para a preempção.

O número de tentativas de preemptção está fortemente correlacionado com o valor da métrica scheduler_schedule_attempts_total quando o valor da etiqueta result é unschedulable. Os dois valores não são equivalentes: por exemplo, se um cluster tiver 0 nós, não há tentativas de preemptividade, mas podem existir tentativas de agendamento que falham.

Para mais informações, consulte o artigo Problemas de recursos.

Monitorizar o programador

As métricas do programador podem dar-lhe estatísticas sobre o desempenho do seu programador:

Esta secção descreve como usar a métrica do programador para monitorizar o seu programador.

Latência do programador

A tarefa do programador é garantir que os seus pods são executados, pelo que quer saber quando o programador está bloqueado ou a ser executado lentamente.

  • Para verificar se o programador está em execução e a programar pods, use a métrica scheduler_schedule_attempts_total.

  • Quando o programador está a ser executado lentamente, investigue as seguintes possíveis causas:

    • O número de pods pendentes está a aumentar. Use a métrica scheduler_pending_pods para monitorizar o número de pods pendentes. A seguinte consulta PromQL devolve o número de pods pendentes por fila num cluster:

      sum by (queue)
(delta(scheduler_pending_pods{cluster="CLUSTER_NAME"}[2m]))

    • As tentativas individuais de agendar pods são lentas. Use a métrica scheduler_scheduling_attempt_duration_seconds para monitorizar a latência das tentativas de agendamento.

      Recomendamos que observe esta métrica, pelo menos, nos percentis 50 e 95. A seguinte consulta PromQL obtém os 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 de recursos

As métricas do programador também podem ajudar a avaliar se tem recursos suficientes. Se o valor da métrica scheduler_preemption_attempts_total estiver a aumentar, verifique o valor de scheduler_preemption_victims através da seguinte consulta PromQL:

scheduler_preemption_victims_sum{cluster="CLUSTER_NAME"}

O número de tentativas de preemptção e o número de vítimas de preemptção aumentam quando existem pods de prioridade mais elevada para agendar. As métricas de antecipação não indicam se os pods de alta prioridade que acionaram as antecipações foram agendados. Por isso, quando vir aumentos no valor das métricas de antecipação, também pode monitorizar o valor da métrica scheduler_pending_pods. Se o número de pods pendentes também estiver a aumentar, pode não ter recursos suficientes para processar os pods de prioridade mais elevada. Pode ter de aumentar os recursos disponíveis, criar novos pods com reivindicações de recursos reduzidas ou alterar o seletor de nós.

  • Se o número de vítimas de preemptção não estiver a aumentar, significa que não existem mais pods com prioridade baixa que possam ser removidos. Neste caso, considere adicionar mais nós para que os novos pods possam ser atribuídos.

  • Se o número de vítimas de preemptions estiver a aumentar, significa que existem pods de prioridade mais elevada à espera de agendamento, pelo que o programador está a impedir a execução de alguns dos pods em execução. As métricas de preemptção não indicam se os pods de prioridade mais elevada foram agendados com êxito.

    Para determinar se os pods de prioridade mais elevada estão a ser agendados, procure valores decrescentes da métrica scheduler_pending_pods. Se o valor desta métrica estiver a aumentar, pode ter de adicionar mais nós.

Pode esperar ver picos temporários nos valores da métrica scheduler_pending_pods quando as cargas de trabalho forem agendadas no cluster, por exemplo, durante eventos como atualizações ou dimensionamentos. Se tiver recursos suficientes no cluster, estes picos sã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 isolados. Os nós isolados não aceitam novos pods.
  • Verifique as seguintes diretivas de agendamento, que podem estar configuradas incorretamente e podem tornar um pod não agendável:
    • Afinidade e seletor de nós.
    • Restrições e tolerâncias.
    • Restrições de dispersão de topologia de agrupamentos.

Se não for possível agendar pods devido a recursos insuficientes, considere libertar alguns dos nós existentes ou aumentar o número de nós.

Métricas do Gestor de comandos

Quando as métricas do gestor de controladores estão ativadas, todas as métricas apresentadas na tabela seguinte 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 têm de ter o prefixo prometheus.googleapis.com/. Esse prefixo foi omitido das entradas na tabela.

Nome da métrica PromQL Fase de lançamento
Nome da métrica do Cloud Monitoring
Kind, Type, Unit
Recursos monitorizados
Versão do GKE obrigatória		 Descrição
Etiquetas
node_collector_evictions_total GA
node_collector_evictions_total/counter
Cumulative, Double, 1
prometheus_target
1.24 ou superior 		Número de remoções de nós que ocorreram desde a instância atual do NodeController.

zone