Esta página se ha traducido con Cloud Translation API.

Escalar y autoescalar servicios de tiempo de ejecución

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 definir parámetros de escalado para los servicios de tiempo de ejecución de Apigee hybrid en el archivo overrides.yaml.

Servicio	Implementado como	Escalado
Cassandra	ApigeeDatastore (CRD)	Consulta Escalar Cassandra.
Ingress/LoadBalancer	Implementación	Cloud Service Mesh usa autoescalado horizontal de pods (HPAs).
Logger	DaemonSet	Los DaemonSets gestionan las réplicas de un pod en todos los nodos, por lo que se escalan cuando se escalan los propios pods.
MART Apigee Connect Watcher	ApigeeOrganization (CRD)	Para escalar mediante la configuración, aumenta el valor de la propiedad de configuración `replicaCountMin` de Deployment en las estrofas `mart`, `watcher` o `connectAgent`. Por ejemplo: mart: replicaCountMax: 2 replicaCountMin: 1 watcher: replicaCountMax: 2 replicaCountMin: 1 connectAgent: replicaCountMax: 2 replicaCountMin: 1 Estos despliegues usan un autoescalador horizontal de pods para el autoescalado. Asigna a la propiedad `targetCPUUtilizationPercentage` del objeto Deployment el umbral de escalado vertical. Cuando se supera este valor, Kubernetes añade pods hasta alcanzar el valor de `replicaCountMax`. Para obtener más información sobre cómo definir las propiedades de configuración, consulta Gestionar componentes del plano de tiempo de ejecución.
Tiempo de ejecución Sincronizador UDCA	ApigeeEnvironment (CRD)	Para escalar mediante la configuración, aumenta el valor de la propiedad `replicaCountMin` de las estrofas `udca`, `synchronizer` o `runtime` en el archivo de anulaciones. 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 anulaciones. Si quieres personalizar el escalado de cada entorno, consulta las configuraciones avanzadas que se indican más abajo. Estos despliegues usan un autoescalador horizontal de pods para el autoescalado. Asigna a la propiedad `targetCPUUtilizationPercentage` del objeto Deployment el umbral de escalado vertical. Cuando se supera este valor, Kubernetes añade pods hasta alcanzar el valor de `replicaCountMax`. Para obtener más información sobre cómo definir las propiedades de configuración, consulta Gestionar componentes del plano de tiempo de ejecución.

Configuración avanzada

En algunos casos, es posible que tengas que usar opciones de escalado avanzadas. Estos son algunos ejemplos:

Definir diferentes opciones de escalado para cada entorno. Por ejemplo, si env1 tiene un minReplica de 5 y env2 tiene un minReplica de 2.
Definir diferentes opciones de escalado para cada componente de un entorno. Por ejemplo, donde el componente udca tiene un maxReplica de 5 y el componente synchronizer tiene un 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 variables de entorno para usarlas con el 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

Aplica el parche. Ten en cuenta que en este ejemplo se presupone que kubectl está en tu 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

Verifica el cambio:
```
kubectl get hpa -n $APIGEE_NAMESPACE
```

Escalado basado en el entorno

De forma predeterminada, el escalado se describe a nivel de organización. Puedes anular los ajustes predeterminados especificando un escalado específico del entorno en el archivo overrides.yaml, como se muestra en el siguiente ejemplo:

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

Escalado basado en métricas

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

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

Métrica	Medir	Cuestiones importantes
serverMainTaskWaitTime	Tiempo de espera medio (en ms) de la cola de procesamiento en instancias del tiempo de ejecución para que las solicitudes de proxy procesen las políticas.	Esta métrica mide el impacto de la complejidad en las políticas asociadas al flujo de solicitudes de proxy.
serverNioTaskWaitTime	Tiempo de espera medio (en ms) de la cola de procesamiento en instancias de tiempo de ejecución para solicitudes de proxy en la capa HTTP.	Esta métrica mide el impacto del número y el tamaño de la carga útil de las solicitudes y respuestas de proxy.

En el siguiente ejemplo de la estrofa runtime del overrides.yaml se muestran los parámetros estándar (y los intervalos permitidos) para escalar pods de apigee-runtime en una implementación 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)

Para aplicar estos ajustes, actualiza el gráfico apigee-runtime de cada entorno. Por ejemplo:

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

Habilitar o inhabilitar el escalado basado en métricas

El escalado basado en métricas está habilitado de forma predeterminada. Para habilitar o inhabilitar el escalado basado en métricas, asigna el valor true o false a la propiedad customAutoscaling.enabled. Aplica los cambios a la propiedad customAutoscaling.enabled actualizando el gráfico apigee-telemetry. Por ejemplo:

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

Configurar un escalado más agresivo

Si aumentas los valores de percent y pods de la política de escalado vertical, esta será más agresiva. Del mismo modo, si aumentas los valores de percent y pods en scaleDown , se aplicará una política de reducción agresiva. Por ejemplo:

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

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

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

Configurar un escalado menos agresivo

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

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

En el ejemplo anterior, el scaleDown.percent.value se ha reducido a 10, el scaleDown.pods.value se ha reducido a 1 y el scaleUp.stablizationWindowSeconds se ha aumentado a 180.

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

Solución de problemas

En esta sección se describen métodos para solucionar problemas habituales que pueden surgir al configurar el escalado y el escalado automático.

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

Si el escalado basado en métricas no funciona y el HPA muestra unknown en los valores de las métricas, usa el siguiente comando para comprobar la salida del HPA:

kubectl describe hpa HPA_NAME

Cuando ejecutes el comando, sustituye HPA_NAME por el nombre del HPA que quieras ver.

El resultado mostrará el objetivo de CPU y el uso del servicio, lo que indica que el escalado de CPU funcionará en ausencia de escalado basado en métricas. Para obtener información sobre el comportamiento de HPA con varios parámetros, consulte Escalar en función de varias métricas.