"Maintenant", ce n'est pas qu'un adverbe à la con pour apprécier l'instant présent ou faire péter ses ordres comme votre Belle Mère !
C'est également un conteneur à lancer,
qui se connecte en lecture seule à un socket Docker pour réaliser en un battement de cil, tout l'inventaire de votre home lab !
Il relève ainsi l'état de chaque conteneur, ses healthchecks, ses boucles de redémarrage, ses logs, et vos projets Compose regroupés comme vous les avez écrits.
Ensuite, tout ce qui vous alerte pour de bon se déclare à la main. Les checks HTTP et TCP se configurent sous la forme de labels sur les conteneurs à surveiller. Par exemple, un maintenant.endpoint.http avec son intervalle et son seuil d'échec, un maintenant.endpoint.tcp pour la base...etc. Pas besoin donc d'aller mettre votre gros nez dans un fichier de config spécifique.
Vos tâches planifiées reçoivent chacune une URL à appeler quand elles finissent comme ça si la sauvegarde de trois heures du matin ne se manifeste pas, vous êtes prévenu. Vos certificats HTTPS sont surveillés et signalés cinq fois avant leur expiration, un mois avant puis de plus en plus près. Il compare aussi l'empreinte de vos images à celle publiée sur le registre, ce qui vous permet ensuite de savoir lesquelles ont pris du retard sans lancer des docker pull à l'aveugle. Ah et il sert une page de statut publique pour vos utilisateurs.
Le tout tient dans un binaire Go qui occupe environ 17 Mo de RAM et qui se repose sur une simple base SQLite.
Par contre, l'édition gratuite (Community) gère une seule machine. Si vous voulez du multi-hôte, il faudra passer par la case payante. Toujours en gratuit, il y a aussi des plafonds... Vous avez le droit uniquement à 10 endpoints, 5 heartbeats, 5 certificats, 3 composants de page de statut et uniquement 7 jours d'historique.
Attention quand même, y'a 2 choses à savoir avant de vous enflammer et de poser ça sur une machine exposée sur le net. Il n'y a aucune authentification intégrée, et de ce que j'ai compris, c'est assumé ! A vous donc de mettre en place un reverse proxy et un Authelia ou un Authentik devant.
Pour situer "Maintenant" par rapport à d'autres solutions que je vous ai déjà présentées,
Beszel
fait les métriques par conteneur sans aucun plafond gratos, mais pas les checks HTTP.
Uptime Kuma
lui, fait les checks, mais ses monitors doivent être créés un par un dans l'interface, sauf à lui greffer
AutoKuma
pour lire les labels. Donc, il n'y a pas vraiment de solution tout-en-un gratuite...
Pour la troisième année consécutive, CAST AI publie son State of Kubernetes Optimization Report, qui mesure l’utilisation réelle des ressources CPU, mémoire et, nouveauté 2026, GPU dans les clusters Kubernetes.
Les données sont issues de mesures directes réalisées sur des dizaines de milliers de clusters de production tournant sur AWS, GCP et Azure ; avant toute optimisation.
Le verdict est sans appel : l’utilisation CPU est tombée à 8%, contre 10% l’année précédente. Celle de la mémoire est passée de 23% à 20%. Contrairement à ce que l’on pourrait attendre d’une technologie arrivant à maturité, les taux d’utilisation ne progressent pas mais ils régressent.
Au cœur du problème : le surprovisioning. Le taux de surprovisioning CPU a bondi de 40% à 69% en un an. Côté mémoire, il atteint 79%. Les entreprises paient donc pour des ressources que leurs applications ne demandent même pas.
Un surprovisioning devenu structurel
Le mécanisme est bien connu des équipes DevOps : pour éviter les ralentissements ou les crashs par manque de mémoire (OOM evictions), les développeurs ajoutent des marges de sécurité généreuses à leurs requêtes de ressources.
Ce padding, invisible pour les équipes en charge des coûts, n’est jamais réexaminé après le déploiement. Les charts Helm appliquent des estimations conservatrices à l’ensemble des services, et les autoscalers de cluster répondent à ces demandes gonflées comme s’il s’agissait d’une charge réelle, en provisionnant des nœuds en conséquence. Le gaspillage devient structurel.
Ce qui est contre-intuitif, c’est que cette surcapacité ne garantit pas la stabilité. Un cluster analysé par CAST AI affichait en moyenne 40 à 50 OOM kills par intervalle de mesure, malgré un padding généreux des ressources. Après déploiement d’un rightsizing automatisé, qui a également réduit les CPU provisionnés de moitié, les OOM kills sont tombés à presque zéro.
Autre constat surprenant de l’édition 2026 : la taille des clusters n’a aucune influence sur le taux d’utilisation. Les petits comme les grands clusters gaspillent environ 70% de leur CPU et mémoire alloués.
Il existe toutefois des nuances selon les fournisseurs cloud : les clusters AWS tendent à gaspiller légèrement moins (environ 66%), ceux sur Azure davantage (environ 72%), GCP se situant entre les deux. Mais même le meilleur résultat ( 66% de gaspillage) reste très élevé.
Les GPU : un problème d’une autre dimension
L’ajout des GPU dans le périmètre du rapport 2026 révèle une situation encore plus alarmante. L’utilisation moyenne des GPU s’établit à 5% sur les 23 000 clusters analysés, soit environ 20 fois moins que la capacité allouée.
Or l’économie des GPU est fondamentalement différente de celle du CPU. Un cœur CPU inactif coûte quelques centimes par heure. Un GPU inactif, lui, coûte des dollars. Et pour la première fois depuis le lancement d’EC2 en 2006, les prix des GPU augmentent. AWS a relevé les prix de ses Capacity Blocks H200 de 15% en janvier 2026, rompant une tendance de deux décennies à la baisse.
Le rapport pointe également un comportement de rétention : les entreprises s’accrochent aux capacités GPU de peur de ne plus pouvoir en obtenir, alimentant une boucle inflationniste. L’adoption des instances Spot pour les charges GPU était quasiment inexistante en 2025, avec moins de 2% des GPU fonctionnant en Spot, partiellement faute de disponibilité.
La situation évolue toutefois depuis début 2026 pour le matériel d’entrée de gamme : les instances T4 dans certaines régions américaines affichent désormais des taux de survie supérieurs à 90% sur une fenêtre de 30 minutes. Mais les disparités régionales sont considérables : pour AWS, eu-west-3 maintient une probabilité de survie supérieure à 0,9 sur 24 heures, tandis que eu-central-1 et us-east-1 tombent sous 0,2 dans la même fenêtre ; soit un risque d’interruption de 80% en une journée.
En sélectionnant la région la plus favorable à un moment donné, les équipes pourraient obtenir des différences de coût de 2 à 5 fois sur le seul prix Spot. Impossible à monitorer manuellement en temps réel.
Le partage GPU : théoriquement connu, pratiquement ignoré
Le rapport illustre le potentiel du GPU sharing avec un cas concret. ALLEN Digital exploitait 7 modèles sur SageMaker ( 3 Open Source et 4 Custom ) avec des instances GPU fonctionnant en continu mais servant une charge intermittente.
En migrant vers Kubernetes avec du GPU time-slicing activé, un mix 50/50 on-demand/Spot et du bin-packing de nœuds, l’entreprise a réalisé 20% d’économies immédiatement grâce au time-slicing, 30 à 40% supplémentaires en consolidant les modèles sur des instances partagées, et plus de 70% d’économies totales par rapport à SageMaker après rightsizing CPU et mémoire.
Un cluster dans le jeu de données du rapport ( 136 H200 maintenant 49% d’utilisation GPU) montre que le plafond n’est pas théorique. La moyenne du parc est à 5%. L’écart est de 10x, et il est presque entièrement une question de méthode, non de matériel.
Au-delà des GPU, le rapport note une tendance de fond sur l’architecture des processeurs. Depuis le deuxième trimestre 2024, l’adoption des processeurs ARM progresse à 3,5 fois le rythme des processeurs x86. Les processeurs ARM représentent désormais 9% du parc CPU total.
L’automatisation, seule réponse viable ?
Face à ces chiffres, CASTAI formule un diagnostic net : les inefficacités décrites dans le rapport ne sont pas nouvelles. Elles s’accumulent d’année en année. La tendance est constante : l’adoption de Kubernetes progresse, l’efficacité décline proportionnellement, et l’écart entre ce que les organisations paient et ce qu’elles consomment ne cesse de s’élargir. Cette trajectoire ne se corrige pas d’elle-même.
La conclusion des auteurs est sans équivoque : les équipes qui ont réduit cet écart n’ont pas attendu une amélioration spontanée. Elles ont traité l’efficacité comme une propriété opérationnelle continue, au même titre que la disponibilité, plutôt que comme un projet ponctuel.
Chez SNCF, plutôt que de souveraineté, on préfère parler d’autonomie stratégique : ce terme dénote davantage une dynamique d’action… et il est moins « royaliste ».
Thomas Comtet a apporté cette précision terminologique la semaine dernière lors d’une « keynote express » à la KubeCon Europe. En toile de fond, un projet auquel il participe en tant que responsable de service conteneurisation/cloud native… et qui a valu à son entreprise un Community Award CNCF. En l’occurrence, le « prix du meilleur utilisateur final » (Top End User).
OpenStack, Talos Linux et Cluster API
Kubernetes sous-tend aujourd’hui environ 30 % des applications de la SNCF, 25 % étant en VM / bare metal et 45 % en services managés.
Ce portefeuille fonctionne à majorité (70 %) sur Azure et AWS, vers lesquels une migration avait démarré en 2018.
Pour atteindre la fameuse « autonomie stratégique », SNCF a cherché à répliquer dans son datacenter l’expérience du cloud public. Les premiers clusters on-prem, créés en 2020, étaient certes fonctionnels, mais impliquaient des processus manuels et des outils custom. En livrer un pouvait prendre jusqu’à 1 mois, en plus de difficultés permanentes de maintenance et du manque de fonctionnalités essentielles comme la mise à l’échelle automatique des pods.
En 2023, le groupe ferroviaire est reparti de zéro, à l’appui d’une pile cloud native : OpenStack, Talos Linux, Cilium, Kyverno… et Cluster API. Cette dernière fut la pièce maîtresse de l’édifice. En plus d’éliminer les dérives de configuration, elle a permis d’activer l’autoscaling des nœuds, via son provider OpenStack.
L’implémentation GitOps effectuée dans le cloud public – à base d’Argo CD – a été reproduite sur site. ORAS a été intégré pour gérer les providers de la Cluster API en tant qu’artefacts OCI. Il est désormais possible de provisionner un cluster en 30 minutes, selon la SNCF, qui met aussi en avant la maintenance automatisée (mise à jour mensuelle). Elle entend développer des jonctions plus profondes avec les écosystèmes CNCF et Open Infra, tout en intégrant KCP et Crossplane pour simplifier la consommation de l’infrastructure.
Les requêtes d’inférence peuvent consommer bien plus de ressources que les requêtes API « traditionnelles ». Leur routage est donc d’autant plus critique et doit reposer sur des stratégies adaptées (buffers, streaming, timeouts…).
Partant de ce postulat, le projet Istio avait introduit, à l’été 2025, une extension spécifique pour la Gateway API de Kubernetes. Elle apporte des CRD InferenceModel et InferencePool. La première permet de définir des endpoints logiques. La seconde fonctionne comme un service back-end spécialisé qui comprend les caractéristiques des workloads IA. Quant aux requêtes entrantes, elles suivent les règles HTTPRoute de la Gateway API, mais avec des algorithmes de load balancing distincts. Entrent notamment en compte l’utilisation de la mémoire GPU, l’évolution des files d’attente et l’affinité d’adaptateur (pour les modèles LoRA, on préfère diriger les requêtes vers des serveurs où le bon adaptateur est déjà chargé).
Istio s’ouvre à Agent Gateway
Cette extension est récemment passée en bêta (mi-février, avec la publication d’Istio 1.29).
Le mode ambient multicluster a atteint le même stade à la même occasion, après des travaux en matière de télémétrie.
Dans un cluster local (ou entre des clusters situés sur un même réseau), la découverte xDS entre pairs permet de connaître tous les endpoints. À l’échelle de plusieurs réseaux, le mécanisme est moins pratique : des informations peuvent se perdre, vu la quantité à répliquer.
Pour permettre l’échange de métadonnées de pairs entre endpoints et gateways situés sur des réseaux différents, le protocole HBONE a été enrichi d’en-têtes spécifiques. Istio y associe le concept de namespace sameness : dans un mesh multicluster, toutes les namespaces ayant le même nom sont considérés comme un même namespace.
Chaque cluster a sa passerelle est-ouest avec une IP faisant office de point d’entrée pour les ztunnels (« tunnels zero trust ») déployés sur chaque nœud. Pour sécuriser le trafic, le mode ambient multicluster imbrique deux connexions HBONE. L’une chiffre le trafic du ztunnel vers la passerelle et leur permet de vérifier leurs identités respectives. L’autre chiffre le trafic de bout en bout et permet aux ztunnels source et destination de vérifier également leurs identités.
Le multicluster sur un même réseau reste en version alpha. Plus récente – et également expérimentale – est la prise en charge d’Agent Gateway comme composant du plan de données. Ce proxy made in Solo.io se nourrit des protocoles A2A et MCP pour apporter une gestion plus flexible du trafic dans le contexte des workloads IA.
L’extension inférence, prise en compte pour la « certification IA » des clusters Kubernetes…
Gérer une implémentation de l’extension inférence pour la Gateway API devrait bientôt devenir un critère dans le cadre du « programme de conformité IA » de la CNCF.
Ce dispositif introduit à l’automne 2025 définit un ensemble de capacités, d’API et de configurations qu’un cluster certifié « conforme Kubernetes » doit proposer pour exécuter de façon fiable et efficace des workloads IA/ML. Principal objectif : éviter une fragmentation qui compromettrait la portabilité.
Chaque version de K8s a sa liste d’exigences associée. Pour la dernière en date (1.35), le socle obligatoire est le suivant :
Prendre en charge l’allocation dynamique des ressources (DRA)
Gérer la Gateway API dans une implémentation permettant une « gestion avancée » pour les services d’inférence (distribution pondérée du trafic, routage sur la base des en-têtes, intégration avec les maillages de services…)
Permettre d’installer et d’exploiter au moins une solution de planification des gangs
Fonctionnement correct de l’HorizontalPodAutoscaler – si présent – pour les pods qui exploitent des accélérateurs
Exposer des métriques sur les accélérateurs et les workloads pris en charge
Isoler les accès aux accélérateurs depuis les conteneurs
Gérer au moins un opérateur IA complexe disposant d’un CRD (Ray, KubeFlow…)
En présence d’un autoscaler ou d’un mécanisme équivalent, permettre de redimensionner les groupes de nœuds contenant des accélérateurs spécifiques en fonction des pods qui sollicitent ces accélérateurs
… comme les architectures désagrégées
Seul ce dernier point n’est pas obligatoire avec les versions précédentes de Kubernetes (il est recommandé avec la 1.34). Avec la 1.35, la spec s’est enrichie de trois autres recommandations :
Mécanisme vérifiable pour s’assurer de l’installation des pilotes et des configurations adéquats sur les nœuds dotés d’accélérateurs
Possibilité de mettre en œuvre au moins une stratégie de partage statique de ressources avec les accélérateurs qui le gèrent
Capacité à exposer des accélérateurs virtualisés
Il y a quelques semaines, plusieurs recommandations ont été intégrées dans la perspective de K8s 1.36, attendu pour le 22 avril. Gérer une implémentation de l’extension inférence pour la Gateway API en fait donc partie. Il en va de même avec l’utilisation du DRA pour attacher des pods à plusieurs interfaces réseau. Et avec la prise en charge d’architectures d’inférence désagrégées (vLLM avec instances prefill et decode séparées, llm-d, Dynamo…).
À l’heure actuelle, les fournisseurs de distros Kubernetes les autocertifient. Une suite de tests automatisés doit prendre le relais cette année.
Dapr Agents en GA
Autre projet de l’écosystème CNCF qui vient de franchir un cap : Dapr Agents. Ce framework Python, destiné au développement d’applications agentiques sur la base du runtime distribué Dapr, est passé en v1.
À cette occasion, le concept d’« agent » devient obsolète, laissant place aux « agents durables ». Une évolution terminologique censée illustrer les bénéfices du runtime en matière de persistance – stockage sur listes Python, bases vectorielles ou magasins Dapr ; retry automatique ; orchestration déterministe ou orientée événements…
La v1 apporte la possibilité d’invoquer des agents en tant qu’outils. Elle donne aussi le choix entre exécution séquentielle et parallèle des outils. Et ajoute Redis comme option de base vectorielle.
Kyverno n’est pas un projet AI-centric (quoique la gestion des passerelles IA/MCP soit sur sa roadmap), mais il vient de monter en grade à la CNCF, y atteignant le plus haut niveau de maturité.
On doit ce moteur de policy-as-code à l’entreprise américaine Nirmata. Laquelle a développé, sur cette base, des solutions de gouvernance d’infrastructure.
Sous l’aile de la CNCF depuis 2020, Kyverno est aujourd’hui utilisé chez Adidas, Bloomberg, Coinbase, Deutsche Telekom, LinkedIn, Spotify, Vodafone et Yahoo, entre autres. Il s’agissait à l’origine d’un contrôleur d’admission Kubernetes. Il est désormais disponible en CLI, SDK et conteneur. La dernière release marque l’adoption complète du CEL (Common Expression Language) en plus du YAML.
Platform engineering : maturité CNCF ne rime pas toujours avec adoption
Kyverno figure dans le dernier radar trimestriel de la CNCF relatif aux outils de platform engineering. Un autre moteur PaC s’y trouve : OPA (Open Policy Agent). Bien qu’arrivé au plus haut niveau de maturité au sein de la fondation, il n’apparaît encore qu’au premier stade d’adoption chez les développeurs. En tout cas les quelque 400 qui ont participé à l’enquête.
Cette dernière a couvert trois domaines : automatisation de workflows, livraison d’applications et gestion de la sécurité/conformité. Elle a pris en compte quatre dimensions :
L’usage des outils (quels devs s’en servent ou s’en sont servis)
Leur utilité (jugement de l’adéquation aux besoins des projets)
Leur maturité (évaluation de stabilité et de fiabilité)
La propension à les recommander
Il en résulte trois catégories : « adopt » (outils fiables et applicables à la plupart des cas d’usage), « trial » (qui valent le coup d’être explorés) et « assess » (à évaluer avec précaution). Le tableau suivant synthétise la situation. « S » signifie qu’un outil est en sandbox à la CNCF (premier niveau de maturité). « I », qu’il en est au deuxième (incubation). « G », qu’il a atteint le dernier (graduated).
Falco (G)
in-toto (G)
KubeArmor (S)
KubeWarden (S)
Kyverno (I)
Sigstore (G)
Bank-Vaults (S)
Bpfman (S)
Capsule (S)
Cloud Custodian (I)
External-Secrets Operator (S)
KubeScape (I)
Notary (I)
OpenCost (I)
SPIFFE/SPIRE (G)
cert-manager (G)
Keycloak (I)
OPA (G)
Quatre approches plate-forme, quatre approches IA
L’enquête donne aussi un aperçu de l’approche que les organisations ont des workflows IA en fonction de la façon dont elles constituent leurs plates-formes développeurs.
Le plus souvent (41 % de l’échantillon), plusieurs équipes – DevOps, SRE, infra – contribuent à fournir des capacités. Dans 10 % des cas, une équipe plate-forme développe en interne ; dans 18 % des cas, elle intègre principalement des outils tiers. Il arrive aussi qu’elle s’appuie essentiellement sur des solutions du marché (6 %) ou que chaque équipe choisisse et gère son outillage (16 %).
Pour traiter les workflows IA, certains ont étendu leur plate-forme existante (17 %). D’autres en ont construit une spécifique (19 %), utilisent des plates-formes du marché (18 %) ou ont une approche hybride (expérimentation séparée, prod partagée ; 35 %). La gestion directe par les équipes IA sans support au niveau plate-forme est plus rare (5 %).
Connexion
