Connecter votre propre cluster

Vos environnements peuvent tourner sur un cluster à vous : une machine Linux neuve, dont l'installeur fait un cluster k3s, ou un cluster Kubernetes que vous avez déjà. Vous les pilotez toujours depuis la plateforme. Votre cluster se connecte à elle, toujours de lui vers elle et en HTTPS : rien n'est à ouvrir vers lui.

Ce qu'il vous faut

Pour un serveur nu : une machine Linux récente (2 CPU et 4 Go de mémoire ou plus), un accès root, et une sortie vers internet en HTTPS. L'installeur y met k3s, puis l'agent de la plateforme : la machine devient le premier nœud de votre cluster, et d'autres peuvent le rejoindre ensuite. Réservez-la à vos environnements : k3s prend les ports 80 et 443 pour les servir, et un site que la machine sert déjà ne recevrait plus ses visiteurs. L'installeur le vérifie avant de rien changer, et s'arrête en nommant ce qu'il a trouvé — un programme sur ces ports, un conteneur Docker, ou un autre Kubernetes. Une machine qui fait déjà tourner Kubernetes se connecte avec l'onglet Cluster Kubernetes existant.

Pour un cluster existant : un cluster que votre kubectl atteint, avec une classe de stockage et un contrôleur d'ingress. L'installeur ne touche qu'à ce qu'il pose, et reprend ce qui est déjà là (plus bas).

Dans les deux cas, la permission team.settings : c'est elle qui crée un cluster et affiche sa commande d'installation, depuis la page Clusters de l'équipe, bouton Connecter un cluster. La page se lit avec team.view.

Les choix à faire avant d'installer

La page pose ces questions avant de vous donner la commande, et la commande suit vos réponses. Trois d'entre elles ne se changent plus sans réinstaller :

• Les certificats HTTPS. Avec Let's Encrypt (recommandé), l'installeur pose cert-manager s'il n'y est pas déjà, et un émetteur : il faut une adresse e-mail, et que *.votre-domaine pointe vers le cluster. Sur un cluster qui a déjà son émetteur cert-manager, nommez-le : il n'est jamais modifié. Sans HTTPS, les environnements répondent en HTTP seulement.
• La base de données des environnements. Par défaut, un serveur PostgreSQL 18 installé avec l'agent. Ou votre propre PostgreSQL, en version 15 ou plus (18 pour recevoir des copies d'environnements de la plateforme), joignable depuis le cluster, avec un administrateur dédié : LOGIN CREATEROLE CREATEDB, jamais superutilisateur, avec pg_signal_backend. Son mot de passe est demandé au terminal : il n'apparaît jamais dans la commande.
• Le réseau des nœuds ajoutés plus tard (serveur nu). Des machines au même endroit, sur un réseau privé : rien à faire. Des machines dans d'autres lieux, qui se joignent par internet : choisissez WireGuard dès maintenant — un réseau chiffré, qui demande une adresse IP publique.

Deux autres se rattrapent en relançant l'installeur :

• Les serveurs de bases de l'équipe : CloudNativePG, pour créer et régler des serveurs PostgreSQL depuis la page du cluster, et leurs sauvegardes vers le stockage de l'équipe (le greffon Barman Cloud). Recommandés.
• La haute disponibilité (serveur nu) : une base etcd dès le départ, pour que d'autres nœuds du plan de contrôle rejoignent la machine. Sans elle, la page la met en place au premier nœud de contrôle ajouté.

Sur un serveur nu, la page demande aussi où vont les données des environnements : le disque de la machine, ou Longhorn pour des volumes répliqués entre les nœuds. Un environnement garde le stockage qu'il a eu à sa création.

Ce qui est déjà sur votre cluster

Inutile de savoir d'avance ce qui y est installé : l'installeur regarde avant d'installer, et son résumé le dit avant Continue? [y/N]. Ce qui est déjà là est repris tel quel, jamais réinstallé ni mis à jour — il sert peut-être d'autres applications chez vous : k3s, Longhorn, cert-manager et ses émetteurs, CloudNativePG et son greffon de sauvegarde, vos classes de stockage et d'ingress.

• cert-manager est reconnu là où il tourne, quel que soit son espace de noms. S'il n'en reste que les définitions, sans cert-manager en marche, l'installeur s'arrête avant tout changement. Avec Let's Encrypt, il ajoute son propre émetteur, rollbackk-letsencrypt, et liste les vôtres : pour utiliser l'un d'eux, choisissez sur la page Un émetteur cert-manager déjà présent.
• CloudNativePG n'est reprise que si elle peut faire tourner les serveurs de bases de l'équipe : son opérateur tourne, en version 1.27.1 ou plus, et surveille leur espace de noms, rollbackk-odoo-db. Sinon, elle reste telle quelle, et la page du cluster dit pourquoi les serveurs de bases sont désactivés, et quoi changer.
• Le greffon de sauvegarde Barman Cloud doit tourner à côté de l'opérateur de CloudNativePG, dans le même espace de noms. Ailleurs, les sauvegardes restent désactivées et la page le dit : elle ne propose jamais une sauvegarde qui ne partirait pas.
• Un cluster déjà connecté à la plateforme : sa propre commande le réinstalle, environnements compris. La commande d'un autre cluster y est refusée — si un collègue l'a déjà connecté, par exemple — et n'est pas consommée : réinstallez depuis la page du cluster déjà connecté, ou retirez-le d'abord de la plateforme.

Lancer la commande

La commande télécharge l'installeur, vérifie son empreinte SHA-256, puis le lance. Chaque étape ne part que si la précédente a réussi :

rm -f rollbackk-install.sh &&
curl -fsSL https://…/install.sh -o rollbackk-install.sh &&
echo "<empreinte>  rollbackk-install.sh" | sha256sum -c - &&
sudo sh rollbackk-install.sh --join <jeton> --letsencrypt-email [email protected]

Collez-la d'un bloc : sur la machine pour un serveur nu, là où votre kubectl atteint le cluster sinon. Si une étape échoue — un téléchargement refusé, une empreinte qui ne correspond pas (« FAILED ») — rien ne s'exécute. Ne lancez jamais un rollbackk-install.sh resté d'une fois précédente : ce n'est pas celui que la plateforme vient de publier.

Le jeton qu'elle contient est à usage unique et ne vaut que quelques minutes ; la page le montre une seule fois. Nouvelle commande en crée un autre, et la précédente cesse de fonctionner.

L'installeur vérifie d'abord la machine ou le cluster, puis résume ce qu'il va faire — stockage, ingress, base de données, certificats — et demande Continue? [y/N]. Relisez ce résumé : c'est le dernier moment pour changer d'avis, et rien n'est encore installé. Il demande aussi la classe de stockage ou d'ingress quand le cluster en a plusieurs. Une fois connecté, le cluster apparaît sur la page, qui dit ce qui reste à faire, par exemple faire pointer votre domaine.

Toutes les options de l'installeur

sh rollbackk-install.sh --help les liste, en anglais. Les voici, avec quand vous en servir.

Si le cluster ne se connecte pas

• Le téléchargement échoue (curl: (22)) ou l'empreinte ne correspond pas (« FAILED ») : rien n'a été lancé. Recommencez ; si cela persiste, demandez une nouvelle commande.
• La commande a expiré, ou elle a déjà servi : Nouvelle commande, sur la page.
• Le cluster ne sort sur internet que par un proxy : --https-proxy.
• Le résumé n'est pas celui attendu, par exemple « certificates: none: HTTP only » : répondez N. Rien n'est installé ; relancez avec les bonnes options.
• « ports 80 and 443 are not free on this machine » : un site ou un conteneur y répond déjà. Arrêtez-le ou déplacez-le, ou réservez une autre machine aux environnements. Rien n'a été changé.
• « this machine already runs Kubernetes » : connectez ce Kubernetes avec l'onglet Cluster Kubernetes existant, depuis un poste où son kubectl fonctionne.
• « already connected to the platform as the cluster … » : cette machine est déjà un cluster de la plateforme. La commande n'a pas servi ; le message dit quoi faire.
• « cert-manager's resource definitions are on this cluster, but cert-manager does not run » : démarrez ou réinstallez cert-manager, puis relancez la commande.
• L'installeur s'arrête sur un refus — une classe de stockage qui ne donne pas de volume, un émetteur introuvable : il dit pourquoi, et ce qu'il a changé. D'habitude, rien.

Réinstaller, ou retirer le cluster

Relancer l'installeur avec une nouvelle commande réinstalle l'agent : les environnements et leurs données restent, et ce qui était en place — classes, base de données — est repris. C'est aussi ainsi qu'on ajoute après coup le HTTPS ou les serveurs de bases de l'équipe.

Pour retirer le cluster, sa page donne la commande de désinstallation : garder les environnements, ou tout supprimer. Retirer le cluster de la plateforme ne touche pas ses machines.