Kubernetes, la rolls des orchestrateurs de conteneurs

Il ne faut pas compter sur le nom de la solution pour expliciter son rôle si l'on n'est pas un helléniste distingué : en grec Kubernetes signifie "capitaine" ou "pilote".

On peut facilement glisser vers la métaphore du chef d'orchestre pour se rapprocher d'un terme beaucoup plus parlant en informatique : orchestrateur.

Et oui, K8s est un orchestrateur, et il orchestre quoi ? Des conteneurs.

Ces applications empaquetées avec leur serveur offrent une souplesse sans égal dans le monde du déploiement de microservices, mais lorsqu'il s'agit de les faire travailler les unes avec les autres, de s'assurer qu'elles tournent bien et qu'il y en est assez pour répondre à la charge, on a vite besoin de quelque chose qui supervise tout ça.

Kubernetes assure cette fonction : il prend en charge un florilège de conteneurs et s'assure de leurs interactions, disponibilité et mise à l'échelle.

Avec K8s on peut avoir un microservice en dotnet sous Windows Server, un autre en nodeJs sous Ubuntu, encore un autre sous Debian avec une stack Apache/Php etc.

Un conteneur est en panne ? Pas grave, Kubernetes en reconstruit un immédiatement. Pas assez de conteneurs pour tenir la charge ? K8s en crée 5 de plus à la volée.

De par leur caractère protéiforme, les environnements déployés et orchestrés par K8s sont donc la panacée des productions complexes et agiles.

Mais pas seulement des productions…

La problématique des environnements de recette et leur gestion avec Kubernetes

Une équipe de développement multi-projet peut rarement être spécialiste d'une seule technologie, elle exploite un spectre large de solutions et de langages pour répondre à des besoins parfois très différents. 

Nest, Nuxt, Next, Drupal, Magento, Python…, autant de technologies qui chacune implique son propre environnement d'exécution (runtime/serveur), sa propre chaîne de build et de déploiement. Et très vite, une foultitude de serveurs à maintenir, même si on tente d'en mutualiser un maximum.

Et à chaque nouveau projet, l'étape de setup : créer un sous-domaine puis le virtual host ad hoc voire un serveur dédié ensuite implémenter la chaîne de déploiement, tester et régler les sempiternels problèmes inhérents à un environnement tellement différent de celui des développeurs…

Bref beaucoup de temps et d'argent investis dans une unique problématique : la recette.

Chez Insign, nous avons déjà fait un premier pas en réglant une aberration : ces serveurs de recette fonctionnent et consomment de l'électricité 24/7 alors que ni les équipes internes ni mes clients n'iront les utiliser sur ce créneau horaire. Nous avons donc mis en place il y a quatre ans un système de gestion automatique de serveurs pour les démarrer et les éteindre automatiquement selon les heures de travail.

Reste l'étape de setup, toujours chronophage même si une bonne partie de l'intégration et du déploiement a été abstraite dans des modèles conteneurisés. La tentation de pousser la conteneurisation à son maximum, longtemps freinée par la complexité d'orchestrer un réseau, des load balancers et des conteneurs, est devenue réalité lorsque nous avons pu constater la puissance de Kubernetes. Nous avons donc franchi le pas, et au lieu de se limiter à la conteneurisation des scripts exécutés dans les chaînes d'intégration de nos repositories, nous sommes allés jusqu'à l'étape ultime : faire tourner les applications de recette dans des conteneurs.

Et pour cela il a fallu s'acculturer, comprendre la logique et la philosophie de K8s. Et notre premier cluster a vu le jour, nous permettant de déployer en un temps record tout type d'applications.

Dissection de notre cluster Kubernetes

Qu'y a-t-il dans cet écosystème capable d'ingérer une nouvelle application en quelques minutes, quel que soit le nombre de conteneurs et de microservices dont elle est composée ?

Nous avons opté pour une infrastructure cloud, Aws en l'espèce.

La colonne vertébrale du dispositif est composé de : 

• 1 domaine dont tous les sous-domaines pointent sur le load balancer d'entrée (cf. plus bas)

• 5 nodes minimum dont 2 qui ne tournent qu'en heures ouvrées, ce sont eux qui contiennent les composants et services kubernetes, le cœur de l'orchestration. C'est à l'intérieur de ces nodes que sont distribuées les pods. Ils se multiplient automatiquement pour une adaptation verticale à la charge.

• 1 load balancer pour assurer le routage des domaines sur les bons pods et pour porter le certificat ssl

• 1 registry docker pour stocker les images de conteneurs.

• 1 rôle dédié à notre bitbucket pour que les CI/CD puissent manipuler les ressources du cluster via une auth OIDC.

• 1 groupe d'utilisateurs Cognito pour protéger l'accès aux front offices (~ basic auth)

• Des pods Vault pour le stockage des secrets applicatifs (mot de passe, api token…).

• Des pods de Databases (Postgres, Mysql etc.)

En en termes d'outillage : 

• Eksctl pour la construction du cluster

• Kubectl pour la manipulation des ressources

• Helm pour les déploiements

Pour intégrer un nouveau projet et le voir apparaître comme par magie en tant que sous-domaine du domaine principal de recette, il nous suffit de : 

• Créer un nouveau repository

• Ajouter au code du projet notre bitbucket-pipelines.yml qui contient toutes les opérations Kubernetes nécessaires

• Ajouter au code du projet le répertoire de build/deploy correspondant à la techno utilisée

• Configurer les variables de repository (nom du sous-domaine, namespace k8s à utiliser etc.)

• Déclencher la CD

L’accompagnement Insign pour la mise en place de Kubernetes

Fort de notre expérience, nous accompagnons nos clients sur la mise en place et l'infogérance d'architectures Kubernetes de production reposant sur les principales solutions PaaS du marché (Aws, Open Redshift…).

Les gains à moyen terme sont considérables. Une plate-forme Kubernetes est beaucoup plus résistante aux pannes et aux variations de charge qu'une stack traditionnelle. De plus, elle facilite de façon incomparable les montées de version des applicatifs et le déploiement des patchs de sécurité.

Mais attention, il faut garder en tête que la courbe d'apprentissage peut être assez abrupte pour maîtriser les concepts et la mise en œuvre. Cela signifie qu'il est nécessaire de prévoir du temps et des ressources pour former les équipes sur les concepts de base de Kubernetes, la gestion des conteneurs, ainsi que les meilleures pratiques pour opérer et maintenir les applications dans un environnement Kubernetes. Cette formation est cruciale pour assurer une collaboration efficace et pour éviter les erreurs opérationnelles qui pourraient affecter la performance ou la sécurité des applications déployées.

En conclusion, quels sont les avantages de Kubernetes ?

À l'ère du microservice et de l'agilité, K8s est quasi un incontournable pour les organisations cherchant à déployer, gérer et faire évoluer leurs applications de manière efficace et cohérente. Kubernetes offre une orchestration automatisée, une gestion simplifiée des conteneurs, et une capacité de mise à l'échelle dynamique. Cela permet non seulement de supporter les architectures de microservices complexes, mais aussi de répondre rapidement aux besoins changeants du marché.

En outre, K8s contribue à la réduction et à la maîtrise des coûts en optimisant l'utilisation des ressources, en automatisant les tâches répétitives, et en permettant aux entreprises de mieux allouer leurs ressources selon la demande réelle. Sa capacité à améliorer la résilience et la portabilité des applications est également cruciale dans des environnements de production modernes, où l'efficacité et le contrôle des coûts sont des priorités.