Kubernetes : L’ANSR reste fidèle à l’offre managée d’OVHcloud

MKS devient la plateforme standard

« En 2021, trois premiers clusters Kubernetes ont été déployés en mode managé sur OVHcloud », raconte Rémi Bercher, consultant chez Gravitek, le prestataire qui assure la cogérance du cloud de l’ASNR avec Alter Way. LeMagIT a pu le rencontrer à l’occasion d’un événement OVHcloud à Paris. « Il s’agit alors d’applications et de données non critiques et le projet est d’avoir une facturation séparée pour chaque unité métier », ajoute-t-il. Véritable plateforme de production, celle-ci n’est pas encore pilotée via les automatismes de Terraform. L’administration des trois clusters est réalisée à la main, via des consoles graphiques.

Puis, à la fin de cette même année, l’aventure MKS est réellement initiée avec six clusters Kubernetes managés sur OVHcloud. L’ASNR commence alors à exploiter la plateforme cloud pour des applications plus sensibles, notamment une application traitant des données de santé, le premier projet HDS.

Les équipes vont rapidement monter en compétence et exploiter les capacités de la plateforme managée, notamment pour gérer l’exécution, les mises à jour de code, ajouter des sauvegardes. Jusque-là, les plateformes de développement et de production sont confondues. L’isolation des environnements n’est assurée que par la différence entre les noms de domaines. Mais cette approche est rapidement jugée insuffisante, d’autant que les applications exécutées sur ces clusters étaient de plus en plus utilisées.

Forts de l’expérience des administrateurs sur Terraform, il a rapidement été possible de séparer les plateformes et de les dédier tantôt au développement, tantôt à la production des nouveaux projets.

« Cela a amené deux avancées notables. D’une part, nous avons pu mieux gérer l’étanchéité des environnements, avec des droits plus limités, ce qui est toujours une bonne chose. D’autre part, sur le volet infrastructure, nous pouvions effectuer des montées de version sur la partie développement avant de le faire sur la partie production, dans un deuxième temps », se souvient Rémi Bercher. Il précise que la gestion des clusters est à ce moment-là réalisée via Terraform en version 0.16 et que la séparation entre les plateformes de développement et de production a été actée en avril 2022.

Deux mois plus tard, le réseau privé vRack est activé sur l’infrastructure. Tout au long de l’année, de nouveaux clusters sont créés. La Software Factory historique, qui fonctionnait toujours sur des instances virtuelles, est migrée au fil de l’eau sur MKS, tout simplement via des sauvegardes/restaurations du cluster.

Une montée en puissance qui doit faire face à quelques bugs

Mais, en 2023, des problèmes de production surviennent. Le premier a concerné etcd, la base de données qui stocke la configuration et les informations de fonctionnement des clusters Kubernetes.

En installant de nombreux outils sur ses clusters, notamment Kyverno pour la sécurité, Trivy pour gérer les vulnérabilités ou encore Rancher, l’ASNR va butter sur les limites du forfait gratuit d’OVHcloud, lequel limite le nombre d’appels à l’API serveur. Lorsque le plafond est atteint, il faut passer au forfait standard. Mais encore faut-il savoir qu’il est atteint.

« Nous avions donc beaucoup d’appels aux API serveur. Or, nous n’avions pas de visibilité sur ces appels. Les interactions avec le support et l’équipe Kubernetes d’OVHcloud nous ont permis de trouver une solution pour anticiper les dépassements de plafond, en déclenchant des alertes sur le quota d’accès etcd consommés », explique Rémi Bercher.

Pour renforcer son contrôle, l’équipe a d’ailleurs développé un module d’export des données etcd. Cela lui permet de vérifier le mode de facturation de l’ensemble des nœuds et savoir lesquels sont facturés au mois ou à l’heure. « La stratégie de l’ASNR est plutôt de s’engager sur le long terme et, notamment, ne pas faire d’auto-scaling. Avec ces données, nous nous assurons que tous les nœuds ont été créés comme il faut. »

Autre problème, celui engendré par le principe même d’une offre managée : c’est le fournisseur de service, OVHcloud en l’occurrence, qui réalise les mises à jour lorsque celles-ci sont disponibles.

« Nous n’étions pas habitués à cette approche, puisque nous gérions nous-mêmes nos clusters. Heureusement, plusieurs modes de mise à jour sont proposés et, dans notre cas, nous avons finalement sélectionné l’option de contrôler nous-mêmes nos mises à jour » dit Rémi Bercher.

Puis, quelques problèmes de stockage ont été rencontrés sur l’application HDS. L’équipe de développement rencontrait des baisses de performances au niveau de la base de données et une nouvelle classe de stockage a dû être sélectionnée pour s’adapter à la charge.

En 2024, enfin, alors que le nombre d’utilisateurs ne cesse de croître en production, apparaissent des erreurs DNS. « C’est un problème fréquent sur les architectures Kubernetes et qui n’est pas lié à OVHcloud. Cela arrive lorsque les applications envoient un grand nombre de requêtes. Plus ce nombre est élevé, plus des requêtes peuvent échouer. La solution est de déployer un cache DNS », assure notre interlocuteur.

Adopter l’approche GitOps, avec ArgoCD

Le nombre de clusters continuant de grossir, l’ASNR va céder à la mode du GitOps. L’équipe décide en l’occurrence de passer sur ArgoCD pour homogénéiser la gestion de son infrastructure. « Depuis une seule interface, nous sommes en mesure de mettre à jour toutes les briques d’infrastructure, même si, en contrepartie, cela vient ajouter de la charge à etcd. » De même, tous les secrets sont désormais gérés dans Git, via l’outil External Secrets Operator.

Autre évolution qui va dans l’air du temps, la mise en œuvre d’IA dans les clusters. L’ASNR compte de nombreux chercheurs qui travaillent sur des données et mettent en œuvre des modèles de Machine Learning. « Nous avons commencé à ajouter des GPU sur plusieurs projets, et nous avons eu quelques surprises. C’est la première fois que j’ai eu une erreur dite Out of stock ! La solution a été de jouer avec les nodepools et de choisir la région en fonction du stock disponible à l’instant T », raconte Rémi Bercher.

En 2025, l’ASNR a dû migrer ses répartiteurs de charge IOLB, lesquels ne sont plus disponibles au-delà de la version 1.31 de Kubernetes. Désormais, OVHcloud propose pour cette tâche son service Public Cloud Load Balancer. À l’occasion de cette migration, l’équipe s’est fait assister par un architecte cloud pour mettre en œuvre les meilleures pratiques du moment dans la gestion des passerelles, répartiteurs de charge et adresses IP publiques via Terraform.

Aujourd’hui, l’ASNR gère 22 clusters MKS, soit 2 600 pods et 120 nœuds. 750 applications sont gérées via ArgoCD ainsi que 150 noms de domaine. La Software Factory compte un millier d’utilisateurs et traite 2,5 millions de jobs CI/CD. Certaines applications ont connu jusqu’à dix montées de version de Kubernetes sans réinstallation. 2026 s’annonce comme une année de rationalisation de la plateforme et d’amélioration de la résilience de cette infrastructure.