Escalonar e escalonar automaticamente serviços de ambiente de execução

Você pode escalonar a maioria dos serviços em execução no Kubernetes na linha de comando ou em uma modificação de configuração. É possível definir parâmetros de escalonamento para serviços de ambiente de execução da Apigee híbrida no arquivo overrides.yaml.

Serviço Implementado como Escalonamento
Cassandra ApigeeDatastore (CRD) Consulte Como escalonar o Cassandra
Entrada/LoadBalancer Implantação

Gerencie o escalonamento com ingressGateways.replicaCountMin e ingressGateways.replicaCountMax.

Logger DaemonSet DaemonSets gerenciam réplicas de um pod em todos os nós, para que eles sejam escalonados quando você mesmo dimensiona os pods.
Inspetor do
Apigee Connect
MART
ApigeeOrganization (CRD)

Para escalonar usando a configuração, aumente o valor da propriedade de configuração replicaCountMin da implantação das estrofes mart, watcher e/ou connectAgent. Exemplo:

mart:
 replicaCountMax: 2
 replicaCountMin: 1
watcher:
 replicaCountMax: 2
 replicaCountMin: 1
connectAgent:
 replicaCountMax: 2
 replicaCountMin: 1

Essas implantações usam um escalonador automático de pod horizontal para fazer escalonamento automático. Defina a propriedade targetCPUUtilizationPercentage do objeto de implantação como o limite do escalonamento vertical. Quando esse valor é excedido, o Kubernetes adiciona pods até o valor de replicaCountMax.

Para mais informações sobre como definir propriedades de configuração, consulte Gerenciar componentes do plano de execução.

UDCA do
sincronizador do
ambiente de execução
ApigeeEnvironment (CRD) Para escalonar usando a configuração, aumente o valor da propriedade replicaCountMin das estrofes udca, synchronizer e/ou runtime no arquivo de substituições. Exemplo:
synchronizer:
 replicaCountMax: 10
 replicaCountMin: 1
runtime:
 replicaCountMax: 10
 replicaCountMin: 1
udca:
 replicaCountMax: 10
 replicaCountMin: 1

Observação: essas alterações se aplicam a TODOS os ambientes do arquivo de substituições. Se você quiser personalizar o escalonamento de cada ambiente, consulte Configurações avançadas abaixo.

Essas implantações usam um escalonador automático de pod horizontal para fazer escalonamento automático. Defina a propriedade targetCPUUtilizationPercentage do objeto de implantação até o limite do escalonamento vertical. Quando esse valor é excedido, o Kubernetes adiciona pods até o valor de replicaCountMax.

Para mais informações sobre como definir propriedades de configuração, consulte Gerenciar componentes do plano de execução.

Configurações avançadas

Em alguns cenários, pode ser necessário usar opções avançadas de escalonamento. Exemplos de cenários:

  • Como definir diferentes opções de escalonamento para cada ambiente. Por exemplo, onde env1 tem minReplica de 5 e env2 tem minReplica de 2.
  • Como definir diferentes opções de escalonamento para cada componente dentro de um ambiente Por exemplo, onde o componente udca tem um maxReplica de 5 e o componente synchronizer tem um maxReplica de 2.

O exemplo a seguir mostra como usar o comando kubernetes patch para alterar a propriedade maxReplicas do componente runtime:

  1. Crie variáveis de ambiente para usar com o comando:
    export ENV=my-environment-name
    export NAMESPACE=apigee  #the namespace where apigee is deployed
    export COMPONENT=runtime #can be udca or synchronizer
    export MAX_REPLICAS=2
    export MIN_REPLICAS=1
  2. Aplique o patch. Observe que esse exemplo considera que kubectl está no seu PATH:
    kubectl patch apigeeenvironment -n $NAMESPACE \
      $(kubectl get apigeeenvironments -n $NAMESPACE -o jsonpath='{.items[?(@.spec.name == "'$ENV'" )]..metadata.name}') \
      --patch "$(echo -e "spec:\n  components:\n    $COMPONENT:\n      autoScaler:\n        maxReplicas: $MAX_REPLICAS\n        minReplicas: $MIN_REPLICAS")" \
      --type merge
  3. Veja a mudança:
    kubectl get hpa -n $NAMESPACE

Escalonamento baseado em ambiente

Por padrão, o escalonamento é descrito no nível da organização. É possível modificar as configurações padrão especificando o escalonamento específico do ambiente no arquivo overrides.yaml, conforme mostrado no exemplo a seguir:

envs:
# Apigee environment name
- name: test
  components:
  # Environment-specific scaling override
  # Otherwise, uses scaling defined at the respective root component
   runtime:
    replicaCountMin: 2
    replicaCountMax: 20

Escalonamento com base em métricas

Com o escalonamento baseado em métricas, o ambiente de execução pode usar métricas de CPU e aplicativo para escalonar os pods apigee-runtime. A API Escalonador automático horizontal de pods (HPA) do Kubernetes usa o campo hpaBehavior para configurar os comportamentos de escalonamento vertical e horizontal do serviço de destino. O escalonamento baseado em métricas não está disponível para outros componentes em uma implantação híbrida.

O escalonamento pode ser ajustado com base nas seguintes métricas:

Métrica Medir Considerações
serverNioTaskWaitTime Tempo médio de espera (em picossegundos) de fila de processamento em instâncias de ambiente de execução para solicitações de proxy na camada http. Essa métrica mede o impacto do número e do tamanho do payload das solicitações e respostas de proxy.
serverMainTaskWaitTime Tempo médio de espera (em picossegundos) de fila de processamento em instâncias de ambiente de execução para solicitações de proxy ao processar políticas. Essa métrica mede o impacto da complexidade nas políticas anexadas ao fluxo de solicitação de proxy.

O exemplo a seguir da estrofe runtime na overrides.yaml ilustra os parâmetros padrão (e intervalos permitidos) para o escalonamento de pods apigee-runtime em uma implementação híbrida:

hpaMetrics:
      serverMainTaskWaitTime: 400M (300M to 450M)
      serverNioTaskWaitTime: 400M (300M to 450M)
      targetCPUUtilizationPercentage: 75
    hpaBehavior:
      scaleDown:
        percent:
          periodSeconds: 60 (30 - 180)
          value: 20 (5 - 50)
        pods:
          periodSeconds: 60 (30 - 180)
          value: 2 (1 - 15)
        selectPolicy: Min
        stabilizationWindowSeconds: 120 (60 - 300)
      scaleUp:
        percent:
          periodSeconds: 60 (30 - 120)
          value: 20 (5 - 100)
        pods:
          periodSeconds: 60 (30 - 120)
          value: 4 (2 - 15)
        selectPolicy: Max
        stabilizationWindowSeconds: 30 (30 - 120)
  

Configurar escalonamentos mais agressivos

Aumentar os valores percent e pods da política de escalonamento vertical resultará em uma política de escalonamento mais agressiva. Da mesma forma, aumentar os valores percent e pods em scaleDown resultará em uma política de redução da escala vertical agressiva. Por exemplo:

hpaMetrics:
    serverMainTaskWaitTime: 400M
    serverNioTaskWaitTime: 400M
    targetCPUUtilizationPercentage: 75
  hpaBehavior:
    scaleDown:
      percent:
        periodSeconds: 60
        value: 20
      pods:
        periodSeconds: 60
        value: 4
      selectPolicy: Min
      stabilizationWindowSeconds: 120
    scaleUp:
      percent:
        periodSeconds: 60
        value: 30
      pods:
        periodSeconds: 60
        value: 5
      selectPolicy: Max
      stabilizationWindowSeconds: 30

No exemplo acima, o scaleDown.pods.value aumentou para 5, o scaleUp.percent.value aumentou para 30 e o scaleUp.pods.value aumentou. para 5.

Configurar escalonamento menos agressivo

Os valores de configuração de hpaBehavior também podem ser reduzidos para implementar políticas de redução ou redução da escala vertical mais baixas. Por exemplo:

hpaMetrics:
    serverMainTaskWaitTime: 400M
    serverNioTaskWaitTime: 400M
    targetCPUUtilizationPercentage: 75
  hpaBehavior:
    scaleDown:
      percent:
        periodSeconds: 60
        value: 10
      pods:
        periodSeconds: 60
        value: 1
      selectPolicy: Min
      stabilizationWindowSeconds: 180
    scaleUp:
      percent:
        periodSeconds: 60
        value: 20
      pods:
        periodSeconds: 60
        value: 4
      selectPolicy: Max
      stabilizationWindowSeconds: 30

No exemplo acima, a scaleDown.percent.value é reduzida para 10, a scaleDown.pods.value é reduzida para 1, e o scaleUp.stablizationWindowSeconds é aumentado para 180.

Para mais informações sobre escalonamento baseado em métricas usando o campo hpaBehavior, consulte Políticas de escalonamento.

Desativar o escalonamento baseado em métricas

Embora o escalonamento baseado em métricas seja ativado por padrão e não possa ser completamente desativado, é possível configurar os limites de métricas em um nível em que o escalonamento com base em métricas não será acionado. O comportamento de escalonamento resultante será igual ao baseado na CPU. Por exemplo, é possível usar a seguinte configuração para evitar o escalonamento com base em métricas:

hpaMetrics:
      serverMainTaskWaitTime: 4000M
      serverNioTaskWaitTime: 4000M
      targetCPUUtilizationPercentage: 75
    hpaBehavior:
      scaleDown:
        percent:
          periodSeconds: 60
          value: 10
        pods:
          periodSeconds: 60
          value: 1
        selectPolicy: Min
        stabilizationWindowSeconds: 180
      scaleUp:
        percent:
          periodSeconds: 60
          value: 20
        pods:
          periodSeconds: 60
          value: 4
        selectPolicy: Max
        stabilizationWindowSeconds: 30

Solução de problemas

Esta seção descreve métodos de solução de problemas para erros comuns que podem ocorrer durante a configuração do escalonamento automático e do escalonamento automático.

O HPA mostra unknown para os valores das métricas

Se o escalonamento baseado em métricas não funcionar e o HPA mostrar unknown para valores de métricas, use o seguinte comando para verificar a saída do HPA:

kubectl describe hpa HPA_NAME

Ao executar o comando, substitua HPA_NAME pelo nome do HPA que você quer visualizar.

A saída mostrará o destino da CPU e a utilização do serviço, indicando que o escalonamento da CPU funcionará na ausência do escalonamento baseado em métricas. Para saber mais sobre o comportamento do HPA usando vários parâmetros, consulte Escalonamento em várias métricas.