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

Publié le

14 juil. 2026

Temps de lecture

11 min de lecture

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 d'API 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é.

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é.

É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. 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 des requêtes, tandis qu'une limite de mémoire peut provoquer des redémarrages si elle est inférieure aux pics normaux. 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. Utilisez un nombre minimal de réplicas qui prend en charge la disponibilité et le comportement de démarrage à froid dont vous avez besoin, et un maximum qui reflète à la fois l'approvisionnement du cluster et la sécurité en aval. Le maximum est un garde-fou, pas une promesse de performance.

Utilisez le comportement de montée et de descente en charge pour éviter les oscillations. Une montée suffisamment rapide peut être nécessaire face aux pics, mais des changements illimités peuvent submerger une base de données ou une API tierce. Une descente prudente réduit le churn et les tempêtes de connexions après un pic temporaire. Validez le comportement lors de 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.

Utiliser KEDA lorsque la mise à l'échelle pilotée par les événements convient

KEDA ajoute une mise à l'échelle pilotée par les événements via des ScaledObjects et des scalers pour des systèmes tels que les files d'attente, les streams et les services externes. Il peut mieux convenir aux workers qui doivent réagir à un backlog ou à une source d'événements, y compris dans les cas de scale-to-zero où le délai de démarrage et de premier message est acceptable.

Choisissez les seuils de déclenchement à partir d'un objectif de traitement. Pour une file d'attente, reliez le backlog, le taux d'arrivée, le débit par worker et le délai d'attente acceptable. Testez ensuite les conditions de défaillance : métriques retardées, messages empoisonnés, partitions inégales, broker indisponible, échecs d'authentification et dépendance en aval qui ne peut pas absorber davantage de consommateurs. Augmenter le nombre de consommateurs peut multiplier les travaux dupliqués ou les appels externes, sauf si les handlers sont idempotents et la concurrence bornée.

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.

S'assurer que le cluster peut fournir les pods

Une décision 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 ou du provisionnement de nœuds, la distribution des images, les contraintes de volumes persistants, les règles de topologie et les quotas. Un pic peut également être bloqué par des PodDisruptionBudgets, des règles d'affinité, la capacité d'adresses IP ou une limite de namespace.

Mesurez le temps entre la décision de mise à l'échelle 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. Ce temps est central pour absorber les pics. S'il est plus long que la hausse de trafic, maintenez une marge, réduisez le travail de démarrage, pré-récupérez ou optimisez les images lorsque cela convient, ou utilisez une stratégie de façonnage du trafic. Ne vous fiez pas à un test de charge qui commence une fois les pods déjà chauds.

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.

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 par des tests progressifs

Utilisez une charge de travail représentative incluant le mélange de requêtes, les tailles de payload, l'authentification, l'état du cache le cas échéant, les appels de base de données et les dépendances externes. Exécutez des rampes graduelles et des changements par paliers. Observez les indicateurs de service, les recommandations HPA, les réplicas prêts, les pods en attente, l'augmentation du nombre de nœuds, la saturation des dépendances et le rétablissement après la baisse de charge.

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

• Kubernetes: Horizontal Pod Autoscaling
• Kubernetes: Pod Resource Requests and Limits
• Kubernetes: Cluster Autoscaler
• KEDA Documentation