Wdrażanie aplikacji z GitOps (Flux v2) dla AKS i Kubernetes z obsługą Azure Arc

Platforma Azure udostępnia funkcję wdrażania aplikacji automatycznych przy użyciu metodyki GitOps, która współpracuje z usługą Azure Kubernetes Service (AKS) i klastrami Kubernetes z obsługą usługi Azure Arc. Najważniejsze korzyści zapewniane przez wdrożenie metodyki GitOps na potrzeby wdrażania aplikacji w klastrach Kubernetes obejmują:

• Ciągły wgląd w stan aplikacji uruchomionych w klastrach.
• Rozdzielenie problemów między zespołami deweloperów aplikacji i zespołami infrastruktury. Zespoły aplikacji nie muszą mieć doświadczenia z wdrożeniami platformy Kubernetes. Zespoły inżynieryjne platformy zwykle tworzą model samoobsługowy dla zespołów aplikacji, umożliwiając im uruchamianie wdrożeń z większą pewnością.
• Możliwość ponownego tworzenia klastrów o tym samym żądanym stanie w przypadku awarii lub skalowania w poziomie.
• Możliwość wdrażania aplikacji na dużą skalę za pomocą usługi Azure Policy.

Za pomocą metodyki GitOps deklarujesz żądany stan klastrów Kubernetes w plikach w repozytoriach Git. Repozytoria Git mogą zawierać następujące pliki:

• Manifesty w formacie YAML opisujące zasoby Kubernetes (takie jak przestrzenie nazw, tajemnice, wdrożenia i inne)
• Helm charts na potrzeby wdrażania aplikacji
• Pliki Kustomize do opisu zmian specyficznych dla środowiska

Ponieważ te pliki są przechowywane w repozytorium Git, są one wersjonowane, a zmiany między wersjami są łatwo śledzone. Kontrolery Kubernetes działają w klastrach i stale uzgadniają stan klastra z żądanym stanem zadeklarowanym 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.

GitOps na Kubernetes obsługiwanym przez Azure Arc lub Azure Kubernetes Service wykorzystuje Flux, popularny zestaw narzędziowy typu open source. Platforma Flux zapewnia obsługę typowych źródeł plików (repozytoria Git i Helm, bucketów, Azure Blob Storage) i typów szablonów (YAML, Helm i Kustomize). Platforma Flux obsługuje również wielodzierżawczość i zarządzanie zależnościami wdrożenia, wśród innych funkcji.

Flux jest wdrażany bezpośrednio w klastrze, a płaszczyzna kontrolna każdego klastra jest logicznie oddzielona. Dzięki temu skaluje się dobrze do setek i tysięcy klastrów. Platforma Flux umożliwia czyste wdrożenia aplikacji GitOps oparte na ściąganiu. Żaden dostęp do klastrów nie jest wymagany przez repozytorium źródłowe lub przez inny klaster.

Rozszerzenie klastra Flux

Usługa GitOps jest włączona w klastrze Kubernetes lub AKS z włączoną usługą Azure Arc jako zasób Microsoft.KubernetesConfiguration/extensions/microsoft.flux. Rozszerzenie microsoft.flux musi być zainstalowane w klastrze, zanim można utworzyć co najmniej jedno fluxConfigurations. Rozszerzenie jest instalowane automatycznie podczas tworzenia pierwszego Microsoft.KubernetesConfiguration/fluxConfigurations w klastrze lub można zainstalować je ręcznie przy użyciu portalu, interfejsu wiersza polecenia platformy Azure (az k8s-extension create --extensionType=microsoft.flux), szablonu usługi ARM lub interfejsu API REST.

Kontrolery

Domyślnie microsoft.flux rozszerzenie instaluje kontrolery Flux (Source, Kustomize, Helm, Notification) i FluxConfig Custom Resource Definition (CRD), fluxconfig-agenti fluxconfig-controller. Opcjonalnie można również zainstalować kontrolery Flux image-automation i image-reflector, które zapewniają funkcjonalność aktualizowania i pobierania obrazów Dockera.

• Kontroler źródła strumienia: monitoruje source.toolkit.fluxcd.io zasoby niestandardowe. Obsługuje synchronizację między repozytoriami Git, repozytoriami Helm, zasobnikami i usługą pamięci masowej Azure Blob. Obsługuje autoryzację w odniesieniu do źródła dla prywatnych repozytoriów Git, Helm i kont Azure Blob Storage. Przedstawia najnowsze zmiany w źródle za pośrednictwem pliku archiwum tar.

• Kontroler Flux Kustomize: obserwuje kustomization.toolkit.fluxcd.io zasoby niestandardowe. Stosuje pliki Kustomize lub nieprzetworzone pliki YAML ze źródła do klastra.

• Kontroler Helm Flux: Nadzoruje helm.toolkit.fluxcd.io zasoby niestandardowe. Pobiera skojarzony wykres ze źródła repozytorium Helm udostępnianego przez kontroler źródła. Tworzy zasób niestandardowy HelmChart i implementuje HelmRelease do klastra, korzystając z określonej wersji, nazwy oraz wartości zdefiniowanych przez klienta.

• Kontroler powiadomień Flux: obserwuje notification.toolkit.fluxcd.io zasoby niestandardowe. Odbiera powiadomienia ze wszystkich kontrolerów Flux. Wysyła powiadomienia do punktów końcowych webhooków zdefiniowanych przez użytkownika.

• Definicje zasobów niestandardowych Flux:

  • kustomizations.kustomize.toolkit.fluxcd.io
  • imagepolicies.image.toolkit.fluxcd.io
  • imagerepositories.image.toolkit.fluxcd.io
  • imageupdateautomations.image.toolkit.fluxcd.io
  • alerts.notification.toolkit.fluxcd.io
  • providers.notification.toolkit.fluxcd.io
  • receivers.notification.toolkit.fluxcd.io
  • buckets.source.toolkit.fluxcd.io
  • gitrepositories.source.toolkit.fluxcd.io
  • helmcharts.source.toolkit.fluxcd.io
  • helmrepositories.source.toolkit.fluxcd.io
  • helmreleases.helm.toolkit.fluxcd.io
  • fluxconfigs.clusterconfig.azure.com

• FluxConfig CRD: niestandardowa definicja zasobu dla fluxconfigs.clusterconfig.azure.com zasobów niestandardowych definiujących FluxConfig obiekty Kubernetes.

• fluxconfig-agent: Odpowiedzialny za monitorowanie platformy Azure w celu wykrywania nowych lub zaktualizowanych fluxConfigurations zasobów oraz uruchamianie odpowiadającej konfiguracji Flux w klastrze. Odpowiada również za wypychanie zmian stanu flux w klastrze z powrotem na platformę Azure dla każdego fluxConfigurations zasobu.

• fluxconfig-controller: Obserwuje fluxconfigs.clusterconfig.azure.com zasoby niestandardowe i reaguje na zmiany poprzez nową lub zaktualizowaną konfigurację mechanizmów GitOps w klastrze.

Uwaga / Notatka

Rozszerzenie microsoft.flux jest instalowane w flux-system przestrzeni nazw i ma zakres obejmujący cały klaster. Nie można zainstalować tego rozszerzenia w zakresie przestrzeni nazw.

Konfiguracje strumienia

Aby pobrać diagramy architektury w wysokiej rozdzielczości, odwiedź stronę Jumpstart Gems.

Zasoby konfiguracyjne Flux (Microsoft.KubernetesConfiguration/fluxConfigurations) umożliwiają zarządzanie klastrem za pomocą GitOps z repozytoriów Git, źródeł Bucket lub przechowywania obiektów Azure Blob. Podczas tworzenia fluxConfigurations zasobu wartości, które podajesz dla parametrów, takich jak docelowe repozytorium Git, są używane do tworzenia i konfigurowania obiektów Kubernetes, które umożliwiają proces GitOps w tym klastrze. Aby zapewnić bezpieczeństwo danych, dane zasobów fluxConfigurations są przechowywane w stanie spoczynku jako zaszyfrowane w bazie danych Azure Cosmos DB przez usługę konfiguracji klastra.

Agenci fluxconfig-agent i fluxconfig-controller instalowani z microsoft.flux rozszerzeniem zarządzają procesem konfiguracji GitOps.

fluxconfig-agent odpowiada za następujące zadania:

• Skanuje usługę płaszczyzny danych konfiguracji Kubernetes w poszukiwaniu nowych lub zaktualizowanych zasobów.
• Tworzy lub aktualizuje FluxConfig zasoby niestandardowe w klastrze, korzystając z informacji o konfiguracji.
• Obserwuje FluxConfig zasoby niestandardowe i przekazuje zmiany stanu do skojarzonych zasobów Azure fluxConfiguration.

fluxconfig-controller odpowiada za następujące zadania:

• Obserwuje aktualizacje stanu zasobów niestandardowych flux utworzonych przez zarządzany fluxConfigurationsprogram .
• Tworzy parę kluczy prywatnych/publicznych, która istnieje przez okres istnienia elementu fluxConfigurations. Ten klucz jest używany do uwierzytelniania, jeśli adres URL jest oparty na protokole SSH i jeśli użytkownik nie udostępnia własnego klucza prywatnego podczas tworzenia konfiguracji.
• Tworzy niestandardowy sekret uwierzytelniający na podstawie danych dostarczonych przez użytkownika: klucz prywatny, HTTP basic-auth, known-hosts lub brak uwierzytelnienia.
• Konfiguruje kontrolę dostępu opartą na rolach (aprowizowanie konta usługi, tworzenie/przypisywanie powiązania roli, tworzenie/przypisywanie roli).
• Tworzy GitRepository lub Bucket niestandardowe zasoby i Kustomization niestandardowe zasoby na podstawie informacji w niestandardowym zasobie FluxConfig.

Każdy fluxConfigurations zasób na platformie Azure jest powiązany z jednym zasobem Flux GitRepository lub co najmniej jednym zasobem niestandardowym Bucket i jednym lub więcej zasobami niestandardowymi Kustomization w klastrze Kubernetes. Podczas tworzenia fluxConfigurations zasobu należy określić adres URL źródła (repozytorium Git, zasobnik lub usługa Azure Blob Storage) oraz miejsce docelowe synchronizacji w źródle dla każdego Kustomization. Zależności między zasobami niestandardowymi Kustomization można skonfigurować w celu kontrolowania sekwencjonowania wdrożenia. Można również utworzyć wiele zasobów o fluxConfigurations zakresie przestrzeni nazw w tym samym klastrze dla różnych aplikacji i zespołów aplikacji.

Uwaga / Notatka

Monitoruje fluxconfig-agent nowe lub zaktualizowane zasoby platformy Azure. Agent wymaga łączności z platformą Azure w celu uzyskania żądanego fluxConfiguration stanu, który ma zostać zastosowany do klastra. Jeśli agent nie może nawiązać połączenia z platformą Azure, zmiany w klastrze czekają, aż agent będzie mógł nawiązać połączenie. Jeśli klaster zostanie odłączony od platformy Azure przez ponad 48 godzin, żądanie do klastra wygaśnie, a zmiany będą musiały zostać ponownie zastosowane na platformie Azure.

Poufne dane wejściowe klienta, takie jak klucz prywatny i token/hasło, są przechowywane przez mniej niż 48 godzin w usłudze konfiguracji Kubernetes. Jeśli zaktualizujesz dowolną z tych wartości na platformie Azure, upewnij się, że klastry łączą się z platformą Azure w ciągu 48 godzin.

Stan konfiguracji i zgodność platformy Flux można monitorować w witrynie Azure Portal lub używać pulpitów nawigacyjnych do monitorowania stanu, zgodności, zużycia zasobów i działań uzgodnień. Aby uzyskać więcej informacji, zobacz Monitorowanie stanu i działania usługi GitOps (Flux v2).

Obsługa wersji

Obsługiwana jest najnowsza wersja rozszerzenia Flux v2 (microsoft.flux) i dwie poprzednie wersje (N-2). Ogólnie zaleca się używanie najnowszej wersji rozszerzenia. microsoft.flux Począwszy od wersji 1.7.0, obsługiwane są klastry oparte na architekturze ARM64.

GitOps z użyciem linku prywatnego

Jeśli dodałeś obsługę łącza prywatnego do klastra Kubernetes z obsługą Azure Arc, to microsoft.flux rozszerzenie działa od razu, umożliwiając komunikację z powrotem do platformy Azure. W przypadku połączeń z repozytorium Git, repozytorium Helm lub innych punktów końcowych potrzebnych do wdrożenia manifestów platformy Kubernetes, należy zabezpieczyć te punkty końcowe za zaporą lub dodać je do zapory, aby Flux Source controller mógł pomyślnie nawiązać z nimi połączenie.

Miejsce przechowywania danych

Usługa Azure GitOps (Azure Kubernetes Configuration Management) przechowuje/przetwarza dane klientów. Domyślnie dane klienta są replikowane do sparowanego regionu. W regionach Singapur, Azja Wschodnia i Brazylia Południowa wszystkie dane klientów są przechowywane i przetwarzane w regionie.

Stosowanie konfiguracji platformy Flux na dużą skalę

Ponieważ Azure Resource Manager zarządza konfiguracjami, możesz zautomatyzować tworzenie jednolitych konfiguracji we wszystkich zasobach Azure Kubernetes Service oraz Azure Arc dla Kubernetes, używając Azure Policy w zakresie subskrypcji lub grupy zasobów. To wymuszanie na dużą skalę zapewnia spójne stosowanie określonych konfiguracji w całych grupach klastrów.

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.

Parametry

Aby wyświetlić wszystkie parametry obsługiwane przez platformę Flux v2 na platformie Azure, zobacz dokumentacjęaz k8s-configuration. Implementacja platformy Azure obecnie nie obsługuje każdego parametru obsługiwanego przez platformę Flux.

Aby uzyskać informacje o dostępnych parametrach i sposobie ich używania, zobacz Parametry obsługiwane przez usługę GitOps (Flux v2).

Wielodzierżawność

Platforma Flux v2 obsługuje multi-tenancy począwszy od wersji 0.26. Ta funkcja jest zintegrowana z platformą Flux v2 na platformie Azure.

Uwaga / Notatka

W przypadku funkcji wielodostępności należy upewnić się, czy manifesty zawierają jakiekolwiek odniesienia źródłowe między przestrzeniami nazw dla HelmRelease, Kustomization, ImagePolicy lub innych obiektów albo jeśli używasz platformy Kubernetes w wersji mniejszej niż 1.20.6. Aby przygotować:

• Uaktualnij platformę Kubernetes do wersji 1.20.6 lub nowszej.
• W manifestach platformy Kubernetes upewnij się, że wszystkie sourceRef obiekty znajdują się w tej samej przestrzeni nazw co konfiguracja usługi GitOps.
  • Jeśli potrzebujesz czasu na zaktualizowanie manifestów, możesz zrezygnować z wielodostępności. Jednak nadal trzeba uaktualnić wersję rozwiązania Kubernetes.

Aktualizacja manifestów dla wielu najemców

Załóżmy, że wdrożysz fluxConfiguration do jednego z naszych klastrów Kubernetes w przestrzeni nazw cluster-config z zakresem klastra. Konfigurujesz źródło, aby synchronizować repozytorium https://github.com/fluxcd/flux2-kustomize-helm-example. Jest to to samo przykładowe repozytorium Git używane w samouczku Wdrażanie aplikacji przy użyciu metodyki GitOps z rozwiązaniem Flux w wersji 2.

Po zsynchronizowaniu repozytorium platforma Flux wdraża zasoby opisane w manifestach (pliki YAML). Dwa z manifestów opisują HelmRelease i HelmRepository obiekty.

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: nginx
  namespace: nginx
spec:
  releaseName: nginx-ingress-controller
  chart:
    spec:
      chart: nginx-ingress-controller
      sourceRef:
        kind: HelmRepository
        name: bitnami
        namespace: flux-system
      version: "5.6.14"
  interval: 1h0m0s
  install:
    remediation:
      retries: 3
  # Default values
  # https://github.com/bitnami/charts/blob/master/bitnami/nginx-ingress-controller/values.yaml
  values:
    service:
      type: NodePort

apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository
metadata:
  name: bitnami
  namespace: flux-system
spec:
  interval: 30m
  url: https://charts.bitnami.com/bitnami

Domyślnie rozszerzenie Flux rozmieszcza fluxConfigurations przez podszywanie się pod konto usługi flux-applier, które jest wdrażane tylko w przestrzeni nazw cluster-config. Używając powyższych manifestów, gdy włączono wielodostęp, HelmRelease zostałoby zablokowane. Jest to spowodowane tym, że HelmRelease znajduje się w przestrzeni nazw nginx, ale odwołuje się do HelmRepository w przestrzeni nazw flux-system. Ponadto Flux helm-controller nie może zastosować HelmRelease, ponieważ nie ma konta usługi flux-applier w przestrzeni nazw nginx.

Aby pracować z wielodzierżawczością, właściwym rozwiązaniem jest wdrożenie wszystkich obiektów Flux we wspólnej przestrzeni nazw co fluxConfigurations. Takie podejście pozwala uniknąć problemu odwołań między przestrzeniami nazw i pozwala kontrolerom Flux uzyskać uprawnienia do stosowania obiektów. W związku z tym w przypadku konfiguracji GitOps utworzonej w przestrzeni nazw cluster-config, następujące przykładowe manifesty ulegają zmianie:

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: nginx
  namespace: cluster-config 
spec:
  releaseName: nginx-ingress-controller
  targetNamespace: nginx
  chart:
    spec:
      chart: nginx-ingress-controller
      sourceRef:
        kind: HelmRepository
        name: bitnami
        namespace: cluster-config
      version: "5.6.14"
  interval: 1h0m0s
  install:
    remediation:
      retries: 3
  # Default values
  # https://github.com/bitnami/charts/blob/master/bitnami/nginx-ingress-controller/values.yaml
  values:
    service:
      type: NodePort

apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository
metadata:
  name: bitnami
  namespace: cluster-config
spec:
  interval: 30m
  url: https://charts.bitnami.com/bitnami

Zrezygnuj z wielodostępności

Po zainstalowaniu microsoft.flux rozszerzenia domyślnie włączona jest wielodzierżawność. Jeśli musisz wyłączyć wielodostępność, możesz to zrobić poprzez stworzenie lub aktualizację microsoft.flux rozszerzenia w swoich klastrach za pomocą --configuration-settings multiTenancy.enforce=false, jak pokazano w przykładach poleceń:

az k8s-extension create --extension-type microsoft.flux --configuration-settings multiTenancy.enforce=false -c CLUSTER_NAME -g RESOURCE_GROUP -n flux -t <managedClusters or connectedClusters>

az k8s-extension update --configuration-settings multiTenancy.enforce=false -c CLUSTER_NAME -g RESOURCE_GROUP -n flux -t <managedClusters or connectedClusters>

Dalsze kroki

• Skorzystaj z naszego samouczka, aby dowiedzieć się, jak włączyć metodykę GitOps w klastrach Kubernetes z włączoną usługą AKS lub Azure Arc.
• Dowiedz się więcej o przepływie pracy CI/CD metodyką GitOps.