Conferir eventos e métricas do escalonador automático de clusters

Nesta página, você encontra informações sobre eventos de visibilidade e métricas emitidas pelo escalonador automático de cluster no Google Kubernetes Engine (GKE). Ao analisar esses registros e métricas, você pode ter insights sobre como o escalonador automático de cluster gerencia o escalonamento do cluster, acompanhar as tendências de provisionamento de nós e entender os motivos por trás das decisões.

Use as informações a seguir para observar o escalonador automático de cluster:

  • Logs de eventos de visibilidade: logs de eventos no Cloud Logging que fornecem informações detalhadas sobre ações de escalonamento específicas, como decisões de scaleUp, scaleDown e noScaleUp. Os eventos descritos neste guia são separados dos eventos do Kubernetes produzidos pelo escalonador automático de cluster.
  • Métricas do Cloud Monitoring: agregam métricas de série temporal que fornecem tendências de alto nível sobre tentativas, falhas e pods pendentes de provisionamento de nós em ComputeClasses.

Requisitos

Para ver os eventos do escalonador automático, ative o Cloud Logging no cluster. Os eventos não serão produzidos se o Logging estiver desativado.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

  • Ative a API Google Kubernetes Engine.
    • Ativar a API Google Kubernetes Engine
  • Para usar a Google Cloud CLI nesta tarefa, instale e inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.

Como visualizar eventos

Os eventos de visibilidade do escalonador automático de cluster são armazenados em um registro do Cloud Logging, no mesmo projeto em que o cluster do GKE está localizado. Também é possível ver esses eventos nas notificações na página do Google Kubernetes Engine no Google Cloud console.

Como ver logs de eventos de visibilidade

Para ver os registros, faça o seguinte

  1. No console do Google Cloud , acesse a página de clusters do Kubernetes.

    Acesse os clusters do Kubernetes

  2. Selecione o nome do cluster para acessar a página Detalhes do cluster.

  3. Na página Detalhes do cluster, clique na guia Registros.

  4. Na guia Registros, clique em Registros do escalonador automático para ver os registros.

  5. (Opcional) Para aplicar filtros mais avançados para restringir os resultados, clique no botão com a seta no lado direito da página para visualizar os registros na Análise de registros.

Como ver notificações de eventos de visibilidade

Para ver as notificações de evento de visibilidade na página do Google Kubernetes Engine, faça o seguinte:

  1. Acesse a página do Google Kubernetes Engine no console do Google Cloud :

    Acessar o Google Kubernetes Engine

  2. Verifique a coluna Notificações para clusters específicos para encontrar notificações relacionadas ao escalonamento.

  3. Clique na notificação para ver informações detalhadas, ações recomendadas e acessar os registros desse evento.

Monitorar o status de pod pendente com o Cloud Monitoring

Disponível no GKE versão 1.37 e posterior, além de eventos de visibilidade, o escalonador automático de cluster do GKE exporta a métrica em tempo real kubernetes.io/autoscaler/cluster_pending_pods_per_ccc para o Cloud Monitoring. Essa métrica fornece uma contagem de pods no estado Pending, conforme visto e processado pelo escalonador automático de clusters, e está disponível para o tipo de recurso monitorado k8s_entity.

Essa métrica é útil principalmente para entender a demanda por diferentes ComputeClasses.

Marcadores principais

A métrica inclui os seguintes rótulos principais:

  • resource.labels.entity_type: o tipo de entidade, que é sempre ComputeClass para essa métrica.
  • resource.labels.entity_name: o nome da ComputeClass que os pods estão solicitando. Vazio ("") para pods sem uma ComputeClass específica.
  • metric.labels.reason: o estágio atual do pod na visualização do escalonador automático de cluster (unprocessed, provisioning_in_progress, unable_to_provision, no_action_taken).
  • metric.labels.type: o tipo de pod (system_pod ou user_pod).

Exemplos de casos de uso

Os exemplos a seguir mostram como consultar essa métrica com PromQL:

  • Acompanhe a demanda de escalonamento vertical por ComputeClass:

    sum by (entity_name) (
  kubernetes_io:autoscaler_cluster_pending_pods_per_ccc{
    monitored_resource="k8s_entity",
    entity_type="ComputeClass",
    type="user_pod"
  }
)

    Essa consulta mostra o total de pods de usuários pendentes para cada ComputeClass, indicando onde está a demanda de escalonamento atual.

  • Monitorar ampliações bloqueadas:

    sum by (entity_name, type) (
  kubernetes_io:autoscaler_cluster_pending_pods_per_ccc{
    monitored_resource="k8s_entity",
    entity_type="ComputeClass",
    reason="unable_to_provision"
  }
)

    Essa consulta ajuda a identificar rapidamente se alguma ComputeClass está com problemas em que o escalonador automático de cluster não consegue provisionar nós.

Ao analisar essa métrica, você pode receber insights sobre o backlog do escalonador automático de cluster e a capacidade dele de provisionar nós para diferentes tipos de carga de trabalho definidos pelas ComputeClasses. Para resolver problemas específicos de programação do ComputeClass, consulte Resolver problemas do ComputeClass.

Monitorar o provisionamento de nós

Disponíveis no GKE versão 1.37 e mais recentes, as seguintes métricas do Cloud Monitoring fornecem visibilidade das atividades de provisionamento de nós do escalonador automático de clusters, divididas por ComputeClasses. Essas métricas usam o tipo de recurso monitorado k8s_entity. Nesse tipo de recurso, o valor do rótulo resource.labels.entity_type é ComputeClass, e o valor do rótulo resource.labels.entity_name é o nome da ComputeClass que define o grupo de nós que está sendo provisionado. Uma string vazia ("") para o rótulo resource.labels.entity_name indica que o grupo de nós que está sendo provisionado não está associado a nenhuma ComputeClass específica.

Usar métricas e registros juntos

Para monitorar e diagnosticar possíveis problemas com o escalonador automático de cluster, use uma combinação de métricas e registros para realizar tarefas como as seguintes:

  • Identificar tendências e definir alertas com métricas: use as métricas do Cloud Monitoring para monitorar a integridade agregada do provisionamento, visualizar tendências ao longo do tempo e configurar políticas de alertas (como alertas sobre picos em falhas de provisionamento ou esgotamento de cotas).
  • Investigue as causas raiz com registros: as tentativas de escalonamento vertical com falha também geram entradas de registro de visibilidade (como eventos noScaleUp ou eventResult) no Cloud Logging. Quando as métricas indicam um aumento nas falhas durante um período, inspecione os registros correspondentes para ver os pods específicos, os pools de nós de destino e as mensagens de erro detalhadas.

Monitorar tentativas de provisionamento de nós

A métrica kubernetes.io/autoscaler/cluster_node_provisioning_attempts_count_per_ccc rastreia a frequência com que o escalonador automático tenta adicionar nós a um grupo de nós definido por uma ComputeClass específica. Uma string vazia ("") para o rótulo resource.labels.entity_name indica que a atividade de provisionamento não está associada a nenhuma ComputeClass específica.

O exemplo de PromQL a seguir rastreia a atividade de escalonamento vertical por ComputeClass:

sum by (entity_name) (
  increase(
    kubernetes_io:autoscaler_cluster_node_provisioning_attempts_count_per_ccc{
      monitored_resource="k8s_entity",
      entity_type="ComputeClass"
    }[5m]
  )
)

Monitorar falhas de provisionamento de nós

A métrica kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc fornece uma contagem de tentativas de escalonamento vertical com falha. Use essa métrica para identificar gargalos ou erros de configuração na infraestrutura.

Os rótulos importantes para essa métrica incluem:

  • resource.labels.entity_name: o nome da ComputeClass que define o grupo de nós em que o provisionamento falhou. O valor ficará vazio ("") se o grupo de nós não for definido por uma ComputeClass específica.
  • metric.labels.reason: o código de string que representa o motivo da falha.

O exemplo de PromQL a seguir identifica os principais motivos de falha por ComputeClass:

sum by (reason, entity_name) (
  increase(
    kubernetes_io:autoscaler_cluster_node_provisioning_failed_attempts_count_per_ccc{
      monitored_resource="k8s_entity",
      entity_type="ComputeClass"
    }[1h]
  )
)

Motivos da falha (metric.labels.reason)

O rótulo metric.labels.reason na métrica kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc fornece um código de string que indica a causa da falha de provisionamento do nó. Para uma explicação detalhada de cada motivo e possíveis ações corretivas, consulte o guia de solução de problemas Interpretar motivos de falha.

Tipos de eventos

Todos os eventos registrados estão no formato JSON e podem ser encontrados no campo jsonPayload de uma entrada de registro. Todos os carimbos de data/hora nos eventos são carimbos de data/hora UNIX.

Veja um resumo dos tipos de eventos emitidos pelo escalonador automático de cluster:

Tipo de evento Descrição
status Ocorre periodicamente e descreve o tamanho de todos os pools de nós com escalonamento automático e o tamanho de destino de todos os pools de nós com escalonamento automático, conforme observado pelo escalonamento automático de cluster.
scaleUp Ocorre quando o escalonador automático de cluster aumenta o cluster.
scaleDown Ocorre quando o escalonador automático de cluster diminui o cluster.
eventResult Ocorre quando um evento scaleUp ou scaleDown é concluído com ou sem êxito.
nodePoolCreated Ocorre quando o escalonador automático de cluster com o provisionamento automático de nós ativado cria um novo pool de nós.
nodePoolDeleted Ocorre quando o escalonador automático de cluster com o provisionamento automático de nós ativado exclui um pool de nós.
noScaleUp Ocorre quando há pods não programáveis no cluster e o escalonador automático de cluster não consegue escalonar verticalmente o cluster para acomodar os pods.
noScaleDown Ocorre quando há nós impedidos de serem excluídos pelo escalonador automático de cluster.

Evento de status

Um evento status é emitido periodicamente e descreve o tamanho atual de todos os pools de nós com escalonamento automático e o tamanho de destino de todos os pools de nós com escalonamento automático, conforme observado pelo escalonamento automático de cluster.

Exemplo

A amostra de registro a seguir mostra um evento status:

{
  "status": {
    "autoscaledNodesCount": 4,
    "autoscaledNodesTarget": 4,
    "measureTime": "1582898536"
  }
}

Evento ScaleUp

Um evento scaleUp é emitido quando o escalonador automático de cluster aumenta o cluster. O escalonador automático aumenta o tamanho dos pools de nós do cluster escalonando verticalmente os grupos gerenciados de instâncias (MIGs) subjacentes dos pools de nós. Para saber mais sobre como funciona o escalonamento vertical, consulte Como funciona o escalonamento vertical? nas perguntas frequentes do escalonador automático de clusters do Kubernetes.

O evento contém informações sobre quais MIGs foram escalonados, por quantos nós e quais pods não programáveis acionaram o evento.

A lista de pods de acionamento é truncada para 50 entradas arbitrárias. O número real de pods de acionamento pode ser encontrado no campo triggeringPodsTotalCount.

Exemplo

A amostra de registro a seguir mostra um evento scaleUp:

{
  "decision": {
    "decideTime": "1582124907",
    "eventId": "ed5cb16d-b06f-457c-a46d-f75dcca1f1ee",
    "scaleUp": {
      "increasedMigs": [
        {
          "mig": {
            "name": "test-cluster-default-pool-a0c72690-grp",
            "nodepool": "default-pool",
            "zone": "us-central1-c"
          },
          "requestedNodes": 1
        }
      ],
      "triggeringPods": [
        {
          "controller": {
            "apiVersion": "apps/v1",
            "kind": "ReplicaSet",
            "name": "test-85958b848b"
          },
          "name": "test-85958b848b-ptc7n",
          "namespace": "default"
        }
      ],
      "triggeringPodsTotalCount": 1
    }
  }
}

Evento ScaleDown

Um evento scaleDown é emitido quando o escalonador automático de cluster diminui o cluster. Para saber mais sobre como funciona a reduzir escala vertical, consulte Como funciona a reduzir escala vertical? nas perguntas frequentes do escalonador automático de cluster do Kubernetes.

Os campos cpuRatio e memRatio descrevem a utilização da CPU e da memória do nó (percentual). Essa utilização é uma soma das solicitações de pods divididas pela alocação de nós, não pela utilização real.

A lista de pods removidos é truncada para 50 entradas arbitrárias. O número real de pods removidos pode ser encontrado no campo evictedPodsTotalCount.

Use a consulta a seguir para verificar se o escalonador automático de cluster reduziu os nós:

resource.type="k8s_cluster" \
resource.labels.location=COMPUTE_REGION \
resource.labels.cluster_name=CLUSTER_NAME \
log_id("container.googleapis.com/cluster-autoscaler-visibility") \
( "decision" NOT "noDecisionStatus" )

Substitua:

  • CLUSTER_NAME: o nome do cluster.

  • COMPUTE_REGION: a região do Compute Engine do cluster, como us-central1.

Exemplo

A amostra de registro a seguir mostra um evento scaleDown:

{
  "decision": {
    "decideTime": "1580594665",
    "eventId": "340dac18-8152-46ff-b79a-747f70854c81",
    "scaleDown": {
      "nodesToBeRemoved": [
        {
          "evictedPods": [
            {
              "controller": {
                "apiVersion": "apps/v1",
                "kind": "ReplicaSet",
                "name": "kube-dns-5c44c7b6b6"
              },
              "name": "kube-dns-5c44c7b6b6-xvpbk"
            }
          ],
          "evictedPodsTotalCount": 1,
          "node": {
            "cpuRatio": 23,
            "memRatio": 5,
            "mig": {
              "name": "test-cluster-default-pool-c47ef39f-grp",
              "nodepool": "default-pool",
              "zone": "us-central1-f"
            },
            "name": "test-cluster-default-pool-c47ef39f-p395"
          }
        }
      ]
    }
  }
}

Também é possível acessar o evento scale-down nos nós sem carga de trabalho em execução (geralmente apenas pods do sistema criados por DaemonSets).

Use a consulta a seguir para conferir os logs de eventos:

resource.type="k8s_cluster" \
resource.labels.project_id=PROJECT_ID \
resource.labels.location=COMPUTE_REGION \
resource.labels.cluster_name=CLUSTER_NAME \
severity>=DEFAULT \
logName="projects/PROJECT_ID/logs/events" \
("Scale-down: removing empty node")

Substitua:

  • PROJECT_ID: o ID do projeto.

  • CLUSTER_NAME: o nome do cluster.

  • COMPUTE_REGION: a região do Compute Engine do cluster, como us-central1.

Evento EventResult

Um evento eventResult é emitido quando um evento scaleUp ou scaleDown é concluído com ou sem êxito. Esse evento contém uma lista de IDs de evento (do campo eventId em eventos scaleUp ou scaleDown) e mensagens de erro. Uma mensagem de erro vazia indica que o evento foi concluído. Uma lista de eventos eventResult é agregada no campo results.

Para diagnosticar erros, consulte as seções Erros de ScaleUp e ScaleDown.

Exemplo

A amostra de registro a seguir mostra um evento eventResult:

{
  "resultInfo": {
    "measureTime": "1582878896",
    "results": [
      {
        "eventId": "2fca91cd-7345-47fc-9770-838e05e28b17"
      },
      {
        "errorMsg": {
          "messageId": "scale.down.error.failed.to.delete.node.min.size.reached",
          "parameters": [
            "test-cluster-default-pool-5c90f485-nk80"
          ]
        },
        "eventId": "ea2e964c-49b8-4cd7-8fa9-fefb0827f9a6"
      }
    ]
  }
}

Evento NodePoolCreated

Um evento nodePoolCreated é emitido quando o escalonador automático de cluster com o provisionamento automático de nós ativado cria um novo pool de nós. Esse evento contém o nome do pool de nós criado e uma lista dos respectivos MIGs. Se o pool de nós foi criado devido a um evento de scaleUp, o eventId do evento de scaleUp correspondente é incluído no campo triggeringScaleUpId.

Exemplo

A amostra de registro a seguir mostra um evento nodePoolCreated:

{
  "decision": {
    "decideTime": "1585838544",
    "eventId": "822d272c-f4f3-44cf-9326-9cad79c58718",
    "nodePoolCreated": {
      "nodePools": [
        {
          "migs": [
            {
              "name": "test-cluster-nap-n1-standard--b4fcc348-grp",
              "nodepool": "nap-n1-standard-1-1kwag2qv",
              "zone": "us-central1-f"
            },
            {
              "name": "test-cluster-nap-n1-standard--jfla8215-grp",
              "nodepool": "nap-n1-standard-1-1kwag2qv",
              "zone": "us-central1-c"
            }
          ],
          "name": "nap-n1-standard-1-1kwag2qv"
        }
      ],
      "triggeringScaleUpId": "d25e0e6e-25e3-4755-98eb-49b38e54a728"
    }
  }
}

Evento NodePoolDeleted

Um evento nodePoolDeleted é emitido quando o escalonador automático de cluster com o provisionamento automático de nós ativado exclui um pool de nós.

Exemplo

A amostra de registro a seguir mostra um evento nodePoolDeleted:

{
  "decision": {
    "decideTime": "1585830461",
    "eventId": "68b0d1c7-b684-4542-bc19-f030922fb820",
    "nodePoolDeleted": {
      "nodePoolNames": [
        "nap-n1-highcpu-8-ydj4ewil"
      ]
    }
  }
}

Evento NoScaleUp

Um evento noScaleUp é emitido periodicamente quando há pods não programáveis no cluster e o escalonador automático de cluster não consegue escalonar verticalmente o cluster para acomodar os pods.

  • Os eventos noScaleUp são de melhor esforço, ou seja, não cobrem todos os motivos possíveis para que o escalonador automático de cluster não possa escalonar verticalmente.
  • Os eventos noScaleUp são limitados para reduzir o volume de registros produzidos. Cada motivo persistente é emitido apenas a cada dois minutos.
  • Todos os motivos podem ser divididos arbitrariamente entre vários eventos. Por exemplo, não há garantia de que todos os motivos de MIG rejeitados para um único grupo de pods serão exibidos no mesmo evento.
  • A lista de grupos de pods não processados é truncada para 50 entradas arbitrárias. O número real de grupos de pods não processados pode ser encontrado no campo unhandledPodGroupsTotalCount.

Campos do motivo

Os campos a seguir ajudam a explicar por que a expansão não ocorreu:

  • reason: fornece um motivo global que impediu a expansão do escalonador automático de cluster. Consulte a seção Motivos de nível superior do NoScaleUp para mais detalhes.
  • napFailureReason: fornece um motivo global para impedir que o escalonador automático de cluster provisione pools de nós adicionais (por exemplo, o provisionamento automático de nós está desativado). Consulte a seção Motivos de provisionamento automático de nós de nível superior do NoScaleUp para mais detalhes.
  • skippedMigs[].reason: fornece informações sobre o motivo pelo qual um MIG específico foi ignorado. O escalonador automático de cluster ignora alguns MIGs de qualquer pod durante uma tentativa de escalonamento vertical (por exemplo, porque adicionar outro nó excederia os limites de recursos em todo o cluster). Consulte a seção Motivos no nível do MIG do NoScaleUp para mais detalhes.
  • unhandledPodGroups: contém informações sobre o motivo pelo qual um determinado grupo de pods não programáveis não aciona o escalonamento vertical. Os pods são agrupados pelo controlador imediato. Os pods sem um controlador estão no mesmo grupo. Cada grupo de pods contém um pod de exemplo arbitrário e o número de pods no grupo, além dos seguintes motivos:
    • napFailureReasons: motivos pelos quais o escalonador automático de cluster não pode provisionar um novo pool de nós para acomodar esse grupo de pods (por exemplo, os pods têm restrições de afinidade). Consulte a seção Motivos de provisionamento automático de nós no nível do pod NoScaleUp para mais detalhes.
    • rejectedMigs[].reason: motivos por MIG da razão pela qual o escalonador automático de cluster não pode aumentar o tamanho de um MIG específico para acomodar esse grupo de pods (por exemplo, o nó do MIG é muito pequeno para os pods). Consulte a seção Motivos no nível do MIG do NoScaleUp para mais detalhes.

Exemplo

A amostra de registro a seguir mostra um evento noScaleUp:

{
  "noDecisionStatus": {
    "measureTime": "1582523362",
    "noScaleUp": {
      "skippedMigs": [
        {
          "mig": {
            "name": "test-cluster-nap-n1-highmem-4-fbdca585-grp",
            "nodepool": "nap-n1-highmem-4-1cywzhvf",
            "zone": "us-central1-f"
          },
          "reason": {
            "messageId": "no.scale.up.mig.skipped",
            "parameters": [
              "max cluster cpu limit reached"
            ]
          }
        }
      ],
      "unhandledPodGroups": [
        {
          "napFailureReasons": [
            {
              "messageId": "no.scale.up.nap.pod.zonal.resources.exceeded",
              "parameters": [
                "us-central1-f"
              ]
            }
          ],
          "podGroup": {
            "samplePod": {
              "controller": {
                "apiVersion": "v1",
                "kind": "ReplicationController",
                "name": "memory-reservation2"
              },
              "name": "memory-reservation2-6zg8m",
              "namespace": "autoscaling-1661"
            },
            "totalPodCount": 1
          },
          "rejectedMigs": [
            {
              "mig": {
                "name": "test-cluster-default-pool-b1808ff9-grp",
                "nodepool": "default-pool",
                "zone": "us-central1-f"
              },
              "reason": {
                "messageId": "no.scale.up.mig.failing.predicate",
                "parameters": [
                  "NodeResourcesFit",
                  "Insufficient memory"
                ]
              }
            }
          ]
        }
      ],
      "unhandledPodGroupsTotalCount": 1
    }
  }
}

Evento NoScaleDown

Um evento noScaleDown é emitido periodicamente quando há nós impedidos de serem excluídos pelo escalonador automático de cluster.

  • Os nós que não podem ser removidos porque a utilização deles é alta não são incluídos nos eventos noScaleDown.
  • Os eventos NoScaleDown são de melhor esforço, ou seja, não cobrem todos os motivos possíveis para que o escalonador automático de cluster não possa reduzir escala vertical.
  • Os eventos NoScaleDown são limitados para reduzir o volume de registros produzidos. Cada motivo persistente será emitido apenas a cada dois minutos.
  • A lista de nós é truncada para 50 entradas arbitrárias. O número real de nós pode ser encontrado no campo nodesTotalCount.

Campos do motivo

Os campos a seguir ajudam a explicar por que a redução de escala vertical não ocorreu:

  • reason: fornece um motivo global que impediu a redução do escalonador automático de cluster (por exemplo, um período de espera após uma expansão recente). Consulte a seção Motivos de nível superior do NoScaleDown para mais detalhes.
  • nodes[].reason: fornece motivos por nó para impedir que o escalonador automático de cluster exclua um nó específico (por exemplo, não há um lugar para mover os pods). Consulte a seção Motivos no nível do nó do NoScaleDown para mais detalhes.

Exemplo

A amostra de registro a seguir mostra um evento noScaleDown:

{
  "noDecisionStatus": {
    "measureTime": "1582858723",
    "noScaleDown": {
      "nodes": [
        {
          "node": {
            "cpuRatio": 42,
            "mig": {
              "name": "test-cluster-default-pool-f74c1617-grp",
              "nodepool": "default-pool",
              "zone": "us-central1-c"
            },
            "name": "test-cluster-default-pool-f74c1617-fbhk"
          },
          "reason": {
            "messageId": "no.scale.down.node.no.place.to.move.pods"
          }
        }
      ],
      "nodesTotalCount": 1,
      "reason": {
        "messageId": "no.scale.down.in.backoff"
      }
    }
  }
}

Mensagens

Os eventos emitidos pelo escalonador automático de cluster usam mensagens parametrizadas para fornecer explicações ao evento. O campo parameters está disponível com o campo messageId, como neste registro de exemplo de um evento NoScaleUp.

Esta seção fornece descrições para vários messageId e os parâmetros correspondentes. No entanto, esta seção não contém todas as mensagens possíveis e pode ser estendida a qualquer momento.

Erros de ScaleUp

As mensagens de evento de erro para eventos scaleUp estão no evento eventResult correspondente, no campo resultInfo.results[].errorMsg.

Quando uma operação de escalonamento vertical falha porque excede uma cota, é um erro de criação de nó que aciona um período de espera do sistema, que pode durar até 30 minutos. Para mais informações, consulte Períodos de backoff.

Mensagem Detalhes Parâmetros Mitigação
"scale.up.error.out.of.resources" Erros de recurso ocorrem quando você tenta solicitar novos recursos em uma zona que não pode acomodar a solicitação devido à indisponibilidade atual de um recurso do Compute Engine, como GPUs ou CPUs. IDs MIG com falha. Siga as etapas de solução de problemas de disponibilidade de recursos na documentação do Compute Engine.
"scale.up.error.quota.exceeded" O evento scaleUp falhou porque não foi possível aumentar alguns dos MIGs devido ao excesso da cota do Compute Engine. IDs de MIG com falha. Verifique a guia Erros do MIG no console do Google Cloud para ver qual cota está sendo excedida. Depois de saber qual cota foi excedida, siga as instruções para solicitar um aumento da cota.
"scale.up.error.waiting.for.instances.timeout" O escalonamento vertical do grupo gerenciado de instâncias falhou devido ao tempo limite. IDs de MIG com falha. Se as instâncias forem inicializadas, mas não forem registradas no plano de controle, siga as etapas de solução de problemas de registro de instâncias. Essa mensagem deve ser temporária. Se o problema persistir, entre em contato com o Cloud Customer Care para realizar uma investigação mais detalhada.
"scale.up.error.ip.space.exhausted" Não foi possível escalonar verticalmente porque as instâncias de alguns dos grupos gerenciados de instâncias ficaram sem IPs. Isso significa que o cluster não tem espaço de endereços IP não alocado suficiente para adicionar novos nós ou pods. IDs MIG com falha. Siga as etapas de solução de problemas em Não há espaço de endereços IP suficiente para o pod.
"scale.up.error.service.account.deleted" Não foi possível escalonar verticalmente porque a conta de serviço foi excluída. IDs de MIG com falha. Tente cancelar a exclusão da conta de serviço. Se esse procedimento não funcionar, entre em contato com o Cloud Customer Care para realizar uma investigação mais detalhada.

Motivos para um evento noScaleUp

Um evento noScaleUp é emitido periodicamente quando há pods não programáveis no cluster e o escalonador automático de cluster não consegue escalonar verticalmente o cluster para acomodar os pods. Os eventos noScaleUp não cobrem todos os casos possíveis.

Motivos de nível superior NoScaleUp

Mensagens de motivo de nível superior para eventos noScaleUp aparecem no campo noDecisionStatus.noScaleUp.reason. A mensagem contém um motivo de nível superior com o motivo pelo qual o escalonador automático de cluster não pode escalonar o cluster.

Mensagem Detalhes Mitigação
"no.scale.up.in.backoff" Não é possível escalonar verticalmente porque o escalonamento está em um período de espera (temporariamente bloqueado). Essa mensagem pode ocorrer durante eventos escalonar verticalmente com um grande número de pods. Essa mensagem deve ser temporária. Verifique esse erro depois de alguns minutos. Se a mensagem persistir, entre em contato com o Cloud Customer Care para realizar uma investigação mais detalhada.

Motivos de provisionamento automático de nós de nível superior NoScaleUp

Mensagens com o motivo de provisionamento automático de nós de nível superior para eventos noScaleUp aparecem no campo noDecisionStatus.noScaleUp.napFailureReason. A mensagem contém um motivo de nível superior com o motivo pelo qual o escalonador automático de cluster não pode provisionar novos pools de nós.

Mensagem Detalhes Mitigação
"no.scale.up.nap.disabled"

O provisionamento automático de nós não foi escalonado verticalmente porque não está ativado no nível do cluster.

Se o provisionamento automático de nós estiver desativado, os novos nós não serão provisionados automaticamente se o pod pendente tiver requisitos que não podem ser atendidos por nenhum dos pools de nós atuais.

 Verifique a configuração do cluster e consulte Como ativar o provisionamento automático de nós.

Motivos no nível MIG NoScaleUp

As mensagens de motivo no nível MIG de eventos noScaleUp aparecem nos campos noDecisionStatus.noScaleUp.skippedMigs[].reason e noDecisionStatus.noScaleUp.unhandledPodGroups[].rejectedMigs[].reason. A mensagem contém um motivo pelo qual o escalonador automático de cluster não pode aumentar o tamanho de um MIG específico.

Mensagem Detalhes Parâmetros Mitigação
"no.scale.up.mig.skipped" Não é possível escalonar verticalmente um MIG porque ele foi ignorado durante a simulação. Motivos para o MIG ter sido ignorado (por exemplo, falta de um requisito de pod). Avalie os parâmetros incluídos na mensagem de erro e verifique por que o MIG foi ignorado.
"no.scale.up.mig.failing.predicate" Não é possível escalonar verticalmente um pool de nós porque há falha em um predicado de programação dos pods pendentes. Nome do predicado com falha e motivos da falha. Verifique os requisitos de pod, como regras de afinidade, taints ou tolerâncias, e os recursos necessários.

Motivos de provisionamento automático de nós no nível do grupo de pods NoScaleUp

As mensagens com o motivo do provisionamento automático de nós no nível do grupo de pods dos eventos noScaleUp aparecem no campo noDecisionStatus.noScaleUp.unhandledPodGroups[].napFailureReasons[]. A mensagem contém um motivo pelo qual o escalonador automático de cluster não pode provisionar um novo pool de nós para programar um determinado grupo de pods.

Mensagem Detalhes Parâmetros Mitigação
"no.scale.up.nap.pod.gpu.no.limit.defined" O provisionamento automático de nós não pôde provisionar nenhum grupo de nós porque um pod pendente tem uma solicitação de GPU, mas os limites de recursos da GPU não estão definidos no nível do cluster. Tipo de GPU solicitada. Avalie a solicitação de GPU pendente do pod e atualize a configuração de limites de GPU do provisionamento automático de nós no nível do cluster.
"no.scale.up.nap.pod.gpu.type.not.supported" O provisionamento automático de nós não provisionou nenhum grupo de nós para o pod porque ele tem solicitações para um tipo de GPU desconhecido. Tipo de GPU solicitada. Na configuração do pod pendente, verifique se o tipo de GPU informado é um dos tipos com suporte.
"no.scale.up.nap.pod.zonal.resources.exceeded" O provisionamento automático de nós não provisionou nenhum grupo de nós para o pod nesta zona porque isso violaria os limites máximos de recursos em todo o cluster, excederia os recursos disponíveis na zona ou não é um tipo de máquina capaz de atender à solicitação. Nome da zona considerada. Avalie e atualize os limites máximos de recursos de todo o cluster, as solicitações de recursos do pod ou as zonas disponíveis para provisionamento automático de nós.
"no.scale.up.nap.pod.zonal.failing.predicates" O provisionamento automático de nós não provisionou nenhum grupo de nós para o pod nessa zona por causa de predicados com falha. Nome da zona considerada e motivos da falha dos predicados. Verifique os requisitos pendentes do pod, como regras de afinidade, taints, tolerâncias ou recursos necessários.

Erros de ScaleDown

As mensagens de evento de erro para eventos scaleDown estão no evento eventResult correspondente, no campo resultInfo.results[].errorMsg.

Mensagem de evento Detalhes Parâmetro Mitigação
"scale.down.error.failed.to.mark.to.be.deleted" Não foi possível marcar um nó para ser excluído. Nome do nó com falha. Essa mensagem deve ser temporária. Se o problema persistir, entre em contato com o Cloud Customer Care para realizar uma investigação mais detalhada.
"scale.down.error.failed.to.evict.pods" O escalonador automático de clusters não pode ser reduzido verticalmente porque alguns dos pods não podem ser removidos de um nó. Nome do nó com falha. Revise o PodDisruptionBudget do pod e verifique se as regras permitem a remoção de réplicas do aplicativo quando aceitável. Para saber mais, consulte Como especificar um orçamento de interrupção para seu aplicativo na documentação do Kubernetes.
"scale.down.error.failed.to.delete.node.min.size.reached" O escalonador automático de clusters não reduziu verticalmente porque não foi possível excluir um nó. Isso aconteceu porque o cluster já está com o tamanho mínimo. Nome do nó com falha. Revise o valor mínimo definido para o escalonamento automático do pool de nós e ajuste as configurações conforme necessário. Para saber mais, consulte o Erro: os nós no cluster atingiram o tamanho mínimo.

Motivos para um evento noScaleDown

Um evento noScaleDown é emitido periodicamente quando há nós impedidos de serem excluídos pelo escalonador automático de clusters. Os eventos noScaleDown são baseados no melhor esforço e não cobrem todos os casos possíveis.

Motivos de nível superior NoScaleDown

Mensagens de motivo de nível superior para eventos noScaleDown aparecem no campo noDecisionStatus.noScaleDown.reason. A mensagem contém um motivo de nível superior que explica por que o escalonador automático de clusters não pode reduzir o cluster.

Mensagem de evento Detalhes Mitigação
"no.scale.down.in.backoff" O escalonador automático de clusters não pode reduzir escala vertical porque a redução de escala vertical está em um período de espera (temporariamente bloqueado).

Essa mensagem deve ser temporária e pode ocorrer quando há um evento de escalonamento vertical recente.

Se a mensagem persistir, entre em contato com o Cloud Customer Care para realizar uma investigação mais detalhada.
"no.scale.down.in.progress"

O escalonador automático de clusters não pode ser reduzido verticalmente porque uma redução anterior ainda estava em andamento.

 Essa mensagem deve ser temporária, já que o pod será removido. Se essa mensagem ocorrer com frequência, analise o período de carência do encerramento da redução de escala vertical dos pods que estão bloqueando. Para acelerar a resolução, também é possível excluir o pod se ele não for mais necessário.

Motivos no nível do nó NoScaleDown

Mensagens de motivo no nível do nó para eventos noScaleDown aparecem em noDecisionStatus.noScaleDown.nodes[].reason field. A mensagem contém um motivo pelo qual o escalonador automático de cluster não pode remover um nó específico.

Mensagem de evento Detalhes Parâmetros Mitigação
"no.scale.down.node.scale.down.disabled.annotation" O escalonador automático de cluster não pode remover um nó do pool de nós porque ele tem a anotação cluster-autoscaler.kubernetes.io/scale-down-disabled: true. N/A O escalonador automático de clusters pula nós com essa anotação sem considerar a utilização deles, e essa mensagem é registrada independentemente do fator de utilização do nó. Se você quiser que o escalonador automático de clusters reduzir escala vertical esses nós, remova a anotação.
"no.scale.down.node.node.group.min.size.reached"

O escalonador automático do cluster não pode ser reduzido quando o tamanho do grupo de nós excede o limite mínimo.

Isso acontece porque a remoção de nós violaria os limites mínimos de recursos em todo o cluster definidos nas configurações de provisionamento automático de nós.

 N/A Revise o valor mínimo definido para o escalonamento automático do pool de nós. Se você quiser que o escalonador automático do cluster reduzir escala vertical esse nó, ajuste o valor mínimo.
"no.scale.down.node.minimal.resource.limits.exceeded"

O escalonador automático de clusters não conseguiu reduzir a escala vertical dos nós porque isso violaria os limites mínimos de recursos em todo o cluster.

Estes são os limites de recursos definidos para o provisionamento automático de nós.

 N/A Revise seus limites de memória e vCPU e, se você quiser que o escalonador automático de clusters reduza verticalmente esse nó, diminua os limites.
"no.scale.down.node.no.place.to.move.pods" O escalonador automático de clusters não pode reduzir a escala vertical porque não há um lugar para mover pods. N/A Se você espera que o pod seja reprogramado, avalie os requisitos de programação dos pods no nó subutilizado para determinar se podem ser movidos para outro nó no cluster. Para saber mais, consulte Erro: não há lugar para mover os pods.
"no.scale.down.node.pod.not.backed.by.controller"

O pod está bloqueando a redução de escala vertical porque não é apoiado por um controlador.

Especificamente, o escalonador automático de cluster não consegue reduzir a escala vertical de um nó subutilizado porque um pod não tem um controlador reconhecido. Os controladores permitidos incluem ReplicationController, DaemonSet, Job, StatefulSet ou ReplicaSet.

 Nome do pod que está bloqueando. Defina a anotação "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" para o pod ou defina um controlador aceitável.
"no.scale.down.node.pod.not.safe.to.evict.annotation" Um pod no nó tem a anotação safe-to-evict=false. Nome do pod que está bloqueando. Se o pod puder ser removido com segurança, edite o manifesto dele e atualize a anotação para "cluster-autoscaler.kubernetes.io/safe-to-evict": "true".
"no.scale.down.node.pod.kube.system.unmovable" O pod está bloqueando a redução de escala vertical porque não tem DaemonSet, não é espelhado e não tem PodDisruptionBudget no namespace kube-system. Nome do pod que está bloqueando.

Nas versões do GKE anteriores à 1.32.4-gke.1236000, o escalonador automático de clusters não remove pods no namespace kube-system. A partir da versão 1.32.4-gke.1236000, o escalonador automático de cluster considera esses pods para remoção após uma hora da criação.

Para resolver esse problema, adicione um PodDisruptionBudget para os pods kube-system ou use uma combinação de taints e tolerâncias de pools de nós para separar os pods kube-system dos pods do aplicativo. Para saber mais, consulte Erro: não é possível remover o pod kube-system.
"no.scale.down.node.pod.not.enough.pdb" O pod está bloqueando a redução de escala vertical porque não tem PodDisruptionBudget suficiente. Nome do pod que está bloqueando. Analise o PodDisruptionBudget do pod e considere torná-lo menos restritivo. Para saber mais, consulte Erro: PodDisruptionBudget insuficiente.
"no.scale.down.node.pod.controller.not.found" O pod está bloqueando a redução de escala vertical porque o controlador (por exemplo, uma implantação ou ReplicaSet) não foi encontrado. N/A Para determinar quais ações foram realizadas e deixaram o pod em execução após a remoção do controlador, analise os registros. Para resolver esse problema, exclua o pod manualmente.
"no.scale.down.node.pod.unexpected.error" O pod está bloqueando a redução de escala vertical devido a um erro inesperado. N/A A causa raiz desse erro é desconhecida. Entre em contato com o Cloud Customer Care para realizar uma investigação mais detalhada.

A seguir