Config Sync manuell mit kubectl installieren (nicht empfohlen)

1.20.0 oder höher

1. Laden Sie die neueste Version der Config Sync-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-sync.tar.gz config-sync.tar.gz
   

2. Extrahieren Sie das Archiv:

   tar -xzvf config-sync.tar.gz

3. Folgen Sie im im vorherigen Schritt extrahierten Archiv der Anleitung in der bereitgestellten README, um die Kustomisierung zu bearbeiten.

4. Um die Config Sync-Installation zu aktualisieren, wenden Sie das gerenderte Manifest an, das Sie gemäß der README-Anleitung erstellt haben:

   kubectl apply -f CONFIG_SYNC_MANIFEST
   

   Ersetzen Sie CONFIG_SYNC_MANIFEST durch den Namen des gerenderten Manifests.

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

1.19.2 oder niedriger

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
   

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

4. Übernehmen Sie die Änderung:

   kubectl apply -f config-management.yaml
   

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

SSH-Schlüsselpaar

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

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

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

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

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

   Ersetzen Sie Folgendes:

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

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

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

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

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

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

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

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

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

   Fügen Sie dann unter data den Eintrag für bekannte Hosts hinzu:

   known_hosts: KNOWN_HOSTS_KEY
   

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

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

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

   Ersetzen Sie Folgendes:

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

Cookiefile

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

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

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

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

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

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

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

   Ersetzen Sie Folgendes:

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

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

Token

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

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

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

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

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

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

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

   Ersetzen Sie Folgendes:

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

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

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

   Ersetzen Sie Folgendes:

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

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

Google-Dienstkonto

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

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

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

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

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

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

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

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

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

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

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

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

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

Ersetzen Sie Folgendes:

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

Standardmäßiges Compute Engine-Dienstkonto

Wenn sich Ihr Repository in Cloud Source Repositories befindet und Ihr Cluster GKE mit deaktivierter Workload Identity Federation for GKE verwendet, können Sie gcenode als Authentifizierungstyp verwenden.

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

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

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

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

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

GitHub App

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

So verwenden Sie eine GitHub-App:

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

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

   Client-ID verwenden

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

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

   Anwendungs-ID verwenden

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

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

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

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

Kubernetes-Dienstkonto

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

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

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

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

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

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

   Ersetzen Sie Folgendes:

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

Google-Dienstkonto

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

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

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

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

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

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

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

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

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

Ersetzen Sie Folgendes:

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

Standardmäßiges Compute Engine-Dienstkonto

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

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

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

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

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

Token

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

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

Ersetzen Sie Folgendes:

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

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

Kubernetes-Dienstkonto

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

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

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

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

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

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

   Ersetzen Sie Folgendes:

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

Google-Dienstkonto

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

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

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

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

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

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

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

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

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

Ersetzen Sie Folgendes:

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

Standardmäßiges Compute Engine-Dienstkonto

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

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

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

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

nomos (empfohlen)

1. Prüfen Sie, ob die nomos CLI auf der neuesten Version ist.

2. Führen Sie den folgenden Befehl aus, um den Cluster in Ihrem aktuellen kubectl-Kontext zu aktualisieren:

   nomos migrate --remove-configmanagement
   

Shell-Skript

Kopieren Sie das folgende Shell-Script in eine Datei und führen Sie es aus, um den Cluster in Ihrem aktuellen kubectl-Kontext zu aktualisieren.

 #!/bin/bash

 set -euox pipefail

 hnc_enabled="$(kubectl get configmanagements.configmanagement.gke.io config-management -o=jsonpath="{.spec.hierarchyController.enabled}" --ignore-not-found)"

 if [[ "${hnc_enabled}" == "true" ]]; then
   echo "Hierarchy Controller is enabled on the ConfigManagement object. It must be disabled before migrating."
   echo "This can be done by unsetting the spec.hierarchyController field on ConfigManagement."
   exit 1
 fi

 kubectl delete deployment -n config-management-system config-management-operator --ignore-not-found --cascade=foreground

 if kubectl get configmanagement config-management &> /dev/null ; then
   kubectl patch configmanagement config-management --type="merge" -p '{"metadata":{"finalizers":[]}}'
   kubectl delete configmanagement config-management --cascade=orphan --ignore-not-found
 fi

 kubectl delete clusterrolebinding config-management-operator --ignore-not-found
 kubectl delete clusterrole config-management-operator --ignore-not-found
 kubectl delete serviceaccount -n config-management-system config-management-operator --ignore-not-found
 kubectl delete customresourcedefinition configmanagements.configmanagement.gke.io --ignore-not-found

1.20.0 oder höher

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

2. Extrahieren Sie das Archiv:

   tar -xzvf config-sync.tar.gz

3. Folgen Sie im im vorherigen Schritt extrahierten Archiv der Anleitung in der bereitgestellten README, um die Kustomisierung zu bearbeiten.

4. Um die Config Sync-Installation zu aktualisieren, wenden Sie das gerenderte Manifest an, das Sie gemäß der README-Anleitung erstellt haben:

   kubectl apply -f CONFIG_SYNC_MANIFEST
   

   Ersetzen Sie CONFIG_SYNC_MANIFEST durch den Namen des gerenderten Manifests.

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

1.19.2 oder niedriger

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

4. Übernehmen Sie die Änderung:

   kubectl apply -f config-management.yaml
   

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