Vilken är den bästa Kubernetes-distributionen för hemma-lab?

De bästa Kubernetes-distributionerna för hemma-labbar är K3s eller MicroK8s.

Jämförelse av Kubernetes-distributioner för ett 3-nodigt hemma-lab

Att välja den bästa Kubernetes-varianten för vårt hemkontor

Sidinnehåll

Jag jämför självvärdande Kubernetes-varianter (https://www.glukhov.org/sv/post/2025/08/kubernetes-distributions-comparison/ “Jämförelse av Kubernetes-distributioner”) som passar för Ubuntu-baserade homelabs med 3 noder (16GB RAM, 4 kärnor vardera), med fokus på enkel installation och underhåll, stöd för persistent volymer och LoadBalancers.

Scenario: Vi har tre Ubuntu-noder (16 GB RAM, 4 CPU-kärnor vardera) i ett homelab. Hög tillgänglighet (HA) och ARM-stöd är inte prioriterat. Vi vill ha ett enkelt att installera, lågmaintanans Kubernetes-kluster (antingen single-node eller 3-node) med stöd för Persistent Volumes (PV) och LoadBalancer (LB)-tjänster (så att molnbaserade appar som kräver lagring eller externa IP-adresser fungerar smidigt). Vi kommer att koncentrera oss på 3-node-klusteralternativ utan HA- eller ARM-CPU-kompatibilitets krav.

kubernetes homelab

Nedan jämför vi populära lätta [Kubernetes(https://www.glukhov.org/sv/post/2024/10/kubernetes-cheatsheet/ “lista och beskrivning av de vanligaste och mest användbara k8s-kommandona - k8s cheatsheet”) distributioner – K3s, MicroK8s, Minikube och kubeadm (vanilla Kubernetes) – och hur de står sig i förhållande till de viktigaste kriterierna (funktioner, installation/underhåll, PV/LB-stöd, resurskrav, klustersättning och verktyg). Har också några rekommendationer för vilket man ska välja baserat på homelab-scenariot.

K3s (Ranchers lätta Kubernetes)

Nyckelfunktioner: K3s är en CNCF-certifierad Kubernetes-distribution som är designad för minimal resursanvändning (den kan köra på så lite som 512 MB RAM). Den paketerar hela Kubernetes-kontrollplanen i en enda binärfil och process, med hjälp av lätta komponenter (t.ex. SQLite-databas som standard istället för etcd, flannel för nätverk). Den inkluderar rimliga standardinställningar som en inbyggd ingress-kontroller (Traefik) och en enkel tjänstbelastningsutjämnare. K3s tar bort gamla/alpha-funktioner för att minska uppblåsthet.

Enkel installation & underhåll: Extremt enkel - vi kan installera den med ett enda kommando (curl ... | sh) eller via verktyg som K3sup. Servern startar med standardkomponenter direkt. Att lägga till noder är enkelt (kör K3s-agenten med en token från servern). Uppgradering är enkelt (byta binärfil eller använda installationsskriptet för ny version). Inget separat etcd-uppsättning behövs (om inte man väljer en multi-master HA-uppsättning). K3s är designat för att kräva minimal justering efter installation, vilket gör den populär för IoT och homelabs.
Stöd för persistent volymer: Inbyggt. Som standard levereras K3s med Ranchers local-path StorageClass, som dynamiskt tillhandahåller PVs i host-filsystemet för varje PVC. Detta innebär att varje PVC uppfylls genom att skapa en hostPath-volym på noden automatiskt. Det är en single-node-lagringslösning (varje volym är på en nods disk), men fungerar direkt för stateful-appar. För mer avancerad lagring kan man lägga till något som Ranchers Longhorn (distribuerad blocklagring) som K3s stöder, men för ett homelab räcker oftast den standard local-path-provisionern.
LoadBalancer-stöd: Inbyggt. K3s inkluderar en lättviktig kontrollant som kallas ServiceLB (tidigare “Klipper LB”) som tillåter tjänster av typen LoadBalancer att få en IP/port på värden utan någon extern molnleverantör. När vi skapar en LoadBalancer-tjänst, distribuerar K3s en DaemonSet av små LB-pods (svc-...) på varje nod, som använder host-portar för att vidarebefordra trafik till tjänsten. I grund och botten återanvänder K3s nodens IP (intern eller extern) som LB-IP och använder iptables-routing i LB-pods för att skicka trafik till tjänstens ClusterIP. Detta fungerar med noll konfiguration – tjänster kommer inte att vara “pending” (till skillnad från vanlig K8s på bare metal). Kompromissen är att den externa LB-IP:n kommer att vara en av våra nodes IP-adresser (eller alla noder) och vi måste se till att porten är ledig. För de flesta homelab-användningar (exponera några tjänster på HTTP/HTTPS-portar) är detta perfekt. Om det behövs kan vi stänga av den inbyggda LB och installera MetalLB manuellt, men de flesta använder den bekväma standarden.
Resurskrav: Mycket låga. K3s kan köra även på lågpresterande hårdvara. Officiellt räcker 512 MB RAM och några hundra MB disk för en servernod. I praktiken kan ett litet kluster använda några hundra MB minne för kontrollplanen. Dess binärfil är <100 MB. CPU-överhead är minimal (K3s använder något mer CPU i idle-läge jämfört med MicroK8s, men inte med en stor marginal). Våra noder (16 GB vardera) är mer än tillräckliga för att köra K3s bekvämt.
Single-Node vs Multi-Node: Lämplig för båda. K3s kan köra single-node (alla kontrollplaner och arbetsbelastningar på en maskin) eller multi-node. För en 3-node-uppsättning kan vi köra 1 server (master) och 2 agenter, eller till och med göra alla 3 servrar för HA (inte nödvändigt här eftersom HA inte är ett mål). Att ansluta agenter är trivialt med token. K3s standard SQLite-databas fungerar för single-server; för multi-server HA skulle vi byta till inbyggd etcd (K3s kan göra detta automatiskt när man startar flera servernoder).
CLI & UI-verktyg: Vi interagerar med K3s precis som med vilket Kubernetes som helst – via kubectl. K3s inkluderar sin egen kubectl-byggnad (vi kan köra k3s kubectl ... eller bara använda en standard kubectl genom att peka den på K3s kubeconfig). Det finns ingen speciell K3s-specifik CLI utöver installationskommandon; det är avsiktligt minimalistiskt. Inget inbyggt web-gränssnitt är inkluderat (upstream Dashboard installeras inte som standard). Dock kan vi manuellt distribuera Kubernetes Dashboard eller andra verktyg på K3s som på vilket standardkluster som helst. Rancher (GUI-hanteringsverktyget av samma företag) kan också installeras på K3s om ett fullständigt gränssnitt önskas, men det är inte en del av K3s självt. I grund och botten tillhandahåller K3s de grundläggande k8s-API:erna och vi lägger till extra funktioner som vi behöver (ingress, lagring etc. - några av vilka redan är paketerade som nämnts).

MicroK8s (Canonicals lättviktiga Kubernetes)

Nyckelfunktioner: MicroK8s är Canonicals lättviktiga Kubernetes-distribution, levererad som ett snap-paket. Det installerar en fullt konform Kubernetes-kluster (upstream-binärer) med ett enda kommando och är utformat för enkelhet (“low ops”) på en enda maskin eller ett litet kluster. Det betonar ett “batteries-included”-tillvägagångssätt - vi får många valfria funktioner som kan aktiveras med enkla kommandon. MicroK8s standardiserar till en vanlig Kubernetes-upplevelse (alla standard-API:er) men med praktiska tillägg för vanliga behov. Det stöder både enskilda nod- och flernodsinstallationer (vi kan bilda ett kluster genom att “ansluta” noder), och har till och med en HA-läge för kontrollplanet (använder Dqlite - en distribuerad SQLite - när vi har 3 master-noder).

Enkel installation & underhåll: Extremt enkel - bara snap install microk8s --classic på en Ubuntu-maskin kommer att konfigurera en Kubernetes-nod. Det är ett paket som inkluderar alla komponenter. MicroK8s underhålls via Ubuntu snap-systemet, vilket innebär att uppdateringar är atomiska och kan vara automatiska (vi kan följa en kanal för Kubernetes-versioner). Denna automatiska uppdaterings-funktion är unik bland dessa alternativ - vi kan välja att få säkerhetsuppdateringar och mindre uppgraderingar via snap-uppdateringar. Hantering av MicroK8s sker via microk8s-kommandot, som har underkommandon för att aktivera/avaktivera funktioner. Sammanfattningsvis är det mycket lågt friktionsfritt: inga containrar eller virtuella maskiner att hantera (körs nativt på värden), och ingen extern etcd att konfigurera (använder en intern datalagring). Underhåll är främst att uppdatera snap-paketet när det behövs och använda microk8s.status för att övervaka.
Stöd för persistenta volymer: Tillgängligt via tillägg. Som standard tillhandahåller inte MicroK8s automatiskt PVs (Persistent Volumes) förrän vi aktiverar tillägget “hostpath-storage”. Aktivering av detta (med microk8s enable hostpath-storage) skapar en standard StorageClass som allokerar volymer från en katalog på värden. Detta är i grunden en dynamisk hostPath-provisionerare, liknande i koncept till K3s lokal-path. När det är aktiverat kommer varje PVC (Persistent Volume Claim) att bindas till en hostpath PV på MicroK8s-noden. (I ett flernodskluster kommer hostpath PV att finnas på en nod - lämpligt för testning eller hemklusteranvändning men inte distribuerad lagring). MicroK8s erbjuder också Mayastor och andra lagringstillägg om vi vill ha mer avancerad lagring mellan noder, men för enkelhetens skull fungerar hostpath-lagringen bra. Obs: Tillägg är inte aktiverat som standard (för att hålla saker enkla), så vi vill aktivera det för att få PVC att fungera. Canonical noterar att detta inte är för produktions-HA-användning (eftersom det inte är replikerat), men för ett hemkluster är det perfekt.
LoadBalancer-stöd: Tillgängligt via tillägg. MicroK8s innehåller inte en standard LoadBalancer, men det erbjuder MetalLB som ett enkelt tillägg. Att köra microk8s enable metallb:<start-IP>-<end-IP> installerar MetalLB i Layer 2-läge och låter oss ange ett intervall av IP-adresser från vårt LAN att använda för LoadBalancer-tjänster. När det är aktiverat kommer varje tjänst av typen LoadBalancer att automatiskt få en IP-adress från det intervallet (och MicroK8s kommer att annonsera den via ARP på LAN). Detta ger en molnliknande upplevelse på fysisk hårdvara. (Om vi inte aktiverar MetalLB kommer en LoadBalancer-tjänst att förbli i vänteläge, eftersom MicroK8s i sig inte implementerar en - precis som upstream Kubernetes.) I ett hemkluster är MetalLB enkelt och låter oss komma åt tjänster på vårt lokala nätverk. Vi kommer att behöva välja ett fritt underområde eller IP-intervall i vårt nätverk för det. MicroK8s aktiveringskommando gör inställningen smärtfri, men det är fortfarande ett separat steg. (I kontrast fungerar K3s direkt för LB men med begränsningen att använda nod-IP/portar.) Många MicroK8s-användare aktiverar helt enkelt MetalLB som en del av deras initiala konfiguration för en fungerande LB.
Resurskrav: MicroK8s är ganska lättviktigt, även om det är något större än K3s i fotavtryck. Det kör alla kärnkomponenter (API-server, controller, schemaläggare, kubelet, etcd eller Dqlite) nativt. Icke-användning är vanligtvis ~500–600 MB RAM för kontrollplanet, beroende på vilka tillägg som är aktiverade. Canonical anger ~540 MB basminne. CPU-användning är låg i vila, och våra 16 GB-noder har gott om marginal. Diskutrymmeskravet är litet (snap ~200 MB plus etcd-data). Sammanfattningsvis kan MicroK8s köra på måttlig hårdvara (det erbjuds till och med för Raspberry Pis), och i vårt scenario klarar maskinerna det lätt. Om flera tillägg är aktiverade (dashboard, övervakning etc.) kommer resursanvändningen att öka motsvarande.
Enskild nod vs flernod: MicroK8s fungerar bra för båda. Vi kan använda det för ett kluster med en enda nod (t.ex. på en utvecklingsmaskin eller en server) eller skapa ett flernodskluster genom att “ansluta” noder. MicroK8s-dokumentationen ger ett kommando för att lägga till en nod (vi hämtar ett anslutningstoken från den första noden och använder det på de andra). I en flernodskonfiguration utan HA kommer en nod att vara den primära kontrollplanen. Med 3 noder har vi också alternativet att aktivera ha-cluster-läge (gör kontrollplanen HA genom att köra Dqlite på 3 noder), även om HA inte behövs i vårt fall. Oavsett om det är en eller tre noder är upplevelsen densamma Kubernetes-API. Flernod MicroK8s är något nyare än K3s tillvägagångssätt men är ganska stabilt nu. Det är ett bra val om vi vill ha en “micro-moln” av några Ubuntu-boxar som kör k8s med minimal ansträngning.
CLI & UI-verktyg: MicroK8s kommer med microk8s kommandoverktyg, som är mycket praktiskt. Till exempel aktiverar microk8s enable <tillägg> olika tjänster (DNS, ingress, lagring, metallb, dashboard etc.), och microk8s status visar vad som körs. Det inkluderar också en inbyggd kubectl: vi kan använda microk8s kubectl ... (eller skapa en alias) som kommunicerar med klustret - detta är bra eftersom vi inte behöver konfigurera en kubeconfig. För UI erbjuder MicroK8s Kubernetes Dashboard som ett tillägg (microk8s enable dashboard), som kommer att installera standardwebbgränssnittet. När det är aktiverat kan vi komma åt det (det körs på port 10443 eller via proxy). MicroK8s har inte ett eget anpassat gränssnitt - det förlitar sig på Kubernetes Dashboard eller andra verktyg - men enkelheten att aktivera det är en fördel. Sammanfattningsvis betonar MicroK8s en en-kommando-upplevelse för vanliga uppgifter och en “det fungerar bara”-filosofi, som abstraherar bort mycket komplexitet (åt kostnad av att dölja några interna detaljer). Detta gör det mycket hemkluster-vänligt för de som vill ha ett Kubernetes-kluster utan manuell konfiguration av varje komponent.

Kontrast K3s vs MicroK8s: Båda är ganska liknande i mål och funktioner - lättviktiga, enkla, flernodskapabla. K3s tenderar att vara något mer “DIY” när det gäller att lägga till extra funktioner (förlitar sig på Helm-charts eller manuella manifest för saker som inte är inkluderade) medan MicroK8s erbjuder inbyggda tillägg via sitt CLI. MicroK8s är också en mer “vanlig” Kubernetes under ytan (upstream-komponenter, bara paketerade som snap), medan K3s använder några anpassade binärer och en enda tjänst för allt. Båda är bra val för ett hemkluster; beslutet handlar ofta om preferenser: om Ubuntu/snaps och en integrerad känsla är att föredra, är MicroK8s bra, medan om vi föredrar en minimalistisk tillvägagångssätt med kanske lite mer manuell kontroll, är K3s utmärkt. (Vi kommer att ge rekommendationer i slutet.)

Minikube (Single-Node Local K8s)

Nyckelfunktioner: Minikube är främst ett verktyg för att köra Kubernetes lokalt (ofta på en utvecklares PC eller bärbar dator) snarare än ett traditionellt kluster över flera maskiner. Det skapar ett single-node Kubernetes-kluster i en VM eller container på vår maskin. Minikube är känt för sitt breda stöd för miljöer – det kan köra på Linux, macOS, Windows och stöder olika hypervisorer (VirtualBox, KVM, Hyper-V, Docker driver etc.). Det underhålls av Kubernetes SIGs och används ofta för testning och inlärning. Medan Minikube kan tvingas in i en multi-node-konfiguration, är det egentligen avsett för single-node-kluster (Minikubes “multi-node”-läge startar faktiskt bara flera noder på samma värd med container-runtimes – användbart för att simulera ett kluster, men inte för att köra på separata fysiska maskiner).

Lätt installation & användning: Minikube är mycket enkelt att komma igång med på en enda maskin. Vi installerar minikube-binären, säkerställer att vi har en VM-drivrutin (eller Docker) och kör minikube start. Detta kommer att konfigurera en lokal VM/container och starta Kubernetes i den. Det är kanske det enklaste sättet att få ett Kubernetes-kluster att köra för första gången. CLI (minikube) ger kommandon för att interagera med VM:n (starta, stoppa, ta bort) och för att aktivera tillägg. Eftersom Minikube är designat för lokal användning är det inte en “långlöpande” demon – vi startar den vanligtvis när vi behöver den och stoppar den när vi är klara, även om vi kan hålla den igång kontinuerligt på en homelab-server om vi vill. Underhåll/uppgraderingar är enkla: uppdatera bara minikube-versionen och starta om klustret (Minikube kan också uppdatera Kubernetes-versionen den kör med en flagga). En begränsning är dock att Minikube är single-node av design (att lägga till fler noder innebär att starta ytterligare VM-instanser på samma värd, inte att ansluta riktiga separata värdar). Att använda Minikube på tre separata fysiska noder skulle alltså innebära att köra tre oberoende single-node-kluster, vilket troligen inte är vad vi vill. Minikube är perfekt för utveckling och testning på en maskin, men det är inte avsett för att hantera ett kluster som sträcker sig över flera fysiska servrar.
Stöd för persistent volymer: Inbyggt (hostPath). Minikube-kluster inkluderar automatiskt en standard StorageClass som använder en hostPath-provisioner. Faktiskt kör Minikube en liten controller som dynamiskt skapar hostPath PVs i VM:n när PVCs begärs. Detta innebär att vi kan skapa PersistentVolumeClaims och de kommer att uppfyllas med lagring på Minikube VM:s filsystem (vanligtvis under /tmp/hostpath-provisioner eller liknande). Detta fungerar direkt – ingen konfiguration behövs för grundläggande PV-användning. Till exempel mappas standard StorageClass “standard” i Minikube till hostPath-lagring på noden. En begränsning: om vi startar om eller tar bort Minikube VM:n kan dessa hostPath-volymer gå förlorade (Minikube försöker dock att bevara vissa kataloger vid omstart – t.ex. /data, /var/lib/minikube, /tmp/hostpath* bevaras). Men i allmänhet är detta bra för en icke-produktionsmiljö. Om vi vill simulera mer har Minikube också ett CSI hostpath driver addon som stöder snapshots och kan fungera i multi-node-läge, men det är mer för experimentering. Sammanfattningsvis: Minikube stöder PVs som standard via hostPath, vilket är tillräckligt för att testa stateful-appar i en homelab.
LoadBalancer-stöd: Stöds via tunnling (eller MetalLB addon). I molnet får en LoadBalancer-tjänst en moln-LB med en extern IP. I Minikube finns det naturligtvis ingen molnleverantör, så Minikube erbjuder två mekanismer:
- Minikube Tunnel: Vi kan köra minikube tunnel i en separat process som kommer att skapa en nätverksväg på vår värd och tilldela en IP till vår LoadBalancer-tjänst. Essentiellt använder det vår värd för att agera som “extern LB”. När vi skapar en LoadBalancer Service kommer Minikube att visa en “extern IP” (vanligtvis från klustrets subnät) och minikube tunnel-processen kommer att dirigera den till tjänsten. Detta kräver att tunnelprocessen fortsätter att köra (och vanligtvis root-behörighet för att skapa vägar). Det är lite av en manuell steg, men Minikube skriver ut en påminnelse om vi har en LoadBalancer-tjänst utan en tunnel som körs (“External-IP pending” tills vi startar tunneln).
- MetalLB Addon: Nyare versioner av Minikube inkluderar också ett MetalLB addon. Vi kan göra minikube addons enable metallb och konfigurera ett IP-intervall (Minikube kommer att fråga oss). Detta installerar effektivt MetalLB i Minikube-klustret, som sedan hanterar LoadBalancer-tjänster precis som det skulle på något bare-metal Kubernetes. Detta är en mer “in-cluster”-lösning och kräver inte en separat tunnelprocess efter initial konfiguration.
Båda alternativen fungerar, och vilket vi ska använda är upp till oss. För en snabb exponering av en tjänst är minikube tunnel snabb och tillfällig. För en mer permanent konfiguration kan MetalLB addon aktiveras så att LBs får riktiga IPer (till exempel kan vi ge det ett intervall som 10.0.0.240-250 på en Minikube med bridged-nätverk). Kom ihåg att Minikube vanligtvis är single-node, så i effekt är “load balancern” inte balanserande över flera noder – den ger bara extern åtkomst till tjänsten på den enda nodens service. Detta är bra för utveckling. I en homelab, om vi bara använder en av våra noder och kör Minikube på den, kan vi använda dessa för att komma åt våra appar. Men om vi vill utnyttja alla 3 noder är Minikubes tillvägagångssätt för LB inte avsett för det scenariot.
Resurskrav: Minikube i sig är lättviktigt, men eftersom det vanligtvis kör ett fullständigt single-node Kubernetes (i en VM), är resursanvändningen liknande ett normalt litet kluster. Det rekommenderade minimum är 2 GB RAM och 2 CPU:er för VM:n. Som standard tilldelar Minikube ofta 2 GB RAM till sin VM. I vårt fall, med 16 GB per maskin, är det trivialt. En Minikube (Kubernetes) i idle-läge kan använda ~600 MB minne. En sak att tänka på är att Minikube kommer att köra ovanpå vårt OS – antingen som en VM via en hypervisor eller en Docker-container – vilket lägger till lite overhead. På en homelab-server kan vi köra Minikube med “none”-drivrutinen (som installerar Kubernetes-komponenter direkt på värden), men “none” (även känd som bare-metal)-drivrutinen är i princip liknande att bara använda kubeadm på den noden och kräver manuell rensning, så den är inte lika populär. De flesta använder en VM eller Docker-drivrutin. Sammanfattningsvis kan någon av våra homelab-noder köra Minikube lätt. Den enda begränsningen är att Minikube inte kommer att använda resurserna från alla 3 noder – det kommer att vara begränsat till den enda värden det körs på (om inte den experimentella multi-node inom en värd används).
Single-Node vs Multi-Node: Primärt single-node. Minikube är idealiskt för ett single-node-kluster på en maskin. Det har en funktion för att simulera flera noder (t.ex. minikube start --nodes 3 med Docker-drivrutinen kommer att starta 3 Kubernetes-noder som containrar på en värd), men detta är bara för testning. Vi kan inte använda Minikube för att skapa ett riktigt multi-node-kluster över 3 separata fysiska servrar. Om vi har 3 maskiner måste vi köra 3 oberoende Minikube-instanser (inte i ett kluster). Det är inte en riktig klusterexperiens (de kommer inte att känna till varandra). Därför är Minikube inte rekommenderat om vårt mål är att utnyttja alla tre noder i ett Kubernetes-kluster – det är bättre för scenarier där vi bara har en maskin (vår PC eller en server) och vill köra K8s på den. Det är också bra för att lära sig grunderna i Kubernetes och göra lokal utveckling.
CLI & UI-verktyg: minikube CLI är det huvudsakliga gränssnittet. Vi använder det för att starta/stoppa klustret, och det har trevliga genvägar: t.ex. minikube dashboard kommer att aktivera Kubernetes Dashboard och öppna det i vår webbläsare för oss. minikube addons enable <addon> kan aktivera en mängd olika valfria komponenter (ingress, metallb, metrics-server etc.). Minikube konfigurerar kubectl-åtkomst automatiskt (det konfigurerar en kontext “minikube” i vår kubeconfig). För UI, som nämnts, är Kubernetes Dashboard lättillgängligt via dashboard-kommandot. Minikube har inte sitt eget unika webbgränssnitt; det förlitar sig på standardverktyg. Felsökning av Minikube är också enkelt eftersom vi kan minikube ssh för att komma in i nod-VM:n om det behövs. Sammanfattningsvis är verktygen mycket användarvänliga för ett single-node-scenario.

Kubeadm (Vanilla Kubernetes på våra egna noder)

Nyckelfunktioner: Kubeadm är inte en “distribution” utan snarare det officiella verktygssetet för att skapa en Kubernetes-kluster från grunden. Att använda kubeadm innebär att vi distribuerar standarduppströms Kubernetes-komponenter på våra maskiner. Det är i grunden hur vi “byggar egen” kluster, följer bästa praxis men utan de extra funktioner som distributioner inkluderar. Kubeadm kommer att konfigurera en kontrollplan-nod (som kör etcd, API-server, kontrollant, schemaläggare) och ansluta arbetarnoder till den. Resultatet är en fullständigt standard Kubernetes-kluster identisk med vad vi skulle få på moln-VM:er. Denna metod ger oss full kontroll och flexibilitet - vi väljer nätverksplugin, lagringsförsörjning etc. - men kräver också mest initial manuellt arbete och kunskap. Det används ofta i produktions- eller lärmiljöer för att förstå Kubernetes-internals.

Lätthet att installera & underhålla: Jämfört med de andra är kubeadm den mest involverade. Vi måste manuellt installera beroenden (container-runtime som containerd, kubeadm, kubelet, kubectl) på varje nod. Sedan kör vi kubeadm init på master-noden, och kubeadm join på arbetarna med den token den ger. Vi måste också konfigurera ett CNI (nätverksplugin) efter initialiseringen (Calico, Flannel etc.) eftersom kubeadm inte installerar något som standard. Det finns väl dokumenterade steg för allt detta (processen är inte svår, men det är många steg) - i grund och botten får kubeadm oss en startkluster men förväntar sig att vi hanterar tilläggen. Vid underhåll är vi ansvariga för uppgraderingar (kubeadm har ett uppgraderingskommando, men vi måste tömma noder, uppdatera binärfiler etc. manuellt), samt övervakning av etcd-hälsa, certifikatsförnyelse etc. Sammanfattningsvis är kubeadm kraftfullt men manuellt. Det kallas ofta “the hard way” (fast inte lika svårt som att bygga från källkod). För en homelab-entusiast som gillar att lära sig är kubeadm ett bra sätt att förstå Kubernetes på djupet. Men om vår prioritet är “enkelt och lågt underhåll” kommer kubeadm att vara mer arbete än K3s/MicroK8s. Varje uppgradering eller förändring kommer att kräva manuellt arbete. Det sagt, när det är uppsatt är det den riktiga grejen: en standard Kubernetes-kluster utan dolda abstraktioner.
Stöd för Persistent Volumes: Ingen som standard (måste läggas till manuellt). En kubeadm-installerad kluster är i grund och botten en blank Kubernetes - den innehåller inte en standard StorageClass eller dynamisk försörjning av lagring som standard. I molnmiljöer skulle molnleverantören normalt tillhandahålla en standard StorageClass (t.ex. AWS EBS etc.), men i en homelab-bare-metal-miljö måste vi installera vår egen lösning. Vanliga tillvägagångssätt:
- HostPath Provisioner: Vi kan replikera vad K3s/Minikube gör genom att installera något som Rancher Local Path Provisioner (som är en liten kontrollant + StorageClass som skapar hostPath PVs). Detta är ett enkelt tillägg (bara en YAML-manifest) och ger oss lokal dynamisk lagring.
- NFS eller NAS: Vissa homelab-användare sätter upp en NFS-server (eller använder en NAS) och använder sedan statiska PVs eller en NFS CSI-drivrutin för försörjning.
- OpenEBS/Longhorn/Ceph: Det finns mer komplexa alternativ som att distribuera Longhorn eller Ceph RBD via Rook om vi vill ha distribuerad lagring över noder. Dessa kräver mer resurser och komplexitet.
Det viktiga är att kubeadm inte “löses” lagring för oss - vi måste besluta och konfigurera det. Om enkelhet är prioritet är den enklaste vägen att distribuera en hostPath-provisioner eller använda NFS. Till exempel kan Ranchers local-path provisioner installeras i ett par kubectl apply-kommando och kommer att efterlikna K3s-beteende (skapa volymer under /var/lib/rancher/ på vilken nod som helst). Men detta är ett manuellt steg. Tills vi gör det kommer varje PVC vi skapar att sitta i Pending-tilstånd eftersom Kubernetes inte har någon standardförsörjning på plats. Så, även om kubeadm definitivt stöder Persistent Volumes (det är full Kubernetes), är stödet för dynamisk PV lika bra som den ansträngning vi lägger på att sätta det upp.
LoadBalancer-stöd: Ingen som standard (måste läggas till manuellt). Liknande historia här: i en traditionell on-prem-kluster har vi inte en inbyggd LoadBalancer-implementering. Om vi skapar en Service av typen LoadBalancer på en ren kubeadm-kluster kommer den att sitta i pending-tilstånd för alltid tills vi distribuerar en kontrollant för att hantera den. Det vanliga lösningen är att installera MetalLB själva. MetalLB kan installeras via manifest eller Helm-chart - vi skulle konfigurera ett IP-område och det kommer sedan att allokera dessa IP:er för LoadBalancer-tjänster (precis som i MicroK8s). Många guider finns för att installera MetalLB på kubeadm-kluster. Ett annat alternativ som vissa använder är kube-vip för kontrollplan-VIP och tjänst-LB:er, men MetalLB är enklare för tjänster. I grund och botten har vi med kubeadm friheten (eller bördan) att sätta upp vilken lastbalanseringsmekanism som passar våra behov. Om vi inte sätter upp något är vi begränsade till NodePort-tjänster för extern åtkomst. För en homelab är installation av MetalLB starkt rekommenderad - det är enkelt och ger oss den molnliknande tjänst-IP-funktionaliteten. Men igen, det är ett extra steg vi måste utföra (till skillnad från K3s som fungerar direkt eller MicroK8s med en enkel aktivering).
Resurskrav: Standard Kubernetes är lite tyngre än de nedskärda versionerna. Varje nod kommer att köra en kubelet och kube-proxy, och master-noden kommer att köra etcd och kontrollplan-komponenter. En enda kontrollplan-nod kan fortfarande köra i 2 GB RAM, men vanligtvis skulle vi vilja ha lite mer för komfort om vi kör pods på den. Padok-guiden föreslår 2 GB för master, 2 GB för arbetare som minimum. I vårt scenario (16 GB per nod) är det bra. Tomma etcd och API-server kan använda några hundra MB minne var. Det finns ingen stor skillnad vid körning mellan en kubeadm-kluster och MicroK8s - till slut är MicroK8s dessa samma komponenter. Skillnaden är bara vad som körs som standard (MicroK8s kan aktivera DNS och lagring som standard, medan på kubeadm skulle vi installera dessa). Så sett till resurser kan kubeadm vara så lätt eller tung som vi konfigurerar den. Med inget extra installerat kan den vara ganska lätt. Med en typisk konfiguration (t.ex. vi lägger till CoreDNS, Dashboard etc.), förvänta dig ~1 GB eller så för systemöverhead. Vi har tillräckligt med RAM, så resurser är inte ett problem. Det handlar mer om den mänskliga tid/resurser som krävs för att hantera den än CPU/RAM.
Single-Node vs Multi-Node: Kubeadm kan göra både, med full flexibilitet. Vi kan initiera en single-node-kluster (och till och med säga till kubeadm att låta den enda noden köra arbetsbelastningar genom att avmarkera master-noden). Eller vi kan ha en master och ansluta två arbetare (en vanlig 3-nod-konfiguration). Vi skulle till och med kunna sätta upp 3 master-noder och 3 arbetare etc. - vilken topologi som helst. I vårt fall skulle en trolig kubeadm-konfiguration vara 1 kontrollplan-nod och 2 arbetare (eftersom HA inte behövs, behöver vi inte flera master-noder). Det ger oss en funktionell 3-nod-kluster. Processen för multi-node är väl dokumenterad: i grund och botten, få Kubernetes installerat på alla, initiera en, anslut de andra. Resultatet är identiskt med vad en hanterad kluster eller annan distribution skulle ge: våra 3 noder visas i kubectl get nodes etc. Så kubeadm uppfyller definitivt kravet “kan använda alla 3 noder”.
CLI & UI-verktyg: Med kubeadm är det enda special-CLI kubeadm självt, som används för installations- och (senare) uppgraderingssteg. Dagligen använder vi kubectl för att hantera klustret. Det finns inget integrerat hanterings-CLI utöver vad Kubernetes erbjuder. För UI finns inget inkluderat som standard - vi kan manuellt distribuera Kubernetes Dashboard eller vilket annat verktyg som helst (precis som i vilket kluster som helst). I grund och botten ger kubeadm oss en blank Kubernetes-duk. Det är upp till oss att måla på den - vilket inkluderar att installera bekvämligheter som dashboard, ingress-kontrollanter, storage-klasser etc. Många tredjeparts-dashboards (Lens, Octant etc.) kan också ansluta till en kubeadm-kluster om vi vill ha en GUI-hanteringsupplevelse, men dessa är externa verktyg. Sammanfattningsvis, med kubeadm får vi den rena Kubernetes-miljö - maximal flexibilitet, men också behovet av att sätta upp allt som om detta vore en produktionskluster.
Kubespray Se även hur man installerar denna variant av Kubernetes med Kubespray.

Jämförande tabell sida vid sida

Här nedan finns en sammanfattning som jämför de fyra alternativen på viktiga punkter:

| **Aspekt**                     | **K3s** (Lättvikts Rancher K8s)                                                                                                                                                                                                                                                                                   | **MicroK8s** (Canonical “Low-Ops” K8s)                                                                                                                                                                                                                                                | **Minikube** (Single-Node Dev K8s)                                                                                                                                                                                                                                                                                   | **Kubeadm** (Vanilla Kubernetes)                                                                                                                                                                                                                                                                                                                           |
| ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Installation**               | En-rad installationsskript (en enda binärfil). Körs som en enda systemtjänst. Mycket snabb uppsättning.                                                                                                                                                                                                               | En-kommandosinstallation via snap på Ubuntu. Alla komponenter inkluderade. Lätt klusterhantering med `microk8s join`.                                                                                                                                                                          | Installera minikube CLI, sedan `minikube start` för att starta en lokal VM/container. Plattformsoberoende och nybörjarvänlig.                                                                                                                                                                                   | Manuell installation av kubeadm, kubelet, etc. på varje nod. Kör `kubeadm init` + `kubeadm join` med förutsättningar. Innebär flera steg (runtime, nätverksplugin, etc.).                                                                                                                                                                           |
| **Underhåll & Uppgraderingar** | Manuella uppgraderingar (byta binärfil eller använda installationsskript för ny version). Enkel, eftersom det är en enda binärfil; lite att hantera. Inga automatiska uppdateringar.                                                                                                                               | Snap-uppdatering för uppdateringar (kan vara automatiska). Tillägg och klustertjänster hanteras via `microk8s` CLI. Generellt låg underhåll; automatiska uppgraderingar tillgängliga.                                                                                                           | Lätt att ta bort/skapa om kluster för utveckling. Uppgraderingar genom att uppdatera minikube-versionen och starta om klustret. Avsett för tillfällig användning (mindre fokus på uppgraderingars långsiktighet).                                                                                                           | Användaren ansvarar för alla uppgraderingar. Använd `kubeadm upgrade` men måste tömma noder, hantera etcd-backup, etc. Full kontroll, men du gör arbetet (inga automatiska uppdateringar).                                                                                                                                                     |
| **K8s Version**                | Följer uppströms ganska nära (ofta används i kantreleaser). CNCF-konform. Vissa funktioner inaktiverade som standard (alpha/ålderdomliga).                                                                                                                                                                      | Följer uppströmsreleaser (snap-kanaler för 1.27, 1.28, etc.). CNCF-konform. Essentiellt vanliga K8s-binärfiler.                                                                                                                                                                                | Vi kan välja Kubernetes-version vid start (t.ex. `minikube start --kubernetes-version=v1.27`). Standard till den senaste stabila versionen.                                                                                                                                                               | Vilken version vi vill (installera specifika kubeadm/kubelet-versioner). Full uppströms Kubernetes – vi bestämmer versionen och när vi uppgraderar.                                                                                                                                                                                   |
| **Standardfunktioner**         | Paketerade standardinställningar: Flannel CNI, CoreDNS, Traefik ingress, service LB, lokal lagringsklass, metrics-server, etc. (Alla kan inaktiveras om de inte behövs). Minimal konfiguration krävs för att vara funktionell.                                                                                       | Minimal standard: DNS är vanligtvis på, andra valfria. Lätt att lägga till ingångar (NGINX), MetalLB, hostpath-lagring, dashboard, etc. med ett kommando. Kan aktivera HA-läge på 3+ noder.                                                                                                | Paketerat i VM: inkluderar vanligtvis Docker/containerd-runtime, Kubernetes med standardtillägg som StorageProvisioner och DNS. Valfria tillägg (ingång, dashboard, etc.) aktiveras via CLI. Inget multi-nod som standard.                                                                                       | Grundläggande: Ingenting utöver kärn-Kubernetes. Ingen ingång, ingen standardlagring eller LB, inget dashboard förrän vi installerar dem. Vi väljer CNI-plugin (måste installera en för nätverket). Essentiellt en DIY-kluster.                                                                                                           |
| **Stöd för bestående volymer** | **Ja – direkt.** Ranchers *local-path* dynamiska tillhandahållare ingår, som skapar hostPath PVs på noden för varje PVC. Standardlagringsklassen “local-path” använder lokal disk automatiskt.                                                                                                          | **Ja – enkelt tillägg.** Aktivera `hostpath-storage` för att få en standardlagringsklass för dynamiska PVs som använder hostPath. Innan aktivering finns ingen standard PV-tillhandahållare. Tillägg är inte för multi-nod produktion, men fungerar bra för hemlab.                                 | **Ja – direkt.** Standardlagringsklassen använder hostPath-tillhandahållare inne i minikube-VM. PVC:er uppfylls av en enkel kontrollant som skapar en hostPath PV på nodens filsystem. Data bevaras över omstartar i vissa mappar.                                                                               | **Nej (manuellt).** Ingen standardtillhandahållare – klustret kommer inte att ha någon lagringsklass från början. Användaren måste installera en lagringslösning (t.ex. local path-tillhandahållare, NFS, Ceph, etc.). Grundläggande tillvägagångssätt: tillämpa en hostPath-tillhandahållare YAML för att efterlikna vad K3s/Minikube gör. Tills dess kommer PVC:er att vara i vänteläge. |
| **LoadBalancer-stöd**         | **Ja – inbyggd ServiceLB.** K3s *servicelb*-kontrollant (Klipper) övervakar LoadBalancer-tjänster och distribuerar pods på noder för att exponera dem. Använder nodens IP och host-portar för att vidarebefordra trafik. Fungerar direkt utan konfiguration. Lämpligt för små kluster; använder nodens interna/externa IP för tjänsten. | **Ja – via MetalLB-tillägg.** Aktivera `metallb` med ett IP-område för tilldelning. Ger en sann Layer-2 load balancer på bare metal. Inte aktiverat som standard. När aktiverat får varje LoadBalancer-tjänst ett unikt IP från vårt pool. Kräver lite initial konfiguration (IP-område).         | **Ja – via tunnel eller MetalLB.** Ingen moln-LB, men vi kan köra `minikube tunnel` för att tilldela ett externt IP till LoadBalancer-tjänster (skapar en väg på värden). Alternativt, aktivera MetalLB-tillägg i minikube för automatiska LB-IP:er. Som standard kommer LB-tjänster att visa “pending” tills vi använder en av dessa metoder. | **Nej (manuellt).** Ingen inbyggd LB. Vanligtvis installera MetalLB manuellt för bare-metal LB-funktion. När MetalLB (eller en annan LB-kontrollant) är installerad, fungerar LoadBalancer-tjänster. Utan det förblir LB-tjänster i vänteläge oändligt länge.                                                                                                 |

| Nätverksanslutning (CNI) | Standard = Flannel (overlay-nätverk). K3s stöder också ersättning av CNI vid behov. Kommer med CoreDNS installerat för klusterdns. Traefik ingång inkluderad som standard (kan inaktiveras). | Standard = Calico (för senare versioner i HA-läge) eller ett enkelt standardalternativ. (MicroK8s använde historiskt flannel; använder nu oftast Calico för strikt begränsning). CoreDNS aktiverat som standard. NGINX ingång tillgänglig via tillägg (microk8s enable ingress). | Standard = kubenet/bridge (beror på drivrutin; använder ofta ett enkelt NAT-nätverk). CoreDNS körs som standard. Vi kan aktivera ett NGINX ingångstillägg om det behövs. Nätverket är begränsat till den enda VM:n; NodePort är tillgänglig via minikube ip. | Val av CNI. Kubeadm installerar inget CNI-plugin – vi måste distribuera ett (Calico, Flannel, Weave etc.). Vi har full kontroll. De flesta guider visar hur vi tillämpar Calico YAML efter kubeadm init. CoreDNS installeras av kubeadm som standard för klusterdns. Ingresskontrollant – välj och installera själv (t.ex. NGINX eller Traefik via manifests/Helm). | | Multi-Node-klustring | Ja. Designad för multi-node. Lätt att ansluta med token. Kan använda extern DB eller inbyggd etcd för multi-master. Bra för 2-3+ nodar i hemlabbar. Inga extra beroenden behövs – K3s har sitt eget klustring inbyggt. | Ja. Stöder klustring av flera MicroK8s-nodar (med microk8s join). Kan aktivera HA med 3+ master (Dqlite). Mycket enkelt att bilda ett kluster, särskilt om alla nodar kör Ubuntu + snap. | Nej (fysiskt). Single-node som standard. Kan simulera multi-node på en maskin (flera nodar i Docker-containrar), men kan inte sträcka sig över flera fysiska värdar i ett kluster. Använd separata Minikube-instanser för separata kluster. | Ja. Stöder fullt ut multi-node (det är poängen). Vi kan ha 1 master + många arbetare, eller till och med flera master (fast kubeadm HA-uppsättning är mer komplex). Inga inbyggda begränsningar för klusterstorlek. | | Resursförbrukning | Mycket låg. Kontrollplan ~<0.5 GB minne i viloläge. En enda process för kontrollplanen ger liten fotavtryck. Effektiv på CPU (fast kan använda lite mer CPU i viloläge än MicroK8s enligt vissa rapporter). Idealisk för lågeffektsystem eller mycket överskottskapacitet. | Låg. ~0.5–0.6 GB minne för kontrollplan i viloläge. Lite högre basminne än K3s, men förblir stabilt. Använder Ubuntu snap (kan ha lite överhead). Fortfarande lättviktig i förhållande till fullständig Kubernetes. | Måttlig. VM standard 2 GB tilldelning (användning ~0.6 GB i viloläge). Kör en fullständig single-node Kubernetes, plus VM-lagret. Inget problem på 16 GB-system, men förbrukar i princip resurserna för ett litet kluster på en maskin. | Måttlig. En enda master med en arbetare kan använda ~1 GB i viloläge efter att typiska tillägg har lagts till. Varje ytterligare nod lägger till minimal overhead (bara kubelet, proxy). Liknande att köra Kubernetes i moln-VM av jämförbar storlek. På 3 nodar med 16 GB var kan overheaden försummas i sammanhanget. | | CLI-verktyg | Använd k3s för installation och som en wrapper för kubectl (eller använd standard kubectl). Inget separat hanterings-CLI (K3s är mestadels “inställ och glöm”). Några hjälpskript (t.ex., k3s-killall.sh). Ranchers GUI kan läggas till om önskat. | Rik microk8s CLI: t.ex., microk8s enable/disable <tillägg>, microk8s status. Inkluderar också microk8s kubectl. Designad för att förenkla vanliga uppgifter (inget direkt redigering av systemmanifest behövs för grunderna). | minikube CLI för att starta/stoppa kluster, hantera konfiguration och tillägg, och för att få information (IP, tjänst-URL, loggar). Ger också bekväma kommandon som minikube dashboard. Interagera med klustret via kubectl (konfigurationen ställs in automatiskt för minikube-kontext). | Endast kubeadm för initial konfiguration och uppgraderingar. Dagliga operationer via standard kubectl och andra Kubernetes-verktyg. Inget distributionsspecifikt CLI utöver bootstrap. Du kommer att arbeta med rena Kubernetes-kommandon och kanske OS-verktyg för underhåll. | | UI / Dashboard | Inte inkluderat som standard. Kan manuellt installera Kubernetes Dashboard eller använda externa verktyg (inget Rancher-specifikt om vi inte lägger till Rancher separat). K3s fokus är headless-drift. | Inte inkluderat som standard, men tillgängligt via ett kommando: microk8s enable dashboard distribuerar standard Dashboard-UI. Lätt åtkomst för kluster via microk8s dashboard-proxy. Integrerar också bra med Canonicals Lens GUI om önskat (Lens kan direkt ansluta till MicroK8s). | Inte aktiverat som standard, men kommandot minikube dashboard kommer att distribuera och öppna Dashboard-webbgränssnittet för oss. Detta är avsett för bekvämlighet i lokal utveckling – ett kommando och vi har en GUI för att se arbetsbelastningar. | Inte inkluderat. Vi kan installera Dashboard (tillämpa YAML) om vi vill. Annars använd CLI eller tredjeparts dashboard-appar. I en hemlab kan man installera dashboard och skapa en NodePort eller använda kubectl proxy för att visa den. Kubeadm bryr sig inte om UIs. |

Källor: De data ovan är sammanställda från officiella dokument och användarhandledningar, till exempel minnesavtryck från MicroK8s egen jämförelse, standardlagring i K3s-dokumentation, K3s tjänst LB-beteende från K3s-dokumentation, MicroK8s tilläggsdetaljer från Canonical-dokumentation, Minikube PV och tunnel från Kubernetes-dokumentationen, samt allmänna erfarenhetsrapporter. (Se Referenser för fullständiga citat.)

Rekommendationer

Givet prioriteringarna (lätt att konfigurera/underhålla och inbyggt stöd för lagring och lastbalanserare) och scenariot (3 Ubuntu-noder, inte orolig för HA):

Toppval: K3s eller MicroK8s är mest lämpade för ett 3-nodigt hemlab:
- Båda är extremt enkla att installera (ett enda kommando på varje nod) och kräver minimal pågående underhåll. De abstraherar bort mesta delen av komplexiteten att köra en kluster.
- Båda stöder multi-nod klustring direkt (vi kan ansluta våra 3 noder och se ett enhetligt kluster).
- De erbjuder var och en en lösning för Persistent Volumes och LoadBalancers utan mycket ansträngning: K3s inkluderar dem som standard (Local Path-lagring, Klipper LB) och MicroK8s gör dem tillgängliga via enkla enable-kommandon. Detta innebär att vi kan distribuera typiska applikationer (databaser med PVCs, tjänster med typ=LoadBalancer) med minimal manuell konfiguration.
- K3s kan vara attraktivt om vi vill ha den absolut minsta fotavtrycket och inte bryr oss om att använda dess inbyggda standarder (Traefik ingress, etc.). Det är ett “installera och det fungerar bara”-tillvägagångssätt med åsiktsbaserade standarder. Det är också mycket populärt i hemlab-communityt för sin enkelhet. Vi kommer att använda standard kubectl mestadels, och kan justera eller inaktivera de paketerade komponenterna om det behövs. K3s kan vara att föredra om vi inte är på Ubuntu eller om vi gillar Ranchers ekosystem (eller planerar att använda Ranchers hanteringsgränssnitt senare).
- MicroK8s kan vara attraktivt om vi föredrar en Ubuntu-stödd lösning och gillar idén med ett kommando för att aktivera funktioner. Det är i grunden vanilj Kubernetes under huven, vilket vissa tycker är lättare att utöka. Tilläggen (som microk8s enable ingress dns storage metallb) kan ge oss en fullt fungerande “micro-moln” på minuter. MicroK8s hanterar också uppdateringar smidigt via snaps, vilket kan vara trevligt för att hålla vårt kluster uppdaterat utan manuell inblandning (vi kan stänga av detta eller kontrollera kanalen för att undvika överraskningar). Om vi redan kör Ubuntu på alla noder (vilket vi gör) och inte bryr oss om att använda snaps, är MicroK8s ett utmärkt val för ett lågmaintanans-kluster.
Kort sagt: Kan inte gå fel med vare sig K3s eller MicroK8s för detta scenario. Båda kommer att ge oss ett enkelt, hemlab-vänligt Kubernetes med de funktioner vi behöver. Många användare rapporterar positiva erfarenheter av båda i 2–3 nodiga hemlab-miljöer. MicroK8s kan ha en liten fördel i användarvänlighet (på grund av tilläggen och integrationen), medan K3s kan ha en liten fördel i att vara lättviktig och rak under huven.
När man ska välja Minikube: Om vi bara kör på en enda maskin eller vill ha ett snabbt kastbart utvecklingskluster, är Minikube fantastiskt för det. Det är det enklaste sättet att starta Kubernetes på en bärbar dator eller en nod för testning. För ett permanent 3-nodigt kluster är Minikube dock inte rätt verktyg – det kommer inte att slå samman de 3 noderna till ett kluster. Vi skulle hamna i att underutnyttja vår hårdvara eller hantera 3 separata kluster, vilket inte är önskvärt. Så i detta hemlab med flera noder, rekommenderas Minikube inte som huvudlösning. Vi kan fortfarande använda Minikube på vår personliga dator för att testa saker innan vi distribuerar till hemlab-klustret, men för klustret självt, använd något som K3s/MicroK8s.
När man ska välja Kubeadm: Om vårt mål var att lära sig Kubernetes-internals eller att ha full kontroll och en “produktionslik” konfiguration, är kubeadm ett bra övning. Det kommer att tvinga oss att förstå hur man installerar CNI, lagring etc., och vi kommer i grund och botten att bygga klustret bit för bit. När det gäller användarvänlighet, är kubeadm dock den mest hands-on. Varje funktion vi behöver (som lagring eller LB) måste vi konfigurera. För ett lärande-fokuserat hemlab, kan detta vara en fördel (utbildande); för ett bara-få-det-att-fungera hemlab, är detta en nackdel. Underhåll kommer också att vara mer invecklat (särskilt under uppgraderingar). Om vi inte specifikt vill ha den vanilj Kubernetes-upplevelsen för lärande eller specifika anpassningsbehov, kommer användning av K3s eller MicroK8s att spara oss mycket tid och huvudvärk i en hemlab-miljö. Det sagt, vissa erfarna användare föredrar kubeadm även hemma för att undvika några leverantörsspecifika egenskaper och ha allt under sin kontroll. Det handlar verkligen om hur mycket ansträngning vi vill lägga ner. För de flesta är kubeadm överdrivet för ett litet kluster där hög tillgänglighet inte är en fråga.
Andra alternativ: Det finns några andra lättviktiga Kubernetes-varianter, som k0s (av Mirantis) och verktyg som kind (Kubernetes i Docker). För fullständighet:
- k0s är en annan single-binary Kubernetes-distribution, med liknande mål som K3s/MicroK8s, som fokuserar på flexibilitet och ett minimalt fotavtryck. Det är relativt nytt men har fans i hemlab-communityt. Det kan också köra på våra 3 noder enkelt. Det har (för närvarande) inte samma stora användarbas som K3s/MicroK8s, men det är ett alternativ att hålla ögonen på (särskilt om man gillar idén om en öppen källkod, konfigurerbar, minimal Kubernetes – vissa rapporter visar till och med k0s som använder något mindre idle-resurser än K3s/MicroK8s i liknande konfigurationer).
- kind är främst för att testa Kubernetes-kluster i Docker-containrar (ofta används i CI-pipelines). Det är inget vi skulle köra som vårt alltid-på hemlab-kluster – det är mer för snabba, tillfälliga kluster på en maskin (liknande Minikubes syfte).
- Rancher Kubernetes Engine (RKE) eller K3d eller andra finns också där, men de är antingen inriktade på containeriserade kluster (k3d kör ett K3s-kluster i Docker) eller mer komplexa distributionsscenarier. I ett hemlab har K3s och MicroK8s blivit de faktiska enkla lösningarna.

Slutsats: För ett hemlab med 3 bra noder, är MicroK8s eller K3s de rekommenderade valen för att få ett fungerande Kubernetes-kluster med minimal ansträngning. De kommer att låta oss utnyttja alla våra noder i ett kluster och erbjuda inbyggt stöd för persistent lagring och LoadBalancer-tjänster, vilket är exakt vad vi efterfrågade. Om vi föredrar en mer plug-and-play, Ubuntu-integrerad lösning, välj MicroK8s. Om vi föredrar en super lättviktig, beprövad lösning med Ranchers stöd, välj K3s. Vi kommer att ha ett fungerande kluster på minuter i vilket fall som helst. När det är uppsatt, kan vi distribuera Kubernetes Dashboard eller andra verktyg för att hantera det, och börja värd för våra applikationer med persistent lagring och enkel tjänstexponering. Nyut av vår hemlab Kubernetes-resa!