Udostępnij za pomocą

GitOps dla usługi Azure Kubernetes Service

Azure Kubernetes Service (AKS)
GitHub

GitOps to zestaw zasad dotyczących obsługi systemu oprogramowania i zarządzania nim. W tym artykule opisano techniki używania zasad GitOps do obsługi klastra usługi Azure Kubernetes Services (AKS) i zarządzania nim.

Logo Flux, Argo CD, OPA Gatekeeper, Kubernetes i Git są znakami towarowymi odpowiednich firm. Użycie tych znaków nie jest dorozumiane.

Architektura

Dwa operatory GitOps, których można używać z usługą AKS, to Flux i Argo CD. Są to projekty Cloud Native Computing Foundation (CNCF) i są szeroko używane. W poniższych scenariuszach przedstawiono sposoby ich używania.

Scenariusz 1. Metodyka GitOps z platformą Flux i usługą AKS

Diagram metodyki GitOps z rozwiązaniem Flux v2, GitHub i AKS.

Pobierz plik programu Visio z tą architekturą.

Przepływ danych dla scenariusza 1

Flux to rozszerzenie klastra, które integruje się natywnie z AKS. Rozszerzenie klastra zapewnia platformę do instalowania rozwiązań i zarządzania nimi w klastrze usługi AKS. Możesz użyć witryny Azure Portal, interfejsu wiersza polecenia platformy Azure lub skryptów infrastruktury jako kodu (IaC), takich jak terraform lub skrypty Bicep, aby włączyć rozwiązanie Flux jako rozszerzenie do usługi AKS. Za pomocą usługi Azure Policy można również zastosować konfiguracje platformy Flux w wersji 2 na dużą skalę w klastrach usługi AKS. Aby uzyskać więcej informacji, zobacz Wdrażanie aplikacji stale na dużą skalę przy użyciu konfiguracji platformy Flux w wersji 2 i usługi Azure Policy.

Platforma Flux może wdrażać manifesty platformy Kubernetes, wykresy Helm i pliki Kustomization w usłudze AKS. Flux to proces oparty na ankietach, dzięki czemu może wykrywać, ściągać i uzgadniać zmiany konfiguracji bez uwidaczniania punktów końcowych klastra agentom kompilacji.

W tym scenariuszu administratorzy platformy Kubernetes mogą zmieniać obiekty konfiguracji kubernetes, takie jak wpisy tajne i ConfigMaps, i zatwierdzać zmiany bezpośrednio w repozytorium GitHub.

Poniższy przepływ danych odpowiada poprzedniemu diagramowi:

  1. Deweloper zatwierdza zmiany konfiguracji w repozytorium GitHub.

  2. Flux wykrywa dryf konfiguracji w repozytorium Git i pobiera zmiany konfiguracji.

  3. Flux uzgadnia stan w klastrze Kubernetes.

Alternatywy dla scenariusza 1

  • Możesz użyć platformy Flux z innymi repozytoriami Git, takimi jak Azure DevOps, GitLab i Bitbucket.

  • Zamiast repozytoriów Git, Flux Bucket API definiuje źródło do tworzenia artefaktu dla obiektów z rozwiązań do przechowywania danych, takich jak bucket Amazon S3 i Google Cloud Storage. Możesz również użyć rozwiązania z interfejsem API zgodnym z usługą S3. Dwa przykłady to MinIO i Alibaba Cloud Object Storage Service (OSS), ale istnieją inne rozwiązania.

  • Możesz również skonfigurować platformę Flux względem kontenera usługi Azure Blob Storage jako źródła w celu utworzenia artefaktów. Aby uzyskać więcej informacji, zobacz GitOps Flux v2 configurations with AKS and Azure Arc-enabled Kubernetes (Konfiguracje usługi GitOps Flux w wersji 2 przy użyciu usług AKS i Kubernetes z obsługą usługi Azure Arc).

  • Platforma Flux v2 obsługuje wielodostępność, umożliwiając oddzielnym zespołom wdrażanie obciążeń w jednym udostępnionym klastrze Kubernetes. Wiele repozytoriów Git, z których każde reprezentuje innego najemcę, można zsynchronizować z klastrem. Aby zapewnić izolację obciążeń między zespołami, każdy zespół może mieć własną przestrzeń nazw lub przestrzenie nazw w klastrze usługi AKS, do których dostęp jest ograniczony za pośrednictwem zasad kontroli dostępu opartej na rolach (RBAC) platformy Kubernetes.

  • Platforma Flux może używać jednego klastra do zarządzania aplikacjami w tym samym klastrze lub w innych klastrach. Klaster centralny AKS z operatorem Flux zarządza ciągłym dostarczaniem aplikacji i obciążeń infrastruktury do wielu podrzędnych klastrów AKS.

Scenariusz 2. Implementowanie ciągłej integracji/ciągłego wdrażania za pomocą metodyki GitOps z rozwiązaniami Flux, GitHub i AKS

Diagram przedstawiający sposób implementowania CI/CD przy użyciu technologii GitOps z Flux, GitHub i AKS.

Pobierz plik programu Visio z tą architekturą.

Przepływ danych dla scenariusza 2

Ten scenariusz jest potokiem DevOps opartym na ściąganiu dla typowej aplikacji internetowej. Potok używa funkcji GitHub Actions do kompilacji. W przypadku wdrożenia używa platformy Flux jako operatora GitOps do ściągania i synchronizowania aplikacji.

Poniższy przepływ danych odpowiada poprzedniemu diagramowi:

  1. Kod aplikacji jest opracowywany przy użyciu zintegrowanego środowiska projektowego (IDE), takiego jak Visual Studio Code.

  2. Kod aplikacji jest zatwierdzany w repozytorium GitHub.

  3. Funkcja GitHub Actions tworzy obraz kontenera z kodu aplikacji i wypycha obraz kontenera do usługi Azure Container Registry.

  4. GitHub Actions aktualizuje plik wdrożenia manifestu Kubernetes z bieżącą wersją obrazu, opartą na numerze wersji obrazu kontenera w rejestrze kontenerów.

  5. Operator Flux wykrywa dryf konfiguracji w repozytorium Git i ściąga zmiany konfiguracji.

  6. Platforma Flux używa plików manifestu do wdrożenia aplikacji w klastrze usługi AKS.

Scenariusz 3. Metodyka GitOps z usługą Argo CD, repozytorium GitHub i usługą AKS

Diagram metodyki GitOps z usługą Argo CD, GitHub i AKS.

Pobierz plik programu Visio z tą architekturą.

Przepływ danych dla scenariusza 3

Argo CD można włączyć jako rozszerzenie dla klastra w usłudze AKS. W tym scenariuszu administrator platformy Kubernetes może zmienić obiekty konfiguracji kubernetes, takie jak wpisy tajne i ConfigMaps, i zatwierdzić zmiany bezpośrednio w repozytorium GitHub.

Poniższy przepływ danych odpowiada poprzedniemu diagramowi:

  1. Administrator platformy Kubernetes wprowadza zmiany konfiguracji w plikach YAML i zatwierdza zmiany w repozytorium GitHub.

  2. Argo CD pobiera zmiany z repozytorium Git.

  3. Argo CD uzgadnia zmiany konfiguracji w klastrze usługi AKS.

Dysk ARgo CD nie musi automatycznie synchronizować żądanego stanu docelowego z klastrem usługi AKS. Jest on implementowany jako kontroler Kubernetes, który stale monitoruje uruchomione aplikacje. Porównuje bieżący stan klastra AKS ze stanem docelowym określonym w repozytorium Git. Argo CD raportuje i wizualizuje różnice oraz udostępnia narzędzia do automatycznego lub ręcznego synchronizowania stanu na żywo z powrotem do żądanego stanu docelowego.

Argo CD udostępnia interfejs użytkownika oparty na przeglądarce. Służy do dodawania konfiguracji aplikacji, obserwowania stanu synchronizacji w odniesieniu do klastra i inicjowania synchronizacji z klastrem. Możesz również użyć wiersza polecenia Argo CD, aby wykonać te zadania. Zarówno interfejs użytkownika, jak i interfejs wiersza polecenia udostępniają funkcje umożliwiające wyświetlanie historii zmian konfiguracji i wycofywanie do poprzedniej wersji.

Domyślnie interfejs użytkownika argo CD i serwer interfejsu API nie są widoczne. Aby uzyskać do nich dostęp, zalecamy utworzenie kontrolera ruchu przychodzącego z wewnętrznym adresem IP. Możesz też użyć wewnętrznego modułu równoważenia obciążenia , aby je uwidocznić.

Alternatywy dla scenariusza 3

Każde repozytorium zgodne z usługą Git, w tym azure DevOps, może służyć jako repozytorium źródła konfiguracji.

Scenariusz 4: Wykorzystanie GitOps z Argo CD, GitHub Actions i AKS do wdrażania ciągłej integracji/ciągłego wdrażania

Diagram, który pokazuje implementację CI/CD za pomocą GitOps z Argo CD, GitHub i AKS.

Pobierz plik programu Visio z tą architekturą.

Przepływ danych dla scenariusza 4

Ten scenariusz jest potokiem DevOps opartym na ściąganiu dla typowej aplikacji internetowej. Potok używa funkcji GitHub Actions do kompilacji. W przypadku wdrożenia używa narzędzia Argo CD jako operatora GitOps do ściągania i synchronizowania aplikacji.

Poniższy przepływ danych odpowiada poprzedniemu diagramowi:

  1. Kod aplikacji jest opracowywany przy użyciu środowiska IDE, takiego jak Visual Studio Code.

  2. Kod aplikacji jest zatwierdzany w repozytorium GitHub.

  3. Funkcja GitHub Actions tworzy obraz kontenera z kodu aplikacji i wypycha obraz kontenera do usługi Container Registry.

  4. GitHub Actions aktualizuje plik wdrożenia manifestu Kubernetes z bieżącą wersją obrazu, opartą na numerze wersji obrazu kontenera w rejestrze kontenerów.

  5. Argo CD ściąga z repozytorium Git.

  6. Usługa Argo CD wdraża aplikację w klastrze usługi AKS.

Alternatywy dla scenariusza 4

Każde repozytorium zgodne z usługą Git, w tym azure DevOps, może służyć jako repozytorium źródła konfiguracji.

Szczegóły scenariusza

GitOps to zestaw zasad dotyczących obsługi systemu oprogramowania i zarządzania nim.

  • Używa kontroli źródła jako pojedynczego źródła prawdy dla systemu.

  • Stosuje ona rozwiązania programistyczne, takie jak kontrola wersji, współpraca, zgodność i ciągła integracja i ciągłe wdrażanie (CI/CD) do automatyzacji infrastruktury.

  • Można go zastosować do dowolnego systemu oprogramowania.

Metodyka GitOps jest często używana do zarządzania klastrem Kubernetes i dostarczania aplikacji.

Zgodnie z zasadami usługi GitOps żądany stan systemu zarządzanego przez usługę GitOps musi spełniać następujące kryteria:

  • Deklaracyjne: System zarządzany przez usługę GitOps musi mieć swój żądany stan wyrażony deklaratywnie. Deklaracja jest zwykle przechowywana w repozytorium Git.

  • Wersjonowane i niezmienne: Żądany stan jest przechowywany w sposób, który wymusza niezmienność i przechowywanie wersji oraz zachowuje pełną historię wersji.

  • Automatycznie ściągane: Agenci oprogramowania automatycznie ściągają deklaracje żądanego stanu ze źródła.

  • Stale uzgadniane: Agenci oprogramowania stale obserwują rzeczywisty stan systemu i próbują zastosować żądany stan.

W usłudze GitOps usługa IaC używa kodu do deklarowania żądanego stanu składników infrastruktury, takich jak maszyny wirtualne, sieci i zapory. Ten kod jest kontrolowany i możliwy do inspekcji.

Platforma Kubernetes opisuje wszystko, od stanu klastra do wdrożeń aplikacji deklaratywnie przy użyciu manifestów. Usługa GitOps dla platformy Kubernetes umieszcza żądany stan infrastruktury klastra pod kontrolą wersji. Składnik w klastrze, zwykle nazywany operatorem, stale synchronizuje stan deklaratywny. Takie podejście umożliwia przeglądanie i przeprowadzanie inspekcji zmian kodu wpływających na klaster. Zwiększa bezpieczeństwo poprzez wspieranie zasady najmniejszych uprawnień (PoLP).

Agenci GitOps stale uzgadniają stan systemu z żądanym stanem przechowywanym w repozytorium kodu. Niektórzy agenci GitOps mogą przywracać operacje wykonywane poza klastrem, takie jak ręczne tworzenie obiektów Kubernetes. Na przykład kontrolery wpływu wymuszają zasady na obiektach podczas operacji tworzenia, aktualizowania i usuwania. Można ich użyć, aby upewnić się, że wdrożenia zmieniają się tylko wtedy, gdy kod wdrożenia w repozytorium źródłowym ulegnie zmianie.

Możesz połączyć narzędzia do zarządzania zasadami i wymuszania przy użyciu metodyki GitOps, aby wymusić zasady i przekazać opinię na temat proponowanych zmian zasad. Możesz skonfigurować powiadomienia dla poszczególnych zespołów, aby otrzymywać informacje o bieżącym stanie usługi GitOps. Możesz na przykład wysyłać powiadomienia o sukcesach wdrożenia i niepowodzeniach uzgodnień.

GitOps jako pojedyncze źródło prawdy

Metodyka GitOps zapewnia spójność i standaryzację stanu klastra i może pomóc zwiększyć bezpieczeństwo. Możesz również użyć metodyki GitOps, aby zapewnić spójny stan w wielu klastrach. Na przykład usługa GitOps może stosować tę samą konfigurację w klastrach podstawowych i odzyskiwania po awarii (DR) lub w farmie klastrów.

Aby wymusić użycie metodyki GitOps jako jedynej metody zmiany stanu klastra, ogranicz bezpośredni dostęp do klastra. Aby ustawić tę konfigurację, użyj kontroli dostępu opartej na rolach (RBAC) platformy Azure, kontrolerów przyjęć lub innych narzędzi.

Uruchamianie początkowej konfiguracji przy użyciu metodyki GitOps

Czasami wdrożenie klastra AKS jest wymagane jako część konfiguracji bazowej. Na przykład może być konieczne wdrożenie usług udostępnionych lub konfiguracji na poziomie systemu przed wdrożeniem obciążeń aplikacji. Te usługi udostępnione mogą konfigurować następujące dodatki i narzędzia:

Flux można włączyć jako rozszerzenie stosowane podczas tworzenia klastra usługi AKS. Strumień może następnie uruchomić konfigurację punktu odniesienia w klastrze. Architektura bazowa klastra usługi AKS zaleca użycie metodyki GitOps do uruchamiania. Jeśli używasz rozszerzenia Flux, możesz uruchamiać klastry wkrótce po wdrożeniu.

Inne narzędzia i dodatki GitOps

Możesz rozszerzyć opisane scenariusze na inne narzędzia GitOps. Jenkins X to inne narzędzie GitOps, które zawiera instrukcje dotyczące integracji z platformą Azure. Narzędzia do dostarczania progresywnego, takie jak Flagger , umożliwiają stopniowe przenoszenie obciążeń produkcyjnych wdrożonych za pomocą metodyki GitOps.

Potencjalne przypadki użycia

To rozwiązanie przynosi korzyści organizacjom, które chcą wdrażać aplikacje i IaC oraz utrzymywać dziennik inspekcji każdej zmiany.

Usługa GitOps upraszcza zarządzanie kontenerami dla deweloperów, co zwiększa produktywność. Deweloperzy mogą nadal pracować ze znanymi narzędziami, takimi jak Git, aby zarządzać aktualizacjami i nowymi funkcjami.

Kwestie wymagające rozważenia

Te zagadnienia implementują filary platformy Azure Well-Architected Framework, która jest zestawem wytycznych, których można użyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Well-Architected Framework.

Niezawodność

Niezawodność pomaga zapewnić, że aplikacja może spełnić zobowiązania podjęte przez klientów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca niezawodności.

Jeśli klaster stanie się niedostępny, należy użyć metodyki GitOps w ramach tworzenia nowego klastra. Używa ono repozytorium Git jako pojedynczego źródła prawdy dla konfiguracji i logiki aplikacji platformy Kubernetes. Może ona tworzyć i stosować konfigurację klastra oraz wdrożenie aplikacji jako jednostkę skalowania i może ustanowić wzorzec sygnatur wdrożenia .

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nieprawidłowym użyciem cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca zabezpieczeń.

Dzięki podejściu GitOps indywidualni deweloperzy lub administratorzy nie uzyskują bezpośredniego dostępu do klastrów Kubernetes w celu stosowania zmian lub aktualizacji. Zamiast tego użytkownicy wypychają zmiany do repozytorium Git, a operator GitOps, taki jak Flux lub Argo CD, odczytuje zmiany i stosuje je do klastra. Takie podejście jest zgodne z najlepszymi rozwiązaniami w zakresie zabezpieczeń najniższymi uprawnieniami, nie dając zespołom DevOps uprawnień do zapisu w interfejsie API Kubernetes. W scenariuszach diagnostycznych lub rozwiązywania problemów można udzielić uprawnień klastra przez ograniczony czas w zależności od przypadku.

Oprócz konfigurowania uprawnień repozytorium rozważ zaimplementowanie następujących środków zabezpieczeń w repozytoriach Git, które są synchronizowane z klastrami usługi AKS:

  • Ochrona gałęzi: chroń gałęzie reprezentujące stan klastrów Kubernetes przed wypchnięciem zmian bezpośrednio do nich. Wykorzystaj wnioski o scalenie (PRs), aby wprowadzać zmiany, i upewnij się, że każdą prośbę przejrzała co najmniej jedna inna osoba. Należy również użyć pull requestów do automatycznego sprawdzania.

  • Przegląd PR: Wymagaj, aby wezwania do pobrania miały co najmniej jednego recenzenta, aby zapewnić przestrzeganie zasady czterech oczu. Możesz również użyć funkcji właścicieli kodu usługi GitHub, aby zdefiniować osoby lub zespoły odpowiedzialne za przeglądanie określonych plików w repozytorium.

  • Niezmienna historia: zezwalaj tylko na nowe zatwierdzenia na podstawie istniejących zmian. Niezmienna historia jest szczególnie ważna w celach inspekcji.

  • Dalsze środki zabezpieczeń: wymagaj od użytkowników usługi GitHub aktywowania uwierzytelniania dwuskładnikowego. Zezwalaj tylko na zatwierdzenia podpisane, aby zapobiec zmianom.

Optymalizacja kosztów

Optymalizacja kosztów koncentruje się na sposobach zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca optymalizacji kosztów.

  • Warstwa bezpłatna usługi AKS zapewnia bezpłatne zarządzanie klastrami. Koszty są ograniczone do zasobów obliczeniowych, magazynu i sieci używanych przez usługę AKS do hostowania węzłów. Warstwa bezpłatna usługi AKS nie obejmuje umowy dotyczącej poziomu usług (SLA) i nie jest zalecana w przypadku obciążeń produkcyjnych.

  • Usługa GitHub oferuje bezpłatną usługę, ale do korzystania z zaawansowanych funkcji związanych z zabezpieczeniami, takich jak właściciele kodu lub wymagane recenzenci, potrzebujesz planu zespołu. Aby uzyskać więcej informacji, zobacz Cennik usługi GitHub.

  • Usługa Azure DevOps udostępnia warstwę bezpłatną, której można używać w niektórych scenariuszach.

  • Koszty możesz szacować za pomocą kalkulatora cen platformy Azure.

Doskonałość operacyjna

Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i działają w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Lista kontrolna projektu dotycząca doskonałości operacyjnej.

Metodyka GitOps może zwiększyć produktywność metodyki DevOps. Jedną z najbardziej przydatnych funkcji jest możliwość szybkiego wycofywania zmian, które zachowują się nieoczekiwanie, wykonując operacje git. Wykres zatwierdzeń nadal zawiera wszystkie zatwierdzenia, dzięki czemu może pomóc w analizie retrospektywnej.

Zespoły GitOps często zarządzają wieloma środowiskami dla tej samej aplikacji. Zazwyczaj istnieje kilka etapów aplikacji, które są wdrażane w różnych klastrach Kubernetes lub przestrzeniach nazw. Repozytorium Git, które jest pojedynczym źródłem prawdy, pokazuje, które wersje aplikacji są obecnie wdrażane w klastrze.

Wdrażanie scenariusza

Aby uzyskać więcej informacji na temat wdrażania pięciu scenariuszy, zobacz następujące zasoby:

  • Scenariusz 1: Aby uzyskać wskazówki dotyczące używania metodyki GitOps z rozwiązaniem Flux w wersji 2 do wdrażania aplikacji w usłudze AKS, zobacz Samouczek: wdrażanie aplikacji przy użyciu metodyki GitOps z rozwiązaniem Flux w wersji 2. Aby zapoznać się z przykładem użycia rozszerzenia Flux do uruchamiania wdrożenia klastra usługi AKS, zobacz implementację referencyjną punktu odniesienia usługi AKS.

  • Scenariusz 2: Aby uzyskać wskazówki dotyczące używania metodyki GitOps z rozwiązaniem Flux v2 w usłudze AKS do wdrażania aplikacji i implementowania ciągłej integracji/ciągłego wdrażania, zobacz Samouczek: implementowanie ciągłej integracji/ciągłego wdrażania za pomocą usługi GitOps (Flux v2).

  • Scenariusze 3 i 4: Aby uzyskać szczegółowe wskazówki dotyczące wdrażania przykładowego obciążenia przy użyciu Argo CD i AKS, zobacz scenariusz ciągłej integracji/ciągłego wdrażania w trybie pull w ramach podstawowej automatyzacji AKS.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główny autor:

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki