Wdrożenia aplikacji z usługą GitOps (Flux v2) dla usług AKS i Kubernetes z obsługą usługi Azure Arc

  • Artykuł

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.

Za pomocą usługi 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, wpisy tajne, wdrożenia i inne)
  • Wykresy helm na potrzeby wdrażania aplikacji
  • Kustomize plików w celu opisania 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.

Usługa GitOps na platformie Kubernetes z włączoną usługą Azure Arc lub Azure Kubernetes Service korzysta z platformy Flux, popularnego zestawu narzędzi typu open source. Platforma Flux zapewnia obsługę typowych źródeł plików (repozytoriów Git i Helm, zasobników, usługi Azure Blob Storage) 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.

Strumień jest wdrażany bezpośrednio w klastrze, a płaszczyzna sterowania każdego klastra jest logicznie oddzielona. Dzięki temu skalowanie jest dobrze skalowane 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 rozszerzenia klastra.Microsoft.KubernetesConfiguration/extensions/microsoft.flux Przed microsoft.flux utworzeniem co najmniej jednego fluxConfigurations rozszerzenia należy zainstalować w klastrze. 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ć platformę Flux image-automation i image-reflector kontrolery, które zapewniają funkcjonalność aktualizowania i pobierania obrazów platformy Docker.

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

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

  • Kontroler Flux Helm: obserwuje helm.toolkit.fluxcd.io zasoby niestandardowe. Pobiera skojarzony wykres ze źródła repozytorium Helm udostępnianego przez kontroler źródła. HelmChart Tworzy zasób niestandardowy i stosuje element HelmRelease z daną wersją, nazwą i wartościami zdefiniowanymi przez klienta do klastra.

  • Kontroler powiadomień flux: obserwuje notification.toolkit.fluxcd.io zasoby niestandardowe. Odbiera powiadomienia ze wszystkich kontrolerów Flux. Wypycha powiadomienia do punktów końcowych elementu webhook zdefiniowanego 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 oglądanie platformy Azure pod kątem nowych lub zaktualizowanych fluxConfigurations zasobów oraz uruchamiania skojarzonej konfiguracji platformy 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: monitoruje fluxconfigs.clusterconfig.azure.com zasoby niestandardowe i reaguje na zmiany dzięki nowej lub zaktualizowanej konfiguracji maszyn GitOps w klastrze.

Uwaga

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

Diagram przedstawiający instalację konfiguracji platformy Flux w klastrze Kubernetes z obsługą usługi Azure Arc lub AKS.

Zasoby konfiguracji platformy Flux (Microsoft.KubernetesConfiguration/fluxConfigurations) umożliwiają zarządzanie klastrem w usłudze GitOps z repozytoriów Git, źródeł zasobników lub usługi Azure Blob Storage. 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, fluxConfigurations dane zasobów są przechowywane zaszyfrowane w spoczynku w bazie danych usługi 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:

  • Sonduje usługę płaszczyzny danych konfiguracji kubernetes dla nowych lub zaktualizowanych fluxConfigurations zasobów.
  • Tworzy lub aktualizuje FluxConfig zasoby niestandardowe w klastrze przy użyciu informacji o konfiguracji.
  • Obserwuje FluxConfig zasoby niestandardowe i wypycha 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 wpis tajny uwierzytelniania na podstawie klucza prywatnego dostarczonego przez użytkownika/http basic-auth/known-hosts/no-auth danych.
  • Konfiguruje kontrolę dostępu opartą na rolach (aprowizowania konta usługi, tworzenia/przypisywania powiązania roli, tworzenia/przypisywania roli).
  • Tworzy GitRepository lub Bucket niestandardowy zasób i Kustomization zasoby niestandardowe na podstawie informacji w zasobie niestandardowym FluxConfig .

Każdy fluxConfigurations zasób na platformie Azure jest skojarzony z jednym zasobem flux GitRepository lub Bucket niestandardowym i co najmniej jednym Kustomization zasobem niestandardowym w klastrze Kubernetes. Podczas tworzenia fluxConfigurations zasobu należy określić adres URL źródła (repozytorium Git, zasobnika lub usługi Azure Blob Storage) oraz miejsce docelowe synchronizacji w źródle dla każdego Kustomizationelementu . 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

Monitory fluxconfig-agent nowych lub zaktualizowanych fluxConfiguration zasobów na platformie 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, zmieni się w klastrze, 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 zostanie przekroczone, a zmiany będą musiały zostać ponownie zastosować 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.

Uwaga

Jeśli używasz platformy Flux w wersji 1, zalecamy jak najszybszą migrację do platformy Flux w wersji 2 .

Obsługa zasobów konfiguracji klastra opartych na platformie Flux w wersji 1 utworzonych przed 1 stycznia 2024 r. zakończy się 24 maja 2025 r. Od 1 stycznia 2024 r. nie będzie można utworzyć nowych zasobów konfiguracji klastra opartego na platformie Flux w wersji 1.

Jeśli dodano obsługę łącza prywatnego do klastra Kubernetes z włączoną usługą Azure Arc, microsoft.flux rozszerzenie działa gotowe do użycia z komunikacją z powrotem na platformę 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 aprowizować te punkty końcowe za zaporą lub wyświetlić je na zaporze, aby kontroler źródła flux mógł pomyślnie nawiązać z nimi połączenie.

Przechowywanie 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ż usługa Azure Resource Manager zarządza konfiguracjami, możesz zautomatyzować tworzenie tej samej konfiguracji we wszystkich zasobach usługi Azure Kubernetes Service i kubernetes z włączoną usługą Azure Arc przy użyciu usługi 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).

Obsługa wielu dzierżawców

Platforma Flux v2 obsługuje wiele dzierżaw , począwszy od wersji 0.26. Ta funkcja jest zintegrowana z platformą Flux v2 na platformie Azure.

Uwaga

W przypadku funkcji wielodostępności musisz wiedzieć, czy manifesty zawierają jakiekolwiek źródła między przestrzeniami nazwRef for 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.

Aktualizowanie manifestów dla wielu dzierżaw

Załóżmy, że wdrożysz fluxConfiguration klaster w jednym z naszych klastrów Kubernetes w cluster-config przestrzeni nazw z zakresem klastra. Źródło należy skonfigurować tak, aby synchronizowało https://github.com/fluxcd/flux2-kustomize-helm-example repozytorium. 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 wdraża fluxConfigurations element przez personifikację flux-applier konta usługi wdrożonego cluster-config tylko w przestrzeni nazw. Użycie powyższych manifestów, gdy włączono wielodostępność, HelmRelease zostanie zablokowane. Jest to spowodowane tym HelmRelease , że element znajduje się w nginx przestrzeni nazw, ale odwołuje się do repozytorium HelmRepository w flux-system przestrzeni nazw. Ponadto flux helm-controller nie może zastosować HelmReleaseelementu , ponieważ nie flux-applier ma konta usługi w nginx przestrzeni nazw.

Aby pracować z wieloma dzierżawami, właściwym rozwiązaniem jest wdrożenie wszystkich obiektów Flux w tej samej przestrzeni nazw co fluxConfigurations. Takie podejście pozwala uniknąć problemu z odwołaniem między przestrzeniami nazw i umożliwia kontrolerom Flux uzyskanie uprawnień do stosowania obiektów. W związku z tym w przypadku konfiguracji GitOps utworzonej cluster-config w przestrzeni nazw następujące przykładowe manifesty uległy 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

Rezygnacja z wielodostępności

Po zainstalowaniu microsoft.flux rozszerzenia domyślnie jest włączona obsługa wielu dzierżaw. Jeśli musisz wyłączyć wielodostępność, możesz zrezygnować z tworzenia lub aktualizowania microsoft.flux rozszerzenia w klastrach za pomocą --configuration-settings multiTenancy.enforce=falsepolecenia , jak pokazano w poniższych przykładowych poleceniach:

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>

Migrowanie z platformy Flux v1

Jeśli nadal używasz platformy Flux w wersji 1, zalecamy jak najszybszą migrację do platformy Flux w wersji 2.

Aby przeprowadzić migrację do usługi Flux v2 w tych samych klastrach, w których używasz platformy Flux v1, należy najpierw usunąć wszystkie elementy Flux v1 sourceControlConfigurations z klastrów. Ponieważ platforma Flux v2 ma zasadniczo inną architekturę, microsoft.flux rozszerzenie klastra nie zostanie zainstalowane, jeśli w klastrze znajdują się zasoby Flux v1 sourceControlConfigurations . Proces usuwania konfiguracji platformy Flux w wersji 1 i wdrażania konfiguracji platformy Flux w wersji 2 nie powinien trwać dłużej niż 30 minut.

Usunięcie platformy Flux w wersji 1 sourceControlConfigurations nie powoduje zatrzymania żadnych aplikacji uruchomionych w klastrach. Jednak w okresie usunięcia konfiguracji platformy Flux v1 i rozszerzenie Flux v2 nie zostało jeszcze w pełni wdrożone:

  • Jeśli istnieją nowe zmiany w manifestach aplikacji przechowywanych w repozytorium Git, te zmiany nie są ściągane podczas migracji, a wersja aplikacji wdrożona w klastrze będzie nieaktualna.
  • Jeśli w stanie klastra nie są niezamierzone zmiany i odbiegają od żądanego stanu określonego w źródłowym repozytorium Git, klaster nie będzie mógł się samodzielnie leczyć.

Zalecamy przetestowanie scenariusza migracji w środowisku deweloperskim przed migracją środowiska produkcyjnego.

Wyświetlanie i usuwanie konfiguracji platformy Flux w wersji 1

Użyj tych poleceń interfejsu wiersza polecenia platformy Azure, aby znaleźć i usunąć istniejące sourceControlConfigurations w klastrze:

az k8s-configuration list --cluster-name <cluster name> --cluster-type <connectedClusters or managedClusters> --resource-group <resource group name>
az k8s-configuration delete --name <configuration name> --cluster-name <cluster name> --cluster-type <connectedClusters or managedClusters> --resource-group <resource group name>

Istniejące konfiguracje usługi GitOps dla klastra można również znaleźć i usunąć w witrynie Azure Portal. W tym celu przejdź do klastra, w którym została utworzona konfiguracja, i wybierz pozycję GitOps w okienku po lewej stronie. Wybierz konfigurację, a następnie wybierz pozycję Usuń.

Wdrażanie konfiguracji platformy Flux w wersji 2

Użyj witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure, aby zastosować konfiguracje platformy Flux w wersji 2 do klastrów.

Informacje o wycofaniu rozwiązania Flux v1

Projekt open source platformy Flux w wersji 1 został zarchiwizowany, a tworzenie funkcji zostało zatrzymane na czas nieokreślony.

Flux v2 został uruchomiony jako uaktualniony projekt open source Flux. Ma nową architekturę i obsługuje więcej przypadków użycia metodyki GitOps. Firma Microsoft uruchomiła wersję rozszerzenia przy użyciu platformy Flux v2 w maju 2022 r. Od tego czasu klienci zostali poinformowani o przejściu na platformę Flux v2 w ciągu trzech lat, ponieważ wsparcie dla korzystania z platformy Flux v1 ma zakończyć się w maju 2025 r.

Najważniejsze nowe funkcje wprowadzone w rozszerzeniu GitOps dla platformy Flux w wersji 2:

  • Flux v1 to monolityczny operator do-it-all. Flux v2 oddziela funkcje od wyspecjalizowanych kontrolerów (kontroler źródłowy, kontroler Kustomize, kontroler Helm i kontroler powiadomień).
  • Obsługuje synchronizację z wieloma repozytoriami źródłowymi.
  • Obsługuje wiele dzierżaw, takich jak stosowanie każdego repozytorium źródłowego z własnym zestawem uprawnień.
  • Udostępnia szczegółowe informacje operacyjne za pomocą kontroli kondycji, zdarzeń i alertów.
  • Obsługuje gałęzie git, przypinanie zatwierdzeń i tagów oraz podążanie za zakresami tagów SemVer.
  • Konfiguracja poświadczeń na zasób gitRepository: klucz prywatny SSH, nazwa użytkownika/hasło/hasło/token protokołu HTTP/S i klucze publiczne Protokołu OpenPGP.

Następne kroki