Freigeben über


Tutorial: Bereitstellen von Konfigurationen mithilfe von GitOps in einem Kubernetes-Cluster mit Azure Arc-Unterstützung

Wichtig

Dieses Tutorial gilt für GitOps mit Flux v1. GitOps mit Flux v2 ist jetzt als Vorschau für Azure Arc-fähige Kubernetes-Cluster und Azure Kubernetes Service (AKS)-Cluster verfügbar. Wechseln Sie zum Tutorial für GitOps mit Flux v2. Es wird empfohlen, so schnell wie möglich zu Flux v2 zu migrieren.

Die Unterstützung für Flux v1-basierte Clusterkonfigurationsressourcen, die vor dem 1. Januar 2024 erstellt wurden, endet am 24. Mai 2025. Ab dem 1. Januar 2024 können Sie keine neuen Flux v1-basierten Clusterkonfigurationsressourcen mehr erstellen.

In diesem Tutorial wenden Sie Flux v1-Konfigurationen mithilfe von GitOps auf einen Kubernetes-Cluster mit Azure Arc-Unterstützung an. Sie lernen Folgendes:

  • Erstellen Sie mithilfe eines Git-Beispielrepositorys eine Konfiguration in einem Kubernetes-Cluster mit Azure Arc-Unterstützung.
  • Überprüfen Sie, ob die Konfiguration erfolgreich erstellt wurde.
  • Anwenden der Konfiguration aus einem privaten Git-Repository.
  • Überprüfen Sie die Kubernetes-Konfiguration.

Voraussetzungen

  • Ein Azure-Konto mit einem aktiven Abonnement. Sie können kostenlos ein Konto erstellen.

  • Ein vorhandener Cluster, der mit Kubernetes mit Azure Arc-Unterstützung verbunden ist

  • Ein grundlegendes Verständnis der Vorteile und der Architektur dieses Features. Weitere Informationen finden Sie im Artikel Konfigurationen und GitOps: Azure Arc-fähiges Kubernetes.

  • Installieren Sie die Azure CLI-Erweiterung k8s-configuration in Version >= 1.0.0:

    az extension add --name k8s-configuration
    

    Tipp

    Wenn die k8s-configuration Erweiterung bereits installiert ist, können Sie sie mit dem folgenden Befehl auf die neueste Version aktualisieren - az extension update --name k8s-configuration

Erstellen einer Konfiguration

Das in diesem Artikel verwendete Beispielrepository ist um die Persona eines Clusteroperators herum strukturiert. Die Manifeste in diesem Repository stellen einige Namespaces und Workloads bereit und bieten einige teamspezifische Konfigurationen. Durch Verwendung dieses Repositorys mit GitOps werden die folgenden Ressourcen in Ihrem Cluster erstellt:

  • Namespaces: cluster-config, team-a, team-b
  • Bereitstellung: arc-k8s-demo
  • ConfigMap: team-a/endpoints

Der config-agent fragt Azure nach neuen oder aktualisierten Konfigurationen ab. Diese Aufgabe kann bis zu 5 Minuten dauern.

Führen Sie auch die Schritte unter Anwenden der Konfiguration über ein privates Git-Repository aus, wenn Sie ein privates Repository mit der Konfiguration zuordnen.

Wichtig

Dieses Tutorial gilt für GitOps mit Flux v1. GitOps mit Flux v2 ist jetzt als Vorschau für Azure Arc-fähige Kubernetes-Cluster und Azure Kubernetes Service (AKS)-Cluster verfügbar. Wechseln Sie zum Tutorial für GitOps mit Flux v2. Es wird empfohlen, so schnell wie möglich zu Flux v2 zu migrieren.

Die Unterstützung für Flux v1-basierte Clusterkonfigurationsressourcen, die vor dem 1. Januar 2024 erstellt wurden, endet am 24. Mai 2025. Ab dem 1. Januar 2024 können Sie keine neuen Flux v1-basierten Clusterkonfigurationsressourcen mehr erstellen.

Mithilfe der Azure-Befehlszeilenschnittstelle

Verwenden Sie die Azure CLI-Erweiterung für k8s-configuration, um einen verbundenen Cluster mit dem Git-Beispielrepository zu verknüpfen.

  1. Benennen Sie diese Konfiguration cluster-config.

  2. Weisen Sie den Agent an, den Operator im cluster-config-Namespace bereitzustellen.

  3. Erteilen Sie dem Operator cluster-admin-Berechtigungen.

    az k8s-configuration flux create --name cluster-config --cluster-name AzureArcTest1 --resource-group AzureArcTest --operator-instance-name cluster-config --operator-namespace cluster-config --repository-url https://github.com/Azure/arc-k8s-demo --scope cluster --cluster-type connectedClusters
    
    {
      "complianceStatus": {
      "complianceState": "Pending",
      "lastConfigApplied": "0001-01-01T00:00:00",
      "message": "{\"OperatorMessage\":null,\"ClusterState\":null}",
      "messageLevel": "3"
      },
      "configurationProtectedSettings": {},
      "enableHelmOperator": false,
      "helmOperatorProperties": null,
      "id": "/subscriptions/<sub id>/resourceGroups/<group name>/providers/Microsoft.Kubernetes/connectedClusters/<cluster name>/providers/Microsoft.KubernetesConfiguration/sourceControlConfigurations/cluster-config",
      "name": "cluster-config",
      "operatorInstanceName": "cluster-config",
      "operatorNamespace": "cluster-config",
      "operatorParams": "--git-readonly",
      "operatorScope": "cluster",
      "operatorType": "Flux",
      "provisioningState": "Succeeded",
      "repositoryPublicKey": "",
      "repositoryUrl": "https://github.com/Azure/arc-k8s-demo",
      "resourceGroup": "MyRG",
      "sshKnownHostsContents": "",
      "systemData": {
        "createdAt": "2020-11-24T21:22:01.542801+00:00",
        "createdBy": null,
        "createdByType": null,
        "lastModifiedAt": "2020-11-24T21:22:01.542801+00:00",
        "lastModifiedBy": null,
        "lastModifiedByType": null
      },
      "type": "Microsoft.KubernetesConfiguration/sourceControlConfigurations"
    }
    

Verwenden eines öffentlichen Git-Repositorys

Parameter Format
--repository-url http[s]://server/repo[.git]

Verwenden eines privaten Git-Repositorys 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. Wenn der Schlüssel dem Repository statt dem Benutzerkonto hinzugefügt wird, verwenden Sie in der URL git@ anstelle von user@.

Weitere Informationen finden Sie im Abschnitt Anwenden einer Konfiguration aus einem privaten Git-Repository.

Parameter Format Notizen
--repository-url ssh://user@server/repo[.git] oder user@server:repo[.git] git@ kann user@ ersetzen

Verwenden eines privaten Git-Repositorys mit SSH und benutzerseitig bereitgestellten Schlüsseln

Stellen Sie Ihren eigenen privaten Schlüssel direkt oder in einer Datei bereit. 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. Wenn der Schlüssel dem Repository statt dem Benutzerkonto hinzugefügt wird, verwenden Sie git@ anstelle von user@.

Weitere Informationen finden Sie im Abschnitt Anwenden einer Konfiguration aus einem privaten Git-Repository.

Parameter Format Notizen
--repository-url ssh://user@server/repo[.git] oder user@server:repo[.git] git@ kann user@ ersetzen
--ssh-private-key base64-codierter Schlüssel im PEM-Format Direktes Bereitstellen des Schlüssels
--ssh-private-key-file Vollständiger Pfad zur lokalen Datei Bereitstellen des vollständigen Pfads zur lokalen Datei, die den Schlüssel im PEM-Format enthält

Verwenden eines privaten Git-Hosts mit SSH und benutzerseitig bereitgestellten bekannten Hosts

Der Flux-Operator verwaltet eine Liste gängiger Git-Hosts in seiner Datei bekannter Hosts, um das Git-Repository vor dem Einrichten der SSH-Verbindung zu authentifizieren. Wenn Sie ein nicht gängiges 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
--repository-url ssh://user@server/repo[.git] oder user@server:repo[.git] git@ kann user@ ersetzen
--ssh-known-hosts base64-codiert Inhalte bekannter Hosts direkt bereitstellen
--ssh-known-hosts-file Vollständiger Pfad zur lokalen Datei Inhalte bekannter Hosts in einer lokalen Datei bereitstellen

Verwenden eines privaten Git-Repository mit HTTPS

Parameter Format Notizen
--repository-url https://server/repo [.git] HTTPS mit Standardauthentifizierung
--https-user Unformatiert (raw) base64-codiert HTTPS-Benutzername
--https-key Unformatiert (raw) base64-codiert Persönliches HTTPS-Zugriffstoken oder -Kennwort

Hinweis

  • Die Chartversion 1.2.0+ des Helm-Operators unterstützt die private Authentifizierung von HTTPS Helm Release.
  • HTTPS Helm Release wird für verwaltete AKS-Cluster nicht unterstützt.
  • Wenn Sie Flux benötigen, um über Ihren Proxy auf das Git-Repository zuzugreifen, müssen Sie die Azure Arc-Agents mit den Proxyeinstellungen aktualisieren. Informationen finden Sie unter Herstellen einer Verbindung mithilfe eines ausgehenden Proxyservers.

Zusätzliche Parameter

Passen Sie die Konfiguration mit den folgenden optionalen Parametern an:

Parameter BESCHREIBUNG
--enable-helm-operator Switch zum Aktivieren der Unterstützung für Helm-Chartbereitstellungen.
--helm-operator-params Chartwerte für den Helm-Operator (falls aktiviert). Beispiel: --set helm.versions=v3.
--helm-operator-chart-version Chartversion für den Helm-Operator (falls aktiviert). Verwenden Sie Version 1.2.0 und höher. Standardwert: ‚1.2.0‘.
--operator-namespace Name für den Operatornamespace. Standardwert: „default“. Max: 23 Zeichen.
--operator-params Parameter für den Operator. Diese müssen in einfachen Anführungszeichen angegeben werden. Zum Beispiel, --operator-params='--git-readonly --sync-garbage-collection --git-branch=main'

In --operator-params unterstützte Optionen:

Option Beschreibung
--git-branch Die Verzweigung des Git-Repositorys für Kubernetes-Manifeste. Der Standardwert ist „master“. Neuere Repositorys haben einen Stammzweig namens main, in diesem Fall müssen Sie --git-branch=main festlegen.
--git-path Dies ist der relative Pfad im Git-Repository für Flux zum Suchen von Kubernetes-Manifesten.
--git-readonly Das Git-Repository wird als schreibgeschützt betrachtet. Flux wird nicht versuchen, darin zu schreiben.
--manifest-generation Wenn diese Option aktiviert ist, sucht Flux nach „.flux.yaml“ und führt Kustomize oder andere Manifest-Generatoren aus.
--git-poll-interval Dies ist die Zeitspanne, in der das Git-Repository für neue Commits abgerufen wird. Der Standardwert ist 5m (fünf Minuten).
--sync-garbage-collection Wenn diese Option aktiviert ist, werden die von Flux erstellten Ressourcen gelöscht und sind nicht mehr in Git verfügbar.
--git-label Bezeichnung zum Nachverfolgen des Synchronisierungsprozesses. Wird verwendet, um die Git-Verzweigung zu markieren. Der Standardwert ist flux-sync.
--git-user Benutzername für Git-Commits.
--git-email Für Git-Commits zu verwendende E-Mail-Adresse.

Wenn Flux nicht in das Repository schreiben soll und --git-user oder --git-email nicht festgelegt ist, wird --git-readonly automatisch festgelegt.

Weitere Informationen finden Sie in der Flux-Dokumentation.

Hinweis

Flux synchronisiert standardmäßig über die Verzweigung master des Git-Repositorys. Neuere Git-Repositorys verfügen jedoch über die Stammverzweigung mit dem Namen main. In diesem Fall müssen Sie --git-branch=main in den Parametern vom Typ „--operator-params“ festlegen.

Tipp

Sie können eine Konfiguration im Azure-Portal auf der Registerkarte GitOps der Kubernetes-Ressource mit Azure Arc-Unterstützung erstellen.

Überprüfen der Konfiguration

Überprüfen Sie mithilfe der Azure CLI, ob die Konfiguration erfolgreich erstellt wurde.

az k8s-configuration show --name cluster-config --cluster-name AzureArcTest1 --resource-group AzureArcTest --cluster-type connectedClusters

Die Konfigurationsressource wird mit Compliancestatus, Nachrichten und Debuginformationen aktualisiert.

{
  "complianceStatus": {
    "complianceState": "Installed",
    "lastConfigApplied": "2020-12-10T18:26:52.801000+00:00",
    "message": "...",
    "messageLevel": "Information"
  },
  "configurationProtectedSettings": {},
  "enableHelmOperator": false,
  "helmOperatorProperties": {
    "chartValues": "",
    "chartVersion": ""
  },
  "id": "/subscriptions/<sub id>/resourceGroups/AzureArcTest/providers/Microsoft.Kubernetes/connectedClusters/AzureArcTest1/providers/Microsoft.KubernetesConfiguration/sourceControlConfigurations/cluster-config",
  "name": "cluster-config",
  "operatorInstanceName": "cluster-config",
  "operatorNamespace": "cluster-config",
  "operatorParams": "--git-readonly",
  "operatorScope": "cluster",
  "operatorType": "Flux",
  "provisioningState": "Succeeded",
  "repositoryPublicKey": "...",
  "repositoryUrl": "git://github.com/Azure/arc-k8s-demo.git",
  "resourceGroup": "AzureArcTest",
  "sshKnownHostsContents": null,
  "systemData": {
    "createdAt": "2020-12-01T03:58:56.175674+00:00",
    "createdBy": null,
    "createdByType": null,
    "lastModifiedAt": "2020-12-10T18:30:56.881219+00:00",
    "lastModifiedBy": null,
    "lastModifiedByType": null
},
  "type": "Microsoft.KubernetesConfiguration/sourceControlConfigurations"
}

Wenn eine Konfiguration erstellt oder aktualisiert wird, geschieht im Hintergrund Folgendes:

  1. Der config-agent von Azure Arc überwacht Azure Resource Manager auf neue oder aktualisierte Konfigurationen (Microsoft.KubernetesConfiguration/sourceControlConfigurations) und erkennt die neue Konfiguration Pending.
  2. Der config-agent liest die Konfigurationseigenschaften und erstellt den Zielnamespace.
  3. Der Azure Arc-controller-manager erstellt ein Kubernetes-Dienstkonto und ordnet es ClusterRoleBinding oder RoleBinding für die entsprechenden Berechtigungen (cluster- oder namespace-Bereich) zu. Dann stellt er eine Instanz von flux bereit.
  4. Bei Verwendung der Option von SSH mit von Flux generierten Schlüsseln generiert flux einen SSH-Schlüssel und protokolliert den öffentlichen Schlüssel.
  5. Der config-agent meldet den Status zurück an die Konfigurationsressource in Azure.

Während des Bereitstellungsprozesses wird der Status der Konfigurationsressource mehrfach geändert. Überwachen Sie den Fortschritt mit dem obigen az k8s-configuration show ...-Befehl:

Phasenänderung BESCHREIBUNG
complianceStatus->Pending Hiermit werden der anfängliche Status und der Status während der Bearbeitung dargestellt.
complianceStatus ->Installed Der config-agent hat den Cluster erfolgreich konfiguriert und flux ohne Fehler bereitgestellt.
complianceStatus ->Failed Beim config-agent ist bei der Bereitstellung von flux ein Fehler aufgetreten. Weitere Informationen finden Sie im complianceStatus.message-Antworttext.

Anwenden der Konfiguration aus einem privaten Git-Repository

Wenn Sie ein privates Git-Repository verwenden, müssen Sie den öffentlichen SSH-Schlüssel in Ihrem Repository konfigurieren. Der öffentliche SSH-Schlüssel wird entweder von Ihnen bereitgestellt oder von Flux generiert. Sie können den öffentlichen Schlüssel entweder für das spezifische Git-Repository oder den Git-Benutzer konfigurieren, der Zugriff auf das Repository hat.

Abrufen Ihres eigenen öffentlichen Schlüssels

Wenn Sie Ihre eigenen SSH-Schlüssel generiert haben, verfügen Sie bereits über die privaten und öffentlichen Schlüssel.

Abrufen des öffentlichen Schlüssels mithilfe der Azure CLI

Verwenden Sie Folgendes in der Azure CLI, wenn die Schlüssel von Flux generiert werden.

az k8s-configuration show --resource-group <resource group name> --cluster-name <connected cluster name> --name <configuration name> --cluster-type connectedClusters --query 'repositoryPublicKey' 
"ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAREDACTED"

Abrufen des öffentlichen Schlüssels über das Azure-Portal

Führen Sie die folgenden Schritte im Azure-Portal aus, wenn die Schlüssel von Flux generiert werden.

  1. Navigieren Sie im Azure-Portal zur verbundenen Clusterressource.
  2. Wählen Sie auf der Ressourcenseite „GitOps“ aus, um die Liste der Konfigurationen für diesen Cluster anzuzeigen.
  3. Klicken Sie auf die Konfiguration, die das private Git-Repository verwendet.
  4. Kopieren Sie den öffentlichen Repositoryschlüssel im geöffneten Kontextfenster unten auf der Seite.

Hinzufügen eines öffentlichen Schlüssels mithilfe von GitHub

Nutzen Sie eine der folgenden Optionen:

  • Option 1: Hinzufügen des öffentlichen Schlüssels zu Ihrem Benutzerkonto (gilt für alle Repositorys in Ihrem Konto):

    1. Öffnen Sie GitHub, und klicken Sie in der oberen rechten Ecke der Seite auf Ihr Profilsymbol.
    2. Klicken Sie auf Einstellungen.
    3. Klicken Sie auf SSH- und GPG-Schlüssel.
    4. Klicken Sie auf Neuer SSH-Schlüssel.
    5. Geben Sie einen Titel an.
    6. Fügen Sie den öffentlichen Schlüssel ohne die diesen umgebenden Anführungszeichen ein.
    7. Klicken Sie auf SSH-Schlüssel hinzufügen.
  • Option 2: Hinzufügen des öffentlichen Schlüssels als Bereitstellungsschlüssel zum Git-Repository (gilt nur für dieses Repository):

    1. Öffnen Sie GitHub, und navigieren Sie zu Ihrem Repository.
    2. Klicken Sie auf Einstellungen.
    3. Klicken Sie auf Bereitstellungsschlüssel.
    4. Klicken Sie auf Bereitstellungsschlüssel hinzufügen.
    5. Geben Sie einen Titel an.
    6. Aktivieren Sie Schreibzugriff gewähren.
    7. Fügen Sie den öffentlichen Schlüssel ohne die diesen umgebenden Anführungszeichen ein.
    8. Klicken Sie auf Schlüssel hinzufügen.

Hinzufügen eines öffentlichen Schlüssels mit einem Azure DevOps-Repository

Führen Sie die folgenden Schritte aus, um den Schlüssel zu Ihren SSH-Schlüsseln hinzuzufügen:

  1. Klicken Sie unter Benutzereinstellungen oben rechts (neben dem Profilbild) auf Öffentliche SSH-Schlüssel.
  2. Wählen Sie + Neuer Schlüssel aus.
  3. Geben Sie einen Namen an.
  4. Fügen Sie den öffentlichen Schlüssel ohne die diesen umgebenden Anführungszeichen ein.
  5. Klicken Sie auf Hinzufügen.

Überprüfen der Kubernetes-Konfiguration

Nachdem der config-agent die flux-Instanz installiert hat, sollten die im Git-Repository gespeicherten Ressourcen an den Cluster weitergeleitet werden. Überprüfen Sie, ob die Namespaces, Bereitstellungen und Ressourcen erstellt wurden, mit dem folgenden Befehl:

kubectl get ns --show-labels
NAME              STATUS   AGE    LABELS
azure-arc         Active   24h    <none>
cluster-config    Active   177m   <none>
default           Active   29h    <none>
itops             Active   177m   fluxcd.io/sync-gc-mark=sha256.9oYk8yEsRwWkR09n8eJCRNafckASgghAsUWgXWEQ9es,name=itops
kube-node-lease   Active   29h    <none>
kube-public       Active   29h    <none>
kube-system       Active   29h    <none>
team-a            Active   177m   fluxcd.io/sync-gc-mark=sha256.CS5boSi8kg_vyxfAeu7Das5harSy1i0gc2fodD7YDqA,name=team-a
team-b            Active   177m   fluxcd.io/sync-gc-mark=sha256.vF36thDIFnDDI2VEttBp5jgdxvEuaLmm7yT_cuA2UEw,name=team-b

Wir sehen, dass die Namespaces team-a, team-b, itops und cluster-config erstellt wurden.

Der flux-Operator wurde gemäß den Anweisungen der Konfigurationsressource im cluster-config-Namespace bereitgestellt:

kubectl -n cluster-config get deploy  -o wide
NAME             READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES                         SELECTOR
cluster-config   1/1     1            1           3h    flux         docker.io/fluxcd/flux:1.16.0   instanceName=cluster-config,name=flux
memcached        1/1     1            1           3h    memcached    memcached:1.5.15               name=memcached

Weitere Untersuchungen

Sie können die anderen Ressourcen, die als Teil des Konfigurationsrepositorys bereitgestellt werden, mit Folgendem untersuchen:

kubectl -n team-a get cm -o yaml
kubectl -n itops get all

Bereinigen von Ressourcen

Löschen Sie eine Konfiguration über die Azure CLI oder das Azure-Portal. Nachdem Sie den Befehl zum Löschen ausgeführt haben, wird die Konfigurationsressource sofort in Azure gelöscht. Das vollständige Löschen der zugeordneten Objekte aus dem Cluster sollte innerhalb von 10 Minuten erfolgen. Wenn sich die Konfiguration beim Entfernen in einem fehlerhaften Zustand befindet, kann das vollständige Löschen der zugeordneten Objekte bis zu einer Stunde dauern.

Wenn eine Konfiguration mit dem namespace-Bereich gelöscht wird, wird der Namespace nicht von Azure Arc gelöscht, um zu vermeiden, dass vorhandene Workloads beschädigt werden. Bei Bedarf können Sie diesen Namespace manuell mit kubectl löschen.

az k8s-configuration delete --name cluster-config --cluster-name AzureArcTest1 --resource-group AzureArcTest --cluster-type connectedClusters

Hinweis

Alle Änderungen am Cluster, die das Ergebnis von Bereitstellungen aus dem nachverfolgten Git-Repository sind, werden beim Löschen der Konfiguration nicht gelöscht.

Wichtig

Dieses Tutorial gilt für GitOps mit Flux v1. GitOps mit Flux v2 ist jetzt als Vorschau für Azure Arc-fähige Kubernetes-Cluster und Azure Kubernetes Service (AKS)-Cluster verfügbar. Wechseln Sie zum Tutorial für GitOps mit Flux v2. Es wird empfohlen, so schnell wie möglich zu Flux v2 zu migrieren.

Die Unterstützung für Flux v1-basierte Clusterkonfigurationsressourcen, die vor dem 1. Januar 2024 erstellt wurden, endet am 24. Mai 2025. Ab dem 1. Januar 2024 können Sie keine neuen Flux v1-basierten Clusterkonfigurationsressourcen mehr erstellen.

Nächste Schritte

Im nächsten Tutorial erfahren Sie, wie Sie CI/CD mit GitOps implementieren.