Vergelijking van Kubernetes-distributies voor een 3-knooppunten homelab

Het kiezen van de beste Kubernetes-variant voor onze homelab

Inhoud

Ik ben het vergelijken van self-hosted Kubernetes varianten die geschikt zijn voor de Ubuntu-gebaseerde homelab met 3 knooppunten (16 GB RAM, 4 cores elk), met aandacht voor eenvoud van installatie en onderhoud, ondersteuning voor persistente volumes en LoadBalancers.

Scenario: We hebben drie Ubuntu-knooppunten (16 GB RAM, 4 CPU-cores elk) in een homelab. High-availability (HA) en ARM-ondersteuning zijn geen prioriteiten. We willen een eenvoudig te installeren, laag-gebruik Kubernetes cluster (één-knooppunt of 3-knooppunt) met ondersteuning voor Persistent Volumes (PV) en LoadBalancer (LB)-diensten (zodat cloud-native apps die opslag of externe IP-adressen vereisen glad lopen). We zullen ons concentreren op 3-knooppunt clusteropties zonder HA of ARM-CPU-compatibiliteitsvereisten.

kubernetes homelab

Hieronder vergelijken we populaire lichte [Kubernetes(https://www.glukhov.org/nl/post/2024/10/kubernetes-cheatsheet/ “lijst en beschrijving van de meest voorkomende en nuttige k8s-commands - k8s cheatsheet”) distributies – K3s, MicroK8s, Minikube, en kubeadm (pure Kubernetes) – en hoe ze scoren op de belangrijkste criteria (functionaliteiten, installatie/onderhoud, PV/LB-ondersteuning, resourcevereisten, clusteropzet en tooling). We geven ook enkele aanbevelingen over welke te kiezen op basis van het homelab-scenario.

K3s (Rancher’s Lightweight Kubernetes)

Belangrijke functies: K3s is een CNCF-gecertificeerde Kubernetes-distributie ontworpen voor minimale resourcegebruik (het kan draaien op zo weinig als 512 MB RAM). Het verpakt de hele Kubernetes-controlplane in één enkel bestand en proces, met lichte componenten (bijvoorbeeld SQLite-gegevensopslag als standaard in plaats van etcd, flannel voor netwerken). Het bevat standaardwaarden zoals een ingebouwde ingressescontroller (Traefik) en een eenvoudige service load balancer. K3s verwijdert oude/alpha-functies om overbodigheid te verminderen.

  • Eenvoud van installatie & onderhoud: Zeer eenvoudig – we kunnen het installeren met een enkelregel script (curl ... | sh) of via tools zoals K3sup. De server start op met standaardcomponenten uit de doos. Het toevoegen van knooppunten is eenvoudig (draai de K3s-agent met een token van de server). Upgrades zijn makkelijk (vervang het bestand of gebruik het installatiescript voor een nieuwe versie). Er is geen aparte etcd-opzet nodig (tenzij je een multi-master HA-opzet kiest). K3s is ontworpen om na installatie minimaal aandacht te vereisen, waardoor het populair is voor IoT en homelabs.

  • Ondersteuning voor Persistent Volumes: Ingebouwd. Standaard bevat K3s Rancher’s local-path StorageClass, die PVs dynamisch toewijst op het hostbestandssysteem voor elke PVC. Dit betekent dat elke PVC automatisch wordt vervuld door een hostPath-volume op het knooppunt. Het is een single-node opslopl oplossing (elk volume is op één knooppunt’s schijf), maar werkt uit de doos voor stateful apps. Voor geavanceerde opslag kunnen we iets toevoegen zoals Rancher’s Longhorn (gedeelde blok-opslag), wat K3s ondersteunt, maar voor een homelab is de standaard local-path provisioner meestal voldoende.

  • Ondersteuning voor LoadBalancer: Ingebouwd. K3s bevat een lichte controller genaamd ServiceLB (vormer “Klipper LB”) die Services van het type LoadBalancer een IP/ports op de host geeft zonder externe cloudprovider. Wanneer we een LoadBalancer-service aanmaken, implementeert K3s een DaemonSet van kleine LB-pods (svc-...) op elk knooppunt, die hostports gebruiken om verkeer naar de service te sturen. Essentieel, K3s hergebruikt het knooppunt’s IP (intern of extern) als LB-IP en gebruikt iptables routing in de LB-pods om verkeer naar de service’s ClusterIP te sturen. Dit werkt zonder configuratie – services blijven niet “in wachtrij” (in tegenstelling tot pure K8s op bare metal). Het nadeel is dat het externe LB-IP één van onze knooppunt’s IP’s (of alle knooppunten) is en we moeten zorgen dat de poort vrij is. Voor de meeste homelab-gebruiken (exponeren van een paar services op HTTP/HTTPS-poorten) is dit perfect. Als nodig, kunnen we de ingebouwde LB uitschakelen en MetalLB handmatig installeren, maar de meeste gebruikers blijven bij de handige standaard.

  • Resourcevereisten: Zeer laag. K3s kan zelfs draaien op laag-gepresteerde hardware. Officieel zijn 512 MB RAM en een paar honderd MB schijf voldoende voor een serverknooppunt. In de praktijk gebruikt een klein cluster een paar honderd MB geheugen voor de controlplane. Het bestand is <100 MB. CPU-overhead is minimaal (K3s gebruikt iets meer CPU wanneer het rustig is vergeleken met MicroK8s, maar niet met veel verschil). Onze knooppunten (16 GB elk) zijn meer dan voldoende om K3s comfortabel te laten draaien.

  • Eén-knooppunt vs meerknooppunt: Geschikt voor beide. K3s kan draaien op één-knooppunt (alle controlplane en workloads op één machine) of meerknooppunt. Voor een 3-knooppunt opzet kunnen we 1 server (master) en 2 agents gebruiken, of zelfs alle 3 servers maken voor HA (niet nodig hier omdat HA geen doel is). Het toevoegen van agents is triviaal met het token. K3s’ standaard SQLite-gegevensopslag werkt voor één-server; voor meerknooppunt HA zouden we overgaan op ingebouwde etcd (K3s kan dit automatisch doen wanneer we meerdere serverknooppunten starten).

  • CLI & UI-tools: We werken met K3s net zoals met elke Kubernetes – via kubectl. K3s bevat zijn eigen kubectl-bouw (we kunnen k3s kubectl ... uitvoeren of gewoon een standaard kubectl gebruiken door het te laten wijzen naar K3s’ kubeconfig). Er is geen specifieke K3s-CLI buiten installatiecommando’s – het is opzetten met opzettelijke minimalisme. Er is geen ingebouwde web-UI (de upstream Dashboard wordt niet standaard geïnstalleerd). Echter, we kunnen handmatig de Kubernetes Dashboard of andere tools op K3s installeren zoals een standaardcluster. Rancher (het GUI-beheerprogramma van hetzelfde bedrijf) kan ook bovenop K3s worden geïnstalleerd als een volledige UI gewenst is, maar het is niet onderdeel van K3s zelf. Essentieel, K3s biedt de kern k8s-API’s en we voegen extra’s toe wanneer we ze nodig hebben (ingress, opslag, etc. – enkele daarvan zijn al ingebouwd zoals vermeld).

MicroK8s (Canonical’s Low-Ops Kubernetes)

Belangrijke functies: MicroK8s is Canonic’s lichte Kubernetes-distributie, geleverd als een snap-pakket. Het installeert een volledig conform Kubernetes-cluster (upstream binaries) met één opdracht en is ontworpen voor gebruiksgemak (“low ops”) op één machine of klein cluster. Het benadrukt een “batteries-included” aanpak – we krijgen veel optionele functies die we kunnen inschakelen met eenvoudige opdrachten. MicroK8s standaard is een pure Kubernetes-ervaring (alle standaard APIs) maar met handige add-ons voor veelvoorkomende behoeften. Het ondersteunt zowel één-knooppunt als meerknooppunt implementaties (we kunnen een cluster vormen door knooppunten te “verbinden”), en heeft zelfs een HA-modus voor de controlplane (met Dqlite – een gedistribueerde SQLite – wanneer we 3 masters hebben).

  • Eenvoud van installatie & onderhoud: Zeer eenvoudig ook – snap install microk8s --classic op een Ubuntu-machine stelt een Kubernetes-knooppunt in. Het is één pakket dat alle componenten bevat. MicroK8s wordt onderhouden via Ubuntu’s snap-systeem, wat betekent dat updates atomaar en automatisch kunnen zijn (we kunnen een kanaal volgen voor Kubernetes-versies). Deze automatische update mogelijkheid is uniek onder deze opties – we kunnen ervoor kiezen om beveiligingspatches en kleine upgrades te krijgen via snap refreshes. Het beheren van MicroK8s gebeurt via de microk8s opdracht, die subopdrachten heeft om functies in- of uit te schakelen. Over het algemeen is het zeer laag-gebruik: er zijn geen containers of VMs om te beheren (het draait natief op de host), en er is geen externe etcd om te configureren (het gebruikt een interne gegevensopslag). Onderhoud is vooral het updaten van de snap wanneer nodig en het gebruik van microk8s.status om te controleren.

  • Ondersteuning voor Persistent Volumes: Beschikbaar via add-on. Standaard schakelt MicroK8s PVs niet automatisch in totdat we de “hostpath-storage” add-on inschakelen. Inschakelen hiervan (met microk8s enable hostpath-storage) maakt een standaard StorageClass aan die volumes toewijst vanuit een map op de host. Dit is essentieel een dynamische hostPath provisioner, vergelijkbaar met K3s’ local-path. Zodra ingeschakeld, bindt elke PVC zich aan een hostpath PV op het MicroK8s-knooppunt. (Op een meerknooppunt MicroK8s-cluster bevindt de hostpath PV zich op één knooppunt – geschikt voor testen of homelab-gebruik maar geen gedistribueerde opslag). MicroK8s biedt ook Mayastor en andere opslag add-ons als we geavanceerde opslag over meerknooppunten willen, maar voor eenvoud werkt hostpath opslag goed. Opmerking: De add-on is niet standaard ingeschakeld (om dingen laag te houden), dus we zullen het inschakelen om PVCs te laten werken. Canonical noemt dit niet geschikt voor productie HA-gebruik (aangezien het niet gerepliceerd is), maar voor een homelab is het perfect.

  • Ondersteuning voor LoadBalancer: Beschikbaar via add-on. MicroK8s bevat geen standaard load balancer, maar biedt MetalLB als eenvoudige add-on. Het uitvoeren van microk8s enable metallb:<start-IP>-<end-IP> implementeert MetalLB in Layer 2-modus en laat ons een pool van IP’s van onze LAN opgeven voor LoadBalancer Services. Zodra ingeschakeld, krijgt elke Service van het type LoadBalancer automatisch een IP uit dat bereik (en MicroK8s advertiseert het via ARP op de LAN). Dit geeft een cloud-achtige ervaring op bare metal. (Als we MetalLB niet inschakelen, blijft een LoadBalancer Service in wachtrij, aangezien MicroK8s zelf geen load balancer implementeert – net zoals upstream Kubernetes.) In een homelab is MetalLB eenvoudig en laat ons services toegankelijk maken op ons lokale netwerk. We zullen een vrije subnet of IP-bereik in ons netwerk moeten kiezen voor het. De enable-opdracht van MicroK8s maakt de setup pijnloos, maar het is nog steeds een aparte stap. (In tegenstelling tot K3s, die uit de doos werkt voor LB maar met de beperking van het gebruik van knooppunt IP’s/poorten.) Veel MicroK8s-gebruikers inschakelen MetalLB als onderdeel van hun initiële setup voor een functionele LB.

  • Resourcevereisten: MicroK8s is vrij lichtgewicht, al is het iets groter dan K3s. Het draait alle kernservices (API-server, controller, scheduler, kubelet, etcd of Dqlite) natief. Idle-gebruik is meestal ~500–600 MB RAM voor de controlplane, afhankelijk van welke add-ons zijn ingeschakeld. Canonical vermeldt ~540 MB basisgeheugen. CPU-gebruik is laag wanneer het rustig is, en onze 16 GB knooppunten hebben genoeg ruimte. Schijfruimtevereisten zijn klein (snap ~ 200 MB plus etcd-gegevens). Samengevat, kan MicroK8s draaien op bescheiden hardware (het wordt zelfs aangeboden voor Raspberry Pis), en in ons scenario passen de machines het gemakkelijk. Als meerdere add-ons zijn ingeschakeld (dashboard, monitoring, etc.), zal het gebruik van resources toenemen.

  • Eén-knooppunt vs meerknooppunt: MicroK8s werkt goed voor beide. We kunnen het gebruiken voor een één-knooppunt cluster (bijvoorbeeld op een dev-machine of één server) of een meerknooppunt cluster maken door knooppunten te “verbinden”. De MicroK8s-documentatie biedt een opdracht om een knooppunt toe te voegen (we halen een join-token op van het eerste knooppunt en gebruiken het op de anderen). In een meerknooppunt setup zonder HA is één knooppunt het primaire controlplane. Met 3 knooppunten hebben we ook de optie om ha-cluster modus in te schakelen (het controlplane wordt HA door Dqlite op 3 knooppunten te draaien), maar in ons geval is HA niet nodig. Of het nu één of drie knooppunten zijn, de ervaring is hetzelfde Kubernetes API. Meerknooppunt MicroK8s is iets nieuwer dan K3s’ aanpak, maar is nu zeer stabiel. Het is een goede keuze als we een “micro cloud” van een paar Ubuntu-boxen willen met k8s met minimale inspanning.

  • CLI & UI-tools: MicroK8s komt met de microk8s command-line tool, wat zeer handig is. Bijvoorbeeld, microk8s enable <addon> schakelt verschillende diensten in of uit (DNS, ingress, opslag, metallb, dashboard, etc.), en microk8s status laat zien wat er draait. Het bevat ook een ingebouwde kubectl: we kunnen microk8s kubectl ... gebruiken (of het aliasen) wat met het cluster communiceert – dit is handig omdat we geen kubeconfig hoeven te configureren. Voor UI biedt MicroK8s de Kubernetes Dashboard als add-on (microk8s enable dashboard), die de standaard web-UI implementeert. Zodra ingeschakeld, kunnen we deze toegankelijk maken (het draait op poort 10443 of via proxy). MicroK8s heeft geen eigen aangepaste GUI – het vertrouwt op Kubernetes Dashboard of andere tools – maar de eenvoud van het inschakelen is een plus. Samengevat, MicroK8s benadrukt een één-opdracht-ervaring voor veelvoorkomende taken en een “het werkt gewoon” filosofie, wat veel complexiteit abstracteert (ten koste van het verbergen van enkele interne details). Dit maakt het zeer geschikt voor homelabs voor wie een Kubernetes-cluster wil zonder handmatige setup van elk onderdeel.

Contrast K3s vs MicroK8s: Beide zijn vrij gelijk in doelen en mogelijkheden – lichtgewicht, eenvoudig, meerknooppunt geschikt. K3s neigt iets meer naar “DIY” bij het toevoegen van extra’s (het vertrouwt op Helm-charts of handmatige manifesten voor dingen die niet zijn ingebouwd), terwijl MicroK8s ingebouwde add-ons biedt via zijn CLI. MicroK8s is ook een meer “pure” Kubernetes onder de kop (upstream componenten, alleen verpakt als snap), terwijl K3s enkele aangepaste binaries en één dienst voor alles gebruikt. Beide zijn goede keuzes voor een homelab; de keuze hangt vaak af van voorkeur: als Ubuntu/snaps en een geïntegreerde gevoel voorkeur hebben, is MicroK8s geweldig, terwijl K3s uitstekend is als we een minimalistische aanpak willen met mogelijk iets meer handmatige controle. (We zullen aanbevelingen geven aan het einde.)

Minikube (Eén-knooppunt lokale K8s)

Belangrijke kenmerken: Minikube is vooral een tool voor het lokaal uitvoeren van Kubernetes (vaak op een ontwikkelaars PC of laptop) in plaats van een traditionele cluster over meerdere machines. Het maakt een één-knooppunt Kubernetes cluster aan in een virtuele machine of container op onze computer. Minikube is bekend om zijn brede ondersteuning van omgevingen – het kan lopen op Linux, macOS, Windows en ondersteunt verschillende hypervisors (VirtualBox, KVM, Hyper-V, Docker driver, enz.). Het wordt onderhouden door de Kubernetes SIGs en wordt vaak gebruikt voor testen en leren. Hoewel Minikube kan worden overgehaald tot een meerknooppunt configuratie, is het essentieel bedoeld voor één-knooppunt clusters (de “meerknooppunt” modus van Minikube start eigenlijk meerdere knooppunten op dezelfde host met behulp van container runtime – nuttig voor het simuleren van een cluster, maar niet voor het uitvoeren op afzonderlijke fysieke machines).

  • Gemak van installatie & gebruik: Minikube is zeer gemakkelijk om te beginnen op één machine. We installeren de minikube binary, zorgen dat we een VM driver (of Docker) hebben, en voeren minikube start uit. Dit zal een lokale VM/container instellen en Kubernetes erin starten. Het is waarschijnlijk de eenvoudigste manier om een Kubernetes cluster voor het eerst te laten draaien. De CLI (minikube) biedt opdrachten om te interageren met de VM (start, stop, verwijder) en om add-ons te activeren. Omdat Minikube is ontworpen voor lokaal gebruik, is het geen “langlopende” daemon – we starten het meestal wanneer we het nodig hebben en stoppen het wanneer we klaar zijn, hoewel we kunnen het continu draaien op een homelab server als gewenst. Onderhoud/upgrades zijn eenvoudig: alleen de minikube versie updaten en het cluster opnieuw starten (Minikube kan ook de Kubernetes versie updaten met een vlag). Eén beperking is dat Minikube ontworpen is voor één-knooppunt (het toevoegen van meer knooppunten betekent het starten van extra VM instanties op dezelfde host, niet het aansluiten van echte afzonderlijke hosts). Dus, het gebruik van Minikube op drie afzonderlijke fysieke knooppunten betekent eigenlijk het draaien van drie onafhankelijke één-knooppunt clusters, wat waarschijnlijk niet wat we willen. Minikube is ideaal voor ontwikkeling en testen op één machine, maar het is niet bedoeld voor het beheren van een cluster verspreid over meerdere fysieke servers.

  • Ondersteuning voor Persistent Volume: Ingebouwd (hostPath). Minikube clusters bevatten automatisch een standaard StorageClass die een hostPath provisioner gebruikt. In feite draait Minikube een kleine controller die dynamisch hostPath PVs binnen de VM aanmaakt wanneer PVCs worden aangevraagd. Dit betekent dat we PersistentVolumeClaims kunnen aanmaken en deze zullen worden voldaan met opslag op het bestandssysteem van de Minikube VM (meestal onder /tmp/hostpath-provisioner of vergelijkbaar). Dit werkt uit de doos – geen configuratie nodig voor basis PV gebruik. Bijvoorbeeld, de standaard “standard” StorageClass in Minikube kaart naar hostPath opslag op het knooppunt. Een opmerking: als we de Minikube VM herstarten of verwijderen, kunnen die hostPath volumes verloren gaan (Minikube probeert bepaalde mappen te behouden bij herstarten – bijvoorbeeld /data, /var/lib/minikube, /tmp/hostpath* worden behouden). Maar in het algemeen is dit voor een niet-productieomgeving prima. Als we meer willen simuleren, heeft Minikube ook een CSI hostpath driver add-on die snapshotting ondersteunt en kan werken in meerknooppunt modus, maar dat is meer voor experimenten. Samenvatting: Minikube ondersteunt PVs standaard via hostPath, wat voldoende is voor een homelab test van stateful apps.

  • Ondersteuning voor LoadBalancer: Ondersteund via tunneling (of MetalLB add-on). In de cloud krijgt een LoadBalancer service een cloud LB met een externe IP. In Minikube is er duidelijk geen cloud provider, dus biedt Minikube twee mechanismen:

    • Minikube Tunnel: We kunnen minikube tunnel in een apart proces uitvoeren dat een netwerkroute op onze host aanmaakt en een IP toekent aan onze LoadBalancer service. Essentieel gebruikt onze host als de “externe LB”. Wanneer we een LoadBalancer Service aanmaken, toont Minikube een “externe IP” (meestal van het subnet van het cluster) en het minikube tunnel proces zal dat naar de service routeren. Dit vereist dat het tunnel proces blijft draaien (en meestal root rechten om routes aan te maken). Het is een beetje een manuele stap, maar Minikube geeft een herinnering als we een LoadBalancer service hebben zonder tunnel („External-IP pending” totdat we de tunnel starten).
    • MetalLB Add-on: Nieuwere versies van Minikube bevatten ook een MetalLB add-on. We kunnen minikube addons enable metallb uitvoeren en een IP bereik configureren (Minikube zal ons vragen). Dit implementeert MetalLB binnen het Minikube cluster, dat dan LoadBalancer services behandelt net zoals op elk bare-metal Kubernetes. Dit is een meer “in-cluster” oplossing en vereist geen apart tunnel proces na de initiële instelling.

    Beide opties werken, en welke we kiezen is aan ons. Voor een snelle blootstelling van één service is minikube tunnel snel en tijdelijk. Voor een meer permanente oplossing kan de MetalLB add-on worden ingeschakeld zodat LBs echte IPs krijgen (bijvoorbeeld kunnen we hem een bereik geven zoals 10.0.0.240-250 op een Minikube met bridged networking). Onthoud dat Minikube meestal één-knooppunt is, dus in werkelijkheid is de “load balancer” niet het balanceren over meerdere knooppunten – het biedt alleen externe toegang tot de service van het enkele knooppunt. Dit is prima voor ontwikkeling. In een homelab, als we slechts één van onze knooppunten gebruiken en Minikube erop draaien, kunnen we deze gebruiken om onze apps te bereiken. Maar als we alle 3 de knooppunten willen gebruiken, is Minikubes aanpak voor LB niet bedoeld voor die scenario.

  • Resourcevereisten: Minikube zelf is lichtgewicht, maar omdat het meestal een volledig één-knooppunt Kubernetes draait (in een VM), is de resourcegebruik vergelijkbaar met een normale kleine cluster. De minimale aanbevolen is 2 GB RAM en 2 CPUs voor de VM. Standaard alloceert Minikube vaak 2 GB RAM voor zijn VM. In ons geval, met 16 GB per machine, is dat triviaal. Inactieve Minikube (Kubernetes) gebruikt ongeveer 600 MB geheugen. Een ding om te overwegen is dat Minikube op top van onze OS draait – ofwel als een VM via een hypervisor of een Docker container – wat enige overhead met zich meebrengt. Op een homelab server kunnen we Minikube met de “none” driver draaien (wat Kubernetes componenten direct op de host installeert). De “none” (a.k.a. bare-metal) driver is essentieel vergelijkbaar met het gebruik van kubeadm op dat knooppunt, en vereist handmatige opschone, dus het is niet zo populair. De meeste gebruiken een VM of Docker driver. Samenvatting: elk van onze homelab knooppunten kan Minikube gemakkelijk draaien. De enige beperking is dat Minikube de resources van alle 3 de knooppunten niet zal gebruiken – het zal beperkt zijn tot het enkele host waarop het draait (tenzij we de experimentele meerknooppunt modus binnen één host gebruiken).

  • Één-knooppunt vs Meerknooppunt: Voornamelijk één-knooppunt. Minikube is ideaal voor een één-knooppunt cluster op één machine. Het heeft een functie om meerdere knooppunten te simuleren (bijvoorbeeld minikube start --nodes 3 met de Docker driver start 3 Kubernetes knooppunten als containers op één host), maar dit is alleen voor testen. We kunnen Minikube niet gebruiken om een echte meerknooppunt cluster aan te maken over 3 afzonderlijke fysieke servers. Als we 3 machines hebben, zouden we 3 onafhankelijke Minikube instanties moeten draaien (niet in één cluster). Dat is geen echte cluster ervaring (ze zullen niet van elkaar weten). Daarom is Minikube niet aanbevolen als ons doel is om alle drie de knooppunten in één Kubernetes cluster te gebruiken – het is beter voor scenario’s waarbij we slechts één machine (onze PC of één server) hebben en K8s erop willen draaien. Het is ook geweldig voor het leren van Kubernetes basis en lokale ontwikkeling.

  • CLI & UI Tools: De minikube CLI is het hoofdinterface. We gebruiken het om het cluster te starten/stoppen, en het heeft handige snelkoppelingen: bijvoorbeeld minikube dashboard zal het Kubernetes Dashboard activeren en het openen in onze browser voor ons. minikube addons enable <addon> kan een verscheidenheid aan optionele componenten activeren (ingress, metallb, metrics-server, enz.). Minikube stelt kubectl toegang automatisch in (het configureert een context “minikube” in onze kubeconfig). Voor UI, zoals vermeld, is het Kubernetes Dashboard gemakkelijk bereikbaar via de dashboard opdracht. Minikube heeft geen eigen unieke web UI; het vertrouwt op standaard tools. Het debuggen van Minikube is ook gemakkelijk omdat we minikube ssh kunnen gebruiken om in het knooppunt VM te komen als nodig. Over het algemeen is het gereedschap zeer gebruikersvriendelijk voor een één-knooppunt scenario.

Kubeadm (Vanille Kubernetes op onze eigen knooppunten)

Belangrijke kenmerken: Kubeadm is geen “distributie” maar eerder het officiële toolkit voor het maken van een Kubernetes cluster vanaf nul. Het gebruik van kubeadm betekent dat we standaard upstream Kubernetes componenten op onze machines implementeren. Het is essentieel hoe we “ons eigen” cluster maken, volgens best practices maar zonder de extra’s die distributies bevatten. Kubeadm zal een controleplane knooppunt instellen (met etcd, API server, controller manager, scheduler) en werknemers knooppunten eraan koppelen. Het resultaat is een volledig standaard Kubernetes cluster identiek aan wat we op cloud VMs zouden krijgen. Deze aanpak geeft ons volledige controle en flexibiliteit – we kiezen de netwerkplugin, opslagprovisioner, enz. – maar vereist ook de meeste initiële manuele werk en kennis. Het wordt vaak gebruikt in productie of leeromgevingen om Kubernetes interne werking te begrijpen.

  • Gemak van installatie & onderhoud: In vergelijking met de anderen is kubeadm de meest betrokken. We moeten handmatig afhankelijkheden installeren (container runtime zoals containerd, kubeadm, kubelet, kubectl) op elk knooppunt. Dan voeren we kubeadm init uit op de master en kubeadm join op werknemers met de token die het geeft. We moeten ook een CNI (netwerkplugin) instellen na initialisatie (Calico, Flannel, enz.) omdat kubeadm er standaard geen installeert. Er zijn goed gedocumenteerde stappen voor al het bovenstaande (het proces is niet moeilijk, maar het is veel stappen) – essentieel, kubeadm brengt ons een startcluster, maar verwacht dat we de add-ons zelf aanhandelen. Voor onderhoud zijn we verantwoordelijk voor upgrades (kubeadm heeft een upgrade opdracht, maar we moeten knooppunten leegmaken, binaries updaten, enz. handmatig), evenals het monitoren van etcd gezondheid, certificaatvernieuwingen, enz. In kort, kubeadm is krachtig maar handmatig. Het wordt vaak genoemd als “de moeilijke manier” (hoewel niet zo moeilijk als het bouwen vanaf bron). Voor een homelab hobbyist die graag leert, is kubeadm een geweldige manier om Kubernetes diep te begrijpen. Maar als onze prioriteit “gemak en laag onderhoud” is, zal kubeadm meer werk vereisen dan K3s/MicroK8s. Elke upgrade of verandering vereist handmatige inspanning. Dat gezegd zijnde, zodra het is ingesteld, is het het echte pakket: een standaard Kubernetes cluster zonder verborgen abstracties.

  • Ondersteuning voor Persistent Volume: Geen standaard (moet handmatig worden toegevoegd). Een kubeadm geïnstalleerde cluster is essentieel een leeg Kubernetes – het bevat geen standaard StorageClass of dynamische provisioner vanaf de start. In cloudomgevingen zou de cloud provider normaal een standaard StorageClass leveren (bijvoorbeeld AWS EBS, enz.), maar in een homelab bare-metal omgeving moeten we onze eigen oplossing installeren. Gewone aanpakken:

    • HostPath Provisioner: We kunnen wat K3s/Minikube doen door iets zoals de Rancher Local Path Provisioner te installeren (wat een kleine controller + StorageClass is die hostPath PVs aanmaakt). Dit is een eenvoudige add-on (alleen een YAML manifest) en geeft ons lokale dynamische opslag.
    • NFS of NAS: Sommige homelab gebruikers zetten een NFS server op (of gebruiken een NAS) en gebruiken dan statische PVs of een NFS CSI driver voor provisioning.
    • OpenEBS/Longhorn/Ceph: Er zijn complexere opties zoals het implementeren van Longhorn of Ceph RBD via Rook als we gedistribueerde opslag over knooppunten willen. Deze vereisen meer resources en complexiteit.

    Het belangrijkste punt is dat kubeadm ons niet “oplost” voor opslag – we moeten beslissen en configureren. Als gemak de prioriteit is, is de eenvoudigste weg om een hostPath provisioner te installeren of NFS te gebruiken. Bijvoorbeeld, Ranchers local-path provisioner kan in een paar kubectl apply opdrachten worden geïnstalleerd en zal het gedrag van K3s nabootsen (volumes aanmaken onder /var/lib/rancher/ op welk knooppunt dan ook). Maar dit is een manuele stap. Totdat we dat doen, zullen alle PVCs die we aanmaken in een “Pending” staat blijven omdat Kubernetes geen standaard provisioning heeft. Dus, terwijl kubeadm zeker ondersteunt Persistent Volumes (het is volledig Kubernetes), is de ondersteuning voor dynamische PV net zo goed als de inspanning die we doen om het op te zetten.

  • Ondersteuning voor LoadBalancer: Geen standaard (moet handmatig worden toegevoegd). Een vergelijkbare verhaal hier: in een traditionele on-prem cluster hebben we geen ingebouwde LoadBalancer implementatie. Als we een Service van het type LoadBalancer op een gewone kubeadm cluster aanmaken, blijft deze in de pending staat tot we een controller installeren die het kan verwerken. De gebruikelijke oplossing is om MetalLB zelf te installeren. MetalLB kan worden geïnstalleerd via manifest of Helm chart – we zouden een IP bereik configureren en het zal dan die IP’s toekennen aan LoadBalancer services (net zoals in MicroK8s). Er zijn veel gidsen voor het installeren van MetalLB op kubeadm clusters. Een andere alternatief die sommigen gebruiken is kube-vip voor controleplane VIP en service LBs, maar MetalLB is eenvoudiger voor services. Essentieel, met kubeadm hebben we de vrijheid (of last) om elke load-balancing mechanisme in te stellen die bij onze behoeften past. Als we er geen installeren, zijn we beperkt tot NodePort services voor externe toegang. Voor een homelab is het installeren van MetalLB zeer aanbevolen – het is eenvoudig en geeft ons die cloud-achtige service IP functionaliteit. Maar weer, dat is een extra stap die we moeten uitvoeren (ongelijk aan K3s die uit de doos werkt of MicroK8s met een eenvoudige enable).

  • Resourcevereisten: Standaard Kubernetes is iets zwaarder dan de afgekorte versies. Elke knooppunt draait een kubelet en kube-proxy, en de master draait etcd en controleplane componenten. Een enkele controleplane knooppunt kan nog steeds in 2 GB RAM draaien, maar meestal willen we iets meer voor comfort als we containers erop draaien. De padok gids stelt 2 GB voor master, 2 GB voor werknemers minimum. In ons scenario (16 GB per knooppunt), is dat prima. Inactieve etcd en API server gebruiken mogelijk een paar honderd MB geheugen per keer. Er is geen grote verschillen tijdens runtime tussen een kubeadm cluster en MicroK8s – na het einde, MicroK8s is diezelfde componenten. Het verschil is alleen wat standaard draait (MicroK8s kan DNS en opslag standaard inschakelen, terwijl op kubeadm we die installeren). Dus, op resources, kan kubeadm net zo slank of zwaar zijn als we het instellen. Zonder extra’s geïnstalleerd, kan het vrij slank zijn. Met een typische setup (bijvoorbeeld we voegen CoreDNS, Dashboard, enz. toe), verwacht ongeveer 1 GB of zo gebruikt voor systeemoverhead. We hebben genoeg RAM, dus resources zijn geen zorg. Het gaat meer om de menselijke tijd en middelen die nodig zijn om het te beheren in plaats van CPU/RAM.

  • Één-knooppunt vs Meerknooppunt: Kubeadm kan beide, met volledige flexibiliteit. We kunnen een één-knooppunt cluster initialiseren (en zelfs kubeadm vertellen om het enkele knooppunt te laten werken door het master te ontaanteken). Of we kunnen één master hebben en twee werknemers aanmelden (een veelvoorkomende 3-knooppunt setup). We kunnen zelfs drie masters en drie werknemers instellen, enz. – elke topologie. In ons geval, een waarschijnlijke kubeadm setup zou één controleplane knooppunt en twee werknemers zijn (aangezien HA niet nodig is, hebben we geen meerdere masters nodig). Dat geeft ons een functionele 3-knooppunt cluster. Het proces voor meerknooppunt is goed gedocumenteerd: essentieel, installeer Kubernetes op alle, initialiseer één, meld de anderen aan. Het resultaat is identiek aan wat een beheerde cluster of andere distributie zou geven: onze 3 knooppunten verschijnen in kubectl get nodes, enz. Dus, kubeadm voldoet zeker aan de “kan alle 3 de knooppunten gebruiken” vereiste.

  • CLI & UI Tools: Met kubeadm is de enige speciale CLI kubeadm zelf, gebruikt voor de setup en (later) upgrade stappen. Dagelijks gebruiken we kubectl om het cluster te beheren. Er is geen ingebouwde beheer CLI buiten wat Kubernetes biedt. Voor UI is er niets standaard ingeschakeld – we kunnen handmatig het Kubernetes Dashboard of elk ander hulpmiddel installeren (net zoals op elk cluster). Essentieel, kubeadm geeft ons een leeg Kubernetes canvas. Het is aan ons om erop te schilderen – wat inclusief het installeren van handigheidjes zoals dashboard, ingress controllers, storage classes, enz. betekent. Veel derde partij dashboards (Lens, Octant, enz.) kunnen ook verbinding maken met een kubeadm cluster als we een GUI beheer ervaring willen, maar die zijn externe tools. Samenvatting: met kubeadm krijgen we de zuivere Kubernetes omgeving – maximale flexibiliteit, maar ook de noodzaak om alles in te stellen alsof het een productiecluster was.

  • Kubespray Zie ook hoe je deze vorm van Kubernetes met Kubespray.

Zij-aan-zij vergelijkings tabel

Hieronder vindt u een overzicht dat de vier opties vergelijkt op belangrijke punten:

Aspect K3s (Lichtgewicht Rancher K8s) MicroK8s (Canonical “Low-Ops” K8s) Minikube (Eén-knoop dev K8s) Kubeadm (Vanille Kubernetes)
Installatie Één-regel installatiescript (één enkele binaire). Werkt als één systeemservice. Zeer snelle opzet. Één-opdracht installatie via snap op Ubuntu. Alle componenten zijn opgenomen. Eenvoudige clustering met microk8s join. Installeer het minikube CLI, dan minikube start om een lokale VM/container te starten. Cross-platform en beginner-vriendelijk. Handmatige installatie van kubeadm, kubelet, enz. op elk knooppunt. Voer kubeadm init + kubeadm join uit met voorwaarden. Bevat meerdere stappen (runtime, netwerkplugin, enz.).
Onderhoud & upgrades Handmatige upgrades (vervang de binaire of gebruik het installatiescript voor een nieuwe versie). Eenvoudig, omdat het slechts één binaire bestand is; weinig te beheren. Geen automatische updates. Snap refresh voor updates (kan automatisch zijn). Add-ons en clusterdiensten worden beheerd via microk8s CLI. Over het algemeen low-ops; automatische upgrades beschikbaar. Eenvoudig om cluster te verwijderen/herstellen voor dev. Upgrades door minikube-versie te updaten en cluster opnieuw te starten. Bedoeld voor tijdelijke gebruik (minder aandacht voor in-place upgrade duurzaamheid). Gebruiker is verantwoordelijk voor alle upgrades. Gebruik kubeadm upgrade maar moet knooppunten leegmaken, etcd-backup beheren, enz. Volledige controle, maar jij doet de werk (geen automatische updates).
K8s-versie Volgt upstream vrij dichtbij (vaak gebruikt in edge releases). CNCF conform. Sommige functies zijn standaard uitgeschakeld (alpha/legacy). Volgt upstream releases (snapkanalen voor 1.27, 1.28, enz.). CNCF conform. Essentieel van pure K8s binaire bestanden. We kunnen de Kubernetes-versie kiezen bij start (bijvoorbeeld minikube start --kubernetes-version=v1.27). Standaard is de nieuwste stabiele versie. Elke versie die we willen (specifieke kubeadm/kubelet-versies installeren). Volledige upstream Kubernetes – wij beslissen de versie en wanneer we upgraden.
Standaard functies Ingebouwde standaarden: Flannel CNI, CoreDNS, Traefik ingang, service LB, lokale opslagklasse, metrics-server, enz. (Allemaal kunnen worden uitgeschakeld als niet nodig). Minimal configuratie nodig om te werken. Minimale standaard: DNS is meestal aan, andere opties zijn optioneel. Eenvoudige één-opdracht add-ons voor ingang (NGINX), MetalLB, hostpath opslag, dashboard, enz.. Kan HA-modus inschakelen op 3+ knooppunten. Ingebouwd in VM: bevat meestal Docker/containerd runtime, Kubernetes met standaard add-ons zoals StorageProvisioner en DNS. Optionele add-ons (ingang, dashboard, enz.) schakelen via CLI. Geen meerknooppunt standaard. Bont: niets naast kern Kubernetes. Geen ingang, geen standaard opslag of LB, geen dashboard totdat we ze installeren. Kiezen CNI plugin (moet installeren voor netwerken). Essentieel een DIY cluster.
Ondersteuning voor persistent volume Ja – uit de doos. Rancher local-path dynamische provisioner is opgenomen, die hostPath PVs op het knooppunt maakt voor elke PVC. Standaard StorageClass “local-path” gebruikt automatisch lokale schijf. Ja – eenvoudige add-on. Schakel hostpath-storage in om een standaard StorageClass voor dynamische PVs met hostPath te krijgen. Totdat ingeschakeld, is er geen standaard PV provisioner. Add-on is niet bedoeld voor meerknooppunt productie, maar goed voor homelab. Ja – uit de doos. Standaard StorageClass gebruikt hostPath provisioner binnen de minikube VM. PVCs worden vervuld door een eenvoudige controller die een hostPath PV op het knooppunt’s bestandssysteem maakt. Gegevens blijven behouden bij herstarten op bepaalde mappen. Nee (handmatig). Geen standaard provisioner – cluster heeft geen StorageClass aan het begin. Gebruiker moet een opslopl oplossing installeren (bijvoorbeeld local path provisioner, NFS, Ceph, enz.). Basisbenadering: toepassen van een hostPath provisioner YAML om te imiteren wat K3s/Minikube doen. Tot dan, blijven PVCs in wachtrij.
Ondersteuning voor LoadBalancer Ja – ingebouwde ServiceLB. K3s’s servicelb controller (Klipper) volgt LoadBalancer services en implementeert pods op knooppunten om ze te blootstellen. Gebruikt knooppunt IP en hostpoorten om verkeer te doorsturen. Werkt uit de doos zonder configuratie. Geschikt voor kleine clusters; gebruikt knooppunt interne/externe IP voor service. Ja – via MetalLB add-on. Schakel metallb in met een IP bereik om te allokeren. Biedt echte Layer-2 load balancer op bare metal. Niet standaard ingeschakeld. Zodra ingeschakeld, krijgt elke LoadBalancer service een unieke IP uit onze pool. Vereist een beetje initiële configuratie (IP bereik). Ja – via tunnel of MetalLB. Geen cloud LB, maar we kunnen minikube tunnel uitvoeren om een externe IP toe te wijzen aan LoadBalancer services (maakt route op host). Alternatief, schakel de MetalLB add-on in minikube in voor automatische LB IPs. Standaard, blijven LB services “in wachtrij” tot we een van deze methoden gebruiken. Nee (handmatig). Geen ingebouwde LB. Typisch installeren van MetalLB handmatig voor bare-metal LB functionaliteit. Zodra MetalLB (of een andere LB controller) is ingesteld, werken LoadBalancer services. Zonder het, blijven LB services onbepaald onbepaald.
Netwerken (CNI) Standaard = Flannel (overlay netwerken). K3s ondersteunt ook het vervangen van CNI als nodig. Komt met CoreDNS geïnstalleerd voor cluster DNS. Traefik ingang is standaard ingeschakeld (kan worden uitgeschakeld). Standaard = Calico (voor recente versies in HA-modus) of een eenvoudige standaard. (MicroK8s gebruikte historisch flannel; nu neigt het naar Calico voor strikte beperking). CoreDNS is standaard ingeschakeld. NGINX ingang beschikbaar via add-on (microk8s enable ingress). Standaard = kubenet/bridge (afhankelijk van driver; vaak een eenvoudige NAT netwerk). CoreDNS draait standaard. We kunnen een NGINX ingang add-on inschakelen als nodig. Netwerken zijn beperkt tot de enkele VM; NodePort is toegankelijk via minikube ip. Keuze van CNI. Kubeadm installeert geen enkele CNI plugin – we moeten er één installeren (Calico, Flannel, Weave, enz.). We hebben volledige controle. Meeste gidsen hebben we Calico YAML toegepast na kubeadm init. CoreDNS is standaard geïnstalleerd door kubeadm als cluster DNS. Ingress controller – kies en installeer zelf (bijvoorbeeld NGINX of Traefik via manifests/Helm).
Meerknooppunt clustering Ja. Ontworpen voor meerknooppunt. Eenvoudig joinen met token. Kan externe DB of ingebouwde etcd gebruiken voor meerknooppunt. Prima voor 2-3+ knooppunt homelabs. Geen extra afhankelijkheden nodig – K3s heeft zijn eigen clustering ingebouwd. Ja. Ondersteunt clustering van meerdere MicroK8s knooppunten (met microk8s join). Kan HA inschakelen met 3+ masters (Dqlite). Zeer eenvoudig om een cluster te vormen, vooral als alle knooppunten Ubuntu + snap draaien. Nee (fysiek). Ontworpen voor één knooppunt. Kan meerknooppunt op één machine simuleren (meerdere knooppunten in Docker containers), maar kan geen meerknooppunt cluster over meerdere fysieke hosts vormen. Gebruik aparte Minikube instanties voor aparte clusters. Ja. Volledig ondersteunt meerknooppunt (dat is het doel). We kunnen 1 master + veel werknemers hebben, of zelfs meerdere masters (hoewel kubeadm HA setup complexer is). Er is geen ingebouwde beperking op cluster grootte.
Resource overhead Zeer laag. Beheerplane ~<0.5 GB geheugen inactief. Één proces voor beheerplane levert kleine voetafdruk. Efficiënt op CPU (hoewel het iets meer CPU kan gebruiken inactief dan MicroK8s per sommige rapporten). Ideaal voor laag vermogen of veel vrije capaciteit. Laag. ~0.5–0.6 GB geheugen voor beheerplane inactief. Slight hogere basisgeheugen dan K3s, maar blijft stabiel. Gebruikt Ubuntu snap (kan wat overhead hebben). Nog steeds lichtgewicht ten opzichte van volledig Kubernetes. Gemiddeld. VM standaard 2 GB toewijzing (gebruik ~0.6 GB inactief). Draait een volledige enkele-knooppunt Kubernetes, plus de VM laag. Niet een probleem op 16 GB systemen, maar essentieel verbruikt resources van een klein cluster op één machine. Gemiddeld. Een enkel master met één werknemer kan ~1 GB inactief gebruiken na het toevoegen van typische add-ons. Elke extra knooppunt voegt minimale overhead toe (alleen kubelet, proxy). Vergelijkbaar met het draaien van Kubernetes in cloud VMs van vergelijkbare grootte. Op 3 knooppunten met 16 GB elk, is de overhead verwaarloosbaar in context.
CLI-tools Gebruik k3s voor installatie en als wrapper voor kubectl (of gebruik standaard kubectl). Geen aparte beheer CLI (K3s is vooral “set and forget”). Sommige helper scripts (bijvoorbeeld k3s-killall.sh). Rancher’s GUI kan bovenop worden toegevoegd als gewenst. Rijke microk8s CLI: bijvoorbeeld microk8s enable/disable <addon>, microk8s status. Ook bevat microk8s kubectl. Ontworpen om veelvoorkomende taken te vereenvoudigen (geen direct bewerken van systeemmanifesten nodig voor basis). minikube CLI om cluster te starten/stoppen, config en add-ons te beheren, en informatie te verkrijgen (IP, service URL, logs). Ook biedt handige opdrachten zoals minikube dashboard. Interactie met cluster via kubectl (config automatisch ingesteld voor minikube context). Alleen kubeadm voor initiële opzet en upgrades. Dagelijks gebruik via standaard kubectl en andere Kubernetes-tools. Geen distro-specifieke CLI na bootstrap. Jij werkt met onbewerkte Kubernetes-opdrachten en mogelijk OS-tools voor onderhoud.
UI / Dashboard Niet opgenomen standaard. Kan handmatig het Kubernetes Dashboard installeren of externe tools gebruiken (niets Rancher-specifiek tenzij we Rancher apart toevoegen). K3s focus is op headless operatie. Niet opgenomen standaard, maar beschikbaar via één opdracht: microk8s enable dashboard implementeert het standaard Dashboard UI. Eenvoudige toegang voor cluster via microk8s dashboard-proxy. Ook goed met Canonical’s Lens GUI integreert als gewenst (Lens kan direct MicroK8s toegankelijk maken). Niet ingeschakeld standaard, maar de minikube dashboard opdracht zal Dashboard web UI implementeren en openen voor ons. Dit is bedoeld voor gemak in lokale dev – één opdracht en we hebben een GUI om werkbelastingen te zien. Niet opgenomen. We kunnen Dashboard installeren (YAML toepassen) als we willen. Anders, gebruik CLI of derde partij dashboard apps. In een homelab, zou iemand Dashboard installeren en een NodePort maken of kubectl proxy gebruiken om het te bekijken. Kubeadm is niet geïnteresseerd in UIs.

Bronnen: De bovenstaande gegevens zijn gesynthetiseerd uit officiële documentatie en gebruikersgidsen: bijvoorbeeld geheugenvoetafdrukken van MicroK8s eigen vergelijking, standaardopslag in K3s documentatie, K3s service LB gedrag van K3s documentatie, MicroK8s add-on details van Canonical documentatie, Minikube PV en tunnel van Kubernetes documentatie, en algemene ervaringsrapporten. (Zie Referenties voor volledige citaten.)

Aanbevelingen

Aan de hand van de prioriteiten (gemak bij installatie/bewaking en ingebouwde ondersteuning voor opslag en load balancers) en de scenario (3 Ubuntu-nodes, geen zorgen over HA):

  • Topkeuzes: K3s of MicroK8s zijn de meest geschikte opties voor een 3-node homelab:

    • Beide zijn extreem gemakkelijk te installeren (één opdracht per node) en vereisen minimale aanhoudende onderhoud. Ze abstracten de meeste complexiteit van het uitvoeren van een cluster weg.
    • Beide ondersteunen multi-node clustering standaard (we kunnen onze 3 nodes bij elkaar voegen en één geïntegreerd cluster zien).
    • Ze bieden elk een oplossing voor Persistent Volumes en LoadBalancers zonder veel inspanning: K3s bevat deze standaard (Local Path opslag, Klipper LB) en MicroK8s maakt ze beschikbaar via eenvoudige enable-opdrachten. Dit betekent dat we typische toepassingen (databases met PVCs, services met type=LoadBalancer) kunnen implementeren met minimale manuele instellingen.
    • K3s kan aantrekkelijk zijn als we het absoluut kleinste voetafdruk willen en de ingebouwde standaarden (zoals Traefik ingress) niet erg storen. Het is een “zet op en het werkt” aanpak met voorkeursspecificaties. Het is ook zeer populair in de homelab gemeenschap vanwege zijn eenvoud. We zullen vooral standaard kubectl gebruiken en kunnen de ingepakte componenten indien nodig aanpassen of uitschakelen. K3s kan voorkeur krijgen als we niet op Ubuntu zitten of als we de ecosystem van Rancher (of het idee om later het management UI van Rancher te gebruiken) leuk vinden.
    • MicroK8s kan aantrekkelijk zijn als we een oplossing willen die ondersteund wordt door Ubuntu en het idee van één-opdracht inschakelen van functies leuk vinden. Het is essentieel gewone Kubernetes onder de kap, wat voor sommigen makkelijker uitbreidbaar is. De add-ons (zoals microk8s enable ingress dns storage metallb) kunnen ons binnen Minuten een volledig functionele “micro cloud” geven. MicroK8s beheert ook updates soepel via snaps, wat handig kan zijn om onze cluster up-to-date te houden zonder manuele tussenkomst (we kunnen dit uitschakelen of het kanaal beheren om onaangename verrassingen te vermijden). Als we al Ubuntu draaien op alle nodes (wat we doen) en geen bezwaar hebben tegen het gebruik van snaps, is MicroK8s een uitstekende keuze voor een laag-onderhoud cluster.

    Kort gezegd: Je kan met beide K3s of MicroK8s geen fout maken in dit scenario. Beide zullen ons een eenvoudige, homelab-vriendelijke Kubernetes geven met de functies die we nodig hebben. Veel gebruikers melden positieve ervaringen met beide in 2–3 knooppunten thuisomgevingen. MicroK8s kan een licht voordeel hebben in gebruiksgemak (vanwege de add-ons en integratie), terwijl K3s een licht voordeel heeft in het draaien met een minimale voetafdruk en eenvoudig onder de kap.

  • Wanneer Minikube te kiezen: Als we alleen op één machine zouden draaien of een snelle tijdelijke dev cluster wilden, is Minikube geweldig daarvoor. Het is de makkelijkste manier om Kubernetes op een laptop of één knooppunt te draaien voor testdoeleinden. Echter, voor een blijvende 3-node cluster is Minikube niet de juiste tool – het zal die 3 nodes niet samenvoegen tot één cluster. We zouden onze hardware onderbenutten of 3 afzonderlijke clusters beheren, wat niet gewenst is. Dus, in deze homelab met meerdere knooppunten is Minikube niet aanbevolen als hoofdoplossing. We kunnen het nog steeds op onze persoonlijke computer gebruiken om dingen te proberen voordat we ze implementeren in de homelab cluster, maar voor de cluster zelf gebruiken we iets zoals K3s/MicroK8s.

  • Wanneer Kubeadm te kiezen: Als ons doel was om Kubernetes interne werkingen te leren of om volledige controle en een “productie-achtige” setup te hebben, is kubeadm een goede oefening. Het dwingt ons om te begrijpen hoe we CNI, opslag enz. moeten installeren, en we bouwen eigenlijk het cluster stuk voor stuk op. In termen van gebruiksgemak, is kubeadm echter de meest handmatige optie. Elke functie die we nodig hebben (zoals opslag of LB) moeten we configureren. Voor een homelab met focus op leren kan dit een voordeel zijn (educatief); voor een gewoon-werkend homelab is het een nadeel. Bovendien is onderhoud intensiever (vooral tijdens upgrades). Tenzij we specifiek willen de originele Kubernetes-ervaring voor leren of specifieke aangepaste behoeften, zal het gebruik van K3s of MicroK8s ons veel tijd en hoofdpijn besparen in een homelabomgeving. Met dat gezegd, prefereren sommige ervaren gebruikers kubeadm zelfs thuis om eventuele leveranciers-specifieke nuances te vermijden en alles onder hun controle te houden. Het hangt echt af van hoeveel inspanning we willen doen. Voor de meeste mensen is kubeadm overkill voor een klein cluster waarin hoge beschikbaarheid niet een zorg is.

  • Andere opties: Er zijn een paar andere lichte Kubernetes-varianten, zoals k0s (door Mirantis) en tools zoals kind (Kubernetes in Docker). Voor volledigheid:

    • k0s is een andere single-binary Kubernetes-distributie, met een vergelijkbaar doel als K3s/MicroK8s, die zich richt op flexibiliteit en een minimale voetafdruk. Het is relatief nieuw maar heeft fans in de homelab gemeenschap. Het kan ook gemakkelijk op onze 3 nodes draaien. Het heeft (momenteel) geen even grote gebruikersgroep als K3s/MicroK8s, maar het is een optie om in de gaten te houden (vooral als we het idee van een open source, aanpasbare, minimale Kubernetes leuk vinden – enkele rapporten tonen zelfs aan dat k0s iets minder idle-resources gebruikt dan K3s/MicroK8s in vergelijkbare opstellingen).
    • kind is vooral bedoeld voor het testen van Kubernetes clusters in Docker containers (vaak gebruikt in CI-pijplijnen). Het is iets wat we niet zouden draaien als onze altijd-actieve homelab cluster – het is meer voor tijdelijke clusters op één machine (zoals Minikubes doel).
    • Rancher Kubernetes Engine (RKE) of K3d of andere zijn ook beschikbaar, maar die zijn gericht op containerclusters (k3d draait een K3s cluster in Docker) of complexere implementatie scenario’s. In een homelab zijn K3s en MicroK8s geworden de standaard eenvoudige oplossingen.

Conclusie: Voor een homelab met 3 goede nodes, zijn MicroK8s of K3s de aanbevolen keuzes om een functionele Kubernetes cluster te krijgen met minimale moeite. Ze zullen ons laten profiteren van alle nodes in één cluster en bieden ingebouwde ondersteuning voor persistent volumes en LoadBalancer services, wat precies wat we wilden. Als we een meer plug-and-play, Ubuntu-integreerde oplossing willen, kies dan voor MicroK8s. Als we een super lichte, bewezen oplossing willen met ondersteuning van Rancher, kies dan voor K3s. We zullen in beide gevallen binnen Minuten een werkende cluster hebben. Zodra het draait, kunnen we het Kubernetes Dashboard of andere tools implementeren om het te beheren, en beginnen we met het hosten van onze toepassingen met persistente opslag en eenvoudige service-expositie. Geniet van onze homelab Kubernetes reis!

Kubernetes Distributies Homepage