Autor: Matt Connor
k3s na pojedynczym VPS: kiedy warto wdrożyć?
Analiza wdrozenia k3s na pojedynczym serwerze VPS. Sprawdz, ile RAM zajmuje klaster, jak uniknac konfliktu portu 80 podczas instalacji i kiedy Docker Compose jest lepszy.
Czym jest k3s i co zapewnia pojedynczy węzeł
k3s to pełna dystrybucja Kubernetes spakowana w jeden plik binarny. Uruchomienie jej na pojedynczym VPS zapewnia dostęp do rzeczywistego API Kubernetes bez konieczności utrzymywania płaszczyzny sterowania (control plane) złożonej z trzech maszyn. Jest to certyfikowana dystrybucja Kubernetes, więc manifesty zastosowane tutaj będą działać również w zarządzanym klastrze w przyszłości. Instalacja sprowadza się do jednego polecenia i trwa około minuty. Kosztem jest pamięć RAM, która nie jest już dostępna dla aplikacji, oraz zestaw trybów awaryjnych, które nie występują w przypadku Docker Compose.
Firma SUSE buduje k3s z myślą o lokalizacjach brzegowych i małych instalacjach. Każda różnica względem standardowego Kubernetes wynika z dążenia do minimalizacji rozmiaru. Domyślnym magazynem danych jest sqlite obsługiwany przez warstwę pośrednią o nazwie kine, a nie etcd, dzięki czemu nie ma potrzeby utrzymywania kworum etcd. containerd jest wbudowany w plik binarny zamiast być instalowanym oddzielnie. Ten sam plik binarny dostarcza również CoreDNS do obsługi DNS w klastrze, Traefik jako kontroler Ingress, ServiceLB (znany również jako klipper-lb), dzięki któremu usługi typu LoadBalancer działają bez wsparcia dostawcy chmurowego, local-path provisioner do obsługi wolumenów trwałych, metrics-server oraz flannel do obsługi sieci podów. Każdy z tych komponentów uruchamia się domyślnie. Dlatego konflikt portów opisany poniżej jest najczęstszym problemem na serwerze VPS, na którym już działały inne usługi.
Kiedy warto stosować pojedynczy węzeł k3s
Zastosuj tę zasadę. Uruchom k3s, gdy celem jest wykorzystanie Kubernetes API: uczysz się Kubernetes na maszynie, którą kontrolujesz, lub oprogramowanie, którego potrzebujesz, jest dostępne wyłącznie jako Helm chart. Przenośność manifestów również ma znaczenie, ponieważ Deployment utworzony w tym środowisku można przenieść do zarządzanego klastra bez żadnych zmian. Uruchom Docker Compose, gdy celem są same aplikacje. Compose uruchamia te same kontenery przy znacznie mniejszej liczbie komponentów, a plik Compose na VPS jest łatwiejszy do odczytania po roku niż katalog manifestów.
Należy jasno określić, czego nie zapewnia pojedynczy węzeł.
- Brak wysokiej dostępności. Gdy VPS restartuje się, wszystkie obciążenia zostają zatrzymane. Kubernetes próbuje przenieść poda na inny węzeł, lecz żaden inny węzeł nie istnieje.
- Brak aktualizacji typu rolling update, która utrzymuje usługę w stanie aktywnym, chyba że aplikacja toleruje dwie repliki na jednej maszynie współdzielące ten sam wolumen.
- Pamięć masowa przypisana do konkretnej maszyny, z przyczyn opisanych w sekcji local-path poniżej.
- Control plane, który zużywa około gigabajta pamięci RAM niezależnie od tego, czy wdrożono jakiekolwiek usługi.
Nic z powyższych nie czyni k3s złym wyborem. Czyni go złym wyborem z powodów, które zazwyczaj podają użytkownicy, czyli niezawodności. Jeśli celem jest posiadanie kilku maszyn w celu budowy rzeczywistego klastra wielowęzłowego, ta decyzja jest priorytetowa: Proxmox na własnym sprzęcie kontra wynajęty VPS określa pochodzenie węzłów, zanim k3s określi, co będzie na nich uruchamiane.
Zużycie pamięci RAM i procesora przez k3s przed wdrożeniem jakichkolwiek usług
Projekt k3s publikuje zmierzone wartości, a nie szacunki. Należy czytać je uważnie, ponieważ liczby przytaczane przez użytkowników nie dotyczą k3s w stanie spoczynku.
The data behind this chart
[
{
"label": "Server, sqlite datastore",
"ram_mb": "1,596",
"cpu_percent_of_one_core": 6
},
{
"label": "Server, embedded etcd",
"ram_mb": "1,606",
"cpu_percent_of_one_core": 6
},
{
"label": "Agent node only",
"ram_mb": "275",
"cpu_percent_of_one_core": 3
}
]Węzeł serwera w tym teście zużywał 1,596 MB pamięci RAM na 95. percentylu oraz około 6 procent jednego rdzenia. Są to opublikowane dane, a nie pomiary z tego przewodnika; test przeprowadzono na k3s w wersji v1.26.5 ze wszystkimi wbudowanymi komponentami oraz stosem monitoringu Prometheus i Grafana, więc liczba ta uwzględnia rzeczywiste obciążenie, a nie pusty klaster. Zastąpienie sqlite wbudowanym etcd zwiększyło zużycie do 1,606 MB. Węzeł agenta, na którym działa kubelet i containerd bez płaszczyzny sterowania (control plane), zużywał 275 MB. Dokumentowane minimum dla serwera to 2 rdzenie i 2 GB pamięci RAM; minimum to obejmuje k3s oraz wbudowane komponenty przed uruchomieniem własnych obciążeń.
Wnioski praktyczne: na VPS z 2 GB pamięci RAM płaszczyzna sterowania i dołączone dodatki pozostawiają bardzo niewiele zasobów, a pierwszą reakcją systemu pod obciążeniem jest eksmisja podów przez kubelet. 4 GB to bezpieczne minimum dla jednego węzła z kilkoma małymi usługami. Należy zmierzyć własny serwer zamiast polegać na jakichkolwiek opublikowanych liczbach, w tym tych zawartych w tym dokumencie.
free -h
sudo k3s kubectl top node
sudo k3s kubectl get pods -AUruchom free -h przed instalacją oraz ponownie, gdy każdy pod w kube-system uzyska status Running. Różnica stanowi koszt płaszczyzny sterowania na danym sprzęcie. k3s kubectl top node zwraca error: Metrics API not available przez pierwszą minutę lub dwie po instalacji, ponieważ metrics-server nie pobrał jeszcze żadnych danych. Nie jest to błąd. Jeśli planujesz wykorzystać jeden serwer jednocześnie do tego celu i do innych zadań, obliczenia zawarte w dobieraniu pamięci RAM i procesora dla VPS mają tu pełne zastosowanie.
Instalacja k3s przypięta do konkretnego wydania, a nie do najnowszej wersji
Standardowe polecenie szybkiego startu pobiera wersję wskazywaną przez kanał stable w dniu uruchomienia. Na maszynie przeznaczonej do długotrwałej pracy należy przypiąć wersję. k3s publikuje kanał dla każdej wersji minor Kubernetes, więc INSTALL_K3S_CHANNEL=v1.36 śledzi wydania poprawkowe wewnątrz v1.36 i nigdy nie dokona automatycznej aktualizacji do wyższej wersji minor. Według stanu na sierpień 2026 kanał stable wskazuje na v1.36.3+k3s1.
Najpierw należy utworzyć plik konfiguracyjny, a następnie przeprowadzić instalację. k3s odczytuje /etc/rancher/k3s/config.yaml podczas startu, więc wszelkie zawarte w nim ustawienia mają zastosowanie zarówno przy pierwszym uruchomieniu, jak i przy każdym kolejnym.
sudo mkdir -p /etc/rancher/k3s
sudo tee /etc/rancher/k3s/config.yaml >/dev/null <<'EOF'
tls-san:
- k3s.example.com
EOF
curl -sfL https://get.k3s.io | INSTALL_K3S_CHANNEL=v1.36 sh -Aby przypiąć konkretne wydanie zamiast kanału, należy użyć INSTALL_K3S_VERSION=v1.36.3+k3s1. Znak plus jest częścią tagu. Następnie należy sprawdzić, czy usługa została uruchomiona.
k3s --version
sudo systemctl status k3s
sudo k3s kubectl get node
sudo k3s kubectl get pods -Akubectl get node powinno wyświetlić jeden węzeł ze statusem Ready w ciągu około trzydziestu sekund, a każdy pod w kube-system powinien osiągnąć stan Running lub Completed. Węzeł zablokowany w stanie NotReady zazwyczaj oznacza, że środowisko uruchomieniowe kontenerów nie wystartowało, dlatego należy sprawdzić sudo journalctl -u k3s -n 100 --no-pager. W przypadku nietypowych obrazów VPS, przed przystąpieniem do dalszej diagnostyki należy uruchomić sudo k3s check-config: narzędzie to zgłasza brakujące funkcje jądra, co pozwala uzyskać odpowiedź znacznie szybciej niż analiza logów.
Dlaczego port 80 jest już zajęty i z czego zrezygnować, aby to naprawić
Jest to błąd, który często dotyka użytkowników VPS-ów, na których już działała jakaś usługa. Instalacja kończy się powodzeniem. Traefik nie otrzymuje adresu, a dotychczasowa witryna nadal działa, więc na pierwszy rzut oka wszystko wydaje się w porządku, dopóki nie spróbujesz uzyskać dostępu do Ingress.
Mechanizm: dołączony chart Traefik tworzy Service typu LoadBalancer na portach 80 i 443. ServiceLB odpowiada na to żądanie, tworząc DaemonSet małych podów, nazwanych prefiksem svclb-, które rezerwują te numery portów jako hostPort na każdym węźle. hostPort publikuje port kontenera bezpośrednio w przestrzeni nazw sieciowej węzła, dokładnie tak, jak robi to docker run -p 80:80. Jeśli nginx, Caddy, Apache lub inny kontener już zajmuje port 80, jądro systemu nie przydzieli go ponownie, więc scheduler nie ma gdzie umieścić poda.
sudo k3s kubectl -n kube-system get pods
sudo k3s kubectl -n kube-system get svc traefik
sudo ss -lntp '( sport = :80 or sport = :443 )'Zobaczysz, że pod svclb ma status Pending, a usługa nie posiada adresu zewnętrznego:
svclb-traefik-8f2c1a-r6k9x 0/2 Pending 0 3m
traefik LoadBalancer 10.43.62.11 <pending> 80:31480/TCP,443:30219/TCPUruchomienie kubectl -n kube-system describe pod svclb-traefik-... wskazuje bezpośrednio przyczynę:
0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports.ss -lntp informuje, który proces zajmuje port. Istnieje więcej niż jedno rozwiązanie, a każde z nich wiąże się z pewnym kosztem.
Przekaż porty do k3s. Zatrzymaj i wyłącz istniejący serwer WWW, a następnie pozwól Traefikowi przejąć porty 80 i 443. Jest to właściwe rozwiązanie, gdy VPS ma pełnić wyłącznie rolę serwera k3s, a wszystkie dotychczasowe usługi zostaną przeniesione za Ingress.
Wyłącz ServiceLB i zachowaj istniejące proxy. Zainstaluj z użyciem --disable=servicelb. Usługa typu LoadBalancer nadal przydziela NodePort, więc Traefik pozostaje dostępny na wysokim porcie, takim jak 31480, a Twój nginx lub Caddy przekazuje ruch do 127.0.0.1:31480. Ceną jest brak adresu zewnętrznego: usługa będzie stale raportować <pending>, co wygląda jak błąd, mimo że jest to świadomy wybór.
Wyłącz Traefik i kieruj ruch własnym proxy. Zainstaluj z użyciem --disable=traefik. W takim przypadku nie masz kontrolera Ingress, więc obiekty Ingress nie wykonują żadnych działań: pozostają w API bez kontrolera, który by je obsługiwał. Jest to dopuszczalne, gdy kierujesz ruch z proxy hosta do NodePortów i jest to uczciwe rozwiązanie, jeśli wiesz, w jaki sposób chcesz obsługiwać ruch HTTP. Jeśli nie masz pewności, co powinno znajdować się na froncie, rozważ wybór między nginx, Caddy i Traefik jako reverse proxy przed wyłączeniem czegokolwiek.
Obie flagi należy dodać podczas instalacji lub w pliku konfiguracyjnym:
tls-san:
- k3s.example.com
disable:
- traefik
- servicelbEdycja tego pliku po instalacji i uruchomienie sudo systemctl restart k3s również działa, ponieważ --disable robi więcej niż tylko pominięcie komponentu podczas instalacji. Usuwa on również komponent, który jest już wdrożony, więc zmiana odnosi skutek w działającym klastrze.
Aby zachować Traefik, ale zmienić sposób konfiguracji charta, nie edytuj /var/lib/rancher/k3s/server/manifests/traefik.yaml. k3s nadpisuje ten plik wartościami domyślnymi przy każdym uruchomieniu. Zamiast tego dodaj osobny plik w tym samym katalogu, ponieważ wszystko w /var/lib/rancher/k3s/server/manifests jest stosowane automatycznie przy starcie oraz za każdym razem, gdy plik zostanie zmieniony na dysku.
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
name: traefik
namespace: kube-system
spec:
valuesContent: |-
ports:
web:
forwardedHeaders:
trustedIPs:
- 10.0.0.0/8Ten przykład ustawia jedną wartość charta Traefik: zaufane adresy proxy. Ten sam mechanizm pozwala ustawić każdą inną wartość udostępnianą przez chart, w tym jego porty.
Trwała pamięć masowa na jednym węźle
k3s dostarcza domyślną klasę StorageClass o nazwie local-path, obsługiwaną przez local-path provisioner firmy Rancher. Żądanie PersistentVolumeClaim bez określonej klasy storageClassName korzysta z niej automatycznie. Wolumeny znajdują się w /var/lib/rancher/k3s/storage, każdy w osobnym podkatalogu na dysku lokalnym węzła.
sudo k3s kubectl get storageclass
sudo k3s kubectl get pvc -A
sudo ls -l /var/lib/rancher/k3s/storageZ faktu, że dane znajdują się na dysku lokalnym węzła, wynikają dwie konsekwencje, które stają się problematyczne w późniejszym czasie.
Klasa StorageClass używa volumeBindingMode: WaitForFirstConsumer, więc nowe żądanie PVC pozostaje w stanie Pending, dopóki pod faktycznie go nie zamontuje. Polecenie kubectl describe pvc wyświetla:
waiting for first consumer to be created before bindingJest to zachowanie prawidłowe, więc utworzenie samego PVC i oczekiwanie na zmianę stanu nie przyniesie rezultatu.
Po powiązaniu wolumen zyskuje powinowactwo do węzła (node affinity), na którym został utworzony. Powoduje to przypisanie każdego poda korzystającego z tego żądania do danego węzła na czas istnienia wolumenu. Na jednym węźle jest to niezauważalne. Po dodaniu drugiego węzła pod, który odmawia przeniesienia, wygląda jak błąd harmonogramu, dopóki nie zostanie wykonane polecenie kubectl get pv -o yaml i nie odnajdzie się nazwy hosta w sekcji nodeAffinity.
Kopie zapasowe są obowiązkiem administratora. Przebudowa VPS niszczy wspomniany katalog, podobnie jak poniższy skrypt odinstalowujący. Należy tworzyć kopie zapasowe /var/lib/rancher/k3s/storage oraz bazy danych sqlite w /var/lib/rancher/k3s/server/db/state.db, kopiując ją przy zatrzymanej usłudze, ponieważ jest to aktywna baza danych. Alternatywą jest traktowanie klastra jako zasobu tymczasowego i przechowywanie wszystkich manifestów w systemie git.
Ingress i TLS
Przy włączonym Traefik, wystarczy standardowy obiekt Ingress.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: hello
annotations:
cert-manager.io/cluster-issuer: letsencrypt
spec:
ingressClassName: traefik
tls:
- hosts:
- hello.example.com
secretName: hello-tls
rules:
- host: hello.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: hello
port:
number: 80Certyfikaty nie pojawiają się automatycznie. Standardowym rozwiązaniem jest cert-manager, instalowany z opublikowanego manifestu, wraz z jednym ClusterIssuer. Wersja v1.21.1 jest aktualna na sierpień 2026.
sudo k3s kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.21.1/cert-manager.yamlapiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt
spec:
acme:
email: you@example.com
server: https://acme-v02.api.letsencrypt.org/directory
privateKeySecretRef:
name: letsencrypt-account-key
solvers:
- http01:
ingress:
ingressClassName: traefikWyzwanie HTTP-01 oznacza, że serwer ACME (automatic certificate management environment) łączy się z http://hello.example.com/.well-known/acme-challenge/... z poziomu publicznego Internetu. Rekord DNS A musi zatem wskazywać na VPS, a port 80 musi być dostępny dla Traefik. Jeśli wyłączono ServiceLB i wdrożono własne proxy, musi ono również przekazywać ścieżkę wyzwania, w przeciwnym razie cert-manager zatrzyma się na obiekcie Challenge z następującym komunikatem:
Waiting for HTTP-01 challenge propagation: wrong status code '404', expected '200'Monitoruj proces wydawania certyfikatów za pomocą sudo k3s kubectl describe certificate hello-tls oraz sudo k3s kubectl get order,challenge -A.
Plik kubeconfig oraz powody, dla których serwer API pozostaje prywatny
k3s zapisuje poświadczenia administratora w /etc/rancher/k3s/k3s.yaml. Plik ten jest własnością użytkownika root i domyślnie posiada uprawnienia 600. Zawiera on certyfikat klienta z uprawnieniami cluster-admin, więc każdy, kto może go odczytać, przejmuje kontrolę nad klastrem.
sudo k3s kubectl get node
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
kubectl get nodeOsobno zainstalowany kubectl bez ustawionej zmiennej KUBECONFIG kończy działanie błędem The connection to the server localhost:8080 was refused - did you specify the right host or port?, ponieważ odwołuje się do domyślnej lokalizacji, która nie jest powiązana z k3s. Należy ustawić KUBECONFIG lub użyć sudo k3s kubectl, który automatycznie odczytuje właściwy plik.
Często zaleca się --write-kubeconfig-mode 644, aby umożliwić zwykłemu użytkownikowi uruchamianie polecenia kubectl. Należy zrozumieć skutki tego działania: sprawia ono, że poświadczenia z uprawnieniami cluster-admin stają się czytelne dla każdego lokalnego konta w systemie. Na maszynie z jednym administratorem może to być akceptowalny kompromis. Na maszynie współdzielonej jest to niedopuszczalne. Skopiowanie pliku zapewnia dostęp wybranemu użytkownikowi bez udostępniania go wszystkim:
mkdir -p ~/.kube
sudo install -o $USER -g $USER -m 600 /etc/rancher/k3s/k3s.yaml ~/.kube/configLinia server: w tym pliku zawiera wartość https://127.0.0.1:6443. Aby używać kubectl z laptopa, nie należy otwierać portu 6443 na świat. Publiczny interfejs API Kubernetes jest stałym celem ataków, a jego wystawienie na zewnątrz jest najczęstszą przyczyną przejmowania małych klastrów w celu kopania kryptowalut. Należy użyć tunelu SSH, pozostawiając adres w pliku bez zmian:
ssh -N -L 6443:127.0.0.1:6443 user@your-vps
KUBECONFIG=./k3s.yaml kubectl get nodeJeśli dostęp do API musi odbywać się przez prywatny adres sieciowy, należy przeprowadzić instalację z flagą tls-san, podając w niej tę nazwę lub adres, a następnie edytować linię server: w skopiowanym pliku, aby była z nią zgodna. Bez wpisu SAN (subject alternative name) kubectl odrzuci połączenie:
x509: certificate is valid for 127.0.0.1, 10.43.0.1, not 203.0.113.10Udumentowane porty przychodzące dla klastra to TCP 6443 dla API, UDP 8472 dla komunikacji flannel VXLAN między węzłami oraz TCP 10250 dla metryk kubelet. W przypadku pojedynczego węzła żaden z nich nie powinien być otwarty na Internet.
containerd to nie Docker
k3s uruchamia własny, wbudowany containerd i nie współdzieli repozytorium obrazów z Docker. Obraz zbudowany za pomocą docker build jest niewidoczny dla k3s, dlatego pod kończy się błędem ErrImagePull, mimo że docker images wyświetla go na liście. Należy zaimportować go jawnie:
docker save myapp:0.1 | sudo k3s ctr images import -
sudo k3s crictl imagesNastępnie należy unikać tagu :latest dla tego kontenera, ponieważ :latest domyślnie ustawia imagePullPolicy na Always, przez co kubelet i tak próbuje pobrać obraz z rejestru. Każdy inny tag domyślnie ustawia IfNotPresent, co wymusza użycie zaimportowanego obrazu. Uruchomienie obu rozwiązań na jednym VPS jest możliwe. Warto pamiętać, że standardowa instalacja Docker na VPS oraz k3s utrzymują własne repozytoria obrazów oraz własne reguły iptables na tej samej maszynie.
Jak usunąć k3s
Instalator tworzy skrypt odinstalowujący. Nie istnieje możliwość częściowego usunięcia ani cofnięcia operacji.
sudo /usr/local/bin/k3s-uninstall.shSkrypt zatrzymuje i usuwa usługę, usuwa magazyn danych, usuwa dane wolumenów trwałych, usuwa konfigurację węzła oraz usuwa narzędzia dodane przez instalator. Na węźle typu agent skryptem jest k3s-agent-uninstall.sh. Przed uruchomieniem należy skopiować zawartość /var/lib/rancher/k3s/storage poza serwer, ponieważ ten katalog zostanie usunięty. Następnie należy sprawdzić, czy żadne procesy nie blokują portów ani interfejsów za pomocą ip link show oraz sudo ss -lntp. Pozostały interfejs cni0 lub flannel.1 zostanie usunięty przy następnym restarcie systemu.
Uznanie, że jeden węzeł Kubernetes to zbyt złożone rozwiązanie dla danego zadania, jest typowym wnioskiem, a nie porażką. Przeniesienie obciążeń z powrotem do Compose zazwyczaj zajmuje jedno popołudnie.
Tryby awarii i komunikaty, które zobaczysz
Node NotReady lub pętla restartów k3s. Najpierw przeczytaj sudo journalctl -u k3s -n 200 --no-pager. Na małym VPS częstą przyczyną jest mechanizm kernel out-of-memory killer, który przerywa proces, co w dmesg objawia się linią wskazującą na k3s-server. Dokumentowane minimum 2 GB RAM to realna wartość graniczna.
Pod w stanie Pending. kubectl describe pod zawsze wskazuje przyczynę. Insufficient memory lub Insufficient cpu oznacza brak wolnych zasobów na węźle. didn't have free ports to wspomniany wcześniej konflikt hostPort. waiting for first consumer przy PVC oznacza, że mechanizm WaitForFirstConsumer działa zgodnie z założeniami.
ImagePullBackOff. Tag nie istnieje w żadnym rejestrze dostępnym dla węzła lub obraz został zbudowany za pomocą Docker i nie został zaimportowany do containerd.
Traefik odpowiada, aplikacja nie. Treść odpowiedzi 404 page not found pochodzi bezpośrednio z Traefik i oznacza, że żądanie dotarło, ale nie dopasowano żadnego routera. Sprawdź, czy Ingress host zgadza się z wpisaną nazwą oraz czy ingressClassName ma wartość traefik.
DNS klastra nie działa, mimo że host rozwiązuje nazwy poprawnie. Sprawdź CoreDNS za pomocą sudo k3s kubectl -n kube-system logs -l k8s-app=kube-dns. Komunikat typu plugin/loop: Loop ... detected for zone "." uniemożliwia uruchomienie CoreDNS. Występuje on, gdy CoreDNS przekazuje zapytania do resolvera, który odsyła je z powrotem, co jest efektem użycia adresu pętli zwrotnej w /etc/resolv.conf. Skieruj k3s na właściwy plik upstream za pomocą --resolv-conf /run/systemd/resolve/resolv.conf.
FAQ
Czy warto uruchamiać k3s na pojedynczym VPS?
Warto, jeśli celem jest wykorzystanie API Kubernetes: nauka na kontrolowanej maszynie, utrzymanie przenośności wdrożeń w formie manifestów, uruchamianie oprogramowania dostępnego wyłącznie jako Helm chart lub budowanie rozwiązań, które w przyszłości trafią do zarządzanego klastra. Nie warto, jeśli celem jest jedynie uruchamianie kontenerów, ponieważ Docker Compose realizuje to przy znacznie mniejszym nakładzie pracy administracyjnej i około gigabajcie więcej wolnej pamięci RAM. Pojedynczy węzeł nie zapewnia wysokiej dostępności, więc niezawodność nie jest powodem wyboru tego rozwiązania.
Dlaczego usługa typu LoadBalancer w k3s pozostaje w stanie Pending?
ServiceLB tworzy pody svclb-, które rezerwują porty usługi jako hostPort na węźle, więc są one planowane tylko tam, gdzie te porty są wolne. Jeśli nginx lub inne proxy zajmuje już port 80, pod pozostaje w stanie Pending, a usługa nigdy nie otrzymuje adresu zewnętrznego. kubectl -n kube-system describe pod svclb-... raportuje 0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports. Należy zwolnić port lub przeprowadzić ponowną instalację z flagą --disable=servicelb i przekierować ruch na NodePort, który usługa nadal przydziela.
Ile pamięci RAM wymaga k3s na VPS?
Dokumentowane minimum dla węzła typu server to 2 rdzenie i 2 GB RAM, co obejmuje k3s oraz jego wbudowane komponenty przed uruchomieniem własnych obciążeń. Profilowanie projektu wykazało, że węzeł server zajmuje 1,596 MB przy uruchomionym stosie monitoringu, dlatego należy traktować 2 GB jako wartość minimalną, a 4 GB jako pierwszy rozmiar zapewniający komfort pracy na jednym węźle. Należy zmierzyć zużycie zasobów własnej maszyny za pomocą free -h przed instalacją oraz ponownie po tym, jak każdy pod w kube-system uzyska status Running.
Czy można uruchomić Docker i k3s na tym samym VPS?
Tak, działają one niezależnie. k3s korzysta z własnego, wbudowanego containerd, więc obraz zbudowany za pomocą docker build nie jest dla niego widoczny, dopóki nie zostanie wykonane polecenie docker save myapp:0.1 | sudo k3s ctr images import -. Każde z tych rozwiązań tworzy również własne reguły iptables oraz własne sieci typu bridge. Należy monitorować całkowite zużycie pamięci, ponieważ Docker, k3s oraz uruchomione kontenery nie zmieszczą się na maszynie z 2 GB RAM.
Jak całkowicie usunąć k3s?
Należy uruchomić sudo /usr/local/bin/k3s-uninstall.sh na węźle typu server lub sudo /usr/local/bin/k3s-agent-uninstall.sh na agencie. Powoduje to zatrzymanie usługi, usunięcie magazynu danych, usunięcie danych wolumenów trwałych w lokalizacji /var/lib/rancher/k3s/storage oraz usunięcie dołączonych narzędzi. Przed wykonaniem operacji należy skopiować wszystkie istotne dane z maszyny, ponieważ proces jest nieodwracalny. Pozostałe interfejsy sieciowe cni0 lub flannel.1 znikną po kolejnym restarcie systemu.