Servicios del entorno de ejecución de escalamiento y ajuste de escala automático

Puedes escalar la mayoría de los servicios que se ejecutan en Kubernetes desde la línea de comandos o en una anulación de configuración. Puedes configurar los parámetros de escalamiento para los servicios del entorno de ejecución de Apigee Hybrid en el archivo overrides.yaml.

Servicio	Implementado como	Escalamiento
Cassandra	ApigeeDatastore (CRD)	Consulta Escalamiento de Cassandra.
Ingress/LoadBalancer	Deployment	Anthos Service Mesh usa el ajuste de escala automático horizontal de pods (HPA).
Logger	DaemonSet	Los DaemonSet administran réplicas de un pod en todos los nodos, por lo que escalan cuando escalas los pods.
MART Apigee Connect Watcher	ApigeeOrganization (CRD)	Para escalar a través de la configuración, aumenta el valor de la propiedad `replicaCountMin` de la implementación para las estrofas `mart`, `watcher` o `connectAgent`. Por ejemplo: mart: replicaCountMax: 2 replicaCountMin: 1 watcher: replicaCountMax: 2 replicaCountMin: 1 connectAgent: replicaCountMax: 2 replicaCountMin: 1 Estas implementaciones usan un ajuste de escala automático de pod horizontal para el ajuste de escala automático. Configura la propiedad `targetCPUUtilizationPercentage` del objeto Deployment en el límite de escalamiento vertical. Cuando este valor se supera, Kubernetes agrega pods hasta el valor de `replicaCountMax`. Para obtener más información sobre cómo configurar las propiedades de configuración, consulta Administra los componentes del plano de entorno de ejecución.
Entorno de ejecución Synchronizer UDCA	ApigeeEnvironment (CRD)	Para escalar a través de la configuración, aumenta el valor de la propiedad `replicaCountMin` para las estrofas `udca`, `synchronizer` o `runtime` del archivo de anulación. Por ejemplo: synchronizer: replicaCountMax: 10 replicaCountMin: 1 runtime: replicaCountMax: 10 replicaCountMin: 1 udca: replicaCountMax: 10 replicaCountMin: 1 Nota: Estos cambios se aplican a TODOS los entornos del archivo de anulación. Si deseas personalizar el escalamiento para cada entorno, consulta la sección Configuración avanzada a continuación. Estas implementaciones usan un ajuste de escala automático de pod horizontal para el ajuste de escala automático. Configura la propiedad `targetCPUUtilizationPercentage` del objeto Deployment en el límite de escalamiento vertical. Cuando este valor se supera, Kubernetes agrega pods hasta el valor de `replicaCountMax`. Para obtener más información sobre cómo configurar las propiedades de configuración, consulta Administra los componentes del plano de entorno de ejecución.

Configuración avanzada

En algunos casos, es posible que debas usar opciones de escalamiento avanzadas. Algunos ejemplos de situaciones son los siguientes:

Configura diferentes opciones de escalamiento para cada entorno Por ejemplo, donde env1 tiene un minReplica de 5 y env2 tiene un minReplica de 2.
Configura diferentes opciones de escalamiento para cada componente dentro de un entorno Por ejemplo, cuando el componente udca tiene una maxReplica de 5 y el componente synchronizer tiene una maxReplica de 2.

En el siguiente ejemplo, se muestra cómo usar el comando kubernetes patch para cambiar la propiedad maxReplicas del componente runtime:

Crea las variables de entorno para usarlas con el 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

Aplica el parche. Ten en cuenta que en este ejemplo se da por sentado que kubectl está en la 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

Verifique el cambio:
```
kubectl get hpa -n $NAMESPACE
```

Escalamiento basado en métricas

Con el escalamiento basado en métricas, el entorno de ejecución puede usar CPU y métricas de aplicación para escalar los Pods apigee-runtime. La API de Horizontal Pod Autoscaler (HPA) de Kubernetes usa el campo hpaBehavior para configurar los comportamientos de escalamiento vertical y horizontal del servicio de destino. El escalamiento basado en métricas no está disponible para ningún otro componente en una implementación híbrida.

El escalamiento se puede ajustar en función de las siguientes métricas:

Métrica	Medición	Consideraciones
serverNioTaskWaitTime	Tiempo de espera promedio (en ms) de la cola de procesamiento en las instancias del entorno de ejecución para las solicitudes de proxy en la capa HTTP.	Esta métrica mide el impacto de la cantidad y el tamaño de la carga útil de las solicitudes y respuestas del proxy.
serverMainTaskWaitTime	Tiempo de espera promedio (en ms) de la cola de procesamiento en las instancias del entorno de ejecución para que las solicitudes de proxy procesen políticas.	Esta métrica mide el impacto de la complejidad en las políticas adjuntas al flujo de solicitudes de proxy.

En el siguiente ejemplo de la estrofa runtime en overrides.yaml, se ilustran los parámetros estándar (y los rangos permitidos) para el escalamiento de Pods de apigee-runtime en una implementación 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)

Configura un escalamiento más agresivo

Si se aumentan los valores percent y pods de la política de escalamiento vertical, se obtendrá una política de escalamiento vertical más agresiva. Del mismo modo, aumentar los valores percent y pods en scaleDown dará como resultado una política agresiva de reducción de escala verticalmente. Por ejemplo:

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

En el ejemplo anterior, el scaleDown.pods.value se aumenta a 5, el scaleUp.percent.value se aumenta a 30 y el scaleUp.pods.value se aumenta a 5.

Nota: El valor de periodSeconds no debe ser inferior a 30.

Configura un escalamiento menos agresivo

Los valores de configuración hpaBehavior también se pueden disminuir para implementar políticas de escalamiento vertical y reducción de escala menos agresivas. Por ejemplo:

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

En el ejemplo anterior, scaleDown.percent.value disminuye a 10, scaleDown.pods.value disminuye a 1 y scaleUp.stablizationWindowSeconds aumenta a 180.

Para obtener más información sobre el escalamiento basado en métricas mediante el campo hpaBehavior, consulta Políticas de escalamiento.

Inhabilita el escalamiento basado en métricas

Si bien el escalamiento basado en métricas está habilitado de forma predeterminada y no se puede inhabilitar por completo, puedes configurar los límites de las métricas a un nivel en el que no se activará el escalamiento basado en métricas. El comportamiento resultante del escalamiento será el mismo que el escalamiento basado en la CPU. Por ejemplo, puedes usar la configuración siguiente para evitar activar el escalamiento basado en 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

Soluciona problemas

En esta sección, se describen métodos de solución de problemas para errores comunes que puedes encontrar cuando configuras el escalamiento y el ajuste de escala automático.

HPA muestra `unknown` para los valores de métricas

Si el escalamiento basado en métricas no funciona y HPA muestra unknown para los valores de métricas, usa el siguiente comando a fin de verificar el resultado de HPA:

kubectl describe hpa HPA_NAME

Cuando ejecutes el comando, reemplaza HPA_NAME por el nombre de HPA que deseas ver.

El resultado mostrará el objetivo de CPU y el uso del servicio, lo que indica que el escalamiento de la CPU funcionará en ausencia del escalamiento basado en métricas. Para el comportamiento del HPA con varios parámetros, consulta Escala en varias métricas.