Choix technologiques

L’architecture de hepto, simple en apparence, repose sur des choix de conception non triviaux, dont les principaux sont explicités à suivre.

Les ressources mises en commun dans le cadre d’un cluster sont :

• la puissance CPU ;
• la capacité mémoire ;
• la capacité de stockage ;
• la connectivité réseau ;
• l’espace d’adressage et de nommage.

Socle réseau et socle orchestration

Ces ressources sont principalement divisées entre les ressources réseau, à savoir la connectivité et la capacité de routage associée d’une part ; et les ressources d’orchestration – le reste – d’autre part.

Lors de la conception d’un cluster distribué géographiquement, il apparaît que la connectivité réseau est essentielle et associée à des propriétés encore peu systématisées dans le déploiement de clusters traditionnels, à commencer par la sécurité des communications internes au cluster.

Aussi, il apparaît que les deux types de ressources doivent être gérés par deux technologies distinctes bien que complémentaires. En résultent deux approches envisageables :

• soit disposer d’une connectivité réseau sécurisée entre les noeuds du cluster, sur la base de laquelle l’orchestration est construite ;
• soit construire une orchestration indépendamment des propriétés de sécurité réseau et déployer par dessus les outils pour sécuriser les communications au sein des applications.

La première approche est assez traditionnelle, orientée VPN (réseau privé virtuel, construit par dessus l’infrastructure réseau existante), tandis que la seconde s’inscrit dans la logique contemporaine du zero trust et correspond aux implémentations de type service mesh, ne postulant ni de la confiance dans l’infrastructure sous-jacente à l’orchestration, ni dans la confiance des applications entre elles au sein du cluster.

Les limites du zero-trust

L’approche zero-trust, non seulement par sa modernité, mais également par sa vision très conservatrice de la sécurité, est particulièrement séduisante pour construire un système moderne.

Les technologies associées sont largement regroupées sous la dénomination de service mesh, parmi lesquels Istio, linkerd ou bien Consul. A la marge, des orchestrateurs réseau pour kubernetes, tels que Cilium, offrent des propriétés de sécurité du trafic entre les applications du cluster.

Ces technologies ont un point commun principal : elles reposent pour leur fonctionnement sur des primitives supposées sécurisées, quelques-unes sur une infrastructure de gestion de clés, et toutes sur un orchestrateur, le plus souvent kubernetes (certaines supportent également Swarm ou Nomad).

Or, la sécurisation de la couche d’orchestration, en particulier à travers Internet sans disposer de réseau sécurisé sous-jacent, est une tâche délicate. Les guides de sécurisation existent, mais tous ne sont pas toujours applicables. Par exemple, k3s, une distribution de kubernetes allégée – aujourd’hui employée dans hepto –, ne supporte pas TLS sur les connexions du master vers les nodes kubernetes.

Pour ces raisons principalement, la mise en oeuvre de l’approche zero-trust pour hepto est repoussée à de futurs travaux.

VPN et mesh

Pour qu’une surcouche réseau à base de VPN soit efficace, il faut que le trafic circule entre les noeuds sans transiter par un noeud central. Il faut également que tous les noeuds puissent échanger avec tous les autres noeuds, et que chacun puisse disposer d’un espace d’adressage complet pour les applications hébergées.

Une telle infrastructure, dénommée VPN full-mesh, n’est pas triviale à mettre en place. C’est en reprenant et en étendant un logiciel existant, « wesher », que hepto parvient à gérer un VPN full-mesh entre l’ensemble des noeuds garantissant la confidentialité et l’intégrité du trafic échangé, et servant de base à la surcouche orchestration.

Orchestration

L’orchestration de déploiements répond généralement à l’une de deux écoles : le pilotage de la configuration des déploiements sur des hôtes qui gèrent ensuite l’exécution, ou bien le pilotage de l’exécution par des agents appliquant une configuration centrale.

La première école tient aux outils Puppet, Chef, SaltStack ou encore Ansible ; la seconde relève plutôt de solutions telles que OpenStack, kubernetes, ou Hashicorp Nomad.

Afin d’offrir un bon niveau de résilience malgré la défaillance probable de ses noeuds, un cluster hepto ne peut reposer sur une solution de pilotage de configuration, nécessitant soit une interaction manuelle, soit une intégration complexe avec les outils de supervision.

A l’inverse, les outils pilotant l’exécution reposent nativement sur la supervision de bonne exécution des applications et d’état des noeuds pour le placement automatique, le redémarrage, etc. Cette approche est plus à même d’assurer la résilience recherchée dans hepto.

Parmi les solutions fréquemment déployées, les distributions Kubernetes et Hashicorp Nomad répondent à l’objectif d’économies des ressources sur les noeuds. Kubernetes est retenu pour hepto pour la richesse de son écosystème.