Former un cluster Incus à 3 nœuds — bootstrap, jonction et exploitation 2026

📍 Article principal du sujet : Incus 6 LTS — gérer conteneurs système et VMs Linux pour PME ouest-africaine
Pour la vue d’ensemble, lisez d’abord l’article principal qui pose le contexte d’Incus, ses concepts et son positionnement.

Un seul VPS, c’est pratique tant que l’hôte ne tombe pas. Le jour où il s’éteint, tous les conteneurs disparaissent avec — et pour une PME qui héberge ses propres outils ou ceux de ses clients, l’incident peut coûter une journée de chiffre d’affaires. La parade industrielle s’appelle cluster Incus : trois nœuds qui se connaissent, partagent leurs images, exécutent les instances là où il y a la place, et basculent automatiquement la charge en cas de panne. Ce tutoriel monte un cluster à trois nœuds depuis zéro, explique pourquoi le chiffre trois n’est pas négociable, et termine par les commandes d’exploitation au quotidien (mise à jour rolling, ajout d’un nœud, évacuation pour maintenance).

Le scénario réel pour cet article : trois Hostinger Cloud VPS à 4 Go de RAM, dans la même région, reliés par un réseau privé. Coût mensuel total : autour de 18 USD, soit environ 11 000 FCFA par mois pour une infrastructure résiliente capable d’héberger une cinquantaine de conteneurs avec haute disponibilité. À ce niveau de prix, plus aucune raison de servir une PME depuis un seul VPS.

Pourquoi exactement trois nœuds (et pas deux)

La règle vient du protocole Raft, l’algorithme de consensus qu’Incus utilise pour synchroniser sa base de données distribuée (Cowsql, dérivée de Dqlite). Raft exige une majorité de nœuds vivants pour valider une écriture — c’est ce qu’on appelle le quorum. Avec deux nœuds, la majorité c’est deux ; perdre un nœud paralyse le cluster (impossible de modifier quoi que ce soit). Avec trois nœuds, la majorité c’est deux ; on peut perdre un nœud et continuer à travailler.

Aller à cinq ou sept nœuds renforce la résilience (perdre deux ou trois nœuds reste tolérable) mais coûte plus en infrastructure et complique les mises à jour. Pour 95 % des cas PME, trois nœuds représentent l’optimum. Pour les déploiements ambitieux, on monte à cinq quand la charge dépasse la capacité de trois VPS confortables.

Prérequis

• Trois VPS Linux 64 bits, idéalement identiques en RAM/CPU/disque (4 Go RAM minimum chacun, 80 Go SSD)
• Ubuntu 24.04 LTS ou Debian 13 sur les trois
• Une connectivité TCP entre les trois sur les ports 8443 (API) et 8444 (cluster) — idéalement un réseau privé entre les VPS
• Hostnames résolvant correctement : incus1.example.com, incus2.example.com, incus3.example.com (DNS interne ou /etc/hosts partagé)
• Une horloge synchronisée par NTP sur les trois (différence < 100 ms)
• Niveau attendu : confortable avec Linux, SSH multi-serveurs, et le concept de cluster
• Temps estimé : 60 à 90 minutes pour le bootstrap complet

Pour reproduire ce scénario, Hostinger Cloud VPS permet de provisionner trois machines identiques en moins de cinq minutes via le panneau, en choisissant la même région (Europe par exemple) pour minimiser la latence inter-nœuds. Le réseau privé entre VPS, optionnel sur certains plans, est essentiel ici : il évite de payer le trafic inter-nœud sur la facture publique et offre des latences inférieures à une milliseconde au lieu de 5-10 ms en internet ouvert.

Étape 1 — Préparer chaque nœud individuellement

Sur les trois VPS, installez Incus selon la procédure standard (paquet natif sur Ubuntu 24.04+, dépôt Zabbly sur Ubuntu 22.04 ou Debian 12). À ce stade, ne lancez pas incus admin init tout de suite — l’initialisation du cluster est différente d’une installation simple.

# Sur chaque nœud, après installation du paquet
sudo apt install -y incus zfsutils-linux
sudo systemctl enable --now incus.service
incus --version
# 6.0.x

Avant de cluster, vérifiez la connectivité entre les trois nœuds. Depuis incus1, vous devez pouvoir ping incus2.example.com et ping incus3.example.com, et les ports 8443/8444 doivent pouvoir s’ouvrir mutuellement. Si vous travaillez sur un réseau privé Hostinger, les hostnames internes du panneau (typiquement vps-XXX.local) suffisent. Sur un environnement simple, l’ajout de quelques lignes dans /etc/hosts de chaque nœud règle le DNS sans dépendance externe.

# /etc/hosts sur chaque nœud
10.0.0.11 incus1
10.0.0.12 incus2
10.0.0.13 incus3

Synchronisez les horloges. Sur Ubuntu et Debian récents, systemd-timesyncd tourne déjà ; un timedatectl status doit montrer System clock synchronized: yes. Sur des installations minimalistes, sudo apt install -y chrony && sudo systemctl enable --now chrony assure une synchro fiable. Une dérive d’horloge supérieure à 500 ms entre nœuds peut faire échouer la jonction au cluster.

Étape 2 — Bootstrap du premier nœud

Le premier nœud du cluster lance la base de données distribuée et expose l’API. C’est lui qui définit la topologie initiale : nom du cluster, adresse de bind, certificat racine. La commande incus admin init en mode interactif gère tout cela, mais comme on veut reproductibilité, on passe par un fichier YAML.

# Sur incus1, créez un fichier preseed-bootstrap.yaml
cat <<'EOF' > /tmp/preseed-bootstrap.yaml
config:
  core.https_address: incus1:8443
  cluster.https_address: incus1:8443
storage_pools:
- config:
    size: 60GB
  description: ""
  name: default
  driver: zfs
networks:
- config:
    ipv4.address: 10.124.10.1/24
    ipv4.nat: "true"
    ipv6.address: none
  description: ""
  name: incusbr0
  type: bridge
profiles:
- config: {}
  description: Default Incus profile
  devices:
    eth0:
      name: eth0
      network: incusbr0
      type: nic
    root:
      path: /
      pool: default
      type: disk
  name: default
projects: []
cluster:
  server_name: incus1
  enabled: true
EOF

sudo incus admin init --preseed < /tmp/preseed-bootstrap.yaml

Quelques secondes plus tard, le premier nœud du cluster est prêt. Vérifiez avec incus cluster list :

incus cluster list
# +--------+----------------------+-----------------+--------+--------+
# | NAME   | URL                  | ROLES           | STATUS | MESSAGE|
# +--------+----------------------+-----------------+--------+--------+
# | incus1 | https://incus1:8443 | database-leader | ONLINE | Fully  |
# +--------+----------------------+-----------------+--------+--------+

Le rôle database-leader indique que ce nœud porte la base de données primaire. Une fois le cluster à trois nœuds, ce rôle pourra basculer si l’élection Raft le décide. Notez que le rôle est dynamique et ne lie pas à la prise de décision applicative : tout nœud peut servir l’API client.

Étape 3 — Générer le token de jonction pour incus2

Pour que le second nœud rejoigne le cluster, il faut un token à usage unique signé par le nœud bootstrap. La commande est simple, et le token doit être copié intact (il fait plusieurs centaines de caractères).

# Sur incus1
incus cluster add incus2
# Member incus2 join token:
# eyJzZXJ2ZXJfbmFtZSI6ImluY3VzMiIsImZpbmdlcnByaW50IjoiYWJjMTIz...

# Copiez ce token complet et conservez-le.

Le token contient le nom du nœud à ajouter, l’empreinte du certificat racine du cluster, l’adresse du leader et un secret partagé à usage unique. Sa durée de validité est limitée (configurable, par défaut quelques heures). Si le token expire avant l’usage, on le régénère sans conséquence côté cluster.

Étape 4 — Joindre incus2 au cluster

Sur incus2, on lance également incus admin init mais en mode join, en fournissant le token. Le YAML preseed pour la jonction est plus court que pour le bootstrap : on ne définit que ce qui change par rapport au cluster existant.

# Sur incus2
cat <<'EOF' > /tmp/preseed-join.yaml
cluster:
  enabled: true
  server_name: incus2
  server_address: incus2:8443
  cluster_token: COLLEZ_ICI_LE_TOKEN_OBTENU_DE_INCUS1
  member_config:
  - entity: storage-pool
    name: default
    key: source
    value: ""
  - entity: storage-pool
    name: default
    key: zfs.pool_name
    value: ""
EOF

sudo incus admin init --preseed < /tmp/preseed-join.yaml

Le bloc member_config permet de personnaliser les paramètres locaux du nœud (par exemple un nom de pool ZFS différent). Pour un setup homogène où tous les nœuds ont exactement les mêmes disques, on laisse les valeurs vides et chaque nœud reproduit la config du leader. La commande met une à deux minutes pour valider la jonction (génération de certificats, sync de la base, premier scrape).

De retour sur incus1, vérifiez :

incus cluster list
# +--------+---------------------+-----------------+--------+
# | NAME   | URL                 | ROLES           | STATUS |
# +--------+---------------------+-----------------+--------+
# | incus1 | https://incus1:8443 | database-leader | ONLINE |
# | incus2 | https://incus2:8443 | database        | ONLINE |
# +--------+---------------------+-----------------+--------+

Étape 5 — Joindre le troisième nœud

La procédure est identique : token généré sur incus1, preseed sur incus3.

# Sur incus1
incus cluster add incus3
# (récupérer le token)

# Sur incus3
sudo incus admin init --preseed < /tmp/preseed-join.yaml
# (avec le token de incus3 et server_name: incus3)

Une fois la jonction effectuée, le cluster est complet. incus cluster list doit montrer trois nœuds ONLINE, dont un avec le rôle database-leader et deux avec le rôle database. C’est cette configuration qui apporte le quorum Raft : tant que deux nœuds sur trois sont vivants, le cluster fonctionne.

Étape 6 — Lancer une instance dans le cluster

Du côté client, rien ne change apparemment : incus launch fonctionne comme avant. Mais derrière, l’algorithme de placement choisit automatiquement le nœud le moins chargé. On peut aussi imposer un nœud spécifique :

# Placement automatique (recommandé)
incus launch images:debian/12 web-srv

# Forcer un nœud précis
incus launch images:debian/12 db-srv --target incus2

# Voir où chaque instance tourne
incus list -c ns,t -L
# +---------+---------+--------+
# | NOM     | ÉTAT    | TARGET |
# +---------+---------+--------+
# | web-srv | RUNNING | incus3 |
# | db-srv  | RUNNING | incus2 |
# +---------+---------+--------+

Pour les conteneurs, le placement est statique : une instance créée sur un nœud y reste tant qu’on ne la migre pas explicitement (incus move web-srv --target incus1). Pour les VMs, la live migration est possible : déplacement à chaud sans interruption tant que les pools sont compatibles entre nœuds. La commande devient alors un outil d’équilibrage à chaud, utilisable même en pleine journée de production.

Étape 7 — Évacuer un nœud pour maintenance

Le scénario classique en production : un nœud doit redémarrer pour une mise à jour kernel, ou un problème matériel impose une intervention. La commande incus cluster evacuate déplace toutes les instances actives vers les autres nœuds.

# Évacuer incus2 (mise à jour à venir)
incus cluster evacuate incus2
# Toutes les instances de incus2 sont déplacées vers incus1 ou incus3.
# incus2 passe à l'état EVACUATED.

# Faire la maintenance
sudo apt update && sudo apt upgrade -y
sudo reboot

# Réintégrer incus2 dans le cluster après reboot
incus cluster restore incus2

Pour les conteneurs, évacuer signifie arrêter sur le nœud source et redémarrer sur le nœud cible ; il y a donc une coupure de quelques secondes par instance. Pour les VMs marquées migration.live: true, l’évacuation est sans coupure visible. Les instances reviennent automatiquement sur leur nœud d’origine après cluster restore, sauf si on configure une politique de placement permanente.

Étape 8 — Mises à jour rolling du cluster

La mise à jour d’Incus dans un cluster se fait nœud par nœud, sans coupure de service global. La séquence prudente : évacuer le nœud, mettre à jour le paquet, redémarrer le service, réintégrer, et passer au suivant.

# Pour chaque nœud, dans l'ordre :
incus cluster evacuate <node>
ssh <node>
sudo apt update && sudo apt upgrade -y incus
sudo systemctl restart incus.service
exit
incus cluster restore <node>
# Vérifier l'état avant de passer au suivant
incus cluster list

La règle de compatibilité : tous les nœuds d’un cluster doivent tourner la même version mineure d’Incus pendant les opérations de routine. Une différence transitoire le temps d’un upgrade rolling est tolérée par le projet, mais ne doit pas durer plus de quelques heures.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Une infrastructure cluster à 3 nœuds chez un hébergeur classique européen pose un problème de latence pour les utilisateurs ouest-africains : 150 à 250 ms de RTT vers Frankfurt ou Paris. Pour une PME qui sert une clientèle locale, ce n’est plus négligeable. Trois solutions possibles : (1) accepter la latence et compenser par un CDN devant (Cloudflare ou Bunny), ce qui marche très bien pour les sites web ; (2) viser un datacenter avec présence en Afrique ; (3) déployer un cluster dans une région européenne tout en faisant tourner un cache local sur un VPS à Dakar ou Abidjan.

Pour le coût, trois VPS Hostinger à 4 Go de RAM tournent autour de 18 USD par mois en facturation triennale, soit moins de 11 000 FCFA. À comparer aux 25 000 à 40 000 FCFA mensuels d’un seul serveur dédié 16 Go chez un hébergeur africain. Le ratio résilience/coût penche très clairement en faveur du cluster VPS, sauf cas d’usage avec contraintes réglementaires de souveraineté locale.

Pour une agence de Cotonou qui doit garantir un SLA de disponibilité à ses clients, le cluster Incus à trois nœuds Hostinger répond à un cahier des charges qui impose 99,9 % d’uptime annuel — soit moins de 9 heures de coupure tolérées par an, ce qui n’est atteignable qu’avec une redondance multi-nœuds.

Tutoriels frères

• Héberger 100 conteneurs Incus sur un seul VPS — la version mono-nœud densifiée.
• Live migration de VMs entre nœuds — pour les déplacements à chaud sans coupure.
• Backup complet d’un cluster — pour la stratégie de reprise après désastre.

Pour aller plus loin

• 🔝 Retour à l’article principal sur Incus
• Documentation officielle du clustering Incus
• Présentation de l’algorithme Raft (utile pour comprendre le quorum)
• Pour pratiquer : trois Hostinger Cloud VPS dans la même région avec réseau privé activé.

FAQ

Peut-on avoir un cluster à 2 nœuds avec un arbitre ?
Pas directement avec Incus, contrairement à certains autres orchestrateurs. La voie supportée est trois nœuds complets. Pour des budgets très contraints, un troisième nœud minimaliste (1 Go RAM, sans charge applicative) suffit pour le quorum.

Le cluster supporte-t-il la perte du leader ?
Oui — l’élection Raft choisit un nouveau leader parmi les membres restants en quelques secondes. Les opérations en cours peuvent voir une latence transitoire mais ne sont pas perdues.

Stockage partagé Ceph est-il obligatoire pour la haute disponibilité ?
Non. Avec des pools locaux par nœud, les conteneurs vivent sur leur nœud d’origine et y reviennent après reboot. Pour une vraie haute dispo avec failover transparent des VMs, Ceph RBD apporte un disque réseau partagé que tous les nœuds voient — c’est l’étape suivante naturelle.

Comment scaler au-delà de trois nœuds ?
incus cluster add <new-node> autant de fois que nécessaire. Cinq ou sept nœuds donnent une meilleure tolérance, mais alourdissent la coordination Raft. Au-delà de neuf, on segmente en plusieurs clusters distincts.

Le cluster fonctionne-t-il à travers internet (multi-régions) ?
Techniquement oui, mais la latence inter-nœuds dégrade fortement les performances de la base distribuée Cowsql. Recommandation officielle : nœuds dans la même région, latence inter-nœuds inférieure à 50 ms.