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 runtime 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 cláusulas `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, 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:

Crie variáveis de ambiente para usar com o comando:

export ENV_NAME=my-environment-name
export ENV_RELEASE_NAME=$ENV_NAME # the Helm release name for the environment
export APIGEE_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 $APIGEE_NAMESPACE \
  $(kubectl get apigeeenvironments -n $APIGEE_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 $APIGEE_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: ENV_NAME>
    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
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.
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.

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:

runtime:
  # the following parameters configure metrics-based scaling
  hpaMetrics:
    serverMainTaskWaitTime: 400M # (range: 300M to 450M)
    serverNioTaskWaitTime: 400M # (range: 300M to 450M)
    targetCPUUtilizationPercentage: 75
  hpaBehavior:
    scaleDown:
      percent:
        periodSeconds: 60 # (range: 30 - 180)
        value: 20 # (range: 5 - 50)
      pods:
        periodSeconds: 60 # (range: 30 - 180)
        value: 2 # (range: 1 - 15)
      selectPolicy: Min
      stabilizationWindowSeconds: 120 # (range: 60 - 300)
    scaleUp:
      percent:
        periodSeconds: 60 # (range: 30 - 120)
        value: 20 # (range: 5 - 100)
      pods:
        periodSeconds: 60 # (range: 30 - 120)
        value: 4 # (range: 2 - 15)
      selectPolicy: Max
      stabilizationWindowSeconds: 30 # (range:  30 - 120)

Aplique estas definições atualizando o gráfico apigee-runtime para cada ambiente. Por exemplo:

helm upgrade $ENV_RELEASE_NAME apigee-runtime/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set env=$ENV_NAME \
  -f overrides.yaml

Ative ou desative o ajuste de escala com base em métricas

O ajuste de escala com base em métricas está ativado por predefinição. Pode ativar ou desativar o dimensionamento baseado em métricas definindo a propriedade customAutoscaling.enabled como true ou false. Aplique alterações à propriedade customAutoscaling.enabled atualizando o gráfico apigee-telemetry. Por exemplo:

helm upgrade telemetry apigee-telemetry/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides.yaml

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:

runtime:
  # ...
  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 diminuídos para implementar políticas de aumento e diminuição menos agressivas. Por exemplo:

runtime:
  # ...
  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.

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.