Opublikowano · Zaktualizowano
Stałe i eksperymentalne komponenty mojego labu K3s
To mój prywatny, niekomercyjny homelab, działający od około sierpnia 2025 na trzech VPS-ach z Ubuntu Server 24.04. Działają na nim prawdziwe workloady, ale nie jest to środowisko produkcyjne klienta. Największym wyzwaniem było dotąd oddzielenie tego, co faktycznie utrzymuję, od tego, co tylko testowałem.
- K3s
- Kubernetes
- Terraform
- Helm
- Ingress
- homelab
Baseline, który utrzymuję
Klaster ma jeden węzeł control plane i dwa workery. Terraform stawia bazową infrastrukturę, a K3s, Helm, Ingress i local storage to konfiguracja, którą stale utrzymuję.
Wybrałem K3s, bo ma mniejszy narzut i niższy próg wejścia niż pełny Kubernetes, sensowne ustawienia domyślne, a przy tym daje API Kubernetesa i ekosystem Helma. Przy jednym węźle control plane to nie jest konfiguracja wysokiej dostępności i tak jej nie przedstawiam.
Eksperymenty trzymane osobno
Osobno testowałem Cilium, cert-manager, sterownik Hetzner CSI, Argo CD, Flux i Ansible. Część z nich instalowałem na czas jednego eksperymentu i potem usuwałem, więc żaden nie należy do baseline’u.
Dzięki temu mogę porównać zmianę z konfiguracją K3s, Helm, Ingress i local storage, zanim cokolwiek dodam na stałe. Łatwiej mi też uczciwie powiedzieć, co utrzymywałem, a z czym tylko eksperymentowałem.
Zakres labu
W labie zajmuję się provisioningiem, utrzymaniem klastra, wdrożeniami, eksperymentami ze storage i siecią oraz troubleshootingiem, a po nieudanych eksperymentach odbudowuję środowisko. Służy do sprawdzania takich zmian poza systemami komercyjnymi, a nie do odwzorowania platformy enterprise. Stąd też znam Terraform; w komercyjnej produkcji go nie używałem.