Scaling et autoscaling des services d'exécution

Vous consultez actuellement la version 1.7 de la documentation d'Apigee hybrid. This version is end of life. You should upgrade to a newer version. Pour en savoir plus, consultez la section Versions compatibles.

Version 1.7 (unsupported)

   Versions compatibles :

• v1.13 (la plus récente)
• v1.12
• v1.11                         
• Liste des versions compatibles

   Versions non compatibles :

• v1.10
• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

Vous pouvez effectuer le scaling de la plupart des services exécutés dans Kubernetes à partir de la ligne de commande ou dans un remplacement de configuration. Vous pouvez définir des paramètres de scaling pour les services d'exécution Apigee hybride dans le fichier overrides.yaml.

Service	Mis en œuvre en tant que	Scaling
Cassandra	ApigeeDatastore (CRD)	Consultez la page Scaling de Cassandra.
Ingress/LoadBalancer	Déploiement	Anthos Service Mesh utilise l'autoscaling horizontal des pods (HPA).
Logger	DaemonSet	Les DaemonSets gèrent les instances dupliquées d'un pod sur tous les nœuds. Ils évoluent donc lorsque vous effectuez le scaling des pods eux-mêmes.
MART Apigee Connect Watcher	ApigeeOrganization (CRD)	Pour effectuer un scaling via la configuration, augmentez la valeur de la propriété de configuration replicaCountMin du déploiement pour les stanzas mart, watcher et/ou connectAgent. Exemple : mart: replicaCountMax: 2 replicaCountMin: 1 watcher: replicaCountMax: 2 replicaCountMin: 1 connectAgent: replicaCountMax: 2 replicaCountMin: 1 Ces déploiements utilisent un autoscaler horizontal de pods pour l'autoscaling. Définissez la propriété targetCPUUtilizationPercentage de l'objet Déploiement sur le seuil d'évolutivité. Lorsque cette valeur est dépassée, Kubernetes ajoute des pods jusqu'à la valeur de replicaCountMax. Pour en savoir plus sur la définition des propriétés de configuration, consultez la page Gérer les composants du plan d'exécution.
Environnement d'exécution Synchronisateur UDCA	ApigeeEnvironment (CRD)	Pour effectuer un scaling via la configuration, augmentez la valeur de la propriété replicaCountMin pour les stanzas udca, synchronizer et/ou runtime dans le fichier de remplacement. Exemple : synchronizer: replicaCountMax: 10 replicaCountMin: 1 runtime: replicaCountMax: 10 replicaCountMin: 1 udca: replicaCountMax: 10 replicaCountMin: 1 Remarque  : Ces modifications s'appliquent à TOUS les environnements du fichier de remplacement. Si vous souhaitez personnaliser le scaling pour chaque environnement, consultez la section Configurations avancées ci-dessous. Les déploiements utilisent un autoscaler horizontal de pods pour l'autoscaling. Définissez la propriété targetCPUUtilizationPercentage de l'objet Déploiement sur le seuil d'évolutivité. Lorsque cette valeur est dépassée, Kubernetes ajoute des pods jusqu'à la valeur de replicaCountMax. Pour en savoir plus sur la définition des propriétés de configuration, consultez la page Gérer les composants du plan d'exécution.

Configurations avancées

Dans certains cas, vous devrez peut-être utiliser des options de scaling avancées. Exemples de scénarios :

• Définir différentes options de scaling pour chaque environnement. Par exemple, où "env1" a une valeur minReplica de 5 et "env2" a une valeur minReplica de 2.
• Définir différentes options de scaling pour chaque composant d'un environnement. Par exemple, où le composant udca a une valeur maxReplica de 5 et le composant synchronizer une valeur maxReplica de 2.

L'exemple suivant montre comment utiliser la commande kubernetes patch pour modifier la propriété maxReplicas du composant runtime :

1. Créez des variables d'environnement à utiliser avec la commande :

   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

2. Appliquez le correctif. Notez que cet exemple suppose que kubectl se trouve dans votre fichier 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

3. Vérifiez que la modification a bien eu lieu en exécutant la commande suivante :

   kubectl get hpa -n $NAMESPACE

Scaling basé sur les métriques

Avec le scaling basé sur les métriques, l'environnement d'exécution peut utiliser les métriques du processeur et des applications pour procéder au scaling des pods apigee-runtime. L'API Horizontal Pod Autoscaler (HPA) de Kubernetes utilise le champ hpaBehavior pour configurer les comportements de scaling à la hausse et à la baisse du service cible. Le scaling basé sur les métriques n'est pas disponible pour les autres composants d'un déploiement hybride.

Remarque: Une connexion interne entre Prometheus et l'adaptateur Prometheus sur le port 6443 doit être ouverte pour recevoir des données de métriques et activer le scaling. Pour en savoir plus sur les ports requis, consultez la section Connexions internes.

Le scaling peut être ajusté en fonction des métriques suivantes:

Métrique	Mesure	Remarques
serverNioTaskWaitTime	Temps d'attente moyen (en ms) de la file d'attente de traitement dans les instances d'exécution pour les requêtes de proxy au niveau de la couche HTTP.	Cette métrique mesure l'impact du nombre et de la taille de la charge utile sur les requêtes et les réponses du proxy.
serverMainTaskWaitTime	Temps d'attente moyen (en ms) de la file d'attente de traitement dans les instances d'exécution pour les requêtes de proxy afin de traiter les stratégies.	Cette métrique mesure l'impact de la complexité des règles associées au flux de requêtes proxy.

L'exemple suivant du stanza runtime dans overrides.yaml illustre les paramètres standards (et les plages autorisées) pour le scaling de pods apigee-runtime dans une mise en œuvre hybride:

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)
  

Configurer un scaling plus agressif

L'augmentation des valeurs percent et pods de la règle de scaling à la hausse entraîne une règle de scaling à la hausse plus agressive. De même, l'augmentation des valeurs percent et pods dans scaleDown entraînera une règle de scaling à la baisse agressive. Exemple :

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

Dans l'exemple ci-dessus, la valeur scaleDown.pods.value est augmentée à 5, la valeur scaleUp.percent.value est augmentée à 30 et la valeur scaleUp.pods.value est augmentée. à 5.

Remarque: La valeur de periodSeconds ne doit pas être inférieure à 30.

Configurer un scaling moins agressif

Les valeurs de configuration hpaBehavior peuvent également être réduites pour mettre en œuvre des règles de scaling à la hausse et à la baisse moins agressives. Exemple :

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

Dans l'exemple ci-dessus, scaleDown.percent.value est réduit à 10, scaleDown.pods.value est réduit à 1 et scaleUp.stablizationWindowSeconds est augmenté. à 180.

Pour plus d'informations sur le scaling basé sur les métriques à l'aide du champ hpaBehavior, consultez la section Règles de scaling.

Désactiver le scaling basé sur les métriques

Bien que le scaling basé sur les métriques soit activé par défaut et ne peut pas être complètement désactivé, vous pouvez configurer les seuils de métriques à un niveau où le scaling basé sur les métriques ne sera pas déclenché. Le comportement de scaling obtenu est identique à celui basé sur le processeur. Par exemple, vous pouvez utiliser la configuration suivante pour empêcher le déclenchement du scaling basé sur des métriques:

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

Dépannage

Cette section décrit les méthodes de dépannage pour les erreurs courantes que vous pouvez rencontrer lors de la configuration du scaling et de l'autoscaling.

HPA indique unknown pour les valeurs de métriques

Si le scaling basé sur les métriques ne fonctionne pas et que l'HPA indique unknown pour les valeurs de métriques, utilisez la commande suivante pour vérifier la sortie du HPA:

kubectl describe hpa HPA_NAME

Lors de l'exécution de la commande, remplacez HPA_NAME par le nom du HPA que vous souhaitez afficher.

Le résultat affiche la cible du processeur et l'utilisation du service, indiquant que le scaling du processeur fonctionnera en l'absence de scaling basé sur les métriques. Pour connaître le comportement de l'autoscaler horizontal de pods avec plusieurs paramètres, consultez la section Scaling sur plusieurs métriques.