Esta página foi traduzida pela API Cloud Translation.

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 tempo de execução híbrido do Apigee no ficheiro overrides.yaml.

Serviço	Implementado como	Dimensionar
Cassandra	ApigeeDatastore (CRD)	Consulte o artigo Dimensionar o Cassandra.
Ingress/LoadBalancer	Implementação	O Cloud Service Mesh usa a escala automática horizontal de pods (HPAs).
Logger	DaemonSet	Os DaemonSets gerem réplicas de um pod em todos os nós, pelo que são dimensionados quando dimensiona os próprios pods.
MART Apigee Connect Watcher	ApigeeOrganization (CRD)	Para dimensionar através da configuração, aumente o valor da propriedade de configuração `replicaCountMin` da implementação para as secções `mart`, `watcher` e/ou `connectAgent`. Por exemplo: mart: replicaCountMax: 2 replicaCountMin: 1 watcher: replicaCountMax: 2 replicaCountMin: 1 connectAgent: replicaCountMax: 2 replicaCountMin: 1 Estas implementações usam um redimensionador automático horizontal de pods para a escala automática. Defina a propriedade `targetCPUUtilizationPercentage` do objeto de implementação para o limite de expansão. Quando este valor é excedido, o Kubernetes adiciona pods até ao valor de `replicaCountMax`. Para mais informações sobre a definição de propriedades de configuração, consulte o artigo Faça a gestão dos componentes do plano de tempo de execução.
Runtime Synchronizer UDCA	ApigeeEnvironment (CRD)	Para dimensionar através da configuração, aumente o valor da propriedade `replicaCountMin` para as estrofes `udca`, `synchronizer` e/ou `runtime` no ficheiro de substituições. Por exemplo: synchronizer: replicaCountMax: 10 replicaCountMin: 1 runtime: replicaCountMax: 10 replicaCountMin: 1 udca: replicaCountMax: 10 replicaCountMin: 1 Nota: estas alterações aplicam-se a TODOS os ambientes no ficheiro de substituições. Se quiser personalizar o dimensionamento para cada ambiente, consulte as Configurações avançadas abaixo. Estas implementações usam um redimensionador automático horizontal de pods para a escala automática. Defina a propriedade `targetCPUUtilizationPercentage` do objeto de implementação para o limite de expansão. Quando este valor é excedido, o Kubernetes adiciona pods até ao valor de `replicaCountMax`. Para mais informações sobre a definição de propriedades de configuração, consulte o artigo Faça a gestão dos componentes do plano de tempo de execução.

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, onde 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:

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. 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

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:

Métrica	Medida	Considerações
serverNioTaskWaitTime	Tempo de espera médio (em ms) da fila de processamento em instâncias de tempo de execução para pedidos de proxy na camada http.	Esta métrica mede o impacto do número e do tamanho da carga útil dos pedidos e das respostas de proxy.
serverMainTaskWaitTime	Tempo de espera médio (em ms) da fila de processamento em instâncias de tempo de execução para pedidos de proxy para processar políticas.	Esta métrica mede o impacto da complexidade nas políticas anexadas ao fluxo de pedidos de proxy.

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.

Nota: o valor de periodSeconds não deve ser inferior a 30.

Configure um ajuste de escala menos agressivo

Os valores de configuração hpaBehavior também podem ser reduzidos 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 que não acione o ajuste de escala com base em métricas. O comportamento de escalabilidade resultante é o mesmo que o da escalabilidade baseada na CPU. Por exemplo, pode usar a seguinte configuração para impedir o acionamento do ajuste de escala 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.

Os HPA mostram `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.