Panel klienta →

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

  1. W menu wybierz Kubernetes, a następnie Utwórz klaster.
  2. Wybierz Lokalizację.
  3. 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.
  4. 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.
  5. Opcjonalnie włącz Wysoka dostępność (HA) – opis poniżej.
  6. Jeśli lokalizacja to oferuje, możesz włączyć Szyfrowany dysk (at-rest) dla dysków węzłów.
  7. W sekcji Szczegóły podaj Nazwę i wybierz Projekt – węzły łączą się po sieci prywatnej projektu.
  8. 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:

  1. Utwórz Service typu NodePort, np.:

    kubectl expose deploy web --type=NodePort --port=80
    kubectl get svc web
    
  2. Odczytaj przydzielony nodePort (zakres 30000–32767).

  3. W zakładce Load balancer kliknij Dodaj regułę, wpisz Port publiczny (np. 443), NodePort i opcjonalny Opis.

  4. 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.

  1. Kliknij Nowy token.
  2. Podaj Nazwę (np. github-produkcja) i Namespace – zostanie utworzony, jeśli nie istnieje.
  3. W Uprawnieniach wybierz Tylko ten namespace (zalecane) albo Cały klaster (administrator) – ten drugi tylko, gdy pipeline instaluje np. CRD lub operatory.
  4. 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.

Nie znalazłeś odpowiedzi? Napisz do nas z panelu klienta — pomożemy.