Config Sync manuell mit kubectl installieren (nicht empfohlen)

Auf dieser Seite erfahren Sie, wie Sie Config Sync mit kubectl-Befehlen installieren. Der ConfigManagement Operator ist ein Controller, der Config Sync in einem Kubernetes-Cluster verwaltet. Führen Sie die folgenden Schritte aus, um den Operator in jedem Cluster zu installieren und zu konfigurieren, den Sie mit Config Sync verwalten möchten.

Hinweise

In diesem Abschnitt werden die Voraussetzungen beschrieben, die Sie vor der Installation von Config Sync mit kubectl erfüllen müssen.

Lokale Umgebung vorbereiten

Bevor Sie den Operator installieren, müssen Sie Ihre lokale Umgebung vorbereiten. Dazu führen Sie die folgenden Aufgaben aus:

  • Eine Datenquelle erstellen oder darauf zugreifen.

  • Installieren und initialisieren Sie das Google Cloud CLI, das die in dieser Anleitung verwendeten Befehle gcloud, gsutil, kubectl und nomos enthält. Wenn Sie Cloud Shell verwenden, ist Google Cloud CLI vorinstalliert.

  • kubectl wird vom Google Cloud CLI nicht standardmäßig installiert. Verwenden Sie zum Installieren von kubectl den folgenden Befehl:

    gcloud components install kubectl

  • Authentifizieren Sie sich bei Google Cloud mit dem Befehl gcloud auth login, sodass Sie Komponenten von Config Sync herunterladen können.

Cluster vorbereiten

Erstellen Sie einen Cluster der Google Kubernetes Engine (GKE) Enterprise-Version, der die Anforderungen für Config Sync erfüllt, oder haben Sie Zugriff darauf.

Berechtigungen vorbereiten

Der Google Cloud-Nutzer, der Config Sync installiert, benötigt IAM-Berechtigungen, um neue Rollen im Cluster zu erstellen. Weisen Sie diese Rollen bei Bedarf mit den folgenden Befehlen zu:

gcloud container clusters get-credentials CLUSTER_NAME

kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole cluster-admin --user USER_ACCOUNT

Ersetzen Sie Folgendes:

  • CLUSTER_NAME: Ihr Clustername
  • USER_ACCOUNT: E-Mail-Adresse Ihres Google Cloud-Kontos

Je nachdem, wie Sie das Google Cloud CLI auf Ihrem lokalen System konfiguriert haben, müssen Sie möglicherweise die Felder --project und --zone hinzufügen.

Wenn Sie mit gcpserviceaccount als Authentifizierungstyp dem Operator Zugriff auf OCI gewähren müssen, benötigen Sie auch die Berechtigung iam.serviceAccounts.setIamPolicy, um eine Richtlinienbindung zu erstellen. Sie können diese Berechtigung erhalten, indem Sie die IAM-Rolle Dienstkontoadministrator (roles/iam.serviceAccountAdmin) zuweisen. Sie können diese Berechtigung auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff verwalten.

Cluster registrieren

Führen Sie die folgenden Schritte aus, um einen Cluster in Config Sync zu registrieren:

  1. Operator bereitstellen
  2. Gewähren Sie dem Operator Lesezugriff auf eine der folgenden Optionen:
  3. Operator konfigurieren

Operator bereitstellen

Wenn Sie geprüft haben, ob alle Voraussetzungen erfüllt sind, können Sie den Operator bereitstellen, indem Sie ein YAML-Manifest herunterladen und anwenden.

  1. Laden Sie die neueste Version der Operator-Manifeste mit dem folgenden Befehl herunter. Wenn Sie eine bestimmte Version herunterladen möchten, finden Sie unter Downloads weitere Informationen.

    gsutil cp gs://config-management-release/released/latest/config-management-operator.yaml config-management-operator.yaml

  2. Wenden Sie die Manifeste an:

    kubectl apply -f config-management-operator.yaml

Wenn dies aufgrund eines Problems mit dem ConfigManagement-Objekt fehlschlägt, das nicht auf einen YAML- oder JSON-Syntaxfehler zurückzuführen ist, wird das Objekt möglicherweise im Cluster instanziiert, funktioniert aber möglicherweise nicht richtig. In diesem Fall können Sie den Befehl nomos status verwenden, um das Objekt auf Fehler zu prüfen.

Eine gültige Installation ohne Probleme hat den Status PENDING oder SYNCED.

Eine ungültige Installation hat den Status NOT CONFIGURED und führt einen der folgenden Fehler auf:

  • missing git-creds Secret
  • missing required syncRepo field
  • git-creds Secret is missing the key specified by secretType

Beheben Sie den Konfigurationsfehler, um das Problem zu lösen. Je nach Art des Fehlers müssen Sie möglicherweise das ConfigManagement-Manifest noch einmal auf den Cluster anwenden.

Wenn das Problem darin besteht, dass Sie vergessen haben, das Secret git-creds zu erstellen, erkennt Config Sync das Secret, sobald Sie es erstellt haben. Sie müssen die Konfiguration dann nicht noch einmal anwenden.

Operator Lesezugriff gewähren

Wenn Sie Ihre Konfigurationen in Git speichern, müssen Sie dem Operator Lesezugriff auf Git gewähren. Wenn Sie Ihre Konfigurationen als OCI-Images speichern, müssen Sie dem Operator Lesezugriff auf OCI gewähren. Wenn Sie Ihre Konfigurationen in Helm speichern, müssen Sie dem Operator Lesezugriff auf Helm gewähren.

Operator Lesezugriff auf Git gewähren

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

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

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

Config Sync unterstützt die folgenden Authentifizierungsmechanismen:

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

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

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

  1. Listen Sie alle Repositories auf:

    gcloud source repos list

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

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

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

SSH-Schlüsselpaar

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

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

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

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

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

    Ersetzen Sie Folgendes:

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

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

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

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

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

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

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

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

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

    known_hosts: KNOWN_HOSTS_KEY

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

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

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

    Ersetzen Sie Folgendes:

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

Cookiefile

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

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

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

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

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

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

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

    Ersetzen Sie Folgendes:

    • /path/to/COOKIEFILE: der entsprechende Pfad und Dateiname
    • HTTPS_PROXY_URL: Die URL für den HTTPS-Proxy, den Sie bei der Kommunikation mit dem Git-Repository verwenden.

  2. Schützen Sie den Inhalt des cookiefile, wenn Sie es noch lokal benötigen. Andernfalls können Sie es löschen.

Token

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

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

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

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

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

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

    Dabei gilt:

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

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

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

    Ersetzen Sie Folgendes:

    • USERNAME: Nutzername, den Sie verwenden möchten.
    • TOKEN: Token, das Sie im vorherigen Schritt erstellt haben.
    • HTTPS_PROXY_URL: Die URL für den HTTPS-Proxy, den Sie bei der Kommunikation mit dem Git-Repository verwenden.

  3. Schützen Sie das Token, wenn Sie es noch lokal benötigen. Andernfalls können Sie es löschen.

Google-Dienstkonto

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

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

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

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

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

    • Erteilen Sie eine Repository-spezifische Berechtigung, wenn Dienstkonten unterschiedliche Zugriffsebenen für jedes Repository in Ihrem Projekt haben sollen.

      gcloud source repos set-iam-policy REPOSITORY POLICY_FILE --project=PROJECT_ID

  3. Wenn Sie Config Sync mit der Google Cloud Console konfigurieren, wählen Sie Workload Identity als Authentifizierungstyp aus und fügen Sie dann die E-Mail-Adresse Ihres Dienstkontos hinzu.

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

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

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

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

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

Ersetzen Sie Folgendes:

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

Standardmäßiges Compute Engine-Dienstkonto

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

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

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

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

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

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

Operator Lesezugriff auf OCI gewähren

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

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

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

  • Kubernetes-Dienstkonto (k8sserviceaccount)
  • Google-Dienstkonto (gcpserviceaccount)

  • Standardmäßiges Compute Engine-Dienstkonto (gcenode)

Kubernetes-Dienstkonto

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

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

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

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

    • Erteilen Sie eine Repository-spezifische Berechtigung, wenn Dienstkonten unterschiedliche Zugriffsebenen für jedes Repository in Ihrem Projekt haben sollen.

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

    Ersetzen Sie Folgendes:

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

Google-Dienstkonto

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

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

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

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

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

    • Erteilen Sie eine Repository-spezifische Berechtigung, wenn Dienstkonten unterschiedliche Zugriffsebenen für jedes Repository in Ihrem Projekt haben sollen.

      gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
   --project=PROJECT_ID

  3. Erstellen Sie mit dem folgenden Befehl eine IAM-Richtlinienbindung zwischen dem Kubernetes-Dienstkonto und dem Google-Dienstkonto:

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

Ersetzen Sie Folgendes:

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

Standardmäßiges Compute Engine-Dienstkonto

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

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

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

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

Operator für eine Zertifizierungsstelle konfigurieren

Bei Git-Servern, die mit Zertifikaten von einer nicht vertrauenswürdigen Zertifizierungsstelle konfiguriert wurden, kann Config Sync so konfiguriert werden, dass ein CA-Zertifikat verwendet wird, um HTTPS-Verbindungen zum Git-Server zu prüfen. Das CA-Zertifikat muss vollständige SSL-Zertifikate (Stamm-/Zwischenzertifikat/Blatt) enthalten. Wenn Ihr Git-Server bereits eine vertrauenswürdige Zertifizierungsstelle verwendet oder Sie keine Verbindung über HTTPS herstellen, können Sie diesen Schritt überspringen und caCertSecretRef nicht festlegen.

RootSync

  1. Rufen Sie das CA-Zertifikat ab, mit dem das Zertifikat für Ihren Git-Server ausgestellt wurde, und speichern Sie es in einer Datei.

  2. Bei RootSync-Objekten muss das Secret im Namespace config-management-system erstellt werden. Beispiel: 

    kubectl create ns config-management-system && 
    
kubectl create secret generic ROOT_CA_CERT_SECRET_NAME 
    
 --namespace=config-management-system 
    
 --from-file=cert=/path/to/CA_CERT_FILE

  3. Wenn Sie den Operator konfigurieren, legen Sie den Wert des Felds spec.git.caCertSecretRef.name im Objekt RootSync auf ROOT_CA_CERT_SECRET_NAME fest.

RepoSync

  1. Rufen Sie das CA-Zertifikat ab, mit dem das Zertifikat für Ihren Git-Server ausgestellt wurde, und speichern Sie es in einer Datei.

  2. Bei RepoSync-Objekten muss das Secret im selben Namespace wie RepoSync erstellt werden. Beispiel: 

    kubectl create ns REPO_SYNC_NAMESPACE && 
    
kubectl create secret generic NAMESPACE_CA_CERT_SECRET_NAME 
    
 --namespace=REPO_SYNC_NAMESPACE 
    
 --from-file=cert=/path/to/CA_CERT_FILE

  3. Wenn Sie RepoSync konfigurieren, legen Sie den Wert des Felds spec.git.caCertSecretRef.name im Objekt RepoSync auf NAMESPACE_CA_CERT_SECRET_NAME fest.

Operator Lesezugriff auf Helm gewähren

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

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

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

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

Token

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

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

Ersetzen Sie Folgendes:

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

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

Kubernetes-Dienstkonto

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

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

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

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

    • Erteilen Sie eine Repository-spezifische Berechtigung, wenn Dienstkonten unterschiedliche Zugriffsebenen für jedes Repository in Ihrem Projekt haben sollen.

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

    Ersetzen Sie Folgendes:

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

Google-Dienstkonto

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

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

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

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

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

    • Erteilen Sie eine Repository-spezifische Berechtigung, wenn Dienstkonten unterschiedliche Zugriffsebenen für jedes Repository in Ihrem Projekt haben sollen.

      gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
   --project=PROJECT_ID

  3. Erstellen Sie mit dem folgenden Befehl eine IAM-Richtlinienbindung zwischen dem Kubernetes-Dienstkonto und dem Google-Dienstkonto:

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

Ersetzen Sie Folgendes:

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

Standardmäßiges Compute Engine-Dienstkonto

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

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

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

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

Operator konfigurieren

Zur Konfiguration der Synchronisierung vom Root-Repository müssen Sie den Multi-Repo-Modus in Ihrem ConfigManagement-Objekt aktivieren und ein RootSync-Objekt erstellen, das Ihr Root-Repository mit dem Cluster synchronisiert. Sie können nur ein Root-Repository pro Cluster erstellen und das Root-Repository kann entweder ein unstrukturiertes Repository oder ein hierarchisches Repository sein.

  1. Wenn Sie den Config Sync-Zulassungs-Webhook verwenden (der Zulassungs-Webhook ist standardmäßig deaktiviert) und Config Sync in einem privaten Cluster installieren, fügen Sie eine Firewallregel hinzu, um Port 10250 zuzulassen. Der Config Sync-Zulassungs-Webhook verwendet Port 10250, um Abweichungen zu verhindern.

  2. Erstellen Sie eine Datei mit dem Namen config-management.yaml und kopieren Sie die folgende YAML-Datei hinein:

    # config-management.yaml
apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  # The `enableMultiRepo` field is set to true to enable RootSync and RepoSync APIs.
  enableMultiRepo: true
  preventDrift: PREVENT_DRIFT

    Ersetzen Sie Folgendes:

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

  3. Änderungen anwenden:

    kubectl apply -f config-management.yaml

  4. Warten Sie, bis die CRDs für RootSync und RepoSync verfügbar sind:

    until kubectl get customresourcedefinitions rootsyncs.configsync.gke.io reposyncs.configsync.gke.io; do date; sleep 1; echo ""; done

  5. Speichern Sie eines der folgenden Manifeste als root-sync.yaml. Verwenden Sie die Manifestversion, die dem Quelltyp für Ihre Konfigurationen entspricht.

    Git

    # root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: ROOT_FORMAT
  git:
    repo: ROOT_REPOSITORY
    revision: ROOT_REVISION
    branch: ROOT_BRANCH
    dir: ROOT_DIRECTORY
    auth: ROOT_AUTH_TYPE
    gcpServiceAccountEmail: ROOT_EMAIL
    secretRef:
      name: ROOT_SECRET_NAME
    noSSLVerify: ROOT_NO_SSL_VERIFY
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME

    Ersetzen Sie Folgendes:

    • ROOT_SYNC_NAME: Fügen Sie den Namen Ihres RootSync-Objekts hinzu.
    • ROOT_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 damit Ihre Konfigurationen so organisieren können, wie es für Sie am besten ist.
    • ROOT_REPOSITORY: Fügen Sie die URL des Git-Repositorys hinzu, das als Stamm-Repository verwendet werden soll. Sie können URLs mithilfe des HTTPS- oder SSH-Protokolls eingeben. https://github.com/GoogleCloudPlatform/anthos-config-management-samples verwendet beispielsweise das HTTPS-Protokoll. Dies ist ein Pflichtfeld.
    • ROOT_REVISION: Fügen Sie die Git-Version (Tag oder Hash) hinzu, 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 im Feld revision auch einen Zweignamen angeben. In Version 1.17.0 oder höher muss ein Hashwert und keine verkürzte Form verwendet werden.
    • ROOT_BRANCH: Fügen Sie den Zweig des Repositorys hinzu, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist master. Ab Config Sync Version 1.17.0 wird der Einfachheit halber empfohlen, das Feld revision zu verwenden, um einen Zweignamen anzugeben. Wenn sowohl das Feld revision als auch das Feld branch angegeben sind, hat revision Vorrang vor branch.
    • ROOT_DIRECTORY: Fügen Sie den Pfad im Git-Repository zum Stammverzeichnis hinzu, das die Konfiguration enthält, mit der Sie die Synchronisierung durchführen möchten. Dieses Feld ist optional und die Standardeinstellung ist das Stammverzeichnis (/) des Repositorys.

    • ROOT_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:

      • none: Keine Authentifizierung verwenden
      • ssh: Ein SSH-Schlüsselpaar verwenden
      • cookiefile: Nutzen Sie einen cookiefile.
      • token: Ein Token verwenden
      • gcpserviceaccount: Mit einem Google-Dienstkonto auf Cloud Source Repositories zugreifen
      • 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.

      Dies ist ein Pflichtfeld.

    • ROOT_EMAIL: Wenn Sie gcpserviceaccount für ROOT_AUTH_TYPE angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.

    • ROOT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, müssen Sie dem Git-Anbieter den öffentlichen Schlüssel des Secrets hinzufügen. Dieses Feld ist optional.

    • ROOT_NO_SSL_VERIFY: Setzen Sie dieses Feld auf true, um die SSL-Zertifikatsüberprüfung zu deaktivieren. Der Standardwert ist false.

    • ROOT_CA_CERT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, muss Ihr Git-Anbieter ein Zertifikat verwenden, das von dieser Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Das Secret muss das CA-Zertifikat unter einem Schlüssel mit dem Namen cert enthalten. Dieses Feld ist optional.

      Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Operator für eine Zertifizierungsstelle konfigurieren.

    Eine Erläuterung der Felder und eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter RootSync-Felder.

    Dieses Manifest erstellt ein RootSync-Objekt, das Git als Quelle verwendet.

    OCI

    # root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: oci
  sourceFormat: ROOT_FORMAT
  oci:
    image: ROOT_IMAGE
    dir: ROOT_DIRECTORY
    auth: ROOT_AUTH_TYPE
    gcpServiceAccountEmail: ROOT_EMAIL

    Ersetzen Sie Folgendes:

    • ROOT_SYNC_NAME: Fügen Sie den Namen Ihres RootSync-Objekts hinzu.
    • ROOT_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 damit Ihre Konfigurationen so organisieren können, wie es für Sie am besten ist.
    • ROOT_IMAGE: Die URL des OCI-Images, das als Root-Repository verwendet werden soll, z. B. 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
    • ROOT_DIRECTORY: Fügen Sie den Pfad im Repository zum Stammverzeichnis hinzu, das die Konfiguration enthält, mit der Sie die Synchronisierung durchführen möchten. Dieses Feld ist optional und die Standardeinstellung ist das Stammverzeichnis (/) des Repositorys.

    • ROOT_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:

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

      Dies ist ein Pflichtfeld.

    • ROOT_EMAIL: Wenn Sie gcpserviceaccount für ROOT_AUTH_TYPE angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.

    Eine Erläuterung der Felder und eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter RootSync-Felder.

    Dieses Manifest erstellt ein RootSync-Objekt, das ein OCI-Image als Quelle verwendet.

    Helm

    # root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: helm
  sourceFormat: ROOT_FORMAT
  helm:
    repo: ROOT_HELM_REPOSITORY
    chart: HELM_CHART_NAME
    version: HELM_CHART_VERSION
    releaseName: HELM_RELEASE_NAME
    namespace: HELM_RELEASE_NAMESPACE
    values:
      foo:
        bar: VALUE_1
      baz:
      - qux: VALUE_2
        xyz: VALUE_3
    includeCRDs: HELM_INCLUDE_CRDS
    auth: ROOT_AUTH_TYPE
      gcpServiceAccountEmail: ROOT_EMAIL
      secretRef:
        name: ROOT_SECRET_NAME

    Ersetzen Sie Folgendes:

    • ROOT_SYNC_NAME: Fügen Sie den Namen Ihres RootSync-Objekts hinzu.
    • ROOT_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 damit Ihre Konfigurationen so organisieren können, wie es für Sie am besten ist.
    • ROOT_HELM_REPOSITORY: die URL des Helm-Repositorys, das als Root-Repository verwendet werden soll. Sie können URLs entweder mit dem HTTPS- oder SSH-Protokoll eingeben. https://github.com/GoogleCloudPlatform/anthos-config-management-samples verwendet beispielsweise das HTTPS-Protokoll. Dies ist ein Pflichtfeld.
    • HELM_CHART_NAME: Fügen Sie den Namen Ihres Helm-Diagramms hinzu. Dies ist ein Pflichtfeld.
    • HELM_CHART_VERSION: die Version Ihres Diagramms. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird die neueste Version verwendet.
    • HELM_RELEASE_NAME: der Name der Helm-Version. Dieses Feld ist optional.
    • HELM_RELEASE_NAMESPACE: Der Ziel-Namespace für einen Release. Ein Namespace wird nur für Ressourcen festgelegt, die namespace: {{ .Release.Namespace }} in ihren Vorlagen enthalten. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird der Standard-Namespace config-management-system verwendet.
    • HELM_INCLUDE_CRDS: Legen Sie dafür true fest, wenn die Helm-Vorlage auch eine CustomResourceDefinition generieren soll. Dieses Feld ist optional. Wenn kein Wert angegeben ist, ist der Standardwert false und es wird keine CRD generiert.
    • VALUE: Werte, die anstelle der Standardwerte im Helm-Diagramm verwendet werden sollen. Formatieren Sie dieses Feld genauso wie die Datei values.yaml des Helm-Diagramms. Dieses Feld ist optional.

    • ROOT_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:

      • none: Keine Authentifizierung verwenden
      • token: Verwenden Sie einen Nutzernamen und ein Passwort, um auf ein privates Helm-Repository zuzugreifen.
      • 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.

      Dies ist ein Pflichtfeld.

    • ROOT_EMAIL: Wenn Sie gcpserviceaccount für ROOT_AUTH_TYPE angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.

    • ROOT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu, wenn token der Wert ROOT_AUTH_TYPE ist. Dieses Feld ist optional.

    Eine Erläuterung der Felder und eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter RootSync-Felder.

    Dieses Manifest erstellt ein RootSync-Objekt, das Helm als Quelle verwendet.

  6. Änderungen anwenden:

    kubectl apply -f root-sync.yaml

Synchronisierungsstatus des Stamm-Repositorys prüfen

Mit dem Befehl nomos status können Sie den Synchronisierungsstatus des Stamm-Repositorys prüfen:

nomos status

Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

my_managed_cluster-1
  --------------------
  <root>   git@github.com:foo-corp/acme/admin@main
  SYNCED   f52a11e4

RootSync-Installation prüfen

Wenn Sie ein RootSync-Objekt erstellen, erstellt Config Sync einen Abgleicher mit dem Präfix root-reconciler. Ein Abgleich ist ein Pod, der als Deployment bereitgestellt wird. Damit werden Manifeste aus einem Git-Repository mit einem Cluster synchronisiert.

Sie können prüfen, ob das RootSync-Objekt ordnungsgemäß funktioniert. Prüfen Sie dazu den Status der Root-Abgleichsbereitstellung:

kubectl get -n config-management-system deployment \
    -l configsync.gke.io/sync-name=ROOT_SYNC_NAME

Ersetzen Sie ROOT_SYNC_NAME durch den Namen von RootSync.

Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

NAME              READY   UP-TO-DATE   AVAILABLE   AGE
root-reconciler   1/1     1            1           3h42m

Weitere Möglichkeiten zur Untersuchung des Status Ihres RootSync-Objekts finden Sie unter RootSync- und RepoSync-Objekte überwachen.

Nachdem Sie Ihr Root-Repository konfiguriert haben, können Sie optional die Synchronisierung aus mehreren Repositories konfigurieren. Diese Repositories sind hilfreich, wenn Sie ein Repository mit Namespace-bezogenen Konfigurationen benötigen, die clusterübergreifend mit einem bestimmten Namespace synchronisiert werden.

Config Sync aktualisieren

Führen Sie die folgenden Befehle für jeden registrierten Cluster aus, um Config Sync zu aktualisieren:

  1. Laden Sie das Config Sync-Manifest und nomos-Befehle für die neue Version herunter.

  2. Wenden Sie das Config Sync-Manifest an:

    kubectl apply -f config-management-operator.yaml

    Mit diesem Befehl wird das Image des ConfigManagement Operators aktualisiert. Kubernetes ruft die neue Version ab und startet den Config Sync-Pod mit der neuen Version neu. Beim Start von Config Sync wird eine Abgleichschleife ausgeführt, die die im neuen Image gebündelten Manifeste anwendet. Dadurch wird jeder Komponenten-Pod aktualisiert und neu gestartet.

  3. Ersetzen Sie auf allen Clients den Befehl nomos durch die neue Version. Durch diese Änderung kann der Befehl nomos immer den Status aller registrierten Cluster abrufen und Konfigurationen für sie validieren.

Config Sync deinstallieren

Führen Sie folgende Schritte aus, um Config Sync zu deinstallieren:

  1. Ein zentraler Administrator sollte das Root-Repository entfernen:

    1. Heben Sie die Verwaltung der vom RootSync-Objekt verwalteten Ressourcen gemäß der Anleitung zur Fehlerbehebung auf oder löschen Sie diese gemäß der Anleitung.

    2. Löschen Sie das Objekt RootSync mit folgendem Befehl:

      kubectl delete -f root-sync.yaml

  2. Entfernen Sie alle Repositories.

  3. Entfernen Sie das Feld spec.enableMultiRepo in der Datei config-management.yaml.

  4. Wenden Sie die Datei config-management.yaml auf Ihren Cluster an.

Wenn Sie Config Sync vollständig deinstallieren möchten, finden Sie weitere Informationen unter ConfigManagement Operator entfernen.

Nächste Schritte