Guide Kubernetes SRE

Autoscaling Kubernetes : HPA, KEDA, garde-fous de capacité

L'autoscaling fonctionne lorsque les signaux de demande, le temps de démarrage des pods, la capacité du cluster et les limites en aval sont conçus comme un seul système d'exploitation.

Publié le: 14 juil. 2026
Mis à jour le: 15 juil. 2026
Temps de lecture: 21 min de lecture

Sur cette page

L'autoscaling Kubernetes peut ajouter des réplicas, mais les réplicas seuls ne garantissent pas une latence plus faible ni un débit supérieur. Un service peut être limité par une base de données non extensible, un pool de connexions, un quota externe, une récupération d'image lente, un pod en attente ou un cache froid. Traitez l'autoscaling comme une boucle de rétroaction avec des signaux, limites et validations explicites, et non comme un substitut à la planification de capacité.

Cette discipline compte encore davantage dès qu'une couche d'orchestration managée pilote le trafic en amont de l'origine : si HPA et KEDA font monter ou descendre en charge un backend plus vite ou plus lentement que ce qu'attend la périphérie, la Performance, la Sécurité et la Visibilité héritent toutes de ce décalage. Les garde-fous de mise à l'échelle doivent donc être examinés dans la même vue système, pas isolément.

La première question est ce qui doit monter en charge. Les charges de travail qui servent des requêtes réagissent souvent à la concurrence, à l'utilisation ou à des signaux proches de la latence. Les workers réagissent généralement au backlog et au taux d'arrivée. Les systèmes avec état ont besoin de leur propre plan de réplication, de partitionnement et de stockage ; augmenter les réplicas applicatifs peut accroître la pression plutôt que la capacité.

Montez en charge selon le travail, pas selon un graphique pratique

Le CPU peut être un proxy utile lorsqu'il reflète la saturation. Sinon, choisissez un signal plus proche du travail contraint, tel que les requêtes en cours, la profondeur de file, le retard du consommateur ou une métrique personnalisée agrégée de manière sûre.

Scénario de référence : l'API catalogue d'Acme Shop

Prenons Acme Shop comme fil rouge. Son service catalog-api expose des fiches produit en lecture publique et s'appuie sur un petit pool de connexions pour les échecs de cache. Les tests de charge montrent qu'un pod reste utile jusqu'à environ 70 % de CPU moyen, met 45 secondes à devenir prêt et ouvre au maximum huit connexions. La base de données du bac à sable en autorise 80 : l'équipe retient donc un maximum de huit réplicas, en réservant de la capacité pour les autres clients — le HPA est un garde-fou, pas une autorisation de dépasser la limite testée. Acme Shop exploite aussi un consommateur order-events, vidé selon la profondeur de file plutôt que le CPU ; ce guide y revient pour montrer comment HPA et KEDA se partagent ce travail.

L'objectif est simple : monter en charge l'API catalogue pour une rampe de trafic mesurée sans dépasser le budget de connexions, et monter en charge le consommateur d'événements sans franchir les mêmes garde-fous. Cela suppose un namespace non productif, un comportement CPU et un démarrage mesurés, un Deployment prêt, un pipeline de métriques équivalent à Metrics Server, de la marge sur les nœuds et un seuil d'activation de backlog convenu.

La boucle suit cinq étapes qui doivent toutes réussir : un signal de demande fiable, une recommandation du HPA qui reste dans les bornes minimale et maximale, une planification qui exige des ressources et des adresses IP allouables, une mise en disponibilité qui laisse les nouveaux pods se réchauffer avant de recevoir du trafic, et une protection de la dépendance qui maintient les connexions cumulées sous le plafond validé. La mise à l'échelle ne réussit que si un réplica se planifie, devient prêt et accomplit un travail utile sans saturer une dépendance.

Établir une base sûre

Avant de configurer un HorizontalPodAutoscaler (HPA), définissez des demandes de ressources significatives pour le CPU et la mémoire, puis validez-les sous une charge représentative, comme le fait le scénario Acme Shop en mesurant plutôt qu'en devinant. Les demandes éclairent la planification ; sans elles, le cluster ne peut pas prendre de décisions de placement crédibles. Les limites demandent autant de soin : une limite CPU peut provoquer une limitation qui augmente la latence de traîne, tandis qu'une limite de mémoire trop basse provoque des redémarrages. Mesurez plutôt que de copier des valeurs d'un service à l'autre.

Documentez le modèle de concurrence de la charge de travail, sa durée de démarrage, ses critères de disponibilité, son comportement de terminaison gracieuse, son nombre maximal utile de réplicas et les limites de ses dépendances. Un pod qui reçoit du trafic avant d'avoir réchauffé ses connexions ou sa configuration donnera l'impression que la mise à l'échelle réussit tout en augmentant les erreurs. Les sondes de disponibilité doivent exprimer l'aptitude à servir le trafic prévu, et non simplement l'existence d'un processus.

Configurer le comportement HPA pour la charge de travail

Le HPA évalue les métriques au fil du temps et ajuste le nombre de réplicas souhaités dans les limites configurées. Pour catalog-api, Acme Shop fixe minReplicas à 2 afin de couvrir la disponibilité de base et maxReplicas à 8, en cohérence avec le plafond de connexions établi plus haut : le maximum est un garde-fou, pas une promesse de performance. La métrique cible reste l'utilisation CPU moyenne à 70 %, portée par la ressource autoscaling/v2.

Utilisez le comportement de montée et de descente en charge pour éviter les oscillations. Dans le bac à sable Acme Shop, la montée autorise jusqu'à deux pods de plus par minute sans fenêtre de stabilisation pour absorber un pic rapidement, tandis que la descente est plafonnée à 25 % des réplicas par minute après cinq minutes de stabilisation, pour limiter le churn une fois le trafic retombé. Des changements de montée illimités peuvent en revanche submerger une base de données ou une API tierce. Validez ce comportement lors de véritables montées de trafic, pas seulement avec un test de charge stable.

Pour les métriques personnalisées, assurez-vous que la métrique est récente, correctement agrégée et toujours disponible en cas de problème d'exporteur ou de backend de supervision. Un taux dérivé d'une courte période peut être bruité à faible volume. Une métrique de latence peut provoquer une boucle dangereuse lorsque la latence vient d'une dépendance qui ne s'améliore pas avec davantage de pods. Prévoyez un runbook de repli pour les métriques absentes ou invraisemblables.

Avec huit connexions par pod, huit réplicas catalogue peuvent demander jusqu'à 64 connexions, ce qui laisse 16 connexions de marge pour les migrations, l'administration et les autres consommateurs approuvés. Ce calcul relève de la planification, pas de la preuve que la base peut absorber le débit de requêtes qui en résulte : validez ensemble l'attente de pool, la latence des requêtes et le taux d'échec de cache. Un test représentatif affichait ainsi 82 % d'utilisation contre une cible de 70 %, quatre réplicas prêts, aucun pod en attente et 28 connexions actives dans le pool — le type de lecture croisée à conserver dans un tableau de bord de validation.

Ajuster les garde-fous de mise à l'échelle : tolérance, stabilisation et métriques manquantes

Le bloc de comportement n'est que la moitié de ce qui façonne une décision : le contrôleur applique aussi une tolérance par défaut, ignorant une action lorsque le rapport entre la métrique courante et la désirée reste à environ 10 % de 1,0. Sur un plafond de huit réplicas comme catalog-api, cette bande représente près d'un réplica de marge — ce qui explique pourquoi 82 % contre 70 % déclenche un nouveau calcul alors que 74 % ne le ferait pas. Kubernetes 1.33 a introduit la fonctionnalité alpha HPAConfigurableTolerance, qui permettra des tolérances de montée et de descente distinctes pour un même HPA ; une piste d'avenir, pas un appui avant qu'elle ne dépasse le stade alpha.

Le contrôleur se montre aussi prudent avec des métriques incomplètes : un pod dont la lecture manque compte pour 100 % de la cible côté descente mais 0 % côté montée, et les pods pas encore prêts sont exclus de la même façon — ce qui amortit les deux directions au moment précis où une mauvaise estimation coûterait le plus cher, y compris pendant la période de grâce d'initialisation du CPU juste après un déploiement.

HPA et KEDA : comment les deux mécanismes se partagent la mise à l'échelle

KEDA ne remplace pas le HPA : il le prolonge. Un ScaledObject surveille une source d'événements — profondeur de file ou retard de consommateur — et prend lui-même la décision d'« activation » de 0 à 1 réplica. Dès qu'un premier réplica doit exister, KEDA crée en coulisses un HPA autoscaling/v2 standard pour la plage de 1 à N réplicas ; la tolérance et le comportement face aux métriques manquantes décrits plus haut s'appliquent donc exactement comme pour catalog-api.

Le consommateur order-events d'Acme Shop correspond bien à ce découpage : inactif lorsque la file est vide, mais il ne doit pas prendre de retard dès qu'un backlog apparaît. Son ScaledObject s'appuie sur un déclencheur RabbitMQ ciblant la file order-events, en mode QueueLength avec un seuil d'activation de 50 messages. Le pollingInterval par défaut (30 s) fixe la fréquence de vérification ; le cooldownPeriod par défaut (300 s) fixe le temps que le backlog doit rester résorbé avant de redescendre vers minReplicaCount, qui vaut 0 par défaut et autorise la mise à l'échelle vers zéro. maxReplicaCount vaut 100 par défaut si on ne le précise pas — le même raisonnement de connexions qui plafonne catalog-api à huit réplicas s'applique ici, d'où le choix de fixer maxReplicaCount à 6.

La mise à l'échelle vers zéro a un coût réel : le premier message après un démarrage à froid ajoute typiquement de quelques secondes à bien plus de dix, selon l'image et le travail d'initialisation — acceptable pour order-events, où la mise en file est invisible pour l'acheteur, mais pas pour un chemin synchrone sensible à la latence. Les gestionnaires doivent aussi rester idempotents et à concurrence bornée, car un événement de montée en charge peut confier le même backlog à davantage de workers qu'il n'en existait un instant plus tôt.

N'exposez pas largement les identifiants des scalers. Utilisez les contrôles de secrets et d'identité de charge de travail de la plateforme, limitez les autorisations à la métrique ou à la source d'événements requise, faites tourner les identifiants et surveillez les erreurs de scaler. KEDA est un composant de mise à l'échelle, pas l'assurance que le système d'événements ou l'application sous-jacente peut atteindre un objectif.

Corrélez les décisions de mise à l'échelle là où la périphérie les voit déjà

HPA et KEDA ne voient que les signaux côté origine ; ni l'un ni l'autre ne dit si une montée en charge a résolu ce qu'un utilisateur a ressenti en périphérie. Une couche d'orchestration managée comme MYO aligne le nombre de réplicas côté origine et le retard de consommateur avec le taux d'erreur et la latence côté périphérie sur la même fenêtre de temps, afin qu'un franchissement de garde-fou de mise à l'échelle se lise comme un seul événement corrélé, et non comme des lectures dispersées à recouper à la main.

S'assurer que le cluster peut fournir les pods

Une décision du HPA n'est utile que si les pods peuvent être planifiés et devenir prêts. Examinez les raisons des pods en attente, la marge des pools de nœuds, le comportement du cluster autoscaler, la distribution des images, les volumes persistants, les règles de topologie et les quotas — un pic peut aussi être bloqué par des PodDisruptionBudgets, des règles d'affinité ou la capacité d'adresses IP. Dans le bac à sable Acme Shop, cela signifie garder assez de marge de nœuds pour absorber à la fois jusqu'à huit réplicas catalog-api et six réplicas order-events, sans que les deux se disputent la même capacité au pire moment.

Mesurez le temps entre la décision et le réplica prêt, en distinguant la planification, la récupération d'image, l'initialisation, la disponibilité et la propagation vers l'équilibreur de charge. Pour catalog-api, ce temps inclut les 45 secondes de démarrage mesurées plus haut. S'il dépasse la hausse de trafic, maintenez une marge, réduisez le travail de démarrage, pré-récupérez ou optimisez les images, ou appliquez une stratégie de façonnage du trafic. Ne vous fiez pas à un test qui commence une fois les pods déjà chauds — et côté file, un test qui démarre avec des consommateurs déjà chauds ne valide pas un démarrage à froid.

Protéger les dépendances et le chemin de livraison

Définissez le comportement de concurrence, de pool de connexions, de retry, de timeout et de coupe-circuit afin que les nouveaux réplicas ne déferlent pas sur une dépendance. Les retries doivent être bornés et les opérations réessayables doivent pouvoir être répétées sans risque. Une tempête de retries peut faire paraître le débit de requêtes comme une réussite de mise à l'échelle alors que la défaillance réelle empire — le même risque, côté file, qui rend l'idempotence des gestionnaires order-events non négociable.

Pour les charges de travail publiques, coordonnez la mise à l'échelle de l'origine avec le chemin de périphérie et d'ingress. Les réponses statiques ou pouvant être mises en cache de manière sûre et les requêtes dynamiques authentifiées ont des profils de demande et des contraintes de correction différents. La limitation de débit, la mise en file d'attente des requêtes, les contrôles d'admission et le délestage peuvent protéger les chemins critiques lors d'un pic, mais chacun exige une décision produit et une réponse observable. Testez les basculements de trafic régionaux et le failover de l'origine avec la conception réelle des données et des sessions.

Valider la boucle complète d'autoscaling Kubernetes

Utilisez une charge de travail représentative incluant le mélange de requêtes, les tailles de payload, l'authentification, l'état du cache et les dépendances externes. Dans le bac à sable Acme Shop, établissez une base de référence puis exécutez une rampe graduelle de trafic catalogue suivie d'une hausse par palier bornée, et testez séparément le backlog order-events depuis zéro jusqu'au seuil d'activation. Observez les recommandations du HPA, les réplicas prêts et en attente, l'attente du pool et le rétablissement après la baisse de charge. Arrêtez le test si les erreurs ou la saturation d'une dépendance franchissent le garde-fou convenu, puis rétablissez uniquement le manifeste précédemment validé via le circuit de changement normal, en laissant la fenêtre de stabilisation et la période de repos se stabiliser avant de retenter. Si les métriques sont périmées, conservez le nombre de réplicas sûr actuel plutôt que d'augmenter maxReplicas, maxReplicaCount ou les limites de dépendance en réflexe d'urgence.

Plusieurs signaux méritent une vigilance particulière. Des réplicas désirés qui augmentent sans que les pods ne sortent de Pending trahissent une contrainte de nœud, de quota, d'affinité ou de volume. Davantage de réplicas qui font grimper les erreurs indiquent que la vraie limite est le pool de base de données ou une tempête de retries : réduisez le plafond approuvé en attendant de corriger le goulot d'étranglement. Un HPA qui oscille signale une métrique bruitée à corriger via l'agrégation et la fenêtre de stabilisation. Un nombre de réplicas qui bouge à peine malgré de réelles variations de charge peut révéler que la tolérance par défaut d'environ 10 % masque une tendance réelle — confirmez-la avant de resserrer la tolérance plutôt que la cible. De nouveaux pods qui n'améliorent pas la latence trahissent souvent la période de grâce d'initialisation du CPU. Un backlog de worker qui continue de croître pointe vers des messages empoisonnés ou des retries non idempotents. Enfin, si KEDA ne dépasse jamais zéro réplica malgré un backlog réel, vérifiez la connectivité du scaler avant de conclure que la demande est absente.

Répétez le test après avoir modifié des images de conteneur, les demandes de ressources, les pipelines de métriques, les types d'instances de nœuds, la configuration d'ingress ou une dépendance majeure. Conservez les résultats et mettez à jour le runbook avec le temps de mise à l'échelle normal, le signal de goulot d'étranglement, le seuil d'escalade et les contrôles manuels.

Références officielles

Mettez à l'échelle avec des garde-fous que la périphérie peut valider

Échangez avec Optimi sur la corrélation des décisions HPA et KEDA avec la Performance, la Sécurité et la Visibilité en périphérie via MYO, pour que l'autoscaling et l'orchestration edge avancent comme un seul système.

Discuter de l'architecture de mise à l'échelle