Déploiement du cluster

Le guide de cette page s’applique aussi bien au déploiement d’un cluster complet qu’à la configuration d’un ou plusieurs noeuds sur un cluster existant.

Présentation des composants

Un cluster hepto est composé de noeuds hepto (dont un noeud master), déployés sur des machines GNU/Linux. Chaque noeud hepto est déployé sous forme d’un pod Podman, et lui-même composé de :

  • un conteneur wesher, chargé de connecter le noeud au réseau du cluster ;
  • un conteneur k3s, chargé d’orchestrer les déploiements.

L’ensemble des composants est déployé par Ansible, compatible avec les principales distributions GNU/Linux (Debian, Ubuntu, CentOS).

Une même machine GNU/Linux peut héberger un noeud hepto et d’autres services, ou bien plusieurs noeuds hepto, en fonction des ressources dont elle dispose.

Pré-requis

L’organisation

Tout le cluster n’est pas nécessairement hébergé par une seule personne. Les machines ne sont pas nécessairement dédiées à hepto. En outre, le modèle de sécurité de hepto n’empêche pas l’administrateur d’une machine hébergeant un noeud d’accéder aux données de ce noeud, ni à l’administrateur d’un noeud d’accéder potentiellement à d’autres ressources de la machine. Cette réalité rend nécessaire la définition d’une organisation autour du cluster.

Les principaux aspects à couvrir sont :

  • quelles sont les conditions pour prétendre héberger un noeud ?
  • quelles sont les conditions pour accéder au cluster ?
  • à qui appartiennent les machines hébergeant les noeuds ?
  • qui doit gérer les machines hébergeant les noeuds ?
  • quels droits ont les administrateurs du cluster sur les machines hébergeant les noeuds et le réseau associé ?
  • quels droits ont les administrateurs des machines hébergeant les noeuds sur le cluster lui-même ?

Une fois ces aspects couverts et si l’organisation le nécessite, il est recommandé de mettre en place une convention entre les personnes hébergeant les noeuds et les personnes gérant le cluster mentionnant les engagements de chaque partie.

Les machines

Chaque machine hébergeant un noeud hepto doit disposer d’un système d’exploitation GNU/Linux. Les distributions supportées à ce jour sont :

  • Debian 10 (buster)
  • Debian 11 (bullseye)
  • Mint 19
  • Mint 20
  • CentOS 7
  • CentOS 8

Chaque machine doit disposer d’un accès à Internet, mais pas nécessairement d’une adresse IP publique. Il est donc possible de configurer les machines en DHCP sur une passerelle de fournisseur d’accès.

Le stockage

Sur chaque machine, hepto est installé par défaut dans /srv. Il est conseillé soit d’installer l’OS de la machine sans partitionnement spécifique, soit d’aménager une partition spécifique pour /srv. Hepto utilise environ 4Go de stockage par défaut et peut employer autant de stockage que d’images de conteneurs sont déployées sur les noeuds hébergés.

Les données des applications déployées sont stockées dans un ou plusieurs répertoires de données configurables. Il est conseillé de disposer au minimum de 500Go d’espace disponible sur disque rotatif, des installations plus abouties pouvant bénéficier d’une combinaison de SSD et de disque rotatif.

Pour un déploiement simplifié, hepto configure par défaut un stockage de données dans /srv avec les données de gestion du cluster.

L’accès réseau

Le noeud hepto doit disposer d’un accès à Internet, avec au minimum une adresse IPv6 publique. Il est conseillé de disposer également d’une adresse IPv4 même si elle n’est pas publiquement routable afin que le noeud puisse accéder à des services non compatibles IPv6.

S’agissant du filtrage, il est préférable qu’aucun filtrage ne soit appliqué sur l’adresse IPv6 publique du noeud. A défaut, il est nécessaire que le trafic wesher au minimum soit autorisé entre les noeuds.

Par défaut et par précaution, hepto configure les interfaces des noeuds en ipvlan. Cette approche permet à des noeuds d’être exécutés sur des interfaces WiFi ou autres interfaces où l’usurpation MAC n’est pas possible. Il est toutefois possible de forcer un mode macvlan si l’interface de la machine est une carte Ethernet et que vous souhaitez employer la couche MAC sur vos noeuds : nécessaire par exemple pour les load balancers fonctionnant au niveau ARP tels que metallb.

Hepto est très dépendant du MTU en raison des couches d’encapsulation réseau. Par précaution, la configuration par défaut suppose que le MTU entre chaque paire de noeuds du cluster est supérieur à 1400. Vous pouvez mesurer le MTU réel entre chaque paire de noeuds du cluster, afin soit de l’ajuster à la baisse pour permettre le bon fonctionnement, soit de l’ajuster à la hausse pour améliorer marginalement les performances réseau.

Avant l’installation, il est ainsi important de réunir les informations suivantes sur chaque machine et pour chaque noeud :

  • l’adresse IPv6 publique du noeud (et le préfixe associé) ;
  • l’adresse de la passerelle IPv6 pour le noeud ;
  • l’adresse IPv4 du noeud (et le préfixe associé) ;
  • l’adresse de la passerelle IPv4 pour le noeud ;
  • le nom de l’interface réseau sur la machine ;
  • le mode réseau s’il est spécifique ;
  • le MTU minimal entre les paires de noeuds.

Les ancres

Le socle réseau de hepto repose sur un VPN mesh géré par wesher. La découverte de la configuration du mesh nécessite que chaque noeud dispose des adresses stables de noeuds existants : des ancres.

Il est recommandé de disposer d’au moins deux ancres au sein d’un cluster, qui peuvent être des noeuds à part entière, chaque ancre connaissant l’adresse de l’autre et tous les autres noeuds du cluster connaissant l’adresse des deux ancres. Un modèle similaire peut être construit avec un nombre quelconque d’ancres : quel que soit le nombre retenu, il est primordial qu’au moins une ancre soit toujours en ligne de sorte qu’un nouveau noeud ou un noeud redémarré puisse rejoindre correctement le cluster.

Le nommage

Chaque noeud dispose d’un nom unique dans le cluster. Le nom des machines sur lesquelles les noeuds sont exécutés n’importe pas, mais le nommage des noeuds eux-mêmes est primordial pour faciliter la gestion du cluster par la suite.

Il est ainsi recommandé d’établir une convention de nommage propre au cluster, d’où peuvent être déclinés au moins autant de noms que de noeuds du cluster et limitant la confusion entre les noms de noeuds.

Par exemples, les conventions de nommage suivantes sont valides : nom des planètes du système solaire, nom des planètes dans Star Wars, nom des sept nains, nom des reines du Père-Noël, nom des personnages des Simpson.

Une fois la convention du nommage établie, choisisez un nom pour chacun des noeuds. Un nom de maximum 10 caractères est recommandé pour faciliter l’administration par la suite.

Les clés

La sécurité de l’infrastructure de chaque cluster hepto repose sur deux clés distinctes :

  • la clé dite d’overlay sécurise le VPN mesh en authentifiant entre elles les instances de wesher (il ne s’agit pas de la clé de protection du trafic, gérée automatiquement par wesher et propre à chaque noeud) ;
  • la clé dite du cluster sécurise l’accès initial des noeuds k3s au master.

Chacune de ces clés est de longueur 32 octets et doit être générée avec soin et indépendamment.

Pour les transmettre aisément et sans affaiblir significativement la sécurité, nous recommandons de les générer à base de lettres minuscules et majuscules et de chiffres, grâce à un générateur de mots de passe aléatoires.

Ansible

Ansible est employé pour déployer le cluster, il doit donc être installé sur les postes d’administration servant au déploiement.

Pour installer Ansible, suivez la documentation officielle.

La collection Ansible containers.podman est nécessaire pour l’utilisation du Playbook Ansible :

ansible-galaxy collection install containers.podman

Configuration et déploiement

Résumé des pré-requis

A ce stade, vous devez disposer :

  • d’une description dun cluster que vous souhaitez déployer ;
  • d’une ou plusieurs machines accueillant les noeuds ;
  • d’une liste de noeuds à déployer et leur nommage ;
  • d’adresses IPv6 et IPv4 et les passerelles pour chaque noeud.

Préparer le fichier d’inventaire

Le fichier d’inventaire est un fichier ini, il est composé de deux sections : l’une décrit le contenu du cluster, l’autre les variables globales.

Pour chaque noeud du cluster, la ligne de configuration est définie comme suit :

nodename ansible_host=1.2.3.4 iface=ens1 ip=2001:1234::1/64,192.168.123.123/24 gw=2001:1234::ffff,192.168.123.254

En particulier :

  • nodename est remplacé par le nom choisi pour le noeud ;
  • ansible_host=1.2.3.4, 1.2.3.4 est remplacé par l’adresse IP (v4 ou v6) de la machine accueillant le noeud ;
  • iface=ens1, ens1 est remplacé par le nom de l’interface réseau principale de la machine accueillant le noeud ;
  • ip= est suivi d’une liste d’adresses IPv4 et IPv6 avec configuration de préfixe, chaque adresse sera assignée au noeud ;
  • gw= est suivi d’une liste de passerelles IPv4 et IPv6 pour que le noeud accède à Internet.

Il est possible de rajouter des paramètres optionnels, tels que network_mode=macvlan pour forcer le mode macvlan par exemple.

La liste des variables est construite comme suit :

ansible_user=root # utilisateur pour la connexion SSH aux machines
storage_base=/srv # emplacement de stockage pour les données de base du noeud (sera suivi du nom du noeud)
anchors=["2001:2345::1","..."] # liste des ancres du cluster
master=nodename # nom du noeud master du cluster
mtu=1400 # MTU convenu pour le cluster
overlay_key=SECRETKEY # clé d'overlay de 32 caractères aléatoires
cluster_key=SECRETKEY # clé du cluster de 32 caractères aléatoires

Le fichier d’inventaire consolidé est défini comme suit :

[cluster]
nodename ansible_host=1.2.3.4 iface=ens1 ip=2001:1234::1/64,192.168.123.123/24 gw=2001:1234::ffff,192.168.123.254

[cluster:vars]
ansible_user=root # utilisateur pour la connexion SSH aux machines
storage_base=/srv # emplacement de stockage pour les données de base du noeud (sera suivi du nom du noeud)
anchors=["2001:2345::1","..."] # liste des ancres du cluster
master=nodename # nom du noeud master du cluster
mtu=1400 # MTU convenu pour le cluster
overlay_key=SECRETKEY # clé d'overlay de 32 caractères aléatoires
cluster_key=SECRETKEY # clé du cluster de 32 caractères aléatoires

Cloner le playbook Ansible

La configuration Ansible de déploiement est définie dans le dépôt Git de Hepto.

Clôner le dépôt :

git clone https://forge.tedomum.net/acides/hepto/ansible.git
cd ansible

Exécuter le déploiement

Exécuter le playbook permet de déployer l’ensemble des composants de Hepto selon la configuration définie dans l’inventaire.

cd ansible
ansible-playbook -i path/to/inventory.ini site.yaml

Si vous souhaitez déployer un unique noeud nodename :

cd ansible
ansible-playbook -i path/to/inventory.ini -l nodename site.yaml
Dernière modification January 1, 0001