Dimensione e dimensione automaticamente os serviços de tempo de execução

Pode dimensionar a maioria dos serviços executados no Kubernetes a partir da linha de comandos ou numa substituição de configuração. Pode definir parâmetros de escalabilidade para os serviços de runtime híbrido do Apigee no ficheiro overrides.yaml.

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

synchronizer:
 replicaCountMax: 10
 replicaCountMin: 1
runtime:
 replicaCountMax: 10
 replicaCountMin: 1
udca:
 replicaCountMax: 10
 replicaCountMin: 1

Configurações avançadas

Em alguns cenários, pode ter de usar opções de dimensionamento avançadas. Exemplos de cenários:

• Definir diferentes opções de dimensionamento para cada ambiente. Por exemplo, onde env1 tem um minReplica de 5 e env2 tem um minReplica de 2.
• Definir diferentes opções de escalabilidade para cada componente num ambiente. Por exemplo, em que o componente udca tem um maxReplica de 5 e o componente synchronizer tem um maxReplica de 2.

O exemplo seguinte 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. Tenha em atenção que este exemplo pressupõe que kubectl está em 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. Valide a alteração:

   kubectl get hpa -n $NAMESPACE

Dimensionamento com base no ambiente

Por predefinição, o dimensionamento é descrito ao nível da organização. Pode substituir as predefinições especificando o dimensionamento específico do ambiente no ficheiro overrides.yaml, conforme mostrado no exemplo seguinte:

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

Escalabilidade baseada em métricas

Com o dimensionamento baseado em métricas, o tempo de execução pode usar métricas da CPU e da aplicação para dimensionar os pods apigee-runtime. A API Horizontal Pod Autoscaler (HPA) do Kubernetes usa o campo hpaBehavior para configurar os comportamentos de aumento e diminuição da escala do serviço de destino. O escalamento baseado em métricas não está disponível para outros componentes numa implementação híbrida.

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

O exemplo seguinte da secção runtime no ficheiro overrides.yaml ilustra os parâmetros padrão (e os intervalos permitidos) para dimensionar os pods apigee-runtime numa 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)
  

Configure um ajuste de escala mais agressivo

O aumento dos valores percent e pods da política de expansão resulta numa política de expansão mais agressiva. Da mesma forma, aumentar os valores percent e pods em scaleDown resulta numa política de redução 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 é aumentado para 5, o scaleUp.percent.value é aumentado para 30 e o scaleUp.pods.value é aumentado para 5.

Configure um ajuste de escala menos agressivo

Os valores de configuração hpaBehavior também podem ser diminuídos para implementar políticas de aumento e diminuição menos agressivas. 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, o scaleDown.percent.value é reduzido para 10, o scaleDown.pods.value é reduzido para 1 e o scaleUp.stablizationWindowSeconds é aumentado para 180.

Para mais informações sobre o ajuste de escala baseado em métricas através do campo hpaBehavior, consulte Políticas de ajuste de escala.

Desative o ajuste de escala com base em métricas

Embora o ajuste de escala com base em métricas esteja ativado por predefinição e não possa ser completamente desativado, pode configurar os limites das métricas a um nível em que o ajuste de escala com base em métricas não seja acionado. O comportamento de escalabilidade resultante é o mesmo que o da escalabilidade baseada na CPU. Por exemplo, pode usar a seguinte configuração para evitar o acionamento do escalamento baseado 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

Resolução de problemas

Esta secção descreve métodos de resolução de problemas para erros comuns que pode encontrar ao configurar o ajuste de escala e o ajuste de escala automático.

O HPA mostra unknown para os valores das métricas

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

kubectl describe hpa HPA_NAME

Quando executar o comando, substitua HPA_NAME pelo nome do HPA que quer ver.

O resultado mostra o objetivo e a utilização da CPU do serviço, o que indica que o ajuste de escala da CPU funciona na ausência do ajuste de escala baseado em métricas. Para o comportamento do HPA com vários parâmetros, consulte o artigo Escalamento com base em várias métricas.