Resolva problemas de escala automática horizontal de pods

Quando a escala automática de pods horizontal não funciona como esperado no Google Kubernetes Engine (GKE), as suas cargas de trabalho podem não ser dimensionadas corretamente. Este problema pode impedir que as aplicações processem a carga, o que pode causar problemas de desempenho ou interrupções. Pode ver que os pods não aumentam apesar da elevada utilização da CPU, os valores das métricas são apresentados como <unknown> no estado do HorizontalPodAutoscaler ou as operações de dimensionamento não ocorrem.

Use esta página para diagnosticar e resolver problemas comuns com o escalamento automático de pods horizontal, desde configurações incorretas iniciais nos objetos HorizontalPodAutoscaler a falhas mais complexas no pipeline de métricas. Seguindo estes passos de resolução de problemas, pode ajudar a garantir que as suas aplicações são dimensionadas de forma eficiente e fiável com base na procura, usando eficazmente o recurso de escala automática horizontal de pods.

Estas informações são importantes para os programadores de aplicações que configuram objetos HorizontalPodAutoscaler e precisam de garantir que as respetivas aplicações são dimensionadas corretamente. Também ajuda os administradores e os operadores da plataforma a resolver problemas com o pipeline de métricas ou a configuração do cluster que afetam todas as cargas de trabalho com escalabilidade automática. Para mais informações sobre as funções comuns e as tarefas de exemplo a que fazemos referência no conteúdo, consulte o artigo Funções e tarefas comuns de utilizadores do GKE. Google Cloud

Se já teve sintomas ou viu uma mensagem de erro, use a tabela seguinte para encontrar as orientações certas:

Sintoma Possível resolução
Sem redimensionamento, mas as condições do HorizontalPodAutoscaler são True Resolva problemas de um HorizontalPodAutoscaler saudável, mas que não responde
É apresentada uma mensagem de erro específica nos eventos HorizontalPodAutoscaler Resolva problemas comuns do redimensionador automático horizontal de pods
Métrica <unknown> Resolva problemas de métricas personalizadas e externas
Não está a reduzir recursos Resolva problemas de falhas na redução da escala do redimensionador automático horizontal de pods

Antes de começar

  • Certifique-se de que usa objetos HorizontalPodAutoscaler com cargas de trabalho escaláveis, como implementações e StatefulSets. Não pode usar o escalamento automático horizontal de pods com cargas de trabalho que não podem ser escaladas, por exemplo, DaemonSets.

  • Para receber as autorizações de que precisa para resolver problemas de escala automática de pods horizontal no GKE, que inclui a inspeção de objetos HorizontalPodAutoscaler e a visualização de registos de clusters, peça ao seu administrador para lhe conceder as seguintes funções de IAM no seu projeto:

    Para mais informações sobre a atribuição de funções, consulte o artigo Faça a gestão do acesso a projetos, pastas e organizações.

    Também pode conseguir as autorizações necessárias através de funções personalizadas ou outras funções predefinidas.

  • Configure a ferramenta de linhas de comando kubectl para comunicar com o seu cluster do GKE:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location LOCATION \
    --project PROJECT_ID

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do cluster.
    • LOCATION: a região ou a zona do Compute Engine (por exemplo, us-central1 ou us-central1-a) para o cluster.
    • PROJECT_ID: o ID do seu Google Cloud projeto.

Valide o estado e a configuração do redimensionador automático horizontal de pods

Comece a resolução de problemas inspecionando o estado e a configuração do objeto HorizontalPodAutoscaler. Esta verificação inicial ajuda a identificar e resolver configurações incorretas básicas, que são uma causa principal comum de problemas de escalabilidade.

Descreva o HorizontalPodAutoscaler

Para ver os cálculos em tempo real do HorizontalPodAutoscaler e as decisões de escalonamento recentes, use o comando kubectl describe hpa. Este comando fornece um resumo do objeto HorizontalPodAutoscaler e um registo Events que é útil para diagnosticar problemas:

kubectl describe hpa HPA_NAME -n NAMESPACE_NAME

Substitua o seguinte:

  • HPA_NAME: o nome do seu objeto HorizontalPodAutoscaler.
  • NAMESPACE_NAME: o espaço de nomes do seu objeto HorizontalPodAutoscaler.

O resultado é semelhante ao seguinte:

Name:                                                  php-apache-hpa
Reference:                                             Deployment/php-apache
Metrics: ( current / target )
  resource cpu on pods (as a percentage of request):   1% (1m) / 50%
Min replicas:                                          1
Max replicas:                                          10
Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     True    ReadyForNewScale    recommended size matches current size
  ScalingActive   True    ValidMetricFound    the HorizontalPodAutoscaler was able to successfully calculate a replica count
Events:
  Type     Reason              Age   From                       Message
  ----     ------              ----  ----                       -------
  Normal   SuccessfulRescale   39m   horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization...
  Normal   SuccessfulRescale   26m   horizontal-pod-autoscaler  New size: 1; reason: cpu resource utilization...

No resultado, as três secções seguintes ajudam a diagnosticar o problema:

  • Metrics: esta secção apresenta os valores das métricas atuais em comparação com os respetivos objetivos. Verifique aqui se o HorizontalPodAutoscaler está a receber dados. Um valor de métrica <unknown> indica que o HorizontalPodAutoscaler não obteve a métrica ou que o pipeline de métricas está danificado.
  • Conditions: esta verificação de estado de alto nível mostra se o HorizontalPodAutoscaler consegue obter métricas (AbleToScale) e fazer cálculos de escalabilidade (ScalingActive). Um estado False em qualquer uma destas condições indica uma falha.
  • Events: esta secção regista ações de escalonamento recentes, avisos e erros do controlador HorizontalPodAutoscaler. Geralmente, é o primeiro local onde pode encontrar mensagens de erro ou motivos específicos, como FailedGetScale ou FailedGetResourceMetric, que ajudam a descobrir a origem do problema.

Verifique o estado do HorizontalPodAutoscaler nas implementações

Para verificar o estado dos objetos HorizontalPodAutoscaler usados com as suas implementações, use a Google Cloud consola:

  1. Na Google Cloud consola, aceda à página Workloads.

    Aceda a Cargas de trabalho

  2. Clique no nome da implementação.

  3. Aceda ao separador Detalhes e encontre a secção Ajuste automático.

  4. Reveja o valor na linha Estado:

    • Uma marca de verificação verde significa que o HorizontalPodAutoscaler está configurado e pode ler as respetivas métricas.
    • Um triângulo âmbar significa que o HorizontalPodAutoscaler está configurado, mas está a ter problemas em ler as respetivas métricas. Este é um problema comum com métricas personalizadas ou externas. Para resolver este problema, diagnostique o motivo pelo qual as métricas não estão disponíveis. Para mais informações, consulte a secção Resolva problemas com métricas personalizadas e externas.

Para outros tipos de carga de trabalho, como StatefulSets, ou para mais detalhes, verifique o manifesto do objeto HorizontalPodAutoscaler.

Verifique o manifesto do HorizontalPodAutoscaler

O manifesto YAML do seu objeto HorizontalPodAutoscaler permite-lhe ver informações sobre a respetiva configuração e estado atual.

Para ver o manifesto YAML, selecione uma das seguintes opções:

Consola

  1. Na Google Cloud consola, aceda à página Explorador de objetos.

    Aceda ao navegador de objetos

  2. Na lista Tipos de objetos, selecione a caixa de verificação HorizontalPodAutoscaler e clique em OK.

  3. Navegue para o grupo de APIs autoscaling e, de seguida, clique na seta para expandir HorizontalPodAutoscaler.

  4. Clique no nome do objeto HorizontalPodAutoscaler que quer inspecionar.

  5. Reveja a secção YAML, que apresenta a configuração completa do objeto HorizontalPodAutoscaler.

kubectl

Execute o seguinte comando:

kubectl get hpa HPA_NAME -n NAMESPACE_NAME -o yaml

Substitua o seguinte:

  • HPA_NAME: o nome do seu objeto HorizontalPodAutoscaler.
  • NAMESPACE_NAME: o espaço de nomes do seu objeto HorizontalPodAutoscaler.

Depois de obter o manifesto, procure estas secções principais:

  • spec (a sua configuração):
    • scaleTargetRef: a carga de trabalho (como uma implementação) que o HorizontalPodAutoscaler deve dimensionar.
    • minReplicas e maxReplicas: as definições de réplica mínimas e máximas.
    • metrics: as métricas que configurou para o escalamento (por exemplo, utilização da CPU ou métricas personalizadas).
  • status (o estado em direto do HorizontalPodAutoscaler):
    • currentMetrics: os valores das métricas mais recentes que o HorizontalPodAutoscaler observou.
    • currentReplicas e desiredReplicas: o número atual de pods e o número para o qual o HorizontalPodAutoscaler quer dimensionar.
    • conditions: a secção mais valiosa para a resolução de problemas. Esta secção mostra o estado do HorizontalPodAutoscaler:
      • AbleToScale: indica se o HorizontalPodAutoscaler consegue encontrar o respetivo destino e métricas.
      • ScalingActive: mostra se o HorizontalPodAutoscaler tem autorização para calcular e realizar o dimensionamento.
      • ScalingLimited: mostra se o HorizontalPodAutoscaler quer dimensionar, mas está limitado pelas definições de minReplicas ou maxReplicas.

Use funcionalidades de registo avançadas

Para obter estatísticas mais detalhadas sobre o seu objeto HorizontalPodAutoscaler, use os seguintes tipos de registos:

  • Veja eventos do redimensionador automático horizontal de pods no Cloud Logging: use um filtro de registos para encontrar todos os eventos do redimensionador automático horizontal de pods para um cluster específico. Por exemplo:

    1. Na Google Cloud consola, aceda à página Explorador de registos.

      Aceda ao Explorador de registos

    2. No painel de consultas, introduza a seguinte consulta:

      resource.type="k8s_cluster"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
logName="projects/PROJECT_ID/logs/events"
jsonPayload.involvedObject.kind="HorizontalPodAutoscaler"`

      Substitua o seguinte:

      • CLUSTER_NAME: o nome do cluster ao qual o HorizontalPodAutoscaler pertence.
      • LOCATION: a região ou a zona do Compute Engine (por exemplo, us-central1 ou us-central1-a) para o cluster.
      • PROJECT_ID: o ID do seu projeto.

    3. Clique em Executar consulta e reveja o resultado.

  • Ver eventos do Horizontal Pod Autoscaler: estes registos fornecem registos estruturados e legíveis por humanos que explicam como o HorizontalPodAutoscaler calcula uma recomendação, oferecendo estatísticas detalhadas sobre o respetivo processo de tomada de decisões.

Resolva problemas de um HorizontalPodAutoscaler em bom estado de funcionamento, mas que não responde

Esta secção ajuda a diagnosticar o motivo pelo qual o HorizontalPodAutoscaler pode não estar a acionar ações de escalabilidade, mesmo quando parece estar em bom estado e não comunica erros no respetivo estado ou eventos.

Sintomas:

O HorizontalPodAutoscaler parece estar em bom estado, as respetivas condições comunicam True e não apresenta erros nos respetivos eventos. No entanto, continua a não realizar ações de escalabilidade.

Causa:

Vários fatores podem causar este comportamento esperado:

  • Limites de réplicas: o número atual de réplicas já atingiu o limite definido pelo campo minReplicas ou maxReplicas na configuração do HorizontalPodAutoscaler.
  • Intervalo de tolerância: o Kubernetes usa um intervalo de tolerância predefinido de 10% para evitar o escalamento em pequenas flutuações das métricas. O ajuste de escala só ocorre se a relação entre a métrica atual e a métrica de destino estiver fora do intervalo de 0,9 a 1,1. Por exemplo, se o alvo for 85% de CPU e a utilização atual for de 93%, a proporção é de aproximadamente 1,094 (93/85≈1,094). Uma vez que este valor é inferior a 1,1, a escala automática horizontal de pods não aumenta a escala.
  • Pods não preparados: o redimensionador automático horizontal de pods inclui apenas pods com um estado Ready nos respetivos cálculos de escalabilidade. Os pods que estão bloqueados com o estado Pending ou que não estão a tornar-se Ready (devido a falhas nas verificações de estado ou problemas de recursos) são ignorados e podem impedir o dimensionamento.
  • Atraso do período de sincronização: o controlador HorizontalPodAutoscaler verifica as métricas periodicamente. É normal um atraso de 15 a 30 segundos entre uma métrica que ultrapassa o limite e o início de uma ação de escalamento.
  • Latência de novas métricas: quando um HorizontalPodAutoscaler usa uma nova métrica personalizada pela primeira vez, pode ver uma latência única de vários minutos. Este atraso ocorre porque o sistema de monitorização (como o Cloud Monitoring) tem de criar a nova série cronológica quando o primeiro ponto de dados é escrito.
  • Cálculo de várias métricas: quando configura várias métricas, o Horizontal Pod Autoscaler calcula o número de réplicas necessário para cada métrica de forma independente e, em seguida, escolhe o valor calculado mais elevado como o número final de réplicas. Devido a este comportamento, a sua carga de trabalho é dimensionada para satisfazer as exigências da métrica com as necessidades mais elevadas. Por exemplo, se as métricas de CPU calcularem uma necessidade de 9 réplicas, mas uma métrica de pedidos por segundo calcular uma necessidade de 15, o redimensionador automático horizontal de pods dimensiona a implementação para 15 réplicas.

Resolução:

Experimente as seguintes soluções:

  • Limites de réplicas: verifique os valores minReplicas e maxReplicas no manifesto HorizontalPodAutoscaler ou no resultado do comando kubectl describe. Ajuste estes limites se estiverem a impedir o dimensionamento necessário.
  • Intervalo de tolerância: se for necessário o ajuste de escala dentro da tolerância predefinida, configure um valor de tolerância diferente. Caso contrário, aguarde que a métrica se mova para fora da proporção de 0,9 a 1,1.
  • Pods não preparados: investigue por que motivo os pods estão Pending ou não estão Ready e resolva os problemas subjacentes (por exemplo, restrições de recursos, falhas nas sondagens de prontidão). Para ver sugestões de resolução de problemas, consulte o artigo Depurar pods na documentação do Kubernetes.
  • Atraso no período de sincronização e latência de novas métricas: estas latências são normais. Aguarde que o período de sincronização seja concluído ou que a nova série cronológica da métrica personalizada seja criada.
  • Cálculo de várias métricas: este é o comportamento pretendido. Se o aumento da escala estiver a ocorrer com base numa métrica (como pedidos por segundo), está a substituir corretamente o cálculo inferior de outra métrica (como a CPU).

Resolva problemas relacionados com erros comuns do redimensionador automático horizontal de pods

As secções seguintes fornecem soluções para mensagens de erro específicas e motivos de eventos que pode encontrar ao inspecionar o estado do HorizontalPodAutoscaler. Normalmente, encontra estas mensagens na secção Events da saída do comando kubectl describe hpa.

Resolva problemas de erros de configuração do redimensionador automático horizontal de pods

Uma configuração incorreta no manifesto HorizontalPodAutoscaler, como um campo com erro de digitação ou configurações em conflito, causa os erros nesta secção.

Erro: métricas inválidas

Pode ver este erro quando a configuração de uma métrica num HorizontalPodAutoscaler está sintaticamente incorreta ou inconsistente.

Sintomas:

Se o HorizontalPodAutoscaler não conseguir calcular as réplicas necessárias devido a um problema de configuração, a respetiva secção Events mostra o motivo FailedComputeMetricsReplicas com uma mensagem semelhante à seguinte:

invalid metrics (1 invalid out of 1)

Causa:

Normalmente, este erro significa que existe uma discrepância entre a métrica type e o target que definiu no manifesto HorizontalPodAutoscaler. Por exemplo, pode ter especificado um type de Utilization, mas fornecido um valor alvo de averageValue em vez de averageUtilization.

Resolução:

Corrija o manifesto HorizontalPodAutoscaler para que o valor do campo target se alinhe com a métrica type:

  • Se type for Utilization, o valor no campo target tem de ser averageUtilization.
  • Se type for AverageValue, o valor no campo target tem de ser averageValue.

Erro: vários serviços a selecionar o mesmo destino

Pode ver este erro quando usa o escalamento automático baseado no tráfego que tem uma configuração de serviço incorreta para o HorizontalPodAutoscaler.

Sintomas:

Repara no seguinte erro:

multiple services selecting the same target of HPA_NAME: SERVICE_NAME

Esta saída inclui os seguintes valores:

  • HPA_NAME: o nome do HorizontalPodAutoscaler.
  • SERVICE_NAME: o nome de um serviço.

Causa:

A escala automática baseada no tráfego está configurada, mas mais do que um serviço do Kubernetes está a segmentar o campo scaleTargetRef do HorizontalPodAutoscaler. O ajuste de escala automático baseado no tráfego só suporta uma relação individual entre o serviço e a carga de trabalho com ajuste de escala automático.

Resolução:

Para corrigir este problema, certifique-se de que apenas o seletor de etiquetas de um serviço corresponde aos pods da sua carga de trabalho:

  1. Encontre as etiquetas de Pod da sua carga de trabalho:

    kubectl get deployment HPA_TARGET_DEPLOYMENT \
    -n NAMESPACE \
    -o jsonpath='{.spec.template.metadata.labels}'

    Substitua o seguinte:

    • HPA_TARGET_DEPLOYMENT: o nome da implementação que o HorizontalPodAutoscaler está a segmentar.
    • NAMESPACE: o espaço de nomes da implementação.

    O resultado é semelhante ao seguinte:

    {"app":"my-app", "env":"prod"}

  2. Encontre todos os serviços que correspondem a essas etiquetas revendo o campo spec.selector para todos os serviços no espaço de nomes.

    kubectl get services -n NAMESPACE -o yaml

    Identifique todos os serviços cujo seletor corresponda às etiquetas do passo anterior. Por exemplo, {"app": "my-app"} e {"app": "my-app", "env": "prod"} corresponderiam às etiquetas de Pod de exemplo.

  3. Resolva o conflito escolhendo uma das seguintes opções:

    • Torne o seletor do serviço pretendido único adicionando uma nova etiqueta única ao campo spec.template.metadata.labels da sua implementação. Em seguida, atualize o campo spec.selector do serviço destinado para incluir esta nova etiqueta.
    • Torne outros seletores de serviços mais restritivos alterando o campo spec.selector de todos os outros serviços em conflito para que sejam mais restritivos e deixem de corresponder aos pods da sua carga de trabalho.

  4. Aplique as alterações:

    kubectl apply -f MANIFEST_NAME

    Substitua MANIFEST_NAME pelo nome do ficheiro YAML que contém o manifesto do serviço ou da implementação atualizado.

Erro: a etiqueta não é permitida

Sintomas:

Repara no seguinte erro:

unable to fetch metrics from external metrics API: googleapi: Error 400: Metric label: 'LABEL_NAME' is not allowed

Neste resultado, LABEL_NAME é o nome da etiqueta incorreta.

Causa:

O manifesto HorizontalPodAutoscaler especifica uma chave de etiqueta inválida na secção metric.selector.matchLabels e o Cloud Monitoring não reconhece nem permite esta chave para a métrica.

Resolução:

Para resolver este problema, faça o seguinte:

  1. Identifique o nome da etiqueta não permitida na mensagem de erro.
  2. Remova ou corrija esta chave de etiqueta na secção metric.selector.matchLabels do manifesto HorizontalPodAutoscaler.
  3. Encontre uma chave de etiqueta válida e filtrável consultando a documentação do Cloud Monitoring para essa métrica.

Problema: vários HorizontalPodAutoscalers a segmentar a mesma carga de trabalho

A configuração de vários objetos HorizontalPodAutoscaler para gerir a mesma carga de trabalho provoca um comportamento de escalabilidade imprevisível e em conflito.

Sintomas:

Não existe um Condition ou um Reason específico no estado de um HorizontalPodAutoscaler que indique diretamente este conflito. Em alternativa, pode observar os seguintes sintomas:

  • A contagem de réplicas da carga de trabalho pode variar inesperadamente.
  • As decisões de escalabilidade podem não parecer corresponder às métricas definidas num único HorizontalPodAutoscaler.
  • Quando vê eventos, pode ver eventos alternados ou contraditórios SuccessfulRescale de diferentes objetos HorizontalPodAutoscaler.

Causa:

Este problema ocorre porque mais do que um objeto HorizontalPodAutoscaler no mesmo espaço de nomes especifica exatamente a mesma carga de trabalho no campo spec.scaleTargetRef. Cada HorizontalPodAutoscaler calcula independentemente o número de réplicas e tenta dimensionar a carga de trabalho com base no seu próprio conjunto de métricas e alvos. O Kubernetes não bloqueia esta configuração, mas leva a ajustes de escalabilidade irregulares porque os HorizontalPodAutoscalers competem entre si.

Resolução:

Para evitar conflitos, defina todas as métricas de escalonamento num único objeto HorizontalPodAutoscaler. Cada HorizontalPodAutoscaler calcula as necessidades de escalonamento a partir do seu próprio campo spec.metrics, pelo que a união dos mesmos permite que o objeto HorizontalPodAutoscaler escolhido considere todos os fatores, como a CPU e os pedidos por segundo, em conjunto:

  1. Para identificar os HorizontalPodAutoscalers que têm como alvo a mesma carga de trabalho, obtenha o manifesto YAML para cada objeto HorizontalPodAutoscaler. Preste especial atenção ao campo spec.scaleTargetRef na saída.

    kubectl get hpa -n NAMESPACE_NAME -o yaml

    Substitua NAMESPACE_NAME pelo espaço de nomes do seu objeto HorizontalPodAutoscaler.

    Procure instâncias em que diferentes recursos HorizontalPodAutoscaler tenham os mesmos valores para apiVersion, kind e name no respetivo campo scaleTargetRef.

  2. Consolidar métricas num único objeto HorizontalPodAutoscaler:

    1. Escolha um objeto HorizontalPodAutoscaler para manter. Este HorizontalPodAutoscaler é o que vai modificar.
    2. Examine a secção spec.metrics no manifesto de cada um dos outros objetos HorizontalPodAutoscaler que segmentam a mesma carga de trabalho.
    3. Copie as definições de métricas que quer manter das spec.metrics secções dos objetos HorizontalPodAutoscaler duplicados.
    4. Cole estas definições de métricas copiadas na matriz spec.metrics do HorizontalPodAutoscaler que decidiu manter.

  3. Aplique as alterações:

    kubectl apply -f MANIFEST_NAME

    Substitua MANIFEST_NAME pelo nome do manifesto HorizontalPodAutoscaler que decidiu manter.

  4. Elimine os outros objetos HorizontalPodAutoscaler que estavam a segmentar a mesma carga de trabalho:

    kubectl delete hpa DUPLICATE_MANIFEST_NAME -n NAMESPACE_NAME

    Substitua DUPLICATE_MANIFEST_NAME pelo nome do objeto HorizontalPodAutoscaler redundante que quer eliminar.

Resolva problemas de erros de carga de trabalho e de destino

Os erros nesta secção são causados pela implementação, pelo StatefulSet ou pelos pods que estão a ser dimensionados, e não pelo próprio objeto HorizontalPodAutoscaler.

Erro: não é possível obter a escala atual do destino

Pode ver este erro quando o HorizontalPodAutoscaler não consegue localizar ou aceder à carga de trabalho que deve dimensionar.

Sintomas:

A secção Events tem uma condição de FailedGetScale com uma mensagem semelhante à seguinte:

the HorizontalPodAutoscaler controller was unable to get the target's current scale: WORKLOAD_TYPE.apps "TARGET_WORKLOAD" not found

Esta saída inclui os seguintes valores:

  • WORKLOAD_TYPE: o tipo de carga de trabalho, como Deployment ou StatefulSet.
  • TARGET_WORKLOAD: o nome da carga de trabalho.

Causa:

O controlador HorizontalPodAutoscaler não consegue encontrar a carga de trabalho (como uma implementação ou um StatefulSet) que está configurado para gerir. Este problema é causado por um problema no campo scaleTargetRef no manifesto do HorizontalPodAutoscaler. O recurso especificado pode não existir, pode ter sido eliminado ou pode ter um erro ortográfico.

Resolução:

Experimente as seguintes soluções:

  1. Verifique o campo scaleTargetRef do manifesto do HorizontalPodAutoscaler: certifique-se de que o valor de name, kind e apiVersion no campo scaleTargetRef corresponde exatamente aos metadados correspondentes da sua carga de trabalho de destino. Se o nome da carga de trabalho estiver incorreto, atualize o campo scaleTargetRef do HorizontalPodAutoscaler para indicar o nome correto.
  2. Confirme que a carga de trabalho existe: certifique-se de que a carga de trabalho de destino existe no mesmo espaço de nomes que o HorizontalPodAutoscaler. Pode verificar esta situação com um comando como kubectl get deployment DEPLOYMENT_NAME. Se eliminou intencionalmente a carga de trabalho, elimine o objeto HorizontalPodAutoscaler correspondente para limpar o cluster. Se precisar de recriar a carga de trabalho, o HorizontalPodAutoscaler encontra-a automaticamente assim que estiver disponível, e o erro é resolvido.
  3. Verifique se o HorizontalPodAutoscaler e a carga de trabalho estão no mesmo espaço de nomes: o HorizontalPodAutoscaler e a respetiva carga de trabalho de destino têm de estar no mesmo espaço de nomes. Se se esquecer de especificar um espaço de nomes ao criar um objeto com comandos kubectl, o Kubernetes coloca o objeto no espaço de nomes default. Este comportamento pode causar uma incompatibilidade se o seu HorizontalPodAutoscaler estiver no espaço de nomes default enquanto a sua carga de trabalho estiver noutro espaço de nomes, ou vice-versa. Verifique o espaço de nomes de ambos os objetos e certifique-se de que correspondem.

Depois de o HorizontalPodAutoscaler localizar com êxito o respetivo destino, a condição AbleToScale passa a True e a mensagem muda para: the HorizontalPodAutoscaler controller was able to get the target's current scale.

Erro: não é possível calcular a contagem de réplicas

Pode ver este erro quando o HorizontalPodAutoscaler precisa de calcular o escalonamento com base na utilização de recursos, mas não tem as informações de base necessárias dos pods.

Sintomas:

A condição ScalingActive é False com um valor de Reason de FailedGetResourceMetric. Normalmente, também é apresentada uma mensagem semelhante à seguinte:

the HorizontalPodAutoscaler was unable to compute the replica count

Causa:

O Horizontal Pod Autoscaler tem de calcular a utilização de recursos como uma percentagem para dimensionar a carga de trabalho, mas não consegue fazer este cálculo porque falta pelo menos um contentor na especificação do pod com uma definição resources.requests para o recurso correspondente (cpu ou memory).

Resolução:

Para resolver este problema, atualize o manifesto do Pod na sua implementação, StatefulSet ou outro controlador para incluir um campo resources.requests para o recurso (cpu ou memory) que o HorizontalPodAutoscaler está a tentar dimensionar para todos os contentores no Pod. Por exemplo:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
...
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"

Erro: não é possível obter métricas do agrupamento de anúncios para o agrupamento de anúncios

Pode ver este erro quando existe um problema ao obter as métricas necessárias para que um HorizontalPodAutoscaler tome decisões de escalabilidade. Está frequentemente relacionado com as definições de recursos de agrupamentos.

Sintomas:

Observa uma mensagem persistente semelhante à seguinte:

unable to fetch pod metrics for pod

É normal ver esta mensagem temporariamente quando o servidor de métricas é iniciado.

Causa:

Para dimensionar com base na percentagem de utilização de recursos (como cpu ou memory), todos os contentores nos pods segmentados pelo objeto HorizontalPodAutoscaler têm de ter o campo resources.requests definido para esse recurso específico. Caso contrário, o HorizontalPodAutoscaler não pode fazer os cálculos necessários e não toma nenhuma ação relacionada com essa métrica.

Resolução:

Se estas mensagens de erro persistirem e notar que os pods não estão a ser dimensionados para a sua carga de trabalho, certifique-se de que especificou pedidos de recursos para cada contentor na sua carga de trabalho.

Resolva problemas de erros de disponibilidade de dados e da API Metrics

As secções seguintes ajudam a resolver erros que ocorrem quando o HorizontalPodAutoscaler tenta obter dados de uma API de métricas. Estes problemas podem variar desde falhas de comunicação internas do cluster, em que a API de métricas está indisponível, a consultas inválidas que o fornecedor de métricas rejeita (vistas frequentemente como erros HTTP ao nível 400).

Erro: não foram encontradas versões de métricas disponíveis conhecidas

Sintomas:

Repara no seguinte erro:

unable to fetch metrics from custom metrics API: no known available metric versions found

Causa:

Este erro indica uma falha de comunicação no cluster e não um problema com a origem das métricas (como o Cloud Monitoring). As causas comuns incluem o seguinte:

  • O servidor da API Kubernetes está temporariamente indisponível (por exemplo, durante uma atualização do cluster ou uma reparação do plano de controlo).
  • Os pods do adaptador de métricas (por exemplo, custom-metrics-stackdriver-adapter) não estão em bom estado, não estão em execução ou não estão registados corretamente no servidor da API.

Resolução:

Este problema é frequentemente temporário. Se o problema persistir, experimente as seguintes soluções:

  1. Verifique o estado do plano de controlo do Kubernetes:

    1. Na Google Cloud consola, veja o estado e o estado de funcionamento do cluster.

      1. Aceda à página Clusters do Kubernetes.

        Aceda aos clusters do Kubernetes

      2. Verifique as colunas Estado e Notificações do seu cluster.

      3. Clique em Notificações para procurar operações em curso, como atualizações ou reparações. O servidor da API pode estar brevemente indisponível durante estes horários.

    2. Reveja os registos de auditoria do Cloud para verificar se existem erros relacionados com os componentes do plano de controlo. Para informações sobre como ver estes registos, consulte as informações de registo de auditoria do GKE.

  2. Verifique o estado e os registos dos pods do adaptador de métricas: certifique-se de que os pods do adaptador de métricas estão no estado Running e não têm reinícios recentes:

    kubectl get pods -n custom-metrics,kube-system -o wide

    Se o estado de um Pod for diferente de Running ou tiver uma contagem de reinícios elevada, investigue o Pod para encontrar a causa principal. Para ver sugestões de resolução de problemas, consulte Depurar pods na documentação do Kubernetes.

  3. Confirme se as APIs de métricas estão registadas e disponíveis:

    kubectl get apiservice | grep metrics.k8s.io

    Se as APIs de métricas estiverem em bom estado, o resultado é semelhante ao seguinte:

    NAME                            SERVICE                                             AVAILABLE   AGE
v1beta1.custom.metrics.k8s.io   custom-metrics/custom-metrics-stackdriver-adapter   True        18d
v1beta1.external.metrics.k8s.io custom-metrics/custom-metrics-stackdriver-adapter   True        18d
v1beta1.metrics.k8s.io          kube-system/metrics-server                          True        18d

    Se a coluna AVAILABLE tiver um valor de False, a coluna Message no manifesto completo do APIService pode fornecer mais detalhes.

    Pode ver o manifesto completo com o seguinte comando:

    kubectl get apiservice API_SERVICE_NAME -o yaml

    Substitua API_SERVICE_NAME pelo nome do objeto APIService, como v1beta1.custom.metrics.k8s.io.

Erro: a consulta não devolve nenhuma série cronológica

Sintomas:

Repara no seguinte erro:

unable to fetch metrics from custom or external metrics API: googleapi: Error
400: The supplied filter [...] query will not return any time series

Causa:

A consulta enviada ao Cloud Monitoring era válida, mas não devolveu dados. Isto significa que não existem pontos de dados que correspondam ao seu filtro (o que é diferente de encontrar uma métrica com um valor de 0). O motivo mais provável para este problema é que a aplicação ou a carga de trabalho responsável pela geração da métrica personalizada não estava a escrever dados no Cloud Monitoring durante o período em que os erros foram comunicados.

Resolução:

Experimente as seguintes soluções:

  1. Validar configuração: certifique-se de que os nomes e as etiquetas das métricas no objeto HorizontalPodAutoscaler correspondem precisamente aos emitidos pela aplicação.
  2. Verifique as autorizações: confirme se a aplicação está configurada corretamente com as autorizações e os pontos finais da API necessários para publicar métricas no Cloud Monitoring.
  3. Confirme a atividade da aplicação: verifique se a aplicação responsável pela métrica estava operacional e a tentar enviar dados para o Cloud Monitoring durante o período em que ocorreram os avisos do Horizontal Pod Autoscaler.
  4. Investigue a existência de erros: verifique se existem erros explícitos nos registos da aplicação no mesmo período relacionados com a emissão de métricas, como falhas de ligação, credenciais inválidas ou problemas de formatação.

Resolva problemas com métricas personalizadas e externas

Quando o HorizontalPodAutoscaler se baseia em métricas de origens que não sejam a CPU ou a memória predefinidas, podem ocorrer problemas no pipeline de métricas personalizadas ou externas. Esta pipeline consiste no controlador HorizontalPodAutoscaler, no servidor da API de métricas do Kubernetes, no adaptador de métricas e na origem de métricas (por exemplo, Cloud Monitoring ou Prometheus), conforme mostrado no diagrama seguinte:

Linha de processamento de métricas do HPA a mostrar componentes: controlador do HPA, servidor da API Kubernetes, adaptador de métricas e origem de métricas.

Esta secção detalha como depurar este pipeline, desde o adaptador de métricas à origem de métricas.

Sintomas:

Os sintomas mais comuns de um problema no pipeline de métricas são os seguintes:

  • O valor da métrica é apresentado como <unknown>.
  • Os eventos HorizontalPodAutoscaler mostram erros como FailedGetExternalMetric ou FailedGetCustomMetric.

Causa:

Existe um problema no pipeline de métricas personalizadas ou externas.

Resolução:

Siga estes passos para ajudar a depurar o pipeline:

  1. Verifique se o adaptador de métricas está registado e disponível: o adaptador de métricas tem de se registar no servidor da API Kubernetes principal para publicar métricas. Esta ação é a forma mais direta de verificar se o adaptador está em execução e se o servidor da API consegue aceder ao mesmo:

    kubectl get apiservice | grep -E 'NAME|metrics.k8s.io'

    No resultado, deve ver as entradas v1beta1.custom.metrics.k8s.io ou v1beta1.external.metrics.k8s.io e um valor de True na coluna Available. Por exemplo:

    NAME                   SERVICE                      AVAILABLE   AGE
v1beta1.metrics.k8s.io kube-system/metrics-server   True        18d

    • Se o valor na coluna Available for False ou estiver em falta, é provável que o seu adaptador tenha falhado ou esteja configurado incorretamente. Verifique os registos do pod do adaptador no espaço de nomes kube-system ou custom-metrics para ver se existem erros relacionados com autorizações, conetividade de rede à origem da métrica ou mensagens que indicam que não foi possível encontrar a métrica.

    • Se o valor for True, avance para o passo seguinte.

  2. Consultar diretamente a API de métricas: se o adaptador estiver disponível, ignore o HorizontalPodAutoscaler e peça a métrica diretamente à API Kubernetes. Este comando testa todo o pipeline, desde o servidor da API ao adaptador de métricas até à origem de dados.

    Para consultar métricas externas, execute o seguinte comando:

    kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/NAMESPACE_NAME/METRIC_NAME" | jq .

    Para consultar métricas de pods personalizadas, execute o seguinte comando:

    kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/NAMESPACE_NAME/pods/*/METRIC_NAME" | jq .

    Substitua o seguinte:

    • NAMESPACE_NAME: o espaço de nomes onde os seus pods estão a ser executados.
    • METRIC_NAME: o nome da métrica personalizada ou externa que está a tentar consultar. Por exemplo, requests_per_second ou queue_depth.

  3. Analise o resultado do comando: o resultado dos comandos anteriores indica-lhe onde está o problema. Escolha o cenário que corresponde ao seu resultado:

    • Resposta JSON bem-sucedida com um valor: o pipeline de métricas está a funcionar corretamente. O problema é provavelmente um problema de configuração no manifesto do HorizontalPodAutoscaler. Verifique se existem erros ortográficos no nome da métrica ou matchLabels incorretos.

    • Error: Error from server (Service Unavailable): este erro indica normalmente um problema de conetividade de rede, que é frequentemente um problema de firewall em clusters que usam isolamento de rede.

      1. Identifique o serviço do adaptador de métricas. Normalmente, encontra-se no espaço de nomes custom-metrics ou kube-system:

        kubectl get service -n custom-metrics,kube-system | grep -E 'adapter|metrics'

      2. Encontre a porta que o adaptador está a escutar:

        kubectl get service ADAPTER_SERVICE -n ADAPTER_NAMESPACE -o yaml

        Substitua o seguinte:

        • ADAPTER_SERVICE: o nome do serviço Kubernetes associado ao adaptador de métricas que implementou. Este serviço é o serviço que encontrou no passo anterior. Este serviço expõe a funcionalidade do adaptador a outras partes do cluster, incluindo o servidor da API Kubernetes.
        • ADAPTER_NAMESPACE: o espaço de nomes onde reside o serviço do adaptador (por exemplo, custom-metrics ou kube-system).

      3. Encontre as regras de firewall de entrada para o plano de controlo do cluster:

        gcloud compute firewall-rules list \
    --filter="name~gke-CLUSTER_NAME-[0-9a-z]*-master"

        Substitua CLUSTER_NAME pelo nome do seu cluster.

      4. Adicione o targetPort do adaptador à regra:

        1. Descreva a regra atual para ver as portas permitidas existentes:

          gcloud compute firewall-rules describe FIREWALL_RULE_NAME

          Substitua FIREWALL_RULE_NAME pelo nome da regra de firewall que rege o tráfego de rede para o plano de controlo do cluster Kubernetes.

        2. Atualize a regra para adicionar a porta do adaptador à lista:

          gcloud compute firewall-rules update FIREWALL_RULE_NAME \
    --allow tcp:443,tcp:10250,tcp:ADAPTER_PORT

          Substitua ADAPTER_PORT pela porta de rede que o adaptador de métricas está a ouvir.

      5. Certifique-se de que as políticas de rede do Kubernetes não estão a bloquear o tráfego para os pods do adaptador de métricas:

        kubectl get networkpolicy -n custom-metrics,kube-system

        Reveja todas as políticas para garantir que permitem o tráfego de entrada do plano de controlo ou do servidor da API para o ADAPTER_SERVICE no ADAPTER_PORT.

    • Uma lista vazia []: este resultado significa que o adaptador está em execução, mas não consegue obter a métrica específica, o que indica um problema com a configuração do adaptador ou a própria origem da métrica.

      • Problemas com o pod do adaptador: inspecione os registos do pod do adaptador de métricas ou dos pods para ver se existem erros relacionados com chamadas da API, autenticação ou obtenção de métricas. Para inspecionar os registos, faça o seguinte:

        1. Encontre o nome do pod do adaptador:

          kubectl get pods -n ADAPTER_NAMESPACE

        2. Ver os respetivos registos:

          kubectl logs ADAPTER_POD_NAME \
    -n ADAPTER_NAMESPACE

          Substitua o seguinte:

          • ADAPTER_POD_NAME: o nome do agrupamento do adaptador que identificou no passo anterior.
          • ADAPTER_NAMESPACE: o espaço de nomes onde o pod do adaptador reside (por exemplo, custom-metrics ou kube-system).

      • Não existem dados na origem: a métrica pode não existir no sistema de origem. Use uma ferramenta de monitorização, como o Explorador de métricas, para confirmar que a métrica existe e tem o nome e as etiquetas corretos.

Resolva problemas de falha na redução da escala do redimensionador automático horizontal de pods

Esta secção ajuda a compreender por que motivo um HorizontalPodAutoscaler pode não estar a reduzir a escala da sua carga de trabalho conforme esperado.

Sintomas:

O HorizontalPodAutoscaler dimensiona com êxito a carga de trabalho, mas não a reduz, mesmo quando as métricas, como a utilização da CPU, são baixas.

Causa:

Este comportamento destina-se a evitar o aumento e a diminuição rápidos ou a diminuição com base em informações incompletas. Os dois motivos principais são os seguintes:

  • Usar várias métricas: o redimensionador automático de pods horizontal é dimensionado com base na métrica que requer o maior número de réplicas. Se tiver várias métricas, a carga de trabalho não é reduzida, a menos que todas as métricas indiquem que são necessárias menos réplicas. Uma métrica que exige um número elevado de réplicas impede a redução da escala, mesmo que outras sejam baixas.
  • Métricas indisponíveis: se alguma métrica ficar indisponível (apresentada frequentemente como <unknown>), o Horizontal Pod Autoscaler recusa-se conservadoramente a reduzir a escala da carga de trabalho. Não é possível determinar se a métrica está em falta porque o uso é realmente zero ou porque o pipeline de métricas está danificado. Este problema é comum com métricas personalizadas baseadas em taxas (por exemplo, messages_per_second), que podem parar de comunicar dados quando não existe atividade, o que faz com que o Horizontal Pod Autoscaler veja a métrica como indisponível e interrompa as operações de redução da escala.
  • Atraso na redução da política de escalabilidade: o campo behavior do HorizontalPodAutoscaler permite-lhe configurar políticas de escalabilidade. A política predefinida para a redução inclui um período de estabilização de 300 segundos (cinco minutos). Durante este período, o HorizontalPodAutoscaler não reduz a quantidade de réplicas, mesmo quando os valores das métricas tiverem ficado abaixo do limite de destino. Esta janela impede flutuações rápidas, mas pode tornar a redução mais lenta do que o esperado.

Resolução:

Experimente as seguintes soluções:

  1. Para várias métricas e métricas indisponíveis, diagnostique a métrica que está a causar problemas:

    kubectl describe hpa HPA_NAME -n NAMESPACE_NAME

    Na saída, procure na secção Metrics qualquer métrica com o estado <unknown> e na secção Events avisos como FailedGetCustomMetric ou FailedGetExternalMetric. Para uma depuração detalhada do pipeline, consulte a secção Resolva problemas de métricas personalizadas e externas.

  2. Para métricas indisponíveis, se uma métrica ficar indisponível durante períodos de tráfego baixo (comum com métricas baseadas em taxas), experimente uma das seguintes soluções:

    • Use métricas baseadas em indicadores em vez de métricas baseadas em taxas, sempre que possível. Uma métrica de indicador, como o número total de mensagens numa fila (por exemplo, subscription ou num_undelivered_messages), comunica consistentemente um valor, mesmo que esse valor seja 0, o que permite ao Horizontal Pod Autoscaler tomar decisões de escalabilidade de forma fiável.
    • Certifique-se de que a origem da métrica comunica valores zero. Se controlar a métrica personalizada, configure-a para publicar um 0 durante os períodos de inatividade, em vez de não enviar dados.

  3. Para atrasos na redução da escala da política de escalabilidade, se o período de estabilização predefinido de cinco minutos para reduções da escala for demasiado longo, personalize-o. Inspeccione a secção spec.behavior.scaleDown do manifesto HorizontalPodAutoscaler. Pode diminuir o stabilizationWindowSeconds para permitir que o ajuste de escala automático seja feito mais rapidamente após a diminuição das métricas. Para mais informações sobre a configuração destas políticas, consulte as Políticas de dimensionamento na documentação do Kubernetes.

O que se segue?