Des Pics De Trafic Sans Pods en Attente : Comment Kubernetes S'adapte Seul

Un cluster serein pendant un pic de trafic est un choix de conception, pas de la chance. Le principe est simple : les pods se multiplient selon la demande, et le cluster ajoute en quelques minutes les nœuds dont ils ont besoin. Ce guide vous donne un auto-test de deux minutes et les quatre étapes que nous utilisons. Il s’appuie sur un vrai projet avec une plateforme de données en temps réel dont le trafic bondit de plusieurs millions de requêtes en quelques minutes.

Auto-test de deux minutes

Répondez honnêtement :

1. Quand le trafic double, les nouveaux pods trouvent-ils un nœud, ou restent-ils en Pending ?
2. Les requests des pods reposent-elles sur l’usage mesuré, par exemple le 95e percentile, ou sur une estimation ?
3. Le cluster ajoute-t-il des nœuds seul, et combien de temps avant que les nouveaux pods tournent ?
4. Recevez-vous une alerte quand des pods restent en Pending ?
5. Quelle part de votre capacité peut tourner sur des instances spot en cas d’interruption ?

Si vous pouvez répondre à quatre questions ou plus, vous êtes bien placé. Chaque réponse manquante est un endroit où un pic peut encore vous surprendre.

Le principe qui fonctionne

Multiplier les pods n’est que la moitié de l’autoscaling. Si les nœuds sont pleins, les nouveaux pods attendent et le trafic s’accumule. Le cluster doit réagir à ce qui est réellement en attente, pas à une prévision.

Le plan en quatre étapes

1. Ajuster les requests. Fixez les requests CPU et mémoire selon l’usage observé, au 95e percentile. Dans le projet, cela a supprimé un surdimensionnement qui occupait environ 60 % de la capacité, et l’autoscaler dispose d’une image fidèle.
2. Ajouter le Cluster Autoscaler. Il surveille les pods en attente, ajoute des nœuds quand ils ne peuvent pas être placés et retire les nœuds inutilisés. Des Pod Disruption Budgets gardent la réduction progressive.
3. Mélanger les pools de nœuds. Capacité réservée pour la charge de base stable, instances spot pour les pics, réparties sur plusieurs types d’instances pour limiter le risque d’interruption.
4. Surveiller et s’entraîner. Alerte sur les pods en attente, suivi des délais de montée et de descente en charge, et test d’une interruption de nœud spot.

Ce que cela a donné en pratique

Après le changement, les pods tournaient 2 à 3 minutes après le début d’un pic, et le cluster redescendait environ 10 minutes après sa fin. Les requêtes n’expirent plus faute de capacité, personne ne dimensionne les nœuds à la main et la configuration est du simple YAML. Détails : l’étude de cas.

Prochaine étape

Faites l’auto-test aujourd’hui. S’il révèle des lacunes, réservez un appel et nous regardons votre cluster ensemble.