Orchestrateur Canonical MicroCloud

Proxmox sur ARM a toujours été un projet « ferme les yeux et espère que ça marche ». MicroCloud de Canonical s’est présenté comme une alternative native de Pi qui orchestre les VM, les conteneurs et le stockage sans les correctifs manuels compliqués. Cela laisse un vrai choix pour un cluster maison sur du matériel Raspberry Pi, et le choix n’est plus seulement entre Docker sur un Pi et abandonner complètement.

Nous avons exécuté sept outils d’orchestration sur un mélange de Pi 4, Pi 5 et Radxa Rock 5B. Chaque option ci-dessous s’installe sur ARM sans correctifs du noyau, se regroupe proprement sur au moins trois nœuds et survit à une coupure d’électricité. Les différences résident dans la forme de la charge de travail : conteneurs uniquement, VM et conteneurs, une seule version de Kubernetes, ou un ordonnanceur de service plus léger.

Ce qu’il faut rechercher dans un orchestrateur de cluster Pi

Comparaison rapide

Application Meilleur pour Plates-formes Plan gratuit Prix de départ/mois Licence
MicroCloud Le cluster de bout en bout Linux (ARM, x86) Application complète Gratuit AGPLv3
K3s Kubernetes sur nœuds basse consommation Linux (ARM, x86) Application complète Gratuit Apache 2.0
Incus Conteneurs plus VM, sans K8s Linux (ARM, x86) Application complète Gratuit Apache 2.0
MicroK8s Variante Kubernetes gérée Linux (ARM, x86) Application complète Gratuit (avec support payant) Apache 2.0
Portainer Couche UI pour Docker/K8s Linux, Windows, macOS Community edition ~0,30 $/nœud/mois (Business) Freemium
Docker Swarm Clustering simple de conteneurs Linux (ARM, x86) Application complète Gratuit Apache 2.0
Nomad Charges de travail non conteneurisées aussi Linux (ARM, x86) Community edition Gratuit BSL 1.1

Les applications

1. MicroCloud, meilleur cluster de bout en bout

MicroCloud coud MicroOVN, MicroCeph et Incus dans un seul cluster d’opinion. Trois commandes transforment un sac de Pi en un cloud maison avec stockage distribué, réseau défini par logiciel et un mélange de VM et de conteneurs système. Sur un Pi 5 neuf, il se lève en moins de vingt minutes ; la documentation suppose ARM dès le départ.

Où cela fait défaut : nécessite Ubuntu Server sur chaque nœud ; si votre ménage utilise Debian ou Raspberry Pi OS, c’est un changement. La récupération d’une défaillance de deux nœuds nécessite toujours de lire la documentation.

Tarification :

Plates-formes : Linux (Ubuntu sur ARM et x86).

Télécharger : canonical.com/microcloud · GitHub

Conclusion : La raison pour laquelle cet article a été écrit. Le premier outil de cluster Pi qui traite ARM comme une cible de première classe et couvre le stockage, la mise en réseau et la gestion des charges de travail en un seul endroit.

2. K3s, meilleur pour un Kubernetes léger

K3s est une distribution Kubernetes certifiée empaquetée en un seul binaire de moins de 100 Mo. Il s’exécute confortablement sur un Pi 4 Go et associe les nouveaux nœuds avec un jeton et un installateur canalisé curl. Si la charge de travail est déjà des conteneurs plus des graphiques Helm, K3s est le chemin le plus court vers un vrai cluster.

Où cela fait défaut : c’est toujours Kubernetes, donc le modèle mental qui l’accompagne reste avec lui. Il y a une limite à la distance que vous pouvez l’abstraire.

Tarification :

Plates-formes : Linux (ARM, x86), Docker.

Télécharger : k3s.io · GitHub

Conclusion : Le choix par défaut lorsque la cible de déploiement ailleurs est aussi Kubernetes.

3. Incus, meilleur pour les conteneurs plus les VM sans Kubernetes

Incus est le fork LXD géré par le projet Linux Containers. Il exécute des conteneurs système (un Debian complet, pas un seul processus) et des VM complètes à partir d’une seule CLI, et son clustering est simple : incus cluster add et c’est fait. Sur un Pi 5 avec 8 Go, il exécute joyeusement quelques conteneurs Debian et une VM Windows 11 ARM en même temps.

Où cela fait défaut : pas de tableau de bord intégré ; l’UI communautaire est correcte mais n’est pas livrée dans la boîte. Le choix du pilote de stockage sur ARM compte plus que ce que la documentation le permet.

Tarification :

Plates-formes : Linux (ARM, x86).

Télécharger : linuxcontainers.org/incus · GitHub

Conclusion : Le meilleur choix quand votre charge de travail est un mélange et que Kubernetes est excessif.

4. MicroK8s, meilleur pour une variante Kubernetes prise en charge

MicroK8s est la distribution Kubernetes Canonical installée en tant que snap. Il se regroupe avec microk8s add-node, est livré avec des modules complémentaires pour MetalLB, Ingress, DNS et Rook Ceph, et dispose d’un chemin de support payant si le cluster se développe en quelque chose d’essentiel.

Où cela fait défaut : le runtime snap est polarisant ; certaines configurations Pi préfèrent éviter complètement snap.

Tarification :

Plates-formes : Linux (Ubuntu sur ARM, x86).

Télécharger : microk8s.io · GitHub

Conclusion : La bonne variante K8s quand vous voulez un catalogue de modules complémentaires organisé et une option de support de secours.

5. Portainer, meilleure couche UI

Portainer n’est pas un orchestrateur en soi ; c’est une interface Web qui gère les clusters Docker, Docker Swarm et Kubernetes. L’édition communautaire couvre la plupart des besoins d’homelab, et l’associer à un cluster K3s donne aux membres du ménage sans CLI un moyen de redémarrer un service bloqué.

Où cela fait défaut : le niveau gratuit n’inclut pas le RBAC complet ou les paramètres centralisés ; c’est le travail du niveau payant.

Tarification :

Plates-formes : Linux, Windows, macOS, Docker.

Télécharger : portainer.io · GitHub

Conclusion : L’interface qui transforme une installation K3s ou MicroCloud en quelque chose que le reste du ménage peut utiliser.

6. Docker Swarm, meilleur cluster minimal

Docker Swarm est le mode de clustering intégré de Docker. docker swarm init sur un nœud et docker swarm join sur les autres vous donne un cluster avec mises à jour continues, gestion des secrets et réseau de superposition. Aucun nouveau binaire à apprendre.

Où cela fait défaut : Swarm est en mode maintenance depuis des années ; les nouvelles fonctionnalités arrivent ailleurs. La configuration fonctionne, mais l’énergie de l’écosystème s’est déplacée vers Kubernetes.

Tarification :

Plates-formes : Linux (ARM, x86).

Télécharger : docker.com · GitHub

Conclusion : Le moyen le plus léger de regrouper les conteneurs si vous avez déjà accepté que Docker est l’avenir sur lequel vous restez.

7. Nomad, meilleur pour les charges de travail non conteneurisées

Nomad par HashiCorp planifie les conteneurs, les jarres Java, les binaires bruts et les charges de travail exec Windows. C’est le mélange où il se démarque des outils Kubernetes uniquement : un cluster Pi qui exécute également un service hérité finit plus propre sous Nomad que sous K3s.

Où cela fait défaut : l’écosystème est plus petit que Kubernetes ; chaque intégration tierce que vous souhaitez peut manquer.

Tarification :

Plates-formes : Linux (ARM, x86), Windows.

Télécharger : nomadproject.io · GitHub

Conclusion : Le bon planificateur quand la charge de travail n’est pas « juste des conteneurs » et que Kubernetes semble une importation lourde.

Comment choisir le bon

Si vous partez de zéro et que vous voulez le chemin le plus court vers « un cluster Pi qui exécute tout », installez MicroCloud sur trois nœuds Ubuntu Server Pi. Le stockage, la mise en réseau et la gestion des charges de travail sont livrés dans un seul paquet.

Si votre flux de travail au travail est Kubernetes, mettez K3s sur les mêmes nœuds et ignorez l’écart d’apprentissage. Ajoutez Portainer par-dessus pour le ménage.

Si votre charge de travail est un mélange de conteneurs système de longue durée et d’une ou deux VM complètes, Incus est l’outil le plus calme de cette liste. Cela le fait sans prétendre être un produit de centre de données.

Si vous souhaitez que la courbe d’apprentissage de Kubernetes soit adoucie par une liste de modules complémentaires organisée, MicroK8s est le choix ; sinon, K3s est plus léger.

Ignorez Docker Swarm pour les nouvelles configurations. Cela fonctionne toujours, et si vous en héritez, c’est bien de le garder, mais ne construisez pas quelque chose de nouveau dessus en 2026.

Accédez à Nomad uniquement quand une charge de travail réelle sur le cluster n’est pas un conteneur.

FAQ

Combien de Pi ai-je besoin pour former un cluster significatif ?

Trois. Les clusters à deux nœuds ne peuvent pas voter quorum et perdre des données en toute sécurité ; trois est où le stockage distribué commence à fonctionner.

Ai-je besoin d’un matériel Pi identique dans un cluster ?

Recommandé, pas obligatoire. Les modèles mixtes fonctionnent ; MicroCloud et MicroK8s les tolèrent. Les performances sont limitées par le membre le plus lent.

Puis-je exécuter un Kubernetes domestique sans tout cela ?

Docker Compose sur un seul Pi suffit à de nombreux ménages et n’est pas gênant. Passez à un cluster quand l’échec d’un seul nœud est inacceptable.

Qu’en est-il de la consommation d’énergie ?

Un cluster de trois Pi 4 inactifs autour de 12 à 15 W au total ; un cluster de trois Pi 5 plus proche de 18 à 22 W. Les deux éclipsent l’efficacité d’un NUC pour la même charge de travail, mais restent silencieux et compacts.

MicroCloud me remplace-t-il Proxmox ?

Sur un Pi, oui. Sur x86, Proxmox est toujours le produit plus mature ; MicroCloud est où ARM obtient enfin la même forme d’outil.