Tutorial: Bereitstellen von Anwendungen mithilfe von GitOps mit Flux v2
In diesem Tutorial wird beschrieben, wie Sie GitOps in einem Kubernetes-Cluster verwenden. GitOps mit Flux v2 ist in Kubernetes-Clustern mit Azure Arc-Unterstützung oder AKS-Clustern (Azure Kubernetes Service) als Clustererweiterung aktiviert. Nachdem die Clustererweiterung microsoft.flux
installiert wurde, können Sie eine oder mehrere fluxConfigurations
-Ressourcen erstellen, die Ihre Git-Repositoryquellen mit dem Cluster synchronisieren und den Cluster mit dem gewünschten Zustand abstimmen. Mit GitOps können Sie Ihr Git-Repository als Quelle der Wahrheit für die Clusterkonfiguration und Anwendungsbereitstellung verwenden.
In diesem Tutorial verwenden wir eine GitOps-Beispielkonfiguration mit zwei Kustomizations, damit Sie sehen können, wie eine Kustomization von einer anderen abhängig sein kann. Je nach Szenario können Sie weitere Kustomizations und Abhängigkeiten hinzufügen.
Nehmen Sie sich vor dem Einarbeiten einen Moment Zeit, um zu erfahren, wie GitOps mit Flux konzeptionell funktioniert.
Tipp
In diesem Tutorial ist die Quelle ein Git-Repository, doch bietet Flux auch Unterstützung für andere gängige Dateiquellen wie Helm-Repositorys, Buckets und Azure Blob Storage.
Sie können Flux-Konfigurationen auch mithilfe von Bicep, ARM-Vorlagen oder des Terraform AzAPI-Anbieters erstellen. Weitere Informationen finden Sie unter Microsoft.KubernetesConfiguration fluxConfigurations.
Wichtig
Mit der microsoft.flux
-Erweiterung wurde die Hauptversion 1.0.0 veröffentlicht. Diese enthält das Mehrinstanzenfähigkeits-Feature. Wenn Sie über vorhandene GitOps Flux v2-Konfigurationen verfügen, die eine frühere Version der microsoft.flux
-Erweiterung verwenden, können Sie manuell mithilfe der Azure CLI ein Upgrade auf die aktuelle Version durchführen: az k8s-extension create -g <RESOURCE_GROUP> -c <CLUSTER_NAME> -n flux --extension-type microsoft.flux -t <CLUSTER_TYPE>
. (Verwenden Sie -t connectedClusters
für Arc-Cluster und -t managedClusters
für AKS Cluster.)
Voraussetzungen
Zum Bereitstellen von Anwendungen mithilfe von GitOps mit Flux v2 benötigen Sie Folgendes:
Für Kubernetes-Cluster mit Azure Arc-Unterstützung
Einen verbundenen Kubernetes-Cluster mit Azure Arc-Unterstützung, der aktiv ist und ausgeführt wird. ARM64-basierte Cluster werden ab
microsoft.flux
-Version 1.7.0 unterstützt.Erfahren Sie, wie Sie einen Kubernetes-Cluster mit Azure Arc verbinden. Wenn Sie eine Verbindung über einen Proxy für ausgehenden Datenverkehr herstellen müssen, stellen Sie sicher, dass Sie die Arc-Agents mit Proxyeinstellungen installieren.
Lese- und Schreibberechtigungen für den Ressourcentyp
Microsoft.Kubernetes/connectedClusters
Für Azure Kubernetes Service-Cluster
Einen MSI-basierten AKS-Cluster, der aktiv ist und ausgeführt wird.
Wichtig
Stellen Sie sicher, dass der AKS-Cluster mit einer MSI (nicht SPN) erstellt wird, da die Erweiterung
microsoft.flux
nicht mit SPN-basierten AKS-Clustern funktioniert. Bei neuen AKS-Clustern, die mitaz aks create
erstellt werden, ist der Cluster standardmäßig MSI-basiert. Bei bereits erstellten SPN-basierten Clustern, die in MSI konvertiert werden müssen, führen Sieaz aks update -g $RESOURCE_GROUP -n $CLUSTER_NAME --enable-managed-identity
aus. Weitere Informationen finden Sie unter Verwenden einer verwalteten Identität in Azure Kubernetes Service.Lese- und Schreibberechtigungen für den Ressourcentyp
Microsoft.ContainerService/managedClusters
Für beide Clustertypen
Lese- und Schreibberechtigungen für diese Ressourcentypen:
Microsoft.KubernetesConfiguration/extensions
Microsoft.KubernetesConfiguration/fluxConfigurations
Azure-Befehlszeilenschnittstelle ab Version 2.15. Installieren Sie die Azure-Befehlszeilenschnittstelle, oder verwenden Sie die folgenden Befehle, um ein Update auf die neueste Version auszuführen:
az version az upgrade
Der Kubernetes-Befehlszeilenclient kubectl.
kubectl
ist bei Verwendung von Azure Cloud Shell bereits installiert.Verwenden Sie für die lokale Installation von
kubectl
den Befehlaz aks install-cli
:az aks install-cli
Registrierung der folgenden Azure-Ressourcenanbieter:
az provider register --namespace Microsoft.Kubernetes az provider register --namespace Microsoft.ContainerService az provider register --namespace Microsoft.KubernetesConfiguration
Die Registrierung ist ein asynchroner Prozess und sollte innerhalb von 10 Minuten abgeschlossen sein. Verwenden Sie zum Überwachen des Registrierungsprozesses den folgenden Befehl:
az provider show -n Microsoft.KubernetesConfiguration -o table Namespace RegistrationPolicy RegistrationState --------------------------------- -------------------- ------------------- Microsoft.KubernetesConfiguration RegistrationRequired Registered
Versions- und Regionsunterstützung
GitOps wird derzeit in allen Regionen unterstützt, die Kubernetes mit Azure Arc-Unterstützung unterstützt. GitOps wird derzeit in einer Teilmenge der Regionen unterstützt, die AKS unterstützt. Der GitOps-Dienst fügt in regelmäßigen Abständen neue unterstützte Regionen hinzu.
Die neueste Version der Flux v2-Erweiterung und die beiden vorherigen Versionen (N-2) werden unterstützt. Im Allgemeinen wird empfohlen, die neueste Version der Erweiterung zu verwenden.
Netzwerkanforderungen
Die GitOps-Agents erfordern ein ausgehendes TCP an die Repository-Quelle auf Port 22 (SSH) oder Port 443 (HTTPS), um zu funktionieren. Außerdem benötigen die Agents Zugriff auf die folgenden ausgehenden URLs:
Endpunkt (DNS) | BESCHREIBUNG |
---|---|
https://management.azure.com |
Erforderlich, damit der Agent mit dem Kubernetes-Konfigurationsdienst kommunizieren kann. |
https://<region>.dp.kubernetesconfiguration.azure.com |
Endpunkt auf Datenebene, über den der Agent Statusinformationen mithilfe von Push übermitteln und Konfigurationsinformationen abrufen kann Hängt von <region> (den zuvor erwähnten unterstützten Regionen) ab. |
https://login.microsoftonline.com |
Erforderlich zum Abrufen und Aktualisieren von Azure Resource Manager-Token. |
https://mcr.microsoft.com |
Erforderlich zum Pullen von Containerimages für Flux-Controller. |
Aktivieren der CLI-Erweiterungen
Installieren Sie die neuesten CLI-Erweiterungspakete k8s-configuration
und k8s-extension
:
az extension add -n k8s-configuration
az extension add -n k8s-extension
So aktualisieren Sie diese Pakete auf die neuesten Versionen
az extension update -n k8s-configuration
az extension update -n k8s-extension
Verwenden Sie den folgenden Befehl, um eine Liste aller installierten Azure CLI-Erweiterungen und deren Versionen anzuzeigen:
az extension list -o table
Experimental ExtensionType Name Path Preview Version
------------- -------------- ----------------- ----------------------------------------------------- -------- --------
False whl connectedk8s C:\Users\somename\.azure\cliextensions\connectedk8s False 1.2.7
False whl k8s-configuration C:\Users\somename\.azure\cliextensions\k8s-configuration False 1.5.0
False whl k8s-extension C:\Users\somename\.azure\cliextensions\k8s-extension False 1.1.0
Tipp
Hilfe beim Beheben von Fehlern finden Sie im Abschnitt GitOps (Flux v2) von Beheben von Erweiterungsproblemen für Azure Arc-fähige Kubernetes-Cluster.
Anwenden einer Flux-Konfiguration
Verwenden Sie Azure CLI-Erweiterung k8s-configuration
oder das Azure-Portal, um GitOps in einem AKS-Cluster oder einem Kubernetes-Cluster mit Azure Arc-Unterstützung zu aktivieren. Verwenden Sie für eine Demonstration das öffentliche Repository gitops-flux2-kustomize-helm-mt.
Wichtig
Das Demo-Repository soll die Nutzung dieses Tutorials vereinfachen und einige wichtige Prinzipien veranschaulichen. Um auf dem neuesten Stand zu bleiben, kann das Repository gelegentlich Breaking Changes von Versionsupgrades abrufen. Diese Änderungen wirken sich nicht auf Ihre neue Anwendung aus diesem Tutorial aus, nur auf frühere Tutorialanwendungen, die nicht gelöscht wurden. Informationen dazu, wie Sie mit diesen Änderungen umgehen, finden Sie im Haftungsausschluss zu Breaking Changes.
Im folgenden Beispiel wird der az k8s-configuration flux create
-Befehl verwendet, um eine Flux-Konfiguration auf einen Cluster anzuwenden, wobei die folgenden Werte und Einstellungen verwendet werden:
- Die Ressourcengruppe, die den Cluster enthält, lautet
flux-demo-rg
. - Der Name des Azure Arc-Clusters lautet
flux-demo-arc
. - Der Clustertyp ist Azure Arc (
-t connectedClusters
), aber dieses Beispiel funktioniert auch mit AKS (-t managedClusters
). - Der Name der Flux-Konfiguration lautet
cluster-config
. - Der Namespace für die Konfigurationsinstallation lautet
cluster-config
. - Die URL für das öffentliche Git-Repository lautet
https://github.com/Azure/gitops-flux2-kustomize-helm-mt
. - Der Git-Repositorybranch ist
main
. - Der Bereich der Konfiguration ist
cluster
. Mit diesem Bereich wird den Operatoren die Berechtigung für Änderungen im gesamten Cluster erteilt. Informationen zum Verwenden desnamespace
-Bereichs mit diesem Tutorial finden Sie in den erforderlichen Änderungen. - Zwei Kustomizations werden mit den Namen
infra
undapps
angegeben. Jede ist einem Pfad im Repository zugeordnet. - Die Kustomization
apps
hängt von der Kustomizationinfra
ab. (Die Kustomizationinfra
muss abgeschlossen sein, bevor die Kustomizationapps
ausgeführt wird.) - Legen Sie
prune=true
für beide Kustomizations fest. Mit dieser Einstellung wird sichergestellt, dass die von Flux im Cluster bereitgestellten Objekte bereinigt werden, wenn sie aus dem Repository entfernt oder die Flux-Konfiguration oder -Anpassungen gelöscht werden.
az k8s-configuration flux create -g flux-demo-rg \
-c flux-demo-arc \
-n cluster-config \
--namespace cluster-config \
-t connectedClusters \
--scope cluster \
-u https://github.com/Azure/gitops-flux2-kustomize-helm-mt \
--branch main \
--kustomization name=infra path=./infrastructure prune=true \
--kustomization name=apps path=./apps/staging prune=true dependsOn=\["infra"\]
Die microsoft.flux
-Erweiterung wird im Cluster installiert (sofern sie nicht schon aufgrund einer vorherigen GitOps-Bereitstellung installiert wurde).
Tipp
Der az k8s-configuration flux create
-Befehl stellt die microsoft.flux
-Erweiterung im Cluster bereit und erstellt die Konfiguration. Bei einigen Szenarien wird empfohlen, die Flux-Erweiterungsinstanz separat zu erstellen, bevor Sie Ihre Konfigurationsressourcen erstellen. Verwenden Sie dazu den az k8s-extension create
-Befehl, um eine Instanz der Erweiterung in Ihrem Cluster zu erstellen.
Wenn die Flux-Konfiguration zuerst installiert wird, kann der anfängliche Konformitätszustand Pending
oder Non-compliant
sein, da die Abstimmung noch ausgeführt wird. Nach etwa einer Minute können Sie die Konfiguration erneut abfragen, um den endgültigen Konformitätszustand anzuzeigen.
az k8s-configuration flux show -g flux-demo-rg -c flux-demo-arc -n cluster-config -t connectedClusters
Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Bereitstellung erfolgreich war:
az k8s-configuration flux show -g flux-demo-rg -c flux-demo-arc -n cluster-config -t connectedClusters
Bei einer erfolgreichen Bereitstellung werden die folgenden Namespaces erstellt:
flux-system
: enthält die Flux-Erweiterungscontrollercluster-config
: enthält die Flux-Konfigurationsobjektenginx
,podinfo
,redis
: Namespaces für Workloads, die in Manifesten im Git-Repository beschrieben werden.
Führen Sie den folgenden Befehl aus, um die Namespaces zu überprüfen:
kubectl get namespaces
Der flux-system
-Namespace enthält die Flux-Erweiterungsobjekte:
- Azure-Flux-Controller:
fluxconfig-agent
,fluxconfig-controller
- OSS-Flux-Controller:
source-controller
,kustomize-controller
,helm-controller
,notification-controller
Die Flux-Agent- und -Controllerpods sollten sich in einem ausgeführten Zustand befinden. Überprüfen Sie dies mit dem folgenden Befehl:
kubectl get pods -n flux-system
NAME READY STATUS RESTARTS AGE
fluxconfig-agent-9554ffb65-jqm8g 2/2 Running 0 21m
fluxconfig-controller-9d99c54c8-nztg8 2/2 Running 0 21m
helm-controller-59cc74dbc5-77772 1/1 Running 0 21m
kustomize-controller-5fb7d7b9d5-cjdhx 1/1 Running 0 21m
notification-controller-7d45678bc-fvlvr 1/1 Running 0 21m
source-controller-df7dc97cd-4drh2 1/1 Running 0 21m
Der cluster-config
-Namespace enthält die Flux-Konfigurationsobjekte.
kubectl get crds
NAME CREATED AT
alerts.notification.toolkit.fluxcd.io 2022-04-06T17:15:48Z
arccertificates.clusterconfig.azure.com 2022-03-28T21:45:19Z
azureclusteridentityrequests.clusterconfig.azure.com 2022-03-28T21:45:19Z
azureextensionidentities.clusterconfig.azure.com 2022-03-28T21:45:19Z
buckets.source.toolkit.fluxcd.io 2022-04-06T17:15:48Z
connectedclusters.arc.azure.com 2022-03-28T21:45:19Z
customlocationsettings.clusterconfig.azure.com 2022-03-28T21:45:19Z
extensionconfigs.clusterconfig.azure.com 2022-03-28T21:45:19Z
fluxconfigs.clusterconfig.azure.com 2022-04-06T17:15:48Z
gitconfigs.clusterconfig.azure.com 2022-03-28T21:45:19Z
gitrepositories.source.toolkit.fluxcd.io 2022-04-06T17:15:48Z
helmcharts.source.toolkit.fluxcd.io 2022-04-06T17:15:48Z
helmreleases.helm.toolkit.fluxcd.io 2022-04-06T17:15:48Z
helmrepositories.source.toolkit.fluxcd.io 2022-04-06T17:15:48Z
imagepolicies.image.toolkit.fluxcd.io 2022-04-06T17:15:48Z
imagerepositories.image.toolkit.fluxcd.io 2022-04-06T17:15:48Z
imageupdateautomations.image.toolkit.fluxcd.io 2022-04-06T17:15:48Z
kustomizations.kustomize.toolkit.fluxcd.io 2022-04-06T17:15:48Z
providers.notification.toolkit.fluxcd.io 2022-04-06T17:15:48Z
receivers.notification.toolkit.fluxcd.io 2022-04-06T17:15:48Z
volumesnapshotclasses.snapshot.storage.k8s.io 2022-03-28T21:06:12Z
volumesnapshotcontents.snapshot.storage.k8s.io 2022-03-28T21:06:12Z
volumesnapshots.snapshot.storage.k8s.io 2022-03-28T21:06:12Z
websites.extensions.example.com 2022-03-30T23:42:32Z
Überprüfen Sie mithilfe der folgenden Befehle weitere Details der Konfiguration:
kubectl get fluxconfigs -A
NAMESPACE NAME SCOPE URL PROVISION AGE
cluster-config cluster-config cluster https://github.com/Azure/gitops-flux2-kustomize-helm-mt Succeeded 44m
kubectl get gitrepositories -A
NAMESPACE NAME URL READY STATUS AGE
cluster-config cluster-config https://github.com/Azure/gitops-flux2-kustomize-helm-mt True Fetched revision: main/4f1bdad4d0a54b939a5e3d52c51464f67e474fcf 45m
kubectl get helmreleases -A
NAMESPACE NAME READY STATUS AGE
cluster-config nginx True Release reconciliation succeeded 66m
cluster-config podinfo True Release reconciliation succeeded 66m
cluster-config redis True Release reconciliation succeeded 66m
kubectl get kustomizations -A
NAMESPACE NAME READY STATUS AGE
cluster-config cluster-config-apps True Applied revision: main/4f1bdad4d0a54b939a5e3d52c51464f67e474fcf 65m
cluster-config cluster-config-infra True Applied revision: main/4f1bdad4d0a54b939a5e3d52c51464f67e474fcf 65m
Workloads werden über Manifeste im Git-Repository bereitgestellt.
kubectl get deploy -n nginx
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-ingress-controller 1/1 1 1 67m
nginx-ingress-controller-default-backend 1/1 1 1 67m
kubectl get deploy -n podinfo
NAME READY UP-TO-DATE AVAILABLE AGE
podinfo 1/1 1 1 68m
kubectl get all -n redis
NAME READY STATUS RESTARTS AGE
pod/redis-master-0 1/1 Running 0 68m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/redis-headless ClusterIP None <none> 6379/TCP 68m
service/redis-master ClusterIP 10.0.13.182 <none> 6379/TCP 68m
NAME READY AGE
statefulset.apps/redis-master 1/1 68m
Steuern, welche Controller mit der Flux-Clustererweiterung bereitgestellt werden
In einigen Szenarien sollten Sie möglicherweise ändern, welche Flux-Controller mit der Flux-Clustererweiterung installiert werden.
Die Flux-Controller source
, helm
, kustomize
und notification
werden standardmäßig installiert. Die image-automation
- und image-reflector
-Controller, die zum Aktualisieren eines Git-Repositorys verwendet werden, wenn neue Containerimages verfügbar sind, müssen explizit aktiviert werden.
Sie können den k8s-extension
-Befehl verwenden, um die Standardoptionen zu ändern:
--config source-controller.enabled=<true/false>
(Standard:true
)--config helm-controller.enabled=<true/false>
(Standard:true
)--config kustomize-controller.enabled=<true/false>
(Standard:true
)--config notification-controller.enabled=<true/false>
(Standard:true
)--config image-automation-controller.enabled=<true/false>
(Standard:false
)--config image-reflector-controller.enabled=<true/false>
(Standard:false
)
Zum Deaktivieren von Benachrichtigungen können Sie beispielsweise notification-controller.enabled
auf false
festlegen.
Mit diesem Beispielbefehl werden die image-reflector
- und image-automation
-Controller installiert. Wenn die Flux-Erweiterung automatisch erstellt wurde, als eine Flux-Konfiguration zum ersten Mal erstellt wurde, lautet der Erweiterungsname flux
.
az k8s-extension create -g <cluster_resource_group> -c <cluster_name> -t <connectedClusters or managedClusters or provisionedClusters> --name flux --extension-type microsoft.flux --config image-automation-controller.enabled=true image-reflector-controller.enabled=true
Verwenden der Kubelet-Identität als Authentifizierungsmethode für AKS-Cluster
Bei AKS-Clustern ist eine der möglichen Authentifizierungsoptionen die Kubelet-Identität. Standardmäßig erstellt AKS eine eigene Kubelet-Identität in der verwalteten Ressourcengruppe. Wenn Sie möchten, können Sie eine vorab erstellte verwaltete Kubelet-Identität verwenden. Fügen Sie dazu den Parameter --config useKubeletIdentity=true
zum Zeitpunkt der Installation der Flux-Erweiterung hinzu.
az k8s-extension create --resource-group <resource-group> --cluster-name <cluster-name> --cluster-type managedClusters --name flux --extension-type microsoft.flux --config useKubeletIdentity=true
Leitfaden zum Onboarding von Red Hat OpenShift
Flux-Controller erfordern eine Sicherheitskontexteinschränkung ohne Root-Berechtigung, damit Pods im Cluster ordnungsgemäß bereitgestellt werden können. Diese Einschränkungen müssen dem Cluster hinzugefügt werden, bevor die microsoft.flux
-Erweiterung bereitgestellt wird.
NS="flux-system"
oc adm policy add-scc-to-user nonroot system:serviceaccount:$NS:kustomize-controller
oc adm policy add-scc-to-user nonroot system:serviceaccount:$NS:helm-controller
oc adm policy add-scc-to-user nonroot system:serviceaccount:$NS:source-controller
oc adm policy add-scc-to-user nonroot system:serviceaccount:$NS:notification-controller
oc adm policy add-scc-to-user nonroot system:serviceaccount:$NS:image-automation-controller
oc adm policy add-scc-to-user nonroot system:serviceaccount:$NS:image-reflector-controller
Weitere Informationen zum OpenShift-Leitfaden für das Onboarding von Flux finden Sie in der Flux-Dokumentation.
Arbeiten mit Parametern
Flux unterstützt viele Parameter, um verschiedene Szenarien zu ermöglichen. Eine Beschreibung aller Parameter, die von Flux unterstützt werden, finden Sie in der offiziellen Flux-Dokumentation. In Azure unterstützt Flux noch nicht alle Parameter. Teilen Sie uns mit, wenn ein von Ihnen benötigter Parameter in der Azure-Implementierung fehlt.
Informationen zu verfügbaren Parametern und deren Verwendung finden Sie unter GitOps (Flux v2) unterstützte Parameter.
Verwenden eines lokalen Geheimnisses als Authentifizierungsverweis
Um ein lokales Geheimnis als Authentifizierungsverweis zu verwenden, muss das Geheimnis im selben Namespace enthalten sein, in dem die fluxConfiguration
bereitgestellt wird. Das Geheimnis muss auch alle für die Quelle erforderlichen Authentifizierungsparameter enthalten.
Weitere Informationen zum Erstellen von Geheimnissen für verschiedene fluxConfiguration
-Quellen finden Sie unter Lokales Geheimnis für die Authentifizierung bei einer Quelle.
Verwalten der Clusterkonfiguration mit dem Flux Kustomize-Controller
Der Flux Kustomize-Controller wird als Teil der Clustererweiterung microsoft.flux
installiert. Er ermöglicht die deklarative Verwaltung von Clusterkonfiguration und Anwendungsbereitstellung mithilfe von Kubernetes-Manifesten, die aus einem Git-Repository synchronisiert werden. Diese Kubernetes-Manifeste können optional die Datei kustomize.yaml enthalten.
Details zur Verwendung finden Sie in den folgenden Ressourcen:
- Flux Kustomize-Controller
- Kustomize-Referenzdokumente
- Die kustomization-Datei
- Kustomize-Projekt
- Kustomize-Leitfäden
Verwalten von Helm-Chartversionen mit dem Flux Helm-Controller
Der Flux Helm-Controller wird als Teil der Clustererweiterung microsoft.flux
installiert. Damit können Sie Helm-Chartversionen deklarativ mit Kubernetes-Manifesten verwalten, die Sie in Ihrem Git-Repository verwalten.
Details zur Verwendung finden Sie in den folgenden Ressourcen:
- Flux für Helm-Benutzer*innen
- Verwalten von Helm-Releases
- Migrieren von Flux v1 Helm zu Flux v2 Helm
- Flux Helm-Controller
Tipp
Weil Helm Indexdateien auf eine bestimmte Art verarbeitet, fällt die Verarbeitung von Helm-Diagrammen teuer aus und kann einen sehr hohen Speicherbedarf erfordern. Der parallele Abgleich einer großen Anzahl von Helm-Diagrammen kann daher zu Speicherspitzen und zum Fehler OOMKilled
führen. Standardmäßig legt der Controller seinen Speichergrenzwert auf 1 GiB und seine Speicheranforderungen auf 64 MiB fest. Wenn Sie diesen Grenzwert und die Anzahl an Anforderungen aufgrund einer hohen Anzahl großer Helm-Diagrammabgleiche erhöhen möchten, führen Sie den folgenden Befehl nach der Installation der microsoft.flux-Erweiterung aus:
az k8s-extension update -g <resource-group> -c <cluster-name> -n flux -t connectedClusters --config source-controller.resources.limits.memory=2Gi source-controller.resources.requests.memory=300Mi
Verwenden der GitRepository-Quelle für Helm-Diagramme
Wenn Ihre Helm-Diagramme in der Quelle GitRepository
gespeichert sind, die Sie als Teil der fluxConfigurations
-Ressource konfigurieren, können Sie Ihrer Datei „HelmRelease.yaml“ wie im folgenden Beispiel gezeigt clusterconfig.azure.com/use-managed-source: "true"
hinzufügen, um anzugeben, dass die konfigurierte Quelle als Quelle der Helm-Diagramme verwendet werden soll:
---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
name: somename
namespace: somenamespace
annotations:
clusterconfig.azure.com/use-managed-source: "true"
spec:
...
Wenn Sie diese Anmerkung verwenden, wird das bereitgestellte HelmRelease mit dem Verweis auf die konfigurierte Quelle gepatcht. Derzeit wird nur die GitRepository
-Quelle unterstützt.
Drifterkennung in Helm
Die Drifterkennung für Helm-Releases ist standardmäßig nicht aktiviert. Ab microsoft.flux
Version 1.7.5 können Sie die Drifterkennung in Helm über den folgenden Befehl aktivieren:
az k8s-extension update --resource-group <resource-group> --cluster-name <cluster-name> --name flux --cluster-type <cluster-type> --config helm-controller.detectDrift=true
Strenge Nachbuildvariablenersetzung
Die strenge Nachbuildvariablenersetzung wird ab microsoft.flux
v1.13.1 verfügbar sein.
Führen Sie den folgenden Befehl aus, um eine Flux-Erweiterung mit aktivierter strikter Ersetzungsrichtlinie zu erstellen:
az k8s-extension create --resource-group <resource-group> --cluster-name <cluster-name> --cluster-type <cluster-type> --name flux --extension-type microsoft.flux --config kustomize-controller.strict-substitution-mode=true
Führen Sie den folgenden Befehl aus, um eine vorhandene Flux-Erweiterung zu aktualisieren, um eine strenge Ersetzungsrichtlinie zu aktivieren:
az k8s-extension update --resource-group <resource-group> --cluster-name <cluster-name> --cluster-type <cluster-type> --name flux --config kustomize-controller.strict-substitution-mode=true
Vertikale Skalierung
Unterstützung für die vertikale Skalierung ist ab microsoft.flux
v1.12.0 verfügbar. Derzeit werden nur spezifische Parameter unterstützt, die in der Dokumentation zur vertikalen Skalierung von Flux beschrieben werden. Andere Parameter können manuell auf den Cluster angewandt werden.
Führen Sie diesen Befehl aus, um die Ressourcengrenzwerte für Controller über die aktuellen Grenzwerte hinaus zu erhöhen. Ändern Sie dabei den jeweiligen Ressourcentyp und Wert nach Bedarf:
az k8s-extension update --resource-group <resource-group> --cluster-name <cluster-name> --cluster-type <cluster-type> --name flux --config kustomize-controller.resources.limits.memory=2Gi kustomize-controller.resources.limits.cpu=2000m
Führen Sie den folgenden Befehl aus, um die Anzahl der Abgleiche zu erhöhen, die parallel ausgeführt werden können:
az k8s-extension update --resource-group <resource-group> --cluster-name <cluster-name> --cluster-type <cluster-type> --name flux --config kustomize-controller.concurrent=6 kustomize-controller.requeue-dependency=50s
Führen Sie den folgenden Befehl aus, um die Erstellung im Arbeitsspeicher zu aktivieren:
az k8s-extension update --resource-group <resource-group> --cluster-name <cluster-name> --cluster-type <cluster-type> --name flux --config kustomize-controller.enable-in-memory-build=true
OOM-Überwachung in Helm
Ab microsoft.flux
Version 1.7.5 können Sie die OOM-Überwachung in Helm aktivieren. Weitere Informationen finden Sie unter Aktivieren der Erkennung von Zuständen nahe OOM in Helm.
Überprüfen Sie bei Aktivierung dieses Features potenzielle Wartungsstrategien, und wenden Sie sie nach Bedarf an.
Führen Sie den folgenden Befehl aus, um die OOM-Überwachung zu aktivieren:
az k8s-extension update --resource-group <resource-group> --cluster-name <cluster-name> --name flux --cluster-type <cluster-type> --config helm-controller.outOfMemoryWatch.enabled=true helm-controller.outOfMemoryWatch.memoryThreshold=70 helm-controller.outOfMemoryWatch.interval=700ms
Wenn Sie keine Werte für memoryThreshold
und outOfMemoryWatch
angeben, wird der Standardspeicherschwellenwert auf 95 % mit einem Intervall für die Überprüfung der Speicherauslastung von 500 ms festgelegt.
Konfigurierbare Protokolliergrad-Parameter
Standardmäßig ist die log-level
für Flux-Controller auf info
festgelegt. Ab microsoft.flux
v1.8.3 können Sie diese Standardeinstellungen mit dem Befehl k8s-extension
wie folgt ändern:
--config helm-controller.log-level=<info/error/debug>
--config source-controller.log-level=<info/error/debug>
--config kustomize-controller.log-level=<info/error/debug>
--config notification-controller.log-level=<info/error/debug>
--config image-automation-controller.log-level=<info/error/debug>
--config image-reflector-controller.log-level=<info/error/debug>
Gültige Werte sind debug
, info
oder error
. Verwenden Sie beispielsweise den folgenden Befehl, um die log-level
für source-controller
und kustomize-controller
zu ändern:
az k8s-extension update --resource-group <resource-group> --cluster-name <cluster-name> --cluster-type <cluster-type> --name flux --config source-controller.log-level=error kustomize-controller.log-level=error
Ab microsoft.flux
v1.9.1 unterstützen fluxconfig-agent
und fluxconfig-controller
die Protokollebenen info
und error
(aber nicht debug
). Diese können mithilfe des Befehls „k8s-extension“ wie folgt geändert werden:
--config fluxconfig-agent.log-level=<info/error>
--config fluxconfig-controller.log-level=<info/error>
Beispielsweise ändert der folgender Befehl log-level
zu error
:
az k8s-extension update --resource-group <resource-group> --cluster-name <cluster-name> --cluster-type <cluster-type> --name flux --config fluxconfig-agent.log-level=error fluxconfig-controller.log-level=error
Einstellung von Azure DevOps SSH-RSA
Azure DevOps kündigte die Einstellung von SSH-RSA als unterstützte Verschlüsselungsmethode für die Verbindung mit Azure-Repositorys mit SSH an. Wenn Sie SSH-Schlüssel verwenden, um sich mit Azure-Repositorys in Flux-Konfigurationen zu verbinden, empfehlen wir den Wechsel zu sichereren RSA-SHA2-256- oder RSA-SHA2-512-Schlüsseln.
Beim Abgleich von Flux-Konfigurationen wird möglicherweise eine Fehlermeldung angezeigt, die besagt, dass ssh-rsa bald veraltet ist oder nicht mehr unterstützt wird. Wenn dies der Fall ist, aktualisieren Sie den Algorithmus für den Host-Schlüssel, der für den Aufbau von SSH-Verbindungen zu Azure DevOps-Repositorys von Flux source-controller
und image-automation-controller
(falls aktiviert) verwendet wird, mit dem Befehl az k8s-extension update
. Zum Beispiel:
az k8s-extension update --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type <cluster-type> --name flux --config source-controller.ssh-host-key-args="--ssh-hostkey-algos=rsa-sha2-512,rsa-sha2-256"
az k8s-extension update --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type <cluster-type> --name flux --config image-automation-controller.ssh-host-key-args="--ssh-hostkey-algos=rsa-sha2-512,rsa-sha2-256"
Weitere Informationen zur Einstellung von Azure DevOps SSH-RSA finden Sie unter Ende der SSH-RSA-Unterstützung für Azure Repos.
Konfigurieren der Anmerkung auf Flux-Erweiterungs-Pods
Wenn Sie eine andere Lösung als Azure Firewall konfigurieren, sind Netzwerk- und FQDN/Anwendungsregeln für einen AKS-Cluster erforderlich. Ab microsoft.flux
v1.11.1 können Flux-Controller-Pods nun die Anmerkung kubernetes.azure.com/set-kube-service-host-fqdn
in ihren Podspezifikationen festlegen. Dies ermöglicht den Datenverkehr zum Domänennamen des API-Servers, selbst wenn eine Layer 7-Firewall vorhanden ist, was die Bereitstellung bei der Installation von Erweiterungen erleichtert. Um diese Anmerkung bei Verwendung der Flux-Erweiterung zu konfigurieren, verwenden Sie die folgenden Befehle.
# Create flux extension with annotation
az k8s-extension create --resource-group <resource-group> --cluster-name <cluster-name> --cluster-type <cluster-type> --name flux --extension-type microsoft.flux --config setKubeServiceHostFqdn=true
# Update flux extension with annotation
az k8s-extension update --resource-group <resource-group> --cluster-name <cluster-name> --cluster-type <cluster-type> --name flux --config setKubeServiceHostFqdn=true
Arbeitsauslastungsidentität in AKS-Clustern
Ab microsoft.flux
v1.8.0 können Sie Flusskonfigurationen in AKS-Clustern mit aktivierter Workloadidentität erstellen. Ändern Sie dazu die Flusserweiterung wie in den folgenden Schritten dargestellt.
Rufen Sie die OIDC-Aussteller-URL für Ihren Cluster ab.
Erstellen Sie eine verwaltete Identität, und notieren Sie ihre Client-ID.
Erstellen Sie die Flusserweiterung auf dem Cluster, indem Sie den folgenden Befehl verwenden:
az k8s-extension create --resource-group <resource_group_name> --cluster-name <aks_cluster_name> --cluster-type managedClusters --name flux --extension-type microsoft.flux --config workloadIdentity.enable=true workloadIdentity.azureClientId=<user_assigned_client_id>
Einrichten von Anmeldeinformationen für eine Verbundidentität. Zum Beispiel:
# For source-controller az identity federated-credential create --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} --identity-name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --issuer "${AKS_OIDC_ISSUER}" --subject system:serviceaccount:"flux-system":"source-controller" --audience api://AzureADTokenExchange # For image-reflector controller if you plan to enable it during extension creation, it is not deployed by default az identity federated-credential create --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} --identity-name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --issuer "${AKS_OIDC_ISSUER}" --subject system:serviceaccount:"flux-system":"image-reflector-controller" --audience api://AzureADTokenExchange # For kustomize-controller az identity federated-credential create --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} --identity-name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --issuer "${AKS_OIDC_ISSUER}" --subject system:serviceaccount:"flux-system":"kustomize-controller" --audience api://AzureADTokenExchange
Stellen Sie sicher, dass die benutzerdefinierte Ressource, die die Workload-Identität verwenden muss, im Manifest den Wert
.spec.provider
aufazure
setzt. Zum Beispiel:apiVersion: source.toolkit.fluxcd.io/v1beta2 kind: HelmRepository metadata: name: acrrepo spec: interval: 10m0s type: <helm_repository_type> url: <helm_repository_link> provider: azure
Stellen Sie sicher, dass Sie für die Arbeitsauslastungsidentität die richtigen Berechtigungen für die Ressource bereitstellen, die vom Source-Controller oder Image-Reflector-Controller abgerufen werden soll. Wenn Sie beispielsweise Azure Container Registry verwenden, sind
AcrPull
Berechtigungen erforderlich.
Löschen der Flux-Konfiguration und -Erweiterung
Verwenden Sie die folgenden Befehle, um Ihre Flux-Konfiguration und ggf. auch die Flux-Erweiterung selbst zu löschen.
Löschen der Flux-Konfiguration
Mit dem folgenden Befehl werden sowohl die fluxConfigurations
-Ressource in Azure als auch die Flux-Konfigurationsobjekte im Cluster gelöscht. Da die Flux-Konfiguration ursprünglich mit dem Parameter prune=true
für die Kustomization erstellt wurde, werden alle Objekte entfernt, die im Cluster basierend auf Manifesten im Git-Repository erstellt wurden, wenn die Flux-Konfiguration entfernt wird. Dieser Befehl entfernt jedoch nicht die Flux-Erweiterung selbst.
az k8s-configuration flux delete -g flux-demo-rg -c flux-demo-arc -n cluster-config -t connectedClusters --yes
Löschen der Flux-Clustererweiterung
Wenn Sie die Flux-Erweiterung löschen, werden sowohl die microsoft.flux
-Erweiterungsressource in Azure als auch die Flux-Erweiterungsobjekte im Cluster entfernt.
Wichtig
Löschen Sie unbedingt alle Flux-Konfigurationen im Cluster, bevor Sie die Flux-Erweiterung löschen. Wenn Sie die Erweiterung löschen, ohne zuerst die Flusskonfigurationen zu löschen, kann Ihr Cluster in instabilem Zustand bleiben.
Wenn die Flux-Erweiterung automatisch erstellt wurde, als die Flux-Konfiguration zum ersten Mal erstellt wurde, lautet der Erweiterungsname flux
.
az k8s-extension delete -g flux-demo-rg -c flux-demo-arc -n flux -t connectedClusters --yes
Tipp
Diese Befehle verwenden -t connectedClusters
, was für einen Kubernetes-Cluster mit Azure Arc-Unterstützung geeignet ist. Verwenden Sie für einen AKS-Cluster stattdessen -t managedClusters
.
Nächste Schritte
- Erfahren Sie mehr über Konfigurationen und GitOps.
- Informieren Sie sich darüber, wie Sie GitOps mithilfe von Azure Policy im großen Stil erzwingen.
- Erfahren Sie mehr über das Überwachen des Status und der Aktivität von GitOps (Flux v2).