Edytuj

Udostępnij za pośrednictwem

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 swoich 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 natywne rozszerzenie klastra do usługi AKS. Rozszerzenia klastra zapewniają 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.

Przepływ danych dla tego scenariusza to:

  1. Deweloper zatwierdza zmiany konfiguracji w repozytorium GitHub.
  2. Platforma Flux wykrywa dryf konfiguracji w repozytorium Git i ściąga zmiany konfiguracji.
  3. Flux uzgadnia stan w klastrze Kubernetes.

Alternatywy dla scenariusza 1

  • Możesz używać platformy Flux z innymi repozytoriami Git, takimi jak Azure DevOps, GitLab i BitBucket.
  • Zamiast repozytoriów Git interfejs API platformy Flux Bucket definiuje źródło do tworzenia artefaktu dla obiektów z rozwiązań magazynu, takich jak zasobniki 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 system operacyjny w chmurze S, ale istnieją inne.
  • 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).

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 implementowanie ciągłej integracji/ciągłego wdrażania przy użyciu metodyki GitOps z rozwiązaniami 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. Dane przepływa przez scenariusz w następujący sposób:

  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 Azure Container Registry.
  4. Funkcja GitHub Actions aktualizuje plik wdrożenia manifestu kubernetes z bieżącą wersją obrazu opartą na numerze wersji obrazu kontenera w usłudze Azure Container Registry.
  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. GitOps z usługą Argo CD, repozytorium GitHub i usługą AKS

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

Pobierz plik programu Visio z tą architekturą.

Przepływ danych dla scenariusza 3

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.

Przepływ danych dla tego scenariusza to:

  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 na żywo klastra usługi AKS z żądanym stanem docelowym określonym w repozytorium Git. Argo CD raportuje i wizualizuje różnice, zapewniając jednocześnie funkcje 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 czynności. 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. Implementowanie ciągłej integracji/ciągłego wdrażania za pomocą usługi Argo CD, funkcji GitHub Actions i usługi AKS

Diagram przedstawiający implementowanie ciągłej integracji/ciągłego wdrażania przy użyciu usługi GitOps z usługą 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. Dane przepływa przez scenariusz w następujący sposób:

  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 Azure Container Registry.
  4. Funkcja GitHub Actions aktualizuje plik wdrożenia manifestu kubernetes z bieżącą wersją obrazu opartą na numerze wersji obrazu kontenera w usłudze Azure Container Registry.
  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/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. W tym artykule opisano niektóre typowe opcje używania metodyki GitOps razem z klastrem usługi AKS.

Zgodnie z zasadami usługi GitOps żądany stan systemu zarządzanego przez usługę GitOps musi być następujący:

  1. Deklaratywna: system zarządzany przez usługę GitOps musi mieć wyrażony deklaratywnie żądany stan. Deklaracja jest zwykle przechowywana w repozytorium Git.
  2. Wersjonowane i niezmienne: żądany stan jest przechowywany w sposób, który wymusza niezmienność i przechowywanie wersji oraz zachowuje pełną historię wersji.
  3. Automatycznie ściągane: agenci oprogramowania automatycznie ściągają deklaracje żądanego stanu ze źródła.
  4. Ciągłe uzgadnianie: agenci oprogramowania stale obserwują rzeczywisty stan systemu i próbują zastosować żądany stan.

W usłudze GitOps infrastruktura jako kod (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 po wdrożenia aplikacji deklaratywnie z manifestami. 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 najniższych uprawnień.

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. Kontrolery przyjęć, na przykład, 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 różnych zespołów, aby zapewnić im aktualny stan 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.

Jeśli chcesz wymusić, że tylko usługa GitOps może zmienić stan klastra, możesz ograniczyć bezpośredni dostęp do klastra. Istnieją różne sposoby, w tym kontrola dostępu oparta na rolach (RBAC) platformy Azure, kontrolery przyjęć i inne narzędzia.

Uruchamianie początkowej konfiguracji przy użyciu metodyki GitOps

Istnieje możliwość wdrożenia klastrów usługi AKS w ramach konfiguracji bazowej. Przykładem jest wdrożenie zestawu usług udostępnionych lub konfiguracji przed wdrożeniem obciążeń. Te udostępnione usługi mogą konfigurować dodatki usługi AKS, takie jak:

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 linii bazowej dla klastra usługi AKS sugeruje użycie metodyki GitOps do uruchamiania. Jeśli używasz rozszerzenia Flux, możesz uruchamiać klastry bardzo szybko 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 każdej organizacji, która chce mieć zalety wdrażania aplikacji i infrastruktury jako kodu z dziennikiem inspekcji każdej zmiany.

Usługa GitOps chroni dewelopera przed złożonością zarządzania środowiskiem kontenera. Deweloperzy mogą nadal pracować ze znanymi narzędziami, takimi jak Git, aby zarządzać aktualizacjami i nowymi funkcjami. W ten sposób usługa GitOps zwiększa produktywność deweloperów.

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 Microsoft Azure Well-Architected Framework.

Niezawodność

Niezawodność gwarantuje, że aplikacja może spełnić zobowiązania, które należy wykonać dla klientów. Aby uzyskać więcej informacji, zobacz Omówienie filaru niezawodności.

Jednym z kluczowych filarów niezawodności jest odporność. Celem odporności jest przywrócenie aplikacji do stanu pełnej funkcjonalności po wystąpieniu błędu. Jeśli klaster stanie się niedostępny, usługa GitOps może szybko utworzyć nowy klaster. 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 sygnatury wdrożenia.

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nadużyciami cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Omówienie filaru 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 (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 zadania 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. Użyj żądań ściągnięcia, aby wprowadzić zmiany i mieć co najmniej jedną inną osobę przeglądać każde żądanie ściągnięcia. Ponadto użyj żądania ściągnięcia do automatycznego sprawdzania.
  • Przegląd żądań ściągnięcia: wymagaj, aby żądania ściągnięcia miały co najmniej jednego recenzenta, aby wymusić zasadę 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. Ponadto zezwalaj na tylko podpisane zatwierdzenia, aby zapobiec zmianom.

Optymalizacja kosztów

Optymalizacja kosztów dotyczy sposobów zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Omówienie filaru optymalizacji kosztów.

  • W warstwie Bezpłatna usługa AKS oferuje 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.
  • 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, potrzebny jest plan zespołu. Aby uzyskać więcej informacji, zobacz stronę cennika usługi GitHub.
  • Usługa Azure DevOps oferuje warstwę bezpłatną, której można użyć 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 Omówienie filaru 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, po prostu wykonując operacje usługi Git. Wykres zatwierdzeń nadal zawiera wszystkie zatwierdzenia, dzięki czemu może pomóc w analizie pośmiertnej.

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

Poniższa lista zawiera informacje dotyczące wdrażania pięciu scenariuszy:

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

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

Następne kroki