Mise À L’échelle Automatique Des Nœuds Kubernetes : Absorber Des Pics De Trafic Imprévisibles Sans Intervention Manuelle

Le problème

Une plateforme de données en temps réel faisait face à un trafic imprévisible : résultats d’élections, dernières nouvelles, annonces des marchés provoquaient des pics soudains de millions de requêtes en quelques minutes. L’équipe avait essayé le Horizontal Pod Autoscaler (HPA) pour adapter le nombre de réplicas, sans succès.

Pourquoi ? Le HPA augmentait le nombre de pods, mais le cluster n’avait pas de place pour les accueillir. Les nouveaux pods restaient « Pending » indéfiniment, car les nœuds étaient pleins. Le trafic s’accumulait, les clients subissaient des délais d’attente dépassés. La question n’était pas « combien de pods », mais « combien de nœuds ».

Le défi

Les approches classiques de mise à l’échelle automatique ont toutes échoué :

• Le HPA seul ne suffit pas : il adapte le nombre de pods, mais le cluster n’a pas la capacité
• La mise à l’échelle manuelle des nœuds : elle va à l’encontre de l’esprit de Kubernetes et ne prévoit pas les pics
• Le Vertical Pod Autoscaler : il modifie la taille des requêtes, mais ne résout pas le manque de place
• Le surdimensionnement : acheter des nœuds en plus « au cas où » est coûteux et inutile
• L’imprévisibilité : les pics de trafic sont aléatoires, impossible de prévoir leur arrivée

La solution

Nous avons mis en place Cluster Autoscaler, avec un dimensionnement correct des requêtes de pods :

Phase 1 : dimensionnement des requêtes de pods

• Analyse de l’utilisation réelle des ressources de toutes les charges de travail
• Requêtes CPU et mémoire fixées sur le 95e percentile de l’usage observé (pas sur des suppositions)
• Suppression du surdimensionnement, qui gaspillait 60% de la capacité
• Configuration de pod disruption budgets pour une réduction en toute sécurité

Phase 2 : Cluster Autoscaler

• Déploiement de Cluster Autoscaler pour surveiller les pods en attente
• Ajout automatique de nœuds quand des pods ne peuvent pas être planifiés
• Retrait automatique des nœuds inactifs
• Intégration aux groupes de mise à l’échelle du fournisseur cloud (AWS, GCP, Azure)

Phase 3 : groupes de mise à l’échelle et types d’instances

• Création de pools de nœuds distincts selon le type de charge de travail
• Instances réservées pour la capacité de base (toujours nécessaire)
• Instances Spot pour les charges extensibles (absorbent les pics à moindre coût)
• Flotte mixte pour limiter le risque d’interruption

Phase 4 : supervision et sécurité

• Alerte sur les pods en attente (signe d’une capacité insuffisante)
• Suivi des événements de montée et de descente en charge, et de leur durée
• Test de la bascule en cas d’interruption d’instances Spot
• Documentation du comportement de mise à l’échelle pour l’équipe

Résultats

Gestion du trafic :

• ✅ Les pics de trafic font évoluer le cluster automatiquement (plus de pods en attente)
• ✅ Montée en charge : pods en service 2 à 3 minutes après le début du pic
• ✅ Descente en charge : 10 minutes après la fin du pic (en douceur)
• ✅ Plus aucun délai d’attente dépassé dû à la capacité (auparavant fréquent)

Exploitation :

• ✅ Plus aucune mise à l’échelle manuelle des nœuds
• ✅ Une mise à l’échelle prévisible et traçable
• ✅ Une équipe confiante face au trafic inattendu
• ✅ Une configuration simple (en YAML, sans code sur mesure)

Finances :

• ✅ Coûts réduits par rapport au surdimensionnement manuel
• ✅ Les instances Spot réduisent le coût de base de 60 à 70%
• ✅ Les instances réservées garantissent une base stable
• ✅ Plus de surdimensionnement « au cas où » qui gaspille de l’argent

À retenir

1. Le HPA gère la mise à l’échelle des pods, pas la capacité du cluster : il faut les deux
2. Des requêtes de pods correctes sont la base : sans elles, la mise à l’échelle automatique ne peut pas fonctionner
3. Cluster Autoscaler est simple et efficace : open source, indépendant du cloud, il surveille simplement les pods en attente
4. Les instances Spot sont sûres avec des disruption budgets adaptés et une flotte mixte
5. Les charges imprévisibles se mettent aussi très bien à l’échelle : à condition que le système réagisse à la demande réelle (pods en attente) et non à une demande prévue