Quand dois-je utiliser la mise à l’échelle automatique des pods horizontaux (HPA) dans Kubernetes ?

Réponse courte : utilisez le HPA lorsque votre charge de travail peut s’exécuter en plusieurs réplicas identiques et que la charge varie — avec une mise à l’échelle en fonction du CPU/de la mémoire, des métriques applicatives (RPS/latence) ou de métriques externes de file d’attente ou de volume en attente. N’utilisez pas HPA pour les services avec état à une seule réplique ni lorsque le véritable goulot d’étranglement est la capacité des nœuds ou des contraintes en aval (connexions à la base de données, limites de débit imposées par des services tiers).

TL;DR :

  • Utilisez l’HPA pour les charges de travail pouvant être partitionnées horizontalement, lorsque des métriques par pod ou des métriques externes reflètent la charge.
  • Utiliser des métriques de ressource/personnalisées/externes (CPU, RPS, longueur de file d’attente) ; combiner avec Cluster Autoscaler pour gérer la capacité des nœuds.
  • Utilisez KEDA pour la mise à l’échelle jusqu’à zéro basée sur les événements ou les mécanismes de mise à l’échelle externes ; utilisez VPA en mode de recommandation pour le dimensionnement des requêtes de ressources.

Liste de contrôle de décision rapide (Oui/Non) :

  • La charge de travail est-elle sans état ou répartissable entre plusieurs réplicas ? (Oui → candidat HPA)
  • Pouvez-vous observer la charge sous la forme d’une métrique par pod ou externe (PROCESSEUR, demandes/s, profondeur de file d’attente) ? (Oui → HPA adapté)
  • Le cluster peut-il planifier davantage de pods (Mise à l’échelle automatique du cluster ou capacité de rechange) ? (Oui → continuer ; si non, activez la mise à l’échelle automatique des nœuds)
  • Les services en aval (pools de bases de données, API tierces) limitent-ils la concurrence ? (Oui → ajouter une limitation du débit/un pool de connexions ou préférer la mise à l’échelle verticale)

Matrice de décision (charge de travail → meilleure métrique → scaler recommandé) :

Type de charge de travail Meilleure métrique à cibler Outil de mise à l’échelle recommandé
Web/API (sans état) CPU ou RPS par pod HPA (+ recommandation de VPA + Cluster Autoscaler)
Processus de file d’attente en arrière-plan Longueur de file d’attente ou messages/s HPA via des métriques externes ou KEDA (KEDA prend en charge la mise à l’échelle à zéro)
Base de données à instance unique ou application avec état N/A (non partitionnable horizontalement) VPA ou mise à l’échelle manuelle
Processus de traitement d’événements par lot/éphémères Arriéré d’événements KEDA ou HPA avec des métriques externes

Fonctionnement de HPA (boucle de contrôle simple et champs importants)

  • Composants : contrôleur HPA (plan de contrôle) + fournisseurs de métriques (métriques-serveur pour les métriques de ressources, API de métriques personnalisées/externes via des adaptateurs ou KEDA).
  • Boucle de contrôle (vue d’ensemble) : le contrôleur HPA interroge l’API de métriques → calcule le nombre de réplicas souhaité à partir de chaque métrique configurée → retient le plus grand nombre de réplicas souhaité calculé → applique les valeurs min/max et le comportement (stratégies/stabilisation) → met à jour spec.replicas de la ressource cible → puis recommence. Pour plus d’informations, consultez les documents HPA Kubernetes .
  • Formule (mode de calcul des réplicas souhaités) : desiredReplicas = ceil(current_total/target_per_pod). Le contrôleur calcule un desiredReplicas pour chaque métrique configurée, puis utilise la plus grande valeur avant d’appliquer min/max et comportement (ce comportement de précédence des métriques est documenté dans la documentation HPA).
  • Champs importants d’autoscaling/v2 : minReplicas, maxReplicas, métriques (Resource, Pods, Object, External), comportement (politiques scaleUp/scaleDown et stabilizationWindowSeconds).
  • Utilisez le comportement pour limiter le taux de modification et éviter le flapping ; stabilisationWindowSeconds est un bouton clé pour le lissage scaleDown.

Exemple d’extrait de code de comportement (mise à l’échelle automatique/v2)

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

Quand utiliser HPA (par type de métrique / cas d’usage courants)

  1. PROCESSEUR/mémoire (Métriques de ressources)
    • Utilisez HPA lorsque l’utilisation du processeur ou de la mémoire par pod est corrélée aux besoins de capacité et que les pods définissent des requêtes de ressources appropriées. Typique des API web et des microservices sans état.
    • Point de départ pratique : ciblez l’utilisation moyenne du processeur dans la plage de 60 à 80% et paramétrez par les tests de charge. HPA calcule l’utilisation des demandes de pod, de sorte que les requêtes doivent être définies.
  2. Métriques de cluster personnalisées (Prometheus / métriques personnalisées)
    • Utilisez HPA lorsque les signaux au niveau de l’application (requêtes/s, latence, consommateurs de files d’attente/pod) représentent mieux la charge que le processeur.
    • Exposez des métriques avec Prometheus + prometheus-adapter (custom.metrics.k8s.io) ou un autre fournisseur de métriques personnalisées et ciblez ces métriques dans HPA.
  3. Métriques externes (files d’attente, arriérés dans le cloud)
    • Utilisez HPA (via l’API de métriques externes) ou KEDA lorsque la mise à l’échelle doit réagir aux signaux externes tels que la longueur de file d’attente (RabbitMQ, Azure Service Bus), Event Hubs ou les métriques de supervision cloud.
    • Si vous avez besoin d’une mise à l’échelle à zéro ou d’un comportement événementiel très réactif, privilégiez KEDA : il intègre nativement des mécanismes de mise à l’échelle externes et prend en charge la mise à l’échelle à zéro (documentation KEDA).

Quand ne pas utiliser HPA

  • Services avec état à réplique unique (bases de données, état unique au sein du pod) : HPA n’est pas approprié, sauf si vous pouvez fragmenter ou partitionner en toute sécurité.
  • Lorsque le goulot d’étranglement se trouve au niveau du nœud (GPU, E/S de disque, processeur de nœud) plutôt que par pod : préférez la mise à l’échelle automatique du pool de nœuds ou la mise à l’échelle verticale.
  • Lorsque les systèmes en aval (pools de connexions de base de données, caches, API tierces) ont des limites strictes de concurrence, augmenter le nombre de pods sans accroître la capacité des systèmes en aval peut aggraver les pannes — voir « Considérations relatives aux systèmes en aval et à l’exploitation » ci-dessous.
  • Si vous avez besoin d’une mise à l’échelle jusqu’à zéro, le HPA seul ne permet pas de le faire ; utilisez KEDA ou un contrôleur externe.

Plusieurs métriques, précédence et un exemple

  • Si vous configurez plusieurs métriques, le contrôleur HPA calcule séparément une valeur de desiredReplicas pour chaque métrique, puis sélectionne ensuite la plus grande valeur de desiredReplicas comme base pour la mise à l’échelle. Après cela, minReplicas/maxReplicas et les stratégies de comportement sont appliquées (source : documents HPA Kubernetes).
  • Exemple : la cible d’utilisation CPU calcule 5 répliques, la cible de requêtes/s calcule 12 répliques → le HPA retiendra 12 (puis les politiques min/max et de comportement pourront modifier le changement final appliqué).
  • Pour éviter un dépassement soudain, combinez une stratégie scaleUp basée sur un pourcentage et une stabilisation scaleDown raisonnableWindowSeconds (voir l’extrait de code de comportement ci-dessus).

HPA vs VPA vs Cluster Autoscaler vs KEDA (guide rapide)

  • HPA : ajuste horizontalement le nombre de réplicas selon des métriques. Idéal pour les charges de travail partitionnables.
  • VPA : ajuste les requêtes et limites de ressources des pods (verticalement). Idéal pour les charges de travail non parallélisables ou pour définir des valeurs par défaut sensibles.
  • Mise à l’échelle automatique du cluster (ou Karpenter) : met à l’échelle les nœuds pour répondre aux demandes de planification (capacité au niveau du nœud). À utiliser lorsque les pods restent à l’état Pending en raison de l’absence de nœuds disponibles.
  • KEDA : outil de mise à l’échelle automatique basée sur les événements qui intègre des déclencheurs externes et prend en charge la mise à l’échelle à zéro pour les charges de travail événementielles.

Modèle courant : utilisez VPA en mode recommandation pour définir les requêtes de base, HPA pour ajuster le nombre de réplicas et Cluster Autoscaler (ou Karpenter) pour fournir la capacité des nœuds. Utilisez KEDA quand vous avez besoin d’une mise à l’échelle à zéro ou d’une intégration directe avec des sources d’événements externes.

Remarque : les offres Kubernetes gérées (AKS/GKE/EKS) peuvent préinstaller des fournisseurs de métriques ou fournir des fonctionnalités de mise à l’échelle automatique intégrées. Documentation sur la mise à l’échelle automatique du cluster AKS

Considérations en aval et opérationnelles (pièges fréquents)

  • Pools de connexions de base de données : l’augmentation du nombre de réplicas augmente le nombre de connexions simultanées. Atténuer avec le regroupement de connexions (p. ex., PgBouncer), limiter la concurrence par pod ou augmenter la taille du pool de bases de données avant la mise à l’échelle des pods.
  • Limites de débit des API et quotas de services tiers : assurez-vous que les systèmes en aval peuvent gérer le volume de requêtes généré par les pods après mise à l’échelle ; envisagez une limitation du débit côté client.
  • PodDisruptionBudgets (PDB) : les PDB n’empêchent pas le scale-up HPA, mais peuvent affecter les opérations de maintenance et le comportement de drainage ; vérifiez que les stratégies de mise à l’échelle s’alignent sur les PDB.
  • Les effets de démarrage et de préchauffage : les initContainers, le préchauffage du cache ou les démarrages à froid longs peuvent fausser les métriques et provoquer l’oscillation : utiliser des sondes de préparation/démarrage et des fenêtres de stabilisation.
  • Approche opérationnelle recommandée : définissez des paramètres de mise à l’échelle prudents, ajustez les requêtes et les limites de ressources ainsi que les sondes, testez dans un environnement hors production et ajoutez une limitation de débit tenant compte des SLO si les systèmes en aval constituent un goulot d’étranglement.

Étapes de déploiement sécurisées et de liste de contrôle de configuration

Assurez-vous que les métriques et le RBAC sont en place :

  • Déployez metrics-server pour les métriques de ressources (ou utilisez un fournisseur managé).
  • Déployez Prometheus + prometheus-adapter pour les métriques personnalisées (custom.metrics.k8s.io) si nécessaire.
  • Pour les scalers externes ou les scalers d'événements, envisagez KEDA.

Écrivez HPA (mise à l’échelle automatique/v2) avec :

  • minReplicas et maxReplicas,
  • Métriques et comportement explicites (stratégies scaleUp/scaleDown),
  • sondes de disponibilité et de démarrage sur les pods,
  • demandes de ressources sensibles afin que les métriques de ressource soient significatives.

Liste de contrôle de test sécurisée (comment tester HPA en toute sécurité) :

  1. Testez dans un espace de noms/un cluster hors production avec des tailles de nœud similaires et une mise à l’échelle automatique activées.
  2. Commencez avec des répliques min/max conservatrices et des politiques d’augmentation progressives (par exemple, une croissance maximale de 100 % par minute).
  3. Effectuez des tests de charge progressifs, surveillez desiredReplicas par rapport à currentReplicas ainsi que les pods en attente.
  4. Ajustez les requêtes/limites, les sondes de préparation et les politiques de comportement avant d’augmenter l’agressivité.

Remarques sur AKS et la mise à l’échelle automatique des nœuds :

  • AKS et d’autres offres cloud peuvent préinstaller des métriques-serveur ou offrir une intégration de mise à l’échelle automatique managée. Exemple d’interface CLI AKS pour activer la mise à l’échelle automatique du cluster : az aks nodepool update --resource-group myRG --cluster-name myAKS --name node-pool1 --enable-cluster-autoscaler --min-count 1 --max-count 5

Remarque Karpenter : Karpenter est une méthode alternative de mise à l’échelle automatique des nœuds, axée sur le provisionnement rapide ; envisagez cette solution lorsqu’un provisionnement rapide des nœuds est nécessaire.

Exemples YAML de travail

HPA basé sur le processeur (mise à l’échelle automatique/v2) :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: webapi-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: webapi
  minReplicas: 3
  maxReplicas: 12
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Pods
          value: 1
          periodSeconds: 60

HPA utilisant une métrique personnalisée exposée par Prometheus (via prometheus-adapter) :

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

Consultez la documentation de l’adaptateur prometheus pour les requêtes de mappage

KEDA ScaledObject (Azure Service Bus) : prend en charge la mise à l’échelle à zéro :

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: sb-queue-scaledobject
  namespace: workers
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: event-worker
  minReplicaCount: 0
  maxReplicaCount: 20
  pollingInterval: 30
  cooldownPeriod: 300
  triggers:
    - type: azure-servicebus
      metadata:
        queueName: orders-queue
        queueLength: "50"
      authenticationRef:
        name: keda-azure-credentials

Documentation KEDA

Observabilité, alertes et exemples SRE

Alertes suggérées (exemples Prometheus pouvant être copiés : ajustez les noms de métriques à votre configuration d’exportation) :

  1. Alerte lorsque la valeur souhaitée de HPA est inférieure à la valeur actuelle > pendant > 5 min (problème de capacité d’ordonnancement)

    alert: HPAUnschedulable
expr: (kube_hpa_status_desired_replicas - kube_hpa_status_current_replicas) > 0
for: 5m
labels:
  severity: page
annotations:
  summary: "HPA desired replicas exceed current replicas for >5m (possible scheduling issue)"

  2. Alerte concernant les pods en attente dans un espace de noms

    alert: PodsPendingHigh
expr: sum(kube_pod_status_phase{phase="Pending", namespace="production"}) > 3
for: 2m
labels:
  severity: ticket
annotations:
  summary: "High number of Pending pods in production"

  3. Alerte en cas de mise à l’échelle fréquente (flapping)

    alert: HPAFlapping
expr: increase(kube_hpa_status_replicas_last_transition_count[10m]) > 5
for: 0m
labels:
  severity: warning
annotations:
  summary: "Frequent HPA scaling events detected"

Tableaux de bord d’instrument montrant :

  • HPA : currentReplicas, desiredReplicas, lastScaleTime, valeurs de métrique utilisées par HPA
  • Santé des pods : pods en attente, événements FailedScheduling, nombre de redémarrages des pods
  • En aval : utilisation de la connexion de base de données, taux d’erreur, taux d’erreur d’API externe/429

Commandes d’exploitation et de débogage (référence rapide)

  • Lister les HPA: kubectl get hpa -n
  • Décrivez le HPA (recherchez les métriques current/current, desiredReplicas, lastScaleTime, les événements) : kubectl describe hpa -n
  • Champs à inspecter dans décrire la sortie : currentReplicas, desiredReplicas, métriques (valeurs actuelles/cibles), lastScaleTime, événements (erreurs provenant du fournisseur de métriques ou des échecs de mise à l’échelle)
  • Afficher l’utilisation des ressources (nécessite metrics-server) : kubectl top pods -n
  • Vérifiez les pods en attente et les échecs de planification : kubectl get pods -n | grep Pending, kubectl describe pod -n (recherchez FailedScheduling)
  • Vérifier les journaux du fournisseur de métriques : kubectl logs -n kube-system deploy/metrics-server, kubectl logs -n deploy/prometheus-adapter
  • Appliquez le manifeste HPA : kubectl apply -f hpa.yaml

Conseils de dépannage rapides :

  • Le HPA indique desiredReplicas > currentReplicas et les pods restent à l’état Pending → capacité des nœuds probablement insuffisante ; activez le Cluster Autoscaler ou augmentez le pool de nœuds.
  • HPA affiche des erreurs liées aux métriques dans les événements → vérifiez la configuration RBAC de l’adaptateur et les journaux du fournisseur de métriques.
  • Mise à l’échelle du HPA trop rapide/lente → régler les politiques de comportement (limites en pourcentage/nombre de pods) et les fenêtres de stabilisation.

Paramètres par défaut recommandés et heuristiques

  • Cible du processeur : commencez autour de 60 % de taux d’utilisation moyen (plage courante de 60 à 80 %), puis ajustez en fonction de la charge de travail.
  • minReplicas : au moins 1 pour la disponibilité ; utilisez KEDA si vous avez besoin de minReplicas : 0.
  • maxReplicas : défini en fonction de la planification de la capacité et du coût ; assurez-vous que les limites de Cluster Autoscaler autorisent l’ajout de nœuds jusqu’à la capacité requise.
  • stabilizationWindowSeconds: scaleDown ≈ 300s (5 min) est un point de départ courant pour éviter une réduction rapide du dimensionnement ; à ajuster selon la charge de travail.
  • stratégies de mise à l’échelle : plafonner les augmentations en pourcentage par période (par exemple, autoriser une croissance maximale de 100 % par minute) pour éviter de surcharger les systèmes en aval.
  • Sondes de préparation/de démarrage : définissez-les toujours afin que les pods ne reçoivent de trafic que lorsqu’ils sont entièrement prêts.

Remarque : les valeurs par défaut du minutage du contrôleur et le comportement exact peuvent varier entre les versions et les distributions kubernetes : consultez la documentation HPA de votre version de cluster.

Pièges courants et liste de contrôle avant d’activer HPA

  • Requêtes de ressources du pod manquantes ou incorrectes → les cibles HPA basées sur les ressources seront faussées.
  • Aucun fournisseur de métriques (metrics-server/prometheus-adapter/KEDA) → HPA ne peut pas lire les métriques.
  • Le cluster n’a aucune capacité au niveau des nœuds et l’autoscaler du cluster n’est pas activé → les pods resteront à l’état Pending.
  • Combiner HPA et VPA : évitez que les deux contrôleurs modifient activement les requêtes de ressources — exécutez le VPA en mode recommandation et laissez le HPA ajuster le nombre de réplicas.
  • Pics de démarrage (initContainers, caches à froid) sans sondes → ajuster manuellement les fenêtres de stabilisation ou les instances chaudes.
  • Configuration incorrecte du RBAC : vérifiez que les adaptateurs de métriques et le contrôleur HPA disposent des autorisations requises pour lire les métriques.

Questions fréquentes (FAQ)

Q : Quels sont les avantages de HPA ? R : adaptez automatiquement le nombre de réplicas à la modification de la charge, améliorez l’utilisation et le coût, et conservez les cibles de latence lorsqu’elles sont utilisées avec les métriques et la mise à l’échelle automatique des nœuds appropriées.

Q : Comment HPA calcule-t-il le nombre souhaité de réplicas ? R : il lit les métriques configurées, calcule desiredReplicas = ceil(current_total/target_per_pod) pour chaque métrique, prend la plus grande valeur calculée, puis applique des stratégies min/max et de comportement (source : documents HPA).

Q: HPA peut-il être mis à l’échelle jusqu’à zéro ? R : Non — un HPA standard ne peut pas être ramené à zéro. Utilisez KEDA pour le comportement de mise à l’échelle à zéro (documentation KEDA).

Q : Comment effectuer une mise à l’échelle en fonction de la longueur de la file d’attente ou du RPS ? R : Exposez la longueur de file d’attente/RPS en tant que métrique externe ou personnalisée (adaptateur Prometheus ou API de métriques externes) ou utilisez KEDA pour la mise à l’échelle pilotée par les événements.

References

  • Last updated on