Ile klastrów Kubernetesa to za mało, a ile za dużo? To pewnie zależy pod zastosowań, wielkości organizacji, jej struktury, polityki i wielu innych czynników.
Ja postanowiłem tym razem przyjrzeć się bliżej temu tematowi i pomóc Ci w odpowiednim wyborze przy projektowaniu lub rozbudowie Twojego środowiska.

Po co wiele

Zacznijmy od powodów, dla których potrzebnych jest wiele klastrów. Poniżej wymieniam najważniejsze według mnie.
Pierwszy to jednocześnie najważniejszy – izolacja środowisk. Ja nazywam to twardą izolacją, bo najskuteczniej oddziela środowiska developerskie od stage i produkcji.
Drugi powód to aktualizacje. Dotyczy to głównie nowych wersji Kubernetesa. O konieczności aktualizacji chyba nie muszę wspominać, a posiadanie wielu klastrów umożliwia wyłapanie większych wpadek spowodowanych np. przez zmiany w API oraz wyłączenie pewnych funkcjonalności jak swego czasu zastąpienie PodSecurityPolicy przez PodSecurity.
Trzeci to eksperymenty. Bez nich Twoje środowisko nie będzie mogło być usprawnianie przez dodawanie nowych funkcji. Te mogą nieść ze sobą ryzyko, a raczej nie chcesz, aby się zmaterializowało na produkcji. Ten element wspomaga też uczenie – bez tego utkniesz wraz z Twoimi zespołami w miejscu.
Czwarty to dostęp do API. Po części związane jest to z izolacją, ponieważ wiele klastrów umożliwia podział kto może się do nich połączyć. Ma to jednak też inne zastosowanie. Możliwe jest wówczas podzielenie klastrów na te, które umożliwiają podłączenie się bezpośrednie użytkownikom i takie, które na to nie zezwalają. Te ostatnie zarządzane są bowiem jedynie w stylu GitOps, a dostęp jest w trybie awaryjnym tylko dla wybranych.
Piąty powód to wysoka dostępność czy raczej Disaster Recovery. Dotyczy to głównie środowisk produkcyjnych o krytycznym znaczeniu. Jeśli redundancja komponentów control plane i odpowiedniej dystrybucji instancji aplikacji po węzłach jednego klastra nie wystarczy to potrzebujesz pójść krok dalej. Wkraczasz wówczas na pole środowisk multi-cluster w trybach od active-passive do active-active w ramach jednego dostawcy lub wielu oraz różnych lokalizacji geograficznych.

Tylko jeden

A po co komu więcej? Może jeden wystarczy? 🤔
Są sytuacje, gdy faktycznie pojedynczy klaster służy za wszystko od środowisk testowych po produkcję. Przemawia za tym przede wszystkim niższy koszt oraz prostota w utrzymaniu. To może mieć duże znaczenie w przypadku małych zespołów, gdzie ogarnianie wielu klastrów może zajmować zbyt wiele czasu.
Kolejnym przypadkiem może być też środowisko on-prem, gdzie instalacja kolejnych klastrów oraz jakakolwiek zmiana to dni lub tygodnie wymiany maili z osobami odpowiedzialnymi za serwery.
Czy da się na pojedynczym klastrze mieć wiele środowisk z produkcją włącznie? Owszem i Ci co widzieli część PRO mojego kursu wiedzą już, że możliwe jest zaimplementowanie tzw. miękkiej izolacji i nawet wydzielenie puli węzłów na poszczególne środowiska (moduł 7 lekcja 3 🙂).
Taki układ jest dobry na start, ale na dłuższą metę sprawia sporo problemów np. przy aktualizacjach Kubernetesa (szczególnie tych mniej “udanych”).

Dwa światy

Tak jak kiedyś dodanie kolejnego rdzenia procesora do jednordzeniowego serwera czyniło go o wiele szybszym (kolejne już nie przynosiły tak spektakularnej różnicy) tak rozdzielenie środowisk na dwa klastry robi zasadniczą różnicę.
Tworzysz wówczas dwa światy. Jeden nieprodukcyjny i drugi produkcyjny. Ten pierwszy możesz nazywać dev, test, stage lub nawet krainą swobody i rozpusty 😉 Ważne, aby eksperymenty tam prowadzone i wszelkie zmiany nie wpływały na działanie środowiska produkcyjnego.
Produkcja powinna być maksymalnie izolowana oraz aktualizowana tylko po testach przeprowadzanych na klastrze nieprodukcyjnym.
W tym układzie zalecany jest już GitOps, przynajmniej dla klastra produkcyjnego. To może być dobry wstęp do pełnego GitOpsa, ale równie dobrze klaster testowy może mieć poluzowane reguły dostępu umożliwiające swobodne eksperymentowanie ze zmianami.
Dwa klastry to już całkiem niezłe rozwiązanie, ale można wciąż lepiej i bezpieczniej!

Dedykowane usługi

Szczęśliwi ci którzy mogą w całości operować na chmurze publicznej, bowiem tam dostępnych jest mnóstwo usług bez konieczności zarządzania nimi. Ci którzy mają do dyspozycji tylko własne serwery na środowiskach on-prem stają przed kilkoma dylematami:

• Gdzie przechowywać obrazy kontenerów?
• Gdzie wysyłać Logi i w jaki sposób je przeglądać?
• Jaki serwer git przeznaczyć na repozytoria aplikacji oraz dedykowane dla podejścia GitOps?
• Skąd podłączać wolumeny dla aplikacji stanowych?

Często okazuje się, że brakuje w organizacji dedykowanych usług i konieczne jest postawienie ich od zera. Wtedy dedykowany klaster na te usługi może być bardzo dobrym rozwiązaniem. Za pomocą operatorów łatwo można postawić rejestr na obrazy, cały stack monitoringu i logowania, storage czy serwery git.
Ze względu na krytyczność takiego klastra musi on być otoczony szczególną opieką, gdyż od dostępności serwisów na nim chodzących zależy działanie pozostałych środowisk.To jest największe wyzwanie i też największy nakład pracy.
Taki klaster jest bardzo przydatny i jeśli jest on dobrze zaprojektowany oraz odpowiednio zarządzany może sprawić, że w Kubernetes na środowisku on-prem może być równie dobry jak w chmurze.

Klaster na dane

I znowu przypadek kiedy potrzebujemy dedykowanego klastra na dane dotyczy właściwie tylko środowisk on-prem. U dostawców chmury publicznej zamówienie wolumenu na dane to kwestia jednego żądania API i oczywiście płacenia za to czasem nawet słonych kwot.

Ale wracając do dedykowanego klastra to ma on pewne szczególne cechy. Przede wszystkim ze względu na potrzebę udostępniania danych składa się on głównie z węzłów zawierających po kilka dysków. Te w normalnych warunkach, na zwykłych klastrach nie są tak krytyczny, ponieważ węzły w tradycyjnych klastrach  przechowują dane głównie tymczasowo.
Oczywiście jeśli masz szczęście to może nie być potrzebny taki klaster jeśli w twoim środowisku istnieje już dedykowane rozwiązania sprzętowe z odpowiednimi sterownikami CSI dla kubernetesa.  Przewagą dedykowanego klastra może być jego uniwersalność, ponieważ może on udostępniać aplikacjom i usługom nie tylko storage blokowy, ale też system plików po NFS czy storage obiektowy kompatybilny z S3. 

Ile sobie drogi Panie/droga Pani zażyczy

Dla naprawdę dużych i krytycznych środowisk potrzeba czasem o wiele, wiele więcej klastrów niż do tej pory wymieniłem. I jest to niezależne od tego czy uruchamiasz to w całości w chmurze, na on–prem czy hybrydowo.
Może się okazać że środowisk nieprodukcyjnych może być kilka, kilkanaście lub nawet kilkaset. Każde z nich może być zarządzane przez oddzielne zespoły lub też centralnie przez predefiniowane zestawy konfiguracji wykorzystując Terraform lub Crossplane.
Mogą również istnieć klastry tymczasowe tworzone na żądanie w ramach różnego rodzaju testów w tym tych sprawdzających nowe wersje  kubernetesa i jego funkcjonalności.
Ciekawiej wygląda sprawa środowiska produkcyjnego, ponieważ może ono używać więcej niż jednego klastra. Jak wspomniałem na wstępie takie klastry mogą być utworzone u tego samego dostawcy chmury, u różnych i w oddzielnych geograficznie lokalizacjach.
W przypadku tak dużych środowisk konieczne jest już elastyczne zarządzanie klastrami co oznacza dla środowisk on–prem bazowanie na pewnym API do provisioningu (np. vSphere lub OpenStack) lub sprytne ogarnięcie tego na bare–metal (no bo czy na pewno potrzebujesz wirtualizacji?).
No i na koniec dla formalności wspomnę, że tutaj GitOps jest standardem i bez niego nie wyobrażam sobie sprawnego zarządzania taką liczbą klastrów.

Liczę, że zainteresowałem Cię tematem i kolejnym razem przy projektowaniu środowiska będziesz już bardziej świadomie dobierał układ klastrów do wymagań projektu oraz oczywiście budżetu.