Config Sync installieren

Mit Config Sync können Sie Kubernetes-Ressourcen mit Konfigurationsdateien verwalten, die in einer Source of Truth gespeichert sind. Config Sync unterstützt Git-Repositories, OCI-Images und Helm-Diagramme als „Source of Truth“. Auf dieser Seite erfahren Sie, wie Sie Config Sync aktivieren und konfigurieren, damit es aus Ihrem Stamm-Repository synchronisiert wird. Config Sync ist für die Google Kubernetes Engine (GKE) Enterprise-Version verfügbar.

Wenn Sie Config Sync mit der Google Cloud Console oder dem Google Cloud CLI installieren, sind die APIs RootSync und RepoSync standardmäßig aktiviert. Dies bietet zusätzliche Funktionen wie die Synchronisierung aus mehreren Repositories und die Synchronisierung von Kustomize- und Helm-Konfigurationen.

Hinweise

Bevor Sie Config Sync installieren, bereiten Sie Ihre Umgebung vor, achten Sie darauf, dass die Clusteranforderungen erfüllt werden, und gewähren Sie die richtigen Nutzerrollen.

Lokale Umgebung vorbereiten

Führen Sie die folgenden Schritte aus, um Ihre lokale Umgebung vorzubereiten:

  1. Erstelle eine „Source of Truth“ oder stelle sicher, dass du Zugriff darauf hast. Hier fügen Sie die Konfigurationen hinzu, mit denen Config Sync synchronisiert wird. Weitere Informationen zum Einrichten Ihrer Konfigurationen und der „Source of Truth“ finden Sie in einer der folgenden Anleitungen:
  2. Installieren und initialisieren Sie das Google Cloud CLI, das die Befehle gcloud und nomos enthält. Wenn Sie Cloud Shell verwenden, ist das Google Cloud CLI vorinstalliert.
  3. Aktivieren Sie die GKE Enterprise API.

    Aktivieren Sie die GKE Enterprise API

Clusteranforderungen

Erstellen Sie einen Cluster, der die folgenden Anforderungen erfüllt, oder verschaffen Sie sich darauf Zugriff:

  • Sie nutzen eine unterstützte Plattform und Version der Google Kubernetes Engine (GKE) Enterprise-Version.
  • Wenn Sie Autopilot-Cluster verwenden, passt Autopilot die Anforderungen an Containerressourcen so an, dass sie die folgenden Regeln erfüllen:

    Aufgrund dieser Regeln führt Config Sync für Autopilot-Cluster Folgendes aus:

  • (Optional) Workload Identity ist aktiviert, wenn Sie GKE-Cluster verwenden. Für das Aufrufen von Google Cloud-Diensten aus Anwendungen in GKE wird Workload Identity empfohlen, da dieses Feature bessere Sicherheitsmerkmale bietet und leichter zu verwalten ist. Wenn Sie Workload Identity aktiviert haben und Cloud Monitoring für Config Sync aktivieren möchten, müssen Sie die richtigen Schreibberechtigungen für Messwerte gewähren.

  • Wenn Sie einen privaten GKE-Cluster verwenden möchten, konfigurieren Sie die Cloud NAT so, dass ausgehender Traffic von privaten GKE-Knoten zugelassen wird. Weitere Informationen finden Sie unter Beispielkonfiguration für GKE. Alternativ können Sie den privaten Google-Zugriff aktivieren, um eine Verbindung zu der Gruppe von externen IP-Adressen herzustellen, die von Google APIs und Google-Diensten verwendet werden.

  • Wenn Sie ein Google-Dienstkonto verwenden möchten, wenn Sie Config Sync Zugriff auf Ihre „Source of Truth“ gewähren, müssen Sie den schreibgeschützten Bereich in die Zugriffsbereiche für die Knoten im Cluster für Cloud Source Repositories aufnehmen.

    Sie können den schreibgeschützten Bereich hinzufügen, indem Sie cloud-source-repos-ro in die Liste --scopes aufnehmen, die beim Erstellen des Clusters angegeben wird, oder indem Sie den Bereich cloud-platform beim Erstellen des Clusters verwenden. Beispiel:

    gcloud container clusters create CLUSTER_NAME --scopes=cloud-platform
    

    Hinweis: Sie können Zugriffsbereiche nicht ändern, nachdem Sie einen Knotenpool erstellt haben. Allerdings haben Sie die Möglichkeit, unter Verwendung desselben Clusters einen neuen Knotenpool mit dem richtigen Zugriffsbereich zu erstellen. Der Standardbereich gke-default enthält nicht cloud-source-repos-ro.

  • Wenn Sie strenge VPC-Firewall-Anforderungen haben, die unnötigen Traffic blockieren, müssen Sie Firewallregeln erstellen, um den folgenden Traffic auf öffentlichen GKE-Clustern zuzulassen:

    • TCP: Eingehenden und ausgehenden Traffic an Port 53 und 443 zulassen

    • UDP: Erlauben Sie ausgehenden Traffic an Port 53.

    Wenn Sie diese Regeln nicht angeben, wird Config Sync nicht korrekt synchronisiert. nomos status meldet den folgenden Fehler:

    Error: KNV2004: unable to sync repo Error in the git-sync container

    Sie können diese Schritte überspringen, wenn Sie einen privaten GKE-Cluster verwenden.

Cluster vorbereiten

Führen Sie die folgenden Schritte aus, nachdem Sie einen geeigneten Cluster erstellt haben:

  1. Weisen Sie dem Nutzer die für die Registrierung des Clusters erforderlichen IAM-Rollen zu.

  2. Wenn Sie die Google Cloud CLI zum Konfigurieren von Config Sync verwenden oder Cluster außerhalb von Google Cloud verwenden möchten, müssen Ihre GKE-Cluster oder Cluster außerhalb von Google Cloud jetzt bei einer Flotte registriert sein. Wenn Sie die Google Cloud Console verwenden möchten, können Sie GKE-Cluster beim Konfigurieren von Config Sync registrieren.

Config Sync installieren

In den folgenden Abschnitten gewähren Sie Config Sync Zugriff auf eine der folgenden Informationsquellen:

Nachdem Sie den Zugriff gewährt haben, können Sie Config Sync konfigurieren.

Zugriff auf Git gewähren

Config Sync benötigt Lesezugriff auf Ihr Git-Repository, damit es die Konfigurationen, die Sie per Commit in das Repository geschrieben haben, lesen und auf Ihre Cluster anwenden kann.

Falls für den Lesezugriff auf Ihr Repository keine Authentifizierung erforderlich ist, können Sie mit der Konfiguration von Config Sync fortfahren und none als Authentifizierungstyp verwenden. Wenn Sie beispielsweise das Repository über eine Weboberfläche durchsuchen können, ohne sich anzumelden, oder git clone verwenden können, um einen Klon des Repositorys lokal zu erstellen, ohne Anmeldedaten anzugeben oder gespeicherte Anmeldedaten zu verwenden, ist keine Authentifizierung erforderlich. In diesem Fall müssen Sie kein Secret erstellen.

Die meisten Nutzer müssen jedoch Anmeldedaten erstellen, da der Lesezugriff auf ihr Repository eingeschränkt ist. Wenn Anmeldedaten erforderlich sind, werden diese auf jedem registrierten Cluster im git-creds-Secret gespeichert, sofern Sie kein Google-Dienstkonto verwenden. Das Secret muss den Namen git-creds haben, da dies ein fester Wert ist.

Config Sync unterstützt die folgenden Authentifizierungsmechanismen:

  • SSH-Schlüsselpaar (ssh)
  • Cookiedatei (cookiefile)
  • Token (token)
  • Google-Dienstkonto (gcpserviceaccount)
  • Standardmäßiges Compute Engine-Dienstkonto (gcenode)

Welchen Mechanismus Sie wählen, hängt davon ab, was Ihr Repository unterstützt. Im Allgemeinen empfehlen wir die Verwendung eines SSH-Schlüsselpaars. GitHub und Bitbucket unterstützen beide die Verwendung eines SSH-Schlüsselpaars. Wenn Sie jedoch ein Repository in Cloud Source Repositories verwenden, empfehlen wir stattdessen die Verwendung eines Google-Dienstkontos. Wenn Ihr Repository von Ihrer Organisation gehostet wird und Sie nicht wissen, welche Authentifizierungsmethoden unterstützt werden, wenden Sie sich an Ihren Administrator.

Wenn Sie ein Repository in Cloud Source Repositories als Config Sync-Repository verwenden möchten, führen Sie die folgenden Schritte aus, um Ihre Cloud Source Repositories-URL abzurufen:

  1. Listen Sie alle Repositories auf:

    gcloud source repos list
    
  2. Kopieren Sie aus der Ausgabe die URL des Repositorys, das Sie verwenden möchten. Beispiel:

    REPO_NAME  PROJECT_ID  URL
    my-repo    my-project  https://source.developers.google.com/p/my-project/r/my-repo-csr
    

    Sie benötigen diese URL bei der Konfiguration von Config Sync im folgenden Abschnitt. Wenn Sie Config Sync über die Google Cloud Console konfigurieren, fügen Sie die URL in das Feld URL ein. Wenn Sie Config Sync mithilfe des Google Cloud CLI konfigurieren, fügen Sie die URL dem Feld syncRepo Ihrer Konfigurationsdatei hinzu.

SSH-Schlüsselpaar

Ein SSH-Schlüsselpaar besteht aus zwei Dateien, einem öffentlichen und einem privaten Schlüssel. Der öffentliche Schlüssel hat in der Regel die Erweiterung .pub.

Führen Sie die folgenden Schritte aus, um ein SSH-Schlüsselpaar zu verwenden:

  1. Erstellen Sie ein SSH-Schlüsselpaar, damit sich Config Sync bei Ihrem Git-Repository authentifizieren kann. Dieser Schritt ist erforderlich, wenn Sie sich beim Repository authentifizieren müssen, um es zu klonen oder Daten daraus zu lesen. Überspringen Sie diesen Schritt, wenn Sie ein Schlüsselpaar von einem Sicherheitsadministrator erhalten. Sie können ein einziges Schlüsselpaar für alle Cluster oder ein Schlüsselpaar pro Cluster verwenden, je nach Ihren Sicherheits- und Complianceanforderungen.

    Mit dem folgenden Befehl wird ein 4.096-Bit-RSA-Schlüssel erstellt. Niedrigere Werte werden nicht empfohlen:

    ssh-keygen -t rsa -b 4096 \
    -C "GIT_REPOSITORY_USERNAME" \
    -N '' \
    -f /path/to/KEYPAIR_FILENAME
    

    Ersetzen Sie Folgendes:

    • GIT_REPOSITORY_USERNAME: Nutzername, mit dem sich Config Sync beim Repository authentifizieren soll
    • /path/to/KEYPAIR_FILENAME: Pfad zum Schlüsselpaar

    Wenn Sie einen Drittanbieter-Host für das Git-Repository wie GitHub oder ein Dienstkonto mit Cloud Source Repositories nutzen möchten, empfehlen wir die Verwendung eines separaten Kontos.

  2. Konfigurieren Sie Ihr Repository so, dass der neu erstellte öffentliche Schlüssel erkannt wird. Weitere Informationen finden Sie in der Dokumentation Ihres Git-Hostanbieters. Anleitungen für einige beliebte Git-Hostanbieter finden Sie hier:

  3. Fügen Sie den privaten Schlüssel einem neuen Secret im Cluster hinzu:

    kubectl create ns config-management-system && \
    kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-file=ssh=/path/to/KEYPAIR_PRIVATE_KEY_FILENAME
    

    Ersetzen Sie /path/to/KEYPAIR_PRIVATE_KEY_FILENAME durch den Namen des privaten Schlüssels (den Namen ohne das Suffix .pub).

  4. (Empfohlen) Wenn Sie die Prüfung von bekannten Hosts mithilfe der SSH-Authentifizierung konfigurieren möchten, können Sie den Schlüssel der bekannten Hosts dem Feld data.known_hosts im Secret git_creds hinzufügen. Wenn Sie die known_hosts-Prüfung deaktivieren möchten, können Sie das Feld known_hosts aus dem Secret entfernen. Führen Sie folgenden Befehl aus, um den Schlüssel des bekannten Hosts hinzuzufügen:

    kubectl edit secret git-creds \
     --namespace=config-management-system
    

    Fügen Sie dann unter data den Eintrag des bekannten Hosts hinzu:

    known_hosts: KNOWN_HOSTS_KEY
    
  5. Löschen Sie den privaten Schlüssel vom lokalen Datenträger oder schützen Sie ihn anderweitig.

  6. Verwenden Sie das SSH-Protokoll, wenn Sie Config Sync konfigurieren und die URL für Ihr Git-Repository hinzufügen. Wenn Sie ein Repository in Cloud Source Repositories verwenden, müssen Sie das folgende Format bei der Eingabe Ihrer URL verwenden:

    ssh://EMAIL@source.developers.google.com:2022/p/PROJECT_ID/r/REPO_NAME
    

    Ersetzen Sie Folgendes:

    • EMAIL: Ihr Google Cloud-Nutzername.
    • PROJECT_ID: ID des Google Cloud-Projekts, in dem sich das Repository befindet.
    • REPO_NAME: Name des Repositorys.

Cookiefile

Der Vorgang zum Abrufen eines cookiefile hängt von der Konfiguration Ihres Repositorys ab. Ein Beispiel finden Sie in der Dokumentation zu Cloud Source Repositories unter Statische Anmeldedaten generieren. Die Anmeldedaten werden normalerweise in der Datei .gitcookies im Basisverzeichnis gespeichert. Sie können Ihnen aber auch von einem Sicherheitsadministrator zur Verfügung gestellt werden.

Führen Sie die folgenden Schritte aus, um ein cookiefile zu erstellen:

  1. Nachdem Sie das cookiefile erstellt und abgerufen haben, fügen Sie es einem neuen Secret im Cluster hinzu:

    Wenn Sie keinen HTTPS-Proxy verwenden, erstellen Sie das Secret mit dem folgenden Befehl:

    kubectl create ns config-management-system && \
    kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-file=cookie_file=/path/to/COOKIEFILE
    

    Wenn Sie einen HTTPS-Proxy verwenden müssen, fügen Sie ihn zusammen mit cookiefile zum Secret hinzu. Führen Sie dazu den folgenden Befehl aus:

    kubectl create ns config-management-system && \
    kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-file=cookie_file=/path/to/COOKIEFILE \
     --from-literal=https_proxy=HTTPS_PROXY_URL
    

    Ersetzen Sie Folgendes:

    • /path/to/COOKIEFILE: der entsprechende Pfad und Dateiname
    • HTTPS_PROXY_URL: Die URL für den HTTPS-Proxy, den Sie bei der Kommunikation mit dem Git-Repository verwenden.
  2. Schützen Sie den Inhalt des cookiefile, wenn Sie es noch lokal benötigen. Andernfalls können Sie es löschen.

Token

Wenn Ihre Organisation die Verwendung von SSH-Schlüsseln nicht zulässt, sollten Sie ein Token verwenden. Mit Config Sync können Sie die persönlichen Zugriffstokens (Personal Access Tokens, PATs) von GitHub, die PATs oder die Deployment-Schlüssel von GitLab oder das App-Passwort von Bitbucket als Token verwenden.

Führen Sie die folgenden Schritte aus, um mit dem Token ein Secret zu erstellen:

  1. Erstellen Sie ein Token mit GitHub, GitLab oder Bitbucket.

  2. Nachdem Sie das Token erstellt und abgerufen haben, fügen Sie es einem neuen Secret im Cluster hinzu.

    Wenn Sie keinen HTTPS-Proxy verwenden, erstellen Sie das Secret mit dem folgenden Befehl:

    kubectl create ns config-management-system && \
    kubectl create secret generic git-creds \
      --namespace="config-management-system" \
      --from-literal=username=USERNAME \
      --from-literal=token=TOKEN
    

    Dabei gilt:

    • USERNAME: Nutzername, den Sie verwenden möchten.
    • TOKEN: Token, das Sie im vorherigen Schritt erstellt haben.

    Wenn Sie einen HTTPS-Proxy verwenden müssen, fügen Sie ihn zusammen mit username und token dem Secret hinzu. Führen Sie dazu den folgenden Befehl aus:

    kubectl create ns config-management-system && \
    kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=username=USERNAME \
      --from-literal=token=TOKEN \
     --from-literal=https_proxy=HTTPS_PROXY_URL
    

    Ersetzen Sie Folgendes:

    • USERNAME: Nutzername, den Sie verwenden möchten.
    • TOKEN: Token, das Sie im vorherigen Schritt erstellt haben.
    • HTTPS_PROXY_URL: Die URL für den HTTPS-Proxy, den Sie bei der Kommunikation mit dem Git-Repository verwenden.
  3. Schützen Sie das Token, wenn Sie es noch lokal benötigen. Andernfalls können Sie es löschen.

Google-Dienstkonto

Wenn sich Ihr Repository in Cloud Source Repositories befindet und Ihr Cluster GKE Workload Identity oder Workload Identity für die Flotte verwendet, können Sie Config Sync Zugriff auf ein Repository im selben Projekt wie Ihr verwalteter Cluster gewähren. Verwenden Sie dazu ein Google-Dienstkonto.

  1. Wenn Sie noch kein Dienstkonto haben, erstellen Sie eines.

  2. Weisen Sie dem Google-Dienstkonto die IAM-Rolle „Cloud Source Repositories-Leser“ (roles/source.reader) zu. Weitere Informationen zu Rollen und Berechtigungen für Cloud Source Repositories finden Sie unter Berechtigungen zum Ansehen von Repositories erteilen.

    • Erteilen Sie projektweite Berechtigungen, wenn dieselben Berechtigungen für alle Repositories im Projekt gelten.

      gcloud projects add-iam-policy-binding PROJECT_ID \
        --role=roles/source.reader \
        --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
      
    • Erteilen Sie eine Repository-spezifische Berechtigung, wenn Dienstkonten unterschiedliche Zugriffsebenen für jedes Repository in Ihrem Projekt haben sollen.

      gcloud source repos set-iam-policy REPOSITORY POLICY_FILE --project=PROJECT_ID
      
  3. Wenn Sie Config Sync mit der Google Cloud Console konfigurieren, wählen Sie Workload Identity als Authentifizierungstyp aus und fügen Sie dann die E-Mail-Adresse Ihres Dienstkontos hinzu.

    Wenn Sie Config Sync mithilfe des Google Cloud CLI konfigurieren, fügen Sie gcpserviceaccount als secretType hinzu und fügen Sie dann die E-Mail-Adresse Ihres Dienstkontos zu gcpServiceAccountEmail hinzu.

  4. Erstellen Sie nach der Konfiguration von Config Sync eine IAM-Richtlinienbindung zwischen dem Kubernetes-Dienstkonto und dem Google-Dienstkonto. Das Kubernetes-Dienstkonto wird erst erstellt, wenn Sie Config Sync zum ersten Mal konfigurieren.

    Wenn Sie Cluster verwenden, die bei einer Flotte registriert sind, müssen Sie die Richtlinienbindung nur einmal pro Flotte erstellen. Alle in einer Flotte registrierten Cluster haben denselben Workload Identity-Pool. Gemäß dem Konzept der Gleichheit der Flotte erhält das Kubernetes-Dienstkonto aus demselben Namespace auf anderen Clustern in derselben Flotte dieselbe IAM-Richtlinie, wenn Sie Ihrem Kubernetes-Dienstkonto die IAM-Richtlinie in einem Cluster hinzufügen.

    Durch diese Bindung kann das Kubernetes-Dienstkonto von Config Sync als Google-Dienstkonto verwendet werden:

    gcloud iam service-accounts add-iam-policy-binding \
        GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/iam.workloadIdentityUser \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
        --project=PROJECT_ID
    

Ersetzen Sie Folgendes:

  • PROJECT_ID: Projekt-ID der Organisation
  • FLEET_HOST_PROJECT_ID: Wenn Sie GKE Workload Identity verwenden, entspricht dies PROJECT_ID. Wenn Sie Workload Identity für die Flotte verwenden, ist dies die Projekt-ID der Flotte, bei der Ihr Cluster registriert ist.
  • GSA_NAME: das benutzerdefinierte Google-Dienstkonto, das Sie zum Herstellen einer Verbindung zu Artifact Registry verwenden möchten. Das Dienstkonto muss die IAM-Rolle „Artifact Registry-Leser“ (roles/artifactregistry.reader) haben.
  • KSA_NAME: das Kubernetes-Dienstkonto für den Abgleich.
    • Wenn der RootSync-Name bei Root-Repositories root-sync lautet, verwenden Sie root-reconciler. Andernfalls verwenden Sie root-reconciler-ROOT_SYNC_NAME. Wenn Sie Config Sync über die Google Cloud Console oder die Google Cloud CLI installieren, erstellt Config Sync automatisch ein RootSync-Objekt mit dem Namen root-sync.
  • REPOSITORY: der Name des Repositorys.
  • POLICY_FILE: die JSON- oder YAML-Datei mit der Richtlinie zu Identity and Access Management.

Standardmäßiges Compute Engine-Dienstkonto

Wenn sich Ihr Repository in Cloud Source Repositories befindet und Ihr Cluster GKE in Google Cloud ist und Workload Identity deaktiviert ist, können Sie gcenode als Authentifizierungstyp verwenden.

Wenn Sie Config Sync mit der Google Cloud Console konfigurieren, wählen Sie als Authentifizierungstyp Google Cloud Repository aus.

Wenn Sie Config Sync über die Google Cloud CLI konfigurieren, fügen Sie gcenode als secretType hinzu.

Wenn Sie entweder Google Cloud Repository oder gcenode auswählen, können Sie das Compute Engine-Standarddienstkonto verwenden. Sie müssen dem Compute Engine-Standarddienstkonto die IAM-Rolle „Cloud Source Repositories-Leser“ (roles/source.reader) zuweisen. Weitere Informationen zu Rollen und Berechtigungen für Cloud Source Repositories finden Sie unter Berechtigungen zum Ansehen von Repositories erteilen.

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/source.reader \
  --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

Ersetzen Sie PROJECT_ID durch die Projekt-ID Ihrer Organisation und PROJECT_NUMBER durch die Projektnummer Ihrer Organisation.

Config Sync Lesezugriff auf OCI gewähren

Config Sync benötigt Lesezugriff auf das in Artifact Registry gespeicherte OCI-Image, damit die im Image enthaltenen Konfigurationen gelesen und auf Ihre Cluster angewendet werden können.

Falls für den Lesezugriff auf Ihr Image keine Authentifizierung erforderlich ist, können Sie mit der Konfiguration von Config Sync fortfahren und none als Authentifizierungstyp verwenden. Wenn Ihr Image beispielsweise öffentlich ist und jeder im Internet darauf zugreifen kann, müssen Sie sich nicht authentifizieren.

Die meisten Nutzer müssen jedoch Anmeldedaten erstellen, um auf eingeschränkte Images zuzugreifen. Config Sync unterstützt die folgenden Authentifizierungsmechanismen:

  • Kubernetes-Dienstkonto (k8sserviceaccount)
  • Google-Dienstkonto (gcpserviceaccount)
  • Standardmäßiges Compute Engine-Dienstkonto (gcenode)

Kubernetes-Dienstkonto

Wenn Sie das OCI-Image in Artifact Registry speichern und Ihr Cluster GKE Workload Identity oder die Workload Identity für die Flotte verwendet, können Sie in Version 1.17.2 und höher k8sserviceaccount als Authentifizierungstyp verwenden. Diese Option wird aufgrund des vereinfachten Konfigurationsprozesses gegenüber gcpserviceaccount empfohlen.

  1. Weisen Sie dem Kubernetes-Dienstkonto mit dem Workload Identity-Pool die IAM-Rolle „Artifact Registry-Leser“ (roles/artifactregistry.reader) zu. Weitere Informationen zu Artifact Registry-Rollen und -Berechtigungen finden Sie unter Rollen und Berechtigungen für Artifact Registry konfigurieren.

    • Erteilen Sie projektweite Berechtigungen, wenn dieselben Berechtigungen für alle Repositories im Projekt gelten.

      gcloud projects add-iam-policy-binding PROJECT_ID \
            --role=roles/artifactregistry.reader \
            --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
      
    • Erteilen Sie eine Repository-spezifische Berechtigung, wenn Dienstkonten unterschiedliche Zugriffsebenen für jedes Repository in Ihrem Projekt haben sollen.

      gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
         --location=LOCATION \
         --role=roles/artifactregistry.reader \
         --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
         --project=PROJECT_ID
      

    Ersetzen Sie Folgendes:

    • PROJECT_ID: Projekt-ID der Organisation
    • FLEET_HOST_PROJECT_ID: Wenn Sie GKE Workload Identity verwenden, entspricht dies PROJECT_ID. Wenn Sie Workload Identity für die Flotte verwenden, ist dies die Projekt-ID der Flotte, bei der Ihr Cluster registriert ist.
    • KSA_NAME: das Kubernetes-Dienstkonto für den Abgleich.
      • Wenn der RootSync-Name bei Root-Repositories root-sync lautet, verwenden Sie root-reconciler. Andernfalls verwenden Sie root-reconciler-ROOT_SYNC_NAME. Wenn Sie Config Sync über die Google Cloud Console oder die Google Cloud CLI installieren, erstellt Config Sync automatisch ein RootSync-Objekt mit dem Namen root-sync.
    • REPOSITORY: die ID des Repositorys.
    • LOCATION: der regionale oder multiregionale Standort des Repositorys.

Google-Dienstkonto

Wenn Sie das OCI-Image in Artifact Registry speichern und Ihr Cluster GKE Workload Identity oder die Workload Identity für die Flotte verwendet, können Sie gcpserviceaccount als Authentifizierungstyp verwenden. Ab Version 1.17.2 wird empfohlen, stattdessen k8sserviceaccount zu verwenden. Mit dieser Option entfallen die zusätzlichen Schritte zum Erstellen eines Google-Dienstkontos und der zugehörigen IAM-Richtlinienbindung.

  1. Wenn Sie noch kein Dienstkonto haben, erstellen Sie eines.

  2. Weisen Sie dem Google-Dienstkonto die IAM-Rolle „Artifact Registry-Leser“ (roles/artifactregistry.reader) zu. Weitere Informationen zu Artifact Registry-Rollen und -Berechtigungen finden Sie unter Rollen und Berechtigungen für Artifact Registry konfigurieren.

    • Erteilen Sie projektweite Berechtigungen, wenn dieselben Berechtigungen für alle Repositories im Projekt gelten.

      gcloud projects add-iam-policy-binding PROJECT_ID  \
         --role=roles/artifactregistry.reader \
         --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
      
    • Erteilen Sie eine Repository-spezifische Berechtigung, wenn Dienstkonten unterschiedliche Zugriffsebenen für jedes Repository in Ihrem Projekt haben sollen.

      gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
         --location=LOCATION \
         --role=roles/artifactregistry.reader \
         --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
         --project=PROJECT_ID
      
  3. Erstellen Sie mit dem folgenden Befehl eine IAM-Richtlinienbindung zwischen dem Kubernetes-Dienstkonto und dem Google-Dienstkonto:

    gcloud iam service-accounts add-iam-policy-binding
      GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/iam.workloadIdentityUser \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
        --project=PROJECT_ID
    

Ersetzen Sie Folgendes:

  • PROJECT_ID: Projekt-ID der Organisation
  • FLEET_HOST_PROJECT_ID: Wenn Sie GKE Workload Identity verwenden, entspricht dies PROJECT_ID. Wenn Sie Workload Identity für die Flotte verwenden, ist dies die Projekt-ID der Flotte, bei der Ihr Cluster registriert ist.
  • GSA_NAME: das benutzerdefinierte Google-Dienstkonto, das Sie zum Herstellen einer Verbindung zu Artifact Registry verwenden möchten. Das Dienstkonto muss die IAM-Rolle „Artifact Registry-Leser“ (roles/artifactregistry.reader) haben.
  • KSA_NAME: das Kubernetes-Dienstkonto für den Abgleich.
    • Wenn der RootSync-Name bei Root-Repositories root-sync lautet, verwenden Sie root-reconciler. Andernfalls verwenden Sie root-reconciler-ROOT_SYNC_NAME. Wenn Sie Config Sync über die Google Cloud Console oder die Google Cloud CLI installieren, erstellt Config Sync automatisch ein RootSync-Objekt mit dem Namen root-sync.
  • REPOSITORY: die ID des Repositorys.
  • LOCATION: der regionale oder multiregionale Standort des Repositorys.

Standardmäßiges Compute Engine-Dienstkonto

Wenn Sie Ihr Helm-Diagramm in Artifact Registry speichern und Ihr Cluster GKE in Google Cloud ist und Workload Identity deaktiviert ist, können Sie gcenode als Authentifizierungstyp verwenden. Config Sync verwendet das Compute Engine-Standarddienstkonto. Sie müssen Ihrem Compute Engine-Standarddienstkonto Lesezugriff auf Artifact Registry gewähren.

  1. Gewähren Sie dem Compute Engine-Dienstkonto die Leseberechtigung für Artifact Registry, indem Sie den folgenden Befehl ausführen:

    gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
       --role=roles/artifactregistry.reader
    

    Ersetzen Sie PROJECT_ID durch die Projekt-ID Ihrer Organisation und PROJECT_NUMBER durch die Projektnummer Ihrer Organisation.

Config Sync Lesezugriff auf Helm gewähren

Config Sync benötigt Lesezugriff auf Ihr Helm-Repository, damit die Helm-Diagramme in Ihrem Repository gelesen und in Ihren Clustern installiert werden können.

Wenn für den Lesezugriff auf Ihr Repository keine Authentifizierung erforderlich ist, können Sie mit der Konfiguration von Config Sync fortfahren und none als Authentifizierungstyp verwenden. Wenn Ihr Helm-Repository beispielsweise öffentlich ist und von jedem über das Internet aufgerufen werden kann, müssen Sie sich nicht authentifizieren.

Die meisten Nutzer müssen jedoch Anmeldedaten erstellen, um auf private Helm-Repositories zugreifen zu können. Config Sync unterstützt die folgenden Authentifizierungsmechanismen:

  • Token (token)
  • Kubernetes-Dienstkonto (k8sserviceaccount)
  • Google-Dienstkonto (gcpserviceaccount)
  • Standardmäßiges Compute Engine-Dienstkonto (gcenode)

Token

Erstellen Sie ein Secret mit einem Nutzernamen und einem Passwort für das Helm-Repository:

kubectl create secret generic SECRET_NAME \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
    --from-literal=password=PASSWORD

Ersetzen Sie Folgendes:

  • SECRET_NAME ist der Name, den Sie dem Secret geben möchten.
  • USERNAME: der Nutzername des Helm-Repositorys.
  • PASSWORD: das Passwort des Helm-Repositorys

Wenn Sie den ConfigManagement Operator konfigurieren, verwenden Sie den Secret-Namen, den Sie für spec.helm.secretRef.name ausgewählt haben.

Kubernetes-Dienstkonto

Wenn Sie Ihr Helm-Diagramm in Artifact Registry speichern und Ihr Cluster GKE Workload Identity oder die Workload Identity für die Flotte verwendet, können Sie in Version 1.17.2 und höher k8sserviceaccount als Authentifizierungstyp verwenden. Diese Option wird aufgrund des vereinfachten Konfigurationsprozesses gegenüber gcpserviceaccount empfohlen.

  1. Weisen Sie dem Kubernetes-Dienstkonto mit dem Workload Identity-Pool die IAM-Rolle „Artifact Registry-Leser“ (roles/artifactregistry.reader) zu. Weitere Informationen zu Artifact Registry-Rollen und -Berechtigungen finden Sie unter Rollen und Berechtigungen für Artifact Registry konfigurieren.

    • Erteilen Sie projektweite Berechtigungen, wenn dieselben Berechtigungen für alle Repositories im Projekt gelten.

      gcloud projects add-iam-policy-binding PROJECT_ID \
         --role=roles/artifactregistry.reader \
         --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
      
    • Erteilen Sie eine Repository-spezifische Berechtigung, wenn Dienstkonten unterschiedliche Zugriffsebenen für jedes Repository in Ihrem Projekt haben sollen.

      gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
         --location=LOCATION \
         --role=roles/artifactregistry.reader \
         --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
         --project=PROJECT_ID
      

    Ersetzen Sie Folgendes:

    • PROJECT_ID: Projekt-ID der Organisation
    • FLEET_HOST_PROJECT_ID: Wenn Sie GKE Workload Identity verwenden, entspricht dies PROJECT_ID. Wenn Sie Workload Identity für die Flotte verwenden, ist dies die Projekt-ID der Flotte, bei der Ihr Cluster registriert ist.
    • KSA_NAME: das Kubernetes-Dienstkonto für den Abgleich.
      • Wenn der RootSync-Name bei Root-Repositories root-sync lautet, verwenden Sie root-reconciler. Andernfalls verwenden Sie root-reconciler-ROOT_SYNC_NAME.
    • REPOSITORY: die ID des Repositorys.
    • LOCATION: der regionale oder multiregionale Standort des Repositorys.

Google-Dienstkonto

Wenn Sie Ihr Helm-Diagramm in Artifact Registry speichern und Ihr Cluster GKE Workload Identity oder Workload Identity für die Flotte verwendet, können Sie gcpserviceaccount als Authentifizierungstyp verwenden. Ab Version 1.17.2 wird empfohlen, stattdessen k8sserviceaccount zu verwenden. Mit dieser Option entfallen die zusätzlichen Schritte zum Erstellen eines Google-Dienstkontos und der zugehörigen IAM-Richtlinienbindung.

  1. Wenn Sie noch kein Dienstkonto haben, erstellen Sie eines.

  2. Weisen Sie dem Google-Dienstkonto die IAM-Rolle „Artifact Registry-Leser“ (roles/artifactregistry.reader) zu. Weitere Informationen zu Artifact Registry-Rollen und -Berechtigungen finden Sie unter Rollen und Berechtigungen für Artifact Registry konfigurieren.

    • Erteilen Sie projektweite Berechtigungen, wenn dieselben Berechtigungen für alle Repositories im Projekt gelten.

      gcloud projects add-iam-policy-binding PROJECT_ID  \
            --role=roles/artifactregistry.reader \
            --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
      
    • Erteilen Sie eine Repository-spezifische Berechtigung, wenn Dienstkonten unterschiedliche Zugriffsebenen für jedes Repository in Ihrem Projekt haben sollen.

      gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
         --location=LOCATION \
         --role=roles/artifactregistry.reader \
         --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
         --project=PROJECT_ID
      
  3. Erstellen Sie mit dem folgenden Befehl eine IAM-Richtlinienbindung zwischen dem Kubernetes-Dienstkonto und dem Google-Dienstkonto:

    gcloud iam service-accounts add-iam-policy-binding
      GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/iam.workloadIdentityUser \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
        --project=PROJECT_ID
    

Ersetzen Sie Folgendes:

  • PROJECT_ID: Projekt-ID der Organisation
  • FLEET_HOST_PROJECT_ID: Wenn Sie GKE Workload Identity verwenden, entspricht dies PROJECT_ID. Wenn Sie Workload Identity für die Flotte verwenden, ist dies die Projekt-ID der Flotte, bei der Ihr Cluster registriert ist.
  • GSA_NAME: das benutzerdefinierte Google-Dienstkonto, das Sie zum Herstellen einer Verbindung zu Artifact Registry verwenden möchten. Das Dienstkonto muss die IAM-Rolle „Artifact Registry-Leser“ (roles/artifactregistry.reader) haben.
  • KSA_NAME: das Kubernetes-Dienstkonto für den Abgleich.
    • Wenn der RootSync-Name bei Root-Repositories root-sync lautet, verwenden Sie root-reconciler. Andernfalls verwenden Sie root-reconciler-ROOT_SYNC_NAME.
  • REPOSITORY: die ID des Repositorys.
  • LOCATION: der regionale oder multiregionale Standort des Repositorys.

Standardmäßiges Compute Engine-Dienstkonto

Wenn Sie Ihr Helm-Diagramm in Artifact Registry speichern und Ihr Cluster GKE in Google Cloud ist und Workload Identity deaktiviert ist, können Sie gcenode als Authentifizierungstyp verwenden. Config Sync verwendet das Compute Engine-Standarddienstkonto. Sie müssen Ihrem Compute Engine-Standarddienstkonto Lesezugriff auf Artifact Registry gewähren. Möglicherweise müssen Sie den Zugriffsbereich storage-ro gewähren, um eine Leseberechtigung zum Abrufen von Images zu gewähren.

  1. Gewähren Sie dem Compute Engine-Dienstkonto Leseberechtigung für Artifact Registry:

    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
        --role=roles/artifactregistry.reader
    

    Ersetzen Sie PROJECT_ID durch die Projekt-ID Ihrer Organisation und PROJECT_NUMBER durch die Projektnummer Ihrer Organisation.

Config Sync konfigurieren

In diesem Abschnitt konfigurieren Sie die Einstellungen für Ihr Stamm-Repository. Wenn Sie eine Synchronisierung mit einem Git-Repository durchführen, können Sie die Google Cloud Console verwenden, um Sie durch den Installationsprozess zu führen und einige Schritte zu automatisieren.

Wenn Sie Config Sync über die Google Cloud Console oder die Google Cloud CLI installieren, erstellt Config Sync automatisch ein RootSync-Objekt mit dem Namen root-sync. Mit kubectl-Befehlen können Sie root-sync ändern und zusätzliche Config Sync-Konfigurationen hinzufügen. Weitere Informationen finden Sie unter Config Sync mit kubectl-Befehlen konfigurieren.

Console

Config Sync installieren

Damit Sie Config Sync verwenden können, müssen Sie zuerst Ihre Cluster registrieren. Wenn Sie Ihre Cluster registrieren, können sie einen gemeinsamen Satz von Konfigurationen und Richtlinien gemeinsam nutzen.

Führen Sie die folgenden Aufgaben aus, um Ihre Cluster zu registrieren:

  1. Rufen Sie in der Google Cloud Console im Bereich Features die Seite Konfiguration auf.

    Zur Konfiguration

  2. Klicken Sie auf Config Sync installieren.
  3. Wählen Sie in der Tabelle Verfügbare Cluster den zu registrierenden Cluster aus und klicken Sie dann auf Config Sync installieren.

    Nach einigen Minuten sollte in der Spalte Config Sync-Status für den ausgewählten Cluster Installiert angezeigt werden.

Paket bereitstellen

Nachdem Sie Ihre Cluster registriert haben, können Sie ein Paket aus einer Source of Truth in Ihrem Config Sync-Cluster bereitstellen. Sie können ein Paket in mehreren Clustern gleichzeitig bereitstellen und mehrere Pakete zu einem einzigen Cluster hinzufügen.

Führen Sie die folgenden Schritte aus, um ein Paket bereitzustellen:

  1. Rufen Sie in der Google Cloud Console das Config Sync-Dashboard auf.

    Zum Config Sync-Dashboard

  2. Klicken Sie auf Paket bereitstellen.

  3. Wählen Sie in der Tabelle Cluster für Paketbereitstellung auswählen den Cluster aus, für den Sie ein Paket bereitstellen möchten, und klicken Sie dann auf Weiter.

  4. Wählen Sie entweder Auf Git gehostetes Paket oder Auf OCI gehostetes Paket als Quelltyp aus und klicken Sie dann auf Weiter.

  5. Geben Sie im Bereich Paketdetails einen Paketnamen ein, der das RootSync- oder RepoSync-Objekt identifiziert.

  6. Führen Sie im Abschnitt Source (Quelle) folgende Schritte aus:

    • Geben Sie für Quellen, die in einem Git-Repository gehostet werden, die folgenden Felder ein:

      1. Geben Sie einen Paketnamen ein, der das RootSync- oder RepoSync-Objekt identifiziert.
      2. Geben Sie die URL des Git-Repositorys, das Sie als „Source of Truth“ verwenden, als Repository-URL ein.
      3. Optional: Aktualisieren Sie das Feld Revision, um zu prüfen, ob Sie nicht den Standardwert HEAD verwenden.
      4. Optional: Aktualisieren Sie das Feld Pfad, wenn Sie nicht vom Root-Repository synchronisieren möchten.
      5. Optional: Aktualisieren Sie das Feld Zweig, wenn Sie nicht den Standardzweig main verwenden.
    • Geben Sie für Quellen, die in einem OCI-Image gehostet werden, die folgenden Felder ein:

      1. Geben Sie unter Image die URL des OCI-Images ein, das Sie als „Source of Truth“ verwenden.
      2. Geben Sie unter Verzeichnis den Pfad des Verzeichnisses relativ zum Stammverzeichnis für die Synchronisierung ein.
  7. Wählen Sie im Feld Synchronisierungstyp entweder RootSync oder RepoSync als Synchronisierungstyp aus.

    RootSync-Objekte sind clusterbezogen und RepoSync-Objekte sind Namespace-bezogen. Weitere Informationen zu diesen Objekten finden Sie unter RootSync- und RepoSync-Felder.

  8. (Optional): Maximieren Sie den Abschnitt Erweiterte Einstellungen, um Folgendes zu tun:

    1. Wählen Sie einen Authentifizierungstyp aus:

      • Keine: Keine Authentifizierung verwenden.
      • SSH: Ein SSH-Schlüsselpaar verwenden.
      • Cookiefile: Ein cookiefile verwenden.
      • Token: Ein Token verwenden.
      • Google Cloud Repository: Ein Google-Dienstkonto verwenden, um auf ein Repository in Cloud Source Repository zuzugreifen. Wählen Sie diese Option nur aus, wenn Workload Identity in Ihrem Cluster nicht aktiviert ist.
      • Workload Identity: Verwenden Sie ein Google-Dienstkonto, um auf ein Cloud Source Repositories-Repository zuzugreifen.
    2. Geben Sie eine Zahl in Sekunden ein, um die Synchronisierungswartezeit festzulegen. Dadurch wird bestimmt, wie lange Config Sync zwischen der Synchronisierung über die „Source of Truth“ wartet.

    3. Geben Sie eine Git-Proxy-URL für den HTTPS-Proxy ein, der bei der Kommunikation mit der „Source of Truth“ verwendet werden soll.

    4. Wählen Sie Hierarchie aus, um das Quellformat zu ändern.

      Der Standardwert Unstructured (Unstrukturiert) wird in den meisten Fällen empfohlen, da Sie Ihre Source of Truth nach Belieben organisieren können.

  9. Klicken Sie auf Paket bereitstellen.

    Sie werden zur Config Sync-Seite Pakete weitergeleitet. Nach einigen Minuten sollte in der Spalte Synchronisierungsstatus für den von Ihnen konfigurierten Cluster Synchronisiert angezeigt werden.

  10. Maximieren Sie zum Aktualisieren eines Pakets auf dem Tab Pakete den Paketnamen, den Sie bearbeiten möchten, und klicken Sie dann auf Bearbeiten.

gcloud

Bevor Sie fortfahren, müssen Sie Ihre Cluster bei einer Flotte registrieren.

  1. Bereiten Sie die Konfiguration vor, indem Sie entweder ein neues apply-spec.yaml-Manifest erstellen oder ein vorhandenes Manifest verwenden. Mit einem vorhandenen Manifest können Sie den Cluster mit denselben Einstellungen konfigurieren, die auch von einem anderen Cluster verwendet werden.

Neues Manifest erstellen

Erstellen Sie eine Datei mit dem Namen apply-spec.yaml und kopieren Sie die folgende YAML-Datei in diese Datei, um Config Sync mit neuen Einstellungen für Ihren Cluster zu konfigurieren.

Sie können alle optionalen spec.configSync-Felder festlegen, die Sie beim Erstellen des Manifests benötigen, und später kubectl-Befehle zur Konfiguration verwenden. Sie können das Feld spec.configSync.enabled auch als true festlegen und die optionalen Felder weglassen. Sie können dann später kubectl-Befehle verwenden, um zusätzliche RootSync-Objekte oder RepoSyncs zu erstellen, die Sie später vollständig mit kubectl-Befehlen verwalten können.

# apply-spec.yaml

applySpecVersion: 1
spec:
  configSync:
    # Set to true to install and enable Config Sync
    enabled: true
    # If you don't have a source of truth yet, omit the
    # following fields. You can configure them later.
    sourceType: SOURCE_TYPE
    sourceFormat: FORMAT
    syncRepo: REPO
    syncRev: REVISION
    syncBranch: BRANCH
    secretType: SECRET_TYPE
    gcpServiceAccountEmail: EMAIL
    metricsGcpServiceAccountEmail: METRICS_EMAIL
    policyDir: DIRECTORY
    preventDrift: PREVENT_DRIFT

Ersetzen Sie Folgendes:

  • SOURCE_TYPE: Fügen Sie git für die Synchronisierung aus einem Git-Repository, oci für die Synchronisierung aus einem OCI-Image oder helm für die Synchronisierung aus einem Helm-Diagramm hinzu. Wenn kein Wert angegeben wird, wird der Standardwert git verwendet.
  • FORMAT: Fügen Sie unstructured hinzu, um ein unstrukturiertes Repository zu verwenden, oder fügen Sie hierarchy hinzu, um ein hierarchisches Repository zu verwenden. Bei diesen Werten wird zwischen Groß- und Kleinschreibung unterschieden. Dieses Feld ist optional und der Standardwert ist hierarchy. Wir empfehlen das Hinzufügen von unstructured, da Sie mit diesem Format Ihre Konfigurationen so organisieren können, wie es für Sie am besten ist.
  • REPO: Fügen Sie die URL der „Source of Truth“ hinzu. Git- und Helm-Repository-URLs verwenden entweder das HTTPS- oder das SSH-Protokoll. Beispiel: https://github.com/GoogleCloudPlatform/anthos-config-management-samples Wenn Sie SSH als secretType verwenden möchten, geben Sie Ihre URL mit dem SSH-Protokoll ein. Dieses Feld ist erforderlich. Wenn Sie kein Protokoll eingeben, wird die URL als HTTPS-URL behandelt.

    OCI-URLs haben das folgende Format: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Standardmäßig wird das Image aus dem Tag latest abgerufen, aber Sie können stattdessen Images von TAG oder DIGEST abrufen. Geben Sie TAG oder DIGEST im PACKAGE_NAME an:

    • Zum Abrufen von TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
    • Zum Abrufen von DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
  • REVISION: Die Git-Version (Tag oder Hash), von der aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist HEAD. Ab Config Sync Version 1.17.0 können Sie auch einen Zweignamen im Feld syncRev angeben. In Version 1.17.0 oder höher muss ein Hashwert und keine Abkürzung verwendet werden.

  • BRANCH: Zweig des Repositorys, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist master. Ab Config Sync Version 1.17.0 wird der Einfachheit halber empfohlen, das Feld syncRev zu verwenden, um einen Zweignamen anzugeben. Wenn sowohl das Feld syncRev als auch das Feld syncBranch angegeben sind, hat syncRev Vorrang vor syncBranch.

  • SECRET_TYPE: einer der folgenden secretTypes:

    git

    • none: Keine Authentifizierung verwenden
    • ssh: Ein SSH-Schlüsselpaar verwenden.
    • cookiefile: Einen cookiefile verwenden.
    • token: Ein Token verwenden.
    • gcpserviceaccount: Mit einem Google-Dienstkonto auf Cloud Source Repositories zugreifen Wenn Sie diesen Authentifizierungstyp auswählen, müssen Sie eine IAM-Richtlinienbindung erstellen, nachdem Sie Config Sync konfiguriert haben. Weitere Informationen finden Sie auf dem Tab „Google-Dienstkonto“ unter Config Sync Lesezugriff auf Git gewähren.
    • gcenode: Mit einem Google-Dienstkonto auf Cloud Source Repositories zugreifen Wählen Sie diese Option nur aus, wenn Workload Identity nicht in Ihrem Cluster aktiviert ist.

    Weitere Informationen zu diesen Authentifizierungstypen finden Sie unter Config Sync Lesezugriff auf Git gewähren.

    oci

    • none: Keine Authentifizierung verwenden
    • gcenode: Verwenden Sie das Compute Engine-Standarddienstkonto, um auf ein Image in Artifact Registry zuzugreifen. Wählen Sie diese Option nur aus, wenn Workload Identity nicht in Ihrem Cluster aktiviert ist.
    • gcpserviceaccount: Verwenden Sie ein Google-Dienstkonto für den Zugriff auf ein Image.

    helm

    • token: Ein Token verwenden.
    • gcenode: Verwenden Sie das Compute Engine-Standarddienstkonto, um auf ein Image in Artifact Registry zuzugreifen. Wählen Sie diese Option nur aus, wenn Workload Identity nicht in Ihrem Cluster aktiviert ist.
    • gcpserviceaccount: Verwenden Sie ein Google-Dienstkonto für den Zugriff auf ein Image.
  • EMAIL: Wenn Sie gcpserviceaccount für secretType angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.

  • METRICS_EMAIL: die E-Mail-Adresse des Google Cloud-Dienstkontos, das zum Exportieren von Config Sync-Messwerten nach Cloud Monitoring verwendet wird Die Appliance muss die IAM-Rolle „Monitoring-Messwert-Autor“ (roles/monitoring.metricWriter) haben. Das Kubernetes-Dienstkonto default im Namespace config-management-monitoring sollte an die Google Search Appliance gebunden sein.

  • DIRECTORY: der Pfad des Verzeichnisses, von dem aus synchronisiert werden soll, relativ zum Stammverzeichnis des Git-Repositorys. Alle Unterverzeichnisse des von Ihnen angegebenen Verzeichnisses werden einbezogen und mit dem Cluster synchronisiert. Der Standardwert ist das Stammverzeichnis des Repositorys.

  • PREVENT_DRIFT: Wenn dieser Wert auf true gesetzt ist, wird der Config Sync-Zulassungs-Webhook aktiviert, um Drifts zu verhindern, indem Änderungskonflikte nicht an Live-Cluster übertragen werden. Die Standardeinstellung ist false. Config Sync korrigiert Drifts immer, unabhängig vom Wert dieses Felds.

Eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter gcloud-Felder.

Vorhandenes Manifest verwenden

Um den Cluster mit den Einstellungen zu konfigurieren, die von einem anderen Cluster verwendet werden, rufen Sie diese Einstellungen von einem registrierten Cluster ab.

gcloud alpha container fleet config-management fetch-for-apply \
    --membership=MEMBERSHIP_NAME \
    --project=PROJECT_ID \
    > CONFIG_YAML_PATH

Ersetzen Sie Folgendes:

  • MEMBERSHIP_NAME: Name der Mitgliedschaft des registrierten Clusters mit den Config Sync-Einstellungen, die Sie verwenden möchten.
  • PROJECT_ID: Ihre Projekt-ID.
  • CONFIG_YAML_PATH: Der Pfad zur Datei apply-spec.yaml, die die aus dem Cluster abgerufenen Einstellungen enthält.

2. Wenden Sie die Datei apply-spec.yaml an: Wenn Sie ein vorhandenes Manifest verwenden, sollten Sie die Datei auf den Cluster anwenden, den Sie mit den Einstellungen konfigurieren möchten, die Sie im vorherigen Befehl abgerufen haben:

  gcloud beta container fleet config-management apply \
      --membership=MEMBERSHIP_NAME \
      --config=CONFIG_YAML_PATH \
      --project=PROJECT_ID

Dabei gilt:

  • MEMBERSHIP_NAME: Name der Mitgliedschaft, den Sie bei der Registrierung Ihres Clusters ausgewählt haben. Sie finden den Namen mit gcloud container fleet memberships list.
  • CONFIG_YAML_PATH: Pfad zur Datei apply-spec.yaml
  • PROJECT_ID: Ihre Projekt-ID.

Nachdem Sie die Konfiguration des Root-Repositorys abgeschlossen haben, können Sie optional die Synchronisierung aus mehreren Repositories konfigurieren, einschließlich anderer Root- und Namespace-Repositories. Die Namespace-Repositories sind hilfreich, wenn Sie ein Repository mit Namespace-bezogenen Konfigurationen wünschen, die clusterübergreifend mit einem bestimmten Namespace synchronisiert werden.

Standardeinstellungen auf Flottenebene konfigurieren

Wenn Sie die Google Kubernetes Engine (GKE) Enterprise-Version aktiviert haben, können Sie Config Sync als Standardeinstellung auf Flottenebene für Ihre Cluster aktivieren und konfigurieren. Das bedeutet, dass Config Sync für jeden neuen GKE in Google Cloud-Cluster, der bei der Clustererstellung registriert wird, mit den von Ihnen angegebenen Einstellungen für den Cluster aktiviert ist. Weitere Informationen zur Flotten-Standardkonfiguration finden Sie unter Features auf Flottenebene verwalten.

Führen Sie die folgenden Schritte aus, um für Config Sync Standardeinstellungen auf Flottenebene zu konfigurieren:

  1. Rufen Sie in der Google Cloud Console die Seite Feature Manager auf.

    Zu Feature Manager

  2. Klicken Sie im Bereich Config Sync auf Konfigurieren.

  3. Einstellungen auf Flottenebene überprüfen. Alle neuen Cluster, die Sie bei der Flotte registrieren, übernehmen diese Einstellungen.

  4. Optional: Klicken Sie zum Ändern der Standardeinstellungen auf Flotteneinstellungen anpassen. Führen Sie im angezeigten Dialogfeld die folgenden Schritte aus:

    1. Wählen Sie in der Liste Version die Config Sync-Version aus, die Sie verwenden möchten.
    2. Klicken Sie auf Änderungen speichern.
  5. Klicken Sie auf Konfigurieren.

  6. Klicken Sie im Dialogfeld zur Bestätigung auf Bestätigen. Wenn Sie Config Sync noch nicht aktiviert haben, wird durch Klicken auf Bestätigen auch die anthosconfigmanagement.googleapis.com API aktiviert.

  7. Optional: Synchronisieren Sie vorhandene Cluster mit den Standardeinstellungen:

    1. Wählen Sie in der Liste Cluster in der Flotte die Cluster aus, die Sie synchronisieren möchten.
    2. Klicken Sie auf Mit Flotteneinstellungen synchronisieren und dann im angezeigten Bestätigungsdialogfeld auf Bestätigen. Dies kann einige Minuten dauern.

Installation überprüfen

Nach der Installation und Konfiguration von Config Sync können Sie prüfen, ob die Installation erfolgreich abgeschlossen wurde.

Console

Gehen Sie folgendermaßen vor:

  1. Rufen Sie in der Google Cloud Console im Bereich Features die Seite Konfiguration auf.

    Zur Konfiguration

  2. Prüfen Sie auf dem Tab Pakete in der Clustertabelle die Spalte Synchronisierungsstatus. Eine erfolgreiche Installation von Config Sync hat den Status Installiert. Eine erfolgreich konfigurierte „Source of Truth“ hat den Status Synchronisiert.

gcloud

Führen Sie dazu diesen Befehl aus:

gcloud beta container fleet config-management status \
    --project=PROJECT_ID

Ersetzen Sie PROJECT_ID durch die ID Ihres Projekts.

Eine erfolgreiche Installation hat den Status SYNCED. Wenn nach Ausführen des vorherigen Befehls ein Fehler auftritt, prüfen Sie, ob Sie das git-creds-Secret erstellt haben. Wenn Sie das Secret erstellt haben, führen Sie den folgenden Befehl noch einmal aus:

gcloud beta container fleet config-management apply

Sie können auch den Befehl nomos status verwenden, um zu prüfen, ob Config Sync erfolgreich installiert wurde. Eine gültige Installation ohne Probleme hat den Status PENDING oder SYNCED. Eine ungültige oder unvollständige Installation hat den Status NOT INSTALLED oder NOT CONFIGURED. Die Ausgabe enthält auch alle gemeldeten Fehler.

Config Sync aktualisieren

Lesen Sie vor dem Upgrade von Policy Controller, Config Sync und Config Controller die Versionshinweise. Dort finden Sie Einzelheiten zu den Änderungen zwischen den Versionen.

Führen Sie die folgenden Schritte aus, um ein Upgrade von Config Sync durchzuführen:

Console

  1. Rufen Sie in der Google Cloud Console im Bereich Features die Seite Konfiguration auf.

    Zur Konfiguration

  2. Wählen Sie auf dem Tab Einstellungen neben dem Cluster, dessen Version Sie aktualisieren möchten, das Kontextmenü und dann Konfiguration bearbeiten aus.
  3. Wählen Sie in der Drop-down-Liste Version die Version aus, auf die Sie ein Upgrade durchführen möchten.
  4. Klicken Sie auf Config Sync aktualisieren.

gcloud

Führen Sie dazu diesen Befehl aus:

gcloud beta container fleet config-management upgrade \
    --version=VERSION \
    --membership=MEMBERSHIP_NAME

Ersetzen Sie Folgendes:

  • VERSION: Version, auf die Sie ein Upgrade ausführen möchten.
  • MEMBERSHIP_NAME: Name der Mitgliedschaft, den Sie bei der Registrierung Ihres Clusters ausgewählt haben. Sie können den Namen der Mitgliedschaft ermitteln, indem Sie gcloud container fleet memberships list ausführen.

Config Management-Version prüfen

Wenn Sie vor dem Upgrade prüfen möchten, welche Config Sync-Version auf Ihren Clustern installiert ist, führen Sie den folgenden Befehl aus:

gcloud beta container fleet config-management version

Weitere Informationen zu diesem Befehl finden Sie in der Referenzdokumentation.

Rollenbasierte Zugriffssteuerung und Berechtigungen

Policy Controller, Config Sync und Config Controller umfassen Arbeitslasten mit umfassenden Berechtigungen. In der folgenden Tabelle sind die Berechtigungen für diese Arbeitslasten aufgeführt:

Komponente Namespace Dienstkonto Berechtigungen Beschreibung
ConfigManagement-Operator config-management-system config-management-operator Clusteradministrator Der ConfigManagement Operator installiert die anderen Komponenten in dieser Tabelle. Für einige dieser Komponenten sind Clusteradministratorberechtigungen erforderlich, sodass der ConfigManagement Operator diese Berechtigungen ebenfalls erfordert.
Config Sync config-management-system Erforderliche Berechtigungen finden Sie unter Config Sync-Berechtigungen.

Ressourcenanforderungen

Im folgenden Abschnitt sind die Ressourcenanfragen für Config Sync aufgeführt.

In der folgenden Tabelle sind die Kubernetes-Ressourcenanforderungen für Config Sync-Komponenten aufgeführt. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Ressourcen für Container verwalten.

Nicht alle aufgeführten Komponenten wurden erstellt. Die folgenden Bedingungen führen dazu, dass jede Komponente geplant wird:

  • config-management-operator ist installiert, wenn Config Sync aktiviert ist.
  • reconciler-manager ist installiert, wenn Config Sync aktiviert ist.
  • admission-webhook ist installiert, wenn der Driftschutz aktiviert ist.
  • Für jede RootSync- und RepoSync-Datei wird jeweils ein reconciler installiert.
  • otel-collector ist installiert, wenn Config Sync aktiviert ist.

1.17

Bereitstellungsname CPU-Anfrage (m) pro Replikat Speicheranfrage (Mi) pro Replikat
config-management-operator 100 100
resource-group-controller-manager 110 300
admission-webhook1 10 100
otel-collector 200 400
reconciler-manager 20 150
reconciler (einer pro RootSync und RepoSync) Weitere Informationen finden Sie unter Deployment des Abgleichs.

1 Der Zulassungs-Webhook hat zwei Replikate. Wenn Sie also den Zulassungs-Webhook verwenden, müssen Sie bei der Berechnung der gesamten Ressourcenanfragen den Wert verdoppeln. Der Zulassungs-Webhook ist standardmäßig deaktiviert.

1.16

Bereitstellungsname CPU-Anfrage (m) pro Replikat Speicheranfrage (Mi) pro Replikat
config-management-operator 100 100
resource-group-controller-manager 110 300
admission-webhook1 10 100
otel-collector 200 400
reconciler-manager 20 150
reconciler (einer pro RootSync und RepoSync) Weitere Informationen finden Sie unter Deployment des Abgleichs.

1 Der Zulassungs-Webhook hat zwei Replikate. Wenn Sie also den Zulassungs-Webhook verwenden, müssen Sie bei der Berechnung der gesamten Ressourcenanfragen den Wert verdoppeln. Der Zulassungs-Webhook ist standardmäßig deaktiviert.

1.15

Bereitstellungsname CPU-Anfrage (m) pro Replikat Speicheranfrage (Mi) pro Replikat
config-management-operator 100 100
resource-group-controller-manager 110 300
admission-webhook1 10 100
otel-collector 200 400
reconciler-manager 20 150
reconciler (einer pro RootSync und RepoSync) Weitere Informationen finden Sie unter Deployment des Abgleichs.

1 Der Zulassungs-Webhook hat zwei Replikate. Wenn Sie also den Zulassungs-Webhook verwenden, müssen Sie bei der Berechnung der gesamten Ressourcenanfragen den Wert verdoppeln. Der Zulassungs-Webhook ist standardmäßig deaktiviert.

Abgleichsbereitstellung

Config Sync erstellt für jede RootSync- und RepoSync-Bereitstellung eine unabhängige Abgleichsbereitstellung, um die Synchronisierung durchzuführen. Dies verbessert die Zuverlässigkeit durch die Reduzierung von Single Points of Failure und ermöglicht, dass einzelne Abgleiche unabhängig skaliert werden können.

Die Abgleichsbereitstellung besteht aus mehreren Containern:

Container name Beschreibung Bedingung
reconciler übernimmt Synchronisierung und Driftkorrektur immer aktiviert
otel-agent sendet Messwerte an den Otel-Collector immer aktiviert
hydration-controller (optional) Kustomize-Rendering verarbeitet aktiviert, wenn die Quelle eine kustomize.yaml-Datei enthält
git-sync übernimmt den Git-Quellabruf aktiviert, wenn spec.sourceType den Wert git hat
gcenode-askpass-sidecar (optional) wird für die Git-Authentifizierung mit dem GKE-Metadatendienst verwendet aktiviert, wenn spec.sourceType den Wert git hat und spec.git.auth den Wert gcenode oder gcpserviceaccount hat
helm-sync übernimmt den Abruf der Helm-Quelle aktiviert, wenn spec.sourceType den Wert helm hat
oci-sync übernimmt den Abruf von OCI-Quellen aktiviert, wenn spec.sourceType den Wert oci hat

In Config Sync Version 1.17.0 und höher unterscheiden sich die Standardressourcenanfragen für Abgleicher für Standard- und Autopilot-Cluster. Bei allen anderen Clustertypen werden die Standardeinstellungen verwendet.

Standardcluster

1.17

Container name CPU-Anfrage (m) Speicheranfrage (Mi)
reconciler 50 200
otel-agent 10 100
hydration-controller (optional) 10 100
git-sync 10 16
gcenode-askpass-sidecar (optional) 10 20
helm-sync 75 128
oci-sync 25 32

1.16

Container name CPU-Anfrage (m) Speicheranfrage (Mi)
reconciler 50 200
otel-agent 10 100
hydration-controller (optional) 10 100
git-sync 10 200
gcenode-askpass-sidecar (optional) 10 20
helm-sync 50 256
oci-sync 10 200

1.15

Container name CPU-Anfrage (m) Speicheranfrage (Mi)
reconciler 50 200
otel-agent 10 100
hydration-controller (optional) 10 100
git-sync 10 200
gcenode-askpass-sidecar (optional) 10 20
helm-sync 50 256
oci-sync 10 200

Autopilot-Cluster

1.17

Container name CPU-Anfrage und -Limit (m) Arbeitsspeicheranforderung und Limit (Mi)
reconciler 700 512
otel-agent 10 64
hydration-controller (optional) 200 256
git-sync 20 32
gcenode-askpass-sidecar (optional) 50 64
helm-sync 150 256
oci-sync 50 64

1.16

In Config Sync-Versionen vor 1.17.0 sind die Ressourcenanfragen für Standard und Autopilot identisch.

1.15

In Config Sync-Versionen vor 1.17.0 sind die Ressourcenanfragen für Standard und Autopilot identisch.

Informationen zum Überschreiben der standardmäßigen Ressourcenanfragen und -limits finden Sie unter Ressourcenüberschreibungen.

Gebündelte Helm- und Kustomize-Versionen

Config Sync nutzt die ausführbaren Dateien von Helm und Kustomize, um die Konfigurationen im Hintergrund zu rendern. Die folgende Tabelle enthält eine Liste der Config Sync-Versionen, die die Renderingfunktion zusammen mit den gebündelten Helm- und Kustomize-Versionen unterstützen.

Config Sync-Versionen Helm-Version Kustomize-Version
1.16.0 und höher v3.11.3 v5.1.1
1.15.0 bis 1.15.3 v3.11.3 v5.0.1
1.11.0 bis 1.14.3 v3.6.3 v4.5.2

Informationen zum Rendern von Helm über Kustomize finden Sie unter Kubernetes mit Kustomize konfigurieren. Informationen zur Verwendung der Helm API finden Sie unter Helm-Diagramme aus Artifact Registry synchronisieren.

Nächste Schritte