Kubernetes Horizontal Pod Autoscaler : architecture et exemples pratiques

Introduction

Le Horizontal Pod Autoscaler (HPA) de Kubernetes ajuste automatiquement le nombre de pods dans un déploiement, un contrôleur de réplication ou un statefulset en fonction de l'utilisation du CPU ou de métriques personnalisées. Pour les opérateurs et développeurs exécutant des charges de travail en production, comprendre l'architecture du HPA est essentiel pour garantir que les applications restent réactives sous charge tout en évitant des coûts d'infrastructure inutiles.

Cet article s'adresse aux développeurs, consultants DevOps et équipes techniques de startups qui doivent dépasser les concepts de base de l'autoscaling. Il explique les composants essentiels du HPA, leur interaction, et comment configurer, vérifier et dépanner l'autoscaling dans des clusters réels. À la fin, vous serez en mesure de configurer le HPA en toute sécurité, d'interpréter son comportement et de récupérer des erreurs de configuration courantes.

Nous insistons sur la sécurité opérationnelle : toujours observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés au lieu de secrets, vérifier les résultats et documenter les étapes de récupération.

Fonctionnement du Horizontal Pod Autoscaler

Le Horizontal Pod Autoscaler est implémenté comme une boucle de contrôle qui s'exécute périodiquement (par défaut toutes les 15 secondes) et interroge le serveur de métriques pour obtenir l'utilisation des ressources. Il calcule ensuite le nombre de réplicas souhaité en fonction du rapport entre la valeur actuelle de la métrique et la valeur cible, puis met à jour le nombre de réplicas de la charge de travail cible en conséquence.

L'algorithme de base détermine le nombre de réplicas souhaité à l'aide de la formule :

desiredReplicas = ceil( currentReplicas * ( currentMetricValue / desiredMetricValue ) )

Par exemple, si un déploiement a 2 réplicas, que l'utilisation actuelle du CPU est de 200m (0,2 cœur) et que l'utilisation cible est de 100m (0,1 cœur), le rapport est de 2,0, donc le nombre de réplicas souhaité devient 4. Le contrôleur HPA met alors le déploiement à l'échelle sur 4 pods.

Le HPA fonctionne avec plusieurs ressources Kubernetes :

• Metrics Server : la source par défaut pour les métriques CPU et mémoire. Il agrège les données d'utilisation des ressources des kubelets et les expose via l'API Metrics. Le HPA récupère périodiquement ces métriques.
• API de métriques personnalisées : pour la mise à l'échelle basée sur des métriques spécifiques à l'application (par exemple, requêtes par seconde, longueur de file d'attente), vous pouvez l'intégrer à des outils comme Prometheus Adapter ou Google Cloud Monitoring.
• API de métriques externes : permet la mise à l'échelle basée sur des métriques provenant de l'extérieur du cluster, telles que les métriques d'équilibreur de charge d'un fournisseur cloud.

Composants essentiels

1. Contrôleur HPA

Le contrôleur HPA fait partie du kube-controller-manager. Il surveille les ressources HorizontalPodAutoscaler et effectue les calculs de mise à l'échelle. Le contrôleur exécute une boucle de réconciliation qui :

1. Récupère la charge de travail cible (par exemple, un déploiement).
2. Obtient les métriques actuelles auprès du serveur de métriques ou de l'API de métriques personnalisées.
3. Calcule le nombre de réplicas souhaité.
4. Met à jour le champ spec.replicas de la charge de travail si le nombre souhaité diffère du nombre actuel, en respectant minReplicas et maxReplicas.

2. Metrics Server

Le Metrics Server est un agrégateur de données d'utilisation des ressources à l'échelle du cluster. Il n'est pas déployé par défaut dans la plupart des clusters. Vous pouvez l'installer avec :

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Vérifiez qu'il est en cours d'exécution :

kubectl get deployment metrics-server -n kube-system

Sortie attendue :

NAME             READY   UP-TO-DATE   AVAILABLE   AGE
metrics-server   1/1     1            1           5m

3. API de métriques

Le HPA interroge l'API Metrics, qui est servie par le metrics-server. Cette API fournit des métriques de ressources telles que le CPU et la mémoire. Pour les métriques personnalisées, vous devez déployer un adaptateur qui implémente l'API custom.metrics.k8s.io.

Inventaire des versions et de l'environnement

Avant de configurer le HPA, vous devez comprendre la version et les capacités de votre cluster, car le comportement du HPA a évolué au fil des versions de Kubernetes. Des fonctionnalités clés comme les fenêtres de stabilisation et les politiques de mise à l'échelle ne sont disponibles que dans les versions plus récentes.

Vérifiez votre version de Kubernetes :

kubectl version --short

Exemple de sortie :

Client Version: v1.24.3
Server Version: v1.24.3

Vérifiez la disponibilité de l'API HPA :

kubectl api-versions | grep autoscaling

La sortie attendue devrait inclure autoscaling/v2 (ou v2beta2 dans les versions plus anciennes) si vous souhaitez utiliser des fonctionnalités avancées :

autoscaling/v1
autoscaling/v2

Vérifiez si Metrics Server est installé :

kubectl get apiservice v1beta1.metrics.k8s.io

S'il est installé, la sortie indique Available: True :

NAME                     SERVICE                      AVAILABLE   AGE
v1beta1.metrics.k8s.io   kube-system/metrics-server   True        10m

S'il n'est pas disponible, installez-le avant de continuer.

Prérequis

• Un cluster Kubernetes en cours d'exécution (version 1.23+ recommandée pour l'API v2).
• Metrics Server installé et fonctionnel.
• kubectl configuré pour accéder au cluster.
• Un déploiement avec des demandes de ressources définies (par exemple, CPU et mémoire). Le HPA ne peut pas fonctionner sans demandes de ressources.

Exemple de manifeste de déploiement avec demandes de ressources :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: php-apache
spec:
  replicas: 1
  selector:
    matchLabels:
      run: php-apache
  template:
    metadata:
      labels:
        run: php-apache
    spec:
      containers:
      - name: php-apache
        image: registry.k8s.io/hpa-example
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: 500m
          requests:
            cpu: 200m

Appliquez-le et vérifiez :

kubectl apply -f deployment.yaml
kubectl get pods -l run=php-apache

Attendu : un pod en cours d'exécution.

Chemin de configuration sécurisé

Configurer le HPA en toute sécurité signifie commencer par une configuration minimale, valider son impact dans un environnement de test, puis l'appliquer progressivement à la production. Les étapes suivantes décrivent une approche sûre.

Étape 1 : Observer la base de référence actuelle

Avant d'activer l'autoscaling, établissez le comportement actuel de la charge de travail sous un trafic normal. Utilisez ces commandes :

kubectl get pods -o wide
kubectl top pods

La commande kubectl top affiche l'utilisation actuelle des ressources :

NAME                         CPU(cores)   MEMORY(bytes)
php-apache-<pod-id>          5m           10Mi

Enregistrez l'utilisation actuelle du CPU comme référence.

Étape 2 : Définir l'objet HPA

Créez un manifeste HPA en utilisant l'API autoscaling/v2 pour plus de contrôle. Exemple :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Cela définit le HPA pour maintenir une utilisation moyenne du CPU de 50 % sur tous les pods. minReplicas et maxReplicas bornent la mise à l'échelle.

Appliquez-le :

kubectl apply -f hpa.yaml

Étape 3 : Vérifier l'état du HPA

Vérifiez l'état du HPA et les événements :

kubectl get hpa
kubectl describe hpa php-apache

Exemple de sortie kubectl get hpa :

NAME         REFERENCE               TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache   0%/50%    1         10        1          1m

Ici, l'utilisation actuelle est de 0 % car aucun trafic n'atteint le pod, la cible est de 50 %.

Étape 4 : Générer une charge pour tester la mise à l'échelle

Pour tester l'autoscaling, vous devez générer une charge. Créez un pod générateur de charge temporaire :

kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

Gardez cette commande en cours d'exécution dans un terminal séparé et surveillez le HPA :

kubectl get hpa php-apache --watch

En une minute ou deux, vous devriez voir l'utilisation actuelle du CPU dépasser la cible et le nombre de réplicas augmenter.

Étape 5 : Valider le comportement de mise à l'échelle

Après l'arrêt de la charge, le HPA réduira l'échelle après la fenêtre de stabilisation par défaut (5 minutes pour la réduction). Vous pouvez observer les événements :

kubectl describe hpa php-apache

Recherchez des événements similaires à :

Events:
  Type    Reason             Age   From                       Message
  ----    ------             ----  ----                       -------
  Normal  SuccessfulRescale  5m    horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target

Considérations de configuration importantes

• Demandes de ressources : le HPA ne fonctionnera pas si la charge de travail cible n'a pas de demandes de ressources définies. Le pourcentage d'utilisation est calculé par rapport à la demande, pas à la limite.
• Métriques multiples : vous pouvez spécifier plusieurs métriques ; le HPA calcule les réplicas souhaités pour chaque métrique et prend le maximum.
• Fenêtres de stabilisation : le champ behavior de l'API v2 vous permet de contrôler la rapidité avec laquelle le HPA augmente ou diminue l'échelle. Par exemple, pour réduire les fluctuations, vous pouvez définir une fenêtre de stabilisation de réduction de 300 secondes.

Exemple de configuration de comportement :

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300
    policies:
    - type: Percent
      value: 100
      periodSeconds: 15
  scaleUp:
    stabilizationWindowSeconds: 0
    policies:
    - type: Percent
      value: 100
      periodSeconds: 15
    - type: Pods
      value: 4
      periodSeconds: 15
    selectPolicy: Max

Cela garantit que la réduction d'échelle ne se produit qu'après que les métriques sont restées sous le seuil pendant 5 minutes, et que l'augmentation d'échelle se produit immédiatement mais est limitée soit à 100 % des réplicas actuels, soit à 4 pods par 15 secondes, selon ce qui donne le plus de réplicas.

Vérification et diagnostics

La vérification va au-delà de la simple commande kubectl get hpa. Vous devez vous assurer que le HPA prend des décisions correctes basées sur des métriques précises.

Vérification de la disponibilité des métriques

Tout d'abord, confirmez que le serveur de métriques fournit des données :

kubectl get --raw "/apis/metrics.k8s.io/v1beta1/namespaces/default/pods" | jq

Si vous voyez des entrées avec des valeurs CPU et mémoire, les métriques circulent correctement.

Commandes de diagnostic courantes

1. Afficher les événements du HPA :

kubectl describe hpa <hpa-name>

Recherchez les avertissements ou erreurs. Les messages d'erreur courants incluent :

• unable to get metrics for resource cpu: no metrics returned from resource metrics API signifie que metrics-server n'est pas installé ou ne fonctionne pas.
• missing request for cpu indique que le déploiement n'a pas de demandes de ressources.
• failed to get cpu utilization: unable to get metrics for resource cpu: no metrics returned from resource metrics API est similaire au premier.

1. Vérifier l'utilisation des ressources des pods :

kubectl top pods

Si kubectl top renvoie une erreur, metrics-server est peut-être en panne.

1. Inspecter les journaux du serveur de métriques :

kubectl logs -n kube-system deployment/metrics-server

Recherchez les erreurs de connexion aux kubelets ou au serveur d'API.

1. Valider le calcul du HPA :

Vous pouvez calculer manuellement les réplicas souhaités à l'aide de la formule. Par exemple, si vous avez 2 réplicas, que le CPU actuel est de 300m et la cible de 200m (c'est-à-dire 100 % d'utilisation pour une demande de 200m), alors les réplicas souhaités = ceil(2 * (300/200)) = ceil(3) = 3.

Vérification des politiques de mise à l'échelle

Si vous avez défini un behavior, testez les événements de réduction et d'augmentation d'échelle :

kubectl get events --field-selector involvedObject.name=<hpa-name> --watch

Cela affiche les événements en temps réel lorsque le HPA met à l'échelle.

Modes de défaillance et récupération

Plusieurs modes de défaillance courants peuvent empêcher le HPA de fonctionner correctement. Nous couvrons ici les symptômes, causes et étapes de récupération.

1. Le HPA affiche Unknown pour les métriques

Symptôme : kubectl get hpa affiche <unknown> dans la colonne TARGETS.

Cause : le serveur de métriques n'est pas joignable ou ne renvoie pas de métriques.

Récupération :

• Vérifiez que metrics-server est en cours d'exécution :

kubectl get pods -n kube-system | grep metrics-server

• Vérifiez la disponibilité de l'API metrics :

kubectl get apiservice v1beta1.metrics.k8s.io

S'il n'est pas disponible, redéployez metrics-server.

2. Le HPA ne met pas à l'échelle malgré une charge élevée

Symptôme : utilisation CPU élevée mais nombre de réplicas inchangé.

Causes :

• Pas de demandes de ressources sur les pods cibles.
• La valeur maxReplicas du HPA est atteinte.
• Le HPA tente de mettre à l'échelle mais échoue en raison d'un quota de ressources ou d'une capacité de cluster insuffisante.
• La fenêtre de stabilisation empêche l'augmentation immédiate (moins courant).

Récupération :

• Vérifiez les événements du HPA pour les erreurs :

kubectl describe hpa <name>

• Assurez-vous que maxReplicas est suffisamment élevé.
• Vérifiez la capacité du cluster : kubectl get nodes et kubectl describe nodes pour voir si les ressources sont épuisées.
• Vérifiez les quotas de ressources :

kubectl get resourcequota -n <namespace>

Si le quota est dépassé, augmentez-le ou réduisez d'autres charges de travail.

3. Fluctuation ou oscillation du nombre de réplicas

Symptôme : le nombre de réplicas change fréquemment à la hausse et à la baisse.

Cause : seuils HPA trop serrés ou modèles de métriques erratiques.

Récupération :

• Ajustez l'utilisation cible pour éviter les conditions limites.
• Utilisez des fenêtres de stabilisation pour lisser la mise à l'échelle :

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300
  scaleUp:
    stabilizationWindowSeconds: 60

• Envisagez des métriques personnalisées qui reflètent mieux la charge réelle.

4. HPA supprimé accidentellement

Symptôme : l'autoscaling s'arrête.

Récupération :

• Recréez le HPA à partir de la sauvegarde du manifeste. Gardez toujours les manifestes HPA sous contrôle de version.

Liste de contrôle opérationnelle

Pour les opérations de jour 2, assurez-vous que cette liste de contrôle fasse partie de votre routine :

Hebdomadaire

• [ ] Examiner l'état du HPA :

kubectl get hpa --all-namespaces

Vérifiez que tous les HPA ont des métriques valides (pas unknown) et des nombres de réplicas dans les limites min/max.

• [ ] Vérifier les événements :

kubectl get events --all-namespaces --field-selector reason=FailedGetResourceMetric

Mensuel

• [ ] Valider la santé du serveur de métriques et le mettre à niveau si nécessaire.
• [ ] Examiner les politiques de mise à l'échelle et les ajuster en fonction des modèles de trafic.
• [ ] Tester la réduction d'échelle en réduisant la charge et en confirmant que les réplicas diminuent après la fenêtre de stabilisation.
• [ ] Mettre à jour les seuils cibles du HPA en fonction des évaluations de performance.

Trimestriel

• [ ] Effectuer des tests de charge pour vérifier que le HPA répond correctement sous des charges de pointe.
• [ ] Examiner la capacité du cluster et l'intégration de l'autoscaling des nœuds.
• [ ] Auditer les configurations HPA pour la sécurité et la conformité.

Responsabilité : Attribuez un propriétaire pour les opérations HPA. Par exemple, dans une startup, le responsable DevOps (par exemple, Priya Shah, responsable de l'ingénierie) devrait être responsable des vérifications hebdomadaires, et l'équipe plateforme devrait être propriétaire des examens mensuels. Le propriétaire revoit la liste de contrôle et met à jour l'attribution du propriétaire chaque trimestre.

Pièges courants et comment les éviter

1. Ne pas définir les demandes de ressources

Pourquoi cela arrive : les équipes oublient de spécifier resources.requests sur les conteneurs, pensant que les limites suffisent. Le HPA utilise les demandes pour les calculs d'utilisation.

Comment éviter : définissez toujours des demandes pour le CPU et la mémoire sur les charges de travail cibles. Automatisez la validation avec des politiques OPA/Kyverno.

Récupération : ajoutez des demandes à la spécification du déploiement et réappliquez. Le HPA commencera à fonctionner une fois les demandes présentes.

2. Utiliser le pourcentage d'utilisation CPU sans le comprendre

Pourquoi cela arrive : le pourcentage d'utilisation cible est relatif à la demande, pas à la limite. Par exemple, si la demande est de 500m et la cible de 50 %, le HPA vise 250m. Si la limite est de 1000m, le pod peut utiliser jusqu'à 1000m mais la moyenne entre les pods doit être de 250m. Une mauvaise compréhension conduit à une sous- ou sur-mise à l'échelle.

Comment éviter : définissez des cibles basées sur les principes SRE. Pour le CPU, visez 50 à 70 % de la demande pour maintenir une marge. Pour la mémoire, soyez prudent car la mémoire n'est pas compressible ; définissez une utilisation cible plus basse (par exemple, 70 à 80 %) pour éviter les tueries OOM.

3. Ignorer les métriques personnalisées lorsque le CPU n'est pas le goulot d'étranglement

Pourquoi cela arrive : de nombreuses applications sont limitées par les E/S ou ont une répartition de charge inégale, donc la mise à l'échelle basée sur le CPU peut être insuffisante.

Comment éviter : utilisez des métriques personnalisées (par exemple, requêtes par seconde, profondeur de file d'attente) via Prometheus Adapter ou d'autres outils. Concevez des métriques corrélées aux performances côté utilisateur.

Récupération : implémentez des métriques personnalisées et mettez à jour le HPA pour les utiliser.

4. Ne pas définir correctement Max Replicas

Pourquoi cela arrive : les équipes définissent maxReplicas trop haut pour éviter les limites de mise à l'échelle, mais cela peut entraîner des dépassements de coûts ou une surcharge du cluster.

Comment éviter : déterminez les réplicas maximaux en fonction de la planification de capacité et des contraintes de coût. Utilisez le HPA avec l'autoscaler de cluster pour garantir que des nœuds peuvent être ajoutés si nécessaire.

Récupération : ajustez maxReplicas après avoir observé les charges de pointe réelles et la capacité du cluster.

5. Oublier les délais de réduction d'échelle

Pourquoi cela arrive : les opérateurs s'attendent à une réduction immédiate après la baisse de charge, mais le HPA a une fenêtre de stabilisation par défaut de 5 minutes pour éviter les fluctuations. Cela peut entraîner des coûts inutiles s'il n'est pas pris en compte.

Comment éviter : comprenez et configurez le behavior de manière appropriée. Pour des économies agressives, réduisez la fenêtre de stabilisation, mais soyez conscient du risque de fluctuation.

6. Utiliser le HPA avec des applications avec état sans précaution

Pourquoi cela arrive : les StatefulSets peuvent être mis à l'échelle par le HPA, mais une coordination minutieuse est nécessaire avec les volumes persistants et l'ordre. Le HPA peut réduire des pods qui sont au milieu d'opérations importantes.

Comment éviter : utilisez des métriques personnalisées ou des hooks de cycle de vie pour retarder la réduction pendant les opérations critiques. Envisagez d'utiliser le Vertical Pod Autoscaler pour les charges de travail avec état.

Conclusion

Le Horizontal Pod Autoscaler de Kubernetes est un outil puissant pour maintenir les performances des applications et l'efficacité des coûts. En comprenant son architecture, vous pouvez le configurer en toute sécurité et résoudre les problèmes efficacement. Dans cet article, nous avons couvert :

• Les composants essentiels du HPA et son algorithme.
• L'inventaire de l'environnement et les prérequis.
• La configuration sécurisée étape par étape avec des exemples pratiques.
• Les techniques de vérification et de diagnostic.
• Les modes de défaillance courants et les étapes de récupération.
• La liste de contrôle opérationnelle et les pièges courants.

Comme prochaine étape, choisissez une vérification à faible risque dans la liste de contrôle, enregistrez votre état HPA actuel, exécutez la vérification documentée et comparez les résultats aux signaux attendus. Examinez les dépendances telles que le déploiement, le quota de ressources et les capacités des pods. Un flux de travail fiable rend les défaillances visibles, protège les valeurs sensibles, limite les modifications aux ressources prévues et définit la vérification de récupération avant que les incidents ne forcent des décisions. Avec ces pratiques, vous pouvez exploiter le HPA en toute confiance.