Black Friday : le HPA passe de quatre à vingt pods API — graphique vert, équipe sereine. Pourtant le checkout timeout : PostgreSQL atteint max_connections, Redis single-thread saturé. Les nouveaux pods multiplient les connexions sans augmenter la capacité transactionnelle. Autoscaling « réussi » côté Kubernetes, échec côté métier.
Scaler des pods résout les goulots sans état. Il aggrave souvent les goulots avec état ou partagés si personne n'a cartographié la chaîne complète. Avant d'automatiser quoi que ce soit, identifiez quelle ressource casse en premier sous pic — base, broker, API tierce, bande passante sortante — et qui est habilité à la dimensionner.
HPA : la métrique par défaut et ses angles morts
Le Horizontal Pod Autoscaler compare une métrique (CPU, mémoire, métrique personnalisée) à une cible et modifie le nombre de réplicas. Sur le papier, c'est simple. En production, le CPU n'est qu'un proxy imparfait de la charge réelle.
| Métrique | Bon signal quand | Mauvais signal quand |
|---|---|---|
| CPU % | Calcul intensif (rendu, chiffrement) | Attente disque ou base de données |
| Mémoire | Cache dans le pod | Fuite masquée par le scale |
| Requêtes/s ou latence (custom) | API sans état | Saturation en amont |
| Profondeur de file (KEDA) | Workers asynchrones | File sans consommateurs sains |
Sans metrics-server et un adaptateur Prometheus (ou équivalent), le HPA reste aveugle au métier. Un pod peut afficher vingt pour cent de CPU tout en attendant une réponse PostgreSQL bloquée depuis huit secondes. La métrique monte trop tard — ou pas du tout.
Ajouter des pods sur une base à cent pour cent de connexions utilisées ne crée que plus de clients en attente.
Pour sortir du CPU par défaut, exposez des signaux qui reflètent l'expérience utilisateur : latence au 95e centile sur /api/checkout, longueur de file Redis, nombre de messages en retard sur RabbitMQ. Le HPA ne devient utile que lorsque la métrique choisie corrèle aux timeouts observés en charge.
VPA et redimensionnement avant de multiplier
Le Vertical Pod Autoscaler recommande ou applique les requests et limits CPU-mémoire. Des requests trop basses provoquent du throttling CPU et poussent le HPA à scaler inutilement. Des requests trop hautes remplissent les nœuds : les nouveaux pods restent Pending, le cluster autoscaler s'active en urgence, et la facture suit.
Workflow pragmatique : stabilisez d'abord les requests (VPA en mode « Off » pour collecter des recommandations), puis activez le HPA sur les réplicas. Sur un cluster managé européen, surveillez le coût par nœud : un cluster autoscaler sans alerte budgétaire transforme un pic de trafic en surprise en fin de mois.
Cluster autoscaler et pods Pending
Quand le HPA crée des pods sans place sur les nœuds existants, ils restent Pending. Le cluster autoscaler provisionne un nœud — avec un délai de plusieurs minutes (téléchargement d'image, démarrage, enregistrement). Pendant ce laps, le trafic continue d'arriver sur les pods existants, déjà saturés.
Anticipez avec un PodDisruptionBudget pour ne pas vider un déploiement critique pendant un scale-down de nœud. Prévoyez plusieurs pools de nœuds (généraliste versus calcul intensif) si vos charges sont hétérogènes. Fixez une limite maximale de nœuds pour éviter une facture incontrôlée lors d'une boucle de scale mal configurée.
KEDA pour workers et files
Workers Symfony Messenger, files Laravel, consommateurs Kafka : le bon signal est le retard ou la profondeur de file, pas un CPU à quinze pour cent pendant que des milliers de messages attendent. KEDA peut scaler depuis zéro — pratique pour des charges batch, mais attention au démarrage à froid incompatible avec un engagement de disponibilité temps réel.
Documentez la topologie des exchanges et des files avant d'automatiser. Un scaler mal câblé sur la mauvaise queue scale les workers pendant que la file critique grossit ailleurs.
Services avec état : ne pas autoscaler aveuglément
PostgreSQL, Elasticsearch, certains déploiements Redis : le scale horizontal n'est pas trivial. Parfois la réponse est un nœud plus grand (redimensionnement de machine virtuelle), une réplica en lecture, ou un cache en amont — pas davantage de pods API qui multiplient les connexions.
Cartographiez la chaîne : pour mille requêtes supplémentaires par seconde, quelle ressource casse en premier ? Mesurez en test de charge avant d'automatiser le mauvais levier. L'autoscaling Kubernetes ne remplace pas une architecture de données réfléchie.
Le sommet : le graphique qui rassure faussement
La bonne question n'est pas « combien de pods ? » mais « quelle ressource part en premier sous pic — et qui la scale ? »
Décider et avancer sans angle mort
Commencez par un test de charge avec des métriques par couche : application, base, broker, réseau. Choisissez le scaler adapté (HPA, KEDA, cluster autoscaler) sur le signal qui corrèle aux timeouts utilisateur, pas sur la métrique la plus facile à grapher. Fixez un maximum de réplicas, des budgets de perturbation et des alertes sur la latence au 95e centile.
Comparez les clusters managés et les pools de nœuds via l'annuaire et le comparateur. Les guides complètent le cadrage architecture cloud. Validez en charge : si la latence au 95e centile reste stable quand les réplicas montent, le goulot est ailleurs — et c'est là qu'il faut investir.
Questions fréquentes
HPA sur CPU suffit-il en production ?
Rarement seul. Un CPU stable peut masquer une file Redis qui grossit ou une base à connexions épuisées. Combinez métriques applicatives (retard de file, requêtes par seconde, latence au 95e centile) via l'adaptateur Prometheus ou KEDA pour scaler sur ce qui corrèle aux timeouts utilisateur.
Quelle différence entre HPA, VPA et cluster autoscaler ?
Le HPA ajuste le nombre de réplicas de pods selon une métrique cible. Le VPA recommande ou applique les requests et limits CPU-mémoire. Le cluster autoscaler ajoute des nœuds quand des pods restent Pending faute de ressources sur le cluster existant.
KEDA apporte quoi par rapport au HPA classique ?
KEDA propose des scalers basés sur la profondeur de files, des déclencheurs cron et des métriques externes. Pour des workers asynchrones, ces signaux sont souvent plus expressifs qu'un CPU moyen bas pendant que des milliers de messages attendent.
Comment éviter le flapping ?
Configurez stabilizationWindowSeconds, des seuils avec hysteresis, un délai de refroidissement entre deux événements de scale, et un minimum de réplicas réaliste. Sans ces garde-fous, le HPA oscille et déstabilise les connexions persistantes.
Autoscaling mature scale la ressource qui fait échouer l'utilisateur — pas celle qui est déjà dans Grafana.