Klaster Kubernetes
Jak utworzyć klaster Kubernetes, włączyć wysoką dostępność, pobrać kubeconfig, skalować workery i wdrażać z CI/CD.
W panelu uruchomisz lekki klaster Kubernetes (k3s) zgodny ze standardowym Kubernetes – działa kubectl i zwykłe manifesty. Węzły klastra to maszyny w sieci prywatnej Twojego projektu.
Tworzenie klastra
- W menu wybierz Kubernetes, a następnie Utwórz klaster.
- Wybierz Lokalizację.
- W sekcji Plan węzła wybierz rozmiar maszyn. Ten sam plan dotyczy wszystkich węzłów (masterów i workerów). Mniejszym aplikacjom wystarczy 4 GB RAM.
- W sekcji Węzły klastra ustaw liczbę workerów przyciskami – / + (minimum 1, domyślny limit to 10). Workery dodasz i usuniesz też później.
- Opcjonalnie włącz Wysoka dostępność (HA) – opis poniżej.
- Jeśli lokalizacja to oferuje, możesz włączyć Szyfrowany dysk (at-rest) dla dysków węzłów.
- W sekcji Szczegóły podaj Nazwę i wybierz Projekt – węzły łączą się po sieci prywatnej projektu.
- Kliknij Utwórz klaster.
Tworzenie trwa zwykle kilka minut. Klaster jest rozliczany godzinowo: cena to liczba węzłów razy cena planu (plus load balancery API w trybie HA).
Wysoka dostępność (HA)
Bez HA klaster ma jeden master. Po włączeniu HA powstają trzy mastery z wbudowanym etcd na różnych serwerach fizycznych, a przed nimi dwa niewielkie load balancery API (port TCP 6443). Awaria jednego mastera lub całego hosta nie zatrzymuje klastra, a kubectl łączy się dalej bez żadnych zmian po Twojej stronie. HA dolicza 2 dodatkowe mastery i 2 load balancery API – panel pokazuje pełną cenę przed utworzeniem.
Kubeconfig i połączenie z kubectl
Gdy master się uruchomi, aktywny stanie się przycisk Kubeconfig u góry strony klastra (jest też w zakładce Ustawienia). Pobrany plik nazywa się <nazwa-klastra>-kubeconfig.yaml.
export KUBECONFIG=./moj-klaster-kubeconfig.yaml
kubectl get nodes
Uwaga: Kubeconfig zawiera certyfikaty administratora. Traktuj go jak hasło – kto go ma, zarządza całym klastrem. Do automatyzacji używaj tokenów wdrożeniowych (poniżej).
Węzły i skalowanie
Zakładka Węzły pokazuje każdy węzeł z rolą (master, worker, API LB), statusem oraz adresem prywatnym i publicznym.
- Dodaj worker – dokłada nową maszynę do klastra.
- Ikona kosza przy workerze usuwa go; pody zostaną przełożone na pozostałe węzły. Klaster musi mieć co najmniej jeden worker.
- Mastera nie można usunąć osobno – usuwa się razem z całym klastrem.
Zakładka Metryki pokazuje wykresy użycia zasobów poszczególnych węzłów.
Udostępnianie aplikacji
Ruch HTTP(S) do aplikacji obsługuje wbudowany ingress (Traefik). W klastrze HA zakładka Load balancer pozwala dodatkowo wystawić dowolny port TCP:
Utwórz Service typu NodePort, np.:
kubectl expose deploy web --type=NodePort --port=80 kubectl get svc webOdczytaj przydzielony
nodePort(zakres 30000–32767).W zakładce Load balancer kliknij Dodaj regułę, wpisz Port publiczny (np. 443), NodePort i opcjonalny Opis.
Kliknij Zapisz i wgraj.
Port 6443 jest zarezerwowany dla API. Szyfrowanie TLS obsłuż w aplikacji lub ingressie. Domenę kieruj rekordem CNAME na adres aplikacji pokazany w tej zakładce – jest on osobny od adresu API używanego przez kubectl.
Wdrożenia z CI/CD
W zakładce CI/CD utworzysz tokeny wdrożeniowe – osobne konta usługi w klastrze, dzięki którym pipeline nie potrzebuje kubeconfig administratora.
- Kliknij Nowy token.
- Podaj Nazwę (np.
github-produkcja) i Namespace – zostanie utworzony, jeśli nie istnieje. - W Uprawnieniach wybierz Tylko ten namespace (zalecane) albo Cały klaster (administrator) – ten drugi tylko, gdy pipeline instaluje np. CRD lub operatory.
- Kliknij Utwórz token i od razu zapisz dane – token i kubeconfig widać tylko raz.
Możesz zapisać cały kubeconfig jako jeden sekret KUBECONFIG albo trzy sekrety: K8S_SERVER, K8S_CA, K8S_TOKEN. Przykład dla GitHub Actions:
- name: kubeconfig
run: |
mkdir -p ~/.kube
echo "${{ secrets.KUBECONFIG }}" > ~/.kube/config
- name: deploy
run: |
kubectl apply -f k8s/
kubectl -n default rollout status deployment/my-app
Gotowe przykłady dla GitHub Actions i GitLab CI znajdziesz w zakładce CI/CD. Przycisk Odwołaj natychmiast odbiera tokenowi dostęp.
Kopie zapasowe i usuwanie
W zakładce Ustawienia karta Kopie zapasowe pokazuje czas ostatniej kopii aplikacji i danych oraz stanu klastra (etcd). Jeśli kopie są włączone w danej lokalizacji, powstają automatycznie co 6 godzin i są przechowywane poza klastrem przez 7 dni. Jeżeli dostępna jest karta Migracja na inny host (failover), przycisk Odtwórz na innym hoście postawi klaster od nowa z ostatniej kopii – adres i kubeconfig zostają bez zmian, ale zmiany z ostatnich (do 6) godzin mogą przepaść.
Usuń klaster kasuje wszystkie węzły razem z danymi na ich dyskach. Operacji nie można cofnąć.
Wskazówka: Dane, które muszą przetrwać wszystko, trzymaj poza klastrem – w zarządzanej bazie danych lub w magazynie S3.