Korzystanie z usługi Azure Kubernetes Fleet Manager w celu dostarczania nowoczesnych architektur GitOps (wersja zapoznawcza)

Dotyczy: ✔️ Fleet Manager z klastrem hubów

GitOps to preferowany model wdrażania aplikacji Kubernetes i konfiguracji klastra. Dzięki zdefiniowaniu żądanego stanu deklaratywnie i ciągłemu uzgadnianiu klastrów względem tego stanu usługa GitOps zapewnia spójność, audytowalność i prostotę operacyjną.

Jednak większość platform GitOps została pierwotnie zaprojektowana zgodnie z założeniem, że każdy klaster Kubernetes jest zarządzany niezależnie. W miarę rozwoju organizacji od kilku klastrów do setek lub tysięcy pojawiają się nowe wyzwania:

• Koordynowanie wdrożeń w wielu klastrach.
• Zarządzanie decyzjami dotyczącymi umieszczenia.
• Wymuszanie przepływów pracy zatwierdzania i kolejności wdrażania.
• Zmniejszenie duplikacji między repozytoriami i kontrolerami.
• Obsługa środowisk wielochmurowych i brzegowych.
• Unikanie wąskich gardeł związanych ze skalowaniem Git i kontrolera.

Azure Kubernetes Fleet Manager wprowadza warstwę orkiestracji wyższego poziomu powyżej poszczególnych klastrów. Zamiast zastępować narzędzia GitOps, takie jak Flux, Fleet Manager uzupełnia je, zajmując się kwestiami, które naturalnie pojawiają się w skali floty, w tym rozmieszczaniem, orkiestracją wdrożeń, zarządzaniem aktualizacjami i zarządzaniem środowiskami wieloklastrowymi. Rozwiązanie Fleet Manager zapewnia scentralizowane umieszczanie zasobów i bezpieczne funkcje orkiestracji aktualizacji wieloklastrowych zaprojektowane specjalnie dla dużych środowisk Kubernetes.

Wynikiem jest nowoczesna architektura platformy, w której usługa GitOps pozostaje odpowiedzialna za uzgadnianie klastra lokalnego, a usługa Fleet Manager zapewnia koordynację na poziomie floty.

Wyzwania związane z istniejącymi architekturami GitOps

Tradycyjne architektury GitOps zwykle są zgodne z tym podstawowym modelem:

W przypadku pojedynczego klastra ten model działa bardzo dobrze.

Chociaż są technicznie skalowalne, zespoły platform często napotykają:

• Duża liczba pętli uzgodnień.
• Wyzwania związane z fan-out repozytorium.
• Duża częstotliwość operacji pull u dostawców Git.
• Złożone potoki promowania.
• Niestandardowe narzędzia do stopniowego wdrażania.
• Trudności z koordynowaniem wdrożeń w różnych środowiskach.

W przypadku setek klastrów i środowisk często rozwija się to do następującej postaci:

W tej skali zespoły często muszą ręcznie dostroić kontrolery, granice repozytorium, ścieżki źródłowe i interwały synchronizacji, aby zapewnić stabilność systemu. Typowym wzorcem jest dzielenie repozytoriów, dodawanie nakładek dla zespołu lub ograniczanie ustawień kontrolera tylko po wystąpieniu wąskiego gardła lub problemu dryfu w środowisku produkcyjnym. Takie podejście tworzy obciążenie operacyjne, ponieważ architektura nie jest już prosta w obsłudze na dużą skalę. Znaczna część dostrajania odbywa się reaktywnie, gdy pojawia się pierwszy problem z niezawodnością lub wydajnością.

Narzędzia GitOps doskonale sprawdzają się w zapewnieniu, że pojedynczy klaster ostatecznie osiąga zamierzony stan. Są one mniej odpowiednie do pełnienia roli globalnego orkiestratora wdrożeń w setkach klastrów.

To rozróżnienie staje się coraz ważniejsze, ponieważ organizacje zwiększają liczbę obsługiwanych przez nie klastrów i wdrażają praktyki inżynierii platform oraz ciągłego dostarczania natywnego dla chmury.

Rozwijanie metodyki GitOps za pomocą usługi Fleet Manager

Rozwiązanie Fleet Manager radzi sobie z tymi wyzwaniami związanymi ze skalowaniem, oddzielając orkiestrację floty od rekonsyliacji na poziomie klastra, umożliwiając organizacjom zarządzanie lokowaniem wdrożeń, postępem wdrażania i zarządzaniem na poziomie floty przy jednoczesnym zachowaniu modelu GitOps, któremu zespoły już ufają.

Rozdzielenie obowiązków

Przydatną zasadą projektowania jest rozdzielenie obowiązków związanych z wdrażaniem na cztery warstwy:

W ramach tego modelu:

• Deweloperzy nadal korzystają z przepływów pracy GitOps.
• Flux pozostaje silnikiem uzgadniania.
• Fleet Manager określa, gdzie są uruchamiane obciążenia.
• Fleet Manager koordynuje postęp wdrażania.

Każdy komponent koncentruje się na tym, co robi najlepiej.

Włączanie kontrolerów GitOps w usłudze Fleet Manager

Po uruchomieniu kontrolerów GitOps w klastrze centrum Fleet Manager tradycyjny model GitOps zmieni się na:

W tym nowym podejściu:

• Pobierasz Git raz do klastra koncentratora.
• Rozmieszczanie zasobów usługi Fleet Manager obsługuje dystrybucję i modyfikuje konfigurację na podstawie wymagań.
• Każdy członek pobiera artefakty OCI lub wykresy helm ze skalowalnego repozytorium.
• Local Flux uzgadnia konfigurację na podstawie rozproszonych zasobów z usługi Fleet Manager.

Takie podejście znacznie zmniejsza:

• Zajętość sterownika.
• Obciążenie serwera Git.
• Pobieranie artefaktów.
• Potencjalne przeciążenia uzgadniania.

Rozwiązanie Fleet Manager zachowuje się jak sieć CDN natywna dla Kubernetes na potrzeby wdrożeń.

GitOps pozostaje mechanizmem rekonsyliacji na poziomie klastra

Fleet Manager nie próbuje zastąpić platformy Flux. Kontrolery w każdym klastrze członkowskim pozostają odpowiedzialne za:

• Przetwarzanie manifestów.
• Zarządzanie artefaktami wydania wdrożenia, takimi jak charty Helm lub artefakty OCI.
• Kolejność zależności.
• Wykrywanie dryfu.
• Uzgadnianie obciążenia.
• Monitorowanie stanu zdrowia.

Dla każdego klastra członkowskiego pętla uzgodnień lokalnych pozostaje taka sama. Takie podejście pozwala zachować istniejące inwestycje i uniknąć zakłócania ustanowionych modeli operacyjnych GitOps.

Fleet Manager staje się warstwą sterowania na poziomie floty

Usługa Fleet Manager wprowadza warstwę powyżej poszczególnych klastrów.

Teraz zamiast pytać: jak wdrożyć ten manifest?

Teams może zapytać: Które klastry powinny otrzymywać tę aplikację?

Rozwiązanie Fleet Manager zapewnia inteligentne umieszczanie zasobów na podstawie właściwości klastra, etykiet, regionów, dostępności zasobów i innych atrybutów na poziomie floty.

Flux na poziomie klastra akceptuje rozproszone zasoby i wdraża składniki aplikacji.

Zespoły platform mogą raz wyrazić intencje i pozwolić zasadom rozmieszczania określić odpowiednie cele.

Takie podejście eliminuje znaczne duplikacje między repozytoriami i definicjami wdrożenia.

Wsparcie dla Gitless GitOps

Ekosystem GitOps coraz częściej przechodzi w kierunku modeli dostarczania opartych na protokole OCI.

Architektura referencyjna D2 firmy Flux i szersze wysiłki branżowe zachęcają do rozdzielenia między:

• Tworzenie.
• Pakowanie.
• Dystrybucja.
• Uzgadnianie.

W tych modelach Git staje się systemem do tworzenia treści, a nie zależnością środowiska wykonawczego.

Nowoczesny przepływ pracy staje się:

Korzyści obejmują:

• Zmniejszone obciążenie serwera Git.
• Niezmienne, podpisane artefakty wdrażania.
• Lepsze przepływy pracy promocji.
• Ulepszone bezpieczeństwo łańcucha dostaw.
• Szybsze wdrażanie na dużą skalę.

Fleet Manager jest naturalnie zgodny z tym podejściem. Aplikacje można pakować do artefaktów OCI i dystrybuować niezależnie od repozytoriów Git, podczas gdy platforma Flux kontynuuje rekonsyliację na poziomie klastra. Takie podejście umożliwia organizacjom ewoluować od tradycyjnego GitOps skoncentrowanego na Git w kierunku gitless GitOps bez zastępowania modelu operacyjnego.

Przezwyciężenie tradycyjnych ograniczeń skalowania w usłudze GitOps

Duże środowiska GitOps często napotykają kilka ograniczeń.

Rozgałęzienie kontrolera

Wdrażanie aplikacji w setkach klastrów oznacza setki niezależnych rekonsyliacji.

Fleet umożliwia określanie docelowych klastrów za pomocą zasad rozmieszczania zamiast jawnego zarządzania poszczególnymi klastrami.

Złożoność promocji

Wiele organizacji korzysta ze struktur repozytorium, takich jak:

Awans często wymaga:

• Żądania ściągnięcia.
• Wybiera zmiany.
• Zarządzanie gałęzią.
• Synchronizacja repozytorium.

Rozwiązanie Fleet Manager umożliwia zespołom platformy zarządzanie postępem wdrażania jako kwestią wdrożenia, a nie kwestią topologii repozytorium.

Koordynacja środowisk wielochmurowych

Narzędzia GitOps w dużej mierze działają klaster po klastrze.

Rozwiązanie Fleet Manager jest przeznaczone do zarządzania klastrami Kubernetes w różnych regionach, chmurach i środowiskach lokalnych za pomocą jednej płaszczyzny sterowania.

Takie podejście zapewnia wspólną warstwę orkiestracji niezależnie od tego, gdzie działają klastry członkowskie.

Progresywne wdrożenia poza GitOps

Jedną z najważniejszych zalet rozwiązania Fleet Manager jest orkiestracja wdrożeń.

Tradycyjne narzędzia GitOps zwykle zapewniają:

• Uzgadnianie.
• Korekta dryfu.
• Stan wdrożenia.

Strategie wdrażania na dużą skalę często wymagają dodatkowych narzędzi.

Usługa Fleet Manager wprowadza strategie wdrażania wielokrotnego użytku przy użyciu:

• Etapy
• Grupy.
• Etapy zatwierdzania.
• Kontrola współbieżności.
• Zaplanowane wykonanie.
• Reguły automatycznego postępu.

Te możliwości zostały zaprojektowane pod kątem bezpiecznych operacji dla całej floty.

Example:

Każdy etap może obejmować zatwierdzenia, wstrzymania i kontrolę postępu na podstawie pomyślnego wdrożenia do klastrów w danym etapie.

Kontrolery GitOps nadal uzgadniają stan lokalnie, gdy wdrożenie trafi do klastra.

Kontrola rozmieszczania zasobów Fleet Manager określa, kiedy klastry odbierają wdrożenie.

Architektura odwołań

W tej architekturze:

• Git pozostaje procesem tworzenia.
• Charty OCI lub Helm stają się formatem dystrybucji.
• Flux pozostaje silnikiem uzgadniania.
• Fleet Manager staje się warstwą orkiestracji.

Conclusion

GitOps pozostaje najlepszym modelem rekonsyliacji platformy Kubernetes, ale operacje na skalę floty wprowadzają obawy wykraczające poza zakres tradycyjnych narzędzi GitOps.

Azure Kubernetes Fleet Manager uzupełnia, a nie zastępuje metodyki GitOps przez wprowadzenie rozmieszczania na poziomie floty, ładu i orkiestracji wdrożeń. Podczas gdy platforma Flux nadal zapewnia, że poszczególne klastry są zbieżne ze swoim żądanym stanem, Fleet Manager określa, gdzie powinny być uruchamiane aplikacje, jak wdrożenia są wykonywane w różnych środowiskach i jak organizacje bezpiecznie działają na dużą skalę.

Wynikowa architektura obsługuje zarówno tradycyjne przepływy pracy oparte na Gicie, jak i nowe wzorce GitOps bez użycia Gita, umożliwiając organizacjom skalowanie wdrażania aplikacji z kilku klastrów do setek lub tysięcy bez porzucenia zasad GitOps, które zapewniły powodzenie operacji w Kubernetes.

Następne kroki

• Poradnik: GitOps na skalę floty z użyciem Flux (wersja zapoznawcza).
• Instrukcje: wdrażanie wykresów Helm przy użyciu platformy Azure Kubernetes Fleet Manager i Flux (wersja zapoznawcza)
• Instrukcje: wdrażanie artefaktów OCI za pomocą usługi Azure Kubernetes Fleet Manager i Flux (wersja zapoznawcza).