Cluster Kubernetes : De la dette technique à la disponibilité continue
« Kubernetes is a platform for building platforms. It’s a better place to start; not the endgame ». Kelsey Hightower relève la modularité importante de Kubernetes qui est un socle d’infrastructure et non pas une solution « clés en main ». Cette approche unique permet à Kubernetes de s’adapter à n’importe quel environnement, même les environnements les plus critiques comme celui du Ministère des Armées qui est en dehors du réseau Internet. C’est avec cette contrainte que j’ai été amené à étudier et à utiliser la technologie Kubernetes. Étant donné que la réalisation s’est déroulée au sein du Ministère des Armées dans un contexte sensible, certaines informations ont été volontairement omises.
Comment la technologies Kubernetes s’est-elle imposée dans le projet ?
J’ai réalisé deux ans d’alternances au Ministère des Armées où j’ai eu la chance de réaliser plusieurs missions. Une de ces missions a été la migration d’un cluster Mesosphere vers un cluster Kubernetes. Un cluster est un regroupement de plusieurs machines pour mutualiser leurs ressources afin d’augmenter la disponibilité des applications se trouvant sur ce dernier. Mesosphere et Kubernetes sont deux technologies qui permettent de créer et d’administrer des clusters en entreprise. La problématique qui est apparue rapidement a été la fin du support de Marathon en octobre 2021. Ce dernier est une brique importante de Mesosphere étant donné que c’est lui qui permet de gérer des conteneurs Docker sur le cluster. Docker est une technologie qui permet de pacager une application ainsi que ces dépendances sous la forme d’un conteneur qui peut ensuite être déployé sur un cluster. Le Ministère des Armées s’est donc retrouvé avec des clusters, n’étant plus maintenu et ne proposant plus de nouvelles fonctionnalités ou des corrections de failles de sécurité. Pour résoudre cette problématique, ils ont décidé de passer sur Kubernetes qui est approuvé par les plus grandes entreprises et qui est soutenu directement par Google. Grâce à cette nouvelle technologie, ils pourraient améliorer grandement la sécurité des applications tout en bénéficiant des nouvelles fonctionnalités et des technologies de clustering. Pour y parvenir, j’ai étudié l’existant, en répertoriant les besoins des équipes de développeurs. L’intérêt était de ne pas perdre de fonctionnalités lors du passage sur Kubernetes et d’assurer une continuité fluide au sein des équipes de développeurs. Plusieurs besoins en sont ressortis, comme la gestion des secrets au sein du cluster ou encore l’intégration et le déploiement continu des applications. Les secrets sont des variables contenant des informations sensibles comme des mots de passe ou des certificats. Que nous avons besoin d’utiliser au sein du cluster et au sein des applications exécutées sur ce dernier. Dans un second temps, j’ai étudié les nouvelles possibilités offertes par Kubernetes. L’intérêt n’est pas de les mettre en place, mais plutôt d’appréhender l’évolution du cluster dans les mois à venir. La plus importante a été le support de « Blue/Green deployments » par Kubernetes. C’est une méthode de déploiement qui permet de faire coexister deux versions d’une même application. La version de production et la nouvelle version. De cette manière, nous pouvons rediriger les utilisateurs sur la nouvelle version et revenir sur l’ancienne extrêmement rapidement en cas d’erreurs. Il y a aussi le support de l’A/B Testing qui permet aussi la cohabitation de deux versions d’une même application. La différence est que seulement une partie des utilisateurs seront redirigés sur la seconde version pour tester leur comportement avant de passer intégralement les utilisateurs sur la nouvelle version. Ces deux approches améliorent grandement la qualité de livraison des nouvelles versions des applications. Pour finir, j’ai migré l’intégralité des outils du Ministère des Armées sur ce nouveau cluster étape par étape afin de m’assurer de son bon fonctionnement. Kubernetes a permis d’améliorer grandement la sécurité des applications tout en fournissant des opportunités certaines pour améliorer le cluster existant.
Quel était le contexte initial du projet ?
Dans le cadre de mon Master Expert des Systèmes d’Information à l’ESIEA, j’ai été amené à réaliser un stage de six mois et une alternance de deux ans au sein du Ministère des Armées à Paris. Il s’agit d’un ministère qui est découpé en de nombreuses organisations qui proposent des postes dans tous les secteurs professionnels. J’ai eu la chance de travailler dans une de ces organisations. J’ai pu évoluer dans un cadre sensible. Je n’avais pas d’accès direct à Internet. Dans ce contexte, j’ai été amené à travailler en tant qu’administrateur SRE sur la migration des applications d’un cluster Mesosphere vers un cluster Kubernetes. Mon rôle a été d’analyser et d’étudier la faisabilité de cette mission afin qu’il y ait le moins de friction possible pour les développeurs lors de la migration et après la migration. Pour y parvenir, en tant qu’administrateur SRE, j’ai dû adapter de manière transparente les processus de développement et de déploiement continu des applications sur le cluster Kubernetes. J’ai me suis adapté aux contraintes et aux besoins des équipes du Ministère des Armées.
Durant ce projet, j’ai créé une solution complète permettant d’améliorer et d’adapter l’intégration et le déploiement continus de la technologie Kubernetes. Cette solution a permis de faciliter grandement la migration. J’ai pu définir et versionner les déploiements sur Kubernetes. Je me suis appuyé sur la convention HELM Charts qui permet de définir les déploiements de chaque application. Une fois le déploiement défini nous pouvons le déployer selon notre volonté sur les clusters Kubernetes. Si la migration d’une application ne se déroulait pas correctement, je n’avais qu’à corriger la définition des déploiements, puis à retester. J’ai pu réitérer un grand nombre de fois sur la définition des déploiements afin de trouver la manière la plus robuste et propre de les définir. Cette solution m’a permis de renforcer l’adoption de la culture DevOps au sein du Ministère des Armées. Le DevOps est une culture qui vise à automatiser, superviser et optimiser les processus de développement.
La culture DevOps est déjà fortement présente au sein du Ministère des Armées, néanmoins les dernières méthodes pour améliorer la qualité des livraisons des nouvelles versions des applications n’en sont pas encore appliquées. Kubernetes, va permettre de mettre en place des méthodes de déploiement comme le « Green Blue deployment » ou encore « l’A/B Testing ». Ces deux nouvelles méthodes sont très importantes au sein de la culture DevOps. Elles permettront de réduire drastiquement les erreurs ou les bugs qui se glissent lors des livraisons de nouvelles versions des applications. Le temps initialement passé à stabiliser les nouvelles versions des applications pourra être redirigé sur des tâches ayant une valeur ajoutée plus élevée dans les projets.
Dans un premier temps, j’ai étudié l’existant et les dépendances à l’ancien cluster Kubernetes. La seule dépendance se trouvait au niveau des CI/CD GitLab. Il s’agit d’une fonctionnalité de GitLab qui permet de déployer des applications sur des clusters. Nos déploiements se basaient sur des templates propres à Mesosphere qui n’étaient donc pas compatibles avec Kubernetes. Par conséquent, il a fallu que je me renseigne sur la manière de déployer une application sur Kubernetes. J’ai trouvé deux solutions. La première est la définition d’un déploiement dans un fichier au format YAML. La problématique qui est rapidement apparue a été la normalisation du code et la réutilisabilité des charts Kubernetes. Une chart Kubernetes permet de définir au format YAML le déploiement et le comportement d’une application. YAML est un format de fichier qui permet de structurer des données. Il est très adapté pour les fichiers de configuration en raison de sa lisibilité. De plus il est facilement maintenable. Pour remédier à cette problématique, une solution a vu le jour en 2015 sous le nom de HELM Chart. Il comprend un ensemble de règles ainsi qu’une structure prédéfinie pour normaliser tous les déploiements. Cette solution est aujourd’hui une référence au sein des entreprises. Grâce à cette solution, il est possible d’avoir des charts de déploiement structurés, maintenables et réutilisables sans avoir à les recréer intégralement. Finalement, nous sommes partis sur cette solution et j’ai pu travailler sur l’adaptation des templates de déploiements pour qu’ils fonctionnent avec la technologie Kubernetes. J’ai aussi pu retravailler en profondeur les CI GitLab existantes afin de rajouter le support des nouvelles fonctionnalités de Kubernetes comme le Green/Blue deployment ou encore l’A/B Testing.
Dans un second temps, j’ai mis en application les solutions étudiées. Je me suis basé sur les outils non critiques utilisés par les équipes. L’intérêt est de minimiser l’impact en cas d’erreurs. Ça a mis en lumière des erreurs dans mes charts HELM que j’ai pu corriger immédiatement. Ça a aussi mis en lumière certaines limitations propres à l’environnement critique dans lequel se trouve le cluster Kubernetes. Certaines fonctionnalités avancées de Kubernetes n’étaient pas disponibles, comme les CRDS qui permettent de créer des ressources de déploiement qui ne sont pas prises en charge nativement. Le nouveau cluster Kubernetes a aussi mis en lumière de nombreuses mauvaises pratiques utilisées au sein des équipes opérationnelles. Comme l’utilisation de conteneurs avec des utilisateurs « root ». Ces utilisateurs ont la particularité d’avoir tous les droits au sein des conteneurs Docker. Ce qui n’est pas une bonne pratique. J’ai immédiatement mis à jour les CI GitLab afin de remonter ces problématiques avant le déploiement sur le cluster Kubernetes. Par conséquent, j’ai pu améliorer et sécuriser les charts HELM ainsi que les déploiements CI GitLab pour répondre à tous les besoins du Ministère des Armées vis-à-vis de leur politique de sécurité.
Même si la migration vers Kubernetes est essentielle pour favoriser l’innovation et améliorer la sécurité des applications. Il s’agit d’une technologie qui utilise énormément de notions et d’outils différents pour fonctionner. Il faut donc s’assurer que les équipes opérationnelles ont la capacité de prendre en charge la maintenance et les mises à jour des composants qui forment la technologie Kubernetes. Sans ce prérequis, le Ministère des Armées pourrait se retrouver dans la même situation que Mesosphere si Kubernetes n’est pas mis à jour tous les six mois lors d’une mise à jour majeure. De plus, la maintenance d’un cluster Kubernetes nécessite de nombreuses compétences et de nombreuses personnes. Pour limiter cette problématique, le Ministère des Armées a formé les équipes opérationnelles durant plusieurs jours avec des experts du milieu.
Quelles ont été les étapes principales du déroulement de ce projet ?
Études de l’existant
Dans un premier temps, j’ai pris en main le cluster historique du Ministère des Armées. C’est une étape essentielle qui me permettra d’identifier les besoins des équipes de développeurs et les dépendances des applications sur ce dernier. Mesosphere a une composition similaire à Kubernetes. C’est-à-dire qu’elle est composée de pleins d’outils qui lui permettent de fonctionner. Par exemple, pour que Mesosphere puisse gérer des applications sous la forme de conteneur Docker, un composant a été ajouté. Il s’agit de Marathon. C’est lui qui va s’occuper d’orchestrer les applications sur le cluster. Mesosphere a aussi un fonctionnement assez particulier, il n’est pas très modulable. C’est-à-dire que pour fonctionner, il installe énormément de services sur les machines qui vont former le cluster. Mais si un service arrête de fonctionner, ça va faire un effet en cascade et les autres services risquent de ne plus fonctionner également. De plus, le support de Marathon s’est arrêté en octobre 2021, dorénavant il n’y a plus de mises à jour pour ajouter des fonctionnalités ou des corrections de failles de sécurité. Il devenait urgent de trouver une solution adaptée pour migrer l’infrastructure existante sur une infrastructure plus moderne et sécurisée. Durant cette phase, j’ai étudié différentes approches pour réaliser la migration de manière progressive, en minimisant les risques. Finalement, l’approche retenue a été de migrer les outils les moins critiques utilisés par les développeurs, puis de migrer les applications les plus critiques plusieurs mois après, une fois que les équipes seront formées à cette nouvelle technologie. Pour répondre aux besoins des développeurs, j’ai étudié les outils de remplacement comme les charts Helm à la place des templates de déploiement Marathon qui permettaient de définir la manière dont devaient fonctionner les applications dans le cluster. Ou encore, j’ai étudié les CI/CD GitLab existants pour les adapter au nouveau cluster Kubernetes.
Tout au long du projet, j’ai appliqué une méthode de travail avec mon tuteur en entreprise, en m’inspirant des principes de la méthodologie Agile. Bien que le contexte du Ministère des Armées impose certaines limites en matière de flexibilité, nous avons mis en place une organisation inspirée du Kanban. Nous avons défini des tâches claires priorisées dans un tableau Kanban, avec un suivi régulier journalier de leur avancement. Cela m’a permis d’anticiper les éventuels blocages et d’adapter mes tâches en fonction des retours des autres administrateurs SRE du service. Cette organisation a été un facteur clé de réussite du projet.
La migration technique s’est faite étape par étape, en commençant par les outils internes à faibles risques. Cela m’a par ailleurs permis de tester mes déploiements avec l’outil Helm et également d’identifier les erreurs dans les templates de déploiement. Lors de mes tests, j’en ai aussi profité pour corriger les problèmes que j’avais détectés sans impacter l’environnement de production. Au final, ce test n’a pas non seulement été bénéfique pour le projet, mais m’a également permis de renforcer mes compétences en CI/CD GitLab et mes connaissances de l’outil HELM. Toutefois, je me suis également rendu compte que les anciens CI/CD GitLab étaient basés sur des templates Mesosphere, ce qui voulait dire que j’ai du apprendre à migrer ces pipelines vers un environnement Kubernetes. Pour finir, j’ai aussi eu à mettre en place plusieurs règles de sécurité, dans les CI GitLab, par exemple le blocage des images non scannées ou encore bloquer l’utilisation de comptes administrateurs dans les conteneurs. Pour ce faire, j’ai simplement eu à intégrer l’outil Trivy qui s’occupe d’analyser automatiquement les failles de sécurité des images Docker. À terme, cela permettra de réduire les risques lors des mises en production.
Je pense que ce projet de migration a été l’un des projets les plus formateurs et techniques que je n’ai jamais pu réaliser. En effet, j’ai du mettre à profit mes connaissances dans en l’administration système, en développement, en sécurité et même en gestion de projet pour réaliser ce projet. Néanmoins, malgré la complexité du projet, il faut reconnaître qu’il m’a donné l’occasion de renforcer l’adoption de la culture DevOps au sein des équipes du Ministère des Armées. Cela c’est fait par l’ajout d’outils modernes qui permettent d’évoluer vers des méthodes de déploiement plus complexes comme l’A/B Testing ou le Blue Green Deployment. De plus, cette migration a eu un impact immédiat sur l’entreprise puisque cela a fortement amélioré la stabilité des applicatioins et la collaboration entre les équipes de développement et les équipes opérationnelles. Enfin, je finirais par dire que Kubernetes est aujourd’hui une compétence essentielle pour tout administrateur SRE et que ce projet m’a permis d’obtenir une solide base de connaissances pour mes futures missions en entreprise, comme pour mes futurs projets personnels.
Migration des outils
Pour réaliser cette migration, j’ai décidé d’industrialiser l’ensemble du processus de déploiement afin de les rendre réutilisables tout en préparant la solution finale. Cette industrialisation a été essentielle pour augmenter l’efficacité. J’ai pu facilement réitérer lors des erreurs. Je me suis appuyé sur Helm pour la gestion des déploiements sur Kubernetes et je me suis appuyé sur GitLab CI/CD pour l’automatisation des processus de livraison. Ces deux outils ont joué un rôle clé dans la réussite du projet, car ils m’ont permis de transformer un ensemble de scripts manuels en chaînes de production continues et entièrement documentées. Dans un premier temps j’ai construit des charts Helm personnalisés pour chaque type d’application utilisée par les développeurs du Ministère des Armées. Un chart Helm permet de définir la manière dont une application doit être déployée, configurée, sécurisée et exposée dans le cluster Kubernetes. Grâce à cette approche, chaque application est aujourd’hui déployée selon une structure standardisée, versionnée et facilement modifiable grâce à un système de variables. J’ai intégré dans ces charts toutes les bonnes pratiques recommandées par la Cloud Native Computing Foundation. J’ai suivi les indications en matière de sécurité. J’ai aussi intégré leur recommandation de sécurité au niveau des conteneurs Docker. Cette approche a permis de garantir une uniformisation des déploiements, tout en facilitant la maintenance. Parallèlement, j’ai adapté les CI/CD GitLab existantes. Elles étaient conçus pour l’ancien cluster Mesosphere. Ces pipelines ont été entièrement réécrits pour supporter les spécificités de Kubernetes. J’y ai intégré la prise en charge des charts Helm. J’ai ajouté plusieurs étapes automatiques dans chaque pipeline : des tests de qualité de code (lint), des scans de vulnérabilité des images Docker avec Trivy, des vérifications de bonne pratique (comme l’interdiction d’exécuter des conteneurs en root), et des étapes de déploiement automatisé sur différents environnements. Enfin, pour assurer l’avenir de cette solution et son adoption par l’ensemble des équipes. J’ai pris soin de documenter et de présenter toutes les modifications à l’équipe de développeurs et à l’équipe opérationnelle. L’ensemble de cette documentation a été rédigé au format Markdown. C’est un format qui est pris en charge nativement par GitLab. Elle explique aux équipes comment utiliser les nouvelles CI/CD GitLab ainsi que les charts Helm. Grâce à cette documentation et à l’automatisation mise en place, les développeurs ont pu monter rapidement en compétence, tout en étant accompagnés. Cette industrialisation a été une étape importante pour permettre une migration fiable, évolutive et sécurisée vers Kubernetes.
a. Prise en main du cluster Mesosphere (remplacement de tous le noeuds)
Dans un premier temps, j’ai dû prendre en main le cluster Mesosphere. Il se trouve qu’une migration réseau devait être effectuée et que tous les nœuds formant le cluster devaient être manuellement réinstallés et configurés dans le nouveau réseau. Ce fut une opportunité pour moi, car si j’y arrivais, ça signifiait que j’étais capable de comprendre en profondeur son fonctionnement. Pour y parvenir, j’ai réécrit tous les rôles Ansible. Un rôle Ansible est un ensemble de fichiers de configuration qui définissent une suite d’actions à réaliser sur des machines pour les configurer. C’est par conséquent une technologie parfaite pour migrer l’intégralité des nœuds du cluster sur un nouveau réseau. Je me suis basé dessus et au bout de deux mois de travaux, j’ai commencé à effectuer la migration. Dans un premier, je n’ai passé que quelques nœuds. Il y a donc eu la cohabitation de nœuds provenant de plusieurs réseaux, ce qui n’est pas problématique dans le cadre d’un cluster. Une fois les vérifications du bon fonctionnement des applications sur ces derniers, j’ai pu migrer la totalité des 300 nœuds qui forment le cluster Mesosphere. Suite à cette migration, j’ai acquis une profonde compréhension de Mesosphere et de son fonctionnement par service ainsi que les dépendances entre ces composants. Cette phase n’était pas prévue initialement, mais elle m’a permis d’acquérir les compétences nécessaires pour appréhender au mieux la migration du cluster Mesosphere vers un cluster Kubernetes. Elle montre aussi que malgré les missions que l’on a, il y a toujours des imprévus et des urgences à faire passer par moment en priorité. Dans le monde de l’entreprise, il faut pouvoir jongler et mener à bien les missions principales, mais aussi les missions qui viennent se greffer d’urgence. Il faut être prêt pour l’imprévu qui est omniprésent.
b. Migration sur le cluster Kubernetes
Dans un second temps, j’ai commencé à définir les chart HELM pour déployer les applications non critiques. Je les ai faites une à une. J’ai déployé avec cette méthode une stack ELK pour la gestion des journaux, un Cerebro et plusieurs autres applications. Une fois les applications migrées sur le nouveau cluster Kubernetes. J’ai intégré les charts HELM au CI/CD GitLab. De cette manière je pouvais les redéployer en automatique. Par exemple, si je souhaitais modifier la version de Cerebro, je n’avais qu’à modifier la valeur de la version dans les paramètres de GitLab. GitLab détectera automatiquement le changement de version et le redéploiera en automatique dans la nouvelle version.
c. Formation de l’équipe
Suite à ces différentes étapes, avant de pouvoir migrer l’application principale de notre équipe, il a fallu faire une passation de connaissances. Afin de s’assurer que l’on puisse gérer les pannes ou les erreurs, peu importe la situation. La problématique a été que j’étais le seul à maîtriser Kubernetes dans l’équipe. Les tâches de maintenance étaient par conséquent plus fastidieuses et plus compliquées à effectuer. Pour améliorer la fiabilité de nos applications, j’ai donc décidé de réaliser une conférence avec les membres de l’équipe afin de les former aux principes, au fonctionnement et aux particularités de Kubernetes. L’objectif est qu’à la fin de la conférence, ils puissent gérer les erreurs courantes liées aux déploiements d’applications sur un cluster Kubernetes. J’ai découpé la conférence en plusieurs étapes. Pour commencer, j’ai parlé du fonctionnement global de Kubernetes, ensuite j’ai parlé des ressources utilisables dans Kubernetes et j’ai expliqué le fonctionnement des charts HELM pour déployer les applications sur ce dernier. Finalement, j’ai aussi montré et expliqué le nouveau fonctionnement des CI/CD GitLab. De cette manière, ils ont une vision d’ensemble précise sur le fonctionnement de la chaîne de production.
d. Solution finale
La réalisation de ce projet a marqué dans la modernisation de l’infrastructure du Ministère des Armées. Après plusieurs mois de travail j’ai pu finaliser la migration. L’ensemble des applications non critiques ont été migrées. Elles sont passées sur le cluster Kubernetes. Ce fut une étape extrêmement importante, car elle a permis de valider l’ensemble des travaux réalisés jusqu’à présent. J’ai utilisé toutes les notions de la culture DevOps. Grâce à cette migration les applications non critiques sont désormais déployées de manière sécurisée et industrialisée avec HELM et les CI/CD GitLab. Cette étape a également permis de démontrer que la solution déployée répondait parfaitement aux besoins réels des équipes de développement. Le tout en respectant les contraintes spécifiques liées à un environnement sans accès au réseau Internet. La mise en production des applications s’est faite progressivement en s’appuyant sur des CI/CD GitLab robustes. Les tests de qualité et de sécurité ont aussi aidés. Chaque application migrée a fait l’objet de vérifications approfondies de la part des quinze membres de l’équipe. Les retours des développeurs ont été très positifs. Surtout concernant la lisibilité des déploiements, la facilité de rollback en cas de problème et la performance globale du nouveau cluster. Un rollback est une fonctionnalité qui permet de redéployer une version précédente. C’est très pratique en cas d’erreurs. Aujourd’hui, il ne reste plus qu’une seule application à migrer : l’application principale de notre équipe, qui est également la plus complexe et critique. Cette dernière centralise de nombreuses données sensibles et ne peut pas se permettre d’être arrêtée même quelques minutes. Sa migration représente une étape à part entière, qui est actuellement en phase de préparation. Toutefois, tous les outils, les processus, les méthodes et les bonnes pratiques mis en place durant la première phase du projet serviront directement à faciliter cette dernière phase. Cette solution démontre l’efficacité de la culture DevOps. Surtout lorsqu’elle est appliquée à un environnement critique comme celui du Ministère des Armées. Elle démontre que même sans accès à Internet, il est possible de concevoir une infrastructure moderne et sécurisée si l’on investi suffisamment de temps. Cette migration est une réussite qui a permis d’améliorer la sécurité générale tout en améliorant mes compétences et celles de l’équipe. Elle pose les bases d’un environnement évolutif, sécurisé et hautement disponible qui pourra accueillir les applications critiques dans les prochains mois. Grâce à cette mission, je me sens plus que jamais prêt à poursuivre dans cette voie.
Qui sont les parties prenantes impliquées dans ce projet ?
Durant l’alternance, malgré le contexte sensible, j’ai pu passer les accréditations me permettant de travailler directement au sein d’une équipe composée de plusieurs développeurs et de plusieurs administrateurs SRE. Contrairement au stage où je me trouvais dans une salle séparée des équipes. Par conséquent, j’ai pu bénéficier grandement de leur expertise sur Mesosphère. Mon tuteur m’a par ailleurs fortement formé sur la solution Mesosphère avant de commencer cette mission. De plus, j’ai aussi pu bénéficier de l’expérience d’expert en Kubernetes qui se trouvait dans d’autres équipes du service, notamment en participant à une réunion de synchronisation des équipes opérationnelles du service toutes les deux semaines. Grâce à cette réunion, j’ai pu m’appuyer sur leurs expériences et les actualités du service afin de répondre au mieux à la mission. Finalement, j’ai pu être force de proposition et autonome dans la gestion de cette mission.
Quels bénéfices Kubernetes nous a-t-il apporté ?
Je suis fier d’avoir contribué à l’adoption de la culture DevOps au sein des équipes de développeurs et je suis fier d’avoir pu mettre en place une solution permettant de déployer les applications sur un cluster Kubernetes de manière sécurisée, ce qui n’était pas le cas avec Mesosphere. À court terme, des résultats sont déjà visibles. Les nouvelles versions des applications qui ont été livrées et déployées ont eu un gain significatif d’erreurs en moins. Les fonctionnalités de Kubernetes y sont pour beaucoup, notamment avec la possibilité de faire cohabiter différentes versions d’une même application et de filtrer précisément qui peut accéder à telle ou telle version. Sur du long terme, les chances d’avoir des applications vérolées se voient drastiquement diminuées étant donné que Kubernetes est mis à jour très régulièrement et qu’il adopte une politique de sécurité stricte au niveau des conteneurs. Un conteneur non sécurisé ne pourra donc pas être exécuté sur le cluster Kubernetes.
Personnellement, je pense que ce projet m’a aidé à approfondir mes connaissances en DevOps en découvrant des principes avancés de déploiement d’application. J’ai dû apprendre le fonctionnement en profondeur des clusters Mesosphere afin de mieux appréhender la migration vers une technologie plus récente comme Kubernetes. J’ai découvert les conventions des charts HELM et son application dans des environnements d’entreprise auprès d’experts du Ministère des Armées. Toutes ces notions m’ont permis d’appréhender et d’obtenir une version large et approfondie des possibilités qu’offrent les solutions de clustering en entreprise ainsi que les enjeux de sécurité qui en découlent. De plus, cette mission m’a donné l’occasion de manipuler à nouveau les CI GitLab et ainsi revoir complétement leur fonctionnement. Cela m’a ainsi permis d’approfondir des notions clés de la culture DevOps, comme la gestion des versions automatiques des applications et la stratégie de développement « GitLab Flow ». Ce projet s’est montré très complet et m’a permis de renforcer mon profil d’administrateur SRE en utilisant toutes les notions de la culture DevOps. Les équipes de développeurs voient aussi leur expérience amélioré avec la gestion des versions automatiques, la livraison et le déploiement des applications en automatique ainsi que la cohabitation entre deux versions d’une même application ce qui leur permet de mieux appréhender les mises en production des applications.
Quelles difficultés j’ai rencontrées et comment puis-je les surmonter à l’avenir ?
Cette alternance, en tant qu’administrateur SRE a représenté, pour moi, une opportunité unique de mettre en application les connaissances techniques et méthodologiques que j’ai acquises durant mon parcours. Durant les six mois de la mission, j’ai été intégré directement dans les équipes, ce qui n’était pas le cas durant mon stage étant donné le contexte sensible. Ce projet m’a permis de mesurer l’impact direct de mon travail au niveau des équipes techniques. J’ai aussi pu travailler sur la notion de gestion de crise, car le cluster Kubernetes a connu plusieurs pannes. Cette notion est difficilement enseignable dans un cadre purement académique. Cette première expérience a d’ailleurs joué un rôle déterminant dans la suite de mon parcours en me permettant de me prouver à moi-même que j’étais capable, même en tant de crise, d’identifier la source d’une panne et de réagir efficacement. Qu’il s’agisse d’un cluster Mesosphere ou Kubernetes. Le Ministère des Armées a ainsi pu évaluer mon sérieux, ma capacité d’adaptation et mes compétences techniques sur un projet critique. Cette mission m’a aussi permis d’aborder un grand nombre d’outils et de technologies modernes, souvent utilisés dans des contextes d’entreprises, mais ici adaptés à un environnement avec de fortes contraintes, ce qui m’a poussé à prendre en compte la résilience, la sécurité et la maintenabilité dès la phase de conception. Enfin, le fait de travailler dans un environnement totalement hors ligne m’a confronté à des limitations concrètes, qui m’ont obligé à anticiper, documenter et structurer mes déploiements Kubernetes avec une rigueur encore plus forte que dans un environnement connecté.
Lors de la réalisation, j’ai relevé deux grands axes d’amélioration. Le premier est l’observabilité au sein du cluster. Elle est déjà mise en place à l’aide de plusieurs outils comme Elastic, Grafana ou encore Kubernetes Dashboard. Néanmoins, elle ne remonte pas toujours toutes les alertes. C’est un problème qui était aussi présent sur l’ancien cluster Mesosphere. Étant donné qu’il s’agit d’un sujet complexe, il fera l’objet d’une prochaine mission à part entière. Il s’agit d’une notion extrêmement importante étant donné qu’elle permet de détecter des incidents avant qu’ils se produisent. Par exemple, un système de stockage qui attend plus de 90% d’utilisations envoie une alerte pour éviter d’être au stade où le système de stockage est complètement utilisé et où les applications l’utilisant se mettent à dysfonctionner. Cette nouvelle mission est déjà en cours de réalisation par les équipes opérationnelles du Ministère des Armées. Le second axe d’amélioration concerne la sécurité des clusters Kubernetes. Malgré les mises à jour régulières des clusters, il est nécessaire de les surveiller activement et régulièrement pour assurer un haut niveau de sécurité. Dans ce cadre, des solutions adaptées à Kubernetes ont récemment vu le jour, comme Kyverno, Falco et Wazuh. Kyverno est un gestionnaire de politiques de sécurité pour Kubernetes qui permet de définir des règles de sécurité avancées. Par exemple, il peut bloquer les images qui n’ont pas été scannées avant d’être déployées. Falco est un IDS qui permet de surveiller et d’envoyer des alertes en cas de comportements suspects sur les clusters Kubernetes. Wazuh est un HIDS, c’est-à-dire qu’il peut observer plus précisément ce qui se passe sur chaque machine qui forme le cluster. Il va plus loin dans la démarche en proposant une interface permettant de faciliter les audits et les investigations. Une mission de six mois a été créée en avril 2025 pour répondre à ce besoin. À l’avenir, je souhaite approfondir mes compétences en observabilité. En septembre 2025, je vais débuter le MS-SIS proposé par l’ESIEA qui est une formation diplômante en cybersécurité qui me permettra d’acquérir des compétences avancées en cybersécurité. Suite à cette formation, en fonction de l’environnement critique propre à chaque entreprise ou organisation, je serai capable d’auditer des clusters Kubernetes en profondeur pour s’assurer que leurs sécurités sont suffisamment robustes.
Pour conclure, Kubernetes est devenu la norme quand il s’agit de créer des clusters. Il permet de rendre les applications hautement disponibles, résilientes et plus sécurisées. L’année dernière, d’après « Ambient IT » il représentait environ 96% des clusters. Le concept de clustering est obligatoire pour un profil d’administrateur SRE, il représente la base de son travail, étant donné qu’il travaille sur la fiabilité des infrastructures. À l’avenir, je continuerai à travailler cette compétence quotidiennement au sein des entreprises dans lesquelles je travaillerai et au sein de mes projets entrepreneuriaux.