Config Sync manuell mit kubectl installieren (nicht empfohlen)

Auf dieser Seite erfahren Sie, wie Sie Config Sync mit kubectl-Befehlen installieren. Der Config Management 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 Source of Truth erstellen oder Zugriff darauf haben.

  • 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

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

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

Dabei gilt:

  • 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 dem Operator Zugriff auf OCI gewähren müssen, indem Sie gcpserviceaccount als Authentifizierungstyp verwenden, benötigen Sie zum Erstellen einer Richtlinienbindung auch die Berechtigung iam.serviceAccounts.setIamPolicy. 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 unter Umständen im Cluster instanziiert, funktioniert jedoch eventuell nicht ordnungsgemäß. In diesem Fall können Sie mit dem Befehl nomos status im Objekt nach Fehlern suchen.

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 bestand, dass Sie das git-creds-Secret nicht erstellt haben, wird es nach seiner Erstellung von Config Sync sofort erkannt. Sie müssen die Konfiguration 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 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 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 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 im selben Projekt wie Ihr verwalteter Cluster gewähren.

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

  2. Weisen Sie dem Google-Dienstkonto die IAM-Rolle „Cloud Source Repositories-Leser” (roles/source.reader) zu. Weitere Informationen zu 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, bei der 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 Name RootSync root-sync ist. Verwenden Sie andernfalls root-reconciler-ROOT_SYNC_NAME. Wenn Sie Config Sync mit der Google Cloud Console oder dem Google Cloud CLI installieren, erstellt Config Sync automatisch ein RootSync-Objekt namens root-sync.
  • REPOSITORY: Name des Repositorys.
  • POLICY_FILE ist die JSON- oder YAML-Datei mit der Identity and Access Management-Richtlinie.

Standardmäßiges Compute Engine-Dienstkonto

Wenn sich Ihr Repository in Cloud Source Repositories 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.

Operator 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 Folgendes verwendet: GKE-Workload Identity oderWorkload Identity der Flotte können Siek8sserviceaccount als Authentifizierungstyp in Version 1.17.2 und höher nutzen. Diese Option wird aufgrund des vereinfachten Konfigurationsprozesses 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, bei der Ihr Cluster registriert ist.
    • KSA_NAME: das Kubernetes-Dienstkonto für den Abgleich.
      • Verwenden Sie für Stamm-Repositories root-reconciler, wenn der Name RootSync root-sync ist. Verwenden Sie andernfalls root-reconciler-ROOT_SYNC_NAME. Wenn Sie Config Sync mit der Google Cloud Console oder dem Google Cloud CLI installieren, erstellt Config Sync automatisch ein RootSync-Objekt namens root-sync.
    • REPOSITORY: 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 Folgendes verwendet GKE-Workload Identity oderWorkload Identity der Flotte können Siegcpserviceaccount 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 kein Dienstkonto haben, erstellen Sie eins.

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

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

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

    • Erteilen Sie eine Repository-spezifische Berechtigung, wenn Sie Dienstkonten für jedes Repository in Ihrem Projekt unterschiedliche Zugriffsebenen zuweisen möchten.

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

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

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

Ersetzen Sie Folgendes:

  • PROJECT_ID: die Projekt-ID der Organisation.
  • FLEET_HOST_PROJECT_ID: Wenn Sie GKE Workload Identity verwenden, entspricht dies PROJECT_ID. Wenn Sie Flotten-Workload Identity verwenden, ist dies die Projekt-ID der Flotte, bei der 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 Name RootSync root-sync ist. Verwenden Sie andernfalls root-reconciler-ROOT_SYNC_NAME. Wenn Sie Config Sync mit der Google Cloud Console oder dem Google Cloud CLI installieren, erstellt Config Sync automatisch ein RootSync-Objekt namens root-sync.
  • REPOSITORY: 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 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.

Operator für eine Zertifizierungsstelle konfigurieren

Bei 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 Server zu prüfen. Dies wird für Git-, Helm- oder OCI-Server unterstützt. Das CA-Zertifikat muss vollständige SSL-Zertifikate (Stamm/Zwischenzertifikat/Blatt) enthalten. Wenn Ihr Server bereits eine vertrauenswürdige Zertifizierungsstelle verwendet oder Sie keine Verbindung über HTTPS herstellen, können Sie diesen Schritt überspringen und caCertSecretRef festlegen weglassen.

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 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 das RepoSync konfigurieren, legen Sie den Wert des Felds 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 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 zuzugreifen. 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 einem -Passwort:

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

Ersetzen Sie Folgendes:

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

Wenn Sie 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 verwendetGKE-Workload Identity oderWorkload Identity der Flotte können Siek8sserviceaccount als Authentifizierungstyp in Version 1.17.2 und höher nutzen. Diese Option wird aufgrund des vereinfachten Konfigurationsprozesses 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, bei der Ihr Cluster registriert ist.
    • KSA_NAME: das Kubernetes-Dienstkonto für den Abgleich.
      • Verwenden Sie für Stamm-Repositories root-reconciler, wenn der Name RootSync root-sync ist. Verwenden Sie andernfalls root-reconciler-ROOT_SYNC_NAME.
    • REPOSITORY: 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 verwendetGKE-Workload Identity oderWorkload Identity der Flotte können Siegcpserviceaccount 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 kein Dienstkonto haben, erstellen Sie eins.

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

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

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

    • Erteilen Sie eine Repository-spezifische Berechtigung, wenn Sie Dienstkonten für jedes Repository in Ihrem Projekt unterschiedliche Zugriffsebenen zuweisen möchten.

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

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

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

Ersetzen Sie Folgendes:

  • PROJECT_ID: die Projekt-ID der Organisation.
  • FLEET_HOST_PROJECT_ID: Wenn Sie GKE Workload Identity verwenden, entspricht dies PROJECT_ID. Wenn Sie Flotten-Workload Identity verwenden, ist dies die Projekt-ID der Flotte, bei der 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 Name RootSync root-sync ist. Verwenden Sie andernfalls root-reconciler-ROOT_SYNC_NAME.
  • REPOSITORY: 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 Zugriff auf Artifact Registry gewähren. Möglicherweise müssen Sie den Zugriffsbereich storage-ro gewähren, um Lesezugriff auf Images zu gewähren.

  1. Gewähren 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.

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

    Dabei gilt:

    • 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-Revision (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 auch einen Zweignamen im Feld revision 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.
    • ROOT_BRANCH: Der 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, 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 namens 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
    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_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.

    • ROOT_CA_CERT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, muss IhrOCI-Anbieter ein Zertifikat verwenden, das von dieser Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Das Secret muss das CA-Zertifikat unter einem Schlüssel namens 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 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
    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_HELM_REPOSITORY: Die URL des Helm-Repositorys, 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.
    • HELM_CHART_NAME: Fügen Sie den Namen des 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 des Helm-Release. Dieses Feld ist optional.
    • HELM_RELEASE_NAMESPACE: der Ziel-Namespace für einen Release. Ein Namespace wird nur für Ressourcen festgelegt, die in ihren Vorlagen namespace: {{ .Release.Namespace }} enthalten. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird der Standard-Namespace config-management-system verwendet.
    • HELM_INCLUDE_CRDS: Legen Sie 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: Anstelle der Standardwerte des Helm-Diagramms zu verwendende Werte 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 ROOT_AUTH_TYPE ist. Dieses Feld ist optional.

    • ROOT_CA_CERT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, muss Ihr Helm-Anbieter ein Zertifikat verwenden, das von dieser Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Das Secret muss das CA-Zertifikat unter einem Schlüssel namens 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 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 die 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 ConfigManagement Operator-Image aktualisiert. Kubernetes ruft die neue Version ab und startet den Config Sync-Pod mit der neuen Version neu. Beim Start von Config Management 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, lesen Sie die Informationen unter ConfigManagement Operator entfernen.

Nächste Schritte