Freigeben über

Tutorial: Anwendungen mit GitOps und ArgoCD bereitstellen

In diesem Tutorial wird beschrieben, wie Sie GitOps in einem Kubernetes-Cluster verwenden. GitOps mit ArgoCD ist als Clustererweiterung in Azure Arc-fähigen Kubernetes-Clustern oder Azure Kubernetes Service (AKS)-Clustern aktiviert. Mit GitOps können Sie Ihr Git-Repository als Quelle der Wahrheit für die Clusterkonfiguration und Anwendungsbereitstellung verwenden.

Von Bedeutung

GitOps mit ArgoCD befindet sich derzeit in der Vorschauphase. Lesen Sie die ergänzenden Nutzungsbedingungen für Microsoft Azure Previews für rechtliche Bestimmungen, die für Azure-Features gelten, die sich in Der Betaversion, Vorschau oder auf andere Weise noch nicht in der allgemeinen Verfügbarkeit befinden. Testen Sie die GitOps-Erweiterungsunterstützung für die Produktion mithilfe von Flux.

Tipp

Während die Quelle in diesem Lernprogramm ein Git-Repository ist, unterstützt ArgoCD andere gängige Dateiquellen wie Helm- und Open Container Initiative (OCI)-Repositorys.

Voraussetzungen

Zum Bereitstellen von Anwendungen mit GitOps benötigen Sie entweder einen Azure Arc-fähigen Kubernetes-Cluster oder einen AKS-Cluster:

Kubernetes-Cluster mit Azure Arc-Unterstützung.

Azure Kubernetes Service-Cluster

  • Einen MSI-basierten AKS-Cluster, der aktiv ist und ausgeführt wird.

    Von Bedeutung

    Der AKS-Cluster muss mit verwalteter Dienstidentität (Managed Service Identity, MSI) und nicht mit dem Dienstprinzipalnamen (Service Principal Name, SPN) erstellt werden, damit diese Erweiterung funktioniert. Bei neuen AKS-Clustern, die mit az aks create erstellt werden, ist der Cluster standardmäßig MSI-basiert. Um SPN-basierte Cluster in MSI zu konvertieren, führen Sie az aks update -g $RESOURCE_GROUP -n $CLUSTER_NAME --enable-managed-identity aus. Weitere Informationen finden Sie unter Verwenden einer verwalteten Identität in AKS.

  • Lese- und Schreibberechtigungen für den Ressourcentyp Microsoft.ContainerService/managedClusters

Für beide Clustertypen

  • Lese- und Schreibberechtigungen für diese Ressourcentypen:

    • Microsoft.KubernetesConfiguration/extensions

  • Azure-Befehlszeilenschnittstelle ab Version 2.15. Installieren Sie die Azure CLI , oder verwenden Sie die folgenden Befehle, um auf die neueste Version zu aktualisieren:

    az version
az upgrade

  • Der Kubernetes-Befehlszeilenclient kubectl. kubectl ist bereits installiert, wenn Sie Azure Cloud Shell verwenden.

    Verwenden Sie für die lokale Installation von kubectl den Befehl az 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 Azure Arc-fähige Kubernetes 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.

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, um Containerimages für Controller abzurufen.

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.10.7
False          whl             k8s-configuration      C:\Users\somename\.azure\cliextensions\k8s-configuration    False     2.2.0
False          whl             k8s-extension          C:\Users\somename\.azure\cliextensions\k8s-extension        False     1.6.4

Erstellen der GitOps-Erweiterung (ArgoCD) (einfache Installation)

Die GitOps ArgoCD-Installation unterstützt mehrinstanzenfähige Mandanten im Hochverfügbarkeitsmodus (HA) und unterstützt die Workloadidentität.

Von Bedeutung

Der HA-Modus ist die Standardkonfiguration und erfordert drei Knoten im Cluster, um die Installation durchführen zu können. Der folgende Befehl fügt --config deployWithHighAvailability=false hinzu, um die Erweiterung auf einem einzelnen Knoten zu installieren.

Mit diesem Befehl wird die einfachste Konfiguration erstellt, die die ArgoCD-Komponenten in einem neuen argocd Namespace mit clusterweitem Zugriff installiert. Der clusterweite Zugriff ermöglicht die Erkennung von ArgoCD-App-Definitionen in allen Namespaces, die in der Configmap-Konfiguration von ArgoCD im Cluster aufgeführt sind. Beispiel: namespace1,namespace2

az k8s-extension create --resource-group <resource-group> --cluster-name <cluster-name> \
--cluster-type managedClusters \
--name argocd \
--extension-type Microsoft.ArgoCD \
--release-train preview \
--config deployWithHighAvailability=false \
--config namespaceInstall=false \
--config "config-maps.argocd-cmd-params-cm.data.application\.namespaces=namespace1,namespace2"

Wenn Sie den ArgoCD-Zugriff auf einen bestimmten Namespace einschränken möchten, verwenden Sie die Parameter --config namespaceInstall=true zusammen mit --target-namespace <namespace>. Dieser Installationsbefehl erstellt einen neuen <namespace> Namespace und installiert die ArgoCD-Komponenten in der <namespace>. Der Installationsbefehl ermöglicht auch die Installation mehrerer Instanzen von ArgoCD im selben Cluster. ArgoCD-Anwendungsdefinitionen in dieser Konfiguration funktionieren nur im <namespace> Namespace.

GitOps-Erweiterung (ArgoCD) mit Workload-Identität erstellen

Eine alternative Installationsmethode, die für die Produktionsverwendung empfohlen wird, ist die Workloadidentität. Mit dieser Methode können Sie Microsoft Entra-ID-Identitäten verwenden, um sich bei Azure-Ressourcen zu authentifizieren, ohne geheime Schlüssel oder Anmeldeinformationen in Ihrem Git-Repository verwalten zu müssen. Diese Installation verwendet die Workload-Identitätsauthentifizierung, die in der Version 3.0.0-rc2 oder höher von ArgoCD aktiviert ist.

Von Bedeutung

Der HA-Modus ist die Standardkonfiguration und erfordert drei Knoten im Cluster, um die Installation durchführen zu können. Fügen Sie --config deployWithHighAvailability=false hinzu, um die Erweiterung auf einem einzelnen Knoten zu installieren.

Um die Erweiterung mit Workload-Identität zu erstellen, ersetzen Sie zuerst die folgenden Variablen durch Ihre eigenen Werte in dieser Bicep-Vorlage:

var clusterName = '<aks-or-arc-cluster-name>'

var workloadIdentityClientId = 'replace-me##-##-###-###'
var ssoWorkloadIdentityClientId = 'replace-me##-##-###-###'

var url = 'https://<public-ip-for-argocd-ui>/'
var oidcConfig = '''
name: Azure
issuer: https://login.microsoftonline.com/<your-tenant-id>/v2.0
clientID: <same-value-as-ssoWorkloadIdentityClientId-above>
azure:
  useWorkloadIdentity: true
requestedIDTokenClaims:
  groups:
    essential: true
requestedScopes:
  - openid
  - profile
  - email
'''

var defaultPolicy = 'role:readonly'
var policy = '''
p, role:org-admin, applications, *, */*, allow
p, role:org-admin, clusters, get, *, allow
p, role:org-admin, repositories, get, *, allow
p, role:org-admin, repositories, create, *, allow
p, role:org-admin, repositories, update, *, allow
p, role:org-admin, repositories, delete, *, allow
g, replace-me##-argocd-ui-Microsoft Entra-group-admin-id, role:org-admin
'''

resource cluster 'Microsoft.ContainerService/managedClusters@2024-10-01' existing = {
  name: clusterName
}

resource extension 'Microsoft.KubernetesConfiguration/extensions@2023-05-01' = {
  name: 'argocd'
  scope: cluster
  properties: {
    extensionType: 'Microsoft.ArgoCD'
    releaseTrain: 'preview'
    configurationSettings: {
      'workloadIdentity.enable': 'true'
      'workloadIdentity.clientId': workloadIdentityClientId
      'workloadIdentity.entraSSOClientId': ssoWorkloadIdentityClientId
      'config-maps.argocd-cm.data.oidc\\.config': oidcConfig
      'config-maps.argocd-cm.data.url': url
      'config-maps.argocd-rbac-cm.data.policy\\.default': defaultPolicy
      'config-maps.argocd-rbac-cm.data.policy\\.csv': policy
      'config-maps.argocd-cmd-params-cm.data.application\\.namespaces': 'default, argocd'
    }
  }
}

Die Vorlage "Bicep" kann mit diesem Befehl erstellt werden:

az deployment group create --resource-group <resource-group> --template-file <bicep-file>

Die Parameter

clusterName ist der Name des AKS- oder Arc-fähigen Kubernetes-Clusters.

workloadIdentityClientId und ssoWorkloadIdentityClientId sind die Client-IDs der verwalteten Identität, die für die Workload-Identität verwendet werden soll. Die ssoWorkloadIdentityClientId wird für die Authentifizierung der ArgoCD-UI verwendet und die workloadIdentityClientId wird für die Workload-Identität der ArgoCD-Komponenten genutzt. Besuchen Sie Microsoft Entra ID App Registration Auth mit OIDC, um weitere Informationen zur grundlegenden Einrichtung und Konfiguration der ssoWorkloadIdentityClientId zu erhalten.

url ist die öffentliche IP der ArgoCD UI. Es gibt keinen öffentlichen IP- oder Domänennamen, es sei denn, der Cluster verfügt bereits über einen kundeneigenen Eingangscontroller. Wenn ja, muss die Ingress-Regel in der ArgoCD-Benutzeroberfläche nach der Bereitstellung hinzugefügt werden.

oidcConfig – Ersetzen Sie <your-tenant-id> durch die Mandanten-ID Ihrer Microsoft Entra-ID. Ersetzen Sie <same-value-as-ssoWorkloadIdentityClientId-above> durch denselben Wert wie ssoWorkloadIdentityClientId.

Die Variable policy entspricht den argocd-rbac-cm configmap-Einstellungen von ArgoCD. g, replace-me##-argocd-ui-entra-group-admin-id ist die Microsoft Entra-Gruppen-ID, die Administratorzugriff auf die ArgoCD-Benutzeroberfläche gewährt. Die Microsoft Entra-Gruppen-ID finden Sie im Azure-Portal unter "Microsoft Entra ID > Groups >your-group-name> Properties". Sie können die Microsoft Entra-Benutzer-ID anstelle einer Microsoft Entra-Gruppen-ID verwenden. Die Microsoft Entra-Benutzer-ID finden Sie im Azure-Portal unter "Microsoft Entra ID > Users >your-user-name> Properties".

Erstellen von Anmeldeinformationen für die Workloadidentität

Führen Sie die folgenden Schritte aus, um neue Anmeldeinformationen für die Workloadidentität einzurichten:

  1. Rufen Sie die OIDC-Aussteller-URL für Ihren AKS-Cluster oder Arc-fähigen Kubernetes-Cluster ab.

  2. Erstellen Sie eine verwaltete Identität , und notieren Sie ihre Client-ID und Mandanten-ID.

  3. Richten Sie verteilte Identitätsnachweise für Ihr AKS-Cluster oder Arc-fähiges Kubernetes-Cluster ein. 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 "${OIDC_ISSUER}" --subject system:serviceaccount:"argocd":"source-controller" --audience api://AzureADTokenExchange

  4. 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, stellen Sie sicher, dass entweder Container Registry Repository Reader (für ABAC-fähige Registrierungen) oder AcrPull (für Nicht-ABAC-Registrierungen) angewendet wurde.

Herstellen einer Verbindung mit privaten ACR-Registrierungen oder ACR-Repositorys mithilfe der Workload-Identität

Um die private ACR-Registrierung oder ACR-Repositorys zu nutzen, befolgen Sie die Anweisungen in der offiziellen ArgoCD-Dokumentation zum Herstellen einer Verbindung mit privaten ACR-Registrierungen. Die Schritte Bezeichnung der Pods, Erstellen von Verbundidentitätsanmeldeinformationen und Hinzufügen von Anmerkungen zu Dienstkonto in diesem Leitfaden wurden durch die Erweiterung mit der Bicep-Bereitstellung abgeschlossen und können übersprungen werden.

Zugreifen auf die ArgoCD-Benutzeroberfläche

Wenn kein Eingangscontroller für den AKS-Cluster vorhanden ist, kann die ArgoCD-Benutzeroberfläche direkt mit einem LoadBalancer-Dienst verfügbar gemacht werden. Der folgende Befehl macht die ArgoCD-Benutzeroberfläche auf Port 80 und 443 verfügbar.

kubectl -n argocd expose service argocd-server --type LoadBalancer --name argocd-server-lb --port 80 --target-port 8080

Bereitstellen der ArgoCD-Anwendung

Nachdem die ArgoCD-Erweiterung installiert wurde, können Sie eine Anwendung mit der ArgoCD-Benutzeroberfläche oder CLI bereitstellen. Im folgenden Beispiel wird ganz einfach kubectl apply genutzt, um den AKS-Speicher innerhalb einer ArgoCD-Anwendung im argocd Namespace in das Standardprojekt von ArgoCD bereitzustellen.

kubectl apply -f - <<EOF
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: aks-store-demo
  namespace: argocd
spec:
  project: default
  source:    
      repoURL: https://github.com/Azure-Samples/aks-store-demo.git
      targetRevision: HEAD
      path: kustomize/overlays/dev
  syncPolicy:
      automated: {}
  destination:
      namespace: argocd
      server: https://kubernetes.default.svc
EOF

Die AKS Store-Demoanwendung wurde im pets Namespace installiert. Lesen Sie die Anwendungswebseite, indem Sie diese Anweisungen befolgen. Achten Sie darauf, die IP-Adresse mit http und nicht https zu besuchen.

Aktuelen der Erweiterungskonfiguration

ArgoCD configmaps können nach der Installation und anderen Erweiterungskonfigurationseinstellungen mithilfe des folgenden Befehls aktualisiert werden:

az k8s-extension update --resource-group <resource-group> --cluster-name <cluster-name> --cluster-type <cluster-type> --name Microsoft.ArgoCD –-config "config-maps.argocd-cm.data.url='https://<public-ip-for-argocd-ui>/auth/callback'”

Es ist wichtig, die ArgoCD configmap über die Erweiterung zu aktualisieren, sodass die Einstellungen nicht überschrieben werden. Das Anwenden der Bicep-Vorlage ist eine alternative Methode gegenüber az cli zum Aktualisieren der Konfiguration.

Löschen Sie die Erweiterung

Verwenden Sie die folgenden Befehle, um die Erweiterung zu löschen.

az k8s-extension delete -g <resource-group> -c <cluster-name> -n argocd -t managedClusters --yes

Nächste Schritte

  • Last updated on