Porównanie dystrybucji Kubernetes dla homelaba z 3 węzłami
Wybór najlepszego wariantu Kubernetes dla naszej domowej laboratorium
Porównuję wersje samowystarczalnego Kubernetesa, które nadają się do homelaba opartego na Ubuntu z 3 węzłami (16 GB RAM, 4 rdzenie CPU każdy), skupiając się na łatwości instalacji i konserwacji, obsłudze persistent volumes i LoadBalancers.
Scenariusz: Mamy trzy węzły Ubuntu (16 GB RAM, 4 rdzenie CPU każdy) w homelabie. Wysoka dostępność (HA) i obsługa ARM nie są priorytetem. Chcemy łatwe do zainstalowania, niskokonserwacyjne Kubernetes klastry (jednowęzłowe lub trzynawłowe) z obsługą Persistent Volumes (PV) i LoadBalancer (LB) (aby aplikacje oparte na chmurze wymagające przechowywania danych lub zewnętrznych adresów IP działały płynnie). Skupimy się na opcjach klastra trzynawłowego bez wymagań HA ani kompatybilności z procesorami ARM.
Poniżej porównujemy popularne lekkie [Kubernetes(https://www.glukhov.org/pl/post/2024/10/kubernetes-cheatsheet/ “lista i opis najczęściej używanych i przydatnych poleceń k8s - cheat sheet k8s”) dystrybucje – K3s, MicroK8s, Minikube, i kubeadm (oryginalny Kubernetes) – i jak one radzą sobie na kluczowych kryteriach (funkcje, instalacja/konserwacja, obsługa PV/LB, wymagania zasobowe, konfiguracja klastra, narzędzia). Podajemy również pewne rekomendacje, które wybrać w zależności od scenariusza homelaba.
K3s (Lekki Kubernetes od Ranchera)
Główne funkcje: K3s to certyfikowana przez CNCF dystrybucja Kubernetesa zaprojektowana do minimalnego zużycia zasobów (może działać nawet na 512 MB RAM). Pakuje całą kontrolną płaszczyznę Kubernetesa w pojedynczy binarny plik i proces, korzystając z lekkich komponentów (np. SQLite jako domyślny magazyn danych zamiast etcd, flannel do sieci). Wbudowane są sensowne domyślne, takie jak wbudowany kontroler ingress (Traefik) i prosty moduł balansowania obciążenia. K3s usuwa funkcje legacy/alpha, aby zmniejszyć nadmiar.
-
Łatwość instalacji i konserwacji: Bardzo prosta – możemy zainstalować ją za pomocą jednoliniowego skryptu (
curl ... | sh
) lub za pomocą narzędzi takich jak K3sup. Serwer uruchamia się z domyślnymi komponentami z domyślnych ustawień. Dodawanie węzłów jest proste (uruchom agenta K3s z tokenem z serwera). Aktualizacja jest łatwa (zastąp binarny plik lub użyj skryptu instalacyjnego do nowej wersji). Nie wymaga osobnego konfiguracji etcd (chyba że wybierzemy konfigurację wielu serwerów HA). K3s jest zaprojektowany tak, aby wymagać minimalnego interwencji po zainstalowaniu, co czyni go popularnym w IoT i homelabach. -
Obsługa Persistent Volumes: Wbudowana. Domyślnie K3s dostarcza local-path StorageClass od Ranchera, który dynamicznie przydziela PV na systemie plików hosta dla każdego PVC. To oznacza, że każdy PVC zostanie automatycznie wypełniony przez utworzenie hostPath volume na węźle. Jest to rozwiązanie jednowęzłowe (każdy wolumin znajduje się na jednym dysku węzła), ale działa natychmiastowo dla aplikacji stanowych. Dla zaawansowanej obsługi magazynu można dodać coś takiego jak Longhorn od Ranchera (rozdzielony magazyn bloków), który K3s obsługuje, ale dla homelaba domyślny local-path wystarcza zwykle.
-
Obsługa LoadBalancer: Wbudowana. K3s zawiera lekkiego kontrolera o nazwie ServiceLB (dawniej “Klipper LB”), który pozwala usługom typu
LoadBalancer
uzyskać IP/port na hoście bez żadnego zewnętrznego dostawcy chmurowego. Gdy tworzymy usługę LoadBalancer, K3s wdraża DaemonSet małych modułów LB (svc-...
) na każdym węźle, które używają portów hosta do przekazywania ruchu do usługi. W zasadzie, K3s ponownie używa IP węzła (wewnętrzne lub zewnętrzne) jako IP LB i używa routingu iptables w modułach LB do przekazywania ruchu do ClusterIP usługi. To działa bez konfiguracji – usługi nie będą “oczekiwać” (w przeciwieństwie do oryginalnego K8s na sprzęcie naziemnym). Wymiana to, że zewnętrzny IP LB będzie jednym z naszych IP węzłów (lub wszystkich węzłów) i musimy upewnić się, że port jest wolny. Dla większości użycia w homelabie (eksponowanie kilku usług na portach HTTP/HTTPS), to jest doskonale. Jeśli potrzebujemy, możemy wyłączyć wbudowany LB i ręcznie zainstalować MetalLB, ale większość użytkowników korzysta z wygodnego domyślnego ustawienia. -
Wymagania dotyczące zasobów: Bardzo niskie. K3s może działać nawet na niskopoziomowym sprzęcie. Oficjalnie, 512 MB RAM i kilka setek MB dysku są wystarczające dla węzła serwera. W praktyce, mały klaster może zużywać kilka setek MB pamięci na płaszczyznę kontroli. Jego binarny plik jest mniejszy niż 100 MB. Nadmiar CPU jest minimalny (K3s zużywa nieco więcej CPU w stanie bezczynności niż MicroK8s, ale nie znacznie). Nasze węzły (16 GB każdy) są bardziej niż wystarczające, aby wygodnie uruchomić K3s.
-
Jednowęzłowy vs. wielowęzłowy: Nadaje się do obu. K3s może działać jednowęzłowo (wszystkie komponenty płaszczyzny kontroli i obciążenia na jednym komputerze) lub wielowęzłowo. Dla konfiguracji trzynawłowej możemy uruchomić 1 serwer (główny) i 2 agentów, lub nawet zrobić wszystkie 3 serwery dla HA (nie jest to konieczne, ponieważ HA nie jest celem). Dołączenie agentów jest trywialne za pomocą tokena. Domyślny magazyn danych SQLite w K3s działa dla jednowęzłowego; dla wielowęzłowego HA przełączymy się na wbudowany etcd (K3s może to zrobić automatycznie, gdy uruchomimy wiele węzłów serwera).
-
Narzędzia CLI i UI: Interakcja z K3s jest taka sama jak z każdym Kubernetes – przez
kubectl
. K3s zawiera własną wersjękubectl
(możemy uruchomićk3s kubectl ...
lub po prostu użyć standardowegokubectl
, wskazując go na kubeconfig K3s). Nie ma specjalnego CLI tylko dla K3s poza komendami instalacyjnymi; jest on celowo minimalistyczny. Nie ma wbudowanego interfejsu webowego (standardowy Dashboard nie jest domyślnie instalowany). Jednak możemy ręcznie wdrożyć Kubernetes Dashboard lub inne narzędzia na K3s tak jak w standardowym klastrze. Rancher (narzędzie zarządzania GUI od tej samej firmy) może być również zainstalowany na K3s, jeśli potrzebujemy pełnego interfejsu, ale nie jest częścią K3s samego. W zasadzie, K3s dostarcza podstawowe API k8s i dodajemy inne elementy, jak potrzebujemy (np. ingress, magazyn itp. – niektóre z nich są już włączone jak wspomniano).
MicroK8s (Niskokonserwacyjny Kubernetes od Canonical)
Główne funkcje: MicroK8s to lekka dystrybucja Kubernetesa od Canonical, dostarczana jako pakiet snap. Instaluje pełny konformujący się z Kubernetesem klaster (oryginalne binarki) za pomocą jednej komendy i jest zaprojektowana do łatwego użytkowania (“niskokonserwacyjny”) na jednym komputerze lub małym klastrze. Podkreśla podejście “batteries-included” – dostarczamy wiele opcjonalnych funkcji, które można włączyć prostymi komendami. MicroK8s domyślnie korzysta z oryginalnego Kubernetesa (wszystkie standardowe API), ale z wygodnymi dodatkami dla typowych potrzeb. Obsługuje zarówno jednowęzłowe, jak i wielowęzłowe wdrożenia (możemy utworzyć klaster, łącząc węzły), a nawet ma tryb HA dla płaszczyzny kontroli (korzystając z Dqlite – rozproszonego SQLite – gdy mamy 3 serwery).
-
Łatwość instalacji i konserwacji: Bardzo łatwa – po prostu
snap install microk8s --classic
na maszynie Ubuntu ustawia węzeł Kubernetesa. To jeden pakiet zawierający wszystkie komponenty. MicroK8s jest utrzymywany przez system snap Ubuntu, co oznacza, że aktualizacje są atomowe i mogą być automatyczne (możemy śledzić kanał dla wersji Kubernetesa). Ta automatyczna aktualizacja jest unikalna wśród tych opcji – możemy zarejestrować się, aby otrzymywać poprawki bezpieczeństwa i drobne aktualizacje za pomocą aktualizacji snap. Zarządzanie MicroK8s odbywa się za pomocą komendymicrok8s
, która ma podkomendy włączające/wyłączające funkcje. W ogólności, to bardzo niskotarczowe: nie ma kontenerów ani maszyn wirtualnych do zarządzania (uruchamia się natively na hoście), a także nie ma zewnętrznego etcd do konfiguracji (używa wewnętrznego magazynu danych). Konserwacja polega głównie na aktualizowaniu snapa, gdy to konieczne, i korzystaniu zmicrok8s.status
, aby monitorować. -
Obsługa Persistent Volumes: Dostępna przez dodatek. Domyślnie MicroK8s nie automatycznie przydziela PV, dopóki nie włączymy dodatku „hostpath-storage”. Włączenie tego (za pomocą
microk8s enable hostpath-storage
) tworzy domyślny StorageClass, który przydziela woluminy z katalogu na hoście. To jest w zasadzie dynamiczny hostPath, podobny do lokalnego ścieżki w K3s. Po włączeniu, każdy PVC będzie wiązał się z hostPath PV na węźle MicroK8s. (W wielowęzłowym klastrze MicroK8s, hostPath PV będzie znajdował się na jednym węźle – odpowiednie do testowania lub użycia w homelabie, ale nie magazynu rozproszonego). MicroK8s oferuje również Mayastor i inne dodatki magazynowe, jeśli chcemy zaawansowanej obsługi magazynu na wielu węzłach, ale dla prostoty hostpath magazyn działa dobrze. Uwaga: Dodatek nie jest włączony domyślnie (aby zachować lekkość), więc będziemy chcieli włączyć go, aby uzyskać działające PVC. Canonical zauważa, że to nie jest przeznaczone do produkcji HA (ponieważ nie jest replikowane), ale dla homelaba jest idealne. -
Obsługa LoadBalancer: Dostępna przez dodatek. MicroK8s nie zawiera domyślnego balansera obciążenia, ale oferuje MetalLB jako łatwy dodatek. Uruchamiając
microk8s enable metallb:<start-IP>-<end-IP>
wdraża MetalLB w trybie warstwy 2 i pozwala nam określić pulę adresów IP z sieci LAN do użycia w usługach typu LoadBalancer. Po włączeniu, każda usługa typu LoadBalancer automatycznie otrzyma adres IP z tego zakresu (a MicroK8s będzie go ogłaszał przez ARP w sieci LAN). To daje doświadczenie podobne do chmury na sprzęcie naziemnym. (Jeśli nie włączymy MetalLB, usługa typu LoadBalancer pozostanie w stanie oczekiwania, ponieważ sam MicroK8s nie implementuje balansera – tak jak oryginalny Kubernetes.) W homelabie MetalLB jest prosty i pozwala nam uzyskać dostęp do usług w naszej lokalnej sieci. Musimy wybrać wolny podsieć lub zakres adresów IP w naszej sieci. Komenda włączenia w MicroK8s sprawia, że konfiguracja jest łatwa, ale to nadal oddzielny krok. (W przeciwieństwie do K3s, który działa natychmiastowo dla LB, ale z ograniczeniem do użycia IP/porcie węzła.) Wiele użytkowników MicroK8s po prostu włącza MetalLB jako część swojej początkowej konfiguracji, aby uzyskać funkcjonalny LB. -
Wymagania dotyczące zasobów: MicroK8s jest dość lekki, choć nieco bardziej obciążony niż K3s. Uruchamia wszystkie główne usługi (serwer API, kontroler, scheduler, kubelet, etcd lub Dqlite) natively. Użycie w stanie bezczynności wynosi zwykle około 500–600 MB RAM dla płaszczyzny kontroli, w zależności od włączonych dodatków. Canonical podaje około 540 MB podstawowej pamięci. Użycie CPU jest niskie w stanie bezczynności, a nasze węzły 16 GB mają dużo miejsca na zapas. Wymagania dotyczące miejsca na dysku są małe (snap ~ 200 MB plus dane etcd). W sumie, MicroK8s może działać na niewielkim sprzęcie (jest nawet oferowany dla Raspberry Pi), a w naszym scenariuszu maszyny łatwo go pomieścią. Jeśli włączymy wiele dodatków (dashboard, monitorowanie itp.), zużycie zasobów wzrośnie odpowiednio.
-
Jednowęzłowy vs. wielowęzłowy: MicroK8s działa dobrze dla obu. Możemy go używać do jednowęzłowego klastra (np. na maszynie deweloperskiej lub jednym serwerze) lub utworzyć wielowęzłowy klaster, łącząc węzły. Dokumentacja MicroK8s zawiera komendę dodającą węzeł (pobieramy token dołączenia z pierwszego węzła i używamy go na innych). W konfiguracji wielowęzłowej bez HA, jeden węzeł będzie główną płaszczyzną kontroli. Z trzema węzłami mamy również opcję włączenia trybu ha-cluster (zrobienie płaszczyzny kontroli HA, uruchamiając Dqlite na trzech węzłach), choć w naszym przypadku HA nie jest konieczne. Niezależnie od tego, czy jest to jednowęzłowy, czy trzynawłowy, doświadczenie jest takie samo API Kubernetesa. Wielowęzłowy MicroK8s jest trochę nowszy niż podejście K3s, ale jest teraz bardzo stabilny. To dobre wyboru, jeśli chcemy „małą chmurę” kilku Ubuntu z uruchomionym k8s z minimalnym wysiłkiem.
-
Narzędzia CLI i UI: MicroK8s zawiera
microk8s
narzędzie wiersza poleceń, które jest bardzo przydatne. Na przykład,microk8s enable <addon>
włącza lub wyłącza różne usługi (DNS, ingress, magazyn, metallb, dashboard itp.), amicrok8s status
pokazuje, co jest uruchomione. Zawiera również wbudowanekubectl
: możemy użyćmicrok8s kubectl ...
(lub aliasować je), które komunikuje się z klastrem – to jest przyjemne, ponieważ nie musimy konfigurować kubeconfig. Dla interfejsu graficznego, MicroK8s oferuje Kubernetes Dashboard jako dodatek (microk8s enable dashboard
), który wdroży standardowy interfejs webowy. Po włączeniu, możemy do niego uzyskać dostęp (działa na porcie 10443 lub przez proxy). MicroK8s nie ma własnego GUI – opiera się na Kubernetes Dashboard lub innych narzędziach – ale łatwość włączenia jest plusem. W skrócie, MicroK8s podkreśla doświadczenie jednokomendowe dla typowych zadań i filozofię „to działa”, ukrywając wiele złożoności (na koszt ukrycia niektórych szczegółów wewnętrznych). To sprawia, że jest bardzo przyjazny dla homelaba dla tych, którzy chcą klaster Kubernetesa bez ręcznej konfiguracji każdego komponentu.
Porównanie K3s vs. MicroK8s: Oba są bardzo podobne pod względem celów i możliwości – lekkie, łatwe do użycia, mogące działać na wielu węzłach. K3s tendencja do bycia bardziej „DIY” przy dodawaniu dodatków (opiera się na Helm chartach lub ręcznych manifestach dla rzeczy, które nie są włączone), podczas gdy MicroK8s oferuje wbudowane dodatki przez CLI. MicroK8s jest również bardziej „oryginalnym” Kubernetesem pod spodem (oryginalne komponenty, tylko pakowane jako snap), podczas gdy K3s używa niektórych niestandardowych binarnych plików i jednej usługi dla wszystkiego. Oba są dobrym wyborem dla homelaba; decyzja często zależy od preferencji: jeśli Ubuntu/snapy i wrażenie integracji są preferowane, MicroK8s jest świetny, podczas gdy jeśli preferujemy minimalistyczne podejście z pewnym większym kontrolą ręczną, K3s jest doskonały. (Podajemy rekomendacje na końcu.)
Minikube (Jedno-węzłowy lokalny K8s)
Główne cechy: Minikube jest głównie narzędziem do uruchamiania Kubernetes lokalnie (często na komputerze lub laptopie programisty), a nie tradycyjnym klastrem rozłożonym na wielu maszynach. Tworzy jednowęzłowy klastrowy Kubernetes w maszynie wirtualnej lub kontenerze na naszej maszynie. Minikube znane jest z szerokiego wsparcia środowisk – może działać na Linuxie, macOS, Windowsie oraz wspiera wiele hiperyzatorów (VirtualBox, KVM, Hyper-V, driver Docker itp.). Jest utrzymane przez Kubernetes SIGs i często jest używane do testowania i nauki. Choć Minikube może zostać przekształcone w konfigurację wielowęzłową, jest przede wszystkim przeznaczony do klastrów jednowęzłowych (tryb „wielowęzłowy” Minikube faktycznie uruchamia wiele węzłów na tej samej maszynie za pomocą runtime kontenerów – przydatny do symulacji klastra, ale nie do działania na oddzielnych maszynach fizycznych).
-
Łatwość instalacji i użycia: Minikube jest bardzo łatwy w użyciu na jednej maszynie. Instalujemy binarkę minikube, upewniamy się, że mamy driver VM (lub Docker), a następnie uruchamiamy
minikube start
. To skonfiguruje lokalną maszynę wirtualną/kontener i uruchomi Kubernetes wewnątrz. Jest to najprostszy sposób na uruchomienie klastra Kubernetes po raz pierwszy. CLI (minikube
) oferuje polecenia do interakcji z maszyną wirtualną (start, stop, delete) oraz do włączania dodatków. Ponieważ Minikube jest zaprojektowany do użytku lokalnego, nie jest „długo działającym” daemonem – zazwyczaj uruchamiamy go, gdy go potrzebujemy, a potem go zatrzymujemy, kiedy skończymy, choć możemy utrzymywać go wciąż działającego na serwerze homelab, jeśli tego chcemy. Konserwacja/aktualizacje są łatwe: wystarczy zaktualizować wersję minikube i ponownie uruchomić klaster (Minikube może również zaktualizować wersję Kubernetes, która działa, za pomocą flagi). Jednak jedną z wad jest to, że Minikube jest przeznaczony do jednowęzłowych klastrów (dodanie więcej węzłów oznacza uruchomienie dodatkowych instancji VM na tej samej maszynie, a nie dołączenie rzeczywistych oddzielnych hostów). Użycie Minikube na trzech oddzielnych fizycznych węzłach oznaczałoby uruchomienie trzech niezależnych jednowęzłowych klastrów, co prawdopodobnie nie jest tym, czego chcemy. Minikube świetnie sprawdza się do rozwijania i testowania na jednej maszynie, ale nie jest przeznaczony do zarządzania klastrem rozłożonym na wielu serwerach fizycznych. -
Wsparcie dla Persistent Volume: Wbudowane (hostPath). Klaster Minikube automatycznie zawiera domyślną klasę magazynowania, która korzysta z hostPath provisionera. W rzeczywistości Minikube uruchamia mały kontroler, który dynamicznie tworzy hostPath PV wewnątrz VM, gdy są żądane PVC. To oznacza, że możemy tworzyć PersistentVolumeClaims, a będą one spełniane przy użyciu magazynowania na systemie plików VM Minikube (zwykle pod
/tmp/hostpath-provisioner
lub podobnym). To działa natychmiast – nie wymaga konfiguracji dla podstawowego użycia PV. Na przykład, domyślna klasa magazynowania „standard” w Minikube mapuje się na magazynowanie hostPath na węźle. Jedna uwaga: jeśli zrestartujemy lub usuniemy VM Minikube, te hostPath volume mogą zostać utracone (Minikube stara się zachować pewne katalogi po restartach – np./data
,/var/lib/minikube
,/tmp/hostpath*
są zachowywane). Ale w ogólności, dla środowiska nieprodukcyjnego to jest w porządku. Jeśli chcemy symulować więcej, Minikube ma również dodatek CSI hostpath driver, który obsługuje tworzenie kopii zapasowych i może działać w trybie wielowęzłowym, ale to bardziej do eksperymentowania. Podsumowując: Minikube obsługuje PV domyślnie poprzez hostPath, co wystarczy do testowania aplikacji stanowych w homelabie. -
Wsparcie dla LoadBalancer: Obsługiwane poprzez tunelowanie (lub dodatek MetalLB). W chmurze, usługa LoadBalancer otrzymuje zewnętrzną IP z chmurą. W Minikube, oczywiscie, nie ma dostawcy chmurowego, więc Minikube oferuje dwa mechanizmy:
- Minikube Tunnel: Możemy uruchomić
minikube tunnel
w oddzielnym procesie, który utworzy trasę sieciową na naszym hoście i przypisze IP do naszej usługi LoadBalancer. W zasadzie, używa naszego hosta jako „zewnętrznego LB”. Gdy tworzymy usługę LoadBalancer, Minikube pokaże „external IP” (zwykle z podsieci klastra) i procesminikube tunnel
przekieruje to do usługi. To wymaga, aby proces tunelu działał cały czas (i zazwyczaj uprawnień root do tworzenia tras). To jest trochę ręczny krok, ale Minikube wypisuje przypomnienie, jeśli mamy usługę LoadBalancer bez działania tunelu („External-IP pending” do momentu uruchomienia tunelu). - Dodatek MetalLB: Nowsze wersje Minikube również zawierają dodatek MetalLB. Możemy wykonać
minikube addons enable metallb
i skonfigurować zakres IP (Minikube poprosi nas o to). To skutecznie wdraża MetalLB wewnątrz klastra Minikube, który następnie obsługuje usługi LoadBalancer tak, jakby były w dowolnym Kubernetes na sprzęcie nago. Jest to bardziej „wewnątrz klastra” rozwiązanie i nie wymaga oddzielnego procesu tunelowania po początkowej konfiguracji.
Oba opcje działają, a wybór zależy od nas. Dla szybkiego eksponowania jednej usługi,
minikube tunnel
jest szybki i tymczasowy. Dla bardziej trwałego ustawienia, można włączyć dodatek MetalLB, aby LB otrzymywał rzeczywiste IP (np. możemy nadać zakres 10.0.0.240-250 na Minikube z sieci mostkowanej). Pamiętaj, że Minikube jest zwykle jednowęzłowy, więc w praktyce „load balancer” nie balansuje między wieloma węzłami – tylko dostarcza zewnętrznego dostępu do usługi jednego węzła. To jest dobre do rozwoju. W homelabie, jeśli używamy tylko jednego z naszych węzłów i uruchamiamy Minikube na nim, możemy użyć tego do dostępu do naszych aplikacji. Ale jeśli chcemy wykorzystać wszystkie 3 węzły, podejście Minikube do LB nie jest przeznaczone do tego scenariusza. - Minikube Tunnel: Możemy uruchomić
-
Wymagania dotyczące zasobów: Same Minikube jest lekkie, ale ponieważ zwykle uruchamia pełny jednowęzłowy Kubernetes (w maszynie wirtualnej), zużycie zasobów jest podobne do normalnego małego klastra. Minimalnie zalecane jest 2 GB RAM i 2 CPU dla VM. Domyślnie Minikube często przydziela 2 GB RAM dla swojego VM. W naszym przypadku, z 16 GB na maszynie, to jest trywialne. Minikube (Kubernetes) w stanie bezczynności może zużywać około 600 MB pamięci. Jedną rzeczą, którą należy zauważyć, to to, że Minikube będzie działać na naszym systemie operacyjnym – albo jako maszyna wirtualna za pomocą hiperyzatora, albo jako kontener Docker – co dodaje pewne narzuty. Na serwerze homelab, możemy uruchomić Minikube z „none” driver (który instaluje komponenty Kubernetes bezpośrednio na hoście). Jednak „none” (tzw. nago) driver jest w zasadzie podobny do użycia kubeadm na tym węźle, i wymaga ręcznej konserwacji, więc nie jest tak popularny. Najczęściej używany jest driver VM lub Docker. Podsumowując, każdy z naszych węzłów homelab może łatwo uruchomić Minikube. Jedyne ograniczenie to to, że Minikube nie będzie używać zasobów wszystkich 3 węzłów – będzie ograniczony do jednego hosta, na którym działa (chyba że użyjemy eksperymentalnego trybu wielowęzłowego w jednym hoście).
-
Jednowęzłowy vs. wielowęzłowy: Przede wszystkim jednowęzłowy. Minikube jest idealny do jednowęzłowego klastra na jednej maszynie. Ma ona funkcję symulowania wielu węzłów (np.
minikube start --nodes 3
z driverem Docker uruchomi 3 węzły Kubernetes jako kontenery na jednym hoście), ale to jest tylko do testowania. Nie możemy użyć Minikube do tworzenia rzeczywistego wielowęzłowego klastra na 3 oddzielnych serwerach fizycznych. Jeśli mamy 3 maszyny, musielibyśmy uruchomić 3 niezależne instancje Minikube (nie w jednym klastrze). To nie jest prawdziwy doświadczenie klastra (nie będą wiedziały o sobie nawzajem). Dlatego Minikube jest nie zalecany, jeśli naszym celem jest wykorzystanie wszystkich trzech węzłów w jednym klastrze Kubernetes – lepiej nadaje się do scenariuszy, w których mamy tylko jedną maszynę (nasz komputer lub jeden serwer) i chcemy uruchomić K8s na niej. Jest również świetny do nauki podstaw Kubernetes i pracy nad lokalnym rozwojem. -
Narzędzia CLI i UI:
minikube
CLI jest głównym interfejsem. Używamy go do uruchamiania/zatrzymywania klastra, a ma przyjazne skróty: np.minikube dashboard
włączy Dashboard Kubernetes i otworzy go w naszym przeglądarce.minikube addons enable <addon>
może włączyć wiele opcjonalnych komponentów (np. ingress, metallb, metrics-server itp.). Minikube automatycznie konfiguruje dostęp do kubectl (konfiguruje kontekst „minikube” w naszym kubeconfig). Dla UI, jak wspomniano, Dashboard Kubernetes jest łatwo dostępny za pomocą poleceniadashboard
. Minikube nie ma własnego unikalnego interfejsu webowego; opiera się na standardowych narzędziach. Debugowanie Minikube jest również łatwe, ponieważ możemyminikube ssh
, aby wejść do węzła VM, jeśli to konieczne. W ogólności, narzędzia są bardzo przyjazne dla scenariusza jednowęzłowego.
Kubeadm (Standardowy Kubernetes na naszych własnych węzłach)
Główne cechy: Kubeadm nie jest „dystrybucją”, ale raczej oficjalnym narzędziem do tworzenia klastra Kubernetes od podstaw. Użycie kubeadm oznacza, że instalujemy standardowe komponenty upstream Kubernetes na naszych maszynach. Jest to zasadniczo sposób, w jaki „budujemy własny” klaster, stosując najlepsze praktyki, ale bez dodatków, które zawierają dystrybucje. Kubeadm ustawi węzeł kontrolny (uruchamiający etcd, serwer API, kontroler manager, scheduler) i dołączy węzły robocze do niego. Wynik to pełny standardowy klaster Kubernetes identyczny z tym, który uzyskalibyśmy na maszynach wirtualnych w chmurze. Ten podejście daje nam pełną kontrolę i elastyczność – wybieramy wtyczkę sieciową, dostawcę magazynowania itp. – ale wymaga również największej ilości początkowej pracy ręcznej i wiedzy. Często jest używany w środowiskach produkcyjnych lub edukacyjnych, aby zrozumieć wewnętrzne mechanizmy Kubernetes.
-
Łatwość instalacji i konserwacji: W porównaniu do innych, kubeadm jest najbardziej zaangażowany. Musimy ręcznie zainstalować zależności (np. kontener runtime takie jak containerd, kubeadm, kubelet, kubectl) na każdym węźle. Następnie uruchamiamy
kubeadm init
na maszynie głównej, akubeadm join
na węzłach roboczych z tokenem, który dostarczy. Musimy również skonfigurować CNI (wtyczkę sieciową) po inicjalizacji (np. Calico, Flannel itp.), ponieważ kubeadm nie instaluje jej domyślnie. Istnieją dobrze udokumentowane kroki dla wszystkiego (proces nie jest trudny, ale składa się z wielu kroków) – zasadniczo, kubeadm dostarcza nam początkowego klastra, ale oczekuje, że sami obsłużymy dodatki. W zakresie konserwacji, jesteśmy odpowiedzialni za aktualizacje (kubeadm ma polecenie do aktualizacji, ale musimy ręcznie drenażować węzły, aktualizować binarki itp.), jak również monitorowanie zdrowia etcd, odświeżanie certyfikatów itp. Krótko mówiąc, kubeadm jest potężny, ale ręczny. Często nazywany jest „trudnym sposobem” (choć nie tak trudnym jak budowanie od zera). Dla pasjonata homelab, który lubi uczyć się, kubeadm to świetny sposób, aby zrozumieć Kubernetes głęboko. Ale jeśli naszym priorytetem jest „łatwość i niski koszt konserwacji”, kubeadm będzie wymagał więcej pracy niż K3s/MicroK8s. Każda aktualizacja lub zmiana będzie wymagała ręcznej pracy. Mimo to, po ustawieniu, to rzeczywisty produkt: standardowy klaster Kubernetes bez ukrytych abstrakcji. -
Wsparcie dla Persistent Volume: Brak domyślnie (musi zostać dodany ręcznie). Klastrowy Kubernetes zainstalowany przez kubeadm to w zasadzie pusty Kubernetes – nie zawiera domyślnej klasy magazynowania ani dynamicznego dostawcy. W środowiskach chmurowych dostawca chmurowy zwykle dostarczyłby domyślną klasę magazynowania (np. AWS EBS itp.), ale w środowisku homelab na sprzęcie nago musimy zainstalować własne rozwiązanie. Powszechne podejścia:
- HostPath Provisioner: Możemy powtórzyć to, co robi K3s/Minikube, instalując coś takiego jak Rancher Local Path Provisioner (który to mały kontroler + klasa magazynowania tworząca hostPath PV). To prosty dodatek (tylko manifest YAML) i daje nam lokalne dynamiczne magazynowanie.
- NFS lub NAS: Niektórzy użytkownicy homelab ustawiają serwer NFS (lub używają NAS) i następnie używają statycznych PV lub wtyczki NFS CSI do przydzielenia.
- OpenEBS/Longhorn/Ceph: Są bardziej złożone opcje, takie jak wdrażanie Longhorna lub Ceph RBD za pomocą Rooka, jeśli chcemy magazynowanie rozproszonego na węzłach. Te wymagają więcej zasobów i złożoności.
Kluczowy punkt to to, że kubeadm nie „rozwiązuje” magazynowania dla nas – musimy sami podejmować decyzję i konfigurować to. Jeśli priorytetem jest łatwość, najprostszy sposób to wdrożenie hostPath provisionera lub użycie NFS. Na przykład, lokalny provider Ranchera może zostać wdrożony w kilku poleceniach
kubectl apply
i zasymuluje zachowanie K3s (tworząc woluminy pod/var/lib/rancher/
na dowolnym węźle). Ale to jest krok ręczny. Dopóki tego nie zrobimy, każdy PVC, który utworzymy, będzie w stanie „Pending”, ponieważ Kubernetes nie ma domyślnego mechanizmu przydzielenia. Więc choć kubeadm wspiera Persistent Volumes (jest to pełny Kubernetes), współpraca z dynamicznym PV zależy od naszej pracy nad jego konfiguracją. -
Wsparcie dla LoadBalancer: Brak domyślnie (musi zostać dodany ręcznie). Podobna sytuacja tutaj: w tradycyjnym klastrze on-prem nie mamy wbudowanego mechanizmu LoadBalancer. Jeśli utworzymy usługę typu LoadBalancer w standardowym klastrze kubeadm, będzie ona w stanie „pending” do czasu, aż wdrożymy kontroler, który ją obsłuży. Typowe rozwiązanie to samodzielne wdrożenie MetalLB. MetalLB może zostać wdrożony za pomocą manifestu lub wykresu Helm – skonfigurujemy zakres IP i MetalLB przydzieli te IP dla usług LoadBalancer (jak w MicroK8s). Istnieją wiele przewodników instalacji MetalLB na klastrach kubeadm. Inna opcja, którą niektórzy używają, to kube-vip do VIP kontrolera i usług LoadBalancer, ale MetalLB jest prostszy dla usług. Zasadniczo, z kubeadm mamy swobodę (lub obowiązek) ustawienia dowolnego mechanizmu balansowania obciążenia, który pasuje do naszych potrzeb. Jeśli nie ustawimy niczego, jesteśmy ograniczeni do usług NodePort dla dostępu zewnętrzniego. Dla homelabu, instalacja MetalLB jest bardzo zalecana – jest prosta i daje nam funkcjonalność IP usług w stylu chmury. Ale znowu, to dodatkowy krok, który musimy wykonać (w przeciwieństwie do K3s, który działa natychmiast lub MicroK8s z prostym włączaniem).
-
Wymagania dotyczące zasobów: Standardowy Kubernetes jest trochę cięższy niż wersje skrócone. Każdy węzeł będzie uruchamiać kubelet i kube-proxy, a węzeł główny będzie uruchamiać etcd i komponenty kontrolne. Jeden węzeł kontrolny może nadal działać w 2 GB RAM, ale zazwyczaj chcemy trochę więcej, jeśli uruchamiamy pakiety na nim. Przewodnik padok sugeruje 2 GB dla węzła głównego, 2 GB dla węzła roboczego minimum. W naszym przypadku (16 GB na węźle), to jest w porządku. Bezczynny etcd i serwer API mogą zużywać kilka setek MB pamięci. Nie ma dużej różnicy w czasie działania między klastrem kubeadm a MicroK8s – po wszystkim, MicroK8s jest tymi samymi komponentami. Różnica jest tylko w tym, co działa domyślnie (MicroK8s może włączyć DNS i magazynowanie domyślnie, podczas gdy w kubeadm musimy je zainstalować). Więc pod względem zasobów, kubeadm może być tak lekki, jak i ciężki, jak tylko go skonfigurujemy. Bez dodatkowych instalacji, może być dość lekki. Z typową konfiguracją (np. dodajemy CoreDNS, Dashboard itp.), spodziewamy się około 1 GB zużycia dla systemowych narzutów. Mamy dużo RAM, więc zasoby nie są problemem. To bardziej kwestia czasu i zasobów ludzkich potrzebnych do zarządzania nimi niż CPU/RAM.
-
Jednowęzłowy vs. wielowęzłowy: Kubeadm może robić oba, z pełną elastycznością. Możemy zainicjalizować jednowęzłowy klaster (i nawet powiedzieć kubeadm, aby pojedynczy węzeł uruchamiał obciążenia, usuwając taint z węzła głównego). Albo możemy mieć jeden węzeł główny i dołączyć dwa węzły robocze (typowe ustawienie 3-węzłowe). Moglibyśmy nawet ustawić 3 węzły główne i 3 węzły robocze itd. – dowolną topologię. W naszym przypadku, prawdopodobne ustawienie kubeadm to 1 węzeł kontrolny i 2 węzły robocze (ponieważ HA nie jest potrzebne, nie potrzebujemy wielu węzłów głównych). To daje nam funkcjonalny 3-węzłowy klaster. Proces wielowęzłowy jest dobrze udokumentowany: zasadniczo, zainstaluj Kubernetes na wszystkich, zainicjalizuj jeden, dołącz pozostałe. Wynik jest identyczny z tym, co dostanie się z zarządzanego klastra lub innej dystrybucji: nasze 3 węzły pojawiają się w
kubectl get nodes
itp. Kubeadm na pewno spełnia wymaganie „można użyć wszystkich 3 węzłów”. -
Narzędzia CLI i UI: Z kubeadm, jedynym specjalnym CLI jest
kubeadm
sam w sobie, używany do instalacji i (później) kroków aktualizacji. W codziennym użytkowaniu, używamykubectl
, aby zarządzać klastrem. Nie ma żadnego zintegrowanego CLI zarządzania poza tym, co oferuje Kubernetes. Dla UI, nic nie jest domyślnie zawarte – możemy ręcznie wdrożyć Dashboard Kubernetes lub inne narzędzia (jak w każdym klastrze). Zasadniczo, kubeadm daje nam pustą planszę Kubernetes. To zależy od nas, co na niej narysujemy – co obejmuje instalację wygoda takich jak dashboard, kontrolery ingressu, klasy magazynowania itp. Wiele narzędzi trzecich (Lens, Octant itp.) może również połączyć się z klastrem kubeadm, jeśli chcemy doświadczenia GUI zarządzania, ale to są narzędzia zewnętrzne. Podsumowując, z kubeadm otrzymujemy czyste środowisko Kubernetes – maksymalna elastyczność, ale również konieczność ustawienia wszystkiego, jakby to był klaster produkcyjny. -
Kubespray Zobacz również, jak zainstalować tę wersję Kubernetes z Kubespray.
Tabela porównania boczna
Poniżej znajduje się podsumowanie porównania czterech opcji pod względem kluczowych punktów:
Aspekt | K3s (Lekki Rancher K8s) | MicroK8s (Canonical “Low-Ops” K8s) | Minikube (Jedno-węzłowy Dev K8s) | Kubeadm (Vanilla Kubernetes) |
---|---|---|---|---|
Instalacja | Skrypt instalacyjny jednoliniowy (jedno wykonywalne plik). Uruchamia się jako pojedynczy systemowy serwis. Bardzo szybka konfiguracja. | Instalacja jednoliniowa za pomocą snap na Ubuntu. Wszystkie komponenty są włączone. Łatwe tworzenie klastra za pomocą microk8s join . |
Zainstaluj CLI minikube, a następnie minikube start , aby uruchomić lokalny VM/container. Krzyżowopłaszczyznowy i przyjazny dla początkujących. |
Ręczna instalacja kubeadm, kubelet itp. na każdym węźle. Uruchom kubeadm init + kubeadm join z wymaganiami. Wymaga wielu kroków (runtime, wtyczka sieciowa itp.). |
Konserwacja i aktualizacje | Ręczne aktualizacje (zamień binarkę lub użyj skryptu instalacyjnego dla nowej wersji). Proste, ponieważ to jedna binarka; niewiele do zarządzania. Brak automatycznych aktualizacji. | Aktualizacje przez snap refresh (można być automatyczne). Dodatki i usługi klastra zarządzane przez CLI microk8s . Ogólnie niski poziom operacyjny; dostępne są automatyczne aktualizacje. |
Łatwe usuwanie/ponowne tworzenie klastra dla dewelopera. Aktualizacje poprzez aktualizację wersji minikube i ponowne uruchomienie klastra. Przeznaczone do użycia tymczasowego (mniejsze zainteresowanie trwałą aktualizacją w miejscu). | Użytkownik odpowiada za wszystkie aktualizacje. Użyj kubeadm upgrade , ale musisz wyczerpać węzły, zarządzać kopią zapasową etcd itp. Pełna kontrola, ale robisz to sam (brak automatycznych aktualizacji). |
Wersja K8s | Często śledzi upstream (często używany w wersjach krawędziowych). Zgodny z CNCF. Niektóre funkcje są domyślnie wyłączane (alpha/legacy). | Śledzi wersje upstream (kanale snap dla 1.27, 1.28 itp.). Zgodny z CNCF. Praktycznie binarki vanilla K8s. | Możemy wybrać wersję Kubernetes w momencie startu (np. minikube start --kubernetes-version=v1.27 ). Domyślnie najnowsza stabilna. |
Dowolna wersja, którą chcemy (zainstaluj konkretne wersje kubeadm/kubelet). Pełny upstream Kubernetes – decydujemy sami, która wersja i kiedy aktualizować. |
Domyślne funkcje | Domyślne funkcje: Flannel CNI, CoreDNS, Traefik ingress, LB usługi, lokalna klasa magazynu, metrics-server itp. (Wszystkie można wyłączyć, jeśli nie są potrzebne). Mała konfiguracja potrzebna, aby działać. | Minimalne domyślne: DNS jest zwykle włączony, inne opcjonalne. Łatwe dodatki jednoliniowe do ingress (NGINX), MetalLB, hostpath storage, dashboard itp.. Można włączyć tryb HA na 3+ węzłach. | Domyślne w VM: zwykle zawiera runtime Docker/containerd, Kubernetes z domyślnymi dodatkami takimi jak StorageProvisioner i DNS. Dodatki opcjonalne (ingress, dashboard itp.) przełączane przez CLI. Brak wersji wielowęzłowych domyślnie. | Pustka: Nic poza podstawowym Kubernetes. Brak ingress, brak domyślnej magazynu lub LB, brak dashboardu, dopóki nie zainstalujemy ich. Wybieramy wtyczkę CNI (musimy zainstalować jedną dla sieci). Praktycznie klastrowanie DIY. |
Wsparcie dla Persistent Volume | Tak – z domyślnego zestawu. Wbudowany Rancher local-path dynamiczny dostawca, który tworzy hostPath PVs na węźle dla dowolnego PVC. Domyślna klasa magazynu „local-path” automatycznie używa lokalnego dysku. | Tak – łatwy dodatek. Włącz hostpath-storage , aby uzyskać domyślną klasę magazynu dla dynamicznych PV używających hostPath. Dopóki nie zostanie włączony, nie ma domyślnego dostawcy PV. Dodatek nie jest przeznaczony do produkcji wielowęzłowej, ale jest dobry dla homelaba. |
Tak – z domyślnego zestawu. Domyślna klasa magazynu używa hostPath dostawcy wewnątrz VM minikube. PVCs są spełniane przez prosty kontroler, który tworzy hostPath PV na systemie plików węzła. Dane trwają po ponownym uruchomieniu na niektórych katalogach. | Nie (ręczne). Brak domyślnego dostawcy – klastrowanie nie będzie miało klasy magazynu początkowo. Użytkownik musi zainstalować rozwiązanie magazynowe (np. lokalny dostawca ścieżki, NFS, Ceph itp.). Podstawowy podejście: zastosuj YAML dostawcy hostPath, aby symulować to, co robi K3s/Minikube. Dopóki nie zostanie to zrobione, PVCs pozostają w stanie oczekiwania. |
Wsparcie LoadBalancer | Tak – wbudowany ServiceLB. Kontroler servicelb K3s (Klipper) monitoruje usługi LoadBalancer i wdraża pakiety na węzłach, aby je uwidocznić. Używa IP węzła i portów hosta do przekazywania ruchu. Działa z domyślnym konfiguracją. Przystosowany do małych klastrów; używa wewnętrznego/external IP węzła do usługi. | Tak – przez dodatek MetalLB. Włącz metallb z zakresem IP, aby przydzielić. Zapewnia prawdziwy Layer-2 load balancer na metalu. Nie jest włączony domyślnie. Po włączeniu, każda usługa LoadBalancer otrzymuje unikalny IP z naszego puli. Wymaga małej początkowej konfiguracji (zakres IP). |
Tak – przez tunel lub MetalLB. Brak LB w chmurze, ale możemy uruchomić minikube tunnel , aby przypisać zewnętrzną IP do usług LoadBalancer (tworzy trasę na host). Alternatywnie, włącz dodatek MetalLB w minikube dla automatycznych IP LB. Domyślnie, usługi LB będą pokazywać „oczekiwanie”, dopóki nie użyjemy jednej z tych metod. |
Nie (ręczne). Brak wbudowanego LB. Zwykle instalujemy MetalLB ręcznie do funkcji LB na metalu. Po zainstalowaniu MetalLB (lub innego kontrolera LB), usługi LoadBalancer działają. Bez niego, usługi LB pozostają w stanie oczekiwania na zawsze. |
Sieć (CNI) | Domyślnie = Flannel (sieć overlay). K3s również obsługuje zastępowanie CNI, jeśli jest to konieczne. Wbudowane CoreDNS do DNS klastra. Traefik ingress włączony domyślnie (można wyłączyć). | Domyślnie = Calico (dla nowszych wersji w trybie HA) lub prosty domyślny. (MicroK8s historycznie używał flannel; teraz tendencja do używania Calico dla ścisłego ograniczenia). CoreDNS włączony domyślnie. NGINX ingress dostępny przez dodatek (microk8s enable ingress ). |
Domyślnie = kubenet/bridge (zależy od sterownika; często używa prostego sieci NAT). CoreDNS działa domyślnie. Możemy włączyć dodatek NGINX ingress, jeśli jest to konieczne. Sieć ograniczona do pojedynczego VM; NodePort dostępny przez minikube ip . |
Wybór CNI. Kubeadm nie instaluje żadnej wtyczki CNI – musimy zainstalować jedną (Calico, Flannel, Weave itp.). Mamy pełną kontrolę. W większości przewodników stosujemy YAML Calico po kubeadm init. CoreDNS jest instalowany przez kubeadm domyślnie jako DNS klastra. Kontroler ingress – wybierz i zainstaluj sam (np. NGINX lub Traefik przez manifesty/Helm). |
Klastrowanie wielowęzłowe | Tak. Przeznaczony do wielowęzłowego. Łatwe dołączenie tokenem. Można użyć zewnętrznego DB lub wbudowanego etcd dla wielu masterów. Świetny dla homelabów 2-3+ węzłów. Brak dodatkowych zależności – K3s ma własne klastrowanie wbudowane. | Tak. Obsługuje klastrowanie wielu węzłów MicroK8s (z microk8s join ). Można włączyć HA z 3+ masterami (Dqlite). Bardzo łatwe do utworzenia klastra, zwłaszcza jeśli wszystkie węzły działają na Ubuntu + snap. |
Nie (fizycznie). Jednowęzłowy przez projekt. Można symulować wielowęzłowy na jednym komputerze (wiele węzłów w kontenerach Docker), ale nie można rozciągnąć jednego klastra na wiele fizycznych hostów. Użyj osobnych instancji Minikube do osobnych klastrów. | Tak. Pełna obsługa wielowęzłowego (to cel). Możemy mieć 1 master + wiele workerów, lub nawet wiele masterów (choć konfiguracja HA kubeadm jest bardziej skomplikowana). Brak wbudowanej granicy rozmiaru klastra. |
Zużycie zasobów | Bardzo niskie. Płaszczyzna kontroli ~<0.5 GB pamięci w stanie bezczynności. Jednoprocesowa płaszczyzna kontroli daje mały zasób. Efektywna pod względem procesora (choć może używać nieco więcej procesora w stanie bezczynności niż MicroK8s według niektórych raportów). Idealna dla niskiej mocy lub dużej ilości wolnej przestrzeni. | Niskie. ~0.5–0.6 GB pamięci dla płaszczyzny kontroli w stanie bezczynności. Słusznie wyższa podstawa pamięci niż K3s, ale stabilna. Używa Ubuntu snap (może mieć pewne nadmiary). Nadal lekki w porównaniu do pełnego Kubernetes. | Średnie. Domyślnie 2 GB alokacji VM (użycie ~0.6 GB w stanie bezczynności). Uruchamia pełny jednowęzłowy Kubernetes, plus warstwę VM. Nie jest problemem na systemach 16 GB, ale w zasadzie zużywa zasoby małego klastra na jednym komputerze. | Średnie. Jednowęzłowy z jednym workerem może zużywać ~1 GB w stanie bezczynności po dodaniu typowych dodatków. Każdy dodatkowy węzeł dodaje minimalne nadmiary (tylko kubelet, proxy). Podobne do działania Kubernetes w chmurowych VM o porównywalnym rozmiarze. Na 3 węzłach z 16 GB każdy, nadmiary są znikome w kontekście. |
Narzędzia CLI | Użyj k3s do instalacji i jako wrappera dla kubectl (lub użyj standardowego kubectl ). Brak osobnego CLI do zarządzania (K3s jest głównie „ustaw i zapomnij”). Niektóre pomocnicze skrypty (np. k3s-killall.sh ). Można dodać GUI Ranchera, jeśli tego chcesz. |
Bogaty CLI microk8s : np. microk8s enable/disable <addon> , microk8s status . Również zawiera microk8s kubectl . Projektowany do uproszczenia typowych zadań (nie wymaga bezpośredniego edytowania manifestów systemowych dla podstawowych zadań). |
CLI minikube do uruchamiania/zatrzymywania klastra, zarządzania konfiguracją i dodatkami oraz do pobierania informacji (IP, URL usługi, logi). Również dostarcza wygodnych poleceń, takich jak minikube dashboard . Interakcja z klastrem przez kubectl (konfiguracja automatycznie ustawiona dla kontekstu minikube). |
Tylko kubeadm do początkowej instalacji i aktualizacji. Codzienne operacje przez standardowy kubectl i inne narzędzia Kubernetes. Brak CLI specyficznych dla dystrybucji poza początkowym etapem. Będziesz pracować z surowymi poleceniami Kubernetes i może narzędziami systemowymi do konserwacji. |
UI / Panel sterowania | Nie jest domyślnie włączony. Można ręcznie zainstalować Panel sterowania Kubernetes lub użyć narzędzi zewnętrznych (nic specyficznego dla Ranchera, chyba że dodamy Ranchera osobno). K3s skupia się na operacjach bez interfejsu graficznego. | Nie jest domyślnie włączony, ale dostępny przez jedno polecenie: microk8s enable dashboard wdraża standardowy interfejs Panelu sterowania. Łatwy dostęp do klastra przez microk8s dashboard-proxy . Dobrze współpracuje również z Lens GUI od Canonical, jeśli tego chcesz (Lens może bezpośrednio uzyskać dostęp do MicroK8s). |
Nie jest włączony domyślnie, ale polecenie minikube dashboard wdroży i otworzy interfejs Panelu sterowania web dla nas. Jest to przeznaczone do wygody w lokalnym dewelopowaniu – jedno polecenie i mamy GUI do przeglądania obciążeń. |
Nie jest włączony. Możemy zainstalować Panel sterowania (zastosować YAML), jeśli tego chcemy. W przeciwnym razie użyjemy CLI lub aplikacji panelu sterowania trzecich stron. W homelabie można zainstalować panel sterowania i utworzyć NodePort lub użyć kubectl proxy , aby go zobaczyć. Kubeadm nie martwi się o interfejsy graficzne. |
Źródła: Dane powyżej zostały zszyte z oficjalnych dokumentacji i przewodników użytkownika: na przykład, zużycie pamięci z własnej porównawczej analizy MicroK8s, domyślny magazyn w dokumentacji K3s, zachowanie usługi LB K3s z dokumentacji K3s, szczegóły dodatków MicroK8s z dokumentacji Canonical, PV i tunel Minikube z dokumentacji Kubernetes, oraz ogólne raporty doświadczeń. (Zobacz odniesienia dla pełnych cytowanych źródeł.)
Rekomendacje
Biorąc pod uwagę priorytety (łatwość instalacji/utrzymania oraz wbudowaną obsługę magazynowania i load balancerów) oraz scenariusz (3 węzły Ubuntu, niezainteresowane HA):
-
Najlepsze opcje: K3s lub MicroK8s są najbardziej odpowiednie dla homelaba z 3 węzłami:
- Oba są bardzo łatwe w instalacji (jedna komenda na każdym węźle) i wymagają minimalnego utrzymania. Abstrahują większość złożoności działania klastra.
- Oba obsługują wielowęzłowe klastry z domyślną konfiguracją (możemy dołączyć nasze 3 węzły i zobaczyć jednolity klaster).
- Oba zapewniają rozwiązanie dla Persistent Volumes i LoadBalancers bez większego wysiłku: K3s zawiera je domyślnie (magazyn lokalny, Klipper LB), a MicroK8s udostępnia je poprzez proste polecenia
enable
. To oznacza, że możemy wdrożyć typowe aplikacje (bazy danych z PVC, usługi z typem=LoadBalancer) z minimalnym ręcznym konfigurowaniem. - K3s może być atrakcyjne, jeśli chcemy najszybszego uruchomienia i nie ma problemu z użyciem jego domyślnych konfiguracji (np. Traefik ingress). Jest to podejście „ustaw i działaj” z domyślnymi ustawieniami. Jest bardzo popularne w społeczności homelabów ze względu na prostotę. Zwykle korzystać będziemy z standardowego kubectl, a jeśli będzie to konieczne, możemy dostosować lub wyłączyć komponenty pakietu. K3s może być lepszym wyborem, jeśli nie jesteśmy na Ubuntu lub lubimy ekosystem Ranchera (lub planujemy używanie interfejsu zarządzania Ranchera w przyszłości).
- MicroK8s może być atrakcyjne, jeśli preferujemy rozwiązanie wspierane przez Ubuntu i lubimy możliwość włączania funkcji jednym poleceniem. Wewnętrznie jest to praktycznie czysty Kubernetes, co niektórzy uważają za łatwiejsze do rozszerzania. Dodatki (np.
microk8s enable ingress dns storage metallb
) mogą dać nam pełną funkcjonalność „micro cloud” w minutach. MicroK8s również obsługuje aktualizacje płynnie poprzez snapy, co może być przydatne do utrzymania klastra zaktualizowanego bez interwencji ręcznej (możemy to wyłączyć lub kontrolować kanał, aby uniknąć niespodzianek). Jeśli już korzystamy z Ubuntu na wszystkich węzłach (co robimy) i nie ma problemu z użyciem snapów, MicroK8s to świetny wybór dla klastra o niskim poziomie utrzymania.
W skrócie: Nie możemy się pomylić z K3s lub MicroK8s w tym scenariuszu. Oba dałyby nam łatwy, przyjazny dla homelaba Kubernetes z funkcjami, które potrzebujemy. Wiele użytkowników zgłasza pozytywne doświadczenia z obu w konfiguracjach domowych z 2–3 węzłami. MicroK8s może mieć lekką przewagę w łatwości użycia (ze względu na dodatki i integrację), podczas gdy K3s może mieć lekką przewagę w działaniu z minimalnym obciążeniem i prostoty działania w tle.
-
Kiedy wybrać Minikube: Jeśli chcielibyśmy pracować tylko na jednym komputerze lub chcielibyśmy szybkiego czasowego klastra deweloperskiego, Minikube to świetny wybór. To najprostszy sposób na uruchomienie Kubernetesa na laptopie lub jednym węźle do testowania. Jednak dla trwało działającego klastra z 3 węzłami, Minikube nie jest odpowiednim narzędziem – nie połączy tych 3 węzłów w jeden klaster. Skończylibyśmy na niedostatecznym wykorzystaniu sprzętu lub zarządzaniu 3 osobnymi klastrami, co nie jest pożądane. Dlatego w tym homelabie z wieloma węzłami, Minikube nie jest zalecane jako główne rozwiązanie. Możemy nadal używać Minikube na naszym komputerze osobistym, aby testować rzeczy przed wdrożeniem w klastrze homelaba, ale dla samego klastra użyjemy czegoś takiego jak K3s/MicroK8s.
-
Kiedy wybrać Kubeadm: Jeśli naszym celem byłoby poznawanie wewnętrznych mechanizmów Kubernetesa lub posiadanie pełnej kontroli i konfiguracji „podobnej do produkcyjnej”, Kubeadm to dobre ćwiczenie. Wymusi to zrozumienie, jak instalować CNI, magazyn itp., a będziemy konstruować klaster kawałek po kawałku. W kwestii łatwości użycia Kubeadm to najbardziej ręczne podejście. Każda funkcja, której potrzebujemy (np. magazyn lub LB), musimy skonfigurować. Dla homelaba skupionego na nauce, to może być zaletą (edukacyjne); dla homelaba, który chce po prostu, żeby działało, to wada. Dodatkowo, utrzymanie będzie bardziej zaangażowane (szczególnie podczas aktualizacji). Chyba że specjalnie chcemy doświadczenia z czystym Kubernetesem do nauki lub konkretnymi, niestandardowymi potrzebami, użycie K3s lub MicroK8s zaoszczędzi nam dużo czasu i frustracji w środowisku homelaba. Mimo to, niektórzy doświadczeni użytkownicy preferują Kubeadm nawet w domu, aby uniknąć wszelkich specyficznych dla dostawcy cech i mieć wszystko pod kontrolą. W rzeczywistości zależy to od tego, jak dużo wysiłku jesteśmy skłonni wyłożyć. Dla większości, Kubeadm to nadmiar dla małego klastra, gdzie nie ma potrzeby wysokiej dostępności.
-
Inne opcje: Istnieją kilka innych lekkich wersji Kubernetesa, takich jak k0s (od Mirantis) i narzędzia takie jak kind (Kubernetes in Docker). Dla kompletności:
- k0s to kolejna dystrybucja Kubernetesa jednobinarnego, podobna do K3s/MicroK8s, skupiająca się na elastyczności i minimalnym obciążeniu. Jest stosunkowo nowa, ale ma fanów w społeczności homelaba. Może również działać łatwo na naszych 3 węzłach. Nie ma obecnie tak dużej liczby użytkowników jak K3s/MicroK8s, ale to opcja, którą warto śledzić (szczególnie jeśli lubimy pomysł na otwarty, konfigurowalny, minimalny Kubernetes – niektóre raporty pokazują, że k0s zużywa nieco mniej zasobów w trybie bezczynności niż K3s/MicroK8s w podobnych konfiguracjach).
- kind jest głównie używany do testowania klastrów Kubernetesa w kontenerach Docker (często używany w potokach CI). Nie byłby to wybór, który uruchomilibyśmy jako nasz zawsze działający homelab – byłby bardziej odpowiedni do szybkich, tymczasowych klastrów na jednym komputerze (podobnie jak cel Minikube).
- Rancher Kubernetes Engine (RKE) lub K3d lub inne są również dostępne, ale są skierowane do klastrów kontenerowych (np. K3d uruchamia klaster K3s w Dockerze) lub bardziej złożonych scenariuszy wdrażania. W homelabie, K3s i MicroK8s stały się w pewnym sensie standardowymi łatwymi rozwiązaniami.
Podsumowanie: Dla homelaba z 3 dość dobrej maszyn, MicroK8s lub K3s są zalecanymi opcjami, aby uzyskać funkcjonalny klaster Kubernetesa z minimalnym wysiłkiem. Pozwalają nam wykorzystać wszystkie nasze węzły w jednym klastrze i zapewniają wbudowaną obsługę persistent volumes i usług LoadBalancer, co dokładnie to, czego szukamy. Jeśli preferujemy bardziej gotowe, zintegrowane z Ubuntu rozwiązanie, wybierz MicroK8s. Jeśli preferujemy super lekkie, udowodnione rozwiązanie z wsparciem Ranchera, wybierz K3s. W obu przypadkach będziemy mieć działający klaster w minutach. Po wdrożeniu, możemy wdrożyć Kubernetes Dashboard lub inne narzędzia do zarządzania, a zacząć hostować nasze aplikacje z trwałym magazynem i łatwym dostępem do usług. Cieszmy się naszą podróżą w homelabie Kubernetesa!
Strony domowe dystrybucji Kubernetesa
- https://k3s.io/
- https://microk8s.io/
- https://minikube.sigs.k8s.io/docs/
- https://kubernetes.io/docs/reference/setup-tools/kubeadm/
- https://kubernetes.io/