Un orchestrateur pour les gouverner tous ?

Un orchestrateur pour les gouverner tous ?

150 150 Loick JONCOUR


Je ne vais pas vous faire 50 lignes sur les questions « pourquoi faire du micro service », ou «  pourquoi faire du container », je pars du principe que c’est quelque chose qui commence à être clair dans l’esprit de chacun (mais si vous ne comprenez pas encore bien leurs avantages et leurs impacts, voici quelques articles qui résument bien la situation : ici, la, ou encore ici ). 

 Je vais me concentrer sur les orchestrateurs docker et plus particulièrement sur Kubernetes.  

En effet lorsque l’on démarre avec docker, les premiers résultats arrivent très vite, un petit docker run avec l’image qui va bien et l’exposition des ports qu’il nous faut et comme par magie notre application tourne. 

Mais vous allez vite comprendre que docker à lui seul n’est pas une solution viable sur une production.
Vous avez besoin de plus de sécurité, de plus de souplesse, d’une micro-segmentation efficace, bref vous avez besoin d’un orchestrateur et, sans le savoir, vous voilà débarqués au milieu d’un champ de bataille sanglant.
Et l’enjeu de la bataille est de taille, dans un monde ou le container est d’ores et déjà incontournable et où les pronostics sur son évolution ne cessent de défrayer la chronique, « Qui deviendra la référence mondiale du container en
production ? ».  

D’un côté la solution « docker inc » avec docker swarm, d’un autre Kubernetes (Google/Cnfc), et au milieu, plusieurs autres acteurs qui commencent à développer leurs outils pour surfer sur la vague des containers avec ECS (AWS), Rancher, nomadmesos ect…

Les solutions pullulent et vous commencez à avoir la tête qui tourne. 

Mais en prenant un peu de recul, vous constaterez que depuis fin 2017, un gagnant commence à se profiler, Kubernetes! 

Quelques dates importantes pour illustrer la montée en puissance de Kubernetes:   

  • 16-19 octobre à la Dockercon Europe : Docker inc capitule et annonce l’intégration de Kubernetes a son produit. Swarm, son orchestrateur maison, ne sera plus le seul à être proposé avec Docker Enterprise Éditions. 
  • 20 novembre 2017 : Microsoft annonce la sortie d’un nouveau service sur son cloud, AKS (azure Kubernetes service), du Kubernetes asaservice. 
  • 29 Novembre 2017 au Re :invent : Aws rend les armes et annonce EKS, du Kubernetes as a service encore une fois, ECS son orchestrateur maison, ne sera plus le seul à être proposé en service manager. 

Vous l’aurez compris en 2 mois Kubernetes et sa communauté monstrueuse (plus de 48000 stars, 16000 Fork, 2000 contributors, 74000 commis sur leurs Git Hub) était devenue tellement incontournable, que tous leurs concurrents se sont vu obligés de l’intégrer dans leurs offres.  

 

Pour expliquer cet engouement revenons un peu sur l’histoire de Kubernetes: 

Kubernetes est un projet démarré en 2014, époque où le container ne fait pas encore sensation, excepté chez un des acteurs principaux du marché : Google. 

En effet Google fait du container depuis plus de 10 ans, et depuis 2003 leur system de container « Borg » fait tourner leurs workloads en production. 

Kubernetes est en quelque sorte la version ouverte de ce system, en effet la plupart de ces contributeurs principaux sont issus du projet Borg. Le nom original de Kubernetes en interne fut Projet Seven, en référence au personnage de Star Trek qui est un Borg devenu amical (les sept rayons de la barre du logo de Kubernetes sont un clin d’œil au nom original).  

Mais là où Borg était destiné à faire tourner les workloads Google, Kubernetes est un projet Open Source beaucoup plus ouvert et flexible (par ici pour plus d’infos ).  

Le 21 juillet 2015 sort la V 1.0 de Kubernetes, à côté de cela Google fait un partenariat avec la fonction Linux pour créer la Cloud Native Computing Fondation (CNCF) et leur fournit Kubernetes comme produit de base pour se développer (d’autres acteurs arrivent sur le projet tel que « AT&T, Box, Cisco, Cloud Foundry Fondation, Core Os, Docker, Ebay, Goldman Sachs, Huawei, IBM, Intel, Red Hat, Twitter, Vmware pour ne citer qu’eux. ».  

Le but de cette fondation ? Harmoniser les techniques de développements, de déploiements, et d’orchestration dans le cloud, en commençant par les containers (rien que ça). 

Nous touchons là à ce qui, selon moi, est le cœur de Kubernetes, l’abstraction, mais nous y reviendrons.  

Le 29 août 2018 Google se sépare de la propriété du projet Kubernetes pour le céder entièrement à la CNCF, en leur offrant 9 M$ sous forme de crédit Google Cloud pour couvrir les coûts de production associés (sachant que les tests effectués avant la sortie d’une release peuvent utiliser jusqu’à 150 000 conteneurs répartis sur 5 000 machines virtuelles). 

La communauté accueille cette marque de confiance avec beaucoup de satisfaction (Google continuant d’utiliser Kubernetes sur son cloud), preuve, pour eux, qu’ils sont devenus suffisamment matures sur le sujet pour continuer à imposer Kubernetes comme la nouvelle référence mondiale du container en production. 

 

Mais qu’est-ce qu’a Kubernetes de si intéressant ?  

Vous l’aurez compris dans son historique, Kubernetes vit pour la production, il a été bâti dans cet objectif et l’intègre dans le plus profond de son core. 

Pour passer sur les aspects purement techniques tels que les performances des containers, de Kubernetes lui-même et de son ouverture, je pense que le plus important est la standardisation des ressources système et réseau qui gravite autour de nos applications.

En effet les clouds se multiplient mais ne se ressemblent pas, on ne commande pas une EC2 (aws) comme on commanderait une GCE (google), les questions de dépendance sont donc au cœur des projets cloud. Quel service se permeton d’utiliser, que se passera-t-il demain si nous souhaitons changer de cloud provider  

Là où les containers pouvaient être un début de réponse, Kubernetes essaie de clore le débat. 

L’idée est de fournir une plateforme qui fait complètement abstraction de son infrastructure.  

Pour déployer une application sur Kubernetes, que son cluster soit sur AWS ou sur Google ou même en local, le processus de déploiement sera identique. Un développer qui déploie des workloads sur un cluster Kubernetes peut très bien ne pas savoir qu’il se trouve en réalité sur AWS, lui ne voit que des pods, des Persistent Volumes, des Ingress, etc… Notions absentes des différents clouds, mais qui font référence à des ressources de compute, de stockage, de réseaux, présentées sous diverses formes selon le cloud provider.  

Toujours dans l’idée de diminuer les dépendances, Kubernetes peut aussi utiliser un autre système de container que docker (tel que rocket, cri-o, etc…), toujours sans que cela n’impacte les développeurs. 

Cela change complètement la donne, grâce a cette standardisation, vous pourrez par exemple installer un soft en lançant une simple commande, avec l’assurance que votre installation (comprenant l’environnement système et réseau donc) sera conforme à ce que l’éditeur du soft avait en tête (voir cet exemple avec kafka ).
De même vos applications fonctionneront de la même manière d’un cluster Kubernetes à un autre, sans changer la moindre ligne de code et avec un minimum de modification à apporter à votre CI/CD..
 

Nb: vous pourrez aller voir ce que fait ibm sur le multi-clouds, ou ce que propose Google sur le cloud-hybrid.

Bref les notions d’abstraction de Kubernetes ouvrent le champ de possible et ils cherchent en permanence à aller plus loin (voir ce que développe Cloud Foundry sur le sujet).

Ok, mais Kubernetes c’est parfait alors ? 

Alors non, si la guerre entre les orchestrateurs a duré plusieurs années c’est bien parce que Kubernetes a ses faiblesses, l’une d’entre elles est aussi sa plus grande force, son abstraction.

En effet Kubernetes assume une abstraction riche et crédible, au risque de rendre la montée en compétence plus longue, même pour une personne familière avec les containers (aucune compatibilité avec la CLI Docker) il faudra se familiariser avec la CLI kubectl la CLI Helm, avec les templates YAML de chaque ressource et son architecture, complexe mais solide, qui demandera un bon niveau de maitrise pour le maintenir. 

Ensuite il y a le processus d’installation d’une plateforme qui est relativement long et lourd pour Kubernetes. En effet les instructions d’installations peuvent varier selon l’OS ou le cloud provider, il requiert aussi un certain nombre de configurations manuelles tel que l’ip de chaque node ainsi que son rôle (il faudra donc avoir défini l’archi du cluster avant de se lancer).  À noter que ce pointci tend à disparaitre dans les solutions managées comme EKS (AWS), au détriment de la maitrise de vos masters (voir Kubernetes, son architecture).  

Mais ces « faiblesses » sont bien peu de chose face à ses atouts majeurs. 

Je pourrais vous parler de son Scheduler, qui se chargera d’optimiser l’emplacement de vos pods sur le cluster;
Ou encore de ces automatisme tel que son système de “rolling update”, qui garantira des upgrades de vos pods avec 0 downtime;
De ces fonctions de self healing très efficace;
Ou encore de sa communauté et de tous les outils développés autour de lui (#OpenSourceFanBoy), qui le rendent un peu plus riche chaque jour.
Tous ces avantages, mis bout à bout, ont fait de lui le grand leader de l’orchestration de containers en production.

Voilà pour cette courte introduction à Kubernetes, je vais prochainement démarrer une série d’articles pour le prendre en main et présenter différents outils qui gravitent autour de lui, restez donc à l’affut des news sur https://gekko.fr/blog/ ! 

Laisser une réponse