Configurer l'autoscaling horizontal des pods


Cette page explique comment utiliser l'autoscaling horizontal des pods pour effectuer l'autoscaling d'un déploiement à l'aide de différents types de métriques. Vous pouvez appliquer les mêmes consignes pour configurer un objet HorizontalPodAutoscaler dans n'importe quel objet Deployment évolutif.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
  • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.

Versions de l'API pour les objets HorizontalPodAutoscaler

Lorsque vous utilisez Google Cloud Console, les objets HorizontalPodAutoscaler sont créés à l'aide de l'API autoscaling/v2.

Lorsque vous utilisez kubectl pour créer ou afficher des informations sur un autoscaler horizontal de pods, vous pouvez spécifier l'API autoscaling/v1 ou l'API autoscaling/v2.

  • apiVersion: autoscaling/v1 est la version par défaut et ne vous permet d'effectuer un autoscaling qu'en fonction de l'utilisation du processeur. Pour effectuer un autoscaling à partir d'autres métriques, il est recommandé d'utiliser la version apiVersion: autoscaling/v2. L'exemple présenté dans la section Créer l'exemple de déploiement utilise apiVersion: autoscaling/v1.

  • La version apiVersion: autoscaling/v2 est recommandée pour la création d'objets HorizontalPodAutoscaler. Cette version permet d'effectuer un autoscaling en fonction de plusieurs métriques, y compris des métriques personnalisées ou externes. Tous les autres exemples de cette rubrique utilisent la version apiVersion: autoscaling/v2.

Pour vérifier quelles versions d'API sont compatibles, utilisez la commande kubectl api-versions.

Vous pouvez spécifier l'API à utiliser lors de l'affichage des détails d'un autoscaler horizontal de pods utilisant apiVersion: autoscaling/v2.

Créer l'exemple de déploiement

Avant de pouvoir créer un autoscaler horizontal de pods, vous devez créer la charge de travail qu'il devra surveiller. Les exemples de cette section appliquent différentes configurations d'autoscaler horizontal de pods au déploiement nginx suivant. Des exemples distincts illustrent l'utilisation d'un autoscaler horizontal de pods basé sur l'utilisation des ressources, sur une métrique personnalisée ou externe et sur plusieurs métriques.

Enregistrez le fichier suivant dans un fichier nommé nginx.yaml :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
        resources:
          # You must specify requests for CPU to autoscale
          # based on CPU utilization
          requests:
            cpu: "250m"

Ce manifeste spécifie une valeur pour les requêtes de processeur. Si vous souhaitez effectuer un scaling automatique en fonction de l'utilisation d'une ressource exprimée en pourcentage, vous devez spécifier les requêtes pour cette ressource. Si vous ne spécifiez pas de requêtes, vous ne pouvez effectuer un scaling automatique qu'en fonction de la valeur absolue de l'utilisation de la ressource, par exemple, pour l'utilisation de processeur, exprimée en milliprocesseurs.

Pour créer le déploiement, appliquez le manifeste nginx.yaml :

kubectl apply -f nginx.yaml

Le déploiement comporte la valeur spec.replicas définie sur 3, donc trois pods sont déployés. Vous pouvez le vérifier à l'aide de la commande kubectl get deployment nginx.

Chacun des exemples de cette section applique un autoscaler horizontal de pods différent à un exemple de déploiement nginx.

Effectuer un autoscaling basé sur l'utilisation des ressources

Cet exemple crée un objet HorizontalPodAutoscaler afin d'effectuer un autoscaling du déploiement nginx lorsque l'utilisation du processeur dépasse 50 %, et garantit l'existence d'au moins 1 instance dupliquée et d'au plus 10 instances dupliquées.

Vous pouvez créer un autoscaler horizontal de pods qui cible l'utilisation du processeur à l'aide de la console Google Cloud, de la commande kubectl apply ou, pour l'utilisation moyenne du processeur, de la commande kubectl autoscale.

Console

  1. Accédez à la page Charges de travail dans la console Google Cloud.

    Accéder à la page Charges de travail

  2. Cliquez sur le nom du déploiement nginx.

  3. Cliquez sur Actions > Évoluer automatiquement.

  4. Spécifiez les valeurs suivantes :

    • Nombre minimal d'instances dupliquées : 1
    • Nombre maximal d'instances dupliquées : 10
    • Métrique d'autoscaling : processeur
    • Cible : 50
    • Unité : %
  5. Cliquez sur OK.

  6. Cliquez sur Évoluer automatiquement.

kubectl apply

Enregistrez le fichier manifeste YAML suivant dans un fichier nommé nginx-hpa.yaml :

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: nginx
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50

Pour créer le HPA, appliquez le fichier manifeste à l'aide de la commande suivante :

kubectl apply -f nginx-hpa.yaml

kubectl autoscale

Pour créer un objet HorizontalPodAutoscaler qui ne cible que l'utilisation moyenne du processeur, vous pouvez utiliser la commande kubectl autoscale :

kubectl autoscale deployment nginx --cpu-percent=50 --min=1 --max=10

Pour obtenir la liste des autoscalers horizontaux de pods dans le cluster, exécutez la commande suivante :

kubectl get hpa

Le résultat ressemble à ce qui suit :

NAME    REFERENCE          TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
nginx   Deployment/nginx   0%/50%    1         10        3          61s

Pour obtenir des détails sur l'autoscaler horizontal de pods, vous pouvez utiliser la console Google Cloud ou la commande kubectl.

Console

  1. Accédez à la page Charges de travail dans la console Google Cloud.

    Accéder à la page Charges de travail

  2. Cliquez sur le nom du déploiement nginx.

  3. Affichez la configuration de l'autoscaler horizontal de pods dans la section Autoscaler.

  4. D'autres informations sur les événements d'autoscaling sont disponibles dans l'onglet Événements.

kubectl get

Pour obtenir des détails sur l'autoscaler horizontal de pods, vous pouvez utiliser kubectl get hpa avec l'option -o yaml. Le champ status contient des informations sur le nombre actuel d'instances dupliquées et les événements d'autoscaling récents.

kubectl get hpa nginx -o yaml

Le résultat ressemble à ce qui suit :

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  annotations:
    autoscaling.alpha.kubernetes.io/conditions: '[{"type":"AbleToScale","status":"True","lastTransitionTime":"2019-10-30T19:42:59Z","reason":"ScaleDownStabilized","message":"recent
      recommendations were higher than current one, applying the highest recent recommendation"},{"type":"ScalingActive","status":"True","lastTransitionTime":"2019-10-30T19:42:59Z","reason":"ValidMetricFound","message":"the
      HPA was able to successfully calculate a replica count from cpu resource utilization
      (percentage of request)"},{"type":"ScalingLimited","status":"False","lastTransitionTime":"2019-10-30T19:42:59Z","reason":"DesiredWithinRange","message":"the
      desired count is within the acceptable range"}]'
    autoscaling.alpha.kubernetes.io/current-metrics: '[{"type":"Resource","resource":{"name":"cpu","currentAverageUtilization":0,"currentAverageValue":"0"}}]'
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"autoscaling/v1","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"maxReplicas":10,"minReplicas":1,"scaleTargetRef":{"apiVersion":"apps/v1","kind":"Deployment","name":"nginx"},"targetCPUUtilizationPercentage":50}}
  creationTimestamp: "2019-10-30T19:42:43Z"
  name: nginx
  namespace: default
  resourceVersion: "220050"
  selfLink: /apis/autoscaling/v1/namespaces/default/horizontalpodautoscalers/nginx
  uid: 70d1067d-fb4d-11e9-8b2a-42010a8e013f
spec:
  maxReplicas: 10
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  targetCPUUtilizationPercentage: 50
status:
  currentCPUUtilizationPercentage: 0
  currentReplicas: 3
  desiredReplicas: 3

Avant de suivre les autres exemples présentés dans cette section, supprimez le HPA :

kubectl delete hpa nginx

Lorsque vous supprimez un autoscaler horizontal de pods, le nombre d'instances dupliquées du déploiement reste le même. Le déploiement ne rétablit pas automatiquement l'état qui précède l'application de l'autoscaler de pods horizontaux.

Apprenez-en plus sur la suppression d'un autoscaler horizontal de pods.

Autoscaling basé sur le trafic de l'équilibreur de charge

L'autoscaling basé sur le trafic est une fonctionnalité de GKE qui intègre des signaux d'utilisation du trafic provenant d'équilibreurs de charge à des pods d'autoscaling.

L'utilisation du trafic comme signal d'autoscaling peut être utile, car le trafic est un indicateur principal de la charge, complémentaire aux processeurs et à la mémoire. L'intégration avec GKE garantit que la configuration est facile et que l'autoscaling réagit rapidement aux pics de trafic pour répondre à la demande.

L'autoscaling basé sur le trafic est activé par le contrôleur Gateway et ses fonctionnalités de gestion du trafic globale. Pour en savoir plus, consultez la page Autoscaling basé sur le trafic.

L'autoscaling basé sur le trafic de l'équilibreur de charge n'est disponible que pour les charges de travail passerelle.

Exigences

L'autoscaling basé sur le trafic présente les exigences suivantes:

  • Compatible avec GKE 1.24 et versions ultérieures.
  • API Gateway activée dans votre cluster GKE.
  • Compatible avec le trafic qui transite par des équilibreurs de charge déployés à l'aide de l'API Gateway et de la ressource GatewayClass gke-l7-global-external-managed, gke-l7-regional-external-managed, gke-l7-rilb ou gke-l7-gxlb.

Limites

L'autoscaling basé sur le trafic présente les limites suivantes :

  • Non compatible avec les ressources GatewayClass multicluster (gke-l7-global-external-managed-mc, gke-l7-regional-external-managed-mc, gke-l7-rilb-mc et gke-l7-gxlb-mc).
  • Non compatible avec le trafic utilisant des services de type ClusterIP ou LoadBalancer.

Déployer l'autoscaling basé sur le trafic

L'exercice suivant utilise HorizontalPodAutoscaler pour procéder à l'autoscaling du déploiement store-autoscale en fonction du trafic qu'il reçoit. Une passerelle accepte le trafic entrant provenant d'Internet pour les pods. L'autoscaler compare les signaux de trafic de la passerelle à la capacité de trafic par pod configurée sur la ressource de service store-autoscale. En générant du trafic vers la passerelle, vous influencez le nombre de pods déployés.

Le schéma suivant illustre le fonctionnement de l'autoscaling basé sur le trafic:

Autoscaling basé sur le trafic

Pour déployer l'autoscaling basé sur le trafic, procédez comme suit:

  1. Pour les clusters standards, vérifiez que les ressources GatewayClasses sont installées dans votre cluster. Pour les clusters Autopilot, les ressources GatewayClasses sont installés par défaut.

    kubectl get gatewayclass
    

    Le résultat confirme que les ressources GatewayClass de GKE sont prêtes à être utilisées dans votre cluster:

    NAME                               CONTROLLER                  ACCEPTED   AGE
    gke-l7-global-external-managed     networking.gke.io/gateway   True       16h
    gke-l7-regional-external-managed   networking.gke.io/gateway   True       16h
    gke-l7-gxlb                        networking.gke.io/gateway   True       16h
    gke-l7-rilb                        networking.gke.io/gateway   True       16h
    

    Si vous n'obtenez pas ce résultat, activez l'API Gateway dans votre cluster GKE.

  2. Déployez l'exemple d'application et l'équilibreur de charge de passerelle sur votre cluster:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/store-autoscale.yaml
    

    L'exemple d'application crée:

    • Un déploiement avec deux instances dupliquées.
    • Capacité de service avec max-rate-per-endpoint défini sur 10 Tant que cette fonctionnalité est disponible en version Bêta, utilisez une annotation dans le service. Lorsque cette fonctionnalité sera disponible pour tous les utilisateurs, la règle de service remplacera l'annotation. Pour en savoir plus sur les fonctionnalités de la ressource Gateway, consultez la page Fonctionnalités GatewayClass.
    • Une passerelle externe pour accéder à l'application sur Internet. Pour en savoir plus sur l'utilisation des équilibreurs de charge Gateway, consultez la page Déployer des passerelles.
    • Un objet HTTPRoute qui correspond à tout le trafic et l'envoie au service store-autoscale.

    La capacité du service est un élément essentiel de l'utilisation de l'autoscaling basé sur le trafic, car elle détermine la quantité de trafic par pod qui déclenche un événement d'autoscaling. Elle configure la capacité de service à l'aide de l'annotation de service networking.gke.io/max-rate-per-endpoint, qui définit le trafic maximal qu'un service doit recevoir en requêtes par seconde et par pod. La capacité de service est spécifique à l'application. Pour en savoir plus, consultez la section Déterminer la capacité de votre service.

  3. Enregistrez le manifeste suivant sous le nom hpa.yaml :

    apiVersion: autoscaling/v2
    kind: HorizontalPodAutoscaler
    metadata:
      name: store-autoscale
    spec:
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: store-autoscale
      minReplicas: 1
      maxReplicas: 10
      metrics:
      - type: Object
        object:
          describedObject:
            kind: Service
            name: store-autoscale
          metric:
            name: "autoscaling.googleapis.com|gclb-capacity-utilization"
          target:
            averageValue: 70
            type: AverageValue
    

    Ce fichier manifeste décrit un objet HorizontalPodAutoscaler avec les propriétés suivantes:

    • minReplicas et maxReplicas: définissent le nombre minimal et maximal d'instances dupliquées pour ce déploiement. Dans cette configuration, le nombre de pods peut faire évoluer de 1 à 10 instances dupliquées.
    • describedObject.name: store-autoscale: référence au service store-autoscale qui définit la capacité du trafic.
    • scaleTargetRef.name: store-autoscale: référence au déploiement store-autoscale qui définit la ressource mise à l'échelle par l'autoscaler horizontal de pods.
    • averageValue: 70: valeur moyenne cible de l'utilisation de la capacité. Cela donne à l'autoscaler horizontal des pods une marge de croissance qui permet aux pods en cours d'exécution de traiter le trafic excédentaire pendant la création des pods.

L'autoscaler horizontal des pods entraîne le comportement de trafic suivant:

  • Le nombre de pods est ajusté entre 1 et 10 instances dupliquées afin d'atteindre 70% du taux maximal par point de terminaison. Cela se traduit par 7 RPS par pod lorsque max-rate-per-endpoint=10.
  • À plus de 7 RPS par pod, les pods font l'objet d'un scaling à la hausse jusqu'à atteindre le nombre maximal de 10 instances dupliquées ou jusqu'à que le trafic moyen atteigne 7 RPS par pod.
  • Si le trafic est réduit, les pods évoluent vers le bas à un taux raisonnable à l'aide de l'algorithme horizontal de l'autoscaler de pods.

Vous pouvez également déployer un générateur de trafic pour valider le comportement de l'autoscaling basé sur le trafic.

À 30 RPS, le déploiement est réduit à cinq instances dupliquées de sorte que chaque instance dupliquée reçoive idéalement 6 RPS de trafic, ce qui correspond à 60% d'utilisation par pod. Ce seuil est inférieur à l'objectif de 70% de l'utilisation. Les pods sont donc adaptés de manière appropriée. En fonction des fluctuations du trafic, le nombre d'instances dupliquées avec autoscaling peut également varier. Pour obtenir une description plus détaillée du calcul du nombre d'instances dupliquées, consultez la page Comportement de l'autoscaling.

Effectuer un autoscaling basé sur une métrique personnalisée ou externe

Pour créer des autoscalers horizontaux de pods pour les métriques personnalisées et externes, consultez la section Optimiser l'autoscaling des pods en fonction des métriques.

Procéder à un autoscaling basé sur plusieurs métriques

Cet exemple crée un autoscaler de pods horizontaux qui réalise un autoscaling en fonction de l'utilisation du processeur et d'une métrique personnalisée nommée packets_per_second.

Si vous avez suivi l'exemple précédent et que vous disposez toujours d'un autoscaler horizontal de pods nommé nginx, supprimez-le avant de commencer cet exemple.

Vous aurez besoin de la version apiVersion: autoscaling/v2. Pour plus d'informations sur les API disponibles, consultez la page Versions d'API pour les objets HorizontalPodAutoscaler.

Enregistrez ce fichier manifeste YAML en tant que fichier nommé nginx-multiple.yaml :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  - type: Resource
    resource:
      name: memory
      target:
        type: AverageValue
        averageValue: 100Mi
  # Uncomment these lines if you create the custom packets_per_second metric and
  # configure your app to export the metric.
  # - type: Pods
  #   pods:
  #     metric:
  #       name: packets_per_second
  #     target:
  #       type: AverageValue
  #       averageValue: 100

Appliquez le manifeste YAML :

kubectl apply -f nginx-multiple.yaml

Une fois créé, l'autoscaler horizontal des pods surveille le déploiement nginx pour l'utilisation moyenne du processeur, l'utilisation moyenne de la mémoire et la métrique personnalisée packets_per_second si vous avez annulé la mise en commentaire. L'autoscaler horizontal des pods effectue un autoscaling du déploiement en fonction de la métrique dont la valeur crée l'événement d'autoscaling le plus important.

Afficher les détails d'un autoscaler horizontal de pods

Pour afficher la configuration et les statistiques d'un autoscaler horizontal de pods, exécutez la commande suivante :

kubectl describe hpa HPA_NAME

Remplacez HPA_NAME par le nom de votre objet HorizontalPodAutoscaler.

Si l'autoscaler horizontal de pods utilise apiVersion: autoscaling/v2 et qu'il est basé sur plusieurs métriques, la commande kubectl describe hpa n'affiche que la métrique d'utilisation du processeur. Pour afficher toutes les métriques, exécutez la commande suivante :

kubectl describe hpa.v2.autoscaling HPA_NAME

Remplacez HPA_NAME par le nom de votre objet HorizontalPodAutoscaler.

L'état actuel de chaque autoscaler horizontal de pods est indiqué dans le champ Conditions et les événements d'autoscaling sont répertoriés dans le champ Events.

Le résultat ressemble à ce qui suit :

Name:                                                  nginx
Namespace:                                             default
Labels:                                                <none>
Annotations:                                           kubectl.kubernetes.io/last-applied-configuration:
                                                         {"apiVersion":"autoscaling/v2","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"s...
CreationTimestamp:                                     Tue, 05 May 2020 20:07:11 +0000
Reference:                                             Deployment/nginx
Metrics:                                               ( current / target )
  resource memory on pods:                             2220032 / 100Mi
  resource cpu on pods  (as a percentage of request):  0% (0) / 50%
Min replicas:                                          1
Max replicas:                                          10
Deployment pods:                                       1 current / 1 desired
Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     True    ReadyForNewScale    recommended size matches current size
  ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
  ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
Events:                                                <none>

Supprimer un autoscaler horizontal de pods

Vous pouvez supprimer un autoscaler horizontal de pods à l'aide de la console Google Cloud ou de la commande kubectl delete.

Console

Pour supprimer l'autoscaler horizontal de pods nginx, procédez comme suit :

  1. Accédez à la page Charges de travail dans la console Google Cloud.

    Accéder à la page Charges de travail

  2. Cliquez sur le nom du déploiement nginx.

  3. Cliquez sur Actions > Évoluer automatiquement.

  4. Cliquez sur Supprimer.

kubectl delete

Pour supprimer l'autoscaler horizontal de pods nginx, utilisez la commande suivante :

kubectl delete hpa nginx

Lorsque vous supprimez un autoscaler horizontal de pods, le déploiement (ou un autre objet de déploiement) n'est pas mis à l'échelle et ne revient pas au nombre d'instances dupliquées du manifeste de déploiement d'origine. Pour rétablir manuellement le scaling du déploiement sur trois pods, vous pouvez utiliser la commande kubectl scale :

kubectl scale deployment nginx --replicas=3

Nettoyer

  1. Supprimez l'autoscaler horizontal de pods, si ce n'est pas déjà fait :

    kubectl delete hpa nginx
    
  2. Supprimez le déploiement nginx :

    kubectl delete deployment nginx
    
  3. Vous pouvez également supprimer le cluster.

Dépannage

Lorsque vous configurez un autoscaler horizontal de pods, des messages d'avertissement semblables aux suivants peuvent s'afficher :

unable to fetch pod metrics for pod

Il est normal que ce message s'affiche au démarrage du serveur de métriques. Toutefois, si vous continuez à voir des avertissements et que vous remarquez que les pods ne sont pas mis à l'échelle pour votre charge de travail, assurez-vous d'avoir spécifié des requêtes de ressources pour chaque conteneur de votre charge de travail. Pour utiliser des pourcentages cibles d'utilisation d'une ressource avec l'autoscaling de pods horizontaux, vous devez configurer les requêtes pour cette ressource pour chaque conteneur et dans chaque pod de la charge de travail. Sinon, l'autoscaler de pods horizontaux ne peut pas effectuer les calculs nécessaires et n'effectue aucune action en lien avec cette métrique.

Étape suivante