Avant d’expliquer le terme « kubernetes », il convient de rappeler ce qu’est un conteneur. Un conteneur, c’est une application et toutes ses dépendances, livrées dans un format standard prêt à l’emploi, appelé image (suivant un standard lui-même appelé OCI 😉 pour Open Container Interface). Les conteneurs sont géniaux, car ils permettent de pouvoir faire fonctionner une application sur n’importe quelle infrastructure, à condition que celle-ci soit prête à accueillir ces conteneurs. Vous avez déjà surement entendu parler de cette technologie, qui a été popularisée par Docker.
Mais pourquoi utiliser des kubernetes, s'il y a déjà des conteneurs ?
Même lorsque l’on utilise des conteneurs, ceux-ci ne se concentrent que sur la partie « applicative », il reste des configurations à faire afin de rendre l’application accessible, sécurisée et sauvegardée. Ce sont les opérateurs DevOps qui brodent autour afin de réaliser ces configurations, souvent à partir d’autres logiciels. Cela rend le déploiement d’images de conteneurs spécifique à l’application que l’on cible. D’autant que ces conteneurs ne disposent pas non plus de fonctions intégrées de scalabilité, qui doivent également être gérées par l’opérateur.
Qu’à cela ne tienne, voici Kubernetes ! C’est ce qu’on appelle un orchestrateur de conteneurs. Son rôle principal est d’abord d’effacer le paradigme dit de « VM » pour se concentrer sur une vision en « cluster ». C’est-à-dire que l’on s’affranchit volontairement du matériel et de l’OS sous-jacent, pour créer des clusters Kubernetes pouvant combiner du matériel et du logiciel différent. Ce que fait Kubernetes, c’est une ribambelle d’APIs standardisées à l’utilisateurs, permettant d’interagir avec le moteur de conteneurs sous-jacent, (vous avez peut être déjà entendu parler de cri-o, containerd ? Ce sont des Container Runtime), et ce quelle que soit la nature des applications fonctionnant à l’intérieur.
Mais que font-ils d'autre ?
Kubernetes, aussi appelé Kube voire k8s, n’est pas une surcouche lourde. C’est une surcouche, un middleware supplémentaire qu’il faut appréhender, mais dont les retours sur investissement nous permettent d’accompagner nos clients dans la transformation de leurs applications historiques vers des versions dites « cloud-native » (comprendre, prête à fonctionner dans un environnement cloud, dont Kubernetes est une pierre angulaire).
Kubernetes s’occupe également de coordonner la partie réseau entre les conteneurs, vers et depuis l’extérieur ; d’automatiser la mise à disposition de stockage de manière dynamique, et de simplifier grandement des étapes telles que la génération d’un certificat SSL Let’s Encrypt, qui auparavant nécessitait une intervention humaine ou de la configuration.
Beaucoup de communautés insistent à dire que le seul intérêt de Kubernetes réside dans l’automatisation de la scalabilité des applications. C’est faux, cela fait partie des fonctionnalités proposées, mais pas uniquement. L’équipe DevOps chez Cloudéo à remarqué, que pour un déploiement d’application web, on gagne environ 1 demi-journée à 1 journée entière de production entre un déploiement « à l’ancienne » et un déploiement via Kubernetes.
Une expérience acquise sur le terrain auprès de nos clients !
Forts des retours d’expériences et connaissances acquises lors d’accompagnements avec nos clients, nous disposons dorénavant d’un bagage de recommandations, conseils, accompagnement, aide au déploiement, formation et bien entendu hébergement de ces clusters Kubernetes au sein de Cloudeo. Le fait d’avoir harmonisé les infrastructures autour de Kubernetes nous permet de gagner du temps lors du pré-audit de code, afin de savoir immédiatement quelles améliorations vous proposer.
La combinaison de l’expertise Kubernetes et de l’accompagnement DevOps de Cloudeo vous permet de disposer d’une chaîne complète d’action, vous garantissant de ne plus vous soucier des performances de vos applications, de vos sauvegardes, de vos déploiements et de votre hébergement.
