Étendre un cluster Incus OS : workers et nœuds distants

Un cluster Incus OS garde son quorum sur trois voters, mais rien n'empêche d'y greffer d'autres nœuds qui n'hébergent que des instances. Ces membres database-client ajoutent de la capacité de calcul sans peser sur la base de données, et peuvent vivre sur un site distant. Ce guide montre comment ajouter un worker, cibler le placement des instances (nœud précis, groupe), refléter la topologie avec les failure domains, et administrer un nœud éloigné. Public visé : administrateurs d'un cluster Incus OS qui veulent l'étendre au-delà de son noyau de trois nœuds.

Ce que vous allez apprendre

Pourquoi un worker rejoint le cluster en database-client.
Ajouter un membre hors quorum et le garder client.
Placer des instances sur un nœud précis ou un groupe.
Modéliser la topologie physique avec les failure domains.
Administrer un nœud distant via le réseau, et ses limites.

Prérequis

Un cluster Incus OS de trois nœuds sain. Voir rôles, quorum et haute disponibilité pour les rôles de base de données.
La procédure de jonction par seed décrite dans Incus OS sans interface.
Un client Incus de confiance avec un remote vers un membre (node1:).

Pourquoi un worker rejoint en database-client

Un cluster place ses rôles de base selon deux limites : 3 voters (cluster.max_voters) et 2 stand-by (cluster.max_standby). Une fois ces cinq emplacements pris, tout membre supplémentaire devient database-client : il ne réplique pas la base et ne vote pas, il se contente d'héberger des instances. C'est exactement ce qu'on veut pour un worker : de la capacité, pas de responsabilité sur le consensus.

Pour être certain qu'un nouveau nœud reste client et ne prenne pas un rôle de base, on met les stand-by à zéro avant de l'ajouter :

incus config set node1: cluster.max_standby 0

Après jonction, incus cluster list confirme le résultat : le worker apparaît sans rôle, la colonne des rôles est vide.

node1,database
node2,"database-leader,database"
node3,database
node4,

Ajouter le worker au cluster

Sur Incus OS, un nœud rejoint le cluster par seed, jamais par un shell. On émet un jeton de jonction depuis un membre existant, puis on provisionne le nouveau nœud avec un seed qui contient ce jeton, le certificat du cluster et la configuration de son pool local :

incus cluster add node1:node4

Le reste de la mécanique (image, seed incus.json avec le bloc cluster, certificat, member_config du pool) est identique à la jonction d'un nœud de base et se trouve dans le guide Incus OS sans interface. La seule différence pour un worker est le réglage max_standby posé avant la jonction. Une fois le premier boot passé, le nœud se met à jour tout seul vers la version du cluster et apparaît ONLINE, prêt à recevoir des instances.

Placer des instances sur un worker

Par défaut, Incus choisit le nœud d'accueil selon la charge. Pour forcer un placement, l'option --target désigne un membre précis :

incus launch images:debian/12 node1:app1 --target node4 -s local -n incusbr0

L'instance démarre sur le worker, ce que confirme la colonne d'emplacement :

| app1 | RUNNING | node4 |

Ce ciblage direct convient pour épingler une charge sur un nœud donné, par exemple un worker doté d'un matériel particulier ou situé sur un site précis.

Cibler un sous-ensemble avec les cluster groups

Épingler nœud par nœud devient vite pénible. Les cluster groups rassemblent des membres sous un nom logique, vers lequel on peut lancer des instances sans connaître le nœud exact. On crée un groupe, puis on y assigne des membres :

incus cluster group create node1:workers
incus cluster group assign node1:node4 default,workers

Un membre appartient toujours au groupe default et peut en cumuler d'autres. Pour lancer une instance sur le groupe, on préfixe le nom du groupe par @ dans --target :

incus launch images:debian/12 node1:calc1 --target @workers -s local -n incusbr0

Incus place alors l'instance sur un membre du groupe workers. C'est le mécanisme idéal pour réserver une famille de charges à une catégorie de nœuds : les workers, ceux qui ont un GPU, ou ceux d'un site donné.

Refléter la topologie avec les failure domains

Un failure domain (domaine de panne) indique à Incus quels membres partagent un risque commun (même baie, même site, même alimentation). Quand un membre de base tombe, Incus tente de réassigner son rôle à un autre membre du même domaine, ce qui évite de concentrer tous les voters au même endroit physique. Le domaine se règle en éditant la définition du membre :

incus cluster show node1:node4 | sed "s/^failure_domain:.*/failure_domain: siteB/" | incus cluster edit node1:node4

La lecture du membre confirme le changement :

failure_domain: siteB

En affectant des domaines cohérents avec la réalité physique, on aide le cluster à répartir intelligemment les rôles et les instances entre les emplacements, plutôt que de les empiler sur une seule zone de panne.

Le cas du nœud distant

Un worker peut se trouver sur un autre site. Deux points méritent l'attention. D'abord la connectivité : au premier boot, le nœud applique son seed de jonction et contacte le leader sur l'adresse indiquée. À cet instant, aucun service applicatif n'est encore monté, donc cette adresse doit être joignable au niveau de l'infrastructure (routage, VPN de site). Le service Tailscale intégré, lui, ne s'active qu'après le boot : il sert à administrer le nœud une fois en place, pas à porter la jonction initiale.

Une fois le worker en service, l'activer sur le tailnet le rend joignable par une adresse privée stable 100.x, ce qui est pratique pour piloter son API à distance sans exposer de port public. La marche à suivre est décrite dans le guide connecter les nœuds à Tailscale.

Dépannage

Symptôme	Cause probable	Solution
Le nouveau nœud prend un rôle `database`	`max_standby` non nul à la jonction	Fixer `cluster.max_standby 0` avant d'ajouter le worker
`--target @groupe` échoue	Groupe inexistant ou vide	Créer le groupe et y assigner au moins un membre
Le worker distant passe `OFFLINE` par intermittence	Latence supérieure à `offline_threshold`	Relever `cluster.offline_threshold`, vérifier le lien
Une instance ne peut pas migrer depuis le worker	Volume sur stockage local	Placer les données sur un stockage partagé

À retenir

Au-delà des 5 emplacements de base (3 voters + 2 stand-by), un membre devient database-client.
Mettre cluster.max_standby à 0 garantit qu'un nouveau nœud reste un worker pur.
On rejoint toujours par seed sur Incus OS ; seul le réglage max_standby distingue un worker.
--target <nœud> épingle une instance ; --target @<groupe> vise un cluster group.
Les failure domains reflètent la topologie physique et guident la répartition des rôles.
Un nœud distant a besoin d'une connectivité d'infrastructure pour joindre ; Tailscale sert à l'administration, pas à la jonction.

Prochaines étapes

Rôles, quorum et haute disponibilité Comprendre les rôles de base de données du cluster.

Connecter les nœuds à Tailscale Administrer un nœud distant par un tailnet mesh.

Stockage partagé CephFS Rendre les instances mobiles entre nœuds.

Incus OS sans interface La procédure de jonction par seed.