Config Sync installieren

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:

   • Cloud Source Repositories.
   • Bitbucket
   • GitHub Wir empfehlen, separate Bereitstellungsschlüssel zu erstellen, um Lesezugriff auf ein einzelnes GitHub-Repository zu gewähren.
   • GitLab

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 Überprüfung der bekannten Hosts mit SSH-Authentifizierung konfigurieren möchten, können Sie den Schlüssel für bekannte Hosts dem Feld data.known_hosts im geheimen Schlüssel git_creds hinzufügen. Wenn Sie die Prüfung von known_hosts deaktivieren möchten, können Sie dafür das Feld known_hosts aus dem Secret entfernen. Führen Sie folgenden Befehl aus, um den Schlüssel bekannter Hosts hinzuzufügen:

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

   Fügen Sie dann unter data den Eintrag für bekannte 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.

   • GitHub: Erstellen Sie ein PAT. Gewähren Sie dem Token den Bereich repo, damit es Daten aus privaten Repositories lesen kann. Da Sie ein PAT an ein GitHub-Konto binden, sollten Sie auch einen Computernutzer erstellen und das PAT an den Computernutzer binden.
   • GitLab: Erstellen Sie ein PAT oder erstellen Sie ein Deployment-Token.
   • Bitbucket: Erstellen Sie ein App-Passwort.

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
   

   Ersetzen Sie Folgendes:

   • 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 Federation for GKE oder Workload Identity Federation for GKE für Flotten verwendet, können Sie Config Sync mithilfe eines Google-Dienstkontos Zugriff auf ein Repository in dem Projekt gewähren, in dem sich Ihr verwalteter Cluster befindet.

1. Wenn Sie kein Dienstkonto haben, erstellen Sie eins.

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 gewähren.

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

     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 Sie Dienstkonten für jedes Repository in Ihrem Projekt unterschiedliche Zugriffsebenen zuweisen möchten.

     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 Federation for GKE 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. Nach dem Konfigurieren von Config Sync erstellen Sie 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 Federation for GKE-Pool. Wenn Sie Ihrem Kubernetes-Dienstkonto in einem Cluster die IAM-Richtlinie hinzufügen, erhält das Kubernetes-Dienstkonto aus demselben Namespace in anderen Clustern in derselben Flotte aufgrund des Konzepts der Gleichheit für eine Flotte ebenfalls dieselbe IAM-Richtlinie.

   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: die Projekt-ID der Organisation.
• FLEET_HOST_PROJECT_ID: Wenn Sie GKE Workload Identity Federation for GKE verwenden, entspricht dies PROJECT_ID. Wenn Sie Workload Identity Federation for GKE für Flotten verwenden, ist dies die Projekt-ID der Flotte, für die Ihr Cluster registriert ist.
• GSA_NAME: das benutzerdefinierte Google-Dienstkonto, das Sie für die Verbindung mit Artifact Registry verwenden möchten. Dieses Dienstkonto muss die IAM-Rolle Artifact Registry-Leser (roles/artifactregistry.reader) haben.
• KSA_NAME: das Kubernetes-Dienstkonto für den Abgleich.
  • Verwenden Sie für Stamm-Repositories root-reconciler, wenn der RootSync-Name root-sync lautet. Verwenden Sie andernfalls root-reconciler-ROOT_SYNC_NAME. Wenn Sie Config Sync mit der Google Cloud Console oder der Google Cloud CLI installieren, erstellt Config Sync automatisch ein RootSync-Objekt namens root-sync.
• REPOSITORY: Name des Repositorys.
• POLICY_FILE ist die JSON- oder YAML-Datei mit der Identity and Access Management-Richtlinie.

Standardmäßiges Compute Engine-Dienstkonto

Wenn sich Ihr Repository in Cloud Source Repositories befindet und Ihr Cluster GKE mit deaktivierter Workload Identity Federation for GKE verwendet, 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 mithilfe des 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 den Rollen und Berechtigungen für Cloud Source Repositories finden Sie unter Berechtigungen zum Ansehen von Repositories gewähren.

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.

GitHub App

Wenn sich Ihr Repository in GitHub befindet, können Sie githubapp als Authentifizierungstyp verwenden.

So verwenden Sie eine GitHub-App:

1. Folgen Sie der Anleitung auf GitHub, um eine GitHub-App bereitzustellen und ihr Lesezugriff auf Ihr Repository zu gewähren.

2. Fügen Sie die GitHub App-Konfiguration einem neuen Secret im Cluster hinzu:

   Client-ID verwenden

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-client-id=CLIENT_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • Ersetzen Sie CLIENT_ID durch die Client-ID für die GitHub App.
   • Ersetzen Sie INSTALLATION_ID durch die Installations-ID der GitHub App.
   • Ersetzen Sie /path/to/GITHUB_PRIVATE_KEY durch den Namen der Datei, die den privaten Schlüssel enthält.
   • Ersetzen Sie BASE_URL durch die Basis-URL für den GitHub API-Endpunkt. Das ist nur erforderlich, wenn das Repository nicht unter www.github.com gehostet wird. Andernfalls kann das Argument weggelassen werden und es wird standardmäßig https://api.github.com/ verwendet.

   Anwendungs-ID verwenden

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-application-id=APPLICATION_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • Ersetzen Sie APPLICATION_ID durch die Anwendungs-ID der GitHub App.
   • Ersetzen Sie INSTALLATION_ID durch die Installations-ID der GitHub App.
   • Ersetzen Sie /path/to/GITHUB_PRIVATE_KEY durch den Namen der Datei, die den privaten Schlüssel enthält.
   • Ersetzen Sie BASE_URL durch die Basis-URL für den GitHub API-Endpunkt. Das ist nur erforderlich, wenn das Repository nicht unter www.github.com gehostet wird. Andernfalls kann das Argument weggelassen werden und es wird standardmäßig https://api.github.com/ verwendet.

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

4. Verwenden Sie den Authentifizierungstyp githubapp, wenn Sie Config Sync konfigurieren und die URL für Ihr Git-Repository hinzufügen.

Kubernetes-Dienstkonto

Wenn Sie Ihr OCI-Image in Artifact Registry speichern und Ihr Cluster GKE Workload Identity Federation for GKE oder Workload Identity Federation for GKE für Flotten verwendet, können Sie k8sserviceaccount als Authentifizierungstyp in Version 1.17.2 und höher verwenden. Diese Option wird aufgrund der einfacheren Konfiguration anstelle von gcpserviceaccount empfohlen.

1. Weisen Sie dem Kubernetes-Dienstkonto mit dem Workload Identity Federation for GKE-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 für alle Repositories im Projekt dieselben Berechtigungen gelten sollen.

     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 Sie Dienstkonten für jedes Repository in Ihrem Projekt unterschiedliche Zugriffsebenen zuweisen möchten.

     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: die Projekt-ID der Organisation.
   • FLEET_HOST_PROJECT_ID: Wenn Sie GKE Workload Identity Federation for GKE verwenden, entspricht dies PROJECT_ID. Wenn Sie Workload Identity Federation for GKE für Flotten verwenden, ist dies die Projekt-ID der Flotte, für die Ihr Cluster registriert ist.
   • KSA_NAME: das Kubernetes-Dienstkonto für den Abgleich.
     • Verwenden Sie für Stamm-Repositories root-reconciler, wenn der RootSync-Name root-sync lautet. Verwenden Sie andernfalls root-reconciler-ROOT_SYNC_NAME. Wenn Sie Config Sync mit der Google Cloud Console oder der Google Cloud CLI installieren, erstellt Config Sync automatisch ein RootSync-Objekt namens root-sync.
   • REPOSITORY: die ID des Repositorys.
   • LOCATION: der regionale oder multiregionale Speicherort für das Repository.

Google-Dienstkonto

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

1. Wenn Sie kein Dienstkonto haben, erstellen Sie eins.

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 für alle Repositories im Projekt dieselben Berechtigungen gelten sollen.

     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 Sie Dienstkonten für jedes Repository in Ihrem Projekt unterschiedliche Zugriffsebenen zuweisen möchten.

     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: die Projekt-ID der Organisation.
• FLEET_HOST_PROJECT_ID: Wenn Sie GKE Workload Identity Federation for GKE verwenden, entspricht dies PROJECT_ID. Wenn Sie Workload Identity Federation for GKE für Flotten verwenden, ist dies die Projekt-ID der Flotte, für die Ihr Cluster registriert ist.
• GSA_NAME: das benutzerdefinierte Google-Dienstkonto, das Sie für die Verbindung mit Artifact Registry verwenden möchten. Dieses Dienstkonto muss die IAM-Rolle Artifact Registry-Leser (roles/artifactregistry.reader) haben.
• KSA_NAME: das Kubernetes-Dienstkonto für den Abgleich.
  • Verwenden Sie für Stamm-Repositories root-reconciler, wenn der RootSync-Name root-sync lautet. Verwenden Sie andernfalls root-reconciler-ROOT_SYNC_NAME. Wenn Sie Config Sync mit der Google Cloud Console oder der Google Cloud CLI installieren, erstellt Config Sync automatisch ein RootSync-Objekt namens root-sync.
• REPOSITORY: die ID des Repositorys.
• LOCATION: der regionale oder multiregionale Speicherort für das Repository.

Standardmäßiges Compute Engine-Dienstkonto

Wenn Sie Ihr Helm-Diagramm in Artifact Registry speichern und Ihr Cluster GKE mit deaktivierter Workload Identity Federation for GKE verwendet, können Sie gcenode als Authentifizierungstyp verwenden. Config Sync verwendet das Compute Engine-Standarddienstkonto. Sie müssen Ihrem Compute Engine-Standarddienstkonto-Leser entweder Zugriff auf Artifact Registry gewähren.

1. Erteilen Sie dem Compute Engine-Dienstkonto die Leseberechtigung für Artifact Registry mit dem folgenden Befehl:

   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.

Token

Erstellen Sie ein Secret mit einem Helm-Repository-Nutzernamen und einem -Passwort:

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

Ersetzen Sie Folgendes:

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

Wenn Sie Config Sync 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 Federation for GKE oder Workload Identity Federation for GKE für Flotten verwendet, können Sie k8sserviceaccount als Authentifizierungstyp in Version 1.17.2 und höher verwenden. Diese Option wird aufgrund der einfacheren Konfiguration anstelle von gcpserviceaccount empfohlen.

1. Weisen Sie dem Kubernetes-Dienstkonto mit dem Workload Identity Federation for GKE-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 für alle Repositories im Projekt dieselben Berechtigungen gelten sollen.

     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 Sie Dienstkonten für jedes Repository in Ihrem Projekt unterschiedliche Zugriffsebenen zuweisen möchten.

     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: die Projekt-ID der Organisation.
   • FLEET_HOST_PROJECT_ID: Wenn Sie GKE Workload Identity Federation for GKE verwenden, entspricht dies PROJECT_ID. Wenn Sie Workload Identity Federation for GKE für Flotten verwenden, ist dies die Projekt-ID der Flotte, für die Ihr Cluster registriert ist.
   • KSA_NAME: das Kubernetes-Dienstkonto für den Abgleich.
     • Verwenden Sie für Stamm-Repositories root-reconciler, wenn der RootSync-Name root-sync lautet. Verwenden Sie andernfalls root-reconciler-ROOT_SYNC_NAME.
   • REPOSITORY: die ID des Repositorys.
   • LOCATION: der regionale oder multiregionale Speicherort für das Repository.

Google-Dienstkonto

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

1. Wenn Sie kein Dienstkonto haben, erstellen Sie eins.

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 für alle Repositories im Projekt dieselben Berechtigungen gelten sollen.

     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 Sie Dienstkonten für jedes Repository in Ihrem Projekt unterschiedliche Zugriffsebenen zuweisen möchten.

     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: die Projekt-ID der Organisation.
• FLEET_HOST_PROJECT_ID: Wenn Sie GKE Workload Identity Federation for GKE verwenden, entspricht dies PROJECT_ID. Wenn Sie Workload Identity Federation for GKE für Flotten verwenden, ist dies die Projekt-ID der Flotte, für die Ihr Cluster registriert ist.
• GSA_NAME: das benutzerdefinierte Google-Dienstkonto, das Sie für die Verbindung mit Artifact Registry verwenden möchten. Dieses Dienstkonto muss die IAM-Rolle Artifact Registry-Leser (roles/artifactregistry.reader) haben.
• KSA_NAME: das Kubernetes-Dienstkonto für den Abgleich.
  • Verwenden Sie für Stamm-Repositories root-reconciler, wenn der RootSync-Name root-sync lautet. Verwenden Sie andernfalls root-reconciler-ROOT_SYNC_NAME.
• REPOSITORY: die ID des Repositorys.
• LOCATION: der regionale oder multiregionale Speicherort für das Repository.

Standardmäßiges Compute Engine-Dienstkonto

Wenn Sie Ihr Helm-Diagramm in Artifact Registry speichern und Ihr Cluster GKE mit deaktivierter Workload Identity Federation for GKE verwendet, können Sie gcenode als Authentifizierungstyp verwenden. Config Sync verwendet das Compute Engine-Standarddienstkonto. Sie müssen Ihrem Compute Engine-Standarddienstkonto-Leser entweder Zugriff auf Artifact Registry gewähren. Möglicherweise müssen Sie den Zugriffsbereich storage-ro gewähren, um Lesezugriff auf Images zu ermöglichen.

1. Erteilen Sie dem Compute Engine-Dienstkonto die 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.

Console

Config Sync installieren

Damit Config Sync installiert werden kann, müssen alle Cluster bei einer Flotte registriert sein. Wenn Sie Config Sync in der Google Cloud Console installieren und einzelne Cluster auswählen, werden diese Cluster automatisch in Ihrer Flotte registriert.

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

   Zu „Config“

2. Klicken Sie auf add Config Sync installieren.
3. Wählen Sie Automatische Upgrades (Vorschau) aus, damit Config Sync die Versionen automatisch aktualisieren kann, oder wählen Sie Manuelle Upgrades aus, um die Config Sync‑Version selbst zu verwalten. Weitere Informationen zur Funktionsweise von automatischen Upgrades finden Sie unter Config Sync upgraden.
4. Wählen Sie unter Installationsoptionen eine der folgenden Optionen aus:
   • Config Sync in der gesamten Flotte installieren (empfohlen): Config Sync wird in allen Clustern in der Flotte installiert.
   • Config Sync in einzelnen Clustern installieren: Alle ausgewählten Cluster werden automatisch in einer Flotte registriert. Config Sync wird in allen Clustern in der Flotte installiert.
5. Wenn Sie Config Sync in einzelnen Clustern installieren, wählen Sie in der Tabelle Verfügbare Cluster die Cluster aus, in denen Sie Config Sync installieren möchten.
6. Klicken Sie auf Config Sync installieren. Nach einigen Minuten sollte auf dem Tab Einstellungen in der Spalte Status für die Cluster in Ihrer Flotte Aktiviert angezeigt werden.

Paket bereitstellen

Nachdem Sie Ihre Cluster für eine Flotte registriert und Config Sync installiert haben, können Sie Config Sync so konfigurieren, dass ein Paket in einem Cluster aus einer Source of Truth bereitgestellt wird. Sie können ein Paket in mehreren Clustern oder verschiedene Pakete in verschiedenen Clustern bereitstellen. Sie können ein Paket nach der Bereitstellung bearbeiten, mit Ausnahme einiger Einstellungen wie Paketname und Synchronisierungstyp. Weitere Informationen finden Sie unter Pakete verwalten.

Führen Sie folgende 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 die 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 In OCI gehostete Paket als Quelltyp aus und klicken Sie dann auf Weiter.

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

6. Wählen Sie im Feld Synchronisierungstyp entweder Clusterbezogene Synchronisierung oder Namespace-bezogene Synchronisierung als Synchronisierungstyp aus.

   Die clusterbezogene Synchronisierung erstellt ein RootSync-Objekt und die Namespace-bezogene Synchronisierung ein RepoSync-Objekt. Weitere Informationen zu diesen Objekten finden Sie unter Config Sync-Architektur.

7. Geben Sie im Abschnitt Quelle Folgendes ein:

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

     1. Geben Sie die URL des Git-Repositorys, das Sie als „Source of Truth“ verwenden, als Repository-URL ein.
     2. Optional: Aktualisieren Sie das Feld Überarbeitung, um zu prüfen, ob Sie nicht die Standardeinstellung HEAD verwenden.
     3. Optional: Aktualisieren Sie das Feld Pfad, wenn Sie nicht aus dem Root-Repository synchronisieren möchten.
     4. 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 die URL des OCI-Images, das Sie als „Source of Truth“ verwenden, als Image ein.
     2. Geben Sie den Pfad des Verzeichnisses relativ zum Stammverzeichnis als Verzeichnis ein, von dem aus synchronisiert werden soll.

8. (Optional): Maximieren Sie den Abschnitt Erweiterte Einstellungen, um Folgendes abzuschließen:

   1. Wählen Sie einen Authentifizierungstyp aus. Config Sync benötigt Lesezugriff auf Ihre „Source of Truth“, um die Konfigurationsdateien in der Quelle zu lesen und auf Ihre Cluster anzuwenden. Sofern nicht Ihre Quelle (z. B. ein öffentliches Repository) keine Authentifizierung erfordert, müssen Sie dafür sorgen, dass Sie Config Sync Lesezugriff auf Ihr Git-Repository, OCI-Image oder Helm-Diagramm (nur gcloud CLI) gewähren. Wählen Sie den Authentifizierungstyp aus, den Sie bei der Installation von Config Sync konfiguriert haben:

      • Keine: Keine Authentifizierung verwenden.
      • SSH: Mit einem SSH-Schlüsselpaar authentifizieren.
      • Cookiefile: Mit einem cookiefile authentifizieren.
      • Token: Mit einem Zugriffstoken oder Passwort authentifizieren.
      • 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 Federation for GKE 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 Anzahl von Sekunden ein, um die Synchronisierungswartezeit festzulegen, die bestimmt, wie lange Config Sync zwischen den Versuchen zum Abruf aus der „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 Unstrukturiert wird in den meisten Fällen empfohlen, da Sie damit Ihre "Source of Truth" wie gewünscht organisieren können.

9. Klicken Sie auf Paket bereitstellen.

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

gcloud

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

1. Aktivieren Sie die Flottenfunktion ConfigManagement:

   gcloud beta container fleet config-management enable
   

2. 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

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

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

   # apply-spec.yaml
   
   applySpecVersion: 1
   spec:
     # upgrades: UPGRADE_SETTING
     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:

   • (Vorabversion) UPGRADE_SETTING: Kommentieren Sie das Feld aufheben und setzen Sie es auf auto, um Config Sync für automatische Upgrades zu konfigurieren. Legen Sie manual fest, um Config Sync manuell zu aktualisieren. Der Standardwert ist manual. Dieses Flag wird nur für GKE-Cluster in Google Cloud unterstützt. Wenn Sie dieses Feld verwenden möchten, müssen Sie möglicherweise die gcloud CLI aktualisieren, indem Sie gcloud components update ausführen.

   • SOURCE_TYPE: Fügen Sie git hinzu, um aus einem Git-Repository zu synchronisieren, oci, um aus einem OCI-Image zu synchronisieren, oder helm, um aus einem Helm-Diagramm zu synchronisieren. Wenn kein Wert angegeben ist, lautet der Standardwert git.

   • 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-Revision (Tag oder Hash) oder der Name des Zweigs, von dem aus synchronisiert werden soll. Wenn Sie einen Hash verwenden, muss es sich um einen vollständigen Hash (nicht um eine abgekürzte Form) handeln.

   • 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 Federation for GKE nicht in Ihrem Cluster aktiviert ist.
     • githubapp: Über eine GitHub-App bei einem GitHub-Repository authentifizieren.

     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 Federation for GKE in Ihrem Cluster nicht 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 Federation for GKE in Ihrem Cluster nicht 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 (GSA), das für den Export von Config Sync-Messwerten zu Cloud Monitoring verwendet wird. Das GSA sollte die IAM-Rolle „Monitoring-Messwert-Autor“ (roles/monitoring.metricWriter) haben. Das Kubernetes-Dienstkonto default im Namespace config-management-monitoring sollte an das GSA 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.

3. 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
   

   Ersetzen Sie Folgendes:

   • MEMBERSHIP_NAME: Name der Flottenmitgliedschaft, den Sie bei der Registrierung Ihres Clusters ausgewählt haben (kann mit gcloud container fleet memberships list ermittelt werden).
   • CONFIG_YAML_PATH: Pfad zur Datei apply-spec.yaml
   • PROJECT_ID: Ihre Projekt-ID.

Terraform

Wenden Sie für jeden Cluster, für den Sie Config Sync konfigurieren möchten, einen google_gkehub_feature_membership-Ressourcenblock mit einem configmanagement- und einem config_sync-Block an:

resource "google_container_cluster" "cluster" {
 name = "EXISTING_CLUSTER_NAME"
 location = "EXISTING_CLUSTER_LOCATION"
}

resource "google_gke_hub_membership" "membership" {
 membership_id = "MEMBERSHIP_ID"
 endpoint {
   gke_cluster {
     resource_link = "//container.googleapis.com/${google_container_cluster.cluster.id}"
   }
 }
}

resource "google_gke_hub_feature" "feature" {
 name = "configmanagement"
 location = "global"
}

resource "google_gke_hub_feature_membership" "feature_member" {
 location = "global"
 feature = google_gke_hub_feature.feature.name
 membership = google_gke_hub_membership.membership.membership_id
 configmanagement {
   version = "VERSION"
   config_sync {
     # The field `enabled` was introduced in Terraform version 5.41.0, and
     # needs to be set to `true` explicitly to install Config Sync.
     enabled = true
     git {
       sync_repo = "REPO"
       sync_branch = "BRANCH"
       policy_dir = "DIRECTORY"
       secret_type = "SECRET"
     }
   }
 }
}

resource "google_container_cluster" "cluster" {
 name = "EXISTING_CLUSTER_NAME"
 location = "EXISTING_CLUSTER_LOCATION"
}

resource "google_gke_hub_membership" "membership" {
 membership_id = "MEMBERSHIP_ID"
 endpoint {
   gke_cluster {
     resource_link = "//container.googleapis.com/${google_container_cluster.cluster.id}"
   }
 }
}

resource "google_gke_hub_feature" "feature" {
 name = "configmanagement"
 location = "global"
}

resource "google_gke_hub_feature_membership" "feature_member" {
 location = "global"
 feature = google_gke_hub_feature.feature.name
 membership = google_gke_hub_membership.membership.membership_id
 configmanagement {
   version = "VERSION"
   config_sync {
     # The field `enabled` was introduced in Terraform version 5.41.0, and
     # needs to be set to `true` explicitly to install Config Sync.
     enabled = true
     oci {
       sync_repo = "REPO"
       policy_dir = "DIRECTORY"
       secret_type = "SECRET"
     }
   }
 }
}

Wiederholen Sie diesen Vorgang für jeden Cluster, den Sie synchronisieren möchten.

gcloud

Führen Sie den Befehl enable für die Funktion aus und übergeben Sie die apply-spec.yaml-Konfigurationsdatei, die Sie beim Konfigurieren von Config Sync in einem einzelnen Cluster erstellt haben:

gcloud beta container fleet config-management enable \
    --fleet-default-member-config=apply-spec.yaml

Mit diesem Befehl können Sie die Standardeinstellungen Ihrer Flotte jederzeit aktualisieren. Wenn Sie die Standardeinstellungen für Ihre Flotte aktualisieren, müssen Sie Ihre vorhandenen Cluster wieder mit den Standardeinstellungen synchronisieren.

Console

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 in der Flotte erstellen, übernehmen diese Einstellungen.

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

5. Wählen Sie Automatische Upgrades (Vorschau) aus, um Config Sync-Versionen automatisch zu aktualisieren, oder wählen Sie Manuelle Upgrades aus, um die Config Sync-Version selbst zu verwalten. Weitere Informationen zur Funktionsweise von automatischen Upgrades finden Sie unter Config Sync upgraden.

6. Wenn Sie Manuelle Upgrades ausgewählt haben, wählen Sie in der Liste Version die Config Sync-Version aus, die Sie verwenden möchten.

7. Klicken Sie auf Änderungen speichern.

8. Klicken Sie auf Konfigurieren.

9. Klicken Sie im Bestätigungsdialogfeld Flotteneinstellungen konfigurieren auf Bestätigen. Wenn Sie Config Sync noch nicht aktiviert haben, wird durch Klicken auf Bestätigen auch die anthosconfigmanagement.googleapis.com API aktiviert.

Terraform

1. Erstellen Sie ein Verzeichnis für die Terraform-Dateien der Standardkonfiguration der Flotte. Fügen Sie diesem Verzeichnis eine main.tf-Datei mit der folgenden Ressource hinzu, die die Einstellungen von Config Sync konfiguriert:

   git

   terraform {
     required_providers {
       google = {
         source = "hashicorp/google"
         version = ">=5.16.0"
         }
       }
     }
   
   provider "google" {
     project = "PROJECT_ID"
   }
   
   resource "google_gke_hub_feature" "feature" {
     name = "configmanagement"
     location = "global"
     provider = google
     fleet_default_member_config {
       configmanagement {
       version = "VERSION"
       config_sync {
       source_format = "unstructured"
         git {
           sync_repo = "REPO"
           sync_branch = "BRANCH"
           policy_dir = "DIRECTORY"
           secret_type = "SECRET"
         }
       }
       }
     }
   }
   

   Ersetzen Sie Folgendes:

   • PROJECT_ID: die Projekt-ID des Hostprojekts der Flotte.
   • VERSION (optional) ist die Config Sync-Versionsnummer. Wenn Sie dieses Feld leer lassen, wird die Standardeinstellung verwendet, nämlich die neueste Version.
   • REPO ist die URL zum Repository mit Ihren Konfigurationsdateien.
   • BRANCH ist der Repository-Zweig, z. B. main.
   • DIRECTORY ist der Pfad im Git-Repository, der die oberste Ebene des Repositorys darstellt, das Sie synchronisieren möchten.
   • SECRET ist der Secret-Authentifizierungstyp.

   Eine vollständige Liste der im Config Sync-git-Block unterstützten Einstellungen finden Sie in der Terraform-Referenzdokumentation für GKE-Hub-Features.

   OCI

   terraform {
     required_providers {
       google = {
         source = "hashicorp/google"
         version = ">=5.16.0"
         }
       }
     }
   
   provider "google" {
     project = "PROJECT_ID"
   }
   
   resource "google_gke_hub_feature" "feature" {
     name = "configmanagement"
     location = "global"
     provider = google
     fleet_default_member_config {
       configmanagement {
       version = "VERSION"
       config_sync {
       source_format = "unstructured"
         oci {
           sync_repo = "REPO"
           policy_dir = "DIRECTORY"
           secret_type = "SECRET"
         }
       }
       }
     }
   }
   

   Ersetzen Sie Folgendes:

   • PROJECT_ID: die Projekt-ID des Hostprojekts der Flotte.
   • VERSION ist die Config Sync-Versionsnummer. Wenn Sie dieses Feld leer lassen, wird die Standardeinstellung verwendet, nämlich die neueste Version.
   • REPO ist die URL zum OCI-Image-Repository mit Konfigurationsdateien.
   • DIRECTORY ist der absolute Pfad des Verzeichnisses mit den Ressourcen, die Sie synchronisieren möchten. Lassen Sie das Feld leer, wenn Sie das Stammverzeichnis verwenden möchten.
   • SECRET ist der Secret-Authentifizierungstyp.

   Eine vollständige Liste der im Config Sync-oci-Block unterstützten Einstellungen finden Sie in der Terraform-Referenzdokumentation für GKE-Hub-Features.

2. Initialisieren Sie Terraform im von Ihnen erstellten Verzeichnis:

   terraform init
   

3. Prüfen Sie, ob die vorgeschlagenen Änderungen mit Terraform dem erwarteten Plan entsprechen:

   terraform plan
   

4. Erstellen Sie die Standardkonfigurationen für Flottenmitglieder:

   terraform apply
   

gcloud

1. Synchronisieren Sie eine vorhandene Mitgliedschaft mit der Standardkonfiguration der Flotte:

   gcloud beta container fleet config-management apply \
       --origin=FLEET \
       --membership=MEMBERSHIP_NAME
   

   Ersetzen Sie MEMBERSHIP_NAME durch den Namen der Flottenmitgliedschaft des Clusters, den Sie mit der Standardkonfiguration der Flotte synchronisieren möchten.

2. Prüfen Sie, ob Ihre Mitgliedschaftskonfigurationen mit den Standardeinstellungen der Flotte synchronisiert sind:

   gcloud beta container fleet config-management status
   

   Die Ausgabe dieses Befehls sollte für die Mitgliedschaft, die Sie synchronisiert haben, Yes für den Status Synced_to_Fleet_Default anzeigen.

Console

1. Zu Feature Manager:

   Feature Manager: Config Sync

2. Wählen Sie in der Clustertabelle die Cluster aus, die Sie mit den Flotteneinstellungen synchronisieren möchten.

3. Klicken Sie auf Mit Flotteneinstellungen synchronisieren.

Console

Gehen Sie folgendermaßen vor:

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

   Zu „Config“

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

gcloud

Führen Sie den folgenden 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. Ab Config Sync Version 1.18.0 zeigt die Ausgabe auch an, welche Version von Config Sync installiert ist, sowie die Upgrade-Einstellung von Config Sync.

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