Confronto delle distribuzioni di Kubernetes per un homelab con 3 nodi

Scegliere la migliore versione di Kubernetes per il nostro homelab

Indice

Sto confrontando le varianti di Kubernetes auto-hostate adatte all’homelab basato su Ubuntu con 3 nodi (16 GB RAM, 4 core ciascuno), concentrandomi sulla facilità di installazione e manutenzione, il supporto per i volumi persistenti e i LoadBalancer.

Scenario: Abbiamo tre nodi Ubuntu (16 GB RAM, 4 CPU core ciascuno) in un homelab. La disponibilità ad alta disponibilità (HA) e il supporto ARM non sono prioritari. Vogliamo un cluster Kubernetes (singolo nodo o 3-nodi) facile da installare e da mantenere, con supporto per Persistent Volumes (PV) e LoadBalancer (LB) (in modo che le applicazioni native cloud che richiedono storage o indirizzi IP esterni funzionino correttamente). Concentreremo l’attenzione sulle opzioni per cluster a 3 nodi senza requisiti di HA o compatibilità CPU ARM.

kubernetes homelab

Di seguito confrontiamo le distribuzioni leggere di [Kubernetes(https://www.glukhov.org/it/post/2024/10/kubernetes-cheatsheet/ “elenco e descrizione dei comandi più frequenti e utili per k8s - k8s cheatsheet”) – K3s, MicroK8s, Minikube, e kubeadm (Kubernetes vanilla) – e come si confrontano sui criteri principali (funzionalità, installazione/mantenimento, supporto PV/LB, requisiti di risorse, configurazione del cluster e strumenti). Daremo anche alcune raccomandazioni su quale scegliere in base allo scenario dell’homelab.

K3s (Kubernetes leggero di Rancher)

Funzionalità principali: K3s è una distribuzione Kubernetes certificata da CNCF progettata per un utilizzo minimo delle risorse (può funzionare anche con così poco come 512 MB di RAM). Imballa l’intero piano di controllo Kubernetes in un unico binario e processo, utilizzando componenti leggeri (ad esempio, il database SQLite per default invece di etcd, flannel per la rete). Include impostazioni predefinite come un controller ingress integrato (Traefik) e un semplice bilanciatore di carico per i servizi. K3s elimina le funzionalità legacy/alpha per ridurre il sovraccarico.

  • Facilità di installazione e manutenzione: Estremamente semplice – possiamo installarlo con uno script a una riga (curl ... | sh) o tramite strumenti come K3sup. Il server si avvia con i componenti predefiniti di default. Aggiungere nodi è semplice (esegui l’agente K3s con un token ottenuto dal server). L’aggiornamento è facile (sostituisci il binario o usa lo script di installazione per la nuova versione). Non è necessario un setup separato per etcd (a meno che non si scelga un setup multi-master HA). K3s è progettato per richiedere un minimo di intervento una volta installato, il che lo rende popolare per IoT e homelab.

  • Supporto per i volumi persistenti: Integrato. Per default, K3s include la classe di storage local-path di Rancher, che provvede dinamicamente i PV sul filesystem dell’host per ogni PVC. Questo significa che qualsiasi PVC verrà soddisfatto creando automaticamente un volume hostPath sul nodo. Si tratta di una soluzione di storage a singolo nodo (ogni volume è su un disco di un singolo nodo), ma funziona senza problemi per le applicazioni stateful. Per un supporto di storage più avanzato, possiamo aggiungere qualcosa come Longhorn di Rancher (storage a blocchi distribuito), che K3s supporta, ma per un homelab la provisioner local-path predefinito è generalmente sufficiente.

  • Supporto per LoadBalancer: Integrato. K3s include un controller leggero chiamato ServiceLB (precedentemente “Klipper LB”) che permette ai servizi di tipo LoadBalancer di ottenere un IP/porta sull’host senza alcun provider esterno. Quando creiamo un servizio LoadBalancer, K3s distribuisce un DaemonSet di piccoli pod LB (svc-...) su ogni nodo, che utilizzano porte host per inoltrare il traffico al servizio. In sostanza, K3s riutilizza l’IP del nodo (interno o esterno) per fungere da IP del LoadBalancer e utilizza le route iptables nei pod LB per inviare il traffico all’IP Cluster del servizio. Questo funziona senza alcuna configurazione – i servizi non rimarranno “in sospeso” (a differenza del Kubernetes vanilla su hardware bare metal). Il compromesso è che l’IP esterno del LoadBalancer sarà uno degli IP dei nostri nodi (o tutti i nodi) e dobbiamo assicurarci che la porta sia libera. Per la maggior parte degli utilizzi dell’homelab (esponendo alcuni servizi su porte HTTP/HTTPS), questo è perfettamente accettabile. Se necessario, possiamo disattivare il LoadBalancer integrato e installare manualmente MetalLB, ma la maggior parte degli utenti preferisce il comodo predefinito.

  • Requisiti di risorse: Molto bassi. K3s può funzionare anche su hardware di bassa gamma. Ufficialmente, 512 MB di RAM e alcune centinaia di MB di disco sono sufficienti per un nodo server. Nella pratica, un piccolo cluster potrebbe utilizzare alcune centinaia di MB di memoria per il piano di controllo. Il suo binario è <100 MB. L’overhead CPU è minimo (K3s utilizza leggermente più CPU quando è inattivo rispetto a MicroK8s, ma non di molto). I nostri nodi (16 GB ciascuno) sono più che sufficienti per eseguire K3s comodamente.

  • Singolo nodo vs multi-nodo: Adatto a entrambi. K3s può funzionare su un singolo nodo (tutti i componenti del piano di controllo e i carichi di lavoro su una singola macchina) o su più nodi. Per un setup a 3 nodi, potremmo eseguire 1 server (master) e 2 agenti, o anche rendere tutti e 3 i server per HA (non necessario qui poiché l’HA non è un obiettivo). L’aggiunta degli agenti è banale con il token. Il database SQLite predefinito di K3s funziona per un singolo server; per un multi-server HA passeremo a etcd integrato (K3s può farlo automaticamente quando si avviano più nodi server).

  • Strumenti CLI e UI: Interagiamo con K3s come con qualsiasi Kubernetes – tramite kubectl. K3s include il proprio build di kubectl (possiamo eseguire k3s kubectl ... o semplicemente utilizzare un kubectl standard puntandolo al kubeconfig di K3s). Non esiste un CLI specifico per K3s oltre ai comandi di installazione; è intenzionalmente minimalista. Non è incluso alcun UI web (il Dashboard upstream non è installato per default). Tuttavia, possiamo installare manualmente il Kubernetes Dashboard o altri strumenti su K3s come qualsiasi cluster standard. Rancher (lo strumento di gestione GUI della stessa azienda) può essere installato sopra K3s se si desidera un’interfaccia completa, ma non fa parte di K3s stesso. In sostanza, K3s fornisce le API core k8s e aggiungiamo gli extra quando necessario (ingress, storage, ecc. – alcuni dei quali sono già inclusi come menzionato).

MicroK8s (Kubernetes low-ops di Canonical)

Funzionalità principali: MicroK8s è la distribuzione leggera di Kubernetes di Canonical, consegnata come pacchetto snap. Installa un cluster Kubernetes pienamente conforme (binari upstream) con un singolo comando e è progettato per l’uso facile (“low ops”) su una singola macchina o su un piccolo cluster. Mette l’accento su un approccio “batterie-incluse” – otteniamo molte funzionalità opzionali che possono essere abilitate con semplici comandi. MicroK8s predefinito adotta un’esperienza Kubernetes vanilla (tutte le API standard) ma con add-on convenienti per esigenze comuni. Supporta sia le installazioni a singolo nodo che quelle a multi-nodo (possiamo formare un cluster “unendo” i nodi), e anche una modalità HA per il piano di controllo (utilizzando Dqlite – un SQLite distribuito – quando abbiamo 3 master).

  • Facilità di installazione e manutenzione: Estremamente facile – basta eseguire snap install microk8s --classic su una macchina Ubuntu per impostare un nodo Kubernetes. È un singolo pacchetto che include tutti i componenti. MicroK8s è mantenuto attraverso il sistema snap di Ubuntu, il che significa che gli aggiornamenti sono atomici e possono essere automatici (possiamo tracciare un canale per le versioni di Kubernetes). Questa capacità di aggiornamento automatico è unica tra queste opzioni – possiamo optare per ricevere patch di sicurezza e aggiornamenti minori tramite snap refresh. La gestione di MicroK8s avviene tramite il comando microk8s, che ha sottocomandi per abilitare/disabilitare le funzionalità. Complessivamente, è molto fluido: non ci sono contenitori o VM da gestire (esegue nativamente sull’host), e non c’è un etcd esterno da configurare (usa un datastore interno). La manutenzione è principalmente aggiornare lo snap quando necessario e utilizzare microk8s.status per monitorare.

  • Supporto per i volumi persistenti: Disponibile tramite add-on. Per default, MicroK8s non provvede automaticamente i PV finché non abilitiamo l’add-on “hostpath-storage”. Abilitandolo (con microk8s enable hostpath-storage) si crea una classe di storage predefinita che alloca volumi da una directory sull’host. Questo è essenzialmente un provisioner dinamico hostPath, simile in concetto a quello di K3s local-path. Una volta abilitato, qualsiasi PVC si lega a un PV hostpath sul nodo MicroK8s. (In un cluster MicroK8s multi-nodo, il PV hostpath risiederà su un singolo nodo – adatto per test o uso in homelab ma non per storage distribuito). MicroK8s offre anche Mayastor e altri add-on di storage se vogliamo un supporto di storage più avanzato su più nodi, ma per semplicità il storage hostpath funziona bene. Nota: L’add-on non è abilitato per default (per mantenere il tutto leggero), quindi vorremo abilitarlo per far funzionare i PVC. Canonical nota che non è adatto per l’uso in produzione HA (poiché non è replicato), ma per un homelab è perfetto.

  • Supporto per LoadBalancer: Disponibile tramite add-on. MicroK8s non include un bilanciatore di carico predefinito, ma fornisce MetalLB come un add-on semplice. Eseguendo microk8s enable metallb:<start-IP>-<end-IP> si installa MetalLB in modalità Layer 2 e ci permette di specificare una piscina di IP dalla rete LAN da utilizzare per i servizi LoadBalancer. Una volta abilitato, qualsiasi servizio di tipo LoadBalancer otterrà automaticamente un IP da quel range (e MicroK8s lo annuncerà tramite ARP sulla LAN). Questo fornisce un’esperienza simile a quella del cloud su hardware bare metal. (Se non abilitiamo MetalLB, un servizio LoadBalancer rimarrà in sospeso, poiché MicroK8s da solo non implementa uno – come Kubernetes upstream.) In un homelab, MetalLB è semplice da configurare e ci permette di accedere ai servizi sulla nostra rete locale. Dovremo scegliere una sottorete o un range di IP libero nella nostra rete per utilizzarlo. Il comando enable di MicroK8s rende l’installazione indolore, ma è comunque un passo separato. (A differenza di K3s, che funziona senza problemi per LB ma con il limite di utilizzare IP/porta dei nodi.) Molti utenti MicroK8s abilitano semplicemente MetalLB come parte della loro configurazione iniziale per un LB funzionante.

  • Requisiti di risorse: MicroK8s è abbastanza leggero, sebbene leggermente superiore a K3s in termini di spazio occupato. Esegue tutti i servizi principali (server API, controller, scheduler, kubelet, etcd o Dqlite) nativamente. L’utilizzo inattivo è tipicamente ~500–600 MB di RAM per il piano di controllo, a seconda di quali add-on sono abilitati. Canonical cita ~540 MB di memoria di base. L’utilizzo della CPU è basso quando inattivo, e i nostri nodi da 16 GB hanno ampio margine. Il requisito di spazio su disco è piccolo (snap ~ 200 MB più dati etcd). In sintesi, MicroK8s può funzionare su hardware modesto (è anche offerto per Raspberry Pi), e nel nostro scenario le macchine lo accolgono facilmente. Se sono abilitati diversi add-on (dashboard, monitoraggio, ecc.), l’utilizzo delle risorse aumenterà di conseguenza.

  • Singolo nodo vs multi-nodo: MicroK8s funziona bene per entrambi. Possiamo utilizzarlo per un cluster a singolo nodo (es. su una macchina di sviluppo o un singolo server) o creare un cluster multi-nodo “unendo” i nodi. La documentazione di MicroK8s fornisce un comando per aggiungere un nodo (recuperiamo un token di unione dal primo nodo e lo utilizziamo sugli altri). In un setup multi-nodo senza HA, un nodo sarà il piano di controllo principale. Con 3 nodi, abbiamo anche l’opzione di abilitare la modalità ha-cluster (rendendo il piano di controllo HA eseguendo Dqlite su 3 nodi), anche se nell’ambito del nostro caso non è necessario. Che si tratti di un singolo nodo o di tre, l’esperienza è la stessa API Kubernetes. Il Multi-nodo MicroK8s è un po’ più recente rispetto all’approccio di K3s, ma è molto stabile ora. È una buona scelta se vogliamo un “micro cloud” di pochi server Ubuntu che eseguono k8s con poco sforzo.

  • Strumenti CLI e UI: MicroK8s include lo strumento microk8s per la riga di comando, molto utile. Ad esempio, microk8s enable <addon> attiva/disattiva diversi servizi (DNS, ingress, storage, metallb, dashboard, ecc.), e microk8s status mostra cosa è in esecuzione. Include anche un kubectl integrato: possiamo utilizzare microk8s kubectl ... (o crearne un alias) che si connette al cluster – è comodo perché non dobbiamo configurare un kubeconfig. Per l’UI, MicroK8s fornisce il Kubernetes Dashboard come add-on (microk8s enable dashboard), che installerà l’interfaccia web standard. Una volta abilitato, possiamo accedervi (esegue sulla porta 10443 o tramite proxy). MicroK8s non ha un’interfaccia grafica personalizzata – si basa su Kubernetes Dashboard o su altri strumenti – ma la facilità di abilitarla è un vantaggio. In sintesi, MicroK8s si concentra su un’esperienza a un comando per compiti comuni e su un filosofia “funziona subito”, nascondendo molta complessità (a scapito di alcuni dettagli interni). Questo lo rende molto adatto per un homelab per chi desidera un cluster Kubernetes senza la configurazione manuale di ogni componente.

Contrasto tra K3s e MicroK8s: Entrambi hanno obiettivi e capacità molto simili – leggeri, facili da usare, capaci di funzionare su multi-nodo. K3s tende a essere un po’ più “fai-da-te” quando si aggiungono funzionalità extra (si basa su Helm charts o manifesti manuali per le cose non incluse), mentre MicroK8s offre add-on integrati tramite il proprio CLI. MicroK8s è anche un Kubernetes più “vanilla” sotto il cofano (componenti upstream, semplicemente imballati come snap), mentre K3s utilizza alcuni binari personalizzati e un singolo servizio per tutto. Entrambi sono buone scelte per un homelab; la decisione spesso dipende dal gusto personale: se preferiamo Ubuntu/snap e un’esperienza integrata, MicroK8s è eccellente, mentre se preferiamo un approccio minimalista con un po’ più di controllo manuale, K3s è ottimo. (Forniremo raccomandazioni alla fine.)

Minikube (Cluster Kubernetes Singolo Nodo)

Funzionalità Principali: Minikube è principalmente uno strumento per eseguire Kubernetes localmente (spesso su un PC o laptop dello sviluppatore) piuttosto che un cluster tradizionale su più macchine. Crea un cluster Kubernetes a singolo nodo in una VM o un container sulla nostra macchina. Minikube è noto per il suo ampio supporto degli ambienti – può funzionare su Linux, macOS, Windows e supporta diversi ipervisor (VirtualBox, KVM, Hyper-V, driver Docker, ecc.). È mantenuto dai Kubernetes SIGs e spesso utilizzato per test e apprendimento. Sebbene Minikube possa essere indirizzato a una configurazione multi-nodo, è essenzialmente destinato a cluster a singolo nodo (la modalità “multi-nodo” di Minikube in realtà avvia più nodi sullo stesso host utilizzando i runtime container – utile per simulare un cluster, ma non per eseguirlo su macchine fisiche separate).

  • Facilità di Installazione e Utilizzo: Minikube è molto facile da iniziare su una singola macchina. Installiamo il binario minikube, assicuriamoci di avere un driver VM (o Docker) e eseguiamo minikube start. Questo creerà un VM/container locale e avvierà Kubernetes al suo interno. È probabilmente il modo più semplice per avviare un cluster Kubernetes per la prima volta. Il CLI (minikube) fornisce comandi per interagire con la VM (avviare, fermare, eliminare) e per abilitare gli add-on. Poiché Minikube è progettato per l’uso locale, non è un “daemon in esecuzione continua” – lo avviamo quando ne abbiamo bisogno e lo fermiamo quando abbiamo finito, anche se possiamo tenerlo in esecuzione continuamente su un server homelab se lo desideriamo. Le manutenzioni/aggiornamenti sono semplici: basta aggiornare la versione di minikube e riavviare il cluster (Minikube può anche aggiornare la versione di Kubernetes che esegue con un flag). Tuttavia, un limite è che Minikube è progettato per un singolo nodo (aggiungere più nodi significa avviare istanze VM aggiuntive sullo stesso host, non unire host fisici reali). Quindi, utilizzare Minikube su tre nodi fisici separati significherebbe essenzialmente eseguire tre cluster a singolo nodo indipendenti, il che probabilmente non è ciò che vogliamo. Minikube eccelle per lo sviluppo e i test su una singola macchina, ma non è destinato a gestire un cluster distribuito su più server fisici.

  • Supporto per Volume Persistenti: Integrato (hostPath). I cluster Minikube includono automaticamente una StorageClass predefinita che utilizza un provisioner hostPath. Di fatto, Minikube esegue un piccolo controller che crea dinamicamente PV hostPath all’interno della VM quando vengono richiesti PVC. Questo significa che possiamo creare PersistentVolumeClaims e saranno soddisfatti utilizzando lo spazio di archiviazione del filesystem della VM Minikube (di solito sotto /tmp/hostpath-provisioner o simili). Questo funziona “out-of-the-box” – non è necessuna configurazione per l’uso base dei PV. Ad esempio, la StorageClass predefinita “standard” in Minikube si mappa su hostPath sull’host. Un’osservazione: se riavviamo o eliminiamo la VM Minikube, quei volumi hostPath potrebbero andare persi (Minikube tenta di persistere alcune directory durante il riavvio – ad esempio, /data, /var/lib/minikube, /tmp/hostpath* vengono conservate). Tuttavia, in generale, per un ambiente non produttivo questo è accettabile. Se vogliamo simulare di più, Minikube ha anche un addon driver CSI hostpath che supporta snapshotting e può funzionare in modalità multi-nodo, ma è più adatto per sperimentare. In sintesi: Minikube supporta i PV di default tramite hostPath, che è sufficiente per un test di applicazioni stateful in un homelab.

  • Supporto per LoadBalancer: Supportato tramite tunneling (o addon MetalLB). In un cloud, un servizio LoadBalancer ottiene un LB cloud con un indirizzo IP esterno. In Minikube, ovviamente non c’è un provider cloud, quindi Minikube fornisce due meccanismi:

    • Minikube Tunnel: Possiamo eseguire minikube tunnel in un processo separato che creerà una route di rete sull’host e assegnerà un IP al nostro servizio LoadBalancer. In sostanza, utilizza il nostro host per agire come “LB esterno”. Quando creiamo un servizio LoadBalancer, Minikube mostrerà un “external IP” (di solito dal sottorretto del cluster) e il processo minikube tunnel indirizzerà quel traffico al servizio. Questo richiede che il processo tunnel rimanga in esecuzione (e tipicamente i permessi root per creare le route). È un passo manuale, ma Minikube stampa un promemoria se abbiamo un servizio LoadBalancer senza un tunnel in esecuzione (“External-IP pending” finché non avviamo il tunnel).
    • Addon MetalLB: Le versioni più recenti di Minikube includono anche un addon MetalLB. Possiamo eseguire minikube addons enable metallb e configurare un range di IP (Minikube ci chiederà). Questo effettivamente distribuisce MetalLB all’interno del cluster Minikube, che gestirà i servizi LoadBalancer come farebbe su qualsiasi Kubernetes bare-metal. Questo è una soluzione più “in-cluster” e non richiede un processo tunnel separato dopo l’installazione iniziale.

    Entrambe le opzioni funzionano, e la scelta dipende da noi. Per esporre rapidamente un servizio, minikube tunnel è veloce e temporaneo. Per una configurazione più permanente, l’addon MetalLB può essere abilitato in modo che gli LB ottengano IP reali (ad esempio, potremmo assegnargli un range come 10.0.0.240-250 su un Minikube con rete bridged). Ricordiamo che Minikube è tipicamente a singolo nodo, quindi in pratica il “load balancer” non bilancia tra più nodi – fornisce solo l’accesso esterno al servizio del singolo nodo. Questo è accettabile per lo sviluppo. In un homelab, se utilizziamo solo uno dei nostri nodi e eseguiamo Minikube su di esso, potremmo utilizzare queste opzioni per accedere alle nostre applicazioni. Ma se vogliamo sfruttare tutti e 3 i nodi, l’approccio di Minikube per LB non è adatto a quel scenario.

  • Requisiti di Risorse: Minikube in sé è leggero, ma poiché di solito esegue un intero cluster Kubernetes a singolo nodo (in una VM), l’utilizzo delle risorse è simile a un normale piccolo cluster. Il minimo consigliato è 2 GB di RAM e 2 CPU per la VM. Di default, Minikube assegna spesso 2 GB di RAM alla sua VM. Nel nostro caso, con 16 GB per macchina, è irrilevante. Minikube inattivo (Kubernetes) potrebbe utilizzare ~600 MB di memoria. Una cosa da considerare è che Minikube verrà eseguito sopra il nostro OS – o come VM tramite un ipervisor o come un container Docker – che aggiunge alcuni overhead. Su un server homelab, potremmo eseguire Minikube con il driver “none” (che installa i componenti Kubernetes direttamente sull’host). Tuttavia, il driver “none” (a.k.a. bare-metal) è essenzialmente simile all’uso di kubeadm su quel nodo, e richiede una pulizia manuale, quindi non è molto popolare. La maggior parte utilizza un driver VM o Docker. In sintesi, qualsiasi uno dei nostri nodi homelab può eseguire facilmente Minikube. L’unico vincolo è che Minikube non utilizzerà le risorse di tutti e 3 i nodi – sarà limitato all’host su cui viene eseguito (a meno di non utilizzare l’esperimentale multi-nodo all’interno di un singolo host).

  • Singolo Nodo vs Multi-Nodo: Principalmente a singolo nodo. Minikube è ideale per un cluster a singolo nodo su una singola macchina. Ha una funzionalità per simulare più nodi (ad esempio, minikube start --nodes 3 con il driver Docker avvierà 3 nodi Kubernetes come container su un singolo host), ma è solo per test. Non possiamo utilizzare Minikube per creare un cluster multi-nodo reale su 3 server fisici separati. Se abbiamo 3 macchine, dovremmo eseguire 3 istanze indipendenti di Minikube (non in un singolo cluster). Questo non è un’esperienza di cluster reale (non saranno a conoscenza l’uno dell’altro). Pertanto, Minikube è non consigliato se il nostro obiettivo è sfruttare tutti e 3 i nodi in un singolo cluster Kubernetes – è meglio per scenari in cui abbiamo solo una macchina (il nostro PC o un singolo server) e vogliamo eseguire K8s su di essa. È anche fantastico per imparare le basi di Kubernetes e per lo sviluppo locale.

  • Strumenti CLI e UI: L’minikube CLI è l’interfaccia principale. Lo utilizziamo per avviare/fermare il cluster, e ha scorciatoie utili: ad esempio, minikube dashboard abilita il Kubernetes Dashboard e lo apre nel nostro browser. minikube addons enable <addon> può abilitare una varietà di componenti opzionali (ingress, metallb, metrics-server, ecc.). Minikube configura automaticamente l’accesso a kubectl (configura un contesto “minikube” nel nostro kubeconfig). Per l’UI, come menzionato, il Kubernetes Dashboard è facilmente accessibile tramite il comando dashboard. Minikube non ha il suo proprio UI web unico; si basa su strumenti standard. Il debug di Minikube è anche semplice poiché possiamo eseguire minikube ssh per entrare nel VM del nodo se necessario. Complessivamente, gli strumenti sono molto user-friendly per uno scenario a singolo nodo.

Kubeadm (Kubernetes Vanilla sui Nostri Nodi)

Funzionalità Principali: Kubeadm non è una “distribuzione” ma piuttosto lo strumento ufficiale per creare un cluster Kubernetes da zero. Utilizzare kubeadm significa che stiamo distribuendo componenti standard di Kubernetes upstream sulle nostre macchine. È essenzialmente il modo in cui “creiamo il nostro cluster”, seguendo le best practice ma senza gli extra che le distribuzioni includono. Kubeadm installerà un nodo di controllo (che esegue etcd, API server, controller manager, scheduler) e unirà i nodi worker a esso. Il risultato è un cluster Kubernetes completamente standard identico a quello che otterremmo su VM cloud. Questo approccio ci dà il pieno controllo e flessibilità – scegliamo il plugin di rete, il provisioner di archiviazione, ecc. – ma richiede anche il lavoro manuale iniziale maggiore e la conoscenza. È spesso utilizzato in ambienti di produzione o di apprendimento per comprendere gli interni di Kubernetes.

  • Facilità di Installazione e Manutenzione: Rispetto agli altri, kubeadm è il più coinvolgente. Dobbiamo installare manualmente le dipendenze (runtime container come containerd, kubeadm, kubelet, kubectl) su ogni nodo. Poi eseguiamo kubeadm init sul master e kubeadm join sui worker con il token che ci dà. Dobbiamo anche configurare un CNI (plugin di rete) dopo l’inizializzazione (Calico, Flannel, ecc.) poiché kubeadm non installa uno di default. Ci sono passaggi ben documentati per tutto questo (il processo non è difficile, ma è composto da molti passaggi) – in sostanza, kubeadm ci dà un cluster iniziale ma ci aspetta che gestiamo gli add-on. Per la manutenzione, siamo responsabili degli aggiornamenti (kubeadm ha un comando di aggiornamento, ma dobbiamo drenare i nodi, aggiornare i binari, ecc. manualmente), nonché del monitoraggio della salute di etcd, rinnovi dei certificati, ecc. In breve, kubeadm è potente ma manuale. È spesso chiamato “the hard way” (anche se non è così difficile come costruire da zero). Per un appassionato di homelab che ama imparare, kubeadm è un ottimo modo per comprendere profondamente Kubernetes. Ma se la nostra priorità è “facile e poco manutenzione”, kubeadm richiederà più lavoro rispetto a K3s/MicroK8s. Ogni aggiornamento o modifica richiederà un impegno manuale. Detto questo, una volta configurato, è la soluzione reale: un cluster Kubernetes standard senza astrazioni nascoste.

  • Supporto per Volume Persistenti: Nessuno di default (deve essere aggiunto manualmente). Un cluster installato con kubeadm è essenzialmente un Kubernetes vuoto – non include una StorageClass predefinita o un provisioner dinamico di default. Negli ambienti cloud, il provider cloud fornirebbe normalmente una StorageClass predefinita (ad esempio, AWS EBS, ecc.), ma in un ambiente homelab bare-metal, dovremo installare la nostra soluzione. Approcci comuni:

    • Provisioner hostPath: Possiamo replicare ciò che K3s/Minikube fanno installando qualcosa come il Rancher Local Path Provisioner (che è un piccolo controller + StorageClass che crea PV hostPath). Questo è un add-on semplice (solo un manifesto YAML) e ci dà un archiviazione dinamica locale.
    • NFS o NAS: Alcuni utenti homelab configurano un server NFS (o utilizzano un NAS) e poi usano PV statici o un driver NFS CSI per la provisioning.
    • OpenEBS/Longhorn/Ceph: Ci sono opzioni più complesse come l’installazione di Longhorn o Ceph RBD tramite Rook se vogliamo un’archiviazione distribuita tra i nodi. Queste richiedono più risorse e complessità.

    Il punto chiave è che kubeadm non “risolve” l’archiviazione per noi – dobbiamo decidere e configurare noi stessi. Se la facilità è la priorità, il percorso più semplice è installare un provisioner hostPath o utilizzare NFS. Ad esempio, il provisioner local-path di Rancher può essere installato in pochi comandi kubectl apply e imiterà il comportamento di K3s (creando volumi sotto /var/lib/rancher/ su qualsiasi nodo). Ma è un passo manuale. Finché non lo facciamo, qualsiasi PVC che creiamo rimarrà in stato “Pending” perché Kubernetes non ha una provisioning predefinita. Quindi, sebbene kubeadm certamente supporti i Persistent Volumes (è un Kubernetes completo), il supporto per PV dinamici è buono quanto lo sforzo che mettiamo per configurarlo.

  • Supporto per LoadBalancer: Nessuno di default (deve essere aggiunto manualmente). Storia simile: in un cluster on-prem tradizionale, non abbiamo un’implementazione LoadBalancer predefinita. Se creiamo un servizio di tipo LoadBalancer su un cluster kubeadm puro, rimarrà in stato pending per sempre finché non installiamo un controller per gestirlo. La soluzione comune è installare MetalLB noi stessi. MetalLB può essere installato tramite manifesto o chart Helm – configureremo un range di IP e allocerà quegli IP per i servizi LoadBalancer (esattamente come in MicroK8s). Esistono molti guide per installare MetalLB su cluster kubeadm. Un’altra alternativa che alcuni utilizzano è kube-vip per il VIP del piano di controllo e i servizi LB, ma MetalLB è più semplice per i servizi. In sostanza, con kubeadm abbiamo la libertà (o il fardello) di configurare qualsiasi meccanismo di bilanciamento del carico che si adatta alle nostre esigenze. Se non lo configuriamo, siamo limitati ai servizi NodePort per l’accesso esterno. Per un homelab, l’installazione di MetalLB è altamente consigliata – è semplice e ci dà la funzionalità di IP di servizio simile al cloud. Ma di nuovo, è un passo aggiuntivo che dobbiamo eseguire (a differenza di K3s che funziona out-of-box o MicroK8s con un semplice abilitare).

  • Requisiti di Risorse: Kubernetes standard è un po’ più pesante rispetto alle versioni tagliate. Ogni nodo eseguirà un kubelet e un kube-proxy, e il master eseguirà etcd e componenti del piano di controllo. Un singolo nodo del piano di controllo può ancora funzionare con 2 GB di RAM, ma tipicamente vorremmo un po’ di più per il comfort se eseguiamo pod su di esso. La guida padok suggerisce 2 GB per il master, 2 GB per il worker minimo. Nel nostro scenario (16 GB per nodo), è perfetto. Etcd e API server inattivi potrebbero utilizzare alcuni centinaia di MB di memoria ciascuno. Non c’è una grande differenza in esecuzione tra un cluster kubeadm e MicroK8s – dopotutto, MicroK8s è quegli stessi componenti. La differenza è solo ciò che viene eseguito di default (MicroK8s potrebbe abilitare DNS e archiviazione di default, mentre su kubeadm installeremo quegli elementi). Quindi, in termini di risorse, kubeadm può essere altrettanto leggero o pesante quanto lo configuriamo. Con niente installato in extra, potrebbe essere abbastanza leggero. Con una configurazione tipica (ad esempio, aggiungiamo CoreDNS, Dashboard, ecc.), aspettiamoci ~1 GB o così utilizzati per l’overhead del sistema. Abbiamo più che abbastanza RAM, quindi le risorse non sono un problema. È più una questione del tempo e delle risorse umane necessarie per gestirlo, piuttosto che CPU/RAM.

  • Singolo Nodo vs Multi-Nodo: Kubeadm può fare entrambi, con piena flessibilità. Possiamo inizializzare un cluster a singolo nodo (e anche dire a kubeadm di permettere al singolo nodo di eseguire carichi di lavoro disabilitando l’untaint del master). Oppure possiamo avere un master e unire due worker (una configurazione comune a 3 nodi). Potremmo anche configurare 3 master e 3 worker, ecc. – qualsiasi topologia. Nel nostro caso, una configurazione kubeadm probabile sarebbe 1 nodo di controllo e 2 worker (poiché non è necessario HA, non abbiamo bisogno di più master). Questo ci dà un cluster funzionale a 3 nodi. Il processo per il multi-nodo è ben documentato: essenzialmente, installiamo Kubernetes su tutti, inizializziamo uno, uniamo gli altri. Il risultato è identico a quanto darebbe un cluster gestito o un’altra distribuzione: i nostri 3 nodi appaiono in kubectl get nodes, ecc. Quindi, kubeadm soddisfa certamente il requisito di “utilizzare tutti e 3 i nodi”.

  • Strumenti CLI e UI: Con kubeadm, l’unico CLI speciale è kubeadm stesso, utilizzato per l’installazione e (in seguito) per i passaggi di aggiornamento. Per le attività quotidiane, utilizziamo kubectl per gestire il cluster. Non c’è alcun CLI di gestione integrato oltre a ciò che Kubernetes fornisce. Per l’UI, non è incluso nulla di default – possiamo installare manualmente il Kubernetes Dashboard o qualsiasi altro strumento (esattamente come in qualsiasi cluster). In sostanza, kubeadm ci dà un canvas Kubernetes vuoto. È a noi di dipingere su di esso – che include l’installazione di convenienze come dashboard, controller ingress, classi di archiviazione, ecc. Molti dashboard terze parti (Lens, Octant, ecc.) possono anche connettersi a un cluster kubeadm se vogliamo un’esperienza di gestione GUI, ma sono strumenti esterni. In sintesi, con kubeadm otteniamo un ambiente Kubernetes puro – massima flessibilità, ma anche la necessità di configurare tutto come se fosse un cluster di produzione.

  • Kubespray Vedere anche come installare questa versione di Kubernetes con Kubespray.

Tabella di confronto a fianco a fianco

Di seguito è riportato un riassunto che confronta le quattro opzioni su punti chiave:

Aspetto K3s (K8s leggero di Rancher) MicroK8s (K8s “Low-Ops” di Canonical) Minikube (K8s per sviluppo singolo nodo) Kubeadm (Kubernetes vanilla)
Installazione Script di installazione in una riga (singolo binario). Funziona come un singolo servizio del sistema. Configurazione molto rapida. Installazione in un comando tramite snap su Ubuntu. Tutti i componenti inclusi. Facile clustering con microk8s join. Installare il CLI di minikube, quindi eseguire minikube start per lanciare un VM/container locale. Cross-platform e amichevole per i principianti. Installazione manuale di kubeadm, kubelet, ecc. su ogni nodo. Eseguire kubeadm init + kubeadm join con prerequisiti. Involge diversi passaggi (runtime, plugin di rete, ecc.).
Manutenzione e aggiornamenti Aggiornamenti manuali (sostituire il binario o utilizzare lo script di installazione per la nuova versione). Semplice, poiché è un singolo binario; poco da gestire. Nessun aggiornamento automatico. Aggiornamenti tramite snap refresh (può essere automatico). Add-on e servizi del cluster gestiti tramite CLI microk8s. In generale low-ops; disponibili aggiornamenti automatici. Facile eliminare/ricreare il cluster per lo sviluppo. Aggiornamenti aggiornando la versione di minikube e riavviando il cluster. Destinato all’uso effimero (meno attenzione alla longevità degli aggiornamenti in-place). L’utente è responsabile di tutti gli aggiornamenti. Utilizzare kubeadm upgrade ma è necessario svuotare i nodi, gestire il backup di etcd, ecc. Controllo completo, ma l’utente deve eseguire il lavoro (nessun aggiornamento automatico).
Versione K8s Segue l’upstream abbastanza da vicino (spesso utilizzato in rilasci edge). Conformante CNCF. Alcune funzionalità disattivate per default (alpha/legacy). Segue le release upstream (canali snap per 1.27, 1.28, ecc.). Conformante CNCF. Sostanzialmente binari K8s vanilla. Possiamo scegliere la versione di Kubernetes all’avvio (es. minikube start --kubernetes-version=v1.27). Predefinito alla versione stabile più recente. Qualsiasi versione vogliamo (installare versioni specifiche di kubeadm/kubelet). Kubernetes upstream completo – decidiamo la versione e quando aggiornare.
Funzionalità predefinite Funzionalità predefinite incluse: Flannel CNI, CoreDNS, Traefik ingress, service LB, classe di archiviazione locale, metrics-server, ecc. (Tutte possono essere disattivate se non necessarie). Minimal config needed to be functional. Funzionalità predefinite minimali: DNS è di solito attivo, gli altri opzionali. Add-on facilmente accessibili tramite comando per ingress (NGINX), MetalLB, hostpath storage, dashboard, ecc.. È possibile abilitare la modalità HA su 3+ nodi. Funzionalità incluse nel VM: tipicamente include Docker/containerd runtime, Kubernetes con add-on predefiniti come StorageProvisioner e DNS. Add-on opzionali (ingress, dashboard, ecc.) attivabili tramite CLI. Nessun multi-nodo per default. Solo i componenti base: Niente oltre Kubernetes core. Nessun ingress, nessuna classe di archiviazione o LB predefinita, nessun dashboard fino a quando non li installiamo. Scegliamo il plugin CNI (dobbiamo installare uno per la rete). Essenzialmente un cluster DIY.
Supporto per Volume persistente Sì – predefinito. Incluso il local-path dinamico di Rancher, che crea PV hostPath sul nodo per qualsiasi PVC. Classe di archiviazione predefinita “local-path” utilizza automaticamente il disco locale. Sì – add-on semplice. Abilitare hostpath-storage per ottenere una classe di archiviazione predefinita per PV dinamici utilizzando hostPath. Finché non abilitato, non c’è nessun provisioner predefinito di PV. L’add-on non è adatto per produzione multi-nodo, ma va bene per un homelab. Sì – predefinito. La classe di archiviazione predefinita utilizza il provisioner hostPath all’interno del VM di minikube. I PVC vengono soddisfatti da un semplice controller che crea un PV hostPath sul filesystem del nodo. I dati persistono dopo il riavvio su certe directory. No (manuale). Nessun provisioner predefinito – il cluster non avrà alcuna classe di archiviazione inizialmente. L’utente deve installare una soluzione di archiviazione (es. local path provisioner, NFS, Ceph, ecc.). Approccio base: applicare un YAML per un provisioner hostPath per imitare ciò che K3s/Minikube fanno. Finché non lo si fa, i PVC rimangono in sospeso.
Supporto LoadBalancer Sì – ServiceLB integrato. Il controller servicelb di K3s (Klipper) monitora i servizi LoadBalancer e distribuisce i pod sui nodi per esporli. Utilizza l’IP del nodo e le porte host per inoltrare il traffico. Funziona senza configurazione. Adatto per piccoli cluster; utilizza l’IP interno/esterno del nodo per il servizio. Sì – tramite add-on MetalLB. Abilitare metallb con un intervallo di IP per allocare. Fornisce un vero bilanciatore di carico Layer-2 su hardware. Non abilitato per default. Una volta abilitato, ogni servizio LoadBalancer ottiene un IP unico dal nostro pool. Richiede una piccola configurazione iniziale (intervallo di IP). Sì – tramite tunnel o MetalLB. Nessun LoadBalancer cloud, ma possiamo eseguire minikube tunnel per assegnare un IP esterno ai servizi LoadBalancer (crea una route sull’host). Alternativamente, abilitare l’add-on MetalLB in minikube per IP automatici di bilanciamento. Per default, i servizi LoadBalancer mostreranno “pending” finché non utilizziamo uno di questi metodi. No (manuale). Nessun bilanciatore integrato. Di solito installare MetalLB manualmente per la funzionalità di bilanciamento su hardware. Una volta installato MetalLB (o un altro controller di bilanciamento), i servizi LoadBalancer funzionano. Senza di esso, i servizi LoadBalancer rimangono in sospeso all’infinito.
Rete (CNI) Predefinito = Flannel (rete overlay). K3s supporta anche il sostituzione del CNI se necessario. Viene distribuito CoreDNS per il DNS del cluster. Traefik ingress incluso per default (può essere disattivato). Predefinito = Calico (per le versioni recenti in modalità HA) o un default semplice. (MicroK8s ha utilizzato storicamente flannel; ora tende a usare Calico per la confinamento rigoroso). CoreDNS abilitato per default. NGINX ingress disponibile tramite add-on (microk8s enable ingress). Predefinito = kubenet/bridge (dipende dal driver; spesso usa una rete NAT semplice). CoreDNS funziona per default. Possiamo abilitare un add-on NGINX ingress se necessario. La rete è confinata al singolo VM; NodePort è accessibile tramite minikube ip. Scelta del CNI. Kubeadm non installa alcun plugin CNI – dobbiamo distribuirne uno (Calico, Flannel, Weave, ecc.). Abbiamo il pieno controllo. La maggior parte delle guide prevedono che applichiamo il YAML di Calico dopo kubeadm init. CoreDNS è installato da kubeadm per default come DNS del cluster. Controller di ingress – scegliamo e installiamo noi stessi (es. NGINX o Traefik tramite manifest/Helm).
Clustering multi-nodo Sì. Progettato per multi-nodo. Facile join con token. È possibile utilizzare un database esterno o etcd incorporato per multi-master. Ottimo per homelab da 2-3+ nodi. Nessuna dipendenza extra necessaria – K3s ha il proprio clustering integrato. Sì. Supporta il clustering di più nodi MicroK8s (con microk8s join). È possibile abilitare HA con 3+ master (Dqlite). Molto semplice formare un cluster, specialmente se tutti i nodi eseguono Ubuntu + snap. No (fisico). Singolo-nodo per design. È possibile simulare un multi-nodo su una singola macchina (più nodi in contenitori Docker), ma non è possibile estendere un cluster a più host fisici. Utilizzare istanze separate di Minikube per cluster separati. Sì. Supporta pienamente multi-nodo (è l’obiettivo). Possiamo avere 1 master + molti worker, o anche più master (sebbene la configurazione HA di kubeadm sia più complessa). Nessun limite predefinito sulla dimensione del cluster.
Overhead risorse Molto basso. Control plane ~<0.5 GB memoria inattiva. Un singolo processo per il control plane genera un footprint piccolo. Efficiente sul CPU (sebbene possa utilizzare leggermente più CPU inattiva di MicroK8s per alcuni rapporti). Ideale per dispositivi a basso consumo o con molta capacità disponibile. Basso. ~0.5–0.6 GB memoria per control plane inattiva. Slightly higher base memory than K3s, but stays stable. Uses Ubuntu snap (might have some overhead). Still lightweight relative to full Kubernetes. Moderato. VM default 2 GB alloc (uso ~0.6 GB inattivo). Esegue un singolo nodo Kubernetes completo, più il livello VM. Non è un problema su sistemi con 16 GB, ma sostanzialmente consuma le risorse di un piccolo cluster su una singola macchina. Moderato. Un singolo master con un worker potrebbe utilizzare ~1 GB inattivo dopo aver aggiunto add-on tipici. Ogni nodo aggiuntivo aggiunge un overhead minimo (solo kubelet, proxy). Simile all’esecuzione di Kubernetes in VM cloud di dimensioni simili. Su 3 nodi con 16 GB ciascuno, l’overhead è trascurabile in contesto.
Strumenti CLI Utilizzare k3s per l’installazione e come wrapper per kubectl (o utilizzare il kubectl standard). Nessun CLI di gestione separato (K3s è principalmente “set and forget”). Alcuni script helper (es. k3s-killall.sh). È possibile aggiungere l’interfaccia grafica di Rancher se desiderato. CLI ricco di microk8s: es. microk8s enable/disable <addon>, microk8s status. Include anche microk8s kubectl. Progettato per semplificare compiti comuni (non necessario modificare direttamente i manifest del sistema per le basi). CLI di minikube per avviare/fermare il cluster, gestire la configurazione e gli add-on, e ottenere informazioni (IP, URL del servizio, log). Fornisce anche comandi di convenienza come minikube dashboard. Interagire con il cluster tramite kubectl (configurazione automatica per il contesto di minikube). Solo kubeadm per l’installazione iniziale e gli aggiornamenti. Operazioni quotidiane tramite kubectl standard e altri strumenti Kubernetes. Nessun CLI specifico del distro oltre al bootstrap. Lavorerai con comandi Kubernetes raw e forse strumenti OS per la manutenzione.
UI / Dashboard Non incluso per default. È possibile installare manualmente il Dashboard Kubernetes o utilizzare strumenti esterni (niente di specifico per Rancher a meno che non si aggiunga Rancher separatamente). K3s si concentra sull’operazione headless. Non incluso per default, ma disponibile tramite un comando: microk8s enable dashboard distribuisce l’UI standard del Dashboard. Facile accesso al cluster tramite microk8s dashboard-proxy. Si integra bene con l’interfaccia grafica Lens di Canonical se desiderato (Lens può accedere direttamente a MicroK8s). Non abilitato per default, ma il comando minikube dashboard deployerà e aprirà l’UI web del Dashboard per noi. È destinato alla comodità nello sviluppo locale – un comando e avremo un’interfaccia grafica per visualizzare i carichi di lavoro. Non incluso. Potremmo installare il Dashboard (applicare YAML) se lo vogliamo. Altrimenti, utilizzare CLI o applicazioni di dashboard terze. In un homelab, si potrebbe installare il dashboard e creare un NodePort o utilizzare kubectl proxy per visualizzarlo. Kubeadm non si preoccupa delle UI.

Fonti: I dati sopra riportati sono sintetizzati da documenti ufficiali e guide utente: ad esempio, i footprint di memoria da confronti MicroK8s, l’archiviazione predefinita in K3s docs, il comportamento del servizio LB di K3s da documentazione K3s, i dettagli degli add-on di MicroK8s da documenti Canonical, i PV e tunnel di Minikube da documenti Kubernetes, e report generali di esperienza. (Vedere Riferimenti per le citazioni complete.)

Consigli

Considerando le priorità (facilità di installazione/mantenimento e supporto integrato per lo storage e i load balancer) e lo scenario (3 nodi Ubuntu, non preoccupati per l’HA):

  • Opzioni principali: K3s o MicroK8s sono le più adatte per un homelab con 3 nodi:

    • Entrambi sono estremamente facili da installare (un singolo comando su ciascun nodo) e richiedono un minimo di manutenzione continua. Sono in grado di astrarre gran parte della complessità di gestione di un cluster.
    • Entrambi supportano il clustering multi-nodo “out of the box” (possiamo unire i nostri 3 nodi e vedere un cluster unificato).
    • Ognuno di loro fornisce una soluzione per Persistent Volumes e LoadBalancers senza molto sforzo: K3s li include per default (storage Local Path, Klipper LB) e MicroK8s li rende disponibili tramite semplici comandi enable. Questo significa che possiamo distribuire applicazioni tipiche (database con PVC, servizi con type=LoadBalancer) con un minimo di configurazione manuale.
    • K3s potrebbe essere preferibile se vogliamo il footprint assolutamente più piccolo e non abbiamo problemi a utilizzare le sue impostazioni predefinite (ingress Traefik, ecc.). È un approccio “set up e funziona”, con impostazioni predefinite orientate. È molto popolare nella comunità degli homelab per la sua semplicità. Utilizzeremo principalmente kubectl standard, e possiamo modificare o disattivare i componenti inclusi se necessario. K3s potrebbe essere preferibile se non siamo su Ubuntu o se apprezziamo l’ecosistema di Rancher (o intendiamo utilizzare l’interfaccia di gestione di Rancher in futuro).
    • MicroK8s potrebbe essere preferibile se preferiamo una soluzione supportata da Ubuntu e apprezziamo l’idea di abilitare le funzionalità con un singolo comando. È essenzialmente Kubernetes “puro” sotto il cofano, che alcuni trovano più facile da estendere. Gli add-on (come microk8s enable ingress dns storage metallb) possono darci un “micro cloud” funzionante in pochi minuti. MicroK8s gestisce anche gli aggiornamenti in modo fluido tramite snaps, il che può essere utile per mantenere il cluster aggiornato senza intervento manuale (possiamo disattivarlo o controllare il canale per evitare sorprese). Se stiamo già utilizzando Ubuntu su tutti i nodi (che è il caso) e non abbiamo problemi a utilizzare i snaps, MicroK8s è un’ottima scelta per un cluster a bassa manutenzione.

    In breve: Non si può andare male con K3s o MicroK8s in questo scenario. Entrambi ci daranno un Kubernetes facile da gestire, adatto agli homelab, con le funzionalità necessarie. Molti utenti segnalano esperienze positive con entrambi in configurazioni domestiche con 2-3 nodi. MicroK8s potrebbe avere un vantaggio leggero in termini di facilità d’uso (grazie agli add-on e all’integrazione), mentre K3s potrebbe avere un vantaggio leggero per il funzionamento efficiente e la semplicità strutturale.

  • Quando scegliere Minikube: Se stessimo eseguendo solo su una singola macchina o volessimo un cluster di sviluppo temporaneo, Minikube è fantastico per questo scopo. È il modo più semplice per avviare Kubernetes su un laptop o un singolo nodo per i test. Tuttavia, per un cluster permanente con 3 nodi, Minikube non è lo strumento giusto – non unirà quei 3 nodi in un unico cluster. Finiremmo per sottoutilizzare il nostro hardware o gestire 3 cluster separati, che non è desiderabile. Quindi, in questo homelab con più nodi, Minikube non è raccomandato come soluzione principale. Potremmo comunque utilizzare Minikube sul nostro computer personale per provare cose prima di distribuirle sul cluster dell’homelab, ma per il cluster stesso, utilizzare qualcosa come K3s/MicroK8s.

  • Quando scegliere Kubeadm: Se il nostro obiettivo fosse imparare l’interno di Kubernetes o avere il controllo completo e una configurazione “simile a produzione”, kubeadm è un buon esercizio. Ci costringerà a comprendere come installare il CNI, lo storage, ecc., e costruiremo sostanzialmente il cluster pezzo per pezzo. Per quanto riguarda l’usabilità, tuttavia, kubeadm è il più manuale. Ogni funzionalità di cui abbiamo bisogno (come lo storage o il LB) dobbiamo configurarla. Per un homelab orientato all’apprendimento, questo potrebbe essere un punto a favore (educativo); per un homelab che funziona subito, è un punto a svantaggio. Inoltre, il mantenimento sarà più impegnativo (soprattutto durante gli aggiornamenti). A meno che non vogliamo specificamente l’esperienza Kubernetes “pura” per l’apprendimento o esigenze personalizzate specifiche, utilizzare K3s o MicroK8s ci risparmierà molto tempo e problemi in un ambiente di homelab. Detto questo, alcuni utenti esperti preferiscono kubeadm anche a casa per evitare qualsiasi peculiarità specifica del fornitore e avere tutto sotto controllo. Dipende davvero da quanto sforzo vogliamo spendere. Per la maggior parte, kubeadm è un’overkill per un piccolo cluster dove non è un problema l’alta disponibilità.

  • Altre opzioni: Esistono altre versioni leggere di Kubernetes, come k0s (di Mirantis) e strumenti come kind (Kubernetes in Docker). Per completezza:

    • k0s è un’altra distribuzione Kubernetes a singolo binario, con obiettivi simili a K3s/MicroK8s, che si concentra su flessibilità e footprint minimo. È relativamente nuovo ma ha fan nella comunità degli homelab. Può anche funzionare facilmente sui nostri 3 nodi. Non ha (al momento) la stessa grande base utenti di K3s/MicroK8s, ma è un’opzione da tenere d’occhio (soprattutto se si apprezza l’idea di un Kubernetes open source, configurabile e minimo – alcune segnalazioni mostrano anche che k0s utilizza leggermente meno risorse inutilizzate rispetto a K3s/MicroK8s in configurazioni simili).
    • kind è principalmente per testare cluster Kubernetes in contenitori Docker (spesso utilizzato in pipeline CI). Non è qualcosa che eseguiremmo come cluster sempre attivo per l’homelab – è più adatto a cluster temporanei su una singola macchina (simile allo scopo di Minikube).
    • Rancher Kubernetes Engine (RKE) o K3d o altri sono disponibili, ma sono orientati verso cluster containerizzati (k3d esegue un cluster K3s in Docker) o scenari di distribuzione più complessi. In un homelab, K3s e MicroK8s hanno quasi diventato le soluzioni facili di default.

Conclusione: Per un homelab con 3 nodi decenti, MicroK8s o K3s sono le scelte consigliate per ottenere un cluster Kubernetes funzionante con il minimo sforzo. Ci permetteranno di sfruttare tutti i nostri nodi in un unico cluster e forniranno supporto integrato per i persistent volumes e i servizi LoadBalancer, che è esattamente ciò che abbiamo richiesto. Se preferiamo una soluzione più plug-and-play integrata con Ubuntu, scegliamo MicroK8s. Se preferiamo una soluzione estremamente leggera, provata e supportata da Rancher, scegliamo K3s. Avremo un cluster funzionante in pochi minuti in entrambi i casi. Una volta avviato, possiamo distribuire il Kubernetes Dashboard o altri strumenti per gestirlo e iniziare a ospitare le nostre applicazioni con archiviazione persistente e esposizione semplice dei servizi. Godiamoci il nostro viaggio con Kubernetes nell’homelab!

Homepage delle distribuzioni Kubernetes