Si vous travaillez dans un domaine proche du système, vous avez entendu parler de Kubernetes.
Si vous avez déployé une architecture Hadoop, Spark, ou des containers Docker, il est possible que vous connaissiez également Mesos, Yarn, Titus, ou Swarm.
Vous ne connaissez peut-être pas BOINC. BOINC n'est pas à proprement parler une technologie de gestion de clusters mais une plateforme pour réaliser du calcul distribué, ou Grid Computing, utilisée notamment par le projet SETI@home (Search for Extraterrestrial Intelligence). Cette plateforme permet de répartir une charge de calcul entre des volontaires, avec des principes de fonctionnement voisins, par bien des aspects, de ceux d'Hadoop ou d'autres plateformes logicielles de traitement asynchrone.
Clustering ou orchestration de containers ?
En théorie, un cluster est constitué d'un ensemble de noeuds dans les états sont synchronisés. C'est notamment l'architecture des clusters Oracle RAC (Real Application Cluster) qui respectent les critères de consistence des bases de données transactionnelles dites ACID.
En pratique, le théorème CAP, mais également des réflexions plus opérationnelles ont conduit la plupart des concepteurs de bases de données récentes à distribuer les données et la charge en s'affranchissant des contraintes ACID. On parle donc de clusters Hadoop, ou de cluster MongoDB ou Couchbase.
Cette notion de cluster renvoie donc à des questions d'intégrité des données qui n'ont pas nécessairement de sens lorsqu'il s'agit, par exemple, de lancer plusieurs instances d'un serveur NodeJS. Le terme d'orchestrateur de containers ou d'orchestrateur de charges de travail (workload) est donc plus approprié puisque certaines de ces technologies ne sont pas limitées ou destinées à gérer des containers.
Cette nuance entre cluster et orchestrateur est intéressante. Il est en effet nécessaire d'ajouter des fonctions à un orchestrateur pour construire un cluster. Le fait de relancer un container lorsqu'un container tombe ne suffit en effet pas à garantir l'intégrité des données.
Pour notre part, nous utilisons l'un ou l'autre terme sans trop y prêter attention dans la mesure où ces termes ne prêtent pas confusion.
La multiplicité des technologies d'orchestration de containers
Les exemples proposés précédemment illustrent le fait que, en matière d'informatique distribuée, que l'on appelle cela du clustering ou de l'orchestration de containers, il y a donc actuellement l'embarras du choix. Vous pouvez légitimement vous interroger sur le choix de l'outil qui conviendra le mieux à votre organisation.
Nous présentions, dans un précédent post, Openstack, qui est évidemment très loin d'avoir la popularité de Kubernetes et n'est pas positionné sur les mêmes besoins. Kubernetes est construit pour gérer des containers. Openstack est plus conçu pour gérer du matériel et des VMs. Il est sans doute possible de gérer des containers avec Openstack ou des machines physiques avec Kubernetes comme il est possible de fixer des vis avec un marteau ou de planter des clous avec le manche d'un tournevis. Planter des clous avec un tournevis demande, il est vrai, plus de dextérité que de fixer des vis avec un marteau :-).
Dans cette diversité des orchestrateurs, nous avons choisi de commencer par présenter par Kubernetes, non pas parce qu'il s'agit de la meilleure technologie mais parce que c'est la technologie actuellement la plus populaire sur le web. Kubernetes est pour le moment en bonne position pour être le "winner takes it all" et devenir le système d'exploitation distribué standard de fait, de par la position relativement hégémonique de son créateur, Google, sur le marché, et de par son positionnement comme orchestrateur généraliste, qui vient supplanter des projets publiés depuis plus longtemps comme Mesos, qui étaient initialement spécialisés sur le créneau des architectures big data. L'informatique a son star system. Il est difficile voir impossible de s'en affranchir!
Les différents plans pour comprendre Kubernetes
Il est possible d'envisager différents plans de compréhension de Kubernetes. Nous en proposons trois, qui se complètent et permettent d'isoler les problématiques :
- Le plan fonctionnel : un orchestrateur fournit des services, ou fonctionnalités, avec des spécifications fonctionnelles, des interfaces (GUI, shell, API) d'accès au service. Il est possible d'envisager Kubernetes sous cet angle. Lorsque l'on utilise une version cloud de Kubernetes, la compréhension peut suffire.
- Le plan conceptuel : les interfaces manipulent des concepts, tenant, pod, container, inventaire..., avec laquelle elles interagissent pour fournir le service demandé par l'utilisateur. C'est à ce niveau que se manifeste la vision et les choix des concepteurs de Kubernetes, c'est-à-dire ce qu'ils entendent par la notion d'orchestrateur, les cas d'usage qu'ils prévoient, le modèle logique dans lequel ils s'inscrivent.
- Le plan système : derrière les fonctions et les concepts, il y a une réalité, des serveurs, un réseau, des hyperviseurs, du stockage. Le modèle conceptuel est posé sur cette réalité et permet à l'utilisateur de s'en affranchir, au moins partiellement, en raisonnant sur des concepts adaptés à son métier, plutôt que sur une réalité plus granulaire et plus difficile à manier. Dans cette construction d'un récit (conceptuel et fonctionnel) à partir d'une réalité physique se réalise le travail des concepteurs du produit.
Nous présentons ces trois plans de manière plus détaillée dans le post suivant "Clustering : l'architecture de Kubernetes en trois plans".
