Quelle est la meilleure distribution Kubernetes pour un homelab ?

La meilleure distribution Kubernetes pour un homelab est K3s ou MicroK8s.

Comparaison des distributions Kubernetes pour un homelab à 3 nœuds

Choisir la meilleure version de Kubernetes pour notre homelab

Sommaire

Je compare les variantes de Kubernetes auto-hébergées que l’on peut utiliser dans un homelab basé sur Ubuntu avec 3 nœuds (16 Go de RAM, 4 cœurs chacun), en mettant l’accent sur la facilité d’installation et de maintenance, ainsi que le support des volumes persistants et des LoadBalancers.

Scénario : Nous disposons de trois nœuds Ubuntu (16 Go de RAM, 4 cœurs CPU chacun) dans un homelab. La haute disponibilité (HA) et le support ARM ne sont pas des priorités. Nous souhaitons un cluster Kubernetes facile à installer et à entretenir (soit en mode single-node, soit en mode 3-nœuds) avec un support des volumes persistants (PV) et des services LoadBalancer (LB) (afin que les applications cloud-native nécessitant un stockage ou des adresses IP externes fonctionnent de manière fluide). Nous nous concentrerons sur les options de cluster à 3 nœuds sans exigences de HA ou de compatibilité CPU ARM.

kubernetes homelab

Ci-dessous, nous comparons les distributions légères de Kubernetes populaires [Kubernetes(https://www.glukhov.org/fr/post/2024/10/kubernetes-cheatsheet/ “liste et description des commandes k8s les plus fréquentes et utiles - k8s cheatsheet”) – K3s, MicroK8s, Minikube, et kubeadm (Kubernetes vanilla) – et comment elles se comparent sur les critères clés (fonctionnalités, installation/entretien, support PV/LB, exigences en ressources, configuration du cluster, et outils). Nous proposons également quelques recommandations sur le choix à faire en fonction du scénario du homelab.

K3s (Kubernetes léger de Rancher)

Fonctionnalités clés : K3s est une distribution Kubernetes certifiée CNCF conçue pour une utilisation minimale des ressources (elle peut fonctionner avec aussi peu que 512 Mo de RAM). Elle empaquette l’ensemble du plan de contrôle Kubernetes dans un seul binaire et processus, en utilisant des composants légers (par exemple, le stockage SQLite par défaut au lieu d’etcd, flannel pour le réseau). Elle inclut des paramètres par défaut comme un contrôleur d’ingress intégré (Traefik) et un équilibreur de charge simple. K3s élimine les fonctionnalités obsolètes ou en phase alpha pour réduire la surcharge.

Facilité d’installation et d’entretien : Très simple – nous pouvons l’installer avec un script d’une seule ligne (curl ... | sh) ou via des outils comme K3sup. Le serveur démarre avec les composants par défaut dès le départ. Ajouter des nœuds est simple (exécuter l’agent K3s avec un jeton fourni par le serveur). La mise à jour est facile (remplacer le binaire ou utiliser le script d’installation pour la nouvelle version). Aucune configuration séparée d’etcd n’est nécessaire (sauf si nous choisissons une configuration HA multi-maître). K3s est conçu pour nécessiter un minimum de réglages après l’installation, ce qui en fait une option populaire pour l’IoT et les homelabs.
Support des volumes persistants : Intégré. Par défaut, K3s est livré avec la classe de stockage local-path de Rancher, qui provisionne dynamiquement des PV sur le système de fichiers de l’hôte pour chaque PVC. Cela signifie qu’un PVC sera automatiquement rempli en créant un volume hostPath sur le nœud. Il s’agit d’une solution de stockage à nœud unique (chaque volume est sur le disque d’un nœud), mais elle fonctionne sans configuration supplémentaire pour les applications étatiques. Pour un stockage plus avancé, on peut ajouter quelque chose comme Longhorn de Rancher (stockage en bloc distribué), que K3s supporte, mais pour un homelab, le provisionneur local-path par défaut suffit généralement.
Support du LoadBalancer : Intégré. K3s inclut un contrôleur léger appelé ServiceLB (anciennement “Klipper LB”) qui permet aux services de type LoadBalancer d’obtenir une adresse IP/ports sur l’hôte sans fournisseur cloud externe. Lorsque nous créons un service LoadBalancer, K3s déploie un DaemonSet de petits pods LB (svc-...) sur chaque nœud, qui utilisent les ports de l’hôte pour rediriger le trafic vers le service. En substance, K3s réutilise l’IP du nœud (interne ou externe) pour servir en tant qu’IP LB, et utilise le routage iptables dans les pods LB pour envoyer le trafic vers l’IP Cluster du service. Cela fonctionne sans configuration – les services ne resteront pas “en attente” (contrairement à Kubernetes vanilla sur du matériel nu). Le compromis est que l’IP externe du LB sera l’une de nos IPs de nœuds (ou toutes les nœuds) et nous devons nous assurer que le port est libre. Pour la plupart des usages de homelab (exposer quelques services sur des ports HTTP/HTTPS), c’est parfaitement acceptable. Si nécessaire, nous pouvons désactiver le LB intégré et installer MetalLB manuellement, mais la plupart des utilisateurs restent sur le paramètre pratique par défaut.
Exigences en ressources : Très faibles. K3s peut fonctionner même sur du matériel bas de gamme. Officiellement, 512 Mo de RAM et quelques centaines de Mo de disque suffisent pour un nœud serveur. En pratique, un petit cluster pourrait utiliser quelques centaines de Mo de mémoire pour le plan de contrôle. Son binaire est inférieur à 100 Mo. L’empreinte CPU est minimale (K3s utilise légèrement plus de CPU en veille que MicroK8s, mais pas de manière significative). Nos nœuds (16 Go chacun) sont plus que suffisants pour exécuter K3s confortablement.
Single-node vs Multi-node : Adapté aux deux. K3s peut fonctionner en single-node (tous les composants de plan de contrôle et les charges de travail sur une seule machine) ou en multi-node. Pour une configuration à 3 nœuds, nous pourrions avoir 1 serveur (maître) et 2 agents, ou même rendre les 3 serveurs pour HA (ce qui n’est pas nécessaire ici, puisque HA n’est pas un objectif). L’ajout d’agents est trivial avec le jeton. Le stockage par défaut SQLite de K3s fonctionne pour un seul serveur ; pour une configuration HA multi-serveur, nous passerions à un etcd embarqué (K3s peut le faire automatiquement lors du démarrage de plusieurs nœuds serveurs).
Outils CLI et UI : Nous interagissons avec K3s comme avec tout Kubernetes – via kubectl. K3s inclut sa propre build de kubectl (nous pouvons exécuter k3s kubectl ... ou utiliser un kubectl standard en pointant vers le kubeconfig de K3s). Il n’existe pas de CLI spécifique à K3s au-delà des commandes d’installation ; il est intentionnellement minimaliste. Aucun interface web intégrée n’est incluse (le tableau de bord upstream n’est pas installé par défaut). Cependant, nous pouvons déployer manuellement le tableau de bord Kubernetes ou d’autres outils sur K3s comme sur tout cluster standard. Rancher (l’outil de gestion graphique par la même entreprise) peut également être installé sur K3s si un interface complète est souhaitée, mais il n’est pas inclus dans K3s lui-même. En substance, K3s fournit les API k8s de base et nous ajoutons des extras selon nos besoins (ingress, stockage, etc. – certains desquels sont déjà inclus comme mentionné).

MicroK8s (Kubernetes low-ops de Canonical)

Fonctionnalités clés : MicroK8s est la distribution légère de Kubernetes de Canonical, livrée sous forme de package snap. Il installe un cluster Kubernetes pleinement conforme (binaires upstream) avec une seule commande et est conçu pour une facilité d’utilisation (“low ops”) sur une seule machine ou un petit cluster. Il met l’accent sur une approche “batteries-included” – nous obtenons de nombreuses fonctionnalités optionnelles que nous pouvons activer avec des commandes simples. MicroK8s par défaut utilise une expérience Kubernetes vanilla (tous les API standard) mais avec des accessoires pratiques pour les besoins courants. Il supporte à la fois les déploiements single-node et multi-node (nous pouvons former un cluster en “joignant” des nœuds), et même un mode HA pour le plan de contrôle (en utilisant Dqlite – un SQLite distribué – lorsque nous avons 3 maîtres).

Facilité d’installation et d’entretien : Très facile également – il suffit d’exécuter snap install microk8s --classic sur une machine Ubuntu pour installer un nœud Kubernetes. Il s’agit d’un seul package qui inclut tous les composants. MicroK8s est maintenu via le système de snap d’Ubuntu, ce qui signifie que les mises à jour sont atomiques et peuvent être automatiques (nous pouvons suivre un canal pour les versions Kubernetes). Cette capacité de mise à jour automatique est unique parmi ces options – nous pouvons nous inscrire pour obtenir des correctifs de sécurité et des mises à jour mineures via des mises à jour snap. La gestion de MicroK8s se fait via la commande microk8s, qui a des sous-commandes pour activer/désactiver les fonctionnalités. En général, c’est très peu fréquent : aucun conteneur ou VM à gérer (il s’exécute nativement sur l’hôte), et aucun etcd externe à configurer (il utilise un stockage interne). L’entretien se résume principalement à mettre à jour le snap lorsqu’il est nécessaire et à utiliser microk8s.status pour surveiller.
Support des volumes persistants : Disponible via un add-on. Par défaut, MicroK8s ne provisionne pas automatiquement de PV jusqu’à ce que nous activions l’add-on “hostpath-storage”. En activant celui-ci (avec microk8s enable hostpath-storage), un classe de stockage par défaut est créé qui alloue des volumes à partir d’un répertoire sur l’hôte. Cela est essentiellement un provisionneur dynamique hostPath, similaire en concept au local-path de K3s. Une fois activé, tout PVC se liera à un PV hostpath sur le nœud MicroK8s. (Sur un cluster MicroK8s multi-nœuds, le PV hostpath se trouvera sur un seul nœud – adapté pour les tests ou les homelabs mais pas pour le stockage distribué). MicroK8s propose également Mayastor et d’autres add-ons de stockage si nous souhaitons un stockage plus avancé sur plusieurs nœuds, mais pour la simplicité le stockage hostpath fonctionne bien. Note : L’add-on n’est pas activé par défaut (pour garder les choses légères), donc nous devrons l’activer pour que les PVC fonctionnent. Canonical note que ce n’est pas adapté pour un usage HA en production (puisque ce n’est pas répliqué), mais pour un homelab c’est parfait.
Support du LoadBalancer : Disponible via un add-on. MicroK8s ne fournit pas de load balancer par défaut, mais il propose MetalLB comme add-on facile à utiliser. L’exécution de microk8s enable metallb:<start-IP>-<end-IP> déploie MetalLB en mode Layer 2 et nous permet de spécifier une plage d’IPs de notre LAN à utiliser pour les services LoadBalancer. Une fois activé, tout service de type LoadBalancer obtiendra automatiquement une IP de cette plage (et MicroK8s l’annoncera via ARP sur le LAN). Cela donne une expérience cloud-like sur du matériel nu. (Si nous n’activons pas MetalLB, un service LoadBalancer restera en attente, car MicroK8s seul ne le met en œuvre pas – comme Kubernetes upstream.) Dans un homelab, MetalLB est simple à utiliser et nous permet d’accéder aux services sur notre réseau local. Nous devrons choisir un sous-réseau ou une plage d’IPs libre dans notre réseau pour l’utiliser. La commande d’activation de MicroK8s rend l’installation simple, mais il s’agit toujours d’une étape séparée. (À l’inverse, K3s fonctionne sans configuration pour le LB, mais avec la limitation d’utiliser les IPs/ports des nœuds.) Beaucoup d’utilisateurs de MicroK8s activent simplement MetalLB lors de leur configuration initiale pour un LB fonctionnel.
Exigences en ressources : MicroK8s est assez léger, bien qu’un peu plus que K3s en termes d’espace. Il exécute tous les services principaux (API server, contrôleur, planificateur, kubelet, etcd ou Dqlite) nativement. L’utilisation en veille est généralement d’environ 500 à 600 Mo de RAM pour le plan de contrôle, selon les add-ons activés. Canonical cite une mémoire de base de 540 Mo. L’utilisation du CPU est faible en veille, et nos nœuds de 16 Go ont de la marge. L’espace disque requis est petit (snap ~ 200 Mo plus les données etcd). En résumé, MicroK8s peut fonctionner sur du matériel modeste (il est même proposé pour les Raspberry Pi), et dans notre scénario les machines s’accommodent facilement de cela. Si plusieurs add-ons sont activés (tableau de bord, surveillance, etc.), l’utilisation des ressources augmentera en conséquence.
Single-node vs Multi-node : MicroK8s fonctionne bien pour les deux. Nous pouvons l’utiliser pour un cluster single-node (par exemple, sur une machine de développement ou un seul serveur) ou créer un cluster multi-node en “joignant” des nœuds. La documentation MicroK8s fournit une commande pour ajouter un nœud (nous récupérons un jeton de jointure depuis le premier nœud et l’utilisons sur les autres). Dans un setup multi-node sans HA, un nœud sera le plan de contrôle principal. Avec 3 nœuds, nous avons également l’option d’activer le mode ha-cluster (rendant le plan de contrôle HA en exécutant Dqlite sur 3 nœuds), bien que dans notre cas HA ne soit pas nécessaire. Qu’il s’agisse d’un seul nœud ou de trois nœuds, l’expérience est la même API Kubernetes. Le multi-node MicroK8s est un peu plus récent que l’approche de K3s mais est maintenant très stable. C’est un bon choix si nous souhaitons un “micro cloud” de quelques machines Ubuntu exécutant k8s avec peu d’efforts.
Outils CLI et UI : MicroK8s vient avec l’outil de ligne de commande microk8s, très pratique. Par exemple, microk8s enable <addon> active divers services (DNS, ingress, stockage, metallb, tableau de bord, etc.), et microk8s status affiche ce qui est en cours d’exécution. Il inclut également un kubectl intégré : nous pouvons utiliser microk8s kubectl ... (ou l’aliaser), ce qui communique avec le cluster – c’est pratique car nous n’avons pas besoin de configurer un kubeconfig. Pour l’interface utilisateur, MicroK8s fournit le tableau de bord Kubernetes comme add-on (microk8s enable dashboard), qui déployera l’interface web standard. Une fois activé, nous pouvons y accéder (il tourne sur le port 10443 ou via un proxy). MicroK8s n’a pas d’interface graphique personnalisée – il dépend du tableau de bord Kubernetes ou d’autres outils – mais la facilité d’activation est un atout. En résumé, MicroK8s met l’accent sur une expérience à une seule commande pour les tâches courantes et une philosophie “ça marche tout de suite”, abstrayant beaucoup de complexité (au prix de cacher certains détails internes). Cela le rend très adapté aux homelabs pour ceux qui souhaitent un cluster Kubernetes sans configuration manuelle de chaque composant.

Contraste entre K3s et MicroK8s : Les deux sont assez similaires en termes d’objectifs et de capacités – légers, faciles à utiliser, capables de fonctionner en multi-node. K3s tend à être un peu plus “DIY” lors de l’ajout d’extras (il dépend de chartes Helm ou de manifestes manuels pour les choses non incluses), alors que MicroK8s propose des add-ons intégrés via son CLI. MicroK8s est également plus “vanilla” Kubernetes en interne (composants upstream, simplement empaquetés comme snap), alors que K3s utilise certains binaires personnalisés et un seul service pour tout. Les deux sont de bons choix pour un homelab ; la décision dépend souvent de la préférence : si Ubuntu/snap et une sensation intégrée sont préférables, MicroK8s est excellent, alors que si l’on préfère une approche minimaliste avec peut-être un peu plus de contrôle manuel, K3s est excellent. (Nous fournirons des recommandations à la fin.)

Minikube (Cluster Kubernetes à un seul nœud local)

Fonctionnalités principales : Minikube est principalement un outil pour exécuter Kubernetes localement (souvent sur un ordinateur ou un laptop du développeur) plutôt qu’un cluster traditionnel sur plusieurs machines. Il crée un cluster Kubernetes à un seul nœud dans une machine virtuelle ou un conteneur sur notre machine. Minikube est connu pour sa large prise en charge des environnements – il peut s’exécuter sur Linux, macOS, Windows et prend en charge divers hyperviseurs (VirtualBox, KVM, Hyper-V, pilote Docker, etc.). Il est maintenu par les SIGs Kubernetes et est souvent utilisé pour les tests et l’apprentissage. Bien que Minikube puisse être configuré pour un mode à plusieurs nœuds, il est essentiellement conçu pour les clusters à un seul nœud (le mode « multi-nœuds » de Minikube démarre en réalité plusieurs nœuds sur le même hôte à l’aide des runtimes de conteneurs – utile pour simuler un cluster, mais pas pour l’exécuter sur des machines physiques distinctes).

Facilité d’installation et d’utilisation : Minikube est très facile à démarrer sur une seule machine. Nous installons le binaire minikube, nous nous assurons d’avoir un pilote de machine virtuelle (ou Docker), puis nous exécutons minikube start. Cela configurera une machine virtuelle/conteneur locale et lancera Kubernetes à l’intérieur. C’est probablement la manière la plus simple de faire fonctionner un cluster Kubernetes pour la première fois. L’interface CLI (minikube) fournit des commandes pour interagir avec la machine virtuelle (démarrer, arrêter, supprimer) et pour activer des compléments. Puisque Minikube est conçu pour une utilisation locale, il n’est pas un « démon longue durée » – nous le démarrons généralement quand nous en avons besoin et l’arrêtons quand nous en avons terminé, bien que nous puissions le laisser fonctionner continuellement sur un serveur de laboratoire si souhaité. Les mises à jour et les entretiens sont faciles : il suffit de mettre à jour la version de minikube et de redémarrer le cluster (Minikube peut également mettre à jour la version de Kubernetes qu’il exécute avec un drapeau). Cependant, une limite est que Minikube est par conception à un seul nœud (ajouter plus de nœuds signifie démarrer d’autres instances de machine virtuelle sur le même hôte, et non rejoindre des hôtes physiques réels). Ainsi, utiliser Minikube sur trois nœuds physiques distincts signifierait en réalité exécuter trois clusters à un seul nœud indépendants, ce qui n’est probablement pas ce que nous voulons. Minikube brille pour le développement et les tests sur une seule machine, mais il n’est pas conçu pour gérer un cluster réparti sur plusieurs serveurs physiques.
Support des volumes persistants : Intégré (hostPath). Les clusters Minikube incluent automatiquement une classe de stockage par défaut qui utilise un provisionneur hostPath. En fait, Minikube exécute un petit contrôleur qui crée dynamiquement des PV hostPath à l’intérieur de la machine virtuelle lorsqu’on demande des PVC. Cela signifie que nous pouvons créer des PersistentVolumeClaims et ils seront satisfaits à l’aide du stockage du système de fichiers de la machine virtuelle Minikube (généralement sous /tmp/hostpath-provisioner ou similaire). Cela fonctionne sans configuration – aucune configuration n’est nécessaire pour une utilisation de base des PV. Par exemple, la classe de stockage par défaut « standard » dans Minikube correspond au stockage hostPath sur le nœud. Une remarque : si nous redémarrons ou supprimons la machine virtuelle Minikube, ces volumes hostPath pourraient être perdus (Minikube tente de persister certains répertoires lors des redémarrages – par exemple, /data, /var/lib/minikube, /tmp/hostpath* sont conservés). Mais en général, pour un environnement non de production, c’est acceptable. Si nous souhaitons simuler davantage, Minikube dispose également d’un addon du pilote hostpath CSI qui prend en charge les sauvegardes et peut fonctionner en mode multi-nœuds, mais c’est plus pour l’expérimentation. En résumé : Minikube prend en charge les PV par défaut via hostPath, ce qui est suffisant pour un test de applications étatiques dans un laboratoire.
Support LoadBalancer : Supporté via le tunneling (ou l’addon MetalLB). Dans le cloud, un service LoadBalancer obtient un équilibreur de charge cloud avec une adresse IP externe. Dans Minikube, il n’y a évidemment pas de fournisseur cloud, donc Minikube fournit deux mécanismes :
- Minikube Tunnel : Nous pouvons exécuter minikube tunnel dans un processus séparé qui créera une route réseau sur notre hôte et assignera une IP à notre service LoadBalancer. En substance, il utilise notre hôte pour agir comme le « LoadBalancer externe ». Lorsque nous créons un service LoadBalancer, Minikube affichera une « adresse IP externe » (généralement provenant du sous-réseau du cluster) et le processus minikube tunnel dirigera celle-ci vers le service. Cela nécessite que le processus tunnel reste en cours d’exécution (et généralement des droits root pour créer des routes). C’est une étape un peu manuelle, mais Minikube affiche un rappel si nous avons un service LoadBalancer sans tunnel en cours d’exécution (« External-IP pending » jusqu’à ce que nous démarions le tunnel).
- Addon MetalLB : Les versions plus récentes de Minikube incluent également un addon MetalLB. Nous pouvons exécuter minikube addons enable metallb et configurer une plage d’IP (Minikube nous demandera). Cela déployera effectivement MetalLB à l’intérieur du cluster Minikube, qui gérera ensuite les services LoadBalancer comme le ferait sur tout Kubernetes en métal nu. C’est une solution plus « en cluster » et n’exige pas un processus tunnel séparé après la configuration initiale.
Les deux options fonctionnent, et le choix dépend de nous. Pour exposer rapidement un seul service, minikube tunnel est rapide et éphémère. Pour une configuration plus permanente, l’addon MetalLB peut être activé afin que les LoadBalancers obtiennent des adresses IP réelles (par exemple, nous pourrions lui donner une plage comme 10.0.0.240-250 sur un Minikube avec un réseau bridgé). Souvenez-vous que Minikube est généralement à un seul nœud, donc en pratique, le « load balancer » ne balance pas sur plusieurs nœuds – il fournit simplement l’accès externe au service du seul nœud. Cela est acceptable pour le développement. Dans un laboratoire, si nous utilisons uniquement un de nos nœuds et exécutons Minikube dessus, nous pouvons utiliser ces méthodes pour accéder à nos applications. Mais si nous souhaitons utiliser tous les trois nœuds, l’approche de Minikube pour le LoadBalancer n’est pas adaptée à ce scénario.
Exigences en ressources : Minikube lui-même est léger, mais comme il exécute généralement un cluster Kubernetes complet (dans une machine virtuelle), l’utilisation des ressources est similaire à celle d’un petit cluster normal. La recommandation minimale est de 2 Go de RAM et 2 cœurs de processeur pour la machine virtuelle. Par défaut, Minikube alloue souvent 2 Go de RAM à sa machine virtuelle. Dans notre cas, avec 16 Go par machine, c’est trivial. Minikube inactif (Kubernetes) pourrait utiliser environ 600 Mo de mémoire. Une chose à considérer est que Minikube s’exécutera au-dessus de notre système d’exploitation – soit en tant que machine virtuelle via un hyperviseur, soit en tant que conteneur Docker – ce qui ajoute un peu d’overhead. Sur un serveur de laboratoire, nous pouvons exécuter Minikube avec le pilote « none » (qui installe directement les composants Kubernetes sur l’hôte). Cependant, le pilote « none » (aussi appelé métal nu) est essentiellement similaire à l’utilisation de kubeadm sur ce nœud, et nécessite un nettoyage manuel, donc il n’est pas aussi populaire. La plupart utilisent un pilote de machine virtuelle ou Docker. En résumé, n’importe lequel de nos nœuds de laboratoire peut exécuter facilement Minikube. La seule contrainte est que Minikube n’utilisera pas les ressources des trois nœuds – il sera limité à l’hôte sur lequel il s’exécute (sauf si l’on utilise l’option expérimentale de multi-nœuds sur un seul hôte).
Un seul nœud vs plusieurs nœuds : Principalement un seul nœud. Minikube est idéal pour un cluster à un seul nœud sur une seule machine. Il dispose d’une fonctionnalité pour simuler plusieurs nœuds (par exemple, minikube start --nodes 3 avec le pilote Docker démarre 3 nœuds Kubernetes en tant que conteneurs sur un seul hôte), mais c’est uniquement pour les tests. Nous ne pouvons pas utiliser Minikube pour créer un cluster à plusieurs nœuds réel sur trois serveurs physiques distincts. Si nous avons trois machines, nous devrons exécuter trois instances indépendantes de Minikube (pas dans le même cluster). Ce n’est pas une véritable expérience de cluster (ils ne connaîtront pas les uns les autres). Par conséquent, Minikube n’est pas recommandé si notre objectif est d’utiliser les trois nœuds dans un seul cluster Kubernetes – il est plus adapté aux scénarios où nous n’avons qu’une seule machine (notre PC ou un seul serveur) et souhaitons exécuter K8s dessus. Il est également excellent pour apprendre les bases de Kubernetes et faire du développement local.
Outils CLI et UI : L’interface CLI minikube est l’interface principale. Nous l’utilisons pour démarrer/arrêter le cluster, et elle dispose de raccourcis pratiques : par exemple, minikube dashboard activera le tableau de bord Kubernetes et l’ouvrira dans notre navigateur. minikube addons enable <addon> permet d’activer divers composants optionnels (ingress, metallb, metrics-server, etc.). Minikube configure automatiquement l’accès à kubectl (il configure un contexte « minikube » dans notre kubeconfig). Pour l’interface graphique, comme mentionné, le tableau de bord Kubernetes est facilement accessible via la commande dashboard. Minikube n’a pas son propre interface web unique ; il s’appuie sur les outils standard. Le débogage de Minikube est également facile puisque nous pouvons exécuter minikube ssh pour accéder au nœud VM si nécessaire. En résumé, les outils sont très conviviaux pour un scénario à un seul nœud.

Kubeadm (Kubernetes standard sur nos propres nœuds)

Fonctionnalités principales : Kubeadm n’est pas une « distribution » mais plutôt l’outil officiel pour créer un cluster Kubernetes à partir de zéro. L’utilisation de kubeadm signifie que nous déployons les composants standard Kubernetes upstream sur nos machines. C’est essentiellement la manière dont nous « construisons nous-mêmes » un cluster, en suivant les bonnes pratiques mais sans les extras que les distributions incluent. Kubeadm configurera un nœud de plan de contrôle (exécutant etcd, serveur API, gestionnaire de contrôle, planificateur) et joindra les nœuds travailleurs à celui-ci. Le résultat est un cluster Kubernetes standard complet identique à ce que nous obtiendrions sur des machines virtuelles cloud. Cette approche nous donne un contrôle et une flexibilité complets – nous choisissons le plugin réseau, le provisionneur de stockage, etc. – mais nécessite également le plus de travail manuel initial et de connaissances. Il est souvent utilisé dans les environnements de production ou d’apprentissage pour comprendre les internes de Kubernetes.

Facilité d’installation et d’entretien : Comparé aux autres, kubeadm est le plus impliqué. Nous devons manuellement installer les dépendances (runtime conteneur comme containerd, kubeadm, kubelet, kubectl) sur chaque nœud. Puis exécuter kubeadm init sur le maître, et kubeadm join sur les travailleurs avec le jeton qu’il fournit. Nous devons également configurer un CNI (plugin réseau) après l’initialisation (Calico, Flannel, etc.) puisque kubeadm ne fournit pas de plugin par défaut. Il existe des étapes bien documentées pour tout cela (le processus n’est pas difficile, mais il comporte de nombreuses étapes) – essentiellement, kubeadm nous donne un cluster de départ mais nous attendons que nous gérions les compléments. En termes d’entretien, nous sommes responsables des mises à jour (kubeadm dispose d’une commande de mise à jour, mais nous devons manuellement drainer les nœuds, mettre à jour les binaires, etc.), ainsi que du suivi de la santé d’etcd, des renouvellements de certificats, etc. En bref, kubeadm est puissant mais manuel. Il est souvent appelé « la manière difficile » (bien que moins difficile que de construire à partir de la source). Pour un passionné de laboratoire qui aime apprendre, kubeadm est un excellent moyen de comprendre profondément Kubernetes. Mais si notre priorité est « facile et peu d’entretien », kubeadm sera plus de travail que K3s/MicroK8s. Chaque mise à jour ou modification exigira un effort manuel. Cela dit, une fois configuré, c’est le vrai deal : un cluster Kubernetes standard sans abstractions cachées.
Support des volumes persistants : Aucun par défaut (doit être ajouté manuellement). Un cluster installé avec kubeadm est essentiellement un Kubernetes vide – il ne comprend pas de classe de stockage par défaut ou de provisionneur dynamique par défaut. Dans les environnements cloud, le fournisseur cloud fournirait normalement une classe de stockage par défaut (par exemple, AWS EBS, etc.), mais dans un environnement de laboratoire en métal nu, nous devrons installer notre propre solution. Approches courantes :
- Provisionneur hostPath : Nous pouvons reproduire ce que fait K3s/Minikube en installant quelque chose comme le provisionneur local de Rancher (qui est un petit contrôleur + classe de stockage qui crée des PV hostPath). C’est un add-on simple (juste un manifeste YAML) et nous donne un stockage dynamique local.
- NFS ou NAS : Certains utilisateurs de laboratoire installent un serveur NFS (ou utilisent un NAS) puis utilisent des PV statiques ou un pilote CSI NFS pour le provisionnement.
- OpenEBS/Longhorn/Ceph : Il existe des options plus complexes comme le déploiement de Longhorn ou de Ceph RBD via Rook si nous souhaitons un stockage distribué sur les nœuds. Ces solutions nécessitent plus de ressources et de complexité.
Le point clé est que kubeadm ne « résout » pas le stockage pour nous – nous devons décider et configurer nous-mêmes. Si la facilité est la priorité, le chemin le plus simple est de déployer un provisionneur hostPath ou d’utiliser NFS. Par exemple, le provisionneur local de Rancher peut être installé en quelques commandes kubectl apply et imitera le comportement de K3s (créant des volumes sous /var/lib/rancher/ sur n’importe quel nœud). Mais c’est une étape manuelle. Jusqu’à ce que nous l’ayons fait, tout PVC que nous créons restera en état « pending » car Kubernetes n’a pas de provisionnement par défaut. Donc, bien que kubeadm supporte les volumes persistants (c’est le vrai Kubernetes), le support pour les PV dynamiques est aussi bon que l’effort que nous mettons à les configurer.
Support LoadBalancer : Aucun par défaut (doit être ajouté manuellement). Histoire similaire ici : dans un cluster traditionnel en interne, nous n’avons pas d’implémentation LoadBalancer intégrée. Si nous créons un service de type LoadBalancer sur un cluster kubeadm standard, il restera en état pending pour toujours jusqu’à ce que nous déployions un contrôleur pour le gérer. La solution courante est d’installer MetalLB nous-mêmes. MetalLB peut être installé via un manifeste ou un chart Helm – nous configurerons une plage d’IP et MetalLB allouera ces IP pour les services LoadBalancer (comme dans MicroK8s). De nombreux guides existent pour installer MetalLB sur des clusters kubeadm. Une autre alternative utilisée par certains est kube-vip pour le VIP du plan de contrôle et les services LoadBalancer, mais MetalLB est plus simple pour les services. En substance, avec kubeadm, nous avons la liberté (ou le fardeau) de configurer n’importe quel mécanisme de load-balancing qui correspond à nos besoins. Si nous n’en configurons aucun, nous sommes limités aux services NodePort pour l’accès externe. Pour un laboratoire, l’installation de MetalLB est fortement recommandée – c’est simple et nous donne cette fonctionnalité d’IP de service comme dans le cloud. Mais à nouveau, c’est une étape supplémentaire que nous devons effectuer (contrairement à K3s qui fonctionne sans configuration ou MicroK8s avec un simple enable).
Exigences en ressources : Kubernetes standard est un peu plus lourd que les versions allégées. Chaque nœud exécutera un kubelet et un kube-proxy, et le maître exécutera etcd et les composants du plan de contrôle. Un seul nœud de plan de contrôle peut encore fonctionner avec 2 Go de RAM, mais généralement nous voudrons un peu plus si nous exécutons des pods dessus. Le guide padok suggère 2 Go pour le maître, 2 Go pour le travailleur minimum. Dans notre scénario (16 Go par nœud), c’est acceptable. L’etcd et le serveur API inactifs utiliseront chacun quelques centaines de mégaoctets de mémoire. Il n’y a pas grande différence au moment de l’exécution entre un cluster kubeadm et MicroK8s – après tout, MicroK8s est ces mêmes composants. La différence est simplement ce qui est exécuté par défaut (MicroK8s pourrait activer le DNS et le stockage par défaut, alors que sur kubeadm nous installerons ces éléments). Donc, en termes de ressources, kubeadm peut être aussi léger ou lourd que nous le configurons. Avec rien d’installé en plus, il pourrait être assez léger. Avec une configuration typique (disons que nous ajoutons CoreDNS, Dashboard, etc.), prévoyez environ 1 Go utilisé pour les surcoûts système. Nous avons beaucoup de RAM, donc les ressources ne sont pas un problème. C’est plus une question du temps et des ressources humaines nécessaires pour le gérer plutôt que du CPU/RAM.
Un seul nœud vs plusieurs nœuds : Kubeadm peut faire les deux, avec une pleine flexibilité. Nous pouvons initialiser un cluster à un seul nœud (et même demander à kubeadm de permettre au seul nœud d’exécuter des charges de travail en supprimant les tâches de maître). Ou nous pouvons avoir un maître et joindre deux travailleurs (une configuration de 3 nœuds courante). Nous pourrions même configurer trois maîtres et trois travailleurs, etc. – toute topologie. Dans notre cas, une configuration probable de kubeadm serait 1 nœud de plan de contrôle et 2 travailleurs (puisque la haute disponibilité n’est pas nécessaire, nous n’avons pas besoin de plusieurs maîtres). Cela nous donne un cluster fonctionnel à 3 nœuds. Le processus pour les clusters multi-nœuds est bien documenté : essentiellement, installez Kubernetes sur tous, initialisez un, joignez les autres. Le résultat est identique à ce qu’offrirait un cluster géré ou une autre distribution : nos 3 nœuds apparaissent dans kubectl get nodes, etc. Donc, kubeadm répond certainement à la « possibilité d’utiliser les trois nœuds ».
Outils CLI et UI : Avec kubeadm, le seul CLI spécial est kubeadm lui-même, utilisé pour les étapes d’installation et (plus tard) de mise à jour. Au quotidien, utilisez kubectl pour gérer le cluster. Il n’y a aucun CLI de gestion intégré au-delà de ce que Kubernetes fournit. Pour l’interface graphique, rien n’est inclus par défaut – nous pouvons manuellement déployer le tableau de bord Kubernetes ou tout autre outil (comme sur tout cluster). En substance, kubeadm nous donne un canevas Kubernetes vierge. C’est à nous de peindre dessus – ce qui inclut l’installation de commodités comme le tableau de bord, les contrôleurs d’ingress, les classes de stockage, etc. De nombreux tableaux de bord tiers (Lens, Octant, etc.) peuvent également se connecter à un cluster kubeadm si nous souhaitons une expérience de gestion graphique, mais ce sont des outils externes. En résumé, avec kubeadm, nous obtenons un environnement Kubernetes pur – une flexibilité maximale, mais également le besoin de configurer tout comme si c’était un cluster de production.
Kubespray Voir également comment installer cette version de Kubernetes avec Kubespray.

Tableau de comparaison côte à côte

Voici un résumé comparant les quatre options sur des points clés :

Aspect	K3s (Kubernetes léger de Rancher)	MicroK8s (Kubernetes “Low-Ops” de Canonical)	Minikube (Kubernetes de développement à un seul nœud)	Kubeadm (Kubernetes vanilla)
Installation	Script d’installation en une ligne (un seul binaire). Fonctionne comme un seul service système. Très rapide à configurer.	Installation en une commande via snap sur Ubuntu. Tous les composants inclus. Facile à regrouper avec `microk8s join`.	Installez le CLI minikube, puis exécutez `minikube start` pour lancer un VM/container local. Multiplateforme et convivial pour les débutants.	Installation manuelle de kubeadm, kubelet, etc. sur chaque nœud. Exécutez `kubeadm init` + `kubeadm join` avec les prérequis. Implique plusieurs étapes (runtime, plugin de réseau, etc.).
Maintenance et mises à jour	Mises à jour manuelles (remplacer le binaire ou utiliser le script d’installation pour la nouvelle version). Simple, car c’est un seul binaire ; peu à gérer. Aucune mise à jour automatique.	Mises à jour via `snap refresh` (peut être automatique). Les add-ons et services de cluster sont gérés via le CLI `microk8s`. Généralement peu d’opérations ; mises à jour automatiques disponibles.	Facile de supprimer/recréer le cluster pour le développement. Mises à jour en mettant à jour la version de minikube et en redémarrant le cluster. Destiné à l’utilisation éphémère (moins d’accent sur la durabilité des mises à jour en place).	L’utilisateur est responsable de toutes les mises à jour. Utilisez `kubeadm upgrade` mais devez vider les nœuds, gérer la sauvegarde d’étcd, etc. Pleine maîtrise, mais vous faites le travail (aucune mise à jour automatique).
Version Kubernetes	Suit le flux principal assez étroitement (souvent utilisé dans les versions de bord). Conformité CNCF. Certaines fonctionnalités désactivées par défaut (alpha/legacy).	Suit les versions principales (canaux snap pour 1.27, 1.28, etc.). Conformité CNCF. Essentiellement des binaires Kubernetes vanilla.	Nous pouvons choisir la version Kubernetes au départ (par exemple, `minikube start --kubernetes-version=v1.27`). Par défaut, la dernière version stable.	N’importe quelle version que nous voulons (installer des versions spécifiques de kubeadm/kubelet). Kubernetes principal complet – nous décidons de la version et du moment de la mise à jour.
Fonctionnalités par défaut	Fonctionnalités par défaut incluses : Flannel CNI, CoreDNS, Traefik ingress, chargeur de service, classe de stockage locale, metrics-server, etc. (Toutes peuvent être désactivées si nécessaire). Peu de configuration nécessaire pour être fonctionnel.	Fonctionnalités par défaut minimales : le DNS est généralement activé, les autres sont optionnels. Add-ons faciles à ajouter en une commande (ingress NGINX, MetalLB, stockage hostpath, tableau de bord, etc.). Peut activer le mode HA sur 3+ nœuds.	Inclus dans le VM : comprend généralement le runtime Docker/containerd, Kubernetes avec des add-ons par défaut comme StorageProvisioner et DNS. Add-ons optionnels (ingress, tableau de bord, etc.) basculent via le CLI. Aucun nœud multiple par défaut.	Basique : Rien au-delà du Kubernetes de base. Aucun ingress, aucune classe de stockage ou LB par défaut, aucun tableau de bord jusqu’à ce que nous les installions. Choisissons le plugin CNI (doit installer un pour le réseau). Essentiellement un cluster DIY.
Support des volumes persistants	Oui – par défaut. Le provisionneur local-path de Rancher est inclus, qui crée des PV hostPath sur le nœud pour tout PVC. La classe de stockage par défaut « local-path » utilise automatiquement le disque local.	Oui – add-on facile. Activez `hostpath-storage` pour obtenir une classe de stockage par défaut pour les PV dynamiques utilisant hostPath. Jusqu’à ce qu’elle soit activée, aucun provisionneur de PV par défaut. L’add-on n’est pas adapté pour les environnements de production multi-nœuds, mais convient pour un homelab.	Oui – par défaut. La classe de stockage par défaut utilise le provisionneur hostPath à l’intérieur du VM minikube. Les PVC sont satisfaits par un contrôleur simple qui crée un PV hostPath sur le système de fichiers du nœud. Les données persistent après redémarrage sur certains répertoires.	Non (manuel). Aucun provisionneur par défaut – le cluster n’aura aucune classe de stockage initialement. L’utilisateur doit installer une solution de stockage (par exemple, provisionneur local path, NFS, Ceph, etc.). Approche basique : appliquez un YAML de provisionneur hostPath pour imiter ce que fait K3s/Minikube. Jusqu’à ce moment, les PVC restent en attente.
Support LoadBalancer	Oui – ServiceLB intégré. Le contrôleur servicelb de K3s (Klipper) surveille les services LoadBalancer et déploie des pods sur les nœuds pour les exposer. Utilise l’IP du nœud et les ports hôtes pour transférer le trafic. Fonctionne sans configuration. Adapté aux petits clusters ; utilise l’IP interne/externe du nœud pour le service.	Oui – via l’add-on MetalLB. Activez `metallb` avec une plage d’IP pour allouer. Fournit un véritable équilibreur de charge en couche 2 sur le matériel. Non activé par défaut. Une fois activé, chaque service LoadBalancer obtient une IP unique de notre pool. Requiert un peu de configuration initiale (plage d’IP).	Oui – via tunnel ou MetalLB. Aucun équilibreur de charge cloud, mais nous pouvons exécuter `minikube tunnel` pour attribuer une IP externe aux services LoadBalancer (crée une route sur l’hôte). Alternativement, activez l’add-on MetalLB dans minikube pour des IPs d’équilibreur automatiques. Par défaut, les services LoadBalancer afficheront « en attente » jusqu’à ce que nous utilisions l’une de ces méthodes.	Non (manuel). Aucun équilibreur de charge intégré. Typiquement, installez MetalLB manuellement pour la fonctionnalité d’équilibreur de charge sur matériel. Une fois MetalLB (ou un autre contrôleur d’équilibreur) configuré, les services LoadBalancer fonctionnent. Sans cela, les services LoadBalancer restent en attente indéfiniment.
Réseau (CNI)	Par défaut = Flannel (réseau overlay). K3s prend également en charge le remplacement du CNI si nécessaire. CoreDNS est déployé pour le DNS du cluster. Traefik ingress est inclus par défaut (peut être désactivé).	Par défaut = Calico (pour les versions récentes en mode HA) ou un défaut simple. (MicroK8s a historiquement utilisé Flannel ; maintenant tend à utiliser Calico pour une confinement stricte). CoreDNS est activé par défaut. L’ingress NGINX est disponible via l’add-on (`microk8s enable ingress`).	Par défaut = kubenet/bridge (dépend du pilote ; souvent utilise un réseau NAT simple). CoreDNS fonctionne par défaut. Nous pouvons activer un add-on NGINX ingress si nécessaire. Le réseau est confiné au seul VM ; NodePort est accessible via `minikube ip`.	Choix du CNI. Kubeadm n’installe aucun plugin CNI – nous devons en déployer un (Calico, Flannel, Weave, etc.). Nous avons pleine maîtrise. La plupart des guides ont appliqué le YAML Calico après `kubeadm init`. CoreDNS est installé par défaut par kubeadm comme DNS du cluster. Contrôleur d’ingress – choisissez et installez vous-même (par exemple, NGINX ou Traefik via des manifestes/Helm).
Clustering multi-nœuds	Oui. Conçu pour le multi-nœuds. Facile à rejoindre avec un jeton. Peut utiliser une base de données externe ou étcd intégré pour le multi-maître. Idéal pour les homelabs de 2-3+ nœuds. Aucune dépendance supplémentaire nécessaire – K3s a son propre clustering intégré.	Oui. Supporte le regroupement de plusieurs nœuds MicroK8s (avec `microk8s join`). Peut activer le mode HA avec 3+ maîtres (Dqlite). Très simple à former un cluster, surtout si tous les nœuds exécutent Ubuntu + snap.	Non (physique). Conçu pour un seul nœud. Peut simuler le multi-nœuds sur une seule machine (plusieurs nœuds dans des conteneurs Docker), mais ne peut pas étendre un cluster à plusieurs hôtes physiques. Utilisez des instances Minikube séparées pour des clusters séparés.	Oui. Supporte pleinement le multi-nœuds (c’est l’objectif). Nous pouvons avoir 1 maître + plusieurs travailleurs, ou même plusieurs maîtres (bien que la configuration HA de kubeadm soit plus complexe). Aucune limite de taille de cluster intégrée.
Surcharge des ressources	Très faible. Plan de contrôle ~<0,5 Go de mémoire inutilisée. Un seul processus pour le plan de contrôle donne une empreinte petite. Efficace en CPU (bien qu’il puisse utiliser légèrement plus de CPU au repos que MicroK8s selon certains rapports). Idéal pour les faibles puissances ou les nombreuses capacités inutilisées.	Faible. ~0,5–0,6 Go de mémoire pour le plan de contrôle inutilisé. Légèrement plus grande mémoire de base que K3s, mais reste stable. Utilise Ubuntu snap (peut avoir un peu de surcharge). Toujours léger par rapport à Kubernetes complet.	Modérée. Allocation par défaut du VM 2 Go (utilisation ~0,6 Go inutilisée). Exécute un Kubernetes à un seul nœud complet, plus la couche VM. Aucun problème sur les systèmes de 16 Go, mais consomme essentiellement les ressources d’un petit cluster sur une seule machine.	Modérée. Un maître unique avec un seul travailleur pourrait utiliser ~1 Go inutilisé après l’ajout d’add-ons typiques. Chaque nœud supplémentaire ajoute une surcharge minimale (juste kubelet, proxy). Similaire à l’exécution de Kubernetes dans des VMs cloud de taille comparable. Sur 3 nœuds avec 16 Go chacun, la surcharge est négligeable dans le contexte.
Outils CLI	Utilisez `k3s` pour l’installation et comme wrapper pour kubectl (ou utilisez le standard `kubectl`). Aucun CLI de gestion séparé (K3s est principalement « set and forget »). Quelques scripts d’aide (par exemple, `k3s-killall.sh`). Le GUI de Rancher peut être ajouté si souhaité.	CLI riche `microk8s` : par exemple, `microk8s enable/disable <addon>`, `microk8s status`. Inclut également `microk8s kubectl`. Conçu pour simplifier les tâches courantes (aucune édition directe des manifestes système nécessaire pour les bases).	CLI `minikube` pour démarrer/arrêter le cluster, gérer la configuration et les add-ons, et obtenir des informations (IP, URL du service, journaux). Fournit également des commandes pratiques comme `minikube dashboard`. Interagir avec le cluster via `kubectl` (configuration automatiquement définie pour le contexte minikube).	Seulement `kubeadm` pour l’installation initiale et les mises à jour. Opérations quotidiennes via `kubectl` standard et d’autres outils Kubernetes. Aucun CLI spécifique à la distribution au-delà de la phase de bootstrap. Vous travaillerez avec des commandes Kubernetes brutes et peut-être des outils système pour l’entretien.
Interface utilisateur / Tableau de bord	Non inclus par défaut. Peut installer manuellement le Dashboard Kubernetes ou utiliser des outils externes (rien de spécifique à Rancher sauf si nous ajoutons séparément Rancher). K3s se concentre sur l’opération sans interface.	Non inclus par défaut, mais disponible via une commande : `microk8s enable dashboard` déploie l’interface utilisateur standard du Dashboard. Accès facile au cluster via `microk8s dashboard-proxy`. Intègre bien avec l’interface graphique Lens de Canonical si souhaité (Lens peut accéder directement à MicroK8s).	Non activé par défaut, mais la commande `minikube dashboard` déposera et ouvrira l’interface web du Dashboard pour nous. C’est destiné à la commodité dans le développement local – une seule commande et nous avons une interface graphique pour voir les charges de travail.	Non inclus. Nous pouvons installer le Dashboard (appliquer le YAML) si nous le souhaitons. Sinon, utiliser le CLI ou des applications de tableau de bord tierces. Dans un homelab, on pourrait installer le tableau de bord et créer un NodePort ou utiliser `kubectl proxy` pour le consulter. Kubeadm ne s’occupe pas des interfaces.

Sources : Les données ci-dessus sont synthétisées à partir des documents officiels et des guides utilisateurs : par exemple, les empreintes mémoire provenant de la propre comparaison de MicroK8s, le stockage par défaut dans les documents K3s, le comportement du service LB de K3s provenant de la documentation K3s, les détails des add-ons de MicroK8s provenant des documents de Canonical, les PV et tunnel de Minikube provenant des documents Kubernetes, et les rapports d’expérience générale. (Voir les Références pour les citations complètes.)

Recommandations

Étant donné les priorités (facilité d’installation/entretien, et prise en charge intégrée du stockage et des équilibreurs de charge) et le scénario (3 nœuds Ubuntu, sans préoccupation concernant la haute disponibilité) :

Choix recommandés : K3s ou MicroK8s sont les plus adaptés pour un homelab à 3 nœuds :
- Les deux sont très faciles à installer (une seule commande par nœud) et nécessitent un entretien minimal. Ils abstraient la plupart de la complexité d’exécuter un cluster.
- Les deux prennent en charge le clustering multi-nœuds dès le départ (nous pouvons joindre nos 3 nœuds et voir un cluster unifié).
- Ils offrent chacun une solution pour les Volumes Persistance et les Équilibreurs de Charge sans beaucoup d’effort : K3s les inclut par défaut (stockage Local Path, Klipper LB) et MicroK8s les rend disponibles via des commandes enable simples. Cela signifie que nous pouvons déployer des applications typiques (bases de données avec des PVC, services avec type=LoadBalancer) avec un minimum de configuration manuelle.
- K3s pourrait être attirant si nous voulons le plus petit empreinte possible et que nous n’avons pas de problème à utiliser ses paramètres par défaut (ingress Traefik, etc.). C’est une approche “mettre en place et ça fonctionne” avec des paramètres par défaut opiniâtres. Il est également très populaire dans la communauté des homelabs pour sa simplicité. Nous utiliserons principalement des commandes standard kubectl, et nous pouvons ajuster ou désactiver les composants emballés si nécessaire. K3s pourrait être préférable si nous ne sommes pas sur Ubuntu ou si nous aimons l’écosystème de Rancher (ou si nous prévoyons d’utiliser l’interface d’administration de Rancher ultérieurement).
- MicroK8s pourrait être attirant si nous préférons une solution soutenue par Ubuntu et aimons l’idée d’activer les fonctionnalités avec une seule commande. Il s’agit essentiellement de Kubernetes pur sous le capot, ce que certains trouvent plus facile à étendre. Les compléments (comme microk8s enable ingress dns storage metallb) peuvent nous donner un “micro cloud” fonctionnel en quelques minutes. MicroK8s gère également les mises à jour de manière gracieuse via les snaps, ce qui peut être pratique pour garder notre cluster à jour sans intervention manuelle (nous pouvons désactiver cela ou contrôler le canal pour éviter les surprises). Si nous exécutons déjà Ubuntu sur tous les nœuds (ce que nous faisons) et que nous n’avons pas de problème à utiliser les snaps, MicroK8s est un excellent choix pour un cluster à faible entretien.
En résumé : On ne peut pas se tromper avec K3s ou MicroK8s dans ce scénario. Les deux nous offriront un Kubernetes facile à utiliser, adapté aux homelabs, avec les fonctionnalités dont nous avons besoin. Beaucoup d’utilisateurs rapportent des expériences positives avec les deux dans des configurations de maison avec 2 à 3 nœuds. MicroK8s pourrait avoir un léger avantage en termes d’ergonomie (en raison des compléments et de l’intégration), tandis que K3s pourrait avoir un léger avantage en termes de performance et de simplicité sous le capot.
Quand choisir Minikube : Si nous étions simplement en cours d’exécution sur une seule machine ou souhaitions un cluster de développement éphémère, Minikube est fantastique pour cela. C’est la manière la plus simple de lancer Kubernetes sur un ordinateur portable ou un seul nœud pour le test. Cependant, pour un cluster permanent à 3 nœuds, Minikube n’est pas le bon outil – il ne fusionnera pas ces 3 nœuds en un seul cluster. Nous finirions par sous-utiliser notre matériel ou à gérer 3 clusters séparés, ce qui n’est pas souhaitable. Ainsi, dans ce homelab avec plusieurs nœuds, Minikube n’est pas recommandé comme solution principale. Nous pourrions toutefois toujours utiliser Minikube sur notre ordinateur personnel pour tester des choses avant de les déployer sur le cluster du homelab, mais pour le cluster lui-même, utiliser quelque chose comme K3s/MicroK8s.
Quand choisir Kubeadm : Si notre objectif était d’apprendre les internes de Kubernetes ou d’avoir un contrôle total et une configuration “proche de la production”, kubeadm est un bon exercice. Il nous obligera à comprendre comment installer le CNI, le stockage, etc., et nous construirons essentiellement le cluster pièce par pièce. En termes d’ergonomie, cependant, kubeadm est le plus manuel. Chaque fonctionnalité dont nous avons besoin (comme le stockage ou le LB) devra être configurée. Pour un homelab axé sur l’apprentissage, cela peut être un point fort (pédagogique) ; pour un homelab juste-fonctionne, c’est un point faible. De plus, l’entretien sera plus complexe (surtout lors des mises à jour). À moins que nous ne souhaitions explicitement l’expérience Kubernetes standard pour l’apprentissage ou des besoins personnalisés spécifiques, l’utilisation de K3s ou de MicroK8s nous économisera beaucoup de temps et de soucis dans un environnement de homelab. Cela dit, certains utilisateurs expérimentés préfèrent kubeadm même à la maison pour éviter tout comportement spécifique à un fournisseur et avoir tout sous contrôle. Cela dépend vraiment de l’effort que nous souhaitons investir. Pour la plupart, kubeadm est trop lourd pour un petit cluster où la haute disponibilité n’est pas une préoccupation.
Autres options : Il existe quelques autres distributions légères de Kubernetes, comme k0s (par Mirantis) et des outils comme kind (Kubernetes in Docker). Pour la complétude :
- k0s est une autre distribution de Kubernetes à un seul binaire, similaire à K3s/MicroK8s, qui se concentre sur la flexibilité et un empreinte minimale. Il est relativement nouveau mais a des fans dans la communauté des homelabs. Il peut également s’exécuter facilement sur nos 3 nœuds. Il n’a (pour le moment) pas la même grande base d’utilisateurs que K3s/MicroK8s, mais c’est une option à surveiller (surtout si l’idée d’un Kubernetes open source, configurable et minimal vous plaît – certains rapports montrent même que k0s utilise légèrement moins de ressources inactives que K3s/MicroK8s dans des configurations similaires).
- kind est principalement utilisé pour tester des clusters Kubernetes dans des conteneurs Docker (souvent utilisé dans les pipelines CI). Ce n’est pas quelque chose que nous exécuterions comme notre cluster homelab toujours actif – c’est plus pour des clusters éphémères rapides sur une seule machine (similaire à l’objectif de Minikube).
- Rancher Kubernetes Engine (RKE) ou K3d ou d’autres sont également disponibles, mais ceux-ci sont soit orientés vers des clusters conteneurisés (k3d exécute un cluster K3s dans Docker) soit plus complexes en termes de déploiement. Dans un homelab, K3s et MicroK8s ont presque devenus les solutions faciles par défaut.

Conclusion : Pour un homelab avec 3 nœuds correctement configurés, MicroK8s ou K3s sont les choix recommandés pour obtenir un cluster Kubernetes fonctionnel avec un minimum de tracas. Ils nous permettront d’utiliser tous nos nœuds dans un seul cluster, et offriront une prise en charge intégrée des volumes persistants et des services LoadBalancer, ce qui est exactement ce que nous avons demandé. Si nous préférons une solution plus plug-and-play intégrée à Ubuntu, optez pour MicroK8s. Si nous préférons une solution extrêmement légère, éprouvée et soutenue par Rancher, optez pour K3s. Nous aurons un cluster fonctionnel en quelques minutes dans les deux cas. Une fois opérationnel, nous pouvons déployer le tableau de bord Kubernetes ou d’autres outils pour le gérer, et commencer à héberger nos applications avec un stockage persistant et une exposition facile des services. Bonne chance pour votre aventure Kubernetes dans votre homelab !