Freigeben über

GitOps (Flux v2) unterstützte Parameter

  • Artikel

Azure bietet eine Funktion zur automatisierten Anwendungsbereitstellung mit GitOps, die mit Azure Kubernetes Service (AKS) und Kubernetes-Clustern mit Azure Arc-Unterstützung arbeitet. Mit GitOps mit Flux v2 können Sie Ihr Git-Repository als Quelle der Wahrheit für die Clusterkonfiguration und Anwendungsbereitstellung verwenden. Weitere Informationen finden Sie unter Anwendungsbereitstellungen mit GitOps (Flux v2) und Tutorial: Bereitstellen von Anwendungen mit GitOps mit Flux v2.

GitOps auf Azure Arc aktivierten Kubernetes oder Azure Kubernetes Service verwendet Flux, ein beliebtes Open-Source-Toolset, der viele Parameter unterstützt, um verschiedene Szenarien zu ermöglichen. Eine Beschreibung aller Parameter, die von Flux unterstützt werden, finden Sie in der offiziellen Flux-Dokumentation.

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. Teilen Sie uns mit, wenn ein von Ihnen benötigter Parameter in der Azure-Implementierung fehlt.

Dieser Artikel beschreibt einige der Parameter und Argumente, die für den Befehl az k8s-configuration flux create zur Verfügung stehen. Sie können auch die vollständige Liste der Parameter für az k8s-configuration flux anzeigen, indem Sie den Parameter -h in Azure CLI verwenden (z. B. az k8s-configuration flux -h oder az k8s-configuration flux create -h).

Tipp

Eine Problemumgehung zum Bereitstellen von Flux-Ressourcen mit nicht unterstützten Parametern besteht darin, die erforderlichen benutzerdefinierten Flux-Ressourcen (wie z. B. GitRepository oder Kustomization) in Ihrem Git-Repository zu definieren. Stellen Sie diese Ressourcen mit dem Befehl az k8s-configuration flux create bereit. Sie können anschließend weiterhin über die Azure Arc-Benutzeroberfläche auf Ihre Flux-Ressourcen zugreifen.

Allgemeine Argumente für die Konfiguration

Parameter Format Hinweise
--cluster-name -c String Name der Clusterressource in Azure.
--cluster-type -t Zulässige Werte: connectedClusters, managedClusters. Verwenden Sie connectedClusters für Kubernetes-Cluster mit Azure Arc-Unterstützung und managedClusters für AKS-Cluster.
--resource-group -g String Name der Azure-Ressourcengruppe mit der Clusterressource.
--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 Hinweise
--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 Hinweise
--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 Hinweise
--url -u http[s]://server/repo[.git] URL der Git-Repositoryquelle, die mit dem Cluster abgestimmt werden soll.

Privates Git-Repository mit SSH

Wichtig

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. Weitere Informationen finden Sie unter Ausmusterung von SSH-RSA in Azure DevOps.

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 Hinweise
--url -u ssh://user@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 Hinweise
--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 Hinweise
--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 Hinweise
--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 Hinweise
--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 eine bucket-Quelle verwenden, finden Sie hier die bucketspezifischen Befehlsargumente.

Parameter Format Hinweise
--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 eine azblob-Quelle verwenden, finden Sie hier die blobspezifischen Befehlsargumente.

Parameter Format Hinweise
--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
--managed-identity-client-id String Die Client-ID der verwalteten Identität für die Authentifizierung mit Azure-Blob

Wichtig

Bei Verwendung der Authentifizierung mit verwalteten Identitäten für AKS-Cluster und azblob-Source muss der verwalteten Identität mindestens die Rolle Leser von Speicherblobdaten zugewiesen sein. Die Authentifizierung mit einer verwalteten Identität ist für Kubernetes-Cluster mit Azure Arc-Unterstützung 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 Hinweise
--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

Wichtig

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. Weitere Informationen finden Sie unter Ausmusterung von SSH-RSA in Azure DevOps.

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:

Hinweis

Wenn Sie Flux benötigen, um über Ihren Proxy auf die Quelle zuzugreifen, 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 dazu 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

Kustomization ist eine Einstellung für Flux-Konfigurationen, mit der Sie einen bestimmten Pfad im Quellrepository auswählen können, der mit dem Cluster abgeglichen wird. Sie müssen keine „kustomization.yaml“-Datei unter diesem angegebenen Pfad erstellen. Standardmäßig werden alle Manifeste in diesem Pfad abgeglichen. Wenn Sie jedoch ein Kustomize-Overlay für Anwendungen auf diesem Repositorypfad zur Verfügung haben möchten, sollten Sie Kustomize-Dateien in Git erstellen, die von der Flux-Konfiguration verwendet werden können.

Mit az k8s-configuration flux kustomization create können Sie während der Konfiguration eine oder mehrere Kustomizations erstellen.

Parameter Format Hinweise
--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 Kundenanpassung entfernen, die abhängige Kundenanpassungen hat, wird der Status der abhängigen Kundenanpassungen 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 az k8s-configuration flux kustomization verwenden, um Kustomizations in einer Flux-Konfiguration zu aktualisieren, aufzulisten, anzuzeigen und zu löschen.

Nächste Schritte