Le problème commence par un paradoxe opérationnel évident : les données d’utilisation des GPU dans l’environnement d’Adobe étaient collectées chaque seconde dans un Prometheus centralisé, mais les équipes qui supportaient le coût de ces unités ne pouvaient pas consulter directement leurs métriques. Selon les ingénieurs Bingi Narasimha Karthik et Ramkumar Nagaraj, cela a conduit à découvrir une unité GPU restée à 0 % d’utilisation pendant 11 jours, alors qu’elle était allouée et en fonctionnement, mais invisible pour l’équipe qui en était responsable.
L’article publié sur le blog de la CNCF le 9 septembre 2026 ne présente pas un nouveau produit commercial, mais explique un modèle pratique pour construire un accès autonome et sécurisé aux métriques dans des clusters Kubernetes multitenants. L’idée centrale consiste à placer une couche intermédiaire consciente des locataires devant le Prometheus centralisé, puis à accorder à chaque équipe une partie sélectionnée de ses données, avec la possibilité de les copier vers son propre Prometheus.
Pourquoi ne suffit-il pas d’ouvrir le Prometheus centralisé ?
Les auteurs estiment que l’octroi aux équipes de droits de lecture sur le point d’interrogation Prometheus centralisé se heurte à deux problèmes. Le premier est lié à la sécurité : le point d’interrogation Prometheus ne connaît pas les espaces de noms ; toute personne capable d’exécuter une requête PromQL pourrait théoriquement demander les données d’autres équipes, comme les taux de requêtes ou les plans de capacité.
Le second problème concerne les performances. Le stockage central sert les métriques de l’ensemble du parc, et des requêtes longues ou mal maîtrisées provenant de centaines d’ingénieurs pourraient consommer les ressources et augmenter le temps de réponse pour tout le monde. Ainsi, ouvrir le stockage partagé ne résout pas le problème de visibilité : cela peut au contraire ajouter à l’architecture un risque de fuite de données et un problème de voisin bruyant.
Une couche intermédiaire aux trois responsabilités
La conception propose une couche légère devant Prometheus, chargée de trois fonctions interdépendantes :
- Identification : authentifier l’auteur de la demande et déterminer le locataire auquel il appartient.
- Isolation : limiter chaque requête à l’espace de noms du locataire, en imposant cette restriction avant que la requête n’atteigne Prometheus afin qu’elle ne puisse pas être contournée via PromQL.
- Distribution : copier périodiquement un ensemble sélectionné de métriques du locataire vers son propre Prometheus lorsque cela est nécessaire.
Le chemin de lecture utilise Nginx pour équilibrer la charge, puis kube-rbac-proxy pour l’authentification et l’autorisation. Les requêtes parviennent ensuite au proxy, qui découvre les serveurs Prometheus via l’API Kubernetes et rassemble les résultats provenant des serveurs opérationnels. Le chemin d’écriture utilise quant à lui remote write pour envoyer les métriques sélectionnées vers le Prometheus du locataire. Dans les environnements à haute disponibilité, les données sont envoyées à tous les réplicas via les noms DNS des Pods.
L’isolation commence par l’identité et s’achève au niveau des données
kube-rbac-proxy s’appuie sur l’identité Kubernetes et RBAC pour déterminer l’auteur de la demande, puis transmet l’identité du locataire sous la forme d’une assertion concernant l’espace de noms. prom-label-proxy applique l’isolation au moment de l’interrogation en réécrivant la requête afin d’y ajouter un sélecteur d’espace de noms avant de l’envoyer à Prometheus. Ainsi, l’isolation ne constitue pas seulement une politique recommandée à l’utilisateur : elle devient une contrainte appliquée à chaque requête.
La source mentionne également des mesures de renforcement du proxy lui-même, notamment son exécution en tant qu’utilisateur non root avec l’identifiant UID 65534, l’utilisation d’un système de fichiers racine en lecture seule, la suppression de toutes les capacités supplémentaires, l’interdiction de l’élévation de privilèges et l’attribution d’un compte de service doté du moins de privilèges possible.
Qu’est-ce qui change concrètement en matière de coût et de performances ?
L’isolation ne se limite pas à empêcher la consultation des données d’autrui. Le paramètre metricIsolation permet d’appliquer le filtre d’espace de noms dès la phase de collecte des métriques, de sorte que le Prometheus du locataire ne stocke que les séries qui le concernent. D’après l’expérience des auteurs, le nombre de séries stockées pour un locataire typique peut diminuer d’environ 97 %, passant de plus de 10 000 séries à quelques centaines.
Cette réduction signifie un stockage plus petit, des requêtes plus rapides et des coûts de stockage moindres. Elle réduit également le risque de fuite de données, puisque les métriques inutiles n’atteignent tout simplement pas le stockage privé. La conception diminue aussi la pression exercée sur le Prometheus centralisé, les tableaux de bord et les alertes quotidiennes étant déplacés vers les stockages des locataires plutôt que de dépendre en permanence du stockage partagé.
L’exploitation autonome nécessite des limites claires
L’équipe définit une ressource personnalisée Kubernetes appelée MetricAccess, qui précise l’espace de noms, les métriques demandées, la destination remote write et la période de collecte. Les locataires peuvent choisir des noms de métriques précis, des expressions régulières ou des sélecteurs PromQL. Le Prometheus cible doit activer la réception remote write via web.enable-remote-write-receiver, tandis que le reste de l’architecture repose sur les composants habituels de Prometheus et Kubernetes.
L’article présente six types de requêtes utiles, notamment la moyenne d’utilisation du GPU par espace de noms, le décompte des unités dont l’utilisation est inférieure à 5 % pendant une heure, le pourcentage de mémoire utilisée, la consommation d’énergie, la détection d’unités occupées sans trafic de requêtes ou la présence de requêtes alors que des unités GPU restent inactives. L’exemple s’appuie sur des métriques de type DCGM, avec un avertissement concernant la nécessité d’adapter les noms à l’exporteur effectivement utilisé.
L’expérience confirme que l’exploitation autonome ne signifie pas la suppression des garde-fous. Les ensembles sélectionnés de métriques et les différentes périodes de collecte fonctionnent comme des quotas qui limitent la charge. De même, l’option remote write devrait être réservée aux équipes qui disposent réellement de tableaux de bord et d’alertes, tandis qu’un accès limité au moment de l’interrogation peut suffire aux petites équipes.
Lecture de certi.news
Le changement important n’est pas l’ajout d’un nouvel outil de supervision, mais le transfert du contrôle de la visibilité de la seule équipe plateforme vers le locataire, tout en maintenant l’isolation sous le contrôle de l’infrastructure. Cela traite simultanément un problème de sécurité, un problème de coût et un problème de performances. La solution n’est toutefois pas automatique : le choix des métriques, le réglage de la cardinalité, la gestion des nouvelles tentatives, l’écriture vers les réplicas en haute disponibilité et le verrouillage des versions des exporteurs constituent tous des responsabilités opérationnelles continues.
Les résultats chiffrés présentés, notamment la réduction d’environ 97 % du nombre de séries, concernent l’expérience des auteurs et un « locataire typique » ; ils ne constituent pas une garantie générale pour tous les clusters. Il convient donc de tester ce modèle avec les noms de métriques, le volume de séries et les périodes de collecte propres à chaque environnement avant de l’adopter à grande échelle. Le projet est disponible sous licence Apache 2.0, et l’article contient un lien vers le dépôt GitHub prometheus-multi-tenant-proxy.