Jak oszczędzać zasoby i czas przy uruchamianiu dziesiątek klastrów OpenShift

Każdy, kto wdrożył Kubernetes lub OpenShift w środowisku produkcyjnym, zna ten ból. Chcesz uruchomić mały izolowany klaster do staging lub dla oddzielnego zespołu, ale wdrożenie co najmniej trzech węzłów dla węzłów master z etcd i kontrolerami jest przesadą. Jeśli potrzebujesz dziesięciu, trzydziestu lub stu klastrów, rachunki za chmurę szybko stają się astronomiczne, a czas tworzenia kolejnego środowiska rozciąga się na dziesiątki minut.

Inżynierowie Red Hat natrafili na ten sam problem i udostępnili rozwiązanie jako open source. Projekt nazywa się HyperShift (lub Hosted Control Planes). W istocie jest to warstwa, która przenosi płaszczyznę kontrolną klastra z oddzielnych węzłów do zwykłych kontenerów w centralnym klastrze zarządzającym.

Przyjrzyjmy się, jak to działa i kto na tym korzysta.

Główny fokus architektoniczny

W klasycznej konfiguracji OpenShift lub Kubernetes każdy klaster ma własne dedykowane maszyny wirtualne lub fizyczne dla serwera API, etcd, kontrolerów i schedulera. Płacisz za te węzły nawet jeśli klaster jest w większości bezczynny.

HyperShift oddziela płaszczyznę kontrolną od węzłów roboczych.

Masz jeden duży klaster zarządzający. Gdy musisz utworzyć nowy klaster OpenShift dla użytkowników lub zespołów deweloperskich, HyperShift wdraża komponenty zarządzające nowego klastra — etcd, kube-apiserver, openshift-apiserver — jako standardowe kontenery (Deployment i StatefulSet) bezpośrednio w klastrze zarządzającym.

Tymczasem węzły robocze są tworzone oddzielnie tam, gdzie ich potrzebujesz: w AWS, Azure lub na bare metal. Łączą się z serwerem API działającym jako kontener w infrastrukturze zarządzającej.

Dlaczego zmieniać znajome podejście

Jeśli zarządzasz wieloma klastrami, korzyści są natychmiast widoczne w trzech obszarach.

Po pierwsze — efektywność kosztowa. Zamiast kupować co najmniej trzy VM dla węzłów master dla każdego indywidualnego klastra, wykorzystujesz zasoby istniejącego klastra zarządzającego. W rezultacie dziesiątki płaszczyzn kontrolnych działają na jednej puli zasobów, osiągając znacznie gęstsze pakowanie.

Po drugie — szybkość aprowizacji infrastruktury. Bootstrapping pełnego węzła z systemem operacyjnym, konfiguracją etcd i inicjalizacją komponentów trwa od 15 do 45 minut. Kontenery płaszczyzny kontrolnej w HyperShift uruchamiają się w ciągu minut, a nawet sekund. To całkowicie zmienia podejście do środowisk dev/test: klaster staje się tymczasowym zasobem, który łatwo uruchomić na potrzeby zadania i szybko usunąć.

Po trzecie — rozdzielenie odpowiedzialności i bezpieczeństwo. Deweloperzy i aplikacje mają dostęp tylko do swoich węzłów roboczych i serwera API. Nie mają fizycznego ani sieciowego dostępu do maszyn uruchamiających płaszczyznę kontrolną lub etcd. Zespół operacyjny centralnie aktualizuje i monitoruje wszystkie serwery API w jednym miejscu.

Jak to wygląda w praktyce

HyperShift utrzymuje 100% kompatybilność ze standardowym API Kubernetes i narzędziami OpenShift Container Platform (OCP). Z perspektywy dewelopera lub pipeline'u CI/CD utworzony klaster jest nie do odróżnienia od zwykłego: otrzymujesz standardowy kubeconfig i pracujesz przez kubectl lub oc.

Zarządzanie odbywa się za pomocą narzędzia CLI hypershift lub przez Custom Resources (CRD), co idealnie wpisuje się w podejścia GitOps jak ArgoCD.

Oto przykład tworzenia klastra w AWS przez CLI:

hypershift create cluster aws \
  --name dev-cluster \
  --node-pool-replicas 2 \
  --base-domain example.com \
  --pull-secret /path/to/pull-secret.json \
  --aws-creds /path/to/aws-credentials

Pod maską polecenie utworzy CRD HostedCluster i NodePool. HyperShift uruchomi kontenery płaszczyzny kontrolnej w klastrze zarządzającym, zapewni parę instancji EC2 w AWS dla węzłów roboczych i połączy je ze sobą.

Pod maską i niuanse

Projekt jest napisany w Go i aktywnie rozwijany przez zespół OpenShift. Repozytorium ma już ponad 500 forków, choć gwiazdki są wciąż stosunkowo nieliczne — nieco ponad pięćset. To dlatego, że HyperShift przez długi czas był wewnętrzną technologią Red Hat dla usługi ROSA (Red Hat OpenShift Service on AWS), a teraz stopniowo staje się standardem dla instalacji on-premises i multi-cloud.

Ważne funkcje obejmują:

• Pełna izolacja między klastrem zarządzającym a obciążeniami klientów.
• Wsparcie dla wdrażania węzłów roboczych u różnych dostawców: AWS, Azure, KubeVirt, Bare Metal.
• Ujednolicony wektor aktualizacji. Aktualizacja wersji OpenShift dla płaszczyzny kontrolnej może być przeprowadzona niezależnie przez zmianę wersji w CRD bez natychmiastowego restartu wszystkich węzłów roboczych.

Czy są jakieś pułapki? Oczywiście. Klaster zarządzający staje się pojedynczym punktem awarii dla płaszczyzn kontrolnych wszystkich twoich klastrów klientów. Jeśli klaster zarządzający przestanie działać, usługi działające na węzłach roboczych będą nadal działać, ale zarządzalność zostanie utracona do czasu przywrócenia infrastruktury. Dlatego wymagania dotyczące niezawodności klastra zarządzającego i kopii zapasowych etcd są podwyższone.

Kto powinien się temu przyjrzeć

HyperShift nie jest konieczny, jeśli masz jeden monolityczny klaster dla całej firmy. Ale staje się ratunkiem, jeśli:

• Budujesz platformę dla wewnętrznych zespołów i chcesz zapewnić izolowane klastry na żądanie.
• Sprzedajesz rozwiązanie SaaS oparte na Kubernetes z fizycznym rozdzieleniem klientów.
• Masz dość płacenia za bezczynne węzły master w chmurach publicznych.

Możesz wypróbować projekt korzystając z oficjalnej dokumentacji na hypershift.pages.dev. Będziesz potrzebować istniejącego klastra OpenShift 4.x jako klastra zarządzającego oraz dostępu do AWS lub lokalnych VM do tworzenia węzłów roboczych.