Zarządzanie klastrami Kubernetes w środowisku multicloud

Sfragmentaryzowane narzędzia i pulpity nawigacyjne dla każdej chmury

Klaster GKE w GCP dla jednej jednostki biznesowej, EKS dla drugiej, lokalny klaster RKE2 dla regulowanego obciążenia, a teraz klaster OVHcloud dla obliczeń suwerennych w UE. Każdy z tych dostawców dostarcza własną konsolę, własny interfejs CLI, własny sposób działania. Brak globalnego wglądu w stan klastra, wydajność lub politykę bezpieczeństwa w każdym środowisku, tylko N dostawców i N zestawów narzędzi, z których każdy wymaga specjalistycznej wiedzy. 

Widoczność jest pierwszą ofiarą, a każde inne zadanie operacyjne staje się bez niej trudniejsze. Każda dodatkowa chmura zwielokrotnia obszar, który musi pokryć Twój zespół, a nic z tego nie czyni uruchomionego na niej obciążenia aplikacji bardziej niezawodnym.

Rozrost RBAC i dryft konfiguracji między klastrami

Zarządzana usługa Kubernetes każdego dostawcy ma własny model tożsamości i uprawnień, więc wiele chmur oznacza wiele modeli. Definiowanie spójnej polityki bezpieczeństwa dla inżyniera, programistów lub audytora oznacza powtarzanie tej samej konfiguracji w trzech lub czterech konsolach i składniach. Dryft nie jest tutaj ryzykiem, jest pewnością i jest wyzwaniem, które skaluje się najgorzej. Uprawnienie przyznane w jednym klastrze i zapomniane w innym to luka w zgodności, która ujawnia się podczas audytu, a nie wcześniej.

Dryft wykracza daleko poza uprawnienia. Reguły sieciowe, limity zasobów, izolacja obciążeń i reguły wstępu, które były spójne przy początkowej konfiguracji, po cichu rozbiegają się, gdy każdy klaster jest łatany, aktualizowany lub ręcznie dostrajany przez osobę pełniącą dyżur. Dryft w zarządzaniu bezpieczeństwem jest najbardziej kosztowną wersją: reguła utwardzania zastosowana w jednym klastrze i nigdy niepropagowana pozostaje niewidoczna, dopóki incydent lub audyt jej nie ujawni.

GitOps, który psuje się na granicy między chmurami

GitOps powinien zapewniać jedno źródło prawdy o tym, co i gdzie działa, oraz jeden potok ciągłego dostarczania dla każdego środowiska. W praktyce większość zespołów uruchamia oddzielne instancje Fleet lub ArgoCD dla każdej chmury lub utrzymuje potoki dla każdej chmury, z których każdy ma własne poświadczenia, logikę synchronizacji i obsługę błędów. Każdy dodany potok to kolejny punkt awarii. 

W momencie, gdy aplikacja musi być wdrażana spójnie w wielu środowiskach, jednocześnie na GKE w GCP, na EKS i lokalnie, obietnica pojedynczego repozytorium Git rozpada się na trzy równoległe potoki dostarczania, które zaczynają się różnić. Zarządzanie ruchem przebiega w ten sam sposób: równoważniki obciążenia, globalne trasowanie ruchu i polityka ruchu między klastrami są obsługiwane chmura po chmurze, zamiast jako jedna reguła sieciowa. Narzędzia zakotwiczone w hiperskalach również nie rozwiązują tego problemu w czysty sposób, ponieważ przesyłają dane telemetryczne i dane o uprawnieniach przez infrastrukturę w USA, nawet jeśli węzły robocze znajdują się w regionie UE, niezależnie od fizycznej lokalizacji sprzętu.

Ukryty koszt samodzielnego hostowania Ranchera

Samodzielny hosting jest jednym z rozwiązań wyzwania, jakim jest niezależność od chmury, ponieważ pojedyncze narzędzie skoncentrowane na Kubernetes zarządza wtedy każdym klastrem zgodnym z CNCF. Tworzy to nowe wyzwanie: teraz Twój zespół utrzymuje to narzędzie. Konfiguracja wysokiej dostępności, zapasowa baza danych, rotacja certyfikatów i kwartalne aktualizacje – wszystko to trafia do Twojego backlogu, oprócz klastrów znajdujących się poniżej. Samodzielnie hostowana warstwa zarządzania jest produktem samym w sobie, z infrastrukturą, która musi być odpowiednio zwymiarowana i łatana, z taką samą uwagą SRE, jak zasoby, którymi zarządza. Hostowane rozwiązanie usuwa tę warstwę.

Architektura: Manager w OVHcloud, agenci na każdym klastrze

Najpierw liczy się jedno rozróżnienie architektoniczne: OVHcloud nie zarządza bezpośrednio Twoimi klastrami w GKE, EKS ani AKS. Manager jest hostowany w OVHcloud, w wybranym przez Ciebie regionie UE, w jednej lokalizacji podlegającej jednej jurysdykcji. Lekki agent działający tylko w trybie wychodzącym uruchamia się na każdym z Twoich klastrów Kubernetes, gdziekolwiek się znajdują, i przesyła raporty zwrotne. Twoje istniejące klastry GKE, EKS, AKS lub lokalne pozostają tam, gdzie są, pod Twoimi własnymi kontami i na Twoją odpowiedzialność.

Każdy typ klastra, niezależnie od tego, czy jest zarządzany w chmurze, samodzielnie, czy jest natywny dla OVHcloud, pojawia się w tym samym interfejsie użytkownika, za tym samym API i może być udostępniany za pomocą tych samych zasobów Terraform. Zespoły, które standaryzują pracę w oparciu o Ansible lub Pulumi, zachowują również te przepływy pracy. Jeśli Twoje klastry współdzielą magazyn obrazów kontenerów, OVHcloud Managed Private Registry udostępnia rejestr oparty na Harbor, z którego każdy klaster może pobierać obrazy, niezależnie od tego, w jakiej chmurze lub regionie działa.

Wzorzec A: importuj istniejące klastry GKE, EKS, AKS lub lokalne

Jeśli już uruchamiasz klastry Kubernetes w GCP, AWS, Azure lub we własnych centrach danych, nie migrujesz niczego. Zainstaluj agenta w każdym istniejącym klastrze; otwiera on połączenie wyłącznie wychodzące do Managera, a klaster pojawia się w ciągu kilku minut. Nie ma zmiany platformy, zakłóceń we wdrożeniu ani zmian w sposobie, w jaki wdrażasz obecnie aplikacje w tym klastrze. Istniejące obciążenia działają dokładnie tak samo jak wcześniej.

Wzorzec B: udostępnij nowe klastry RKE2 lub k3s na dowolnej infrastrukturze

W przypadku nowych klastrów, zamiast importowanych, użyj Managera do udostępnienia RKE2, produkcyjnej dystrybucji Kubernetes wzmocnionej zgodnie z CIS-benchmark, lub k3s, lekkiej dystrybucji dostosowanej do wdrożeń brzegowych. Oba działają na dowolnej infrastrukturze z dostępnymi zasobami obliczeniowymi: lokalnymi serwerami typu bare metal, maszynami wirtualnymi lub instancjami IaaS u dowolnego dostawcy chmury, w dowolnym regionie. Przepływ pracy udostępniania, RBAC i scentralizowane monitorowanie są identyczne w każdym regionie, niezależnie od tego, gdzie fizycznie znajdują się wynikowe węzły.

Wzorzec C: dodaj OVHcloud MKS jako suwerenny klaster w UE

Trzecim wzorcem architektury jest rozwiązanie suwerenne: klaster natywny dla OVHcloud dla każdego obciążenia, które wymaga suwerenności w UE. Klastry OVHcloud Managed Kubernetes Service rejestrują się w tym samym Managerze co Twoje zaimportowane i udostępnione klastry i pojawiają się obok nich jako pełnoprawne obiekty, z tym samym interfejsem użytkownika, tym samym RBAC i tymi samymi potokami GitOps. W przeciwieństwie do klastrów w chmurach innych firm, OVHcloud w pełni zarządza samym płaszczyzną sterowania MKS, więc jest to jedyny typ klastra w Twoim środowisku, który nie obciąża operacyjnie płaszczyzny sterowania po Twojej stronie.

Ujednolicona kontrola dostępu w każdym klastrze, zdefiniuj raz, propaguj wszędzie

Zdefiniuj rolę raz i propaguj ją do każdego klastra Kubernetes, zamiast powtarzać to w trzech lub czterech oddzielnych konsolach. Użytkownicy logują się wszędzie za pośrednictwem tego samego dostawcy tożsamości. Każde przyznanie, cofnięcie i zmiana uprawnień użytkownika trafia do jednego spójnego dziennika audytu, co stanowi różnicę między przeglądem dostępu, który zajmuje popołudnie, a takim, który zajmuje tydzień.

Wdrożenie nowego inżyniera staje się jednym krokiem udostępniania, a nie listą kontrolną dla każdej chmury, a zgłoszenia dotyczące tego, kto ma do czego dostęp, przestają być projektami badawczymi. Dla organizacji uruchamiającej klastry w więcej niż jednej chmurze ten pojedynczy punkt kontrolny sprawia, że audyt zgodności jest wykonalny i pozwala wykazać zobowiązania dotyczące prywatności danych, które podjęła wobec własnych użytkowników.

GitOps dla wielu klastrów z Rancher Fleet

Fleet pozwala na jednokrotne zdefiniowanie aplikacji w repozytorium GitHub i synchronizowanie ich za pomocą selektora etykiet, na przykład dla wszystkich klastrów produkcyjnych w UE lub każdego środowiska testowego, zamiast utrzymywania oddzielnego potoku dla każdego dostawcy. Rozbieżności między tym, co zadeklarowano w Git, a tym, co jest uruchomione, są wykrywane i automatycznie uzgadniane w każdym klastrze w selektorze, co stanowi kontrolę wersji zastosowaną do infrastruktury, a nie tylko do kodu.

Jest to scentralizowane zarządzanie zarówno izolacją obciążeń, jak i polityką przestrzeni nazw: te same zasady obowiązują wszędzie, co jest jedynym sposobem na zapewnienie spójności w klastrach, które rzadko są sprawdzane. To bezpośrednie rozwiązanie problemu fragmentacji potoku dostarczania, z jednym źródłem prawdy i jednym silnikiem synchronizacji, niezależnie od tego, czy docelowe obciążenie działa w GKE, lokalnie, czy w OVHcloud MKS. Nasz przewodnik po zarządzaniu wieloma klastrami to miejsce, w którym można dowiedzieć się więcej o codziennej obsłudze po skonfigurowaniu infrastruktury oraz o tym, jak zespoły usprawniają wydania w różnych regionach.

Cykl życia klastra: aktualizacje, udostępnianie, wycofywanie za pośrednictwem interfejsu użytkownika, API lub Terraform

Aktualizacje wersji Kubernetes są aranżowane w każdym klastrze z konfigurowalnymi ustawieniami zwiększania wydajności, zamiast oddzielnych okien serwisowych dla każdego klastra i każdej chmury. Możesz zautomatyzować udostępnianie, aktualizowanie i wycofywanie za pomocą tego samego interfejsu użytkownika, tego samego API, tych samych zasobów Terraform lub istniejących przepływów pracy Ansible, uzyskując wgląd w bieżący stan bez przełączania konsol, nie polegając na niczym innym niż sam klaster.

Polecenia, które Twoi inżynierowie już znają, nadal działają identycznie. Zmień kontekst, a następnie wykonaj te same operacje:

kubectl create namespace payments-staging
kubectl get events --all-namespaces

Ta spójność zmienia zarządzanie cyklem życia z podatnego na błędy zadania w powtarzalny, zautomatyzowany proces. Eliminuje to złożoność, która w przeciwnym razie rosłaby wraz z każdym skomplikowanym wdrożeniem wieloregionalnym, pozwalając małemu zespołowi na efektywne zarządzanie dużą infrastrukturą na dużą skalę, od etapu programowania aż po produkcję.

Scentralizowane monitorowanie i logowanie za pomocą Prometheus i Grafana

Prometheus i Grafana integrują się w skali całej infrastruktury, zapewniając jeden ujednolicony stos obserwowalności dla wielu klastrów, zamiast różnych narzędzi i konfiguracji dla każdej chmury. Przechowywanie metryk i agregacja logów są włączane w ten sam sposób na każdym węźle w każdym regionie, a te same pulpity nawigacyjne, reguły alertów i przewodniki runbook mają zastosowanie niezależnie od tego, czy alert wystąpi w klastrze GKE, lokalnym klastrze RKE2, czy węźle OVHcloud MKS. Pytania dotyczące niezawodności otrzymują jedną odpowiedź zamiast jednej na dostawcę, a trendy użycia i ruchu stają się widoczne w jednym globalnym widoku.

Dlaczego warto dodać klaster suwerenny w UE (CLOUD Act, zależność od jednego dostawcy chmury)

Jeśli każdy uruchamiany przez Ciebie klaster znajduje się u amerykańskiego dostawcy chmury obliczeniowej, wszystkie dane płaszczyzny sterowania podlegają amerykańskiej ustawie CLOUD Act, niezależnie od fizycznej lokalizacji węzłów roboczych. Rozwiązaniem jest dodanie usługi OVHcloud Managed Kubernetes Service: klastra, którego płaszczyzna sterowania działa w regionie europejskim, bez amerykańskiej spółki macierzystej i bez strukturalnego narażenia na ustawę CLOUD Act.

Ma to znaczenie dla każdej organizacji, niezależnie od tego, jakiego narzędzia używasz do zarządzania pozostałymi klastrami. Takie podejście zmniejsza zależność od jednego dostawcy chmury w przypadku każdego krytycznego obciążenia i daje regulowanym zespołom z sektora opieki zdrowotnej, usług finansowych i sektora publicznego opcję jurysdykcji UE bez konieczności rezygnacji z klastrów, które już działają gdzie indziej.

MKS Free: dodaj klaster OVHcloud bez żadnych kosztów

MKS jest dostępny w darmowej wersji we wszystkich 14 regionach, bez konieczności podawania karty kredytowej, więc sprawdzenie suwerennego klastra w UE nic nie kosztuje. Działa on wewnątrz Twojego istniejącego projektu Public Cloud , obok wszelkich innych zasobów i węzłów, z których Twój zespół już korzysta. W przypadku obciążeń produkcyjnych MKS Standard działa w 3 strefach dostępności (3-AZ) w regionie Paryża w ramach umowy o poziomie usług (SLA) na poziomie 99,99%. Każda wersja rejestruje się dokładnie tak samo jak każdy inny klaster, z tym samym RBAC, tym samym GitOps i tym samym monitoringiem, w wybranym przez Ciebie regionie.

100% open source, zero uzależnienia od dostawcy: Twoją ścieżką wyjścia jest samodzielny hosting, a nie migracja

Rancher jest udostępniany na licencji Apache License 2.0, a dystrybucje RKE2 i k3s, które obsługuje, są projektami CNCF. OVHcloud nie prowadzi własnego, autorskiego forka ani nie dodaje zamkniętej warstwy funkcji: to identyczny projekt upstream, niezależny od chmury i hostowany dla Ciebie jako rozwiązanie zarządzane. Jeśli później zdecydujesz się na samodzielne zarządzanie, Twoją ścieżką wyjścia jest samodzielny hosting tego samego projektu, a nie migracja czy przepisywanie konfiguracji klastrów. Klastry pozostają nienaruszone w obu przypadkach, ponieważ nigdy nie były powiązane z niczym poza standardowym Kubernetesem i standardowymi agentami.