Serwer cloud dla Kubernetes w Europie
Kubernetes to standardowa platforma orkiestracji dla skonteneryzowanych obciazen w skali. Dobre dzialanie wymaga więcej niz tylko instalacji k8s - potrzebujesz wystarczajacego sprzetu na węzeł, niezawodnych sieci między wezlami i zrozumienia, jak wyglada minimalnie zywy klaster.
Hosting klastra Kubernetes w Europie jest praktycznym wymogiem, jesli Twoi użytkownicy lub dane sa tutaj. Prywatne sieci o niskiej latencji między wezlami, zgodność z RODO i fizyczna bliskosc Twojego zespołu inzynierskiego faworyzuja hosting w UE.
Dlaczego hosting w UE ma znaczenie dla Kubernetes
Klaster Kubernetes to system rozproszony. Komponenty planu sterowania stale komunikuja sie z wezlami roboczymi. Latencja sieci między wezlami bezpośrednio wplywa na stabilność klastra. Etcd wymaga zapisów z niska latencja, aby zachować spojnosc.
Umieszczenie wszystkich węzłów w tym samym centrum danych w UE utrzymuje latencje między wezlami poniżej 1 ms.
Minimalne wymagania serwera
Kubernetes ma realne wymagania sprzetowe.
Dla wezla planu sterowania:
- RAM: minimum 4 GB (8 GB zalecane dla klastrów z więcej niz 10 pracownikami)
- CPU: minimum 2 rdzenie (zalecane 4 rdzenie)
- Dysk: 40 GB SSD
Dla każdego wezla roboczego:
- RAM: minimum 4 GB na węzeł
- CPU: minimum 2 rdzenie na węzeł
- Dysk: 40 GB SSD na węzeł
Minimalna konfiguracja gotowa do produkcji to 1 węzeł planu sterowania plus 2 wezly robocze.
Zalecana konfiguracja DCXV
Instancje cloud DCXV na https://dcxv.com/data-center#cloud zaczynaja sie od 15 EUR/miesiąc. Dla 3-wezlowego klastra Kubernetes, trzy instancje z 4 GB RAM i 4 vCPU każda to rozsadny punkt wyjscia.
Instancje cloud DCXV w tym samym centrum danych dzieląc prywatna sieć z bardzo niska latencja między instancjami. Wsparcie inżynierów 24/7 jest wlaczone bez dodatkowych kosztów.
Dla większych klastrów dedykowane serwery DCXV zaczynaja sie od 49 EUR/miesiąc.
Przewodnik konfiguracji
Wdrozenie klastra k3s na trzech instancjach DCXV:
# Na wezle planu sterowania: zainstaluj k3s
curl -sfL https://get.k3s.io | sh -
# Pobierz token dolaczenia z planu sterowania
cat /var/lib/rancher/k3s/server/node-token
# Na każdym wezle roboczym: dołącz do klastra
curl -sfL https://get.k3s.io | K3S_URL=https://<control-plane-ip>:6443 K3S_TOKEN=<token> sh -
# Sprawdz, ze wszystkie wezly sa gotowe
kubectl get nodes
Ile węzłów warstwy sterowania
To decyzja, którą trzeba podjąć przed uruchomieniem czegokolwiek na klastrze, bo etcd utrzymuje kworum, a kworum wymaga większości. Drugi wiersz jest tym nieoczywistym:
| Warstwa sterowania | Przetrwa utratę | Kworum wymaga | Wybierz, gdy |
|---|---|---|---|
| 1 węzeł | Niczego - API znika | 1 z 1 | Rozwój, CI, staging, wszystko, co da się odtworzyć |
| 2 węzły | Niczego, a kosztuje dwa razy więcej | 2 z 2 | Nigdy - jest ściśle gorsze niż jeden węzeł |
| 3 węzły | Jeden węzeł, bez utraty zapisów | 2 z 3 | Produkcja, i najmniejsza, która zasługuje na to słowo |
| 5 węzłów | Dwa węzły | 3 z 5 | Duże klastry albo gdy może padnąć cała szafa |
Dwa węzły to pułapka: przy parzystej liczbie nie ma większości, więc utrata któregokolwiek położy serwer API tak samo jak jeden węzeł, a zapłaciłeś podwójnie. Z workerami jest odwrotnie - to bydło, dodawaj je i usuwaj swobodnie, ich liczba niczego nie podtrzymuje.
Oczekiwana wydajność
Na 3-wezlowym klastrze k3s z instancjami 4 GB / 4 vCPU:
- Latencja planowania podów poniżej 2 sekund dla typowych obciazen
- Przepustowosc sieci między podami 1-5 Gbps w tym samym centrum danych
- Ingress obslugujacy 1 000-3 000 zapytań HTTP na sekunde
- Czasy odpowiedzi API planu sterowania poniżej 50 ms
- Latencja zapisu etcd poniżej 5 ms z przechowywaniem SSD
To oczekiwania dla sprzętu tej klasy, a nie pomiary z naszego laboratorium. Traktuj je jako punkt wyjścia do doboru rozmiaru i zmierz własne obciążenie: realne liczby zależą od twoich danych, zapytań i tuningu znacznie bardziej niż od dostawcy.
