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
|
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 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 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 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 temminReplica
de 2. - Como definir diferentes opções de escalonamento para cada componente dentro de um ambiente Por exemplo,
onde o componente
udca
tem ummaxReplica
de 5 e o componentesynchronizer
tem ummaxReplica
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 seuPATH
: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 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. 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. 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.