Kubernetes : Un cluster hautement disponible pour la production
Ma définition
Kubernetes est un outil qui a été démarré par trois ingénieurs de chez Google, Craig McLukie, Joe Beda et Brendan Burns. Il a été conçu pour atteindre une haute disponibilité des applicatifs. Le CTO d’Amazon a parfaitement résumé le quotidien d’un ingénieur en informatique avec cette phrase « Everything fails all the time ». Effectivement, l’humain et les Systèmes d’Informations que nous mettons en place sont faillibles, malgré une expertise pointue des ingénieurs. Nous ne pouvons pas arrêter de faire des erreurs, mais nous pouvons réduire drastiquement leur impact, notamment avec Kubernetes qui propose d’appliquer plusieurs concepts. Comme la redondance et l’auto-réparation des applicatifs ou encore le principe de cohabitation de deux versions d’un même applicatif pour rendre plus transparent un changement de version de ce dernier. Ce concept est essentiel pour mon profil d’administrateur SRE. Le rôle d’un administrateur SRE est d’assurer la fiabilité et l’efficacité des systèmes d’informations d’une entreprise. Certaines entreprises fournissent des services critiques avec de nombreuses attentes chez les clients et certaines organisations gouvernementales ont des missions ainsi que des devoirs à respecter. Dans ce cadre, les applicatifs qui permettent de répondre à ces problématiques se doivent d’être hautement disponibles. Quand l’on parle de la notion de hautement disponible, on essaie de tendre vers un applicatif ou un service qui est fonctionnel et qui est accessible plus de 99% du temps. L’objectif est d’atteindre un maximum de quatre jours d’inaccessibilité dans une année.
Mes éléments de preuve
Lors de mon alternance au Ministère des Armées, j’ai eu la mission de migrer des applications d’un cluster Mesosphere à un cluster Kubernetes. Un cluster en informatique est un ensemble de plusieurs machines interconnectées (généralement des machines virtuelles). Elles travaillent ensemble pour optimiser la performance, la haute disponibilité et la redondance des applications qu’elles font fonctionner. Mesosphère n’étant plus maintenu depuis le 31 octobre 2021, les risques autour de l’utilisation et de la sécurité de la technologie Mesosphère augmentent significativement. Il était donc important pour un organisme aussi sensible de réaliser une migration sur une technologie plus récente, maintenue et surtout plus sécurisée. Il se trouve qu’en interne de l’organisation se trouve un cluster Kubernetes, qui est un concurrent de Mesosphère. Kubernetes répond parfaitement aux problématiques actuelles. Il s’agit d’un outil qui permet de créer des infrastructures hautement disponibles pouvant accueillir différents applicatifs sous la forme de conteneurs Docker. Il est sécurisé et activement maintenu. Un conteneur docker est une technologie qui permet de créer une sorte de paquet contenant toutes les dépendances et uniquement les dépendances essentielles pour faire tourner un applicatif défini. Par conséquent, Kubernetes est un outil particulièrement adapté aux problématiques rencontrées. De plus, il fonctionne aussi avec des conteneurs Docker. Je n’ai pas eu à faire des adaptations au niveau des applications à déployer, ce qui m’aurait pris beaucoup plus de temps. Elles ont pu être directement migrées. La seule chose que j’ai eu à retravailler intégralement, c’est la méthode de déploiement des applications. Néanmoins, il existe une normalisation appelée HELM qui permet de réutiliser des configurations de déploiement sous forme de templates. Ça rend le travail plus efficace. Par exemple, j’ai pu utiliser la même configuration de déploiement pour un serveur web sous Apache2 ainsi que pour un serveur web utilisant Node. Le gain de temps a permis d’approfondir la partie sécurité des applications.
Afin que les applications répondent aux concepts d’intégration continue et de déploiement continu, j’ai créé des pipelines GitLab pour déployer ces applications sur le nouveau cluster Kubernetes. Un pipeline GitLab est un défini sous la forme d’un fichier de configuration à la racine d’un projet. Il permet d’exécuter une suite de tâches. De cette manière, les développeurs n’ont qu’à lancer le pipeline lors des mises en production et l’application se retrouve exécutée dans la bonne version sur le nouveau cluster. Le gain de temps est considérable pour un développeur, car un déploiement dans Kubernetes lorsque l’on ne maitrise pas la technologie peut être très compliqué. Il n’y a pas que l’application à déployer, il y a aussi sa configuration pour la rendre accessible à l’extérieur du cluster. Il y a son domaine à définir ainsi qu’un certificat propre à ce dernier pour sécuriser son accès. Toutes ces configurations font de Kubernetes une technologie particulièrement compliquée à utiliser pour la plupart des développeurs. On pourrait penser que c’est un frein pour l’adoption de la technologie Kubernetes, mais ça n’en est pas un. Les développeurs ont pour rôle de développer et l’administrateur SRE a pour objectif de limiter toutes les frictions qui les empêcheraient de développer. C’est à ce niveau que j’interviens en créant des pipelines GitLab pour qu’ils n’aient pas à intervenir directement sur le cluster. Ça permet de leur faire gagner du temps de développement sur les applications.
Mon autocritique
J’utilise Kubernetes quotidiennement depuis six mois. J’ai pu me former et m’exercer auprès d’une équipe d’experts Kubernetes pendant une immersion d’une semaine. J’ai aussi bénéficié de l’expertise des membres de l’équipe ayant déjà travaillé sur Kubernetes. Je pense donc arriver à un niveau intermédiaire. Cette compétence est obligatoire pour un administrateur SRE, car nous devons maitriser les concepts liés à la haute disponibilité des applicatifs et aux clusters. Par conséquent, il est normal que nous maitrisions la technologie Kubernetes qui est la plus utilisée pour répondre à ces concepts. Lors de la migration de certaines applications d’un cluster existant vers un cluster plus récent, j’ai rencontré des difficultés. La problématique se trouve lors de la définition des déploiements des applications sur les clusters Kubernetes. Nous définissons les déploiements dans des fichiers au format de données YAML et en utilisant la normalisation HELM qui définit l’architecture des fichiers YAML pour les déploiements. La manière de décrire les déploiements dans les fichiers d’une version de Kubernetes à une autre change complètement en fonction de sa version, ce qui rend les montées de version des clusters Kubernetes très douloureuses pour les équipes de SRE. Heureusement, il n’y a que les déploiements à redéfinir entièrement dans les fichiers HELM. Les applications se basant sur la technologie Docker ne sont pas à mettre à jour dans la quasi-totalité des cas. Pour faciliter l’adaptation des fichiers de configuration d’une version Kubernetes à une version plus récente, il faut avoir une maitrise avancée de plusieurs versions de Kubernetes. Pour être efficace et précise, l’acquisition de cette expertise devra passer par la passation des compétences d’administrateur SRE senior ayant une expertise approfondie en Kubernetes. Je devrais aussi approfondir mes compétences au niveau du format de normalisation HELM pour améliorer la maintenabilité des configurations Kubernetes. Dans les prochaines entreprises où je serai amenée à manipuler Kubernetes, je ferai très attention à ce qu’une équipe dédiée à la gestion du cluster soit formée et disponible. Car une seule personne ne peut pas administrer correctement un cluster intégrant autant d’outils et de concepts. Si l’utilisation de Kubernetes n’est pas possible, en raison d’un manque de personnel qualifié, ce qui peut arriver étant donné la pénurie d’administrateurs SRE dans le secteur professionnel. J’orienterai l’entreprise vers des solutions délocalisées où nous n’avons pas à gérer nous-mêmes l’administration du ou des clusters Kubernetes. Plusieurs solutions existent, comme AWS qui est fournie par Amazon ou encore Azure qui est proposée par Microsoft. Dans tous les cas, un niveau intermédiaire de maîtrise de Kubernetes est un prérequis pour un administrateur SRE en raison de sa forte popularité et de sa forte courbe d’adoption exponentielle au sein des entreprises.
Mon évolution dans cette compétence
Je commence à avoir vu toutes les notions autour de la technologie Mesos. Qui est une autre technologie de cluster. Il s’est fait succéder par Kubernetes, par conséquent, à moyen terme, je souhaite devenir autonome sur la gestion de cluster Kubernetes. Dans ce contexte, j’ai commencé à me former au sein de l’organisation du Ministère des Armées en réalisant une immersion d’une semaine au sein d’une équipe d’experts. J’ai aussi commencé à réaliser la migration de plusieurs outils du cluster Mesos vers un cluster Kubernetes. À l’avenir, je compte continuer à m’autoformer. J’ai prévu de participer à la formation « Black Belt » proposée par la société Enix. Le formateur est un des créateurs de la technologie Docker sur laquelle Kubernetes se base. De plus, plusieurs de mes collègues me l’ont particulièrement recommandé. Je pense que cette formation est par conséquent l’une des plus intéressantes et l’une des plus formatrices à suivre. Aujourd’hui, je compte continuer à approfondir cette compétence afin de répondre au mieux aux besoins des entreprises.