GitOps Flux v2-Konfigurationen mit AKS und Azure Arc-fähigem Kubernetes
Azure bietet Konfigurationsverwaltungsfunktionen unter Verwendung von GitOps in AKS-Clustern (Azure Kubernetes Service) und in Kubernetes-Clustern mit Azure Arc-Unterstützung.
Mit GitOps deklarieren Sie den gewünschten Zustand Ihrer Kubernetes-Cluster in Dateien in Git-Repositorys. Die Git-Repositorys können die folgenden Dateien enthalten:
- YAML-formatierte Manifeste, die Kubernetes-Ressourcen (z. B. Namespaces, Geheimnisse, Bereitstellungen usw.) beschreiben
- Helm-Charts für die Bereitstellung von Anwendungen
- Kustomize-Dateien zum Beschreiben umgebungsspezifischer Änderungen
Da diese Dateien in einem Git-Repository gespeichert werden, werden sie mit Versionsinformationen verwaltet, und Änderungen zwischen Versionen können leicht nachverfolgt werden. Kubernetes-Controller werden in den Clustern ausgeführt und stimmen den Clusterzustand kontinuierlich mit dem gewünschten Zustand ab, der im Git-Repository deklariert ist. Diese Operatoren ruft die Dateien aus den Git-Repositorys ab und wenden den gewünschten Zustand auf die Cluster an. Die Operatoren stellen außerdem kontinuierlich sicher, dass sich der Cluster im gewünschten Zustand befindet.
GitOps auf Azure Arc aktivierten Kubernetes oder Azure Kubernetes Service verwendet Flux, ein beliebtes Open-Source-Toolset. Flux bietet Unterstützung für gängige Dateiquellen (Git- und Helm-Repositorys, Buckets, Azure Blob Storage) und Vorlagentypen (YAML, Helm und Kustomize). Flux unterstützt unter anderem auch die Verwaltung von Mehrinstanzenfähigkeit und Bereitstellungsabhängigkeit.
Flux-Clustererweiterung
GitOps wird in einem Azure Arc aktivierten Kubernetes- oder AKS-Cluster als Microsoft.KubernetesConfiguration/extensions/microsoft.fluxClustererweiterungs-Ressource aktiviert. Die microsoft.flux Erweiterung muss im Cluster installiert werden, bevor eine oder mehrere fluxConfigurations erstellt werden können. Die Erweiterung wird automatisch installiert, wenn Sie die erste Microsoft.KubernetesConfiguration/fluxConfigurations in einem Cluster erstellen, oder Sie können sie manuell über das Portal, die Azure CLI (az k8s-extension create --extensionType=microsoft.flux), die ARM-Vorlage oder die REST-API installieren.
Versionsunterstützung
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.
Hinweis
Wenn Sie Flux v1 verwendet haben, wird empfohlen, so bald wie möglich zu Flux v2 zu migrieren .
Die Unterstützung für Flux v1-basierte Clusterkonfigurationsressourcen, die vor dem 1. Mai 2023 erstellt wurden, endet am 24. Mai 2025. Ab dem 1. Mai 2023 können Sie keine neuen Flux v1-basierten Clusterkonfigurationsressourcen erstellen.
Controller
Standardmäßig installiert die microsoft.flux Erweiterung die Flux-Controller (Source, Kustomize, Helm, Notification) und fluxConfig CRD, fluxconfig-agent und fluxconfig-controller. Sie können steuern, welcher dieser Controller installiert ist. Optional können Sie auch die Flux-Imageautomatisierungs- und Imagereflektorcontroller installieren, die Funktionen zum Aktualisieren und Abrufen von Docker-Images bereitstellen.
Flux Source Controller: Überwacht die
source.toolkit.fluxcd.iobenutzerdefinierten Ressourcen. Übernimmt die Synchronisierung zwischen den Git-Repositorys, Helm-Repositorys, Buckets und Azure Blob Storage. Behandelt die Autorisierung mit der Quelle für private Git- und Helm-Repositorys und Azure Blob Storage-Konten. Gibt die neuesten Änderungen an der Quelle über eine TAR-Archivdatei an.Flux Kustomize-Controller: Überwacht die
kustomization.toolkit.fluxcd.iobenutzerdefinierten Ressourcen. Wendet Kustomize- oder unformatierte YAML-Dateien aus der Quelle auf den Cluster an.Flux Helm-Controller: Überwacht die
helm.toolkit.fluxcd.iobenutzerdefinierten Ressourcen. Ruft das zugeordnete Diagramm aus der Helm-Repositoryquelle ab, die vom Quellcontroller angezeigt wird. Erstellt dieHelmChartbenutzerdefinierte Ressource und wendet dieHelmReleasemit der angegebenen Version, dem angegebenen Namen und den vom Kunden definierten Werten auf den Cluster an.Flux Notification-Controller: Überwacht die
notification.toolkit.fluxcd.iobenutzerdefinierten Ressourcen. Empfängt Benachrichtigungen von allen Flux-Controllern. Pushbenachrichtigungen an benutzerdefinierte Webhookendpunkte.Flux Benutzerdefinierte Ressourcendefinitionen:
kustomizations.kustomize.toolkit.fluxcd.ioimagepolicies.image.toolkit.fluxcd.ioimagerepositories.image.toolkit.fluxcd.ioimageupdateautomations.image.toolkit.fluxcd.ioalerts.notification.toolkit.fluxcd.ioproviders.notification.toolkit.fluxcd.ioreceivers.notification.toolkit.fluxcd.iobuckets.source.toolkit.fluxcd.iogitrepositories.source.toolkit.fluxcd.iohelmcharts.source.toolkit.fluxcd.iohelmrepositories.source.toolkit.fluxcd.iohelmreleases.helm.toolkit.fluxcd.iofluxconfigs.clusterconfig.azure.com
FluxConfig CRD: Benutzerdefinierte Ressourcendefinition für
fluxconfigs.clusterconfig.azure.combenutzerdefinierte Ressourcen, die Kubernetes-Objekte definierenFluxConfig.fluxconfig-agent: Zuständig für die Azure-Suche nach neuen oder aktualisierten
fluxConfigurationsRessourcen und für das Starten der zugeordneten Flux-Konfiguration im Cluster. Außerdem verantwortlich für das Pushen von Flux-Statusänderungen im Cluster an Azure für jedefluxConfigurationsRessource.fluxconfig-controller: Überwacht die
fluxconfigs.clusterconfig.azure.combenutzerdefinierten Ressourcen und reagiert auf Änderungen mit einer neuen oder aktualisierten Konfiguration von GitOps-Maschinen im Cluster.
Hinweis
Die microsoft.flux Erweiterung wird im flux-system Namespace installiert und verfügt über einen clusterweiten Bereich. Die Option zum Installieren dieser Erweiterung im Namespacebereich ist nicht verfügbar, und versuche, die Installation im Namespacebereich zu installieren, schlägt mit dem Fehler 400 fehl.
Flux-Konfigurationen
Sie erstellen Flux-Konfigurationsressourcen (Microsoft.KubernetesConfiguration/fluxConfigurations), um die GitOps-Verwaltung des Clusters aus Ihren Git-Repositorys, Bucketquellen oder Azure Blob Storage zu ermöglichen. Wenn Sie eine fluxConfigurations Ressource erstellen, werden die Werte, die Sie für die Parameter angeben, z. B. das Git-Zielrepository, verwendet, um die Kubernetes-Objekte zu erstellen und zu konfigurieren, die den GitOps-Prozess in diesem Cluster aktivieren. Um die Datensicherheit zu gewährleisten, werden die fluxConfigurations Ressourcendaten verschlüsselt im Ruhezustand vom Cluster-Konfigurationsdienst in einer Azure Cosmos DB-Datenbank gespeichert.
Die fluxconfig-agent und fluxconfig-controller Agents, die mit der Erweiterung microsoft.flux installiert wurden, verwalten den GitOps-Konfigurationsprozess.
fluxconfig-agent ist für die folgenden Aufgaben zuständig:
- Fragt den Kubernetes Configuration-Datenebenendienst nach neuen oder aktualisierten
fluxConfigurationsRessourcen ab. - Erstellt oder aktualisiert
FluxConfigbenutzerdefinierte Ressourcen im Cluster mit den Konfigurationsinformationen. - Überwacht
FluxConfigbenutzerdefinierte Ressourcen und pusht Statusänderungen zurück an die zugeordneten Azure fluxConfiguration-Ressourcen.
fluxconfig-controller ist für die folgenden Aufgaben zuständig:
- Überwacht Statusaktualisierungen der von der verwalteten erstellten benutzerdefinierten
fluxConfigurationsFlux-Ressourcen. - Erstellt ein privates/öffentliches Schlüsselpaar, das für die Lebensdauer von
fluxConfigurationsvorhanden ist. Dieser Schlüssel wird für die Authentifizierung verwendet, wenn die URL SSH-basiert ist und der Benutzer während der Erstellung der Konfiguration keinen eigenen privaten Schlüssel bereitstellt. - Erstellt ein benutzerdefiniertes Authentifizierungsgeheimnis basierend auf vom Benutzer bereitgestellten Daten vom Datentyp private-key/http basic-auth/known-hosts/no-auth.
- Richtet RBAC ein (bereitgestelltes Dienstkonto, erstellte/zugewiesene Rollenbindung, erstellte/zugewiesene Rolle).
- Erstellt benutzerdefinierte
GitRepository- oderBucket-Ressourcen und benutzerdefinierteKustomization-Ressourcen aus den Informationen in der benutzerdefiniertenFluxConfig-Ressource.
Jede fluxConfigurations Ressource in Azure ist einer Flux GitRepository - oder Bucket benutzerdefinierten Ressource und mindestens einer Kustomization benutzerdefinierten Ressource in einem Kubernetes-Cluster zugeordnet. Wenn Sie eine fluxConfigurations Ressource erstellen, geben Sie die URL für die Quelle (Git-Repository, Bucket oder Azure Blob Storage) und das Synchronisierungsziel in der Quelle für jeden Kustomizationan. Sie können Abhängigkeiten zwischen Kustomization benutzerdefinierten Ressourcen konfigurieren, um die Bereitstellungssequenzierung zu steuern. Sie können auch mehrere namespacebezogene fluxConfigurations Ressourcen im selben Cluster für verschiedene Anwendungen und App-Teams erstellen.
Hinweis
fluxconfig-agent überwacht neue oder aktualisierte fluxConfiguration-Ressourcen in Azure. Für den Agent ist eine Verbindung mit Azure erforderlich, damit der gewünschte Zustand des fluxConfiguration auf den Cluster angewendet werden kann. Wenn der Agent keine Verbindung mit Azure herstellen kann, kommt es zu einer Verzögerung bei den Änderungen im Cluster, bis der Agent eine Verbindung herstellen kann. Wenn der Cluster länger als 48 Stunden von Azure getrennt ist, tritt für die Anforderung an den Cluster ein Timeout auf, und die Änderungen müssen in Azure erneut angewendet werden.
Vertrauliche Kundeneingaben wie private Schlüssel und das Token/Kennwort werden nicht länger als 48 Stunden im Kubernetes Konfigurationsdienst gespeichert. Wenn Sie einen dieser Werte in Azure aktualisieren, stellen Sie sicher, dass Ihre Cluster innerhalb von 48 Stunden eine Verbindung mit Azure herstellen.
GitOps mit Private Link
Wenn Sie Unterstützung für einen privaten Link zu einem Azure Arc-fähigen Kubernetes-Cluster hinzugefügt haben, funktioniert die microsoft.flux-Erweiterung ohne weitere Konfiguration mit Rückkommunikation zu Azure. Für Verbindungen mit Ihrem Git-Repository, Helm-Repository oder anderen Endpunkten, die zum Bereitstellen Ihrer Kubernetes-Manifeste erforderlich sind, müssen Sie diese Endpunkte hinter Ihrer Firewall bereitstellen oder in Ihrer Firewall auflisten, damit der Flux Source Controller sie erfolgreich erreichen kann.
Datenresidenz
Der Azure GitOps-Dienst (Azure Kubernetes-Konfigurationsverwaltung) speichert/verarbeitet Kundendaten. Standardmäßig werden Kundendaten in die gekoppelte Region repliziert. Für die Regionen „Singapur“, „Asien, Osten“ und „Brasilien, Süden“ werden alle Kundendaten in der Region gespeichert und verarbeitet.
Anwenden von Flux-Konfigurationen im großen Stil
Da Azure Resource Manager Ihre Konfigurationen verwaltet, können Sie mithilfe von Azure Policy im Rahmen eines Abonnements oder einer Ressourcengruppe automatisch dieselbe Konfiguration für alle Azure Kubernetes Service- und Azure Arc-fähigen Kubernetes-Ressourcen erstellen. Durch diese erzwingung im großen Stil wird sichergestellt, dass bestimmte Konfigurationen konsistent auf ganze Clustergruppen angewendet werden.
Erfahren Sie, wie Sie die integrierten Richtlinien für Flux v2 verwenden.
Parameter
Alle parameter, die von Flux in Azure unterstützt werden, finden Sie in der az k8s-configuration Dokumentation. Diese Implementierung unterstützt derzeit nicht jeden Parameter, den Flux unterstützt (siehe offizielle Flux-Dokumentation). Teilen Sie uns mit, wenn ein von Ihnen benötigter Parameter in der Azure-Implementierung fehlt.
Sie können auch die vollständige Liste der Parameter für die az k8s-configuration flux anzeigen, az k8s-configuration flux -h indem Sie den Parameter in der -h Azure CLI verwenden (z. B. oder az k8s-configuration flux create -h).
In den folgenden Informationen werden einige der Parameter und Argumente beschrieben, die für den az k8s-configuration flux create Befehl verfügbar sind.
Allgemeine Argumente für die Konfiguration
| Parameter | Format | Notizen |
|---|---|---|
--cluster-name -c |
String | Name der Clusterressource in Azure. |
--cluster-type -t |
Zulässige Werte: connectedClusters, managedClusters, provisionedClusters |
Verwenden Sie connectedClusters für Azure Arc-fähige Kubernetes-Cluster, managedClusters für AKS-Cluster oder provisionedClusters für von Azure bereitgestellte AKS-Hybridcluster (die Installation von Erweiterungen auf diesen Clustern befindet sich derzeit in der Vorschau). |
--resource-group -g |
String | Name der Azure-Ressourcengruppe, die die Clusterressource enthält. |
--name -n |
String | Name der Flux-Konfiguration in Azure. |
--namespace --ns |
String | Name des Namespace zum Bereitstellen der Konfiguration. Standardwert: default. |
--scope -s |
String | Berechtigungsbereich für die Operatoren. Mögliche Werte sind cluster (Vollzugriff) oder namespace (eingeschränkter Zugriff). Standardwert: cluster. |
--suspend |
Flag | Verwirft alle quell- und kustomize-Abstimmungen, die in dieser Flux-Konfiguration definiert sind. Abstimmungen, die zu diesem Zeitpunkt aktiv sind, werden fortgesetzt. |
Allgemeine Quellargumente
| Parameter | Format | Notizen |
|---|---|---|
--kind |
String | Quelltyp für die Abstimmung. Zulässige Werte: bucket, git und azblob. Standardwert: git. |
--timeout |
Golang-Format der Dauer | Maximale Zeit zum Abstimmen der Quelle vor dem Timeout. Standardwert: 10m. |
--sync-interval --interval |
Golang-Format der Dauer | Zeit zwischen Abstimmungen der Quelle im Cluster. Standardwert: 10m. |
Quellreferenzargumente für Git-Repositorys
| Parameter | Format | Notizen |
|---|---|---|
--branch |
String | Branch innerhalb der Git-Quelle für die Synchronisierung mit dem Cluster. Standardwert: master. Neuere Repositorys haben möglicherweise einen Stammbranch namens main. In diesem Fall müssen Sie --branch=main festlegen. |
--tag |
String | Tag innerhalb der Git-Quelle für die Synchronisierung mit dem Cluster. Beispiel: --tag=3.2.0. |
--semver |
String | Git-Tag semver-Bereich innerhalb der Git-Quelle für die Synchronisierung mit dem Cluster. Beispiel: --semver=">=3.1.0-rc.1 <3.2.0". |
--commit |
String | SHA für Git-Commit innerhalb der Git-Quelle für die Synchronisierung mit dem Cluster. Beispiel: --commit=363a6a8fe6a7f13e05d34c163b0ef02a777da20a. |
Weitere Informationen finden Sie in der Flux-Dokumentation zu Auscheckstrategien für Git-Repositorys.
Öffentliches Git-Repository
| Parameter | Format | Notizen |
|---|---|---|
--url -u |
http[s]://server/repo[.git] | URL der Git-Repositoryquelle, die mit dem Cluster abgestimmt werden soll. |
Privates Git-Repository mit SSH und mit Flux erstellten Schlüsseln
Fügen Sie den mit Flux generierten öffentlichen Schlüssel zum Benutzerkonto in Ihrem Git-Dienstanbieter hinzu.
| Parameter | Format | Notizen |
|---|---|---|
--url -u |
ssh://benutzer@server/repo[.git] | git@ sollte user@ ersetzen, wenn der öffentliche Schlüssel dem Repository und nicht dem Benutzerkonto zugeordnet ist. |
Privates Git-Repository mit SSH und benutzerseitig bereitgestellten Schlüsseln
Verwenden Sie Ihren eigenen privaten Schlüssel direkt oder in einer Datei. Der Schlüssel muss im PEM-Format sein und mit einem Zeilenumbruch (\n) enden.
Fügen Sie den zugeordneten öffentlichen Schlüssel zum Benutzerkonto in Ihrem Git-Dienstanbieter hinzu.
| Parameter | Format | Notizen |
|---|---|---|
--url -u |
ssh://benutzer@server/repo[.git] | git@ sollte user@ ersetzen, wenn der öffentliche Schlüssel dem Repository und nicht dem Benutzerkonto zugeordnet ist. |
--ssh-private-key |
Base64-Schlüssel im PEM-Format | Geben Sie den Schlüssel direkt an. |
--ssh-private-key-file |
Vollständiger Pfad zur lokalen Datei | Stellen Sie den vollständigen Pfad zur lokalen Datei bereit, die den Schlüssel im PEM-Format enthält. |
Privater Git-Host mit SSH und benutzerseitig bereitgestellten bekannten Hosts
Der Flux-Operator verwaltet eine Liste allgemeiner Git-Hosts in seiner Datei known_hosts. Flux verwendet diese Informationen, um das Git-Repository zu authentifizieren, bevor die SSH-Verbindung hergestellt wird. Wenn Sie ein ungewöhnliches Git-Repository oder Ihren eigenen Git-Host verwenden, können Sie den Hostschlüssel bereitstellen, damit Flux Ihr Repository identifizieren kann.
Wie private Schlüssel können Sie Ihren known_hosts-Inhalt (bekannte Hosts) direkt oder in einer Datei bereitstellen. Wenn Sie Ihren eigenen Inhalt bereitstellen, verwenden Sie die Spezifikationen des known_hosts-Inhaltformats zusammen mit einem der oben aufgeführten SSH-Schlüsselszenarien.
| Parameter | Format | Notizen |
|---|---|---|
--url -u |
ssh://benutzer@server/repo[.git] | git@ kann user@ ersetzen. |
--known-hosts |
Base64-Zeichenfolge | Geben Sie den known_hosts-Inhalt direkt an. |
--known-hosts-file |
Vollständiger Pfad zur lokalen Datei | Stellen Sie den known_hosts-Inhalt in einer lokalen Datei bereit. |
Privates Git-Repository mit einem HTTPS-Benutzer und -Schlüssel
| Parameter | Format | Notizen |
|---|---|---|
--url -u |
https://server/repo[.git] |
HTTPS mit der Basisauthentifizierung |
--https-user |
Rohzeichenfolge | HTTPS-Benutzername |
--https-key |
Rohzeichenfolge | Persönliches HTTPS-Zugriffstoken oder -Kennwort |
Privates Git-Repository mit einem HTTPS-Zertifikat einer Zertifizierungsstelle
| Parameter | Format | Notizen |
|---|---|---|
--url -u |
https://server/repo[.git] |
HTTPS mit der Basisauthentifizierung |
--https-ca-cert |
Base64-Zeichenfolge | Zertifizierungsstellenzertifikat für die TLS-Kommunikation |
--https-ca-cert-file |
Vollständiger Pfad zur lokalen Datei | Geben Sie den Inhalt des Zertifizierungsstellenzertifikats in einer lokalen Datei an. |
Bucketquellargumente
Wenn Sie source verwenden bucket , finden Sie hier die bucketspezifischen Befehlsargumente.
| Parameter | Format | Notizen |
|---|---|---|
--url -u |
URL-Zeichenfolge | Die URL für den bucket. Unterstützte Formate: http://, https://. |
--bucket-name |
String | Name des zu synchronisierenden bucket. |
--bucket-access-key |
String | Zugriffsschlüssel-ID, die für die Authentifizierung bei dem bucket verwendet wird. |
--bucket-secret-key |
String | Geheimer Schlüssel, der für die Authentifizierung bei dem bucket verwendet wird. |
--bucket-insecure |
Boolean | Kommunikation mit einem bucket ohne TLS. Wenn keine Angabe erfolgt, wird „false“ angenommen, wenn angegeben, wird „true“ angenommen. |
Azure Blob Storage-Kontoquellenargumente
Wenn Sie source verwenden azblob , finden Sie hier die blobspezifischen Befehlsargumente.
| Parameter | Format | Notizen |
|---|---|---|
--url -u |
URL-Zeichenfolge | Die URL für den azblob. |
--container-name |
String | Name des Azure Blob Storage-Containers für die Synchronisierung |
--sp_client_id |
String | Die Client-ID für die Authentifizierung eines Dienstprinzipals mit Azure-Blob, erforderlich für diese Authentifizierungsmethode |
--sp_tenant_id |
String | Die Mandanten-ID für die Authentifizierung eines Dienstprinzipals mit Azure-Blob, erforderlich für diese Authentifizierungsmethode |
--sp_client_secret |
String | Das Clientgeheimnis für die Authentifizierung eines Dienstprinzipals mit Azure-Blob |
--sp_client_cert |
String | Das Base64-codierte Clientzertifikat für die Authentifizierung eines Dienstprinzipals mit Azure-Blob |
--sp_client_cert_password |
String | Das Kennwort zum Clientzertifikat für die Authentifizierung eines Dienstprinzipals mit Azure-Blob |
--sp_client_cert_send_chain |
String | Gibt an, ob x5c-Header in Clientansprüche beim Abrufen eines Tokens einbezogen werden sollen, um die Authentifizierung anhand des Antragstellernamens/Ausstellers für das Clientzertifikat zu aktivieren |
--account_key |
String | Der gemeinsam verwendete Azure Blob-Schlüssel für die Authentifizierung |
--sas_token |
String | Das Azure Blob-SAS-Token für die Authentifizierung |
--mi_client_id |
String | Die Client-ID der verwalteten Identität für die Authentifizierung mit Azure-Blob |
Wichtig
Wenn Sie die Authentifizierung mit verwalteter Identität für AKS-Cluster und azblob -Quelle verwenden, muss der verwalteten Identität mindestens die Rolle Storage-Blobdatenleser zugewiesen werden. Die Authentifizierung mit einer verwalteten Identität ist für Azure Arc-fähige Kubernetes-Cluster noch nicht verfügbar.
Lokales Geheimnis für die Authentifizierung bei der Quelle
Sie können ein lokales Kubernetes-Geheimnis für die Authentifizierung bei einer git-, bucket- oder azBlob-Quelle verwenden. Das lokale Geheimnis muss alle für die Quelle erforderlichen Authentifizierungsparameter enthalten und im gleichen Namespace wie die Flux-Konfiguration erstellt werden.
| Parameter | Format | Notizen |
|---|---|---|
--local-auth-ref --local-ref |
String | Lokaler Verweis auf ein Kubernetes-Geheimnis im Flux-Konfigurationsnamespace, das für die Authentifizierung bei der Quelle verwendet werden soll. |
Für die HTTPS-Authentifizierung erstellen Sie ein Geheimnis mit username und password:
kubectl create ns flux-config
kubectl create secret generic -n flux-config my-custom-secret --from-literal=username=<my-username> --from-literal=password=<my-password-or-key>
Für die SSH-Authentifizierung erstellen Sie ein Geheimnis mit den Feldern identity und known_hosts:
kubectl create ns flux-config
kubectl create secret generic -n flux-config my-custom-secret --from-file=identity=./id_rsa --from-file=known_hosts=./known_hosts
Verwenden Sie in beiden Fällen beim Erstellen der Flux-Konfiguration --local-auth-ref my-custom-secret anstelle der anderen Authentifizierungsparameter:
az k8s-configuration flux create -g <cluster_resource_group> -c <cluster_name> -n <config_name> -t connectedClusters --scope cluster --namespace flux-config -u <git-repo-url> --kustomization name=kustomization1 --local-auth-ref my-custom-secret
Erfahren Sie mehr über die Verwendung eines lokalen Kubernetes-Geheimnisses mit diesen Authentifizierungsmethoden:
- Git-Repository: HTTPS-Authentifizierung
- Git-Repository: Selbstsignierte HTTPS-Zertifikate
- Git-Repository: SSH-Authentifizierung
- Statische Bucketauthentifizierung
Hinweis
Wenn Flux über Ihren Proxy auf die Quelle zugreifen muss, müssen Sie die Azure Arc-Agents mit den Proxyeinstellungen aktualisieren. Informationen finden Sie unter Herstellen einer Verbindung mithilfe eines ausgehenden Proxyservers.
Git-Implementierung
Um verschiedene Repositoryanbieter zu unterstützen, die Git implementieren, kann Flux so konfiguriert werden, dass eine der beiden Git-Bibliotheken go-git oder libgit2 verwendet wird. Weitere Informationen finden Sie in der Flux-Dokumentation.
Die GitOps-Implementierung von Flux v2 bestimmt automatisch, welche Bibliothek für öffentliche Cloudrepositorys verwendet werden soll:
- Für GitHub-, GitLab- und Bitbucket-Repositorys verwendet Flux
go-git. - Für Azure DevOps und alle anderen Repositorys verwendet Flux
libgit2.
Für lokale Repositorys verwendet Flux libgit2.
Kustomization
Mit az k8s-configuration flux kustomization create können Sie während der Konfiguration eine oder mehrere Kustomizations erstellen.
| Parameter | Format | Notizen |
|---|---|---|
--kustomization |
Kein Wert | Beginn einer Zeichenfolge von Parametern, die eine Kustomization konfigurieren. Sie können sie mehrmals verwenden, um mehrere Kustomizations zu erstellen. |
name |
String | Eindeutiger Name für diese Kustomization. |
path |
String | Pfad innerhalb des Git-Repositorys, das mit dem Cluster abgestimmt werden soll. Der Standardwert ist die oberste Ebene des Branchs. |
prune |
Boolean | Der Standardwert ist false. Durch die Einstellung prune=true wird sichergestellt, dass die von Flux im Cluster bereitgestellten Objekte bereinigt werden, wenn sie aus dem Repository entfernt oder die Flux-Konfiguration oder Kustomizations gelöscht werden. Die Verwendung von prune=true ist wichtig für Umgebungen, in denen Benutzer*innen keinen Zugriff auf die Cluster haben und Änderungen nur über das Git-Repository vornehmen können. |
depends_on |
String | Name einer oder mehrerer Kustomizations (innerhalb dieser Konfiguration), die abgestimmt werden müssen, bevor diese Kustomization abgestimmt werden kann. Beispiel: depends_on=["kustomization1","kustomization2"]. Wenn Sie eine Kustomisierung entfernen, die abhängige Kustomisierungen aufweist, wird der Zustand der abhängigen Kustomisierungen zu DependencyNotReady, und die Abstimmung wird angehalten. |
timeout |
Golang-Format der Dauer | Standardwert: 10m. |
sync_interval |
Golang-Format der Dauer | Standardwert: 10m. |
retry_interval |
Golang-Format der Dauer | Standardwert: 10m. |
validation |
String | Werte: none, client, server. Standardwert: none. Ausführliche Informationen dazu finden Sie in der Flux-Dokumentation. |
force |
Boolean | Standardwert: false. Legen Sie force=true fest, um den kustomize-Controller anzuweisen, Ressourcen neu zu erstellen, wenn beim Patchen aufgrund einer Änderung an einem unveränderlichen Feld ein Fehler auftritt. |
Sie können auch verwenden az k8s-configuration flux kustomization , um Kustomisierungen in einer Flux-Konfiguration zu aktualisieren, auflisten, anzuzeigen und zu löschen.
Mehrinstanzenfähigkeit
Flux v2 unterstützt Mehrinstanzenfähigkeit in Version 0.26. Diese Funktion wurde in Azure GitOps mit Flux v2 integriert.
Hinweis
Für das Mehrinstanzenfähigkeitsfeature müssen Sie wissen, ob Ihre Manifeste namespaceübergreifende SourceRef für HelmRelease, Kustomization, ImagePolicy oder andere Objekte enthalten oder ob Sie eine Kubernetes-Version kleiner als 1.20.6 verwenden. Vorbereitung:
- Führen Sie ein Upgrade auf Kubernetes Version 1.20.6 oder höher durch.
- Stellen Sie in Ihren Kubernetes-Manifesten sicher, dass alle Quellverweise (
sourceRef) für Objekte innerhalb desselben Namespace festgelegt sind, in dem sich auch die GitOps-Konfiguration befindet.- Wenn Sie Zeit benötigen, um Ihre Manifeste zu aktualisieren, können Sie die Mehrinstanzenfähigkeit deaktivieren. Sie müssen jedoch weiterhin ein Upgrade Ihrer Kubernetes-Version durchführen.
Aktualisieren von Manifesten für Mehrinstanzenfähigkeit
Angenommen, Sie stellen eine Flux-Konfiguration (fluxConfiguration) in einem Kubernetes-Cluster im Namespace cluster-config mit Clusterbereich bereit. Sie konfigurieren die Quelle für die Synchronisierung des Repositorys https://github.com/fluxcd/flux2-kustomize-helm-example. Dies ist das gleiche Git-Beispielrepository, das im Tutorial Bereitstellen von Anwendungen mit GitOps mit Flux v2 verwendet wird. Nachdem Flux das Repository synchronisiert hat, werden die in den Manifesten (YAML-Dateien) beschriebenen Ressourcen bereitgestellt. Zwei der Manifeste beschreiben HelmRelease- und HelmRepository-Objekte.
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
Die Flux-Erweiterung stellt standardmäßig fluxConfigurations bereit. Dazu wird die Identität des Dienstkontos flux-applier angenommen, das nur im Namespace cluster-config bereitgestellt wird. Bei Verwendung der oben genannten Manifeste würde HelmRelease bei aktivierter Mehrinstanzenfähigkeit blockiert werden. Das liegt daran, dass sich HelmRelease im Namespace nginx befindet und auf HelmRepository im Namespace flux-system verweist. Darüber hinaus kann der Flux Helm-Controller HelmRelease nicht anwenden, da im nginx-Namespace kein flux-applier-Dienstkonto vorhanden ist.
Der richtige Ansatz zur Verwendung von Mehrinstanzenfähigkeit besteht in der Bereitstellung aller Flux-Objekte im gleichen Namespace, in dem sich auch fluxConfigurations befindet. Dieser Ansatz vermeidet das Problem mit namespaceübergreifenden Verweisen und ermöglicht es den Flux-Controllern, die Berechtigungen zum Anwenden der Objekte zu erhalten. Daher würden sich diese Beispielmanifeste für eine GitOps-Konfiguration, die im Namespace cluster-config erstellt wurde, wie folgt ändern:
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
Deaktivieren der Mehrinstanzenfähigkeit
Wenn die microsoft.flux-Erweiterung installiert ist, wird die Mehrinstanzenfähigkeit standardmäßig aktiviert, um standardmäßige Sicherheit in Ihren Clustern zu gewährleisten. Wenn Sie die Mehrinstanzenfähigkeit jedoch deaktivieren müssen, können Sie dies deaktivieren, indem Sie die microsoft.flux Erweiterung in Ihren Clustern mit "---configuration-settings multiTenancy.enforce=false" erstellen oder aktualisieren:
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>
Migrieren von Flux v1
Wenn Sie Flux v1 noch verwenden, empfehlen wir, so bald wie möglich zu Flux v2 zu migrieren.
Zum Migrieren zu Flux v2 in denselben Clustern, in denen Sie Flux v1 verwendet haben, müssen Sie zunächst alle Flux v1-Instanzen sourceControlConfigurations aus den Clustern löschen. Da Flux v2 über eine grundlegend andere Architektur verfügt, wird die microsoft.flux Clustererweiterung nicht installiert, wenn flux v1-Ressourcen sourceControlConfigurations in einem Cluster vorhanden sind. Das Entfernen von Flux v1-Konfigurationen und die Bereitstellung von Flux v2-Konfigurationen sollte nicht länger als 30 Minuten dauern.
Durch das Entfernen von Flux v1 sourceControlConfigurations werden keine Anwendungen beendet, die auf den Clustern ausgeführt werden. In dem Zeitraum, in dem die Flux v1-Konfiguration entfernt wurde und die Flux v2-Erweiterung noch nicht vollständig bereitgestellt wurde:
- Wenn in einem Git-Repository neue Änderungen an den Anwendungsmanifesten gespeichert sind, werden diese während der Migration nicht abgerufen, und die im Cluster bereitgestellte Anwendungsversion ist veraltet.
- Wenn es unbeabsichtigte Änderungen am Clusterstatus gibt und er vom gewünschten Zustand abweicht, der im Git-Quellrepository angegeben ist, kann der Cluster nicht selbst repariert werden.
Es wird empfohlen, Ihr Migrationsszenario in einer Entwicklungsumgebung zu testen, bevor Sie Ihre Produktionsumgebung migrieren.
Anzeigen und Löschen von Flux v1-Konfigurationen
Verwenden Sie die folgenden Azure CLI-Befehle, um vorhandene sourceControlConfigurations-Ressourcen in einem Cluster zu suchen und dann zu löschen:
az k8s-configuration list --cluster-name <Arc or AKS cluster name> --cluster-type <connectedClusters OR managedClusters> --resource-group <resource group name>
az k8s-configuration delete --name <configuration name> --cluster-name <Arc or AKS cluster name> --cluster-type <connectedClusters OR managedClusters> --resource-group <resource group name>
Sie können auch vorhandene GitOps-Konfigurationen für einen Cluster im Azure-Portal anzeigen und löschen. Navigieren Sie hierzu zu dem Cluster, in dem die Konfiguration erstellt wurde, und wählen Sie im linken Bereich GitOps aus. Wählen Sie die Konfiguration und dann Löschen aus.
Bereitstellen von Flux v2-Konfigurationen
Verwenden Sie die Azure-Portal oder die Azure CLI, um Flux v2-Konfigurationen auf Ihre Cluster anzuwenden.
Flux v1-Informationen zur Einstellung
Das Open-Source-Projekt von Flux v1 wurde archiviert, und die Featureentwicklung wurde auf unbestimmte Zeit angehalten. Weitere Informationen finden Sie im Fluxcd-Projekt.
Flux v2 wurde als aktualisiertes Open-Source-Projekt von Flux gestartet. Es verfügt über eine neue Architektur und unterstützt weitere GitOps-Anwendungsfälle. Microsoft hat im Mai 2022 eine Version einer Erweiterung mit Flux v2 eingeführt. Seitdem wurde den Kunden empfohlen, innerhalb von drei Jahren auf Flux v2 umzusteigen, da der Support für die Verwendung von Flux v1 im Mai 2025 endet.
Wichtige neue Features, die in der GitOps-Erweiterung für Flux v2 eingeführt wurden:
- Flux v1 ist ein monolithischer Do-it-All-Operator. Flux v2 unterteilt die Funktionen in spezialisierte Controller (Quellcontroller, Kustomize-Controller, Helm-Controller und Benachrichtigungscontroller).
- Unterstützt die Synchronisierung mit mehreren Quellrepositorys.
- Unterstützt mehrinstanzenfähige Mandanten, z. B. das Anwenden jedes Quellrepositorys mit einem eigenen Berechtigungssatz.
- Bietet operative Einblicke durch Integritätsprüfungen, Ereignisse und Warnungen.
- Unterstützt Git-Branches, das Anheften von Commits und Tags sowie das Folgen von SemVer-Tagbereichen.
- Konfiguration von Anmeldeinformationen pro GitRepository-Ressource: privater SSH-Schlüssel, HTTP/S-Benutzername/Kennwort/Token und öffentliche OpenPGP-Schlüssel.
Nächste Schritte
- Verwenden Sie unser Tutorial, um zu erfahren, wie Sie GitOps in Ihren AKS- oder Azure Arc-fähigen Kubernetes-Clustern aktivieren.
- Erfahren Sie mehr über den CI/CD-Workflow mit GitOps.