Kubernetes, en tant que plateforme d’orchestration de conteneurs, s’est imposée comme la solution de facto pour gérer des applications à grande échelle. Cependant, face à la multitude de distributions disponibles, chaque équipe IT se trouve confrontée au défi de sélectionner celle qui correspond le mieux à ses exigences techniques, opérationnelles et budgétaires.
Que votre projet nécessite une solution clé en main, une flexibilité maximale ou une intégration profonde avec l’écosystème existant, Matthieu Strohl, Lead Cloud, Référent technique Digital Foundation et référent Red Hat, vous apporte ses lumières pour éclairer vos décisions.
Pour commencer, pourrais-tu nous rappeler le principe de Kubernetes (K8S) et les raisons de son succès actuel ?
Kubernetes (ou K8S) est un orchestrateur de conteneurs. Pour rappel, ces derniers permettent de limiter au strict minimum les ressources nécessaires pour faire tourner des applications sur un système. Ce qui permet d’instancier avec efficience plus d’applications sur cette seule machine en comparaison avec d’autres approches (notamment celle utilisant des machines virtuelles ou VM).
K8S se propose d’orchestrer ces conteneurs et d’apporter de la résilience, de la continuité de service et de la flexibilité. Ainsi, les ressources consommées sont fortement réduites avec à la clé des gains financiers évidents. Et grâce à la couche d’abstraction apportée par K8S, il n’y a plus d’adhérence forte avec les infrastructures (y compris Cloud et celles des providers). C’est pourquoi l’utilisation d’orchestrateurs et des conteneurs rendu possible par l’Infra as Code (IaC) est aujourd’hui préférée aux VMs.
Quelles sont les différences majeures entre les distributions K8S ?
Il existe de nombreuses distributions de Kubernetes aujourd’hui, et logiquement toutes n’apportent pas les mêmes prestations. Voici 3 exemples :
- Kubernetes dans sa version Open Source n’embarque qu’un seul orchestrateur de conteneurs, c’est la version la plus basique et aussi la plus flexible. Elle peut gérer des fonctions comme la génération de certificats automatique, la génération de record DNS automatique, l’exposition vers l’extérieur, mais aucune n’est fournie par défaut.
- OpenShift de Red Hat embarque par défaut toutes les fonctions décrites juste avant, avec en plus des fonctions d’intégration continue, de déploiement continu (Bluegreen), de build d’application ou encore donnent la possibilité de faire du « source to image ». C’est l’une des versions les plus packagées actuellement.
- Talos Linux n’embarque pas de fonctionnalités particulières mais l’orchestrateur propose un CSOS (container-specific host OS), ce qui veut dire que le système d’exploitation est lui-même conteneurisé pour faciliter sa montée de version (on parle aussi « d’OS atomique» car il est découpé en une multitude de sous-éléments).
Comment choisir la version Kubernetes la plus adaptée à un contexte particulier ?
Les distributions se distinguent essentiellement par ce qui est embarqué autour de l’orchestrateur Kubernetes. Ainsi, une organisation qui utilise Kubernetes dans sa version Open Source doit disposer d’un bon niveau de maturité IT, et d’une équipe d’administrateurs et d’ingénieurs systèmes qui soient capables de parfaitement comprendre les mécanismes de la conteneurisation, et d’amener de la cohérence. Alors qu’avec la distribution OpenShift de Red Hat (par exemple) et son écosystème déjà fourni, une partie des choix techniques a déjà été fait en amont. L’autonomie nécessaire est alors moindre pour les équipes IT, et un support très performant est disponible.
Revers de la médaille, une telle distribution va avoir un certain coût en abonnement et en support. Qui plus est, elle est orientée pour utiliser une solution de stockage basée sur une solution détenue par Red Hat/IBM : Ceph. Comme Tanzu, la distribution K8S de VMWare, qui va orienter vers des solutions de stockage portées par la couche VMWare. Ou encore la distribution K8S Rancher orientée vers la solution de stockage Longhorn, de Rancher Labs. Cette approche « vendor lock-in » est donc à prendre en compte. Au moment du choix, il faut donc bien réfléchir en amont au contexte technique sur lequel va reposer l’infrastructure, en prenant en compte l’existant, la maturité et l’investissement.
Quels sont tes conseils pour migrer une infrastructure existante vers un orchestrateur de type Kubernetes ?
Avant de se lancer, je conseille d’imaginer le projet comme une recette de cuisine « j’ai tels ingrédients à disposition et quelle recette je peux faire avec ? ». Ici, il faut prendre en compte l’existant IT : le type de stockage disponible, les exigences de sécurité de l’entreprise, les solutions de métrologie et de supervision déjà utilisées… et quelle solution va me permettre de faire de l’orchestration de conteneurs en réutilisant un maximum de l’existant pour limiter le coût de migration. En fait, les défis et les interrogations sont un peu les mêmes qu’une migration vers le Cloud. Les orchestrateurs sont, pour moi, ni plus ni moins que des solutions de type Cloud privé, et concevoir l’intégralité de son catalogue de services dans du « kube » c’est être en capacité de fournir les mêmes services qu’un provider Cloud. Il faut donc se demander s’il est préférable de tordre encore une énième solution pour qu’elle rentre dans mes processus, mes approches et mon idée. Ou s’il est préférable de se remettre en question et adapter l’ensemble des processus et des méthodologies de mon organisation pour coller parfaitement au produit.
Comment Inside accompagne ses clients dans ce contexte ?
C’est un domaine qui ne se prête pas vraiment à un mode de distribution « sur étagères ». En revanche nous pouvons faire de l’accompagnement sur l’architecture à la fois technique et de solutions. Comme nous sommes agnostiques, tout dépend du contexte et du besoin client. Par exemple, si ce besoin représente la conteneurisation de 3 applicatifs et que ce client dispose de toutes les compétences en interne pour maintenir et gérer le déploiement, il n’aura pas besoin d’une solution type OpenShift ultra packagée avec beaucoup de couches d’abstraction. Autrement dit, notre accompagnement prend la forme d’une expertise technique sur le choix d’une solution, son implémentation et son maintien en condition opérationnel. Nous avons chez Inside une dynamique de certification bien marquée, et sommes ainsi certifiés CKA (Certified Kubernetes Administrator) qui montre notre compétence sur la version K8S Open Source, et donc notre polyvalence pour faire le pas vers n’importe quelle distribution Kube. Nous voulons également nous rapprocher de la CNCF (la Cloud Native Computing Foundation, qui porte entre autres les projets K8S et tout ce qui gravite autour) en se faisant reconnaître comme KCSP (Kubernetes Certified Service Provider). Nous évangélisons beaucoup cette approche car elle propose des avantages indéniables, et va dans le sens de l’histoire. Le landscape du CNCF ne laisse pas de doute là-dessus !
Vous souhaitez échanger avec nos experts autour de vos enjeux d’optimisation de votre SI et de K8S, c’est par ici !
