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 mit Google Kubernetes Engine (GKE) Enterprise 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, müssen Sie Ihre Umgebung vorbereiten, dafür sorgen, dass die Clusteranforderungen erfüllt sind, und die richtigen Nutzerrollen zuweisen.

Lokale Umgebung vorbereiten

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

  1. Erstellen Sie eine „Source of Truth“ oder sorgen Sie dafür, dass Sie auf eine solche zugreifen können. Hier fügen Sie die Konfigurationen hinzu, mit denen Config Sync synchronisiert wird. Weitere Informationen zum Einrichten von Konfigurationen und einer „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. Wenn Sie die Google Cloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.

  3. Aktivieren Sie die GKE Enterprise API.

    GKE Enterprise API aktivieren

Clusteranforderungen

Erstellen Sie einen Cluster oder sorgen Sie dafür, dass Sie auf einen Cluster zugreifen können, der die folgenden Anforderungen erfüllt:

  • Der Cluster befindet sich auf einer von Google Kubernetes Engine (GKE) Enterprise unterstützten Plattform und Version.

  • Wenn Sie Autopilot-Cluster verwenden, passt Autopilot die Ressourcenanforderungen für Container gemäß den folgenden Regeln an:

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

    • passt die benutzerdefinierten Überschreibungslimits für Ressourcen an Anfragen an.
    • wendet Überschreibungen nur an, wenn eine oder mehrere Ressourcenanfragen vorhanden sind, die höher sind als die entsprechende in der Annotation deklarierte Ausgabe, oder eine oder mehrere Ressourcenanfragen, die niedriger sind als die entsprechende Eingabe in der Annotation.

  • (Optional) Für den Cluster ist Workload Identity 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. Für Autopilot-Cluster ist Workload Identity standardmäßig aktiviert.

  • Weisen Sie die richtigen Schreibberechtigungen für Messwerte zu, damit Config Sync Messwerte an Cloud Monitoring senden kann. Das ist erforderlich, wenn Sie automatische Upgrades verwenden möchten.

  • Wenn Sie die Config Sync-Version automatisch aktualisieren lassen möchten, muss Ihr GKE-Cluster in einer Release-Version registriert sein. Ein Cluster, der keine GKE-Release-Versionen verwendet, wird als Cluster mit der stabilen Release-Version behandelt.

  • 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, um Config Sync Zugriff auf Ihre „Source of Truth“ zu gewähren, müssen Sie den schreibgeschützten Bereich in Zugriffsbereiche für die Knoten im Cluster für Cloud Source Repositories einbinden.

    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.

  • Sie müssen Config Sync auf einem amd64-Knotenpool ausführen. Container-Images der Backend-Komponenten von Config Sync werden nur für die Maschinenarchitektur amd64 erstellt, verteilt und getestet. Wenn eine Config Sync-Komponente auf einem Arm-Knoten geplant ist, tritt der Fehler exec format auf und es kommt zum Absturz.

    Wenn in Ihrem Cluster Arm-Knoten vorhanden sind, fügen Sie Ihrem Cluster einen oder mehrere amd64-Knoten hinzu. Wenn Sie keinen GKE-Cluster verwenden, fügen Sie eine Markierung zu Ihren arm64-Knoten hinzu, damit auf den arm64-Knoten keine Pods ohne spezifische Toleranz geplant werden. GKE-Arm-Knoten haben bereits eine Standardmarkierung, sodass Sie diese nicht hinzufügen müssen.

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 Config Sync mit der Google Cloud CLI konfigurieren oder Cluster außerhalb von Google Cloud verwenden möchten, müssen Sie darauf achten, dass Ihre GKE-Cluster oder Cluster außerhalb von Google Cloud in einer Flotte registriert sind. Wenn Sie die Google Cloud Console verwenden möchten, können Sie GKE-Cluster bei der Konfiguration von Config Sync registrieren.

Config Sync installieren

In den folgenden Abschnitten gewähren Sie Config Sync Zugriff auf eine der folgenden „Sources of Truth“:

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 das Repository beispielsweise über eine Weboberfläche ohne Anmeldung aufrufen oder mit git clone einen Klon des Repositorys lokal erstellen können, ohne Anmeldedaten einzugeben oder gespeicherte Anmeldedaten zu verwenden, müssen Sie sich nicht authentifizieren. In diesem Fall brauchen Sie kein -Secret zu 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)
  • Cookiefile (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.

Um ein Repository in Cloud Source Repositories als Config Sync-Repository zu nutzen, 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 mit der Google Cloud Console konfigurieren, fügen Sie die URL dem Feld URL hinzu. 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) Um die Prüfung bekannter Hosts mit SSH-Authentifizierung zu konfigurieren, können Sie den Schlüssel der bekannten Hosts in das Feld data.known_hosts im Secret git_creds aufnehmen. 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 bekannter 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

    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 oder Flotten-Workload Identity 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 noch kein Dienstkonto haben, erstellen Sie ein Dienstkonto.

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

    • 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 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-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 verwenden, entspricht dies PROJECT_ID. Wenn Sie Flotten-Workload Identity verwenden, ist dies die Projekt-ID der Flotte, für die Ihr Cluster registriert ist.
  • GSA_NAME: das benutzerdefinierte Google-Dienstkonto, mit dem Sie eine Verbindung zu Artifact Registry herstellen 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 ist der 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 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 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 Rollen und Berechtigungen für Cloud Source Repositories finden Sie unter Berechtigungen zum Aufrufen 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 Ihr in Artifact Registry gespeichertes OCI-Image, damit es die im Image enthaltenen Konfigurationen lesen und auf Ihre Cluster anwenden kann.

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 Ihr OCI-Image in Artifact Registry speichern und Ihr Cluster GKE-Workload Identity oderWorkload Identity der Flotte verwendet, können Sie k8sserviceaccount als Authentifizierungstyp in Version 1.17.2 und höher nutzen. Diese Option wird aufgrund der einfacheren Konfiguration anstelle von 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 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 verwenden, entspricht dies PROJECT_ID. Wenn Sie Flotten-Workload Identity 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 oderWorkload Identity der Flotte verwendet, können Sie gcpserviceaccount als Authentifizierungstyp nutzen. 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 ein Dienstkonto.

  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 verwenden, entspricht dies PROJECT_ID. Wenn Sie Flotten-Workload Identity verwenden, ist dies die Projekt-ID der Flotte, für die Ihr Cluster registriert ist.
  • GSA_NAME: das benutzerdefinierte Google-Dienstkonto, mit dem Sie eine Verbindung zu Artifact Registry herstellen 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 ist, 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. Führen Sie den folgenden Befehl aus, um dem Compute Engine-Dienstkonto die Leseberechtigung für Artifact Registry zu erteilen:

    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 es die Helm-Diagramme in Ihrem Repository lesen und in Ihren Clustern installieren 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 Ihr Helm-Repository 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 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 Helm-Repository-Nutzernamen und -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 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 verwendet GKE-Workload Identity oder Workload Identity der Flotte, 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-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 verwenden, entspricht dies PROJECT_ID. Wenn Sie Flotten-Workload Identity 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 verwendet GKE-Workload Identity oder Workload Identity der Flotte können Sie gcpserviceaccount als Authentifizierungstyp auswählen. 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 ein Dienstkonto.

  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 verwenden, entspricht dies PROJECT_ID. Wenn Sie Flotten-Workload Identity verwenden, ist dies die Projekt-ID der Flotte, für die Ihr Cluster registriert ist.
  • GSA_NAME: das benutzerdefinierte Google-Dienstkonto, mit dem Sie eine Verbindung zu Artifact Registry herstellen 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 ist, 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.

Config Sync konfigurieren

In diesem Abschnitt konfigurieren Sie die Einstellungen für Ihr Stamm-Repository. Wenn Sie eine Synchronisierung mit einem Git-Repository ausführen, können Sie die Google Cloud Console für eine schrittweise Installation verwenden und dabei einige Schritte automatisieren.

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

Zum Installieren von Config Sync müssen alle Cluster in einer Flotte registriert sein. Wenn Sie Config Sync in der Google Cloud Console installieren, werden diese Cluster durch Auswahl einzelner 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 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 automatischer Upgrades finden Sie unter Config Sync aktualisieren.
  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 Auf OCI gehostetes 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 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“ nach Bedarf 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 das Flottenfeature 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 optionalen spec.configSync-Felder festlegen, die Sie beim Erstellen Ihres Manifests benötigen, und später kubectl-Befehle für die 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:

    • (Vorschau) UPGRADE_SETTING: Entfernen Sie die Kommentarzeichen des Felds und legen Sie auto fest, um Config Sync für das automatische Upgrade zu konfigurieren. Legen Sie manual fest, um Config Sync selbst manuell zu aktualisieren. Der Standardwert ist manual. Dieses Flag wird nur für GKE in Google Cloud-Clustern unterstützt. Damit Sie dieses Feld verwenden können, müssen Sie möglicherweise die gcloud CLI aktualisieren, indem Sie gcloud components update ausführen.

    • SOURCE_TYPE: Fügen Sie git zum Synchronisieren aus einem Git-Repository, oci zum Synchronisieren aus einem OCI-Image oder helm zum Synchronisieren aus einem Helm-Diagramm hinzu. 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-Überarbeitung (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. Wenn Sie einen Hash in Version 1.17.0 oder höher verwenden, muss es sich um einen vollständigen Hash und nicht um eine abgekürzte Form handeln.

    • 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 empfohlen, der Einfachheit halber das Feld syncRev zu verwenden, um einen Zweignamen anzugeben. Wenn sowohl das Feld syncRev als auch das Feld syncBranch angegeben ist, 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 ist die E-Mail-Adresse des Google Cloud-Dienstkontos (GSA), das zum Exportieren von Config Sync-Messwerten nach 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 Ressourcenblock google_gkehub_feature_membership an, der einen configmanagement- und config_sync-Block enthält:

git

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 {
     git {
       sync_repo = "REPO"
       sync_branch = "BRANCH"
       policy_dir = "DIRECTORY"
       secret_type = "SECRET"
     }
   }
 }
}

Ersetzen Sie Folgendes:

  • EXISTING_CLUSTER_NAME ist der Name Ihres vorhandenen Clusters.
  • EXISTING_CLUSTER_LOCATION ist der Standort Ihres vorhandenen Clusters.
  • MEMBERSHIP_ID ist die ID der Mitgliedschaftsbindung.
  • VERSION (optional) ist die Config Sync-Versionsnummer. Sie muss auf Version 1.17.0 oder höher festgelegt sein. Wenn Sie dieses Feld leer lassen, wird die Standardeinstellung verwendet.
  • 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.

oci

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 {
     oci {
       sync_repo = "REPO"
       policy_dir = "DIRECTORY"
       secret_type = "SECRET"
     }
   }
 }
}

Ersetzen Sie Folgendes:

  • EXISTING_CLUSTER_NAME ist der Name Ihres vorhandenen Clusters.
  • EXISTING_CLUSTER_LOCATION ist der Standort Ihres vorhandenen Clusters.
  • MEMBERSHIP_ID ist die ID der Mitgliedschaftsbindung.
  • VERSION (optional) ist die Config Sync-Versionsnummer. Wenn Sie dieses Feld leer lassen, wird die Standardeinstellung verwendet.
  • REPO ist die URL zum OCI-Image-Repository mit Ihren 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.

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

Nachdem Sie die Konfiguration Ihres Stamm-Repositories abgeschlossen haben, können Sie optional die Synchronisierung aus mehreren Repositories konfigurieren, einschließlich anderer Stamm-Repositories und Namespace-Repositories. Die Namespace-Repositories sind hilfreich, wenn Sie ein Repository mit Namespace-bezogenen Konfigurationen benötigen, 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 Standard auf Flottenebene für Ihre Cluster aktivieren und konfigurieren. Dies bedeutet, dass Config Sync für jeden neuen GKE-Cluster in Google Cloud, der in der Flotte erstellt wird, mit den von Ihnen festgelegten Einstellungen im Cluster aktiviert wird. Weitere Informationen zur Standardkonfiguration für Flotten finden Sie unter Features auf Flottenebene verwalten.

Wenn Sie nur die Google Cloud Console verwenden, können Sie Config Sync standardmäßig für Ihre Cluster aktivieren und die Config Sync-Version für Ihre Flotte festlegen. Wenn Sie Terraform verwenden, können Sie Config Sync standardmäßig für Ihre Cluster aktivieren, die Config Sync-Version für Ihre Flotte festlegen und die Verbindung zu Ihrem Git-Repository oder OCI-Image-Repository einrichten.

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

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 automatischer Upgrades finden Sie unter Config Sync aktualisieren.

  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 ist die ID des Flotten-Hostprojekts.
    • VERSION (optional) ist die Config Sync-Versionsnummer. Wenn Sie dieses Feld leer lassen, wird die Standardeinstellung verwendet.
    • 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 ist die ID des Flotten-Hostprojekts.
    • VERSION ist die Config Sync-Versionsnummer. Sie muss auf Version 1.17.0 oder höher festgelegt sein. Wenn Sie dieses Feld leer lassen, wird die Standardeinstellung verwendet.
    • 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 die Flottenmitglieder:

    terraform apply

Wenn Sie bereits Cluster haben, die Sie auf Ihre Standardeinstellungen für Config Sync aktualisieren möchten, verwenden Sie die Google Cloud Console, um ausgewählte Flottencluster mit den Standardeinstellungen Ihrer Flotte zu synchronisieren. Alternativ können Sie jeden Cluster manuell mit denselben Einstellungen mithilfe von Terraform oder der gcloud CLI konfigurieren. Folgen Sie dazu der Anleitung unter Config Sync konfigurieren. Wenn Sie zuvor Terraform verwendet haben, um Standardeinstellungen für Flotten anzugeben, verwenden Sie denselben configmanagement- und config_sync‑Block, mit dem Sie die Standardeinstellungen zur Konfiguration Ihrer ausgewählten Cluster festgelegt haben.

So synchronisieren Sie die Standardeinstellungen von Config Sync für Ihre gesamte Flotte:

  1. Zu Feature Manager:

    Zu „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.

Die Standardeinstellungen von Config Sync werden auf alle von Ihnen ausgewählten Cluster angewendet. Auch wenn die Google Cloud Console nur einen Teil der Einstellungen anzeigt, z. B. die Config Sync-Version, werden alle Einstellungen auf Flottenebene für die Cluster synchronisiert. Wenn Sie beispielsweise Config Sync für die Synchronisierung mit einem Git-Repository mithilfe von Terraform konfigurieren, wird diese Einstellung mit Ihren Clustern synchronisiert, aber nicht in der Google Cloud Console angezeigt.

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 Abschnitt Features die Seite Konfiguration auf.

    Zu „Config“

  2. Prüfen Sie auf dem Tab Pakete die Spalte Synchronisierungsstatus in der Clustertabelle. 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

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.

Rollenbasierte Zugriffssteuerung (RBAC) und Berechtigungen

Policy Controller, Config Sync und Config Controller umfassen Arbeitslasten mit umfangreichen 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 ConfigManagement Operator installiert die anderen Komponenten in dieser Tabelle. Einige dieser Komponenten erfordern Berechtigungen für den Clusteradministrator. Daher benötigt der ConfigManagement Operator sie ebenfalls.
Config Sync config-management-system Weitere Informationen zu den erforderlichen Berechtigungen finden Sie unter Config Sync-Berechtigungen.

Ressourcenanforderungen

Im folgenden Abschnitt sind die Ressourcenanforderungen 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 werden erstellt. Die folgenden Bedingungen führen dazu, dass jede Komponente geplant wird:

  • config-management-operator wird installiert, wenn Config Sync aktiviert ist.
  • reconciler-manager wird installiert, wenn Config Sync aktiviert ist.
  • admission-webhook wird installiert, wenn die Drift-Prävention aktiviert ist.
  • Für jedes RootSync- und RepoSync-Objekt wird ein reconciler installiert.
  • otel-collector wird installiert, wenn Config Sync aktiviert ist.

Weitere Informationen zu diesen Komponenten finden Sie unter Config Sync-Architektur.

1.18

Bereitstellungsname CPU-Anfrage (m) pro Replikat Speicheranfrage (Mi) pro Replikat
config-management-operator 100 200
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 Abgleichsbereitstellung.

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

1.17

Bereitstellungsname CPU-Anfrage (m) pro Replikat Speicheranfrage (Mi) pro Replikat
config-management-operator 100 200
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 Abgleichsbereitstellung.

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

1.16

Bereitstellungsname CPU-Anfrage (m) pro Replikat Speicheranfrage (Mi) pro Replikat
config-management-operator 100 200
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 Abgleichsbereitstellung.

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

Abgleichsbereitstellung

Für jedes RootSync- und RepoSync-Objekt erstellt Config Sync eine unabhängige Abgleichsbereitstellung, um die Synchronisierung durchzuführen. Die Abgleichsbereitstellung besteht aus mehreren Containern. Weitere Informationen zu diesen Containern finden Sie unter Abgleich-Container.

In Config Sync Version 1.17.0 und höher unterscheiden sich die Standardressourcenanfragen für den Abgleich bei Standard- und Autopilot-Clustern. Alle anderen Clustertypen verwenden die Standardeinstellungen.

Standardcluster

1.18

Containername 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.17

Containername 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

Containername 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.18

Containername CPU-Anfrage und ‑Limit (m) Speicheranfrage 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 250 384
oci-sync 50 64

1.17

Containername CPU-Anfrage und ‑Limit (m) Speicheranfrage 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.

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.18.0 v3.14.3 v5.3.0
1.17.1 und 1.17.3 v3.13.3 v5.3.0
1.16.3 und 1.17.0 v3.13.1 v5.1.1
1.16.1 und 1.16.2 v3.12.3 v5.1.1
1.16.0 v3.12.2 v5.1.1
1.15.3 v3.12.2 v5.1.0
1.15.1 bis 1.15.2 v3.11.3 v5.0.3
1.15.0 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