Udostępnij za pośrednictwem

Dziedziny ciągłej integracji/ciągłego wdrażania i usługi GitOps z włączoną usługą Kubernetes z obsługą usługi Azure Arc

  • Artykuł

Jako konstrukcja natywna dla chmury platforma Kubernetes wymaga natywnego dla chmury podejścia do wdrażania i operacji. Za pomocą metodyki GitOps deklarujesz żądany stan wdrożeń opartych na aplikacji w plikach przechowywanych w repozytoriach Git. Aplikacje mają obiekty Kubernetes potrzebne do uruchomienia, które mogą obejmować wdrożenia, narzędzia Horizontal-Pod-Autoscalers, usługi i konfigurację Mapy. Operatory kubernetes działają w klastrach i stale uzgadniają stan każdego klastra z żądanym stanem zadeklarowanymi w repozytorium Git. Te operatory ściągają pliki z repozytoriów Git i stosują żądany stan do klastrów. Operatorzy stale zapewniają również, że klaster pozostaje w żądanym stanie.

Implementowanie metodyki GitOps umożliwia:

  • Popraw ogólną widoczność stanu i konfiguracji klastra Kubernetes.
  • Masz prostą historię inspekcji i wersji zmian w klastrze za pomocą historii zmian usługi Git, która pokazuje, kto dokonał zmian, kiedy te zmiany zostały wprowadzone i dlaczego.
  • Automatycznie popraw dryf, który może wystąpić w klastrze.
  • Wycofaj konfigurację platformy Kubernetes z poprzednią wersją za pomocą poleceń przywracania lub wycofywania usługi Git. Ponowne tworzenie wdrożenia klastra w scenariuszach odzyskiwania po awarii staje się również szybkim, prostym procesem, ponieważ wymagana konfiguracja klastra Kubernetes jest przechowywana w usłudze Git.
  • Zwiększ bezpieczeństwo, zmniejszając liczbę kont usług wymaganych do posiadania uprawnień wdrożenia do klastra.
  • Zaimplementuj potok ciągłej integracji/ciągłego wdrażania na potrzeby wdrażania aplikacji w klastrze.

Usługa GitOps na platformie Kubernetes z obsługą usługi Azure Arc używa rozszerzenia implementującego platformę Flux, popularnego zestawu narzędzi typu open source. Flux to operator, który automatyzuje wdrożenia konfiguracji GitOps w klastrze. Platforma Flux zapewnia obsługę typowych źródeł plików (repozytoriów Git, repozytoriów Helm, zasobników) i typów szablonów (YAML, Helm i Kustomize). Platforma Flux obsługuje również zarządzanie zależnościami między wieloma dzierżawami i wdrożeniami.

Architektura

Na poniższych diagramach przedstawiono koncepcyjną architekturę referencyjną, która wyróżnia aprowizację instalacji rozszerzenia klastra Flux w klastrze, proces konfiguracji GitOps dla klastra Kubernetes z włączoną usługą Azure Arc i usługę GitOps Flow.

Proces aprowizacji rozszerzenia klastra Flux v2:

Diagram that shows Flux extension installation.

Proces konfiguracji GitOps:

Diagram that shows how to configure GitOps.

Usługa GitOps Flow przedstawiająca aktualizację aplikacji:

Diagram that shows a typical GitOps workflow.

Uwagi dotyczące projektowania

Zapoznaj się z poniższymi zagadnieniami dotyczącymi projektowania podczas planowania wdrożenia metodyki GitOps dla platformy Kubernetes z obsługą usługi Azure Arc.

Konfigurowanie

Omówienie różnych warstw konfiguracji w klastrze Kubernetes i obowiązków związanych z ich aprowizowaniem.

Warstwy konfiguracji

  • Konfiguracja aplikacji wymagana do wdrożenia aplikacji i powiązanych z nią obiektów Kubernetes w klastrze, takich jak wdrażanie, usługa, HPA i zasoby ConfigMap. Konfiguracje aplikacji są zwykle stosowane do konfiguracji GitOps na poziomie przestrzeni nazw, co wymaga skonfigurowania składników aplikacji tylko w ramach jednej przestrzeni nazw.
  • Konfiguracja obejmująca cały klaster na potrzeby tworzenia obiektów Kubernetes, takich jak przestrzenie nazw, konta usług, role i powiązania ról oraz inne zasady dla całego klastra.
  • Składniki całego klastra, takie jak kontroler ruchu przychodzącego, stos monitorowania i zabezpieczeń oraz różni agenci działający w klastrze.

Zakres odpowiedzialności

  • Deweloperzy aplikacji są odpowiedzialni za wypychanie kodu źródłowego, wyzwalanie kompilacji i tworzenie obrazów kontenerów.
  • Operatorzy aplikacji są odpowiedzialni za utrzymywanie repozytoriów aplikacji, konfiguracji, zmiennych środowiskowych, wykresów helm specyficznych dla aplikacji, kustomizacji itp.
  • Operatorzy klastra są odpowiedzialni za konfigurowanie punktu odniesienia klastra. Zwykle zajmują się oni konfigurowaniem składników i zasad dotyczących całego klastra. Konserwują oni katalogi repozytorium Git zawierające typowe narzędzia infrastruktury, takie jak przestrzenie nazw, konta usług, powiązania ról, definicje zasobów niestandardowych (CRD), zasady dla całego klastra, składniki ruchu przychodzącego itp.

Struktura repozytorium

Podczas wybierania struktury repozytorium Git należy wziąć pod uwagę kompromisy. Wybrana struktura definiuje stan klastra Kubernetes, który obejmuje aplikacje i składniki całego klastra. W zależności od tego, które obowiązki i osoby zostaną zidentyfikowane, ważne jest, aby uwzględnić wszelką niezbędną współpracę lub żądaną niezależność zespołu wymaganą w przypadku różnych opcji struktury repozytorium.

Możesz użyć dowolnej strategii rozgałęziania, którą chcesz zastosować w repozytoriach kodu, ponieważ jest ona używana tylko przez proces ciągłej integracji.

W przypadku repozytoriów konfiguracji GitOps należy wziąć pod uwagę następujące strategie na podstawie potrzeb biznesowych, wielkości i narzędzi organizacji:

  • Pojedyncze repozytorium (gałąź na środowisko):
    • Zapewnia największą elastyczność do kontrolowania zasad i uprawnień usługi Git dla każdej gałęzi reprezentującej środowisko.
    • Wadą jest brak współużytkowania wspólnej konfiguracji między środowiskami, ponieważ narzędzia takie jak Kustomize nie działają z gałęziami usługi Git.
  • Pojedyncze repozytorium (katalog na środowisko):
    • To podejście można zaimplementować przy użyciu narzędzi, takich jak Kustomize, co umożliwia zdefiniowanie podstawowej konfiguracji obiektów Kubernetes i zestawu artefaktów (tj. poprawek) dla środowiska, które zastępuje konfiguracje w bazie.
    • Takie podejście może zmniejszyć zduplikowane pliki YAML dla każdego środowiska, ale także zmniejszyć separację konfiguracji między środowiskami. Wprowadzenie pojedynczej zmiany w repozytorium może mieć wpływ na wszystkie środowiska jednocześnie, więc wymaga dobrego zrozumienia i starannego uwzględniania wpływu zmian w katalogach bazowych.
  • Wiele repozytoriów (każde do określonego celu):
    • To podejście można zastosować w celu oddzielenia repozytoriów konfiguracji dla każdej aplikacji, zespołu, warstwy lub dzierżawy.
    • Dzięki temu zespoły mogą mieć większą niezależną kontrolę, ale odchodzą od zasady definiowania stanu systemu w jednym repozytorium, aby poprawić centralną konfigurację, widoczność i kontrolę wdrożeń w klastrze.
    • Skonfigurowanie wielu repozytoriów powinno się brać pod uwagę w przypadku potrzeb obejmujących wiele dzierżaw. Istnieje wbudowana kontrola dostępu oparta na rolach (RBAC) i zabezpieczenia, które pozwalają ograniczyć to, jaką konfigurację zespół/dzierżawa przypisana do określonego repozytorium może zastosować, na przykład przez zezwolenie na wdrażanie tylko w określonych przestrzeniach nazw.

Więcej sposobów tworzenia struktury repozytorium można znaleźć w Przewodniku po platformie Flux.

Konfiguracja aplikacji i platformy

Operatory platformy i operatorzy aplikacji mają kilka opcji zarządzania konfiguracją platformy Kubernetes:

  • Nieprzetworzone pliki YAML kubernetes reprezentujące specyfikacje YAML dla każdego wdrażanego obiektu interfejsu API Kubernetes mogą działać dobrze w przypadku pojedynczych środowisk. Wadą korzystania z nieprzetworzonych plików YAML jest to, że dostosowywanie staje się trudne, gdy zaczniesz uwzględniać wiele środowisk, ponieważ musisz następnie duplikować pliki YAML i nie ma dobrej metody ponownego użycia.
  • Helm to narzędzie do zarządzania pakietami dla obiektów Kubernetes. Jest to prawidłowa opcja Operatorzy klastrów mogą użyć do instalowania aplikacji innych firm poza półki. Upewnij się, że nie używasz tworzenia szablonów zbyt mocno jako narzędzia do zarządzania konfiguracją dla aplikacji wewnętrznych, ponieważ może stać się skomplikowane do zarządzania w miarę zwiększania się szablonów.
    • Jeśli używasz programu Helm, platforma Flux zawiera kontroler helm, który umożliwia deklaratywne zarządzanie wydaniami pakietu Helm przy użyciu manifestów platformy Kubernetes. Aby zarządzać tym procesem , możesz utworzyć obiekt HelmRelease .
  • Kustomize to natywne narzędzie do zarządzania konfiguracją platformy Kubernetes, które wprowadza bezpłatny sposób dostosowywania konfiguracji aplikacji.
    • Jeśli używasz narzędzia Kustomize, platforma Flux zawiera kontroler Kustomize, który specjalizuje się w uruchamianiu potoków ciągłego dostarczania dla infrastruktury i obciążeń zdefiniowanych za pomocą manifestów platformy Kubernetes i zestawiony z usługą Kustomize. Aby zarządzać tym procesem, można utworzyć obiekt Kustomization.
  • Dzięki rozwiązaniu Kubernetes z obsługą usługi Azure Arc zamiast samodzielnie zarządzać cyklem życia i obsługą składników, możesz użyć listy dostępnych rozszerzeń , którymi zarządza i obsługuje firma Microsoft. Te rozszerzenia są zarządzane za pośrednictwem usługi Azure Resource Manager. Niektóre z tych rozszerzeń, takie jak dostawca wpisów tajnych usługi Azure Key Vault, mają alternatywy typu open source. Zarządzanie składnikami poza procesem rozszerzenia zapewnia większą kontrolę nad składnikami, ale także wymaga większego nakładu pracy na potrzeby zarządzania pomocą techniczną i cyklem życia.

Przepływ ciągłej integracji i ciągłego dostarczania (CI/CD)

W poniższych sekcjach opisano zagadnienia dotyczące potoku aplikacji i procesu aktualizacji składników.

Potok aplikacji

  • Należy wziąć pod uwagę kompilację, testowanie i walidacje aplikacji, które należy uwzględnić w procesie ciągłej integracji. Mogą one obejmować linting i testowanie związane z zabezpieczeniami, integracją i wydajnością, które są potrzebne w celu utworzenia kandydata wydania (RC) na potrzeby wdrożeń środowiska.
  • Możesz użyć tradycyjnej metody wdrażania wypychanego, aby wypełnić lukę między obrazem kontenera kompilacji w potoku ciągłej integracji i jego wdrożeniem w klastrze, wywołując interfejs API Kubernetes bezpośrednio z potoku wdrażania.

Aby uniknąć ręcznych modyfikacji konfiguracji repozytorium GitOps, możesz uruchomić potok ciągłego wdrażania jako konto usługi, które ma uprawnienia do otwierania żądań ściągnięcia (PRs) lub zatwierdzenia nowej zmiany obrazu kontenera bezpośrednio w repozytorium konfiguracji. Te zmiany mogą również aprowizować wszystkie obiekty YAML wymagane dla aplikacji.

Na poniższym diagramie procesów przedstawiono tradycyjny proces ciągłej integracji aplikacji uwzględniony ze zmianami obsługującymi metodyki GitOps.

Diagram that shows the standard GitOps process.

Proces aktualizacji składnika całego klastra

  • Operatorzy klastrów muszą zarządzać składnikami całego klastra, więc prawdopodobnie nie będzie to pochodzić z potoku ciągłego wdrażania używanych do wdrażania aplikacji i usług. Rozważ zdefiniowanie procesu podwyższania poziomu specyficznego dla operatorów klastra w celu zapewnienia bezproblemowego przejścia zmian z jednego środowiska do drugiego.
  • Jeśli musisz zastosować identyczną konfigurację gitOps na dużą skalę do klastrów Kubernetes z włączoną usługą Azure Arc, rozważ zastosowanie usługi Azure Policy, która może automatycznie zainstalować rozszerzenie Flux i zastosować konfigurację gitOps do istniejących klastrów Kubernetes z włączoną usługą Azure Arc lub do nowych klastrów podczas dołączania do usługi Azure Arc.

Podczas aktualizowania konfiguracji prawdopodobnie chcesz sprawdzić, czy zmiany zostały pomyślnie zastosowane do żądanego środowiska. Powiadomienia w środowisku Flux można zdefiniować w celu integracji z narzędziami ciągłej integracji/ciągłego wdrażania, pocztą e-mail lub narzędziami ChatOps oraz automatycznie wysyłać alerty dotyczące pomyślnych zmian i niepowodzeń wdrażania. Informacje o stanie wdrożenia można również znaleźć w witrynie Azure Portal oraz za pośrednictwem interfejsu wiersza polecenia k8s-configuration i interfejsu API usługi ARM.

Zagadnienia dotyczące zabezpieczeń

Zapoznaj się z poniższymi zagadnieniami dotyczącymi zabezpieczeń podczas planowania wdrożenia metodyki GitOps dla platformy Kubernetes z obsługą usługi Azure Arc.

Uwierzytelnianie repozytorium

  • Możesz użyć publicznego lub prywatnego repozytorium Git z usługą GitOps, ale ze względu na poufny charakter konfiguracji platformy Kubernetes zalecamy użycie prywatnego repozytorium, które wymaga uwierzytelniania za pomocą klucza SSH lub klucza interfejsu API. Usługa GitOps współpracuje również z repozytoriami Git, które są dostępne tylko w sieci prywatnej, o ile klaster Kubernetes może uzyskać do niego dostęp, ale ta konfiguracja ogranicza możliwość korzystania z dostawców git opartych na chmurze, takich jak Azure Repos lub GitHub.
  • Protokoły HTTPS i SSH oferują niezawodne i bezpieczne połączenie, którego można użyć do nawiązania połączenia z narzędziem kontroli źródła. Jednak protokół HTTPS jest często łatwiejszy do skonfigurowania i używa portu, który rzadko wymaga otwarcia większej liczby portów w zaporach.

Zabezpieczenia repozytorium i gałęzi

  • Ustaw uprawnienia gałęzi i zasady w repozytorium konfiguracji. Ponieważ repozytorium Git staje się centralnym elementem wdrożeń platformy Kubernetes, niezwykle ważne jest skonfigurowanie uprawnień do kontrolowania, kto może odczytywać i aktualizować kod w gałęzi oraz wdrażać zasady w celu wymuszania jakości kodu i zarządzania zmianami w zespole. W przeciwnym razie przepływ pracy usługi GitOps może wysyłać kod, który nie jest do standardów organizacji.
  • Potoki żądań ściągnięcia mogą współpracować z zasadami gałęzi, aby w razie potrzeby zweryfikować konfigurację YAML i/lub wdrożyć środowiska testowe. Bramy pomagają wyeliminować błędy konfiguracji i zwiększyć bezpieczeństwo wdrożenia i pewność siebie.
  • Podczas przypisywania uprawnień dostępu należy wziąć pod uwagę, którzy użytkownicy w organizacji powinni mieć dostęp do odczytu repozytorium, dostęp do tworzenia żądania ściągnięcia i dostęp do zatwierdzania żądań ściągnięcia.

Zarządzanie wpisami tajnymi

  • Unikaj przechowywania wpisów tajnych zakodowanych w postaci zwykłego tekstu lub base64 w repozytorium Git. Zamiast tego rozważ użycie zewnętrznego dostawcy wpisów tajnych, takiego jak usługa Azure Key Vault. Dostawca usługi Azure Key Vault dla sterownika CSI magazynu wpisów tajnych umożliwia integrację magazynu kluczy platformy Azure jako magazynu wpisów tajnych z klastrem usługi Azure Kubernetes Service (AKS) przy użyciu woluminu CSI. Ta usługa jest dostępna za pośrednictwem rozszerzenia Kubernetes z obsługą usługi Azure Arc. HashiCorp Vault to alternatywa dostawcy wpisów tajnych zarządzanych przez inną firmę.
  • Innym alternatywnym sposobem zarządzania wpisami tajnymi jest użycie zapieczętowanych wpisów tajnych Bitnami, które działały na podstawie koncepcji kluczy publicznych i prywatnych. Dzięki temu operatorzy mogą przechowywać zaszyfrowany wpis tajny jednokierunkowy przy użyciu klucza publicznego w usłudze Git, który można odszyfrować tylko za pomocą klucza prywatnego, który jest używany przez kontroler SealedSecrets uruchomiony w klastrze.

Zalecenia dotyczące projektowania

Zapoznaj się z poniższymi zaleceniami dotyczącymi projektowania podczas planowania wdrożenia metodyki GitOps dla platformy Kubernetes z obsługą usługi Azure Arc.

Poniższy diagram zawiera architekturę referencyjną, która ilustruje obowiązki, repozytoria i potoki potrzebne do zaimplementowania procesu GitOps przy użyciu rozszerzenia Kubernetes Platformy Flux z obsługą usługi Azure Arc.

Diagram that shows a GitOps Reference flow.

Repozytoria

W projekcie znajdują się trzy repozytoria Git:

  • Repozytorium kodu aplikacji
    • To repozytorium przechowuje kod aplikacji i wszystkie skrypty definicji potoku i konfiguracji.
    • Użyj strategii rozgałęziania programowania, która jest łatwa do zrozumienia i ogranicza liczbę niepożądanych gałęzi długotrwałych.
  • Repozytorium konfiguracji aplikacji
    • To repozytorium przechowuje konfiguracje aplikacji, w tym obiekty Kubernetes, takie jak Config Mapy, Deployments, Services i HPA objects. Utwórz strukturę tego repozytorium z różnymi katalogami dla każdej aplikacji. Strumień synchronizuje zmiany z tego repozytorium i gałęzi docelowej z klastrem.
    • Uwzględnij narzędzia, które ułatwiają deweloperom aplikacji i operatorom tworzenie początkowych konfiguracji na środowisko. Operatorzy aplikacji powinni zdefiniować konfigurację aplikacji specyficzną dla platformy Kubernetes, która używa menedżerów pakietów, takich jak Helm lub narzędzia konfiguracyjne, takie jak Kustomize, aby ułatwić konfigurację.
    • Utwórz gałąź reprezentującą każdy typ środowiska. Dzięki temu można precyzyjnie kontrolować zmiany w poszczególnych środowiskach, takich jak środowiska nieprodowe i produkcyjne.
    • Po wdrożeniu aplikacji w określonej przestrzeni nazw użyj funkcji zakresu przestrzeni nazw w konfiguracji gitOps, aby wymusić konfigurację tylko dla określonej przestrzeni nazw.
  • Repozytorium konfiguracji całego klastra
    • Zdefiniuj składniki obejmujące cały klaster, takie jak kontroler ruchu przychodzącego, przestrzenie nazw, kontrola dostępu oparta na rolach, monitorowanie i stos zabezpieczeń na potrzeby zarządzania operatorami klastra. Platforma Flux synchronizuje zmiany z tego repozytorium i gałęzi docelowej z klastrem.
    • Utwórz strukturę tego repozytorium z różnymi katalogami reprezentującymi różne składniki.
    • Utwórz gałąź reprezentującą każdy typ środowiska. Dzięki temu można precyzyjnie kontrolować zmiany w poszczególnych środowiskach, takich jak środowiska nieprodowe i produkcyjne.
    • Operatorzy klastrów powinni używać menedżerów pakietów, takich jak Helm lub narzędzia konfiguracji, takie jak nakładki Kustomize, aby ułatwić konfigurację.

Ciągła integracja/ciągłe wdrażanie i proces aktualizacji konfiguracji

Aktualizacje ciągłej integracji/ciągłego wdrażania i obrazu kontenera

  • Potok ciągłej integracji
    • Zespoły programistyczne powinny definiować potok ciągłej integracji za pośrednictwem procesu, który obejmuje kompilowanie, tworzenie, testowanie i wypychanie aplikacji do rejestru kontenerów.
  • Potok ciągłego wdrażania
    • Utwórz potok ciągłego wdrażania, który uruchamia skrypt przeznaczony dla zmian w repozytorium konfiguracji aplikacji. Ten skrypt tworzy tymczasową gałąź źródłową ze środowiska docelowego, wprowadza zmianę w wersji tagu obrazu, zatwierdza zmianę i otwiera żądanie ściągnięcia względem gałęzi środowiska docelowego. Ten potok ciągłego wdrażania może zawierać etapy środowiska z odpowiednimi zmiennymi środowiskowymi w celu kierowania odpowiedniego repozytorium konfiguracji i gałęzi GitOps.
    • Zdefiniuj kroki ręcznego zatwierdzania dla etapów środowiska, aby ograniczyć niepożądane żądania ściągnięcia do wszystkich środowisk.
  • Włącz zasady gałęzi w repozytorium konfiguracji aplikacji, aby wymusić przegląd równorzędny lub zatwierdzenia dla środowisk. Może to obejmować minimalną liczbę wymaganych przeglądów lub automatyczne zatwierdzenie dla niższych środowisk. Należy również rozważyć integrację i zatwierdzenia innych firm zgodnie z potrzebami, aby spełnić standardy organizacji.

Aktualizacje konfiguracji aplikacji i całego klastra

  • Operatorzy klastrów i operatorzy aplikacji definiują konfigurację w odpowiednich repozytoriach konfiguracji. Ci użytkownicy nie wymagają narzędzi potoku do wypychania konfiguracji. Zamiast tego używają natywnych procesów zatwierdzania i żądania ściągnięcia usługi Git do definiowania konfiguracji i wypychania zmian do gałęzi reprezentującej środowisko.
  • W przypadku nowych definicji konfiguracji zacznij od zdefiniowania konfiguracji w niższych środowiskach, takich jak Deweloper, a następnie podwyższ poziom do wyższych środowisk za pomocą scalania i żądań ściągnięcia. Konfiguracja cherry-pick aktualizuje specyficzne dla niektórych środowisk zgodnie z potrzebami.

Opinie i alerty

  • Skonfiguruj powiadomienia flux, aby otrzymywać alerty , gdy konfiguracje usługi GitOps nie są w stanie zsynchronizować lub zgłaszają błędy. Operatorzy aplikacji powinni skonfigurować alerty, aby określić, kiedy wdrożenie aplikacji zakończyło się pomyślnie i jest w dobrej kondycji. Operatorzy klastra powinni skonfigurować alerty w celu określenia, kiedy uzgadnianie składnika całego klastra nie powiodło się i gdy występują problemy z synchronizacją z repozytorium Git.
  • Zaimplementuj Połączenie or usługi GitOps, aby zintegrować opinie od agenta Flux do narzędzi ciągłej integracji/ciągłego wdrażania.

Zalecenia dotyczące zabezpieczeń

  • Zapoznaj się z zaleceniami dotyczącymi ładu i zabezpieczeń dla klastrów Kubernetes z obsługą usługi Azure Arc.
  • Unikaj niechcianego dostępu do dowolnej konfiguracji klastra przy użyciu prywatnego repozytorium Git z uwierzytelnianiem i autoryzacją, którego można użyć do zdefiniowania dowolnego repozytorium konfiguracji.
  • Uzyskaj dostęp do repozytorium Git za pośrednictwem protokołu SSH i klucza SSH, jeśli dostawca usługi Git go obsługuje. Jeśli protokół SSH jest bezużyteczny z powodu ograniczeń łączności wychodzącej lub jeśli dostawca usługi Git nie obsługuje wymaganych bibliotek SSH, użyj dedykowanego konta usługi i skojarz klucz interfejsu API z tym kontem, które ma być używane przez usługę Flux. Jeśli potrzebujesz alternatywy dla protokołu SSH podczas korzystania z usługi GitHub, możesz utworzyć osobisty token dostępu do uwierzytelniania.
  • Skonfiguruj zasady gałęzi i uprawnienia zgodne z obowiązkami klastra. Ustaw minimalną liczbę recenzentów, aby zatwierdzić zmiany.
  • Skonfiguruj potok żądania ściągnięcia, aby zweryfikować konfiguracje i składnię YAML oraz opcjonalnie wdrożyć testowy klaster Kubernetes. Skonfiguruj zasady gałęzi, które wymagają pomyślnego uruchomienia tego potoku przed zaakceptowaniem dowolnego scalania.
  • Zaimplementuj wpisy tajne przy użyciu dostawcy usługi Azure Key Vault dla sterownika CSI magazynu wpisów tajnych, co umożliwi integrację usługi Azure Key Vault jako magazynu wpisów tajnych z klastrem Kubernetes z włączoną usługą Azure Arc za pośrednictwem woluminu CSI.
  • Rozszerzenie Flux obsługuje konfiguracje o zakresie przestrzeni nazw i klastra. Wybierz zakres przestrzeni nazw, gdy konfiguracja nie powinna mieć dostępu poza jedną przestrzenią nazw.

Następne kroki

Aby uzyskać więcej informacji na temat podróży do chmury hybrydowej i wielochmurowej, zobacz następujące artykuły.