Como visualizar eventos do escalonador automático de clusters

Nesta página, descrevemos as decisões que o escalonador automático de cluster do Google Kubernetes Engine (GKE) toma sobre o escalonamento automático.

O escalonador automático de clusters do GKE emite eventos de visibilidade, que estão disponíveis como entradas de registro no Cloud Logging.

Observação: os eventos descritos neste guia são separados dos eventos do Kubernetes produzidos pelo escalonador automático de cluster.

Requisitos de disponibilidade

A capacidade de visualizar eventos registrados para o escalonador automático de cluster está disponível nas seguintes versões de cluster:

Tipo de evento Versão do cluster
status, scaleUp, scaleDown, eventResult 1.15.4-gke.7 e posterior
nodePoolCreated, nodePoolDeleted. 1.15.4-gke.18 e posterior
noScaleUp 1.16.6-gke.3 e posterior
noScaleDown 1.16.8-gke.2 e posterior

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.

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 Console do Google Cloud.

Como ver registros 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.

    Acessar os clusters do Kubernetes

  2. Selecione o nome do cluster para ver 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 no Explorador 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.

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 programados no cluster e o escalonador automático de cluster não pode escalonar 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 autoescalador aumenta o tamanho dos pools de nós do cluster aumentando os Grupos de instâncias gerenciadas (MIGs, na sigla em inglês) 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 redução, consulte Como funciona a redução de escala? 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 programados no cluster e o escalonador automático de cluster não pode escalonar o cluster para acomodar os pods.

  • Os eventos noScaleUp representam o melhor esforço, ou seja, esses eventos não apresentam todos os motivos possíveis que impedem o escalonamento automático vertical do cluster.
  • 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 do 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 representam o melhor esforço, ou seja, esses eventos não apresentam todos os motivos possíveis que impedem a redução do escalonamento automático do cluster.
  • 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 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 um escalonamento vertical 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"
      }
    }
  }
}

Solução de problemas de escalonamento

Esta seção fornece orientações sobre como depurar eventos de escalonamento.

O cluster não está escalonando verticalmente

Cenário: criei um pod no meu cluster, mas ele encontra-se travado no estado Pendente durante a última hora. O escalonador automático de cluster não provisionou novos nós para acomodar o pod.

Solução:

  1. No Explorador de registros, encontre os detalhes de registro dos eventos do escalonador automático de cluster, conforme descrito na seção Como visualizar eventos.

  2. Pesquise eventos scaleUp que contenham o pod desejado no campo triggeringPods. É possível filtrar as entradas de registro, incluindo a filtragem por um valor de campo JSON específico. Saiba mais em Consultas de registros avançados.

    1. Encontre um EventResult que contenha o mesmo eventId que o evento scaleUp.
    2. Observe o campo errorMsg e consulte a lista de possíveis mensagens de erro scaleUp.

    Exemplo de erro de ScaleUp: para um evento scaleUp, você descobre que o erro é "scale.up.error.quota.exceeded", o que indica que "Um evento scaleUp falhou porque alguns dos MIGs não puderam ser aumentados devido à cota em excesso". Para resolver o problema, revise as configurações de cota e aumente as configurações que estão perto de serem excedidas. O escalonador automático de cluster adiciona um novo nó e o pod é programado.

  3. Caso contrário, pesquise eventos noScaleUp e analise os seguintes campos:

    • unhandledPodGroups: contém informações sobre o pod (ou o controlador do pod).
    • reason: fornece motivos globais que indicam que o escalonamento vertical pode ser bloqueado.
    • skippedMigs: fornece motivos pelos quais alguns MIGs podem ser ignorados.

  4. Consulte as seguintes seções que contêm possíveis motivos para eventos noScaleUp:

    Exemplo de NoScaleUp: você encontrou um evento noScaleUp para o pod e todos os MIGs no campo rejectedMigs têm o ID da mensagem do mesmo motivo de "no.scale.up.mig.failing.predicate" com dois parâmetros: "NodeAffinity" e "node(s) did not match node selector". Depois de consultar a lista de mensagens de erro, você descobre que "não pode escalonar verticalmente um MIG porque um predicado falhou para ele"; os parâmetros são o nome do predicado com falha e o motivo da falha. Para resolver o problema, revise a especificação do pod e descubra que ele tem um seletor de nós que não corresponde a nenhum MIG no cluster. Exclua o seletor da especificação do pod e recrie o pod. O escalonador automático de cluster adiciona um novo nó e o pod é programado.

  5. Se não houver eventos noScaleUp, use outros métodos de depuração para resolver o problema.

O cluster não está reduzindo verticalmente

Cenário: tenho um nó no cluster que utilizou apenas 10% da CPU e da memória dele nos últimos dias. Apesar da baixa utilização, o escalonador automático de cluster não excluiu o nó conforme esperado.

Solução:

  1. No Explorador de registros, encontre os detalhes de registro dos eventos do escalonador automático de cluster, conforme descrito na seção Como visualizar eventos.
  2. Pesquise eventos scaleDown que contenham o pod desejado no campo nodesToBeRemoved. É possível filtrar as entradas de registro, incluindo a filtragem por um valor de campo JSON específico. Saiba mais em Consultas de registros avançados.
    1. No evento scaleDown, procure um evento EventResult que contenha o eventId associado.
    2. Observe o campo errorMsg e consulte a lista de possíveis mensagens de erro scaleDown.
  3. Caso contrário, pesquise eventos noScaleDown que tenham o nó desejado no campo nodes. Analise o campo reason para ver os motivos globais que indicam que a redução do escalonamento pode ser bloqueado.

  4. Consulte as seguintes seções que contêm possíveis motivos para eventos noScaleDown:

    Exemplo de NoScaleDown: você encontrou um evento noScaleDown que contém um motivo por nó para seu nó. O ID da mensagem é "no.scale.down.node.pod.has.local.storage" e há um único parâmetro: "test-single-pod". Depois de consultar a lista de mensagens de erro, você descobre que o "pod está bloqueando a redução porque solicita armazenamento local. Consulte as Perguntas frequentes do escalonador automático de cluster do Kubernetes e descubra que a solução é adicionar uma anotação "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" ao pod. Depois de aplicar a anotação, o escalonador automático de cluster diminui o cluster corretamente.

  5. Se não houver eventos noScaleDown, use outros métodos de depuração para resolver o problema.

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 erro para eventos scaleUp são encontradas no evento eventResult correspondente, no campo resultInfo.results[].errorMsg.

Mensagem Descrição Mitigação
"scale.up.error.out.of.resources" O evento scaleUp falhou porque alguns dos MIGs não puderam ser aumentados devido à falta de recursos.

Parâmetros: IDs MIG com falha.

 Siga as etapas de solução de problemas de disponibilidade de recursos.
"scale.up.error.quota.exceeded" O evento scaleUp falhou porque alguns dos MIGs não puderam ser aumentados devido à cota do Compute Engine excedida.

Parâmetros: IDs MIG com falha.

 Verifique a guia Erros do MIG no console do Google Cloud para ver qual quota está sendo excedida. Siga as instruções para solicitar um aumento de quota.
"scale.up.error.waiting.for.instances.timeout" O evento scaleUp falhou porque as instâncias em alguns dos MIGs não apareciam a tempo.

Parâmetros: IDs MIG com falha.

 Esta mensagem é temporária. Se o problema persistir, entre em contato com o suporte do Google Cloud para realizar uma investigação mais detalhada.
"scale.up.error.ip.space.exhausted" O evento scaleUp falhou porque o cluster não tem espaço suficiente de endereços IP não alocados para usar para adicionar novos nós ou pods.

Parâmetros: IDs MIG com falha.

 Consulte as etapas de solução de problemas para resolver a falta de espaço de endereço IP para os nós ou pods.
"scale.up.error.service.account.deleted" O evento scaleUp falhou porque a conta de serviço usada pelo escalonador automático de cluster foi excluída.

Parâmetros: IDs MIG com falha.

 Envolva o suporte do Google Cloud para uma investigação mais detalhada.

Erros de ScaleDown

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

Mensagem Descrição Mitigação
"scale.down.error.failed.to.mark.to.be.deleted" O evento scaleDown falhou porque não foi possível marcar um nó para exclusão.

Parâmetros: nome do nó com falha.

 Esta mensagem é temporária. Se o problema persistir, entre em contato com o suporte do Google Cloud para realizar uma investigação mais detalhada.
"scale.down.error.failed.to.evict.pods" Ocorreu uma falha no evento scaleDown porque alguns dos pods não puderam ser removidos de um nó.

Parâmetros: nome do nó com falha.

 Revise as práticas recomendadas para orçamentos de interrupção de pods para garantir que as regras permitam a remoção de réplicas de aplicativos quando aceitáveis.
"scale.down.error.failed.to.delete.node.min.size.reached" O evento scaleDown falhou porque não foi possível excluir um nó devido ao tamanho mínimo do cluster.

Parâmetros: 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.

Motivos para um event NoScaleUp

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 Descrição Mitigação
"no.scale.up.in.backoff" Ocorreu um noScaleUp porque o escalonamento vertical está em um período de espera (temporariamente bloqueado). Essa é uma mensagem temporária que pode ocorrer durante eventos de escalonamento vertical com um grande número de pods. Se a mensagem persistir, entre em contato com o suporte do Google Cloud para fazer 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 Descrição Mitigação
"no.scale.up.nap.disabled" O provisionamento automático de nós 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. Revise a configuração do cluster e consulte Como ativar o provisionamento automático de nós.

Motivos no nível MIG NoScaleUp

Mensagens de motivo no nível MIG para 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 Descrição Mitigação
"no.scale.up.mig.skipped" Não é possível escalonar um MIG porque ele foi ignorado durante a simulação.

Parâmetros: motivos legíveis por que ele foi ignorado (por exemplo, falta de um requisito de pod).

 Avalie os parâmetros incluídos na mensagem de erro e explique por que o MIG foi ignorado.
"no.scale.up.mig.failing.predicate" Não é possível escalonar verticalmente um MIG porque ele não atende aos requisitos de predicado dos pods pendentes.

Parâmetros: nome do predicado com falha, motivos legíveis da razão pela qual ele falhou.

 Avalie os requisitos de pod, como regras de afinidade, taints ou tolerâncias e requisitos de recursos.

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 para 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 acomodar um determinado grupo de pods.

Mensagem Descrição 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.

Parâmetros: tipo de GPU solicitado.

 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.

Parâmetros: tipo de GPU solicitado.

 Verifique a configuração do pod pendente para o tipo de GPU para garantir que ele corresponda a um tipo de GPU compatível.
"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.

Parâmetros: 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.

Parâmetros: nome da zona considerada, motivos legíveis da razão pela qual os predicados falharam.

 Avalie os requisitos pendentes do pod, como regras de afinidade, taints, tolerâncias ou requisitos de recursos.

Motivos para um evento NoScaleDown

Motivos de nível superior do 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 pelo qual o escalonador automático de cluster não pode reduzir o cluster.

Mensagem Descrição Mitigação
"no.scale.down.in.backoff" Ocorreu um evento noScaleDown porque a redução está em um período de espera (temporariamente bloqueado). Esse evento precisa ser temporário e pode ocorrer quando há um evento de escalonamento vertical recente. Siga as etapas de mitigação associadas aos motivos de nível inferior para a redução da escala vertical. Quando os motivos subjacentes forem resolvidos, o escalonador automático de clusters sairá da espera. Se a mensagem persistir depois de resolver os motivos subjacentes, entre em contato com o suporte do Google Cloud para uma investigação mais detalhada.
"no.scale.down.in.progress" Ocorreu um evento noScaleDown porque a redução de escala vertical será bloqueada até que o nó anterior programado para remoção seja excluído. Esse evento precisa ser temporário, já que o pod será removido à força. Se essa mensagem ocorre com frequência, você pode avaliar o valor gracefulTerminationPeriod da redução de escala vertical de bloqueio de pods. Se você quiser acelerar a resolução, também é possível excluir o pod caso ele não seja mais necessário.

Motivos no nível do nó NoScaleDown

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

Mensagem Descrição Mitigação
"no.scale.down.node.scale.down.disabled.annotation" O nó não pode ser removido porque tem uma anotação scale-down-disabled. Avalie a anotação que está impedindo a redução do escalonamento vertical seguindo as instruções nas perguntas frequentes do escalonador automático de cluster do Kubernetes.
"no.scale.down.node.node.group.min.size.reached" O nó não pode ser removido porque o grupo de nós já está no tamanho mínimo. Avalie e ajuste o valor mínimo definido para o escalonamento automático do pool de nós.
"no.scale.down.node.minimal.resource.limits.exceeded" A redução de escala vertical de um nó subutilizado está bloqueada porque isso violaria os limites mínimos de recursos em todo o cluster definidos para o provisionamento automático de nós. Avalie os limites mínimos de recursos em todo o cluster.
"no.scale.down.node.no.place.to.move.pods" A redução de escala vertical de um nó subutilizado está bloqueada porque está executando um pod que não pode ser movido para outro nó do cluster. 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. Essa mensagem é esperada quando você não espera reprogramar o pod porque não há outros nós que podem ser programados.
"no.scale.down.node.pod.not.backed.by.controller" O pod está bloqueando a redução em escala de um nó subutilizado porque o pod não tem um controlador conhecido para o escalonador automático de clusters do Kubernetes (ReplicationController, DaemonSet, Job, StatefulSet ou ReplicaSet). Saiba mais sobre as perguntas frequentes do escalonador automático de cluster do Kubernetes sobre quais tipos de pods podem impedir que o escalonador automático de clusters remova um nó.

Parâmetros: nome do pod de bloqueio.

 Defina uma anotação "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" para o pod ou um controlador (ReplicationController, DaemonSet, Job, StatefulSet ou ReplicaSet).
"no.scale.down.node.pod.has.local.storage" O pod está bloqueando a redução do escalonamento porque solicita armazenamento local. Saiba mais em Perguntas frequentes sobre o escalonador automático de cluster do Kubernetes sobre quais tipos de pods podem impedir que o escalonador automático de clusters remova um nó.

Parâmetros: nome do pod de bloqueio.

 Defina uma anotação "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" para o pod se os dados no armazenamento local do pod não forem essenciais.
"no.scale.down.node.pod.not.safe.to.evict.annotation" O pod está bloqueando a redução do escalonamento porque tem uma anotação "não seguro para remoção". Consulte as Perguntas frequentes do escalonador automático de cluster do Kubernetes para mais detalhes.

Parâmetros: nome do pod de bloqueio.

 Se o pod puder ser removido com segurança, 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 é um pod sem DaemonSet e não espelhado sem um PodDisruptionBudget no namespace kube-system.

Parâmetros: nome do pod de bloqueio.

 Siga as instruções nas perguntas frequentes do escalonador automático de cluster do Kubernetes para definir um PodDisruptionBudget e permitir que o escalonador automático de cluster mova pods no namespace kube-system.
"no.scale.down.node.pod.not.enough.pdb" O pod está bloqueando a redução de escala vertical porque não há PodDisruptionBudget suficiente. Consulte as Perguntas frequentes do escalonador automático de cluster do Kubernetes para mais detalhes.

Parâmetros: nome do pod de bloqueio.

 Avalie o PodDisruptionBudget do pod. Consulte Práticas recomendadas para PodDisruptionBudget. Talvez seja possível resolver a mensagem escalonando o aplicativo ou alterando PodDisruptionBudget para permitir mais pods indisponíveis.
"no.scale.down.node.pod.controller.not.found" O pod está bloqueando a redução de escala vertical porque o controlador (por exemplo, implantação ou ReplicaSet) não foi encontrado. Avalie os registros para determinar quais ações foram executadas e deixaram um pod em execução após a remoção do controlador. Para resolver isso, exclua o pod manualmente.
"no.scale.down.node.pod.unexpected.error" A redução em escala de um nó subutilizado está bloqueada porque está com um pod em estado de erro inesperado. Envolva o suporte do GCP para uma investigação mais detalhada.

A seguir