Klaster to grupa połączonych ze sobą maszyn — fizycznych serwerów albo maszyn wirtualnych — które działają razem i są zarządzane jak jeden, większy system. Z zewnątrz wygląda to tak, jakbyś rozmawiał z pojedynczym, mocnym komputerem, a pod spodem pracę dzieli między sobą kilka, kilkanaście albo i tysiące węzłów (node). Sens jest prosty: jedna maszyna ma swój sufit mocy i pewnego dnia się wywróci, a klaster pozwala dołożyć kolejne, rozłożyć ruch i przeżyć awarię jednego elementu bez budzenia całego zespołu w nocy.
Jak to działa i do czego służy
W klastrze maszyny komunikują się przez sieć i wspólnie realizują trzy rzeczy: równoważenie obciążenia (load balancing — ruch rozkłada się na wiele węzłów), skalowanie (dokładasz węzły, gdy rośnie ruch, i zdejmujesz, gdy spada) oraz wysoką dostępność (high availability — gdy jeden węzeł padnie, jego zadania przejmują pozostałe). Zwykle jest podział na control plane, który zarządza i decyduje, oraz węzły robocze, które wykonują faktyczną pracę.
Klaster sam pilnuje, ile kopii aplikacji ma działać, i jeśli któraś znika, odtwarza ją gdzie indziej. To różni go od pojedynczego serwera, gdzie awaria oznacza po prostu przestój.
Przykład z praktyki
Najbardziej znany dziś przykład to Kubernetes (k8s) — orchestrator klastrów kontenerów. Masz aplikację w kontenerze i chcesz, żeby zawsze działały trzy jej kopie rozłożone na różnych węzłach. Mówisz klastrowi, ile chcesz:
kubectl scale deployment moja-apka --replicas=3
Jeśli węzeł padnie, Kubernetes zauważy, że brakuje jednej kopii, i uruchomi ją na zdrowym węźle. Podobnie działa Elasticsearch, gdzie dane są dzielone na shardy i replikowane między węzłami, czy bazy w trybie klastra. Lokalnie do nauki odpalisz mini-klaster przez kind albo minikube, zanim ruszysz produkcję w chmurze.
Częste błędy i mity
Mit pierwszy: „klaster to znaczy, że nic nie padnie”. Nieprawda — pada tylko mniej i mniej boleśnie, pod warunkiem że masz parzyste minimum przemyślane. Stąd klasyk: w systemach z głosowaniem (etcd, ZooKeeper) potrzebujesz nieparzystej liczby węzłów (3, 5), żeby uniknąć split-brain — sytuacji, gdy klaster dzieli się na dwie połowy i każda uważa, że to ona jest główna. Drugi błąd: stawianie klastra „bo modne”, gdy aplikacji w zupełności wystarczy jeden VPS. Klaster to dodatkowa złożoność, monitoring i koszt — bierz go, gdy naprawdę potrzebujesz skali albo dostępności, nie dla samego CV.
Pojęcia powiązane
Warto znać przy okazji: węzeł (node), load balancer, high availability, skalowanie poziome i pionowe, Kubernetes, kontenery, orchestracja, replikacja oraz split-brain.