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.

Achtung: Die auf dieser Seite verwendeten Installationsmethoden werden nicht empfohlen, da sie nicht mit der Google Cloud Console oder der Google Cloud CLI kompatibel sind.

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:

• Erstellen Sie eine Source of Truth oder greifen Sie darauf zu.

• Installieren und initialisieren Sie das Google Cloud CLI, das die in dieser Anleitung verwendeten Befehle gcloud, 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:
   • Git
   • OCI
   • Helm
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.

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

Achtung: Sie sollten die mit diesem Befehl erstellten Dateien schützen, da sie den Lesezugriff auf das Repository ermöglichen.

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.

   Hinweis: Sie müssen den SSH-Schlüssel ohne Passphrase erstellen. Config Sync unterstützt keine Passphrasen für SSH-Schlüssel.

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

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

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

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

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

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

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

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

   known_hosts: KNOWN_HOSTS_KEY
   

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

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

   ssh://[e-mail]: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

Hinweis: Die Verwendung von cookiefile-Anmeldedaten wird nur bei Cloud Source Repositories unterstützt. Wenn Sie GitHub mit cookiefile-Authentifizierung verwenden möchten, können Sie das GitHub-Repository mit Cloud Source Repositories spiegeln.

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.
   Hinweis: Der HTTP-Proxy wird aus Sicherheitsgründen nicht unterstützt.

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

Token

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

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

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

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

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

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

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

   Ersetzen Sie Folgendes:

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

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

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

   Ersetzen Sie Folgendes:

   • USERNAME: Nutzername, den Sie verwenden möchten.
   • TOKEN: Token, das Sie im vorherigen Schritt erstellt haben.
   • HTTPS_PROXY_URL: Die URL für den HTTPS-Proxy, den Sie bei der Kommunikation mit dem Git-Repository verwenden.
   Hinweis: Der HTTP-Proxy wird aus Sicherheitsgründen nicht unterstützt.

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

Google-Dienstkonto

Wenn sich Ihr Repository in Cloud Source Repositories befindet und Ihr Cluster GKE Workload Identity Federation for GKE oder Fleet Workload Identity Federation for GKE verwendet, können Sie Config Sync mithilfe eines Google-Dienstkontos Zugriff auf ein Repository in dem Projekt gewähren, in dem sich Ihr verwalteter Cluster befindet.

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

2. Weisen Sie dem Google-Dienstkonto die IAM-Rolle „Cloud Source Repositories-Leser” (roles/source.reader) zu. Weitere Informationen zu 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 Federation for GKE als Authentifizierungstyp aus und fügen Sie dann die E-Mail-Adresse Ihres Dienstkontos hinzu.

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

4. Nach dem Konfigurieren von Config Sync erstellen Sie eine IAM-Richtlinienbindung zwischen dem Kubernetes-Dienstkonto und dem Google-Dienstkonto. Das Kubernetes-Dienstkonto wird erst erstellt, wenn Sie Config Sync zum ersten Mal konfigurieren.

   Wenn Sie Cluster verwenden, die bei einer Flotte registriert sind, müssen Sie die Richtlinienbindung nur einmal pro Flotte erstellen. Alle in einer Flotte registrierten Cluster haben denselben Workload Identity Federation for GKE-Pool. Wenn Sie Ihrem Kubernetes-Dienstkonto in einem Cluster die IAM-Richtlinie hinzufügen, erhält das Kubernetes-Dienstkonto aus demselben Namespace in anderen Clustern in derselben Flotte aufgrund des Konzepts der Gleichheit für eine Flotte ebenfalls dieselbe IAM-Richtlinie.

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

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

Ersetzen Sie Folgendes:

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

Hinweis: Zum Erstellen dieser Richtlinienbindung ist die Berechtigung iam.serviceAccounts.setIamPolicy erforderlich.

Standardmäßiges Compute Engine-Dienstkonto

Wenn sich Ihr Repository in Cloud Source Repositories befindet und Ihr Cluster GKE mit deaktivierter Workload Identity Federation for GKE 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:[e-mail]"

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

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

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

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

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

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

   Ersetzen Sie Folgendes:

   • PROJECT_ID: die Projekt-ID der Organisation.
   • FLEET_HOST_PROJECT_ID: Wenn Sie GKE Workload Identity Federation for GKE verwenden, entspricht dies PROJECT_ID. Wenn Sie die Flotten-Workload Identity-Föderation für GKE verwenden, ist dies die Projekt-ID der Flotte, für die Ihr Cluster registriert ist.
   • KSA_NAME: das Kubernetes-Dienstkonto für den Abgleich.
     • Verwenden Sie für Stamm-Repositories root-reconciler, wenn der RootSync-Name root-sync lautet. Verwenden Sie andernfalls root-reconciler-ROOT_SYNC_NAME. Wenn Sie Config Sync mit der Google Cloud Console oder der Google Cloud CLI installieren, erstellt Config Sync automatisch ein RootSync-Objekt namens root-sync.
   • REPOSITORY: die ID des Repositorys.
   • LOCATION: der regionale oder multiregionale Speicherort für das Repository.
   Hinweis: Zum Erstellen dieser Richtlinienbindung ist die Berechtigung iam.serviceAccounts.setIamPolicy erforderlich.

Google-Dienstkonto

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

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

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

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

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

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

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

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

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

Ersetzen Sie Folgendes:

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

Hinweis: Zum Erstellen dieser Richtlinienbindung ist die Berechtigung iam.serviceAccounts.setIamPolicy erforderlich.

Standardmäßiges Compute Engine-Dienstkonto

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

1. Führen Sie den folgenden Befehl aus, um dem Compute Engine-Dienstkonto die Leseberechtigung für Artifact Registry zu erteilen:

   gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:[e-mail] \
      --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- und OCI-Server unterstützt. Das CA-Zertifikat muss vollständige SSL-Zertifikate (Stamm/Intermediate/Leaf) 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, setzen Sie den Wert des Feldes caCertSecretRef.name im Objekt RootSync auf ROOT_CA_CERT_SECRET_NAME.

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, setzen Sie den Wert des caCertSecretRef.name-Felds im RepoSync-Objekt auf NAMESPACE_CA_CERT_SECRET_NAME.

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

Hinweis: Config Sync unterstützt nicht die Konfiguration von helm als Quelltyp über die Google Cloud Console oder die Google Cloud CLI. Sie können Ihr RootSync- oder RepoSync-Objekt konfigurieren, um von einem Helm-Repository mithilfe der Kubernetes API zu synchronisieren, oder es in einer anderen „Source of Truth“ deklarieren. Weitere Informationen finden Sie unter Konfiguration für das Helm-Repository.

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

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

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

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

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

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

   Ersetzen Sie Folgendes:

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

Hinweis: Zum Erstellen dieser Richtlinienbindung ist die Berechtigung iam.serviceAccounts.setIamPolicy erforderlich.

Google-Dienstkonto

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

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

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

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

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

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

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

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

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

Ersetzen Sie Folgendes:

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

Hinweis: Zum Erstellen dieser Richtlinienbindung ist die Berechtigung iam.serviceAccounts.setIamPolicy erforderlich.

Standardmäßiges Compute Engine-Dienstkonto

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

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

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:[e-mail] \
       --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 (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 Federation for GKE 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 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

   Achtung: Config Sync erfordert, dass die OCI-Ebene in der tar oder tar+gzip-Format. Andere Formate (z. B. tar+bz2) werden von Config Sync nicht erkannt. Der Wechsel von einem gültigen REPO-Konto zu einem OCI-Image mit einem nicht unterstützten Format führt dazu, dass verwaltete Ressourcen fehlerfrei gelöscht werden.

   • 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 Federation for GKE in Ihrem Cluster nicht 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 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 aktuelle 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 Federation for GKE in Ihrem Cluster nicht 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 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>   [e-mail]: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

Hinweis: Bei einem Upgrade von einer früheren Version als 1.10.0 werden alle Config Sync-Zulassungs-Webhook-Ressourcen entfernt.

Hinweis: Wenn Sie ein Upgrade von einer nicht unterstützten Version durchführen, sollten Sie ein schrittweises Upgrade auf maximal drei Nebenversionen gleichzeitig durchführen. Wenn die aktuelle Config Sync-Version beispielsweise 1.11.0 ist, führen Sie zuerst ein Upgrade auf Version 1.14.0 und dann auf Version 1.17.0 durch.

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

Achtung: Durch das Löschen eines RootSync- oder RepoSync-Objekts werden die Annotationen und Labels von Config Sync nicht bereinigt. Der Config Sync-Zulassungs-Webhook lehnt Anfragen zum Löschen dieser Ressourcen ab, wenn Config Sync noch im Cluster aktiviert ist. Verwenden Sie als Problemumgehung die Aufhebung der Verwaltung dieser verwalteten Ressourcen bzw. löschen Sie diese, bevor Sie das entsprechende RootSync- oder RepoSync-Objekt löschen.

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

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

   1. Wenn Sie den Webhook aktiviert haben und Ihre Ressourcen beibehalten möchten, deaktivieren Sie die Drift-Prävention für verworfene Ressourcen. Wenn Sie den Webhook nicht aktiviert haben, müssen Sie keine zusätzlichen Schritte ausführen, um Ihre Ressourcen beizubehalten.

   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.

Hinweis: Das Deaktivieren dieser Funktion wirkt sich nicht auf Konfigurationen aus, die Config Sync zuvor auf Ihre Cluster angewendet hat.

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

Nächste Schritte

• Synchronisierung aus mehreren Repositories konfigurieren