Architecture

Composition d’un cluster

Un cluster hepto est constitué :

• d’hôtes physiques, possédés par les contributeurs au cluster ;
• de noeuds du cluster, chaque noeud étant instancié sur un hôte physique ;
• d’une surcouche réseau, regroupant ces noeuds sur un même réseau privé virtuel (VPN) sécurisant les communications à suivre ;
• d’une surcouche orchestration, exploitant le CPU, la RAM et le stockage des noeuds pour y déployer des applications et rendre des services ;
• d’une surcouche de contribution, permettant le travail collaboratif sur les ressources du cluster, l’historisation des modifications, le déploiement contrinu, etc. ;
• d’outils pré-déployés, tels que les reverse proxy d’accès aux services, la gestion des certificats TLS, la supervision des ressources, la collecte et le traitement des journaux, etc.

Propriétés d’un cluster

Distribué

Il est distribué, c’est à dire que les ressources sont mises à disposition par des individus collaborant, mais pas nécessairement appartenant à la même association, entreprise, collectif, etc. Chaque contributeur peut par exemple disposer d’un hôte à son domicile, et décider de l’allouer pour partie à un noeud d’un premier cluster, pour partie à un noeud d’un autre cluster, et d’en conserver la maîtrise pour stocker ses documents personnels.

La distribution contribue à la sécurité, la vie privée, et au respect des libertés des individus.

Résilient

Il est résilient, c’est à dire qu’une application déployée et ses données ne sont pas gérées sur le noeud d’un unique contributeur. En cas de panne de courant, d’accès à Internet, de déménagement, ou simplement si le contributeur décide subitement de déconnecter son noeud, le cluster continue d’exister et les applications continuent de fonctoinner sur les autres noeuds.

La résilience n’est pas une propriété inhérente à la distribution. En particulier, pour assurer sa résilience, le cluster doit contre-balancer les difficultés imposées par la distirbution et la distance entre les noeuds. La résilience résulte ainsi de l’équilibre atteint entre disponibilité et cohérence des données.

Econome

Il est économe, c’est à dire qu’il peut reposer sur des machines à faible consommation, et que la somme des ressources peut approcher la somme des besoins des applications, au facteur de réplication près. Egalement, la configuration de l’orchestration tient compte de la topologie du cluster et du coût – financier et énergétique – des communications à travers Internet, pour les minimiser tant que possible.

Terminologie

Un hôte est une machine physique, il s’agit généralement d’un ordinateur personnel de récupération ou d’un micro-serveur. Il peut être utilisé pour contribuer à un ou plusieurs clusters hepto, voire servir en parallèle d’autres applications de son propriétaire.

Un noeud matérialise l’allocation de tout ou partie des ressources de l’hôte sur lequel il repose au profit d’un cluster hepto. Un noeud est concrètement constitué de deux programmes : la contribution à la surcouche réseau et la contribution à la surcouche orchestration.

Le cluster hepto est réalisé par l’ensemble des noeuds qui le constituent, il fournit les primitives réseau et d’orchestration aux applications qui y sont hébergées.

Dans le contexte de hepto, un pod peut techniquement faire référence à un pod Podman, technologie employée pour gérer les noeuds, ou bien un pod kubernetes, technologie employée pour la couche d’orchestration. Sauf précision, il s’agit d’un pod au sens kubernetes.

Un namespace représente un espace de nommage de la couche orchestration, il s’agit de l’unité d’allocation des ressources dans un environnement multi-utilisateurs.

Technologies

Les technologies suivantes sont celles actuellement employées dans le laboratoires hepto. Elles sont susceptibles d’évoluer régulièrement :

• les hôtes sont limités aux machines de l’architecture AMD64, avec au minimum 1Go de mémoire vive et 50Go de stockage ;
• les noeuds sont constitués par des pods Podman, eux-mêmes organisés en deux conteneurs, l’un pour la surcouche réseau, l’autre pour la surcouche orchestration ;
• la surcouche réseau est opérée par wesher, qui négocie et configure des VPN Wireguard en full-mesh entre tous les membres du cluster ;
• la surcouche orchestration est opérée par k3s, une version allégée de l’orchestration de conteneur kubernetes ;
• la surcouche contribution repose sur Git (par exemple un dépôt sur une instance Gitlab) et Flux, une solution de déploiement continu conforme aux principes GitOps.

Périmètres de responsabilités

Un cluster hepto est initié et géré généralement par un groupement, nommé responsable du cluster. Ce groupement dispose des privilèges d’administration du cluster au niveau de la surcouche d’orchestration et dispose de l’ensemble des clés de sécurité du cluster, y compris celles protégeant la surcouche réseau.

Un noeud hepto fait partie du cluster, et est donc sous la responsabilité du responsable du cluster, de même que l’ensemble des ressources qui y sont orchestrées, sauf délégation.

Un hôte abritant un noeud hepto est sous la responsable du propriétaire de l’équipement. Il peut s’agir de la même entité que le responsable du cluster, mais il peut également s’agir d’un individu ou d’un groupement tiers. Par exemple, des associations peuvent mettre à disposition chacune des hôtes pour héberger les noeuds d’un cluster hepto géré en fédération d’associations ; ou bien une association gérer un cluster hepto reposant pour une part sur des noeuds hébergés sur ses propres hôtes et sur des noeuds contribués par ses membes mais dont l’association n’est pas propriétaire.

Au sein d’un cluster hepto, le responsable du cluster peut décider de déléguer la gestion d’un ou plusieurs namespaces à des tiers. Dans ce cas, la convention de délégation précise les périmètres de responsabilité.