Accueil · Journal · HPA scale
N° 140 — Article SRE · Niveau intermédiaire

Pourquoi votre HPA ne scale pas assez vite — et comment corriger.

En audit, c'est le même scénario tous les mois : les pods arrivent deux minutes trop tard, la latence grimpe, l'astreinte se déclenche. Dans 80% des cas, la cause tient en une ligne de configuration que personne n'a relue.

Auteur
Corentin Mas, associé fondateur
Publié
15 avril 2026
Lecture
8 minutes
Niveau
SRE intermédiaire

01 — Le symptôme : deux minutes de latence inexpliquées

Le scénario, on le voit chaque semaine. Un pic de trafic arrive — ouverture de Black Friday, publication d’un article, demi-finale d’un match. Le CPU moyen des pods grimpe à 85%, 90%, 95%. L’HPA finit par réagir. Mais c’est ce finir par qui est le mot important : entre l’instant où la charge augmente et l’instant où les nouveaux pods sont opérationnels, il s’écoule deux à trois minutes.

Pendant cette fenêtre, la latence p95 explose, quelques requêtes expirent, et l’astreinte est appelée. Quand on arrive en audit et qu’on demande pourquoi le scaling n’est pas plus réactif, les réponses sont toujours les mêmes : « l’HPA est configuré, le CPU cible est à 70%, ça devrait suffire ».

Sur les 14 dernières missions de revue SRE que nous avons conduites (2023-2026), 11 clients avaient le même défaut de configuration par défaut sur leur HPA. Aucun ne l'avait vu.
— Constat récurrent en mission

02 — La boucle de décision interne du HPA

Pour comprendre d’où viennent ces deux minutes, il faut regarder la boucle interne du contrôleur. La fréquence est pilotée par --horizontal-pod-autoscaler-sync-period. Sa valeur par défaut depuis Kubernetes 1.4 ? Quinze secondes.

03 — Le correctif : trois lignes de configuration

Depuis Kubernetes 1.18, le HPA v2 expose un bloc behavior qui permet de contrôler finement la politique de montée et de descente.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15
    scaleDown:
      stabilizationWindowSeconds: 300

04 — Mesures avant/après sur une charge réelle

  • Latence p95 avec configuration par défaut : 120 ms à 1 480 ms en 90 secondes
  • Latence p95 avec bloc behavior : plafonne à 340 ms, retour à la normale en moins d’une minute
  • Coût infrastructure : léger surcoût acceptable

05 — Pour aller plus loin

Notre Audit FinOps Express et nos missions Platform Engineering incluent systématiquement une revue HPA et autoscaling. Si votre cluster Kubernetes a des comportements de scaling que vous ne maîtrisez pas, c’est typiquement le genre de sujet qu’on traite en quelques jours.
N° 141 — Conversation préalable

Discuter de votre HPA avec Corentin.

Si vous reconnaissez le scénario décrit, conversation préalable d'une heure pour cadrer un audit.

Délai de réponse
Sous 24 heures ouvrées
Confidentialité
NDA fourni sur demande
Format
1 h · visio ou présentiel
Interlocuteur
Associé fondateur
Retour en haut