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	O Anthos Service Mesh usa o Escalonamento automático de pod horizontal (HPA, na sigla em inglês) (link em inglês).
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`. Por 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. Por 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:

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

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

Veja a mudança:
```
kubectl get hpa -n $NAMESPACE
```

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.

Observação: o valor de periodSeconds não pode ficar abaixo de 30.

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.