Vergleich von Kubernetes-Distributionen für ein 3-Knoten-Homelab

Die beste Kubernetes-Variante für unser Homelab auswählen

Inhaltsverzeichnis

Ich vergleiche selbstgehostete Kubernetes-Varianten, die für ein auf Ubuntu basierendes Homelab mit 3 Knoten (16 GB RAM, 4 Kerne pro Knoten) geeignet sind, wobei der Fokus auf einfacher Einrichtung und Wartung, Unterstützung für Persistent Volumes und LoadBalancer liegt.

Szenario: Wir haben drei Ubuntu-Knoten (16 GB RAM, 4 CPU-Kerne pro Knoten) in einem Homelab. Hochverfügbarkeit (HA) und ARM-Unterstützung sind keine Prioritäten. Wir möchten einen einfach zu installierenden, wartungsarmen Kubernetes-Cluster (entweder Single-Node oder 3-Node) mit Unterstützung für Persistent Volumes (PV) und LoadBalancer (LB)-Dienste (damit cloud-native Anwendungen, die Speicher oder externe IPs benötigen, reibungslos funktionieren). Wir werden uns auf 3-Node-Cluster-Optionen ohne HA- oder ARM-CPU-Kompatibilitätsanforderungen konzentrieren.

kubernetes homelab

Unten vergleichen wir beliebte leichte [Kubernetes(https://www.glukhov.org/de/post/2024/10/kubernetes-cheatsheet/ “Liste und Beschreibung der häufigsten und nützlichsten k8s-Befehle - k8s-Cheatsheet”)-Distributionen – K3s, MicroK8s, Minikube und kubeadm (Vanilla Kubernetes) – und wie sie sich auf die wichtigsten Kriterien (Funktionen, Installation/Wartung, PV/LB-Unterstützung, Ressourcenanforderungen, Cluster-Einrichtung und Tooling) schlagen. Auch haben wir einige Empfehlungen, welche man basierend auf dem Homelab-Szenario wählen sollte.

K3s (Ranchers leichtgewichtige Kubernetes-Distribution)

Wichtige Merkmale: K3s ist eine CNCF-zertifizierte Kubernetes-Distribution, die für minimalen Ressourcenverbrauch entwickelt wurde (sie kann mit so wenig wie 512 MB RAM laufen). Sie packt die gesamte Kubernetes-Steuerungsebene in eine einzelne Binärdatei und einen Prozess, wobei leichtgewichtige Komponenten (z. B. SQLite-Datenspeicher standardmäßig anstelle von etcd, Flannel für das Netzwerk) verwendet werden. Sie enthält sinnvolle Standardeinstellungen wie einen eingebauten Ingress-Controller (Traefik) und einen einfachen Service-LoadBalancer. K3s entfernt veraltete/Alpha-Funktionen, um Bloatware zu reduzieren.

  • Einfachheit der Installation & Wartung: Extrem einfach - wir können es mit einem einzeiligen Skript (curl ... | sh) oder über Tools wie K3sup installieren. Der Server startet mit Standardkomponenten aus der Box. Das Hinzufügen von Knoten ist unkompliziert (führen Sie den K3s-Agenten mit einem Token vom Server aus). Das Upgraden ist einfach (ersetzen Sie die Binärdatei oder verwenden Sie das Installationsskript für die neue Version). Keine separate etcd-Einrichtung erforderlich (außer Sie wählen eine Multi-Master-HA-Einrichtung). K3s ist so konzipiert, dass es nach der Installation minimalen Aufwand erfordert, was es bei IoT und Homelabs beliebt macht.

  • Unterstützung für Persistent Volumes: Eingebaut. Standardmäßig liefert K3s mit Ranchers local-path StorageClass, die PVs dynamisch auf dem Host-Dateisystem für jede PVC bereitstellt. Das bedeutet, dass jede PVC durch das Erstellen eines hostPath-Volumes auf dem Knoten automatisch erfüllt wird. Es ist eine Single-Node-Speicherlösung (jedes Volume befindet sich auf der Festplatte eines Knotens), aber es funktioniert aus der Box für stateful-Anwendungen. Für fortgeschrittenen Speicher können Sie etwas wie Ranchers Longhorn (verteilte Blockspeicherung) hinzufügen, das K3s unterstützt, aber für ein Homelab reicht der Standard-local-path-Provisioner in der Regel aus.

  • LoadBalancer-Unterstützung: Eingebaut. K3s enthält einen leichtgewichtigen Controller namens ServiceLB (früher „Klipper LB“), der es ermöglicht, dass Dienste vom Typ LoadBalancer eine IP/port auf dem Host ohne einen externen Cloud-Anbieter erhalten. Wenn wir einen LoadBalancer-Dienst erstellen, setzt K3s einen DaemonSet von kleinen LB-Pods (svc-...) auf jedem Knoten ein, die Host-Ports verwenden, um den Verkehr zum Dienst weiterzuleiten. Im Wesentlichen nutzt K3s die IP des Knotens (intern oder extern) als LB-IP und verwendet iptables-Routing in den LB-Pods, um den Verkehr zur ClusterIP des Dienstes zu senden. Dies funktioniert mit null Konfiguration – Dienste werden nicht „pending“ bleiben (im Gegensatz zu Vanilla K8s auf Bare Metal). Der Kompromiss besteht darin, dass die externe LB-IP eine der IPs unserer Knoten (oder aller Knoten) sein wird und wir sicherstellen müssen, dass der Port frei ist. Für die meisten Homelab-Anwendungen (Freigabe einiger Dienste auf HTTP/HTTPS-Ports) ist dies perfekt in Ordnung. Wenn nötig, können wir den eingebauten LB deaktivieren und MetalLB manuell installieren, aber die meisten Benutzer bleiben bei der bequemen Standardeinstellung.

  • Ressourcenanforderungen: Sehr gering. K3s kann sogar auf Low-End-Hardware laufen. Offiziell sind 512 MB RAM und einige hundert MB Festplatte ausreichend für einen Server-Knoten. In der Praxis könnte ein kleiner Cluster einige hundert MB Speicher für die Steuerungsebene verwenden. Seine Binärdatei ist <100 MB. Der CPU-Overhead ist minimal (K3s verwendet etwas mehr CPU im Leerlauf im Vergleich zu MicroK8s, aber nicht um einen großen Betrag). Unsere Knoten (16 GB pro Knoten) sind mehr als genug, um K3s bequem auszuführen.

  • Single-Node vs Multi-Node: Geeignet für beides. K3s kann Single-Node (alle Steuerungsebenen und Arbeitslasten auf einer Maschine) oder Multi-Node laufen. Für eine 3-Node-Einrichtung könnten wir 1 Server (Master) und 2 Agenten laufen lassen oder sogar alle 3 zu Servern für HA machen (nicht nötig hier, da HA kein Ziel ist). Das Hinzufügen von Agenten ist trivial mit dem Token. Der Standard-SQLite-Datenspeicher von K3s funktioniert für Single-Server; für Multi-Server-HA würden wir zu eingebettetem etcd wechseln (K3s kann dies automatisch tun, wenn mehrere Server-Knoten gestartet werden).

  • CLI & UI-Tools: Wir interagieren mit K3s genau wie mit jedem Kubernetes – über kubectl. K3s enthält seine eigene kubectl-Build (wir können k3s kubectl ... ausführen oder einfach ein Standard-kubectl verwenden, indem wir es auf die K3s-kubeconfig verweisen). Es gibt keine spezielle K3s-spezifische CLI über die Installationsbefehle hinaus; es ist absichtlich minimalistisch. Es ist kein eingebautes Web-UI enthalten (das Upstream-Dashboard wird standardmäßig nicht installiert). Allerdings können wir das Kubernetes-Dashboard oder andere Tools auf K3s genau wie bei einem Standard-Cluster manuell bereitstellen. Rancher (das GUI-Verwaltungstool desselben Unternehmens) kann auch auf K3s installiert werden, wenn eine vollständige UI gewünscht ist, aber es ist nicht Teil von K3s selbst. Im Wesentlichen bietet K3s die Kern-K8s-APIs und wir fügen Extras hinzu, wie wir sie benötigen (Ingress, Speicher usw. – einige davon sind bereits wie erwähnt gebündelt).

MicroK8s (Canonicals Low-Ops Kubernetes)

Wichtige Merkmale: MicroK8s ist Canonicals leichtgewichtige Kubernetes-Distribution, die als Snap-Paket geliefert wird. Es installiert einen vollständig konformen Kubernetes-Cluster (Upstream-Binärdateien) mit einem einzigen Befehl und ist für die Einfachheit der Bedienung („Low Ops“) auf einem einzelnen Gerät oder einem kleinen Cluster entwickelt. Es betont einen „Batteries-included“-Ansatz – wir erhalten viele optionale Funktionen, die mit einfachen Befehlen aktiviert werden können. MicroK8s standardisiert auf eine Vanilla-Kubernetes-Erfahrung (alle Standard-APIs) mit praktischen Add-ons für häufige Bedürfnisse. Es unterstützt sowohl Single-Node- als auch Multi-Node-Installationen (wir können einen Cluster bilden, indem wir „Knoten hinzufügen“), und es hat sogar einen HA-Modus für die Steuerungsebene (unter Verwendung von Dqlite – einem verteilten SQLite – wenn wir 3 Master haben).

  • Einfachheit der Installation & Wartung: Extrem einfach - einfach snap install microk8s --classic auf einem Ubuntu-Gerät wird einen Kubernetes-Knoten einrichten. Es ist ein Paket, das alle Komponenten enthält. MicroK8s wird über Ubuntu’s Snap-System verwaltet, was bedeutet, dass Updates atomar und automatisch sein können (wir können einen Kanal für Kubernetes-Versionen verfolgen). Diese automatische Update-Fähigkeit ist einzigartig unter diesen Optionen - wir können sich für die Erhaltung von Sicherheitsupdates und kleineren Upgrades über Snap-Aktualisierungen entscheiden. Die Verwaltung von MicroK8s erfolgt über den microk8s-Befehl, der Unterbefehle zum Aktivieren/Deaktivieren von Funktionen hat. Insgesamt ist es sehr reibungslos: keine Container oder VMs zu verwalten (läuft nativ auf dem Host), und kein externes etcd zu konfigurieren (verwendet einen internen Datenspeicher). Die Wartung besteht hauptsächlich aus dem Aktualisieren des Snaps bei Bedarf und der Verwendung von microk8s.status zur Überwachung.

  • Unterstützung für Persistent Volumes: Verfügbar über Add-on. Standardmäßig stellt MicroK8s keine PVs automatisch bereit, bis wir das „hostpath-storage”-Add-on aktivieren. Durch Aktivieren dieses (mit microk8s enable hostpath-storage) wird eine Standard-StorageClass erstellt, die Volumes aus einem Verzeichnis auf dem Host zuweist. Dies ist im Wesentlichen ein dynamischer hostPath-Provisioner, ähnlich im Konzept zu K3s’s local-path. Sobald aktiviert, bindet jede PVC an ein hostpath-PV auf dem MicroK8s-Knoten. (In einem Multi-Node-MicroK8s-Cluster wird sich das hostpath-PV auf einem Knoten befinden – geeignet für Tests oder Homelab-Nutzung, aber nicht für verteilte Speicherung). MicroK8s bietet auch Mayastor und andere Speicher-Add-ons an, wenn wir fortgeschrittenen Speicher über Knoten hinweg wünschen, aber für die Einfachheit funktioniert der hostpath-Speicher gut. Hinweis: Das Add-on ist nicht standardmäßig aktiviert (um die Dinge schlank zu halten), also werden wir es aktivieren müssen, um PVCs zum Laufen zu bringen. Canonical weist darauf hin, dass dies nicht für die Produktion von HA geeignet ist (da es nicht repliziert wird), aber für ein Homelab ist es perfekt.

  • LoadBalancer-Unterstützung: Verfügbar über Add-on. MicroK8s enthält keinen Standard-LoadBalancer, bietet aber MetalLB als einfaches Add-on. Durch Ausführen von microk8s enable metallb:<start-IP>-<end-IP> wird MetalLB im Layer 2-Modus bereitgestellt und wir können einen Pool von IPs aus Ihrem LAN für LoadBalancer-Dienste angeben. Sobald aktiviert, erhält jeder Dienst vom Typ LoadBalancer automatisch eine IP aus diesem Bereich (und MicroK8s wird sie über ARP im LAN bekannt geben). Dies gibt eine cloudähnliche Erfahrung auf Bare Metal. (Wenn wir MetalLB nicht aktivieren, bleibt ein LoadBalancer-Dienst im Status „pending“, da MicroK8s selbst keinen implementiert – genau wie Upstream-Kubernetes.) In einem Homelab ist MetalLB einfach und ermöglicht den Zugriff auf Dienste in unserem lokalen Netzwerk. Wir müssen ein freies Subnetz oder einen IP-Bereich in unserem Netzwerk dafür auswählen. Der Enable-Befehl von MicroK8s macht die Einrichtung schmerzfrei, aber es ist trotzdem ein separater Schritt. (Im Gegensatz dazu funktioniert K3s aus der Box für LB, aber mit der Einschränkung, dass Knoten-IPs/Ports verwendet werden.) Viele MicroK8s-Benutzer aktivieren MetalLB einfach als Teil ihrer anfänglichen Einrichtung für einen funktionsfähigen LB.

  • Ressourcenanforderungen: MicroK8s ist recht leichtgewichtig, wenn auch etwas größer als K3s im Fußabdruck. Es führt alle Kernservices (API-Server, Controller, Scheduler, Kubelet, etcd oder Dqlite) nativ aus. Der Leerlaufverbrauch beträgt typischerweise \ 500–600 MB RAM für die Steuerungsebene, abhängig davon, welche Add-ons aktiviert sind. Canonical gibt \ 540 MB Grundspeicher an. Die CPU-Nutzung ist im Leerlauf gering, und unsere 16 GB-Knoten haben reichlich Spielraum. Die Festplattenanforderung ist gering (Snap \ 200 MB plus etcd-Daten). Insgesamt kann MicroK8s auf bescheidener Hardware laufen (es wird sogar für Raspberry Pis angeboten), und in unserem Szenario nehmen die Maschinen es leicht auf. Wenn mehrere Add-ons aktiviert sind (Dashboard, Überwachung usw.), wird der Ressourcenverbrauch entsprechend steigen.

  • Single-Node vs Multi-Node: MicroK8s funktioniert gut für beides. Wir können es für einen Single-Node-Cluster (z. B. auf einem Entwicklungsgerät oder einem Server) verwenden oder einen Multi-Node-Cluster erstellen, indem wir „Knoten hinzufügen“. Die MicroK8s-Dokumentation bietet einen Befehl zum Hinzufügen eines Knotens (wir holen uns ein Join-Token vom ersten Knoten und verwenden es auf den anderen). In einer Multi-Node-Einrichtung ohne HA wird ein Knoten die primäre Steuerungsebene sein. Mit 3 Knoten haben wir auch die Option, den ha-cluster-Modus zu aktivieren (die Steuerungsebene wird durch das Ausführen von Dqlite auf 3 Knoten hochverfügbar gemacht), obwohl in unserem Fall HA nicht benötigt wird. Ob Single-Node oder drei Knoten, die Erfahrung ist dieselbe Kubernetes-API. Multi-Node-MicroK8s ist etwas neuer als K3s’s Ansatz, aber jetzt recht stabil. Es ist eine gute Wahl, wenn wir eine „Micro-Cloud“ aus einigen Ubuntu-Boxen mit minimalem Aufwand betreiben möchten.

  • CLI & UI-Tools: MicroK8s kommt mit dem microk8s-Befehlszeilen-Tool, das sehr praktisch ist. Zum Beispiel schaltet microk8s enable <addon> verschiedene Dienste (DNS, Ingress, Speicher, metallb, Dashboard usw.), und microk8s status zeigt an, was läuft. Es enthält auch ein eingebettetes kubectl: wir können microk8s kubectl ... verwenden (oder es als Alias setzen), das mit dem Cluster spricht – das ist schön, weil wir keine kubeconfig konfigurieren müssen. Für die UI bietet MicroK8s das Kubernetes-Dashboard als Add-on (microk8s enable dashboard), das das Standard-Web-UI bereitstellt. Sobald aktiviert, können wir darauf zugreifen (es läuft auf Port 10443 oder über Proxy). MicroK8s hat keine eigene benutzerdefinierte GUI – es verlässt sich auf das Kubernetes-Dashboard oder andere Tools – aber die Einfachheit der Aktivierung ist ein Pluspunkt. Zusammenfassend betont MicroK8s eine One-Command-Erfahrung für häufige Aufgaben und eine „es funktioniert einfach“-Philosophie, die viel Komplexität abstrahiert (zum Preis des Versteckens einiger Interna). Dies macht es sehr homelab-freundlich für diejenigen, die einen Kubernetes-Cluster ohne manuelle Einrichtung jedes einzelnen Bestandteils wünschen.

Kontrast K3s vs MicroK8s: Beide sind sich in ihren Zielen und Fähigkeiten sehr ähnlich – leichtgewichtig, einfach, multi-node-fähig. K3s neigt dazu, etwas mehr „DIY“ zu sein, wenn Extras hinzugefügt werden (Verwendung von Helm-Charts oder manuellen Manifesten für Dinge, die nicht enthalten sind), während MicroK8s eingebaute Add-ons über seine CLI bietet. MicroK8s ist auch ein etwas „vanilla“-Kubernetes unter der Haube (Upstream-Komponenten, einfach als Snap verpackt), während K3s einige benutzerdefinierte Binärdateien und einen einzigen Dienst für alles verwendet. Beide sind gute Wahl für ein Homelab; die Entscheidung fällt oft auf die Vorlieben: wenn Ubuntu/snaps und ein integriertes Gefühl bevorzugt werden, ist MicroK8s großartig, während wenn wir einen minimalistischen Ansatz mit etwas mehr manueller Kontrolle bevorzugen, ist K3s ausgezeichnet. (Wir werden Empfehlungen am Ende geben.)

Minikube (Einzelknoten-Lokales K8s)

Wichtige Merkmale: Minikube ist hauptsächlich ein Tool zum Ausführen von Kubernetes lokal (oft auf dem PC oder Laptop eines Entwicklers) anstatt eines traditionellen Clusters über mehrere Maschinen hinweg. Es erstellt einen Einzelknoten-Kubernetes-Cluster in einer VM oder einem Container auf unserer Maschine. Minikube ist für seine breite Unterstützung von Umgebungen bekannt – es kann auf Linux, macOS, Windows laufen und unterstützt verschiedene Hypervisoren (VirtualBox, KVM, Hyper-V, Docker-Treiber usw.). Es wird von den Kubernetes SIGs gepflegt und wird oft zum Testen und Lernen verwendet. Obwohl Minikube kann in eine Multi-Knoten-Konfiguration gezwungen werden, ist es im Wesentlichen für Einzelknoten-Cluster gedacht (der „Multi-Knoten“-Modus von Minikube startet tatsächlich mehrere Knoten auf demselben Host unter Verwendung von Container-Runtimes – nützlich zum Simulieren eines Clusters, aber nicht zum Ausführen auf separaten physischen Maschinen).

  • Einfachheit der Installation & Nutzung: Minikube ist sehr einfach zu starten auf einer einzelnen Maschine. Wir installieren die Minikube-Binärdatei, stellen sicher, dass wir einen VM-Treiber (oder Docker) haben, und führen minikube start aus. Dies wird eine lokale VM/Container einrichten und Kubernetes darin starten. Es ist wahrscheinlich der einfachste Weg, einen Kubernetes-Cluster zum ersten Mal zum Laufen zu bringen. Die CLI (minikube) bietet Befehle, um mit der VM zu interagieren (starten, stoppen, löschen) und Add-ons zu aktivieren. Da Minikube für die lokale Nutzung konzipiert ist, ist es kein „lange laufender“ Daemon – wir starten es in der Regel, wenn wir es benötigen, und stoppen es, wenn wir fertig sind, obwohl wir es können kontinuierlich auf einem Homelab-Server laufen lassen, wenn gewünscht. Wartung/Aktualisierungen sind einfach: einfach die Minikube-Version aktualisieren und den Cluster neu starten (Minikube kann auch die Kubernetes-Version, die es ausführt, mit einer Flagge aktualisieren). Allerdings hat Minikube eine Einschränkung: es ist einzelknoten per Design (das Hinzufügen weiterer Knoten bedeutet das Starten zusätzlicher VM-Instanzen auf demselben Host, nicht das Verbinden echter separater Hosts). Daher würde die Verwendung von Minikube auf drei separaten physischen Knoten im Wesentlichen bedeuten, drei unabhängige Einzelknoten-Cluster zu betreiben, was wahrscheinlich nicht das ist, was wir wollen. Minikube glänzt für Entwicklung und Tests auf einer Maschine, aber es ist nicht dafür gedacht, einen Cluster zu verwalten, der über mehrere physische Server verteilt ist.

  • Unterstützung für Persistente Volumes: Integriert (hostPath). Minikube-Cluster enthalten standardmäßig eine Standard-StorageClass, die einen hostPath-Provisioner verwendet. Tatsächlich führt Minikube einen kleinen Controller aus, der dynamisch hostPath-PVs innerhalb der VM erstellt, wenn PVCs angefordert werden. Das bedeutet, wir können PersistentVolumeClaims erstellen und sie werden mit Speicher auf dem Dateisystem der Minikube-VM erfüllt (in der Regel unter /tmp/hostpath-provisioner oder ähnlich). Dies funktioniert sofort – keine Konfiguration ist für die grundlegende PV-Nutzung erforderlich. Zum Beispiel entspricht die Standard-„standard“-StorageClass in Minikube dem hostPath-Speicher auf dem Knoten. Ein Hinweis: Wenn wir die Minikube-VM neu starten oder löschen, könnten diese hostPath-Volumes verloren gehen (Minikube versucht, bestimmte Verzeichnisse über Neustarts hinweg zu erhalten – z. B. /data, /var/lib/minikube, /tmp/hostpath* werden beibehalten). Aber im Allgemeinen ist dies für eine Nicht-Produktionsumgebung in Ordnung. Wenn wir mehr simulieren möchten, hat Minikube auch ein CSI hostpath driver Addon, das Snapshots unterstützt und im Multi-Knoten-Modus funktionieren kann, aber das ist eher für Experimente. Fazit: Minikube unterstützt PVs standardmäßig über hostPath, was für einen Homelab-Test von zustandsbehafteten Apps ausreicht.

  • LoadBalancer-Unterstützung: Unterstützt über Tunneling (oder MetalLB Addon). In einer Cloud erhält ein LoadBalancer-Service einen Cloud-LB mit einer externen IP. In Minikube gibt es offensichtlich keinen Cloud-Anbieter, daher bietet Minikube zwei Mechanismen:

    • Minikube Tunnel: Wir können minikube tunnel in einem separaten Prozess ausführen, der eine Netzwerkroute auf unserem Host erstellt und eine IP für unseren LoadBalancer-Service zuweist. Im Wesentlichen verwendet es unseren Host als „externen LB“. Wenn wir einen LoadBalancer-Service erstellen, zeigt Minikube eine „externe IP“ (in der Regel aus dem Subnetz des Clusters) an, und der minikube tunnel-Prozess leitet diesen an den Service weiter. Dies erfordert, dass der Tunnel-Prozess weiterläuft (und typischerweise Root-Rechte zum Erstellen von Routen). Es ist ein etwas manueller Schritt, aber Minikube erinnert uns daran, wenn wir einen LoadBalancer-Service ohne laufenden Tunnel haben („External-IP pending“ bis wir den Tunnel starten).
    • MetalLB Addon: Neuere Versionen von Minikube enthalten auch ein MetalLB Addon. Wir können minikube addons enable metallb ausführen und einen IP-Bereich konfigurieren (Minikube wird uns dazu auffordern). Dies installiert effektiv MetalLB innerhalb des Minikube-Clusters, das dann LoadBalancer-Services genau wie auf einem bare-metal Kubernetes handelt. Dies ist eine „in-Cluster“-Lösung und erfordert keinen separaten Tunnel-Prozess nach der anfänglichen Einrichtung.

    Beide Optionen funktionieren, und die Wahl liegt bei uns. Für eine schnelle Freigabe eines Dienstes ist minikube tunnel schnell und vorübergehend. Für eine dauerhaftere Einrichtung kann das MetalLB Addon aktiviert werden, sodass LBs echte IPs erhalten (z. B. könnten wir ihm einen Bereich wie 10.0.0.240-250 auf einem Minikube mit Bridging-Netzwerk zuweisen). Denken Sie daran, dass Minikube typischerweise ein einzelknoten ist, sodass der „Load Balancer“ nicht über mehrere Knoten hinweg ausgleicht – er stellt nur den externen Zugriff auf den Service des einzelnen Knotens bereit. Das ist für die Entwicklung in Ordnung. In einem Homelab, wenn wir nur einen unserer Knoten verwenden und Minikube darauf ausführen, könnten wir diese verwenden, um auf unsere Apps zuzugreifen. Aber wenn wir alle 3 Knoten nutzen möchten, ist Minikubes Ansatz für LB nicht für dieses Szenario gedacht.

  • Ressourcenanforderungen: Minikube selbst ist leichtgewichtig, aber da es in der Regel einen vollständigen Einzelknoten-Kubernetes (in einer VM) ausführt, ist der Ressourcenverbrauch ähnlich wie bei einem normalen kleinen Cluster. Die empfohlene Mindestgröße beträgt 2 GB RAM und 2 CPUs für die VM. Standardmäßig weist Minikube oft 2 GB RAM für seine VM zu. In unserem Fall mit 16 GB pro Maschine ist das trivial. Ein inaktives Minikube (Kubernetes) könnte \ 600 MB Speicher verwenden. Etwas zu beachten ist, dass Minikube über unserem Betriebssystem läuft – entweder als VM über einen Hypervisor oder einen Docker-Container – was einige Überhead verursacht. Auf einem Homelab-Server könnten wir Minikube mit dem „none“-Treiber ausführen (der Kubernetes-Komponenten direkt auf dem Host installiert). Allerdings ist der „none“ (auch bekannt als bare-metal)-Treiber im Wesentlichen ähnlich wie die Verwendung von kubeadm auf diesem Knoten und erfordert manuelle Bereinigung, daher ist er nicht so beliebt. Die meisten verwenden einen VM- oder Docker-Treiber. Zusammenfassend gesagt, jeder unserer Homelab-Knoten kann Minikube leicht ausführen. Die einzige Einschränkung ist, dass Minikube nicht die Ressourcen aller 3 Knoten nutzen wird – es wird auf den einzelnen Host beschränkt sein, auf dem es läuft (außer bei der experimentellen Multi-Knoten-Funktion innerhalb eines Hosts).

  • Einzelknoten vs. Multi-Knoten: Primär Einzelknoten. Minikube ist ideal für einen Einzelknoten-Cluster auf einer Maschine. Es hat eine Funktion, um mehrere Knoten zu simulieren (z. B. minikube start --nodes 3 mit dem Docker-Treiber wird 3 Kubernetes-Knoten als Container auf einem Host starten), aber dies dient nur zum Testen. Wir können Minikube nicht verwenden, um einen echten Multi-Knoten-Cluster über 3 separate physische Server zu erstellen. Wenn wir 3 Maschinen haben, müssten wir 3 unabhängige Minikube-Instanzen ausführen (nicht in einem Cluster). Das ist keine echte Cluster-Erfahrung (sie werden nicht voneinander wissen). Daher ist Minikube nicht empfohlen, wenn unser Ziel darin besteht, alle drei Knoten in einem Kubernetes-Cluster zu nutzen – es ist besser für Szenarien, in denen wir nur eine Maschine (unseren PC oder einen Server) haben und K8s darauf ausführen möchten. Es ist auch großartig, um die Grundlagen von Kubernetes zu lernen und lokale Entwicklung durchzuführen.

  • CLI- & UI-Tools: Die minikube CLI ist die Hauptschnittstelle. Wir verwenden sie, um den Cluster zu starten/stoppen, und sie hat nützliche Abkürzungen: z. B. minikube dashboard aktiviert das Kubernetes-Dashboard und öffnet es in unserem Browser für uns. minikube addons enable <addon> kann eine Vielzahl von optionalen Komponenten aktivieren (Ingress, metallb, metrics-server usw.). Minikube richtet den kubectl-Zugriff automatisch ein (es konfiguriert einen Kontext „minikube“ in unserer kubeconfig). Für die UI, wie erwähnt, ist das Kubernetes-Dashboard leicht über den dashboard-Befehl zugänglich. Minikube hat keine eigene einzigartige Web-UI; es verlässt sich auf Standard-Tools. Das Debuggen von Minikube ist auch einfach, da wir minikube ssh verwenden können, um auf den Knoten-VM zuzugreifen, wenn nötig. Insgesamt sind die Tools sehr benutzerfreundlich für ein Einzelknoten-Szenario.

Kubeadm (Vanilla Kubernetes auf unseren eigenen Knoten)

Wichtige Merkmale: Kubeadm ist keine „Distribution“, sondern vielmehr das offizielle Toolkit zum Erstellen eines Kubernetes-Clusters von Grund auf. Die Verwendung von kubeadm bedeutet, dass wir Standard-Upstream-Kubernetes-Komponenten auf unseren Maschinen bereitstellen. Es ist im Wesentlichen, wie wir „unseren eigenen“ Cluster erstellen, wobei wir den Best Practices folgen, aber ohne die Extras, die Distributionen enthalten. Kubeadm wird einen Control-Plane-Knoten (der etcd, API-Server, Controller-Manager, Scheduler ausführt) einrichten und Worker-Knoten mit ihm verbinden. Das Ergebnis ist ein vollständig standardmäßiger Kubernetes-Cluster, identisch zu dem, was wir auf Cloud-VMs erhalten würden. Dieser Ansatz gibt uns volle Kontrolle und Flexibilität – wir wählen das Netzwerk-Plugin, den Speicher-Provisioner usw. – erfordert aber die meisten manuellen Arbeit und Know-how von Anfang an. Es wird oft in Produktions- oder Lernumgebungen verwendet, um die Kubernetes-Internals zu verstehen.

  • Einfachheit der Installation & Wartung: Im Vergleich zu den anderen ist kubeadm am aufwendigsten. Wir müssen Abhängigkeiten manuell installieren (Container-Runtime wie containerd, kubeadm, kubelet, kubectl) auf jedem Knoten. Dann führen wir kubeadm init auf dem Master aus und kubeadm join auf den Workern mit dem Token, das es gibt. Wir müssen auch ein CNI (Network-Plugin) nach der Initialisierung einrichten (Calico, Flannel usw.), da kubeadm standardmäßig keines installiert. Es gibt gut dokumentierte Schritte für all dies (der Prozess ist nicht schwer, aber es sind viele Schritte) – im Wesentlichen bringt kubeadm uns einen Startcluster, aber es erwartet von uns, dass wir die Add-ons handhaben. Bei der Wartung sind wir für Upgrades verantwortlich (kubeadm hat einen Upgrade-Befehl, aber wir müssen Knoten entleeren, Binärdateien aktualisieren usw. manuell), sowie für die Überwachung der etcd-Gesundheit, Zertifikatsverlängerungen usw. Kurz gesagt, kubeadm ist mächtig, aber manuell. Es wird oft „der harte Weg“ genannt (obwohl es nicht so schwer ist wie das Erstellen aus der Quelle). Für einen Hobby-Homelab-Benutzer, der das Lernen genießt, ist kubeadm eine großartige Möglichkeit, Kubernetes tiefgehend zu verstehen. Aber wenn unsere Priorität „einfach und wartungsarm“ ist, wird kubeadm mehr Arbeit als K3s/MicroK8s sein. Jedes Upgrade oder jede Änderung erfordert manuellen Aufwand. Das gesagt, sobald es eingerichtet ist, ist es das echte Ding: ein Standard-Kubernetes-Cluster ohne versteckte Abstraktionen.

  • Unterstützung für Persistente Volumes: Keine standardmäßig (muss manuell hinzugefügt werden). Ein mit kubeadm installierter Cluster ist im Wesentlichen ein leerer Kubernetes – er enthält keine Standard-StorageClass oder dynamischen Provisioner von Haus aus. In Cloud-Umgebungen würde der Cloud-Anbieter normalerweise eine Standard-StorageClass bereitstellen (z. B. AWS EBS usw.), aber in einer Homelab-Bare-Metal-Umgebung müssen wir unsere eigene Lösung installieren. Gängige Ansätze:

    • HostPath Provisioner: Wir können das nachahmen, was K3s/Minikube tun, indem wir etwas wie den Rancher Local Path Provisioner installieren (der ein kleiner Controller + StorageClass ist, der hostPath-PVs erstellt). Dies ist ein einfaches Add-on (nur ein YAML-Manifest) und gibt uns lokalen dynamischen Speicher.
    • NFS oder NAS: Einige Homelab-Benutzer richten einen NFS-Server ein (oder verwenden ein NAS) und verwenden dann statische PVs oder einen NFS-CSI-Treiber für die Bereitstellung.
    • OpenEBS/Longhorn/Ceph: Es gibt komplexere Optionen wie die Bereitstellung von Longhorn oder Ceph RBD über Rook, wenn wir verteilten Speicher über Knoten wünschen. Diese erfordern mehr Ressourcen und Komplexität.

    Der entscheidende Punkt ist, dass kubeadm uns den Speicher nicht „löst“ – wir müssen ihn entscheiden und konfigurieren. Wenn die Einfachheit Priorität hat, ist der einfachste Weg, einen hostPath-Provisioner bereitzustellen oder NFS zu verwenden. Zum Beispiel kann der local-path provisioner von Rancher in ein paar kubectl apply-Befehlen installiert werden und wird das Verhalten von K3s nachahmen (Volumes unter /var/lib/rancher/ auf dem jeweiligen Knoten erstellen). Aber das ist ein manueller Schritt. Bis wir das tun, wird jeder PVC, den wir erstellen, im Zustand „Pending“ bleiben, weil Kubernetes keine Standard-Bereitstellung hat. Daher unterstützt kubeadm zwar dynamische PV, aber die Unterstützung ist so gut wie die Mühe, die wir in die Einrichtung stecken.

  • LoadBalancer-Unterstützung: Keine standardmäßig (muss manuell hinzugefügt werden). Ähnliche Geschichte hier: In einem traditionellen On-Premise-Cluster haben wir keine eingebaute LoadBalancer-Implementierung. Wenn wir einen Service vom Typ LoadBalancer auf einem einfachen kubeadm-Cluster erstellen, wird er für immer im Zustand pending bleiben, bis wir einen Controller bereitstellen, der ihn behandelt. Die gängige Lösung ist, MetalLB selbst zu installieren. MetalLB kann über Manifest oder Helm-Chart installiert werden – wir würden einen IP-Bereich konfigurieren und es würde dann diese IPs für LoadBalancer-Services zuweisen (genau wie in MicroK8s). Es gibt viele Anleitungen zur Installation von MetalLB auf kubeadm-Clustern. Eine andere Alternative, die einige verwenden, ist kube-vip für Control-Plane-VIP und Service-LBs, aber MetalLB ist einfacher für Services. Im Wesentlichen haben wir mit kubeadm die Freiheit (oder Last), jeden Load-Balancing-Mechanismus einzurichten, der unseren Bedürfnissen entspricht. Wenn wir keinen einrichten, sind wir auf NodePort-Services für den externen Zugriff beschränkt. Für ein Homelab wird die Installation von MetalLB dringend empfohlen – sie ist einfach und gibt uns diese cloudähnliche Service-IP-Funktionalität. Aber wieder ist das ein zusätzlicher Schritt, den wir durchführen müssen (im Gegensatz zu K3s, das out-of-the-box funktioniert, oder MicroK8s mit einer einfachen Aktivierung).

  • Ressourcenanforderungen: Standard-Kubernetes ist etwas schwerer als die gekürzten Versionen. Jeder Knoten wird einen kubelet und kube-proxy ausführen, und der Master wird etcd und Control-Plane-Komponenten ausführen. Ein einzelner Control-Plane-Knoten kann immer noch mit 2 GB RAM laufen, aber typischerweise möchten wir etwas mehr für den Komfort, wenn wir Pods darauf ausführen. Die padok-Anleitung empfiehlt 2 GB für den Master, 2 GB für den Worker als Minimum. In unserem Szenario (16 GB pro Knoten) ist das in Ordnung. Ein inaktiver etcd und API-Server könnten jeweils einige hundert MB Speicher verwenden. Es gibt keinen großen Unterschied beim Laufzeitverhalten zwischen einem kubeadm-Cluster und MicroK8s – schließlich ist MicroK8s dieselben Komponenten. Der Unterschied besteht nur darin, was standardmäßig läuft (MicroK8s könnte DNS und Speicher standardmäßig aktivieren, während bei kubeadm wir diese installieren würden). Daher sind die Ressourcen bei kubeadm so leicht oder schwer, wie wir es konfigurieren. Mit nichts zusätzlich installiert, könnte es recht leicht sein. Mit einer typischen Einrichtung (z. B. wir fügen CoreDNS, Dashboard usw. hinzu), erwarten Sie \ 1 GB oder so für System-Overheads. Wir haben genug RAM, also sind Ressourcen kein Problem. Es geht mehr um die menschliche Zeit/Ressourcen, die für die Verwaltung erforderlich sind, als um CPU/RAM.

  • Einzelknoten vs. Multi-Knoten: Kubeadm kann beides, mit voller Flexibilität. Wir können einen Einzelknoten-Cluster initialisieren (und sogar kubeadm anweisen, den einzelnen Knoten für die Ausführung von Workloads freizugeben, indem wir den Master entstigmatisieren). Oder wir können einen Master und zwei Worker haben (eine häufige 3-Knoten-Konfiguration). Wir könnten sogar 3 Master und 3 Worker usw. einrichten – jede Topologie. In unserem Fall wäre eine wahrscheinlich kubeadm-Konfiguration 1 Control-Plane-Knoten und 2 Worker (da HA nicht benötigt wird, benötigen wir keine mehreren Master). Das gibt uns einen funktionsfähigen 3-Knoten-Cluster. Der Prozess für Multi-Knoten ist gut dokumentiert: im Wesentlichen Kubernetes auf allen installieren, einen initialisieren, die anderen beitreten lassen. Das Ergebnis ist identisch mit dem, was ein verwalteter Cluster oder eine andere Distribution geben würde: unsere 3 Knoten erscheinen in kubectl get nodes usw. Daher erfüllt kubeadm definitiv die Anforderung „kann alle 3 Knoten nutzen“.

  • CLI- & UI-Tools: Mit kubeadm ist die einzige spezielle CLI kubeadm selbst, die für die Einrichtung und (später) Upgrade-Schritte verwendet wird. Im täglichen Gebrauch verwenden wir kubectl, um den Cluster zu verwalten. Es gibt keine integrierte Verwaltungs-CLI über das hinaus, was Kubernetes bietet. Für die UI ist nichts standardmäßig enthalten – wir können das Kubernetes-Dashboard oder jedes andere Tool manuell bereitstellen (genau wie bei jedem Cluster). Im Wesentlichen gibt uns kubeadm eine leere Kubernetes-Leinwand. Es liegt an uns, darauf zu malen – was die Installation von Bequemlichkeiten wie Dashboard, Ingress-Controllern, Storage-Classes usw. umfasst. Viele Drittanbieter-Dashboards (Lens, Octant usw.) können sich auch mit einem kubeadm-Cluster verbinden, wenn wir ein GUI-Verwaltungserlebnis wünschen, aber diese sind externe Tools. Zusammenfassend gesagt, mit kubeadm erhalten wir die reine Kubernetes-Umgebung – maximale Flexibilität, aber auch die Notwendigkeit, alles so einzurichten, als wäre dies ein Produktionscluster.

  • Kubespray Siehe auch, wie man diese Variante von Kubernetes mit Kubespray installiert.

Seitengleiche Vergleichstabelle

Unten finden Sie eine Zusammenfassung, die die vier Optionen zu den wichtigsten Punkten vergleicht:

Aspekt K3s (Lightweight Rancher K8s) MicroK8s (Canonical „Low-Ops“ K8s) Minikube (Single-Node Dev K8s) Kubeadm (Vanilla Kubernetes)
Installation Einzeilige Installationsskript (einzelne Binärdatei). Wird als einzelner Systemdienst ausgeführt. Sehr schnelle Einrichtung. Ein-Befehl-Installation über Snap auf Ubuntu. Alle Komponenten enthalten. Einfaches Clustering mit microk8s join. Installation des Minikube-CLI, dann minikube start, um einen lokalen VM/Container zu starten. Plattformübergreifend und anfängerfreundlich. Manuelle Installation von kubeadm, kubelet usw. auf jedem Knoten. Ausführen von kubeadm init + kubeadm join mit Voraussetzungen. Beinhaltet mehrere Schritte (Laufzeit, Netzwerk-Plugin usw.).
Wartung & Upgrades Manuelle Upgrades (Ersetzen der Binärdatei oder Verwenden des Installationsskripts für die neue Version). Einfach, da es sich um eine einzelne Binärdatei handelt; wenig zu verwalten. Kein Auto-Update. Snap-Refresh für Updates (kann automatisch erfolgen). Add-ons und Clusterdienste werden über die microk8s-CLI verwaltet. Im Allgemeinen Low-Ops; Auto-Upgrades verfügbar. Einfach zu löschen/neu zu erstellen für die Entwicklung. Upgrades durch Aktualisieren der Minikube-Version und Neustarten des Clusters. Geeignet für temporäre Nutzung (weniger Fokus auf die Langlebigkeit von In-Place-Upgrades). Der Benutzer ist für alle Upgrades verantwortlich. Verwenden Sie kubeadm upgrade, aber Sie müssen die Knoten entleeren, etcd-Sicherungen usw. durchführen. Volle Kontrolle, aber Sie führen die Arbeit aus (keine automatischen Updates).
K8s-Version Folgt dem Upstream relativ eng (oft in Edge-Releases verwendet). CNCF-konform. Einige Funktionen sind standardmäßig deaktiviert (Alpha/Legacy). Folgt den Upstream-Releases (Snap-Kanäle für 1.27, 1.28 usw.). CNCF-konform. Im Wesentlichen Vanilla-K8s-Binärdateien. Wir können die Kubernetes-Version beim Start auswählen (z. B. minikube start --kubernetes-version=v1.27). Standardmäßig die neueste stabile Version. Jede Version, die wir wollen (Installation spezifischer kubeadm/kubelet-Versionen). Vollständiges Upstream-Kubernetes – wir entscheiden über die Version und wann wir aktualisieren.
Standard-Funktionen Gebündelte Standards: Flannel CNI, CoreDNS, Traefik-Ingress, Service-LB, lokale Storage-Klasse, Metrics-Server usw. (Alle können deaktiviert werden, falls nicht benötigt). Minimale Konfiguration erforderlich, um funktionsfähig zu sein. Minimaler Standard: DNS ist in der Regel aktiviert, andere optional. Einfache Ein-Befehl-Add-ons für Ingress (NGINX), MetalLB, Hostpath-Speicher, Dashboard usw. Kann HA-Modus auf 3+ Knoten aktivieren. Gebündelt in VM: typischerweise Docker/containerd-Laufzeit, Kubernetes mit Standard-Add-ons wie StorageProvisioner und DNS. Optionale Add-ons (Ingress, Dashboard usw.) werden über die CLI umgeschaltet. Kein Multi-Node standardmäßig. Sparsam: Nichts über das Kern-Kubernetes hinaus. Kein Ingress, kein Standard-Speicher oder LB, kein Dashboard, bis wir sie installieren. Wir wählen das CNI-Plugin (müssen eines für die Netzwerkkommunikation installieren). Im Wesentlichen ein DIY-Cluster.
Persistent Volume Support Ja – out-of-box. Rancher local-path dynamischer Provisioner enthalten, der HostPath-PVs auf dem Knoten für jede PVC erstellt. Standard-StorageClass „local-path“ verwendet automatisch lokale Festplatte. Ja – einfaches Add-on. Aktivieren Sie hostpath-storage, um eine Standard-StorageClass für dynamische PVs mit HostPath zu erhalten. Bis zur Aktivierung kein Standard-PV-Provisioner. Add-on nicht für Multi-Node-Produktion, aber in Ordnung für Homelab. Ja – out-of-box. Standard-StorageClass verwendet HostPath-Provisioner innerhalb der Minikube-VM. PVCs werden durch einen einfachen Controller erfüllt, der ein HostPath-PV auf dem Dateisystem des Knotens erstellt. Daten bleiben über Neustarts in bestimmten Verzeichnissen erhalten. Nein (manuell). Kein Standard-Provisioner – der Cluster hat zunächst keine StorageClass. Der Benutzer muss eine Speicherlösung installieren (z. B. Local-Path-Provisioner, NFS, Ceph usw.). Grundansatz: Eine HostPath-Provisioner-YAML anwenden, um das zu imitieren, was K3s/Minikube tun. Bis dahin bleiben PVCs in Warteschleife.
LoadBalancer Support Ja – eingebauter ServiceLB. Der servicelb-Controller von K3s (Klipper) überwacht LoadBalancer-Dienste und implementiert Pods auf Knoten, um sie freizugeben. Verwendet die Knoten-IP und Host-Ports, um den Verkehr weiterzuleiten. Funktioniert ohne Konfiguration. Geeignet für kleine Cluster; verwendet die interne/externen Knoten-IP für den Dienst. Ja – über MetalLB-Add-on. Aktivieren Sie metallb mit einem IP-Bereich zur Zuweisung. Bietet einen echten Layer-2-Load Balancer auf Bare Metal. Nicht standardmäßig aktiviert. Sobald aktiviert, erhält jeder LoadBalancer-Dienst eine eindeutige IP aus unserem Pool. Erfordert etwas anfängliche Konfiguration (IP-Bereich). Ja – über Tunnel oder MetalLB. Kein Cloud-LB, aber wir können minikube tunnel ausführen, um LoadBalancer-Diensten eine externe IP zuzuweisen (erstellt eine Route auf dem Host). Alternativ können wir das MetalLB-Addon in Minikube für automatische LB-IPs aktivieren. Standardmäßig werden LB-Dienste „in Warteschleife“ angezeigt, bis wir eine dieser Methoden verwenden. Nein (manuell). Kein eingebauter LB. Typischerweise wird MetalLB manuell für Bare-Metal-LB-Funktionalität installiert. Sobald MetalLB (oder ein anderer LB-Controller) eingerichtet ist, funktionieren LoadBalancer-Dienste. Ohne ihn bleiben LB-Dienste unbestimmt in Warteschleife.
Netzwerk (CNI) Standard = Flannel (Overlay-Netzwerk). K3s unterstützt auch das Ersetzen des CNI, falls erforderlich. Kommt mit CoreDNS für Cluster-DNS. Traefik-Ingress standardmäßig enthalten (kann deaktiviert werden). Standard = Calico (für neuere Versionen im HA-Modus) oder ein unkomplizierter Standard. (MicroK8s verwendete historisch Flannel; neigt jetzt dazu, Calico für strikte Abgrenzung zu verwenden). CoreDNS standardmäßig aktiviert. NGINX-Ingress über Addon (microk8s enable ingress) verfügbar. Standard = kubenet/bridge (abhängig vom Treiber; oft verwendet ein einfaches NAT-Netzwerk). CoreDNS läuft standardmäßig. Wir können ein NGINX-Ingress-Addon aktivieren, falls erforderlich. Die Netzwerkkommunikation ist auf die einzelne VM beschränkt; NodePort ist über minikube ip zugänglich. Wahl des CNI. Kubeadm installiert kein CNI-Plugin – wir müssen eines einsetzen (Calico, Flannel, Weave usw.). Wir haben volle Kontrolle. Die meisten Anleitungen zeigen, dass wir Calico-YAML nach kubeadm init anwenden. CoreDNS wird von kubeadm standardmäßig als Cluster-DNS installiert. Ingress-Controller – wählen und selbst installieren (z. B. NGINX oder Traefik über Manifests/Helm).
Multi-Node-Clustering Ja. Für Multi-Node ausgelegt. Einfaches Hinzufügen mit Token. Kann externe DB oder eingebetteten etcd für Multi-Master verwenden. Ideal für 2-3+ Knoten-Homelabs. Keine zusätzlichen Abhängigkeiten erforderlich – K3s hat sein eigenes Clustering integriert. Ja. Unterstützt das Clustering mehrerer MicroK8s-Knoten (mit microk8s join). Kann HA mit 3+ Masters (Dqlite) aktivieren. Sehr einfach, ein Cluster zu bilden, insbesondere wenn alle Knoten Ubuntu + Snap ausführen. Nein (physisch). Ein-Knoten-Design. Kann Multi-Node auf einem Gerät simulieren (mehrere Knoten in Docker-Containern), aber kann nicht mehrere physische Hosts in einem Cluster überspannen. Verwenden Sie separate Minikube-Instanzen für separate Cluster. Ja. Voll unterstützt Multi-Node (das ist der Zweck). Wir können 1 Master + viele Worker oder sogar mehrere Master haben (obwohl die kubeadm-HA-Konfiguration komplexer ist). Keine eingebaute Begrenzung der Clustergröße.
Ressourcen-Overhead Sehr gering. Steuerungsebene <0,5 GB Speicher im Leerlauf. Ein einzelner Prozess für die Steuerungsebene ergibt einen kleinen Fußabdruck. Effizient bei der CPU (verwendet jedoch möglicherweise etwas mehr CPU im Leerlauf als MicroK8s, laut einigen Berichten). Ideal für Low-Power oder viel freie Kapazität. Gering. 0,5–0,6 GB Speicher für die Steuerungsebene im Leerlauf. Etwas höherer Grundspeicher als K3s, aber bleibt stabil. Verwendet Ubuntu Snap (kann etwas Overhead haben). Immer noch leichtgewichtig im Vergleich zu vollem Kubernetes. Mäßig. VM-Standard 2 GB Zuweisung (Verbrauch \ 0,6 GB im Leerlauf). Führt ein vollständiges Single-Node-Kubernetes sowie die VM-Ebene aus. Kein Problem auf 16-GB-Systemen, verbraucht aber im Wesentlichen Ressourcen eines kleinen Clusters auf einem Gerät. Mäßig. Ein einzelner Master mit einem Worker könnte \ 1 GB im Leerlauf nach dem Hinzufügen typischer Add-ons verbrauchen. Jeder zusätzliche Knoten fügt minimalen Overhead hinzu (nur kubelet, Proxy). Ähnlich wie das Ausführen von Kubernetes in Cloud-VMs vergleichbarer Größe. Auf 3 Knoten mit jeweils 16 GB ist der Overhead im Kontext vernachlässigbar.
CLI-Tools Verwenden Sie k3s für die Installation und als Wrapper für kubectl (oder verwenden Sie den Standard kubectl). Keine separate Verwaltungs-CLI (K3s ist größtenteils „einstellen und vergessen“). Einige Hilfsskripte (z. B. k3s-killall.sh). Ranchers GUI kann bei Bedarf hinzugefügt werden. Reichhaltige microk8s-CLI: z. B. microk8s enable/disable <addon>, microk8s status. Enthält auch microk8s kubectl. Entwickelt, um häufige Aufgaben zu vereinfachen (keine direkte Bearbeitung von Systemmanifesten für die Grundlagen erforderlich). minikube-CLI zum Starten/Stoppen des Clusters, Verwalten der Konfiguration und Add-ons sowie zum Abrufen von Informationen (IP, Service-URL, Protokolle). Bietet auch praktische Befehle wie minikube dashboard. Interagieren Sie mit dem Cluster über kubectl (Konfiguration wird automatisch für den Minikube-Kontext gesetzt). Nur kubeadm für die anfängliche Einrichtung und Upgrades. Tagesgeschäftliche Operationen über Standard kubectl und andere Kubernetes-Tools. Keine distrospezifische CLI über das Bootstrapping hinaus. Sie werden mit rohen Kubernetes-Befehlen und möglicherweise OS-Tools für die Wartung arbeiten.
UI / Dashboard Nicht standardmäßig enthalten. Kann manuell das Kubernetes-Dashboard installieren oder externe Tools verwenden (nichts Rancher-spezifisches, es sei denn, wir fügen Rancher separat hinzu). Der Fokus von K3s liegt auf der headless-Betriebsweise. Nicht standardmäßig enthalten, aber über einen Befehl verfügbar: microk8s enable dashboard installiert die Standard-Dashboard-UI. Einfacher Zugriff auf den Cluster über microk8s dashboard-proxy. Integriert sich auch gut mit der Lens-GUI von Canonical, falls gewünscht (Lens kann direkt auf MicroK8s zugreifen). Nicht standardmäßig aktiviert, aber der Befehl minikube dashboard wird das Dashboard-Web-UI für uns installieren und öffnen. Dies ist für die Bequemlichkeit in der lokalen Entwicklung gedacht – ein Befehl und wir haben eine GUI, um Arbeitslasten zu sehen. Nicht enthalten. Wir können das Dashboard installieren (YAML anwenden), wenn wir es wünschen. Andernfalls verwenden Sie die CLI oder Drittanbieter-Dashboard-Apps. In einem Homelab könnte man das Dashboard installieren und einen NodePort erstellen oder kubectl proxy verwenden, um es anzuzeigen. Kubeadm kümmert sich nicht um UIs.

Quellen: Die oben genannten Daten sind aus offiziellen Dokumentationen und Benutzerhandbüchern zusammengestellt, z. B. Speicher-Fußabdrücke aus dem eigenen Vergleich von MicroK8s, Standard-Speicher in den K3s-Dokumenten, K3s-Service-LB-Verhalten aus der K3s-Dokumentation, MicroK8s-Add-on-Details aus den Canonical-Dokumenten, Minikube-PV und Tunnel aus den Kubernetes-Dokumenten sowie allgemeine Erfahrungsberichte. (Siehe Referenzen für vollständige Zitate.)

Empfehlungen

Gegeben die Prioritäten (Einfachheit der Einrichtung/Wartung und eingebaute Unterstützung für Speicher und Load Balancer) und das Szenario (3 Ubuntu-Knoten, keine Sorge um Hochverfügbarkeit):

  • Top-Auswahlen: K3s oder MicroK8s sind am besten für ein 3-Knoten-Homelab geeignet:

    • Beide sind extrem einfach zu installieren (ein einzelner Befehl auf jedem Knoten) und erfordern minimale laufende Wartung. Sie abstrahieren den Großteil der Komplexität beim Betrieb eines Clusters.
    • Beide unterstützen Multi-Knoten-Clustering aus der Box (wir können unsere 3 Knoten verbinden und einen einheitlichen Cluster sehen).
    • Sie bieten jeweils eine Lösung für Persistent Volumes und LoadBalancer ohne großen Aufwand: K3s enthält sie standardmäßig (Local Path-Speicher, Klipper LB) und MicroK8s macht sie über einfache enable-Befehle verfügbar. Das bedeutet, wir können typische Anwendungen (Datenbanken mit PVCs, Dienste mit type=LoadBalancer) mit minimaler manueller Einrichtung bereitstellen.
    • K3s könnte attraktiv sein, wenn wir den absolut kleinsten Fußabdruck wollen und nichts dagegen haben, seine eingebauten Standardeinstellungen (Traefik-Ingress usw.) zu nutzen. Es ist ein „einrichten und es funktioniert einfach“-Ansatz mit vorgegebenen Standardeinstellungen. Es ist auch sehr beliebt in der Homelab-Community wegen seiner Einfachheit. Wir werden hauptsächlich standardmäßiges kubectl nutzen und können die gepackten Komponenten bei Bedarf anpassen oder deaktivieren. K3s könnte bevorzugt werden, wenn wir nicht auf Ubuntu sind oder das Rancher-Ökosystem mögen (oder planen, später Ranchers Management-UI zu nutzen).
    • MicroK8s könnte attraktiv sein, wenn wir eine Ubuntu-unterstützte Lösung bevorzugen und die Idee mögen, Features mit einem Befehl zu aktivieren. Es ist im Kern im Wesentlichen Vanilla-Kubernetes, was einige leichter erweiterbar finden. Die Add-ons (wie microk8s enable ingress dns storage metallb) können uns in Minuten eine voll funktionsfähige „Micro-Cloud“ verschaffen. MicroK8s handelt auch Updates elegant über Snaps, was schön ist, um unseren Cluster aktuell zu halten ohne manuellen Eingriff (wir können das abschalten oder den Kanal kontrollieren, um Überraschungen zu vermeiden). Wenn wir bereits Ubuntu auf allen Knoten nutzen (was wir tun) und nichts dagegen haben, Snaps zu nutzen, ist MicroK8s eine ausgezeichnete Wahl für einen wartungsarmen Cluster.

    Kurz gesagt: Man kann mit K3s oder MicroK8s in diesem Szenario nichts falsch machen. Beide werden uns ein einfaches, homelab-freundliches Kubernetes mit den benötigten Features geben. Viele Nutzer berichten positive Erfahrungen mit beiden in 2–3 Knoten-Home-Setups. MicroK8s könnte einen leichten Vorteil in der Benutzerfreundlichkeit haben (wegen der Add-ons und Integration), während K3s einen leichten Vorteil in der schlanken Ausführung und Einfachheit unter der Haube haben könnte.

  • Wann Minikube wählen: Wenn wir nur auf einer einzelnen Maschine arbeiten oder einen schnellen wegwerfbaren Entwicklungscluster wollen, ist Minikube dafür fantastisch. Es ist der einfachste Weg, Kubernetes auf einem Laptop oder einem Knoten zum Testen zu starten. Für einen dauerhaften 3-Knoten-Cluster ist Minikube jedoch nicht das richtige Werkzeug – es wird diese 3 Knoten nicht zu einem Cluster zusammenführen. Wir würden unsere Hardware unternutzen oder 3 separate Cluster verwalten, was nicht gewünscht ist. Also, in diesem Homelab mit mehreren Knoten ist Minikube nicht empfohlen als Hauptlösung. Wir könnten Minikube trotzdem auf unserem persönlichen Computer nutzen, um Dinge auszuprobieren, bevor wir sie auf den Homelab-Cluster deployen, aber für den Cluster selbst sollten wir etwas wie K3s/MicroK8s nutzen.

  • Wann Kubeadm wählen: Wenn unser Ziel war, Kubernetes-Internals zu lernen oder volle Kontrolle und eine „produktionsähnliche“ Einrichtung zu haben, ist kubeadm eine gute Übung. Es wird uns zwingen, zu verstehen, wie man CNI, Speicher usw. installiert, und wir werden den Cluster im Wesentlichen Stück für Stück aufbauen. In Bezug auf Benutzerfreundlichkeit ist kubeadm jedoch der am meisten hands-on. Jedes Feature, das wir benötigen (wie Speicher oder LB), müssen wir konfigurieren. Für ein lernorientiertes Homelab könnte das ein Vorteil sein (bildend); für ein einfach-funktionierendes Homelab ist das ein Nachteil. Auch die Wartung wird intensiver sein (insbesondere bei Upgrades). Es sei denn, wir wollen speziell die Vanilla-Kubernetes-Erfahrung zum Lernen oder für spezifische individuelle Bedürfnisse, dann wird die Nutzung von K3s oder MicroK8s uns viel Zeit und Kopfschmerzen in einer Homelab-Umgebung sparen. Das gesagt, bevorzugen einige erfahrene Nutzer auch zu Hause kubeadm, um vendor-spezifische Eigenheiten zu vermeiden und alles unter Kontrolle zu haben. Es hängt wirklich davon ab, wie viel Aufwand wir betreiben wollen. Für die meisten ist kubeadm übertrieben für einen kleinen Cluster, bei dem Hochverfügbarkeit keine Rolle spielt.

  • Andere Optionen: Es gibt einige andere leichte Kubernetes-Varianten wie k0s (von Mirantis) und Tools wie kind (Kubernetes in Docker). Zur Vollständigkeit:

    • k0s ist eine weitere Single-Binary-Kubernetes-Distribution mit ähnlichem Ziel wie K3s/MicroK8s, die sich auf Flexibilität und einen minimalen Fußabdruck konzentriert. Es ist relativ neu, hat aber Fans in der Homelab-Community. Es kann auch einfach auf unseren 3 Knoten laufen. Es hat (derzeit) nicht die gleiche große Nutzerbasis wie K3s/MicroK8s, aber es ist eine Option, die man im Auge behalten sollte (insbesondere wenn man die Idee eines Open-Source-, konfigurierbaren, minimalen Kubernetes mag – einige Berichte zeigen sogar, dass k0s in ähnlichen Setups leicht weniger Leerlauf-Ressourcen als K3s/MicroK8s verbraucht).
    • kind dient hauptsächlich zum Testen von Kubernetes-Clustern in Docker-Containern (oft für CI-Pipelines genutzt). Es ist nichts, was wir als unseren immer aktiven Homelab-Cluster nutzen würden – es ist eher für schnelle, vergängliche Cluster auf einer Maschine (ähnlich wie der Zweck von Minikube).
    • Rancher Kubernetes Engine (RKE) oder K3d oder andere sind auch da draußen, aber die sind entweder auf containerisierte Cluster ausgerichtet (k3d läuft einen K3s-Cluster in Docker) oder auf komplexere Deployment-Szenarien. In einem Homelab haben K3s und MicroK8s sozusagen die Standardlösungen für einfache Setups geworden.

Fazit: Für ein Homelab mit 3 anständigen Knoten sind MicroK8s oder K3s die empfohlenen Wahl, um einen funktionsfähigen Kubernetes-Cluster mit minimalem Aufwand zu erhalten. Sie werden uns ermöglichen, alle unsere Knoten in einem Cluster zu nutzen und bieten eingebaute Unterstützung für persistente Volumes und LoadBalancer-Dienste, genau das, was wir wollten. Wenn wir eine mehr Plug-and-Play, Ubuntu-integrierte Lösung bevorzugen, dann wählen Sie MicroK8s. Wenn wir eine super leichte, bewährte Lösung mit Ranchers Unterstützung bevorzugen, dann wählen Sie K3s. In jedem Fall werden wir einen funktionierenden Cluster in Minuten haben. Sobald er läuft, können wir das Kubernetes-Dashboard oder andere Tools zum Verwalten nutzen und beginnen, unsere Anwendungen mit persistenter Speicherung und einfacher Dienstexposition zu hosten. Viel Spaß mit unserer Homelab-Kubernetes-Reise!

Kubernetes-Distributionen-Homepages