Kubernetes HPA : Guide du Horizontal Pod Autoscaler

Le Horizontal Pod Autoscaler (HPA) de Kubernetes ajuste automatiquement le nombre de réplicas de pods dans un deployment, replica set ou stateful set en fonction des métriques observées. Au lieu de mettre à l’échelle manuellement les charges de travail quand le trafic augmente à 2h du matin, HPA s’en charge pour vous. Dans ce guide, vous apprendrez comment HPA fonctionne en interne, comment le configurer avec des métriques CPU, mémoire et personnalisées, et comment ajuster les politiques de mise à l’échelle pour les charges de travail en production.

Prérequis

Avant de configurer HPA, assurez-vous d’avoir :

• Un cluster Kubernetes en fonctionnement (v1.23+) — minikube, kind, ou un cluster géré (EKS, GKE, AKS)
• kubectl installé et configuré pour communiquer avec votre cluster
• metrics-server déployé (la plupart des clusters gérés l’incluent par défaut)
• Une familiarité de base avec les Deployments et Services
• Un deployment avec des requests CPU/mémoire définis (HPA ne peut pas calculer l’utilisation sans eux)

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

kubectl get deployment metrics-server -n kube-system
kubectl top nodes
kubectl top pods

Si kubectl top retourne des métriques, vous êtes prêt à continuer.

Comment Fonctionne HPA

HPA s’exécute comme une boucle de contrôle dans le controller manager de Kubernetes, vérifiant les métriques à un intervalle configurable (par défaut : 15 secondes). À chaque itération il :

1. Récupère les valeurs de métriques actuelles depuis l’API de métriques pour tous les pods de la charge de travail cible
2. Calcule le nombre de réplicas souhaité en utilisant la formule :

$$ \text{réplicasSouhaitées} = \lceil \text{réplicasActuelles} \times \frac{\text{valeurMétriqueActuelle}}{\text{valeurMétriqueSouhaitée}} \rceil $$

3. Compare les réplicas souhaitées avec les réplicas actuelles
4. Met à l’échelle la charge de travail à la hausse ou à la baisse si le ratio dépasse une tolérance configurable (par défaut ±10%)

Par exemple, si votre deployment a 3 réplicas à 75% de CPU en moyenne et votre cible est 50% :

$$ \text{souhaité} = \lceil 3 \times \frac{75}{50} \rceil = \lceil 4.5 \rceil = 5 $$

HPA mettrait à l’échelle le deployment à 5 réplicas.

Comportement de cooldown : HPA utilise des fenêtres de stabilisation pour éviter les oscillations. Par défaut, les événements de scale-down utilisent une fenêtre de stabilisation de 5 minutes — HPA choisit le nombre de réplicas le plus élevé recommandé des 5 dernières minutes. Le scale-up n’a pas de fenêtre de stabilisation par défaut, réagissant immédiatement aux augmentations de charge.

Configuration de HPA avec Métriques CPU

Configuration Rapide avec kubectl

La manière la plus rapide de créer un HPA :

kubectl autoscale deployment my-app \
  --cpu-percent=50 \
  --min=2 \
  --max=10

Cela dit à Kubernetes : maintenez l’utilisation CPU moyenne à 50% sur tous les pods, avec un minimum de 2 et maximum de 10 réplicas.

Manifeste YAML Complet

Pour la production, définissez HPA comme un manifeste YAML versionnable :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 70

Appliquez et surveillez :

kubectl apply -f hpa.yaml
kubectl get hpa my-app-hpa --watch

La sortie ressemble à :

NAME         REFERENCE           TARGETS           MINPODS   MAXPODS   REPLICAS
my-app-hpa   Deployment/my-app   32%/50%, 45%/70%   2         10        3

Important : Les conteneurs de votre deployment doivent avoir des demandes de ressources définies, sinon HPA ne peut pas calculer les pourcentages d’utilisation :

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

Métriques Personnalisées et Métriques Externes

CPU et mémoire sont souvent insuffisantes pour les décisions de mise à l’échelle. Un service web peut avoir un CPU faible mais une grande file d’attente de requêtes. HPA v2 supporte trois types de métriques :

Type de Métrique	Source	Exemple
Resource	metrics-server	Utilisation CPU, mémoire
Pods	API de métriques personnalisées	Requêtes par seconde par pod
External	API de métriques externes	Profondeur de file SQS, backlog Pub/Sub

Configuration des Métriques Personnalisées avec Prometheus Adapter

Installez prometheus-adapter pour exposer les métriques Prometheus via l’API de métriques personnalisées de Kubernetes :

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus-adapter prometheus-community/prometheus-adapter \
  --namespace monitoring \
  --set prometheus.url=http://prometheus-server.monitoring.svc

Puis configurez un HPA utilisant une métrique personnalisée :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "100"

Mise à l’Échelle sur la Profondeur de File Externe

Pour les architectures événementielles, mettez à l’échelle sur une métrique externe comme une file SQS :

metrics:
  - type: External
    external:
      metric:
        name: sqs_queue_length
        selector:
          matchLabels:
            queue: "order-processing"
      target:
        type: Value
        value: "30"

Cela met à l’échelle vos pods consommateurs pour maintenir la longueur de file autour de 30 messages.

HPA vs VPA vs Cluster Autoscaler

Caractéristique	HPA	VPA	Cluster Autoscaler
Ce qu’il met à l’échelle	Nombre de réplicas de pods	Demandes CPU/mémoire par pod	Nombre de nœuds du cluster
Direction	Horizontale (plus de pods)	Verticale (pods plus grands)	Horizontale (plus de nœuds)
Métriques utilisées	CPU, mémoire, personnalisées, externes	Utilisation historique des ressources	Pods en attente de planification
Nécessite redémarrage	Non	Oui (recrée les pods)	Non (ajoute des nœuds)
Idéal pour	Apps sans état, scalables horizontalement	Apps mono-instance à ressources variables	Accommoder le scale-up de HPA
Peut combiner	Oui, avec Cluster Autoscaler	Pas avec HPA sur la même métrique	Oui, avec HPA
Vitesse de réaction	Secondes à minutes	Minutes (redémarrage de pod)	Minutes (provisionnement de nœud)

Combinaison recommandée : Utilisez HPA pour la mise à l’échelle des charges de travail + Cluster Autoscaler pour la mise à l’échelle de l’infrastructure. Évitez d’utiliser HPA et VPA sur la même métrique pour le même deployment — ils entreront en conflit.

Scénario Réel

Considérez une plateforme e-commerce qui voit 10x plus de trafic pendant les ventes flash. Votre deployment checkout-service gère normalement 50 requêtes/seconde avec 3 réplicas.

Sans HPA : Votre ingénieur d’astreinte reçoit une alerte à minuit, met à l’échelle manuellement à 20 réplicas, puis oublie de réduire. Vous payez pour des ressources inactives pendant 3 jours.

Avec HPA configuré :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: checkout-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: checkout-service
  minReplicas: 3
  maxReplicas: 30
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "50"
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Percent
          value: 100
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60

Cette configuration :

• Met à l’échelle agressivement à la hausse — doublant les réplicas toutes les 60 secondes quand le CPU dépasse 60% ou le taux de requêtes dépasse 50 req/s par pod
• Met à l’échelle conservativement à la baisse — supprimant seulement 10% des réplicas par minute avec une fenêtre de stabilisation de 5 minutes
• Empêche la réduction prématurée après de courtes rafales de trafic

Pendant la vente flash, HPA passe de 3 à 25 réplicas en moins de 5 minutes. Après que le trafic diminue, il réduit progressivement à 3 en environ 30 minutes.

Politiques de Mise à l’Échelle et Comportement

Le champ behavior (autoscaling/v2) vous donne un contrôle précis sur la vitesse de mise à l’échelle :

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

Champs clés :

• stabilizationWindowSeconds — combien de temps HPA regarde en arrière pour choisir la recommandation la plus conservatrice. Définissez à 0 pour un scale-up immédiat ; 300 (5 min) pour un scale-down prudent.
• policies — définit la vitesse de mise à l’échelle en pourcentage des réplicas actuelles ou nombre absolu de pods par période de temps.
• selectPolicy — Max choisit la politique permettant le plus de changement (agressif), Min choisit la plus conservatrice, Disabled empêche la mise à l’échelle dans cette direction.

Modèles de Politiques Courants

Scale-up rapide, scale-down lent (recommandé pour la plupart des apps web) :

scaleUp:
  stabilizationWindowSeconds: 0
  policies:
    - type: Percent
      value: 100
      periodSeconds: 15
scaleDown:
  stabilizationWindowSeconds: 300
  policies:
    - type: Pods
      value: 1
      periodSeconds: 60

Empêcher le scale-down entièrement (jobs batch) :

scaleDown:
  selectPolicy: Disabled

Pièges et Cas Particuliers

Délai des métriques : Metrics-server collecte les données toutes les 15 secondes, et HPA évalue toutes les 15 secondes. Cela signifie qu’il y a un délai de 15–30 secondes entre un pic de charge et la première décision de mise à l’échelle. Pour les services sensibles à la latence, envisagez de commencer avec plus de minReplicas.

Demandes de ressources manquantes : Si vos conteneurs ne définissent pas de requests CPU ou mémoire, HPA signale <unknown> pour l’utilisation et ne mettra pas à l’échelle. Définissez toujours les requests.

Les sondes de disponibilité comptent : HPA ne compte que les pods Ready lors du calcul des métriques. Si les nouveaux pods mettent 60 secondes à devenir prêts, HPA peut sur-provisionner car les pods existants restent surchargés pendant le démarrage. Ajustez les sondes de disponibilité et envisagez des sondes de démarrage pour les applications à démarrage lent.

Conflits avec PodDisruptionBudget : Un PDB qui autorise zéro pod indisponible peut bloquer le scale-down si HPA tente de supprimer des réplicas pendant une interruption volontaire. Assurez-vous que le minAvailable de votre PDB est inférieur au minReplicas de votre HPA.

Interaction de métriques multiples : Quand HPA évalue plusieurs métriques, il calcule le nombre de réplicas souhaité pour chaque métrique indépendamment et choisit la valeur la plus élevée. Cela signifie qu’un pic sur une seule métrique peut déclencher la mise à l’échelle même si les autres métriques sont basses.

Latence HPA et Cluster Autoscaler : HPA crée de nouveaux pods immédiatement, mais si aucun nœud n’a de capacité, les pods restent en Pending jusqu’à ce que Cluster Autoscaler provisionne de nouveaux nœuds (typiquement 2–5 minutes sur les fournisseurs cloud). Tenez-en compte dans votre stratégie de mise à l’échelle.

Métrique d’objet vs métrique de pods : Utilisez le type Pods quand la métrique est par pod (taux de requêtes). Utilisez le type Object quand la métrique provient d’un seul objet Kubernetes comme un Ingress.

Résumé

• HPA met automatiquement à l’échelle les réplicas de pods en fonction des métriques CPU, mémoire, personnalisées ou externes
• La formule de mise à l’échelle est réplicasSouhaitées = ceil(réplicasActuelles × métriqueActuelle / métriqueCible)
• Définissez toujours les requests CPU et mémoire dans vos conteneurs — HPA ne fonctionne pas sans eux
• Utilisez l’API autoscaling/v2 pour la mise à l’échelle multi-métriques et les politiques de comportement
• Configurez un scale-up agressif et un scale-down conservateur pour les charges de production
• Combinez HPA avec Cluster Autoscaler pour une mise à l’échelle élastique complète — évitez de combiner HPA et VPA sur la même métrique
• Les métriques personnalisées via prometheus-adapter débloquent la mise à l’échelle sur des métriques métier comme le taux de requêtes ou la profondeur de file
• Testez votre configuration HPA sous charge réaliste avant de vous y fier en production

Articles Connexes

• Kubernetes Fundamentals: Deploy Your First Cluster
• K3s Lightweight Kubernetes for Homelab
• Docker Compose Practical Guide for Sysadmins
• Terraform Infrastructure as Code Getting Started Guide