Le problème de la mise à l’échelle automatique des charges GPU ne vient peut-être pas de l’incapacité de Kubernetes à prendre une décision, mais du fait que cette décision arrive trop tard. Ramkumar Nagaraj et Bingi Narasimha Karthik, d’Adobe, décrivent un incident au cours duquel un service de production critique a subi une vague de demandes qui a fait grimper le taux d’erreur côté utilisateurs à 15–20 %, bien que le Horizontal Pod Autoscaler ait commencé la mise à l’échelle. La raison : des centaines de conteneurs sont restés en attente, tandis que les nouveaux nœuds GPU ont mis beaucoup de temps à devenir opérationnels.
Dans la chronologie documentée par les auteurs, la vague de demandes est arrivée à 06:00, les indicateurs du HPA ont dépassé le seuil à 06:05, puis la planification des conteneurs a commencé à 06:15. Toutefois, les premiers nœuds GPU n’ont achevé leur préparation qu’à 06:45, soit après la fin du pic. La préparation des nœuds GPU prend généralement trois à cinq fois plus de temps que celle des services reposant sur des CPU, en raison du chargement du firmware, de la configuration des pilotes et de la préparation de CUDA.
Passer de la réaction à la demande à l’anticipation
L’équipe a proposé d’exécuter un contrôleur au sein de Kubernetes toutes les 60 secondes. Celui-ci lit une heure de métriques historiques et prédit la demande à dix minutes. L’objectif n’est pas une prédiction parfaite, mais le lancement de la préparation de la capacité suffisamment tôt avant l’arrivée de la vague pour que les nœuds et les conteneurs soient prêts au moment voulu.
La conception s’est appuyée sur les données collectées par Prometheus, notamment l’utilisation du CPU et de la mémoire, la latence, le débit des requêtes et l’utilisation du GPU. L’équipe a testé les modèles ARIMA, le lissage exponentiel, la bibliothèque Prophet et LSTM, avant de choisir un modèle Bi-LSTM composé de deux couches de 64 puis 32 unités. Selon l’article, ce choix répondait à des profils de données comprenant des pics courts, des périodes de récupération et des valeurs constantes aberrantes, et non au fait qu’il s’agirait théoriquement de la meilleure option dans tous les cas.
Le modèle est réentraîné chaque semaine, tandis que le modèle déployé fonctionne uniquement en mode inférence au sein d’un binaire du contrôleur écrit en Go, à l’aide de TensorFlow Lite. La conception ne nécessite ainsi ni plateforme externe d’apprentissage automatique ni couche de service des modèles.
Trois couches pour réguler la mise à l’échelle
La conception repose sur trois fonctions interdépendantes : la prédiction, la préparation et l’absorption. Le modèle prédit la demande, puis le contrôleur commence à augmenter progressivement le nombre de réplicas, tandis que la capacité préparée à l’avance fournit une marge pour absorber la vague réelle.
Comme la prédiction ne peut pas gérer toutes les surprises, l’équipe a ajouté un détecteur de pics soudains fonctionnant en parallèle. Ce composant compare la demande réelle aux prévisions au moyen d’un seuil adaptatif fondé sur l’écart type mobile. Si la demande dépasse la prévision d’une différence atteignant le niveau de confiance défini, le détecteur accélère la mise à l’échelle. Les auteurs décrivent ce composant comme un filet de sécurité heuristique, et non comme un second modèle prédictif.
Le dispositif de mise à l’échelle progressive limite l’augmentation à 20 conteneurs par minute. L’objectif est d’éviter une vague massive de planification qui exercerait une pression sur le planificateur et etcd, et provoquerait une concurrence entre les opérations de téléchargement des images, de démarrage des conteneurs, d’initialisation des conteneurs et d’injection des sidecars. L’utilisation cible a également été fixée à 70 % plutôt qu’à 100 %, afin de conserver une marge permettant d’absorber les pics et de tolérer les imprécisions occasionnelles du modèle sans que l’erreur ne se transforme en cascade de défaillances.
Qu’ont démontré les tests ?
L’équipe a d’abord exécuté le système en mode fantôme, de sorte que les prévisions soient enregistrées sans déclencher de mise à l’échelle réelle, et a recueilli plus de 500 heures de données. Les résultats ont montré une précision de 85 % lorsque la prévision de la demande à dix minutes se situait dans une marge de ±10 % par rapport à la demande réelle. Le détecteur de pics a également identifié neuf vagues sur dix, avec deux fausses alertes, tandis que les tests du dispositif de mise à l’échelle progressive n’ont révélé ni défaillance en cascade ni oscillation de la mise à l’échelle.
Le système a également fonctionné aux côtés de HPA v2 sans conflit. Au cours d’une semaine de validation dans un environnement de développement contrôlé, il a réussi 23 tests sur 23. Lors d’une simulation des profils de pics à l’origine de l’incident initial, le système a détecté la vague environ 11 minutes à l’avance.
Quand cette approche est-elle pertinente ?
La valeur de la mise à l’échelle prédictive apparaît lorsque la préparation des nœuds prend plus de deux ou trois minutes et que la demande est partiellement prévisible, par exemple selon des profils quotidiens ou hebdomadaires, ou lors d’événements connus. Elle nécessite également de bonnes données de supervision, avec au moins une semaine de métriques Prometheus. En revanche, l’approche devient moins pertinente si les nœuds sont préparés en 30 secondes, si la demande est totalement aléatoire ou si la priorité de l’équipe est avant tout de réduire les coûts ; conserver des nœuds prêts implique de payer le coût d’une capacité de réserve.
Lecture éditoriale : le changement pratique ne consiste pas ici à remplacer HPA, mais à ajouter un horizon de prédiction à un système qui traite habituellement la demande après son apparition. Son importance est particulièrement manifeste pour les charges GPU, où la rapidité de la décision de mise à l’échelle ne suffit pas si l’infrastructure a besoin de dizaines de minutes avant de démarrer les conteneurs. Toutefois, les éléments présentés proviennent encore d’une validation contrôlée, et non d’une mesure indépendante à grande échelle menée dans plusieurs environnements de production.
L’expérience de l’équipe elle-même fait ressortir d’importantes limites : un modèle ARIMA correctement réglé pourrait obtenir un résultat proche avec une architecture plus simple, et le modèle peut devenir obsolète en quelques jours lorsque les profils de demande changent. Il est également resté difficile d’expliquer pourquoi un certain nombre de réplicas était prédit, et les questions relatives au volume optimal de données, à la fréquence du réentraînement et à la capacité du détecteur de pics heuristique à identifier des événements sans précédent n’ont pas encore été tranchées.
L’article recommande donc de commencer par recueillir une semaine de métriques, d’entraîner un modèle simple, de l’exécuter en mode fantôme, puis de mesurer sa précision avant d’activer la mise à l’échelle. Lors du passage en production, il convient d’imposer une limite maximale au nombre de réplicas, de prévoir une procédure claire de désactivation et, de préférence, de passer par une phase de mise à l’échelle limitée avant d’ouvrir complètement le dispositif. La conclusion répétée par les auteurs est pragmatique : la complexité du modèle n’est pas une qualité en soi et, si la solution la plus simple fonctionne, il vaut mieux l’exploiter.