Config Sync installieren
Mit Config Sync können Sie Kubernetes-Ressourcen mit Konfigurationsdateien verwalten, die in einer Source of Truth gespeichert sind. Config Sync unterstützt Git-Repositories, OCI-Images und Helm-Diagramme als „Source of Truth“. Auf dieser Seite erfahren Sie, wie Sie Config Sync aktivieren und konfigurieren, damit es aus Ihrem Stamm-Repository synchronisiert wird. Config Sync ist für die Google Kubernetes Engine (GKE) Enterprise-Version verfügbar.
Wenn Sie Config Sync mit der Google Cloud Console oder dem Google Cloud CLI installieren, sind die APIs RootSync
und RepoSync
standardmäßig aktiviert. Dies bietet zusätzliche Funktionen wie die Synchronisierung aus mehreren Repositories und die Synchronisierung von Kustomize- und Helm-Konfigurationen.
Hinweise
Bevor Sie Config Sync installieren, bereiten Sie Ihre Umgebung vor, achten Sie darauf, dass die Clusteranforderungen erfüllt werden, und gewähren Sie die richtigen Nutzerrollen.
Lokale Umgebung vorbereiten
Führen Sie die folgenden Schritte aus, um Ihre lokale Umgebung vorzubereiten:
- Erstelle eine „Source of Truth“ oder stelle sicher, dass du Zugriff darauf hast. Hier fügen Sie die Konfigurationen hinzu, mit denen Config Sync synchronisiert wird. Weitere Informationen zum Einrichten Ihrer Konfigurationen und der „Source of Truth“ finden Sie in einer der folgenden Anleitungen:
- Installieren und initialisieren Sie das Google Cloud CLI, das die Befehle
gcloud
undnomos
enthält. Wenn Sie Cloud Shell verwenden, ist das Google Cloud CLI vorinstalliert. Wenn Sie die Google Cloud CLI bereits installiert haben, können Sie mitgcloud components update
die neueste Version abrufen.
Clusteranforderungen
Erstellen Sie einen Cluster, der die folgenden Anforderungen erfüllt, oder haben Sie Zugriff darauf:
- Der Cluster befindet sich auf einer unterstützten Plattform und Version der Google Kubernetes Engine (GKE) Enterprise.
Wenn Sie Autopilot-Cluster verwenden, passt Autopilot die Anforderungen an Containerressourcen so an, dass sie die folgenden Regeln erfüllen:
- Ressourcenlimits sind auf Ressourcenanfragen festgelegt.
- Pod-vCPUs sind in Schritten von 0,25 vCPUs (aufgerundet) verfügbar.
- Der Mindestwert beträgt 250 MilliCPU (mCPU).
- Das Verhältnis von Arbeitsspeicher (in GiB) zu vCPU muss im Bereich von 1 bis 6,5 vCPU liegen.
Aufgrund dieser Regeln führt Config Sync für Autopilot-Cluster Folgendes aus:
- passt die Überschreibungslimits für benutzerdefinierte Ressourcen an die Anfragen an.
- wendet Überschreibungen nur an, wenn eine oder mehrere Ressourcenanfragen vorhanden sind, die höher sind als die entsprechende in der Annotation deklarierte Ausgabe, oder eine oder mehrere Ressourcenanfragen, die niedriger sind als die entsprechende Eingabe in der Annotation.
(Optional) Für den Cluster ist Workload Identity aktiviert, wenn Sie GKE-Cluster verwenden. Für das Aufrufen von Google Cloud-Diensten aus Anwendungen in GKE wird Workload Identity empfohlen, da dieses Feature bessere Sicherheitsmerkmale bietet und leichter zu verwalten ist. Für Autopilot-Cluster ist Workload Identity standardmäßig aktiviert.
Gewähren Sie die entsprechenden Berechtigungen zum Schreiben von Messwerten, damit Config Sync Messwerte an Cloud Monitoring senden kann. Das ist erforderlich, wenn Sie automatische Upgrades verwenden möchten.
Wenn Sie ein automatisches Upgrade der Config Sync-Version durchführen möchten, muss Ihr GKE-Cluster für eine Release-Version registriert sein. Ein Cluster, der keine GKE-Release-Versionen verwendet, wird wie ein Cluster mit der stabilen Release-Version behandelt.
Wenn Sie einen privaten GKE-Cluster verwenden möchten, konfigurieren Sie die Cloud NAT so, dass ausgehender Traffic von privaten GKE-Knoten zugelassen wird. Weitere Informationen finden Sie unter Beispielkonfiguration für GKE. Alternativ können Sie den privaten Google-Zugriff aktivieren, um eine Verbindung zu der Gruppe von externen IP-Adressen herzustellen, die von Google APIs und Google-Diensten verwendet werden.
Wenn Sie ein Google-Dienstkonto verwenden möchten, wenn Sie Config Sync Zugriff auf Ihre „Source of Truth“ gewähren, müssen Sie den schreibgeschützten Bereich in die Zugriffsbereiche für die Knoten im Cluster für Cloud Source Repositories aufnehmen.
Sie können den schreibgeschützten Bereich hinzufügen, indem Sie
cloud-source-repos-ro
in die Liste--scopes
aufnehmen, die beim Erstellen des Clusters angegeben wird, oder indem Sie den Bereichcloud-platform
beim Erstellen des Clusters verwenden. Beispiel:gcloud container clusters create CLUSTER_NAME --scopes=cloud-platform
Hinweis: Sie können Zugriffsbereiche nicht ändern, nachdem Sie einen Knotenpool erstellt haben. Allerdings haben Sie die Möglichkeit, unter Verwendung desselben Clusters einen neuen Knotenpool mit dem richtigen Zugriffsbereich zu erstellen. Der Standardbereich
gke-default
enthält nichtcloud-source-repos-ro
.Wenn Sie strenge VPC-Firewall-Anforderungen haben, die unnötigen Traffic blockieren, müssen Sie Firewallregeln erstellen, um den folgenden Traffic auf öffentlichen GKE-Clustern zuzulassen:
TCP: Eingehenden und ausgehenden Traffic an Port 53 und 443 zulassen
UDP: Erlauben Sie ausgehenden Traffic an Port 53.
Wenn Sie diese Regeln nicht angeben, wird Config Sync nicht korrekt synchronisiert.
nomos status
meldet den folgenden Fehler:Error: KNV2004: unable to sync repo Error in the git-sync container
Sie können diese Schritte überspringen, wenn Sie einen privaten GKE-Cluster verwenden.
Sie müssen Config Sync für einen Knotenpool vom Typ
amd64
ausführen. Die Container-Images von Config Sync-Back-End-Komponenten werden nur für die Maschinenarchitektur vonamd64
erstellt, verteilt und getestet. Wenn eine Config Sync-Komponente auf einem Arm-Knoten geplant ist, tritt der Fehlerexec format
auf und stürzt ab.Wenn Ihr Cluster Arm-Knoten enthält, fügen Sie dem Cluster einen oder mehrere amd64-Knoten hinzu. Wenn Sie keinen GKE-Cluster verwenden, fügen Sie den arm64-Knoten eine Markierung hinzu, um zu vermeiden, dass Pods auf den arm64-Knoten ohne spezielle Toleranz geplant werden. Knoten der GKE-Verzweigung haben bereits eine Standardmarkierung, sodass Sie keine hinzufügen müssen.
Cluster vorbereiten
Führen Sie die folgenden Schritte aus, nachdem Sie einen geeigneten Cluster erstellt haben:
Weisen Sie dem Nutzer die für die Registrierung des Clusters erforderlichen IAM-Rollen zu.
Wenn Sie die Google Cloud CLI zum Konfigurieren von Config Sync verwenden oder Cluster außerhalb von Google Cloud verwenden möchten, müssen Ihre GKE-Cluster oder Cluster außerhalb von Google Cloud jetzt bei einer Flotte registriert sein. Wenn Sie die Google Cloud Console verwenden möchten, können Sie GKE-Cluster beim Konfigurieren von Config Sync registrieren.
Config Sync installieren
In den folgenden Abschnitten gewähren Sie Config Sync Zugriff auf eine der folgenden Informationsquellen:
Nachdem Sie den Zugriff gewährt haben, können Sie Config Sync konfigurieren.
Zugriff auf Git gewähren
Config Sync benötigt Lesezugriff auf Ihr Git-Repository, damit es die Konfigurationen, die Sie per Commit in das Repository geschrieben haben, lesen und auf Ihre Cluster anwenden kann.
Falls für den Lesezugriff auf Ihr Repository keine Authentifizierung erforderlich ist, können Sie mit der Konfiguration von Config Sync fortfahren und none
als Authentifizierungstyp verwenden. Wenn Sie beispielsweise das Repository über eine Weboberfläche durchsuchen können, ohne sich anzumelden, oder git
clone
verwenden können, um einen Klon des Repositorys lokal zu erstellen, ohne Anmeldedaten anzugeben oder gespeicherte Anmeldedaten zu verwenden, ist keine Authentifizierung erforderlich. In diesem Fall müssen Sie kein Secret erstellen.
Die meisten Nutzer müssen jedoch Anmeldedaten erstellen, da der Lesezugriff auf ihr Repository eingeschränkt ist. Wenn Anmeldedaten erforderlich sind, werden diese auf jedem registrierten Cluster im git-creds
-Secret gespeichert, sofern Sie kein Google-Dienstkonto verwenden. Das Secret muss den Namen git-creds
haben, da dies ein fester Wert ist.
Config Sync unterstützt die folgenden Authentifizierungsmechanismen:
- SSH-Schlüsselpaar (
ssh
) - Cookiedatei (
cookiefile
) - Token (
token
) - Google-Dienstkonto (
gcpserviceaccount
) - Standardmäßiges Compute Engine-Dienstkonto (
gcenode
)
Welchen Mechanismus Sie wählen, hängt davon ab, was Ihr Repository unterstützt. Im Allgemeinen empfehlen wir die Verwendung eines SSH-Schlüsselpaars. GitHub und Bitbucket unterstützen beide die Verwendung eines SSH-Schlüsselpaars. Wenn Sie jedoch ein Repository in Cloud Source Repositories verwenden, empfehlen wir stattdessen die Verwendung eines Google-Dienstkontos. Wenn Ihr Repository von Ihrer Organisation gehostet wird und Sie nicht wissen, welche Authentifizierungsmethoden unterstützt werden, wenden Sie sich an Ihren Administrator.
Wenn Sie ein Repository in Cloud Source Repositories als Config Sync-Repository verwenden möchten, führen Sie die folgenden Schritte aus, um Ihre Cloud Source Repositories-URL abzurufen:
Listen Sie alle Repositories auf:
gcloud source repos list
Kopieren Sie aus der Ausgabe die URL des Repositorys, das Sie verwenden möchten. Beispiel:
REPO_NAME PROJECT_ID URL my-repo my-project https://source.developers.google.com/p/my-project/r/my-repo-csr
Sie benötigen diese URL bei der Konfiguration von Config Sync im folgenden Abschnitt. Wenn Sie Config Sync über die Google Cloud Console konfigurieren, fügen Sie die URL in das Feld URL ein. Wenn Sie Config Sync mithilfe des Google Cloud CLI konfigurieren, fügen Sie die URL dem Feld
syncRepo
Ihrer Konfigurationsdatei hinzu.
SSH-Schlüsselpaar
Ein SSH-Schlüsselpaar besteht aus zwei Dateien, einem öffentlichen und einem privaten Schlüssel. Der öffentliche Schlüssel hat in der Regel die Erweiterung .pub
.
Führen Sie die folgenden Schritte aus, um ein SSH-Schlüsselpaar zu verwenden:
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.
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
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
).(Empfohlen) Wenn Sie die Prüfung von bekannten Hosts mithilfe der SSH-Authentifizierung konfigurieren möchten, können Sie den Schlüssel der bekannten Hosts dem Feld
data.known_hosts
im Secretgit_creds
hinzufügen. Wenn Sie dieknown_hosts
-Prüfung deaktivieren möchten, können Sie das Feldknown_hosts
aus dem Secret entfernen. Führen Sie folgenden Befehl aus, um den Schlüssel des bekannten Hosts hinzuzufügen:kubectl edit secret git-creds \ --namespace=config-management-system
Fügen Sie dann unter
data
den Eintrag des bekannten Hosts hinzu:known_hosts: KNOWN_HOSTS_KEY
Löschen Sie den privaten Schlüssel vom lokalen Datenträger oder schützen Sie ihn anderweitig.
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:
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 DateinameHTTPS_PROXY_URL
: Die URL für den HTTPS-Proxy, den Sie bei der Kommunikation mit dem Git-Repository verwenden.
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:
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 Ihr PAT an den Computernutzer binden. - GitLab Erstellen Sie ein PAT oder Erstellen Sie ein Bereitstellungstoken.
- Bitbucket: Erstellen Sie ein App-Passwort.
- GitHub: Erstellen Sie ein PAT. Gewähren Sie dem Token den Bereich
Nachdem Sie das Token erstellt und abgerufen haben, fügen Sie es einem neuen Secret im Cluster hinzu.
Wenn Sie keinen HTTPS-Proxy verwenden, erstellen Sie das Secret mit dem folgenden Befehl:
kubectl create ns config-management-system && \ kubectl create secret generic git-creds \ --namespace="config-management-system" \ --from-literal=username=USERNAME \ --from-literal=token=TOKEN
Dabei gilt:
USERNAME
: Nutzername, den Sie verwenden möchten.TOKEN
: Token, das Sie im vorherigen Schritt erstellt haben.
Wenn Sie einen HTTPS-Proxy verwenden müssen, fügen Sie ihn zusammen mit
username
undtoken
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.
Schützen Sie das Token, wenn Sie es noch lokal benötigen. Andernfalls können Sie es löschen.
Google-Dienstkonto
Wenn sich Ihr Repository in Cloud Source Repositories befindet und Ihr Cluster GKE Workload Identity oder Workload Identity für die Flotte verwendet, können Sie Config Sync Zugriff auf ein Repository im selben Projekt wie Ihr verwalteter Cluster gewähren. Verwenden Sie dazu ein Google-Dienstkonto.
Wenn Sie noch kein Dienstkonto haben, erstellen Sie eines.
Weisen Sie dem Google-Dienstkonto die IAM-Rolle „Cloud Source Repositories-Leser“ (
roles/source.reader
) zu. Weitere Informationen zu Rollen und Berechtigungen für Cloud Source Repositories finden Sie unter Berechtigungen zum Ansehen von Repositories erteilen.Erteilen Sie projektweite Berechtigungen, wenn dieselben Berechtigungen für alle Repositories im Projekt gelten.
gcloud projects add-iam-policy-binding PROJECT_ID \ --role=roles/source.reader \ --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
Erteilen Sie eine Repository-spezifische Berechtigung, wenn Dienstkonten unterschiedliche Zugriffsebenen für jedes Repository in Ihrem Projekt haben sollen.
gcloud source repos set-iam-policy REPOSITORY POLICY_FILE --project=PROJECT_ID
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
alssecretType
hinzu und fügen Sie dann die E-Mail-Adresse Ihres Dienstkontos zugcpServiceAccountEmail
hinzu.Erstellen Sie nach der Konfiguration von Config Sync eine IAM-Richtlinienbindung zwischen dem Kubernetes-Dienstkonto und dem Google-Dienstkonto. Das Kubernetes-Dienstkonto wird erst erstellt, wenn Sie Config Sync zum ersten Mal konfigurieren.
Wenn Sie Cluster verwenden, die bei einer Flotte registriert sind, müssen Sie die Richtlinienbindung nur einmal pro Flotte erstellen. Alle in einer Flotte registrierten Cluster haben denselben Workload Identity-Pool. Gemäß dem Konzept der Gleichheit der Flotte erhält das Kubernetes-Dienstkonto aus demselben Namespace auf anderen Clustern in derselben Flotte dieselbe IAM-Richtlinie, wenn Sie Ihrem Kubernetes-Dienstkonto die IAM-Richtlinie in einem Cluster hinzufügen.
Durch diese Bindung kann das Kubernetes-Dienstkonto von Config Sync als Google-Dienstkonto verwendet werden:
gcloud iam service-accounts add-iam-policy-binding \ GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/iam.workloadIdentityUser \ --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \ --project=PROJECT_ID
Ersetzen Sie Folgendes:
PROJECT_ID
: Projekt-ID der OrganisationFLEET_HOST_PROJECT_ID
: Wenn Sie GKE Workload Identity verwenden, entspricht diesPROJECT_ID
. Wenn Sie Workload Identity für die Flotte verwenden, ist dies die Projekt-ID der Flotte, bei der Ihr Cluster registriert ist.GSA_NAME
: das benutzerdefinierte Google-Dienstkonto, das Sie zum Herstellen einer Verbindung zu Artifact Registry verwenden möchten. Das Dienstkonto muss die IAM-Rolle „Artifact Registry-Leser“ (roles/artifactregistry.reader
) haben.KSA_NAME
: das Kubernetes-Dienstkonto für den Abgleich.- Wenn der
RootSync
-Name bei Root-Repositoriesroot-sync
lautet, verwenden Sieroot-reconciler
. Andernfalls verwenden Sieroot-reconciler-ROOT_SYNC_NAME
. Wenn Sie Config Sync über die Google Cloud Console oder die Google Cloud CLI installieren, erstellt Config Sync automatisch ein RootSync-Objekt mit dem Namenroot-sync
.
- Wenn der
REPOSITORY
: der Name des Repositorys.POLICY_FILE
: die JSON- oder YAML-Datei mit der Richtlinie zu Identity and Access Management.
Standardmäßiges Compute Engine-Dienstkonto
Wenn sich Ihr Repository in Cloud Source Repositories befindet und Ihr Cluster GKE in Google Cloud ist und Workload Identity deaktiviert ist, können Sie gcenode
als Authentifizierungstyp verwenden.
Wenn Sie Config Sync mit der Google Cloud Console konfigurieren, wählen Sie als Authentifizierungstyp Google Cloud Repository aus.
Wenn Sie Config Sync über die Google Cloud CLI konfigurieren, fügen Sie gcenode
als secretType
hinzu.
Wenn Sie entweder Google Cloud Repository oder gcenode
auswählen, können Sie das Compute Engine-Standarddienstkonto verwenden. Sie müssen dem Compute Engine-Standarddienstkonto die IAM-Rolle „Cloud Source Repositories-Leser“ (roles/source.reader
) zuweisen. Weitere Informationen zu Rollen und Berechtigungen für Cloud Source Repositories finden Sie unter Berechtigungen zum Ansehen von Repositories erteilen.
gcloud projects add-iam-policy-binding PROJECT_ID \
--role=roles/source.reader \
--member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"
Ersetzen Sie PROJECT_ID
durch die Projekt-ID Ihrer Organisation und PROJECT_NUMBER
durch die Projektnummer Ihrer Organisation.
Config Sync Lesezugriff auf OCI gewähren
Config Sync benötigt Lesezugriff auf das in Artifact Registry gespeicherte OCI-Image, damit die im Image enthaltenen Konfigurationen gelesen und auf Ihre Cluster angewendet werden können.
Falls für den Lesezugriff auf Ihr Image keine Authentifizierung erforderlich ist, können Sie mit der Konfiguration von Config Sync fortfahren und none
als Authentifizierungstyp verwenden. Wenn Ihr Image beispielsweise öffentlich ist und jeder im Internet darauf zugreifen kann, müssen Sie sich nicht authentifizieren.
Die meisten Nutzer müssen jedoch Anmeldedaten erstellen, um auf eingeschränkte Images zuzugreifen. Config Sync unterstützt die folgenden Authentifizierungsmechanismen:
- Kubernetes-Dienstkonto (
k8sserviceaccount
) - Google-Dienstkonto (
gcpserviceaccount
) Standardmäßiges Compute Engine-Dienstkonto (
gcenode
)
Kubernetes-Dienstkonto
Wenn Sie das OCI-Image in Artifact Registry speichern und Ihr Cluster GKE Workload Identity oder die Workload Identity für die Flotte verwendet, können Sie in Version 1.17.2 und höher k8sserviceaccount
als Authentifizierungstyp verwenden. Diese Option wird aufgrund des vereinfachten Konfigurationsprozesses gegenüber gcpserviceaccount
empfohlen.
Weisen Sie dem Kubernetes-Dienstkonto mit dem Workload Identity-Pool die IAM-Rolle „Artifact Registry-Leser“ (
roles/artifactregistry.reader
) zu. Weitere Informationen zu Artifact Registry-Rollen und -Berechtigungen finden Sie unter Rollen und Berechtigungen für Artifact Registry konfigurieren.Erteilen Sie projektweite Berechtigungen, wenn dieselben Berechtigungen für alle Repositories im Projekt gelten.
gcloud projects add-iam-policy-binding PROJECT_ID \ --role=roles/artifactregistry.reader \ --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
Erteilen Sie eine Repository-spezifische Berechtigung, wenn Dienstkonten unterschiedliche Zugriffsebenen für jedes Repository in Ihrem Projekt haben sollen.
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \ --location=LOCATION \ --role=roles/artifactregistry.reader \ --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \ --project=PROJECT_ID
Ersetzen Sie Folgendes:
PROJECT_ID
: Projekt-ID der OrganisationFLEET_HOST_PROJECT_ID
: Wenn Sie GKE Workload Identity verwenden, entspricht diesPROJECT_ID
. Wenn Sie Workload Identity für die Flotte verwenden, ist dies die Projekt-ID der Flotte, bei der Ihr Cluster registriert ist.KSA_NAME
: das Kubernetes-Dienstkonto für den Abgleich.- Wenn der
RootSync
-Name bei Root-Repositoriesroot-sync
lautet, verwenden Sieroot-reconciler
. Andernfalls verwenden Sieroot-reconciler-ROOT_SYNC_NAME
. Wenn Sie Config Sync über die Google Cloud Console oder die Google Cloud CLI installieren, erstellt Config Sync automatisch ein RootSync-Objekt mit dem Namenroot-sync
.
- Wenn der
REPOSITORY
: die ID des Repositorys.LOCATION
: der regionale oder multiregionale Standort des Repositorys.
Google-Dienstkonto
Wenn Sie das OCI-Image in Artifact Registry speichern und Ihr Cluster GKE Workload Identity oder die Workload Identity für die Flotte verwendet, können Sie gcpserviceaccount
als Authentifizierungstyp verwenden. Ab Version 1.17.2 wird empfohlen, stattdessen k8sserviceaccount
zu verwenden. Mit dieser Option entfallen die zusätzlichen Schritte zum Erstellen eines Google-Dienstkontos und der zugehörigen IAM-Richtlinienbindung.
Wenn Sie noch kein Dienstkonto haben, erstellen Sie eines.
Weisen Sie dem Google-Dienstkonto die IAM-Rolle „Artifact Registry-Leser“ (
roles/artifactregistry.reader
) zu. Weitere Informationen zu Artifact Registry-Rollen und -Berechtigungen finden Sie unter Rollen und Berechtigungen für Artifact Registry konfigurieren.Erteilen Sie projektweite Berechtigungen, wenn dieselben Berechtigungen für alle Repositories im Projekt gelten.
gcloud projects add-iam-policy-binding PROJECT_ID \ --role=roles/artifactregistry.reader \ --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
Erteilen Sie eine Repository-spezifische Berechtigung, wenn Dienstkonten unterschiedliche Zugriffsebenen für jedes Repository in Ihrem Projekt haben sollen.
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \ --location=LOCATION \ --role=roles/artifactregistry.reader \ --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \ --project=PROJECT_ID
Erstellen Sie mit dem folgenden Befehl eine IAM-Richtlinienbindung zwischen dem Kubernetes-Dienstkonto und dem Google-Dienstkonto:
gcloud iam service-accounts add-iam-policy-binding GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/iam.workloadIdentityUser \ --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \ --project=PROJECT_ID
Ersetzen Sie Folgendes:
PROJECT_ID
: Projekt-ID der OrganisationFLEET_HOST_PROJECT_ID
: Wenn Sie GKE Workload Identity verwenden, entspricht diesPROJECT_ID
. Wenn Sie Workload Identity für die Flotte verwenden, ist dies die Projekt-ID der Flotte, bei der Ihr Cluster registriert ist.GSA_NAME
: das benutzerdefinierte Google-Dienstkonto, das Sie zum Herstellen einer Verbindung zu Artifact Registry verwenden möchten. Das Dienstkonto muss die IAM-Rolle „Artifact Registry-Leser“ (roles/artifactregistry.reader
) haben.KSA_NAME
: das Kubernetes-Dienstkonto für den Abgleich.- Wenn der
RootSync
-Name bei Root-Repositoriesroot-sync
lautet, verwenden Sieroot-reconciler
. Andernfalls verwenden Sieroot-reconciler-ROOT_SYNC_NAME
. Wenn Sie Config Sync über die Google Cloud Console oder die Google Cloud CLI installieren, erstellt Config Sync automatisch ein RootSync-Objekt mit dem Namenroot-sync
.
- Wenn der
REPOSITORY
: die ID des Repositorys.LOCATION
: der regionale oder multiregionale Standort des Repositorys.
Standardmäßiges Compute Engine-Dienstkonto
Wenn Sie Ihr Helm-Diagramm in Artifact Registry speichern und Ihr Cluster GKE in Google Cloud ist und Workload Identity deaktiviert ist, können Sie gcenode
als Authentifizierungstyp verwenden.
Config Sync verwendet das Compute Engine-Standarddienstkonto.
Sie müssen Ihrem Compute Engine-Standarddienstkonto Lesezugriff auf Artifact Registry gewähren.
Gewähren Sie dem Compute Engine-Dienstkonto die Leseberechtigung für Artifact Registry, indem Sie den folgenden Befehl ausführen:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \ --role=roles/artifactregistry.reader
Ersetzen Sie
PROJECT_ID
durch die Projekt-ID Ihrer Organisation undPROJECT_NUMBER
durch die Projektnummer Ihrer Organisation.
Config Sync Lesezugriff auf Helm gewähren
Config Sync benötigt Lesezugriff auf Ihr Helm-Repository, damit die Helm-Diagramme in Ihrem Repository gelesen und in Ihren Clustern installiert werden können.
Wenn für den Lesezugriff auf Ihr Repository keine Authentifizierung erforderlich ist, können Sie mit der Konfiguration von Config Sync fortfahren und none
als Authentifizierungstyp verwenden. Wenn Ihr Helm-Repository beispielsweise öffentlich ist und von jedem über das Internet aufgerufen werden kann, müssen Sie sich nicht authentifizieren.
Die meisten Nutzer müssen jedoch Anmeldedaten erstellen, um auf private Helm-Repositories zugreifen zu können. Config Sync unterstützt die folgenden Authentifizierungsmechanismen:
- Token (
token
) - Kubernetes-Dienstkonto (
k8sserviceaccount
) - Google-Dienstkonto (
gcpserviceaccount
) - Standardmäßiges Compute Engine-Dienstkonto (
gcenode
)
Token
Erstellen Sie ein Secret mit einem Nutzernamen und einem Passwort für das Helm-Repository:
kubectl create secret generic SECRET_NAME \
--namespace=config-management-system \
--from-literal=username=USERNAME \
--from-literal=password=PASSWORD
Ersetzen Sie Folgendes:
SECRET_NAME
ist der Name, den Sie dem Secret geben möchten.USERNAME
: der Nutzername des Helm-Repositorys.PASSWORD
: das Passwort des Helm-Repositorys
Wenn Sie den ConfigManagement Operator konfigurieren, verwenden Sie den Secret-Namen, den Sie für spec.helm.secretRef.name
ausgewählt haben.
Kubernetes-Dienstkonto
Wenn Sie Ihr Helm-Diagramm in Artifact Registry speichern und Ihr Cluster GKE Workload Identity oder die Workload Identity für die Flotte verwendet, können Sie in Version 1.17.2 und höher k8sserviceaccount
als Authentifizierungstyp verwenden. Diese Option wird aufgrund des vereinfachten Konfigurationsprozesses gegenüber gcpserviceaccount
empfohlen.
Weisen Sie dem Kubernetes-Dienstkonto mit dem Workload Identity-Pool die IAM-Rolle „Artifact Registry-Leser“ (
roles/artifactregistry.reader
) zu. Weitere Informationen zu Artifact Registry-Rollen und -Berechtigungen finden Sie unter Rollen und Berechtigungen für Artifact Registry konfigurieren.Erteilen Sie projektweite Berechtigungen, wenn dieselben Berechtigungen für alle Repositories im Projekt gelten.
gcloud projects add-iam-policy-binding PROJECT_ID \ --role=roles/artifactregistry.reader \ --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
Erteilen Sie eine Repository-spezifische Berechtigung, wenn Dienstkonten unterschiedliche Zugriffsebenen für jedes Repository in Ihrem Projekt haben sollen.
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \ --location=LOCATION \ --role=roles/artifactregistry.reader \ --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \ --project=PROJECT_ID
Ersetzen Sie Folgendes:
PROJECT_ID
: Projekt-ID der OrganisationFLEET_HOST_PROJECT_ID
: Wenn Sie GKE Workload Identity verwenden, entspricht diesPROJECT_ID
. Wenn Sie Workload Identity für die Flotte verwenden, ist dies die Projekt-ID der Flotte, bei der Ihr Cluster registriert ist.KSA_NAME
: das Kubernetes-Dienstkonto für den Abgleich.- Wenn der
RootSync
-Name bei Root-Repositoriesroot-sync
lautet, verwenden Sieroot-reconciler
. Andernfalls verwenden Sieroot-reconciler-ROOT_SYNC_NAME
.
- Wenn der
REPOSITORY
: die ID des Repositorys.LOCATION
: der regionale oder multiregionale Standort des Repositorys.
Google-Dienstkonto
Wenn Sie Ihr Helm-Diagramm in Artifact Registry speichern und Ihr Cluster GKE Workload Identity oder Workload Identity für die Flotte verwendet, können Sie gcpserviceaccount
als Authentifizierungstyp verwenden. Ab Version 1.17.2 wird empfohlen, stattdessen k8sserviceaccount
zu verwenden. Mit dieser Option entfallen die zusätzlichen Schritte zum Erstellen eines Google-Dienstkontos und der zugehörigen IAM-Richtlinienbindung.
Wenn Sie noch kein Dienstkonto haben, erstellen Sie eines.
Weisen Sie dem Google-Dienstkonto die IAM-Rolle „Artifact Registry-Leser“ (
roles/artifactregistry.reader
) zu. Weitere Informationen zu Artifact Registry-Rollen und -Berechtigungen finden Sie unter Rollen und Berechtigungen für Artifact Registry konfigurieren.Erteilen Sie projektweite Berechtigungen, wenn dieselben Berechtigungen für alle Repositories im Projekt gelten.
gcloud projects add-iam-policy-binding PROJECT_ID \ --role=roles/artifactregistry.reader \ --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
Erteilen Sie eine Repository-spezifische Berechtigung, wenn Dienstkonten unterschiedliche Zugriffsebenen für jedes Repository in Ihrem Projekt haben sollen.
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \ --location=LOCATION \ --role=roles/artifactregistry.reader \ --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \ --project=PROJECT_ID
Erstellen Sie mit dem folgenden Befehl eine IAM-Richtlinienbindung zwischen dem Kubernetes-Dienstkonto und dem Google-Dienstkonto:
gcloud iam service-accounts add-iam-policy-binding GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/iam.workloadIdentityUser \ --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" --project=PROJECT_ID
Ersetzen Sie Folgendes:
PROJECT_ID
: Projekt-ID der OrganisationFLEET_HOST_PROJECT_ID
: Wenn Sie GKE Workload Identity verwenden, entspricht diesPROJECT_ID
. Wenn Sie Workload Identity für die Flotte verwenden, ist dies die Projekt-ID der Flotte, bei der Ihr Cluster registriert ist.GSA_NAME
: das benutzerdefinierte Google-Dienstkonto, das Sie zum Herstellen einer Verbindung zu Artifact Registry verwenden möchten. Das Dienstkonto muss die IAM-Rolle „Artifact Registry-Leser“ (roles/artifactregistry.reader
) haben.KSA_NAME
: das Kubernetes-Dienstkonto für den Abgleich.- Wenn der
RootSync
-Name bei Root-Repositoriesroot-sync
lautet, verwenden Sieroot-reconciler
. Andernfalls verwenden Sieroot-reconciler-ROOT_SYNC_NAME
.
- Wenn der
REPOSITORY
: die ID des Repositorys.LOCATION
: der regionale oder multiregionale Standort des Repositorys.
Standardmäßiges Compute Engine-Dienstkonto
Wenn Sie Ihr Helm-Diagramm in Artifact Registry speichern und Ihr Cluster GKE in Google Cloud ist und Workload Identity deaktiviert ist, können Sie gcenode
als Authentifizierungstyp verwenden.
Config Sync verwendet das Compute Engine-Standarddienstkonto.
Sie müssen Ihrem Compute Engine-Standarddienstkonto Lesezugriff auf Artifact Registry gewähren. Möglicherweise müssen Sie den Zugriffsbereich storage-ro
gewähren, um eine Leseberechtigung zum Abrufen von Images zu gewähren.
Gewähren Sie dem Compute Engine-Dienstkonto Leseberechtigung für Artifact Registry:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \ --role=roles/artifactregistry.reader
Ersetzen Sie
PROJECT_ID
durch die Projekt-ID Ihrer Organisation undPROJECT_NUMBER
durch die Projektnummer Ihrer Organisation.
Config Sync konfigurieren
In diesem Abschnitt konfigurieren Sie die Einstellungen für Ihr Stamm-Repository. Wenn Sie eine Synchronisierung mit einem Git-Repository durchführen, können Sie die Google Cloud Console verwenden, um Sie durch den Installationsprozess zu führen und einige Schritte zu automatisieren.
Wenn Sie Config Sync über die Google Cloud Console oder die Google Cloud CLI installieren, erstellt Config Sync automatisch ein RootSync-Objekt mit dem Namen root-sync
. Mit kubectl
-Befehlen können Sie root-sync
ändern und zusätzliche Config Sync-Konfigurationen hinzufügen. Weitere Informationen finden Sie unter Config Sync mit kubectl
-Befehlen konfigurieren.
Console
Config Sync installieren
Zum Installieren von Config Sync müssen alle Cluster bei einer Flotte registriert sein. Wenn Sie Config Sync in der Google Cloud Console installieren, werden durch die Auswahl einzelner Cluster diese Cluster automatisch bei Ihrer Flotte registriert.
- Rufen Sie in der Google Cloud Console im Bereich Features die Seite Konfiguration auf.
- Klicken Sie auf add Config Sync installieren.
- Wählen Sie Automatische Upgrades (Vorschau) aus, damit Config Sync Versionen automatisch upgraden kann, oder wählen Sie Manuelle Upgrades aus, um die Config Sync-Version selbst zu verwalten. Weitere Informationen zur Funktionsweise automatischer Upgrades finden Sie unter Config Sync upgraden.
- Wählen Sie unter Installationsoptionen eine der folgenden Optionen aus:
- Config Sync in der gesamten Flotte installieren (empfohlen): Config Sync wird auf allen Clustern in der Flotte installiert.
- Config Sync auf einzelnen Clustern installieren: Alle ausgewählten Cluster werden automatisch bei einer Flotte registriert. Config Sync wird auf allen Clustern in der Flotte installiert.
- Wenn Sie Config Sync auf einzelnen Clustern installieren, wählen Sie in der Tabelle Verfügbare Cluster die Cluster aus, auf denen Sie Config Sync installieren möchten.
- Klicken Sie auf Config Sync installieren. Nach einigen Minuten sollte auf dem Tab Einstellungen in der Spalte Status für die Cluster in Ihrer Flotte Aktiviert angezeigt werden.
Paket bereitstellen
Nachdem Sie Ihre Cluster registriert haben, können Sie ein Paket aus einer Source of Truth in Ihrem Config Sync-Cluster bereitstellen. Sie können ein Paket in mehreren Clustern gleichzeitig bereitstellen und mehrere Pakete zu einem einzigen Cluster hinzufügen.
Führen Sie die folgenden Schritte aus, um ein Paket bereitzustellen:
Rufen Sie in der Google Cloud Console das Config Sync-Dashboard auf.
Klicken Sie auf Paket bereitstellen.
Wählen Sie in der Tabelle Cluster für Paketbereitstellung auswählen den Cluster aus, für den Sie ein Paket bereitstellen möchten, und klicken Sie dann auf Weiter.
Wählen Sie entweder Auf Git gehostetes Paket oder Auf OCI gehostetes Paket als Quelltyp aus und klicken Sie dann auf Weiter.
Geben Sie im Bereich Paketdetails einen Paketnamen ein, der das RootSync- oder RepoSync-Objekt identifiziert.
Führen Sie im Abschnitt Source (Quelle) folgende Schritte aus:
Geben Sie für Quellen, die in einem Git-Repository gehostet werden, die folgenden Felder ein:
- Geben Sie einen Paketnamen ein, der das RootSync- oder RepoSync-Objekt identifiziert.
- Geben Sie die URL des Git-Repositorys, das Sie als „Source of Truth“ verwenden, als Repository-URL ein.
- Optional: Aktualisieren Sie das Feld Revision, um zu prüfen, ob Sie nicht den Standardwert
HEAD
verwenden. - Optional: Aktualisieren Sie das Feld Pfad, wenn Sie nicht vom Root-Repository synchronisieren möchten.
- Optional: Aktualisieren Sie das Feld Zweig, wenn Sie nicht den Standardzweig
main
verwenden.
Geben Sie für Quellen, die in einem OCI-Image gehostet werden, die folgenden Felder ein:
- Geben Sie unter Image die URL des OCI-Images ein, das Sie als „Source of Truth“ verwenden.
- Geben Sie unter Verzeichnis den Pfad des Verzeichnisses relativ zum Stammverzeichnis für die Synchronisierung ein.
Wählen Sie im Feld Synchronisierungstyp entweder RootSync oder RepoSync als Synchronisierungstyp aus.
RootSync-Objekte sind clusterbezogen und RepoSync-Objekte sind Namespace-bezogen. Weitere Informationen zu diesen Objekten finden Sie unter RootSync- und RepoSync-Felder.
(Optional): Maximieren Sie den Abschnitt Erweiterte Einstellungen, um Folgendes zu tun:
Wählen Sie einen Authentifizierungstyp aus:
- Keine: Keine Authentifizierung verwenden.
- SSH: Ein SSH-Schlüsselpaar verwenden.
- Cookiefile: Ein
cookiefile
verwenden. - Token: Ein Token verwenden.
- Google Cloud Repository: Ein Google-Dienstkonto verwenden, um auf ein Repository in Cloud Source Repository zuzugreifen. Wählen Sie diese Option nur aus, wenn Workload Identity in Ihrem Cluster nicht aktiviert ist.
- Workload Identity: Verwenden Sie ein Google-Dienstkonto, um auf ein Cloud Source Repositories-Repository zuzugreifen.
Geben Sie eine Zahl in Sekunden ein, um die Synchronisierungswartezeit festzulegen. Dadurch wird bestimmt, wie lange Config Sync zwischen der Synchronisierung über die „Source of Truth“ wartet.
Geben Sie eine Git-Proxy-URL für den HTTPS-Proxy ein, der bei der Kommunikation mit der „Source of Truth“ verwendet werden soll.
Wählen Sie Hierarchie aus, um das Quellformat zu ändern.
Der Standardwert Unstructured (Unstrukturiert) wird in den meisten Fällen empfohlen, da Sie Ihre Source of Truth nach Belieben organisieren können.
Klicken Sie auf Paket bereitstellen.
Sie werden zur Config Sync-Seite Pakete weitergeleitet. Nach einigen Minuten sollte in der Spalte Synchronisierungsstatus für den von Ihnen konfigurierten Cluster Synchronisiert angezeigt werden.
Maximieren Sie zum Aktualisieren eines Pakets auf dem Tab Pakete den Paketnamen, den Sie bearbeiten möchten, und klicken Sie dann auf edit Bearbeiten.
gcloud
Bevor Sie fortfahren, müssen Sie Ihre Cluster bei einer Flotte registrieren.
Aktivieren Sie das Flottenfeature
ConfigManagement
:gcloud beta container fleet config-management enable
Bereiten Sie die Konfiguration vor, indem Sie entweder ein neues
apply-spec.yaml
-Manifest erstellen oder ein vorhandenes Manifest verwenden. Mit einem vorhandenen Manifest können Sie den Cluster mit denselben Einstellungen konfigurieren, die auch von einem anderen Cluster verwendet werden.Neues Manifest erstellen
Erstellen Sie eine Datei mit dem Namen
apply-spec.yaml
und kopieren Sie die folgende YAML-Datei in diese Datei, um Config Sync mit neuen Einstellungen für Ihren Cluster zu konfigurieren.Sie können alle optionalen
spec.configSync
-Felder festlegen, die Sie beim Erstellen des Manifests benötigen, und späterkubectl
-Befehle zur Konfiguration verwenden. Sie können das Feldspec.configSync.enabled
auch alstrue
festlegen und die optionalen Felder weglassen. Sie können dann späterkubectl
-Befehle verwenden, um zusätzliche RootSync-Objekte oder RepoSyncs zu erstellen, die Sie später vollständig mitkubectl
-Befehlen verwalten können.# apply-spec.yaml applySpecVersion: 1 spec: # upgrades: UPGRADE_SETTING configSync: # Set to true to install and enable Config Sync enabled: true # If you don't have a source of truth yet, omit the # following fields. You can configure them later. sourceType: SOURCE_TYPE sourceFormat: FORMAT syncRepo: REPO syncRev: REVISION syncBranch: BRANCH secretType: SECRET_TYPE gcpServiceAccountEmail: EMAIL metricsGcpServiceAccountEmail: METRICS_EMAIL policyDir: DIRECTORY preventDrift: PREVENT_DRIFT
Ersetzen Sie Folgendes:
(Vorschau)
UPGRADE_SETTING
: Entfernen Sie die Kommentarzeichen im Feld und legen Sie aufauto
fest, um Config Sync für das automatische Upgrade zu konfigurieren. Legen Siemanual
fest, um Config Sync manuell zu aktualisieren. Der Standardwert istmanual
. Dieses Flag wird nur für GKE on Google Cloud-Cluster unterstützt. Damit Sie dieses Feld verwenden können, müssen Sie möglicherweise die gcloud CLI mitgcloud components update
aktualisieren.SOURCE_TYPE
: Fügen Siegit
für die Synchronisierung aus einem Git-Repository,oci
für die Synchronisierung aus einem OCI-Image oderhelm
für die Synchronisierung aus einem Helm-Diagramm hinzu. Wenn kein Wert angegeben wird, wird der Standardwertgit
verwendet.FORMAT
: Fügen Sieunstructured
hinzu, um ein unstrukturiertes Repository zu verwenden, oder fügen Siehierarchy
hinzu, um ein hierarchisches Repository zu verwenden. Bei diesen Werten wird zwischen Groß- und Kleinschreibung unterschieden. Dieses Feld ist optional und der Standardwert isthierarchy
. Wir empfehlen das Hinzufügen vonunstructured
, da Sie mit diesem Format Ihre Konfigurationen so organisieren können, wie es für Sie am besten ist.REPO
: Fügen Sie die URL der „Source of Truth“ hinzu. Git- und Helm-Repository-URLs verwenden entweder das HTTPS- oder das SSH-Protokoll. Beispiel:https://github.com/GoogleCloudPlatform/anthos-config-management-samples
Wenn Sie SSH alssecretType
verwenden möchten, geben Sie Ihre URL mit dem SSH-Protokoll ein. Dieses Feld ist erforderlich. Wenn Sie kein Protokoll eingeben, wird die URL als HTTPS-URL behandelt.OCI-URLs haben das folgende Format:
LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME
. Standardmäßig wird das Image aus dem Taglatest
abgerufen, aber Sie können stattdessen Images vonTAG
oderDIGEST
abrufen. Geben SieTAG
oderDIGEST
imPACKAGE_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
- Zum Abrufen von
REVISION
: Die Git-Version (Tag oder Hash), von der aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert istHEAD
. Ab Config Sync Version 1.17.0 können Sie auch einen Zweignamen im FeldsyncRev
angeben. In Version 1.17.0 oder höher muss ein Hashwert und keine Abkürzung verwendet werden.BRANCH
: Zweig des Repositorys, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert istmaster
. Ab Config Sync Version 1.17.0 wird der Einfachheit halber empfohlen, das FeldsyncRev
zu verwenden, um einen Zweignamen anzugeben. Wenn sowohl das FeldsyncRev
als auch das FeldsyncBranch
angegeben sind, hatsyncRev
Vorrang vorsyncBranch
.SECRET_TYPE
: einer der folgendensecretTypes
:git
none
: Keine Authentifizierung verwendenssh
: Ein SSH-Schlüsselpaar verwenden.cookiefile
: Einencookiefile
verwenden.token
: Ein Token verwenden.gcpserviceaccount
: Mit einem Google-Dienstkonto auf Cloud Source Repositories zugreifen Wenn Sie diesen Authentifizierungstyp auswählen, müssen Sie eine IAM-Richtlinienbindung erstellen, nachdem Sie Config Sync konfiguriert haben. Weitere Informationen finden Sie auf dem Tab „Google-Dienstkonto“ unter Config Sync Lesezugriff auf Git gewähren.gcenode
: Mit einem Google-Dienstkonto auf Cloud Source Repositories zugreifen Wählen Sie diese Option nur aus, wenn Workload Identity nicht in Ihrem Cluster aktiviert ist.
Weitere Informationen zu diesen Authentifizierungstypen finden Sie unter Config Sync Lesezugriff auf Git gewähren.
oci
none
: Keine Authentifizierung verwendengcenode
: Verwenden Sie das Compute Engine-Standarddienstkonto, um auf ein Image in Artifact Registry zuzugreifen. Wählen Sie diese Option nur aus, wenn Workload Identity nicht in Ihrem Cluster aktiviert ist.gcpserviceaccount
: Verwenden Sie ein Google-Dienstkonto für den Zugriff auf ein Image.
helm
token
: Ein Token verwenden.gcenode
: Verwenden Sie das Compute Engine-Standarddienstkonto, um auf ein Image in Artifact Registry zuzugreifen. Wählen Sie diese Option nur aus, wenn Workload Identity nicht in Ihrem Cluster aktiviert ist.gcpserviceaccount
: Verwenden Sie ein Google-Dienstkonto für den Zugriff auf ein Image.
EMAIL
: Wenn Siegcpserviceaccount
fürsecretType
angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel:acm@PROJECT_ID.iam.gserviceaccount.com
.METRICS_EMAIL
: die E-Mail-Adresse des Google Cloud-Dienstkontos, das zum Exportieren von Config Sync-Messwerten nach Cloud Monitoring verwendet wird Die Appliance muss die IAM-Rolle „Monitoring-Messwert-Autor“ (roles/monitoring.metricWriter
) haben. Das Kubernetes-Dienstkontodefault
im Namespaceconfig-management-monitoring
sollte an die Google Search Appliance gebunden sein.DIRECTORY
: der Pfad des Verzeichnisses, von dem aus synchronisiert werden soll, relativ zum Stammverzeichnis des Git-Repositorys. Alle Unterverzeichnisse des von Ihnen angegebenen Verzeichnisses werden einbezogen und mit dem Cluster synchronisiert. Der Standardwert ist das Stammverzeichnis des Repositorys.PREVENT_DRIFT
: Wenn dieser Wert auftrue
gesetzt ist, wird der Config Sync-Zulassungs-Webhook aktiviert, um Drifts zu verhindern, indem Änderungskonflikte nicht an Live-Cluster übertragen werden. Die Standardeinstellung istfalse
. Config Sync korrigiert Drifts immer, unabhängig vom Wert dieses Felds.
Eine vollständige Liste der Felder, die Sie dem Feld
spec
hinzufügen können, finden Sie unter gcloud-Felder.Vorhandenes Manifest verwenden
Um den Cluster mit den Einstellungen zu konfigurieren, die von einem anderen Cluster verwendet werden, rufen Sie diese Einstellungen von einem registrierten Cluster ab.
gcloud alpha container fleet config-management fetch-for-apply \ --membership=MEMBERSHIP_NAME \ --project=PROJECT_ID \ > CONFIG_YAML_PATH
Ersetzen Sie Folgendes:
MEMBERSHIP_NAME
: Name der Mitgliedschaft des registrierten Clusters mit den Config Sync-Einstellungen, die Sie verwenden möchten.PROJECT_ID
: Ihre Projekt-ID.CONFIG_YAML_PATH
: Der Pfad zur Dateiapply-spec.yaml
, die die aus dem Cluster abgerufenen Einstellungen enthält.
Wenden Sie die Datei
apply-spec.yaml
an: Wenn Sie ein vorhandenes Manifest verwenden, sollten Sie die Datei auf den Cluster anwenden, den Sie mit den Einstellungen konfigurieren möchten, die Sie im vorherigen Befehl abgerufen haben:gcloud beta container fleet config-management apply \ --membership=MEMBERSHIP_NAME \ --config=CONFIG_YAML_PATH \ --project=PROJECT_ID
Ersetzen Sie Folgendes:
MEMBERSHIP_NAME
: der Name der Flottenmitgliedschaft, den Sie bei der Registrierung des Clusters ausgewählt haben. Sie finden den Namen mitgcloud container fleet memberships list
.CONFIG_YAML_PATH
: Pfad zur Dateiapply-spec.yaml
PROJECT_ID
: Ihre Projekt-ID.
Terraform
Wenden Sie auf jeden Cluster, den Sie Config Sync konfigurieren möchten, einen google_gkehub_feature_membership
-Ressourcenblock an, der einen configmanagement
- und einen config_sync
-Block enthält:
git
resource "google_container_cluster" "cluster" {
name = EXISTING_CLUSTER_NAME
location = "EXISTING_CLUSTER_LOCATION"
}
resource "google_gke_hub_membership" "membership" {
membership_id = "MEMBERSHIP_ID"
endpoint {
gke_cluster {
resource_link = "//container.googleapis.com/${google_container_cluster.cluster.id}"
}
}
resource "google_gke_hub_feature" "feature" {
name = "configmanagement"
location = "global"
}
}
resource "google_gke_hub_feature_membership" "feature_member" {
location = "global"
feature = google_gke_hub_feature.feature.name
membership = google_gke_hub_membership.membership.membership_id
configmanagement {
version = "VERSION"
config_sync {
git {
sync_repo = "REPO"
sync_branch = "BRANCH"
policy_dir = "DIRECTORY"
secret_type = "SECRET"
}
}
}
}
Ersetzen Sie Folgendes:
EXISTING_CLUSTER_NAME
ist der Name Ihres vorhandenen Clusters.EXISTING_CLUSTER_LOCATION
: der Standort Ihres vorhandenen Clusters.MEMBERSHIP_ID
: Die ID der Mitgliedschaftsbindung.VERSION
: (optional) die Config Sync-Versionsnummer. Muss auf Version 1.17.0 oder höher festgelegt sein. Wenn Sie das Feld leer lassen, wird die aktuelle Version verwendet.REPO
: Die URL zu dem Repository, das Ihre Konfigurationsdateien enthält.BRANCH
: der Repository-Zweig, z. B.main
.DIRECTORY
: der Pfad innerhalb des Git-Repositorys, der die oberste Ebene des Repositorys darstellt, das Sie synchronisieren möchten.SECRET
: der Secret-Authentifizierungstyp.
oci
resource "google_container_cluster" "cluster" {
name = EXISTING_CLUSTER_NAME
location = "EXISTING_CLUSTER_LOCATION"
}
resource "google_gke_hub_membership" "membership" {
membership_id = "MEMBERSHIP_ID"
endpoint {
gke_cluster {
resource_link = "//container.googleapis.com/${google_container_cluster.cluster.id}"
}
}
resource "google_gke_hub_feature" "feature" {
name = "configmanagement"
location = "global"
}
}
resource "google_gke_hub_feature_membership" "feature_member" {
location = "global"
feature = google_gke_hub_feature.feature.name
membership = google_gke_hub_membership.membership.membership_id
configmanagement {
version = "VERSION"
config_sync {
oci {
sync_repo = "REPO"
policy_dir = "DIRECTORY"
secret_type = "SECRET"
}
}
}
}
Ersetzen Sie Folgendes:
EXISTING_CLUSTER_NAME
ist der Name Ihres vorhandenen Clusters.EXISTING_CLUSTER_LOCATION
: der Standort Ihres vorhandenen Clusters.MEMBERSHIP_ID
: Die ID der Mitgliedschaftsbindung.VERSION
: (optional) die Config Sync-Versionsnummer. Wenn Sie das Feld leer lassen, wird die aktuelle Version verwendet.REPO
: Die URL zum OCI-Image-Repository, das Ihre Konfigurationsdateien enthält.DIRECTORY
: der absolute Pfad des Verzeichnisses, das die Ressourcen enthält, die Sie synchronisieren möchten. Lassen Sie das Feld leer, um das Stammverzeichnis zu verwenden.SECRET
: der Secret-Authentifizierungstyp.
Wiederholen Sie diesen Vorgang für jeden Cluster, den Sie synchronisieren möchten.
Nachdem Sie die Konfiguration des Root-Repositorys abgeschlossen haben, können Sie optional die Synchronisierung aus mehreren Repositories konfigurieren, einschließlich anderer Root- und Namespace-Repositories. Die Namespace-Repositories sind hilfreich, wenn Sie ein Repository mit Namespace-bezogenen Konfigurationen wünschen, die clusterübergreifend mit einem bestimmten Namespace synchronisiert werden.
Standardeinstellungen auf Flottenebene konfigurieren
Wenn Sie die Google Kubernetes Engine (GKE) Enterprise-Version aktiviert haben, können Sie Config Sync als Standardeinstellung auf Flottenebene für Ihre Cluster aktivieren und konfigurieren. Dies bedeutet, dass Config Sync für jeden neuen GKE-Cluster in Google Cloud, der in der Flotte erstellt wurde, mit den von Ihnen angegebenen Einstellungen für den Cluster aktiviert ist. Weitere Informationen zur Standardkonfiguration für Flotten finden Sie unter Features auf Flottenebene verwalten.
Wenn Sie nur die Google Cloud Console verwenden, können Sie Config Sync standardmäßig für Ihre Cluster aktivieren und die Config Sync-Version für Ihre Flotte festlegen. Wenn Sie Terraform verwenden, können Sie Config Sync standardmäßig für Ihre Cluster aktivieren, die Config Sync-Version für Ihre Flotte festlegen und die Verbindung zu Ihrem Git-Repository oder OCI-Image-Repository einrichten.
Führen Sie die folgenden Schritte aus, um für Config Sync Standardeinstellungen auf Flottenebene zu konfigurieren:
Console
Rufen Sie in der Google Cloud Console die Seite Feature Manager auf.
Klicken Sie im Bereich Config Sync auf Konfigurieren.
Einstellungen auf Flottenebene überprüfen. Alle neuen Cluster, die Sie in der Flotte erstellen, übernehmen diese Einstellungen.
Optional: Klicken Sie zum Ändern der Standardeinstellungen auf Flotteneinstellungen anpassen. Führen Sie im angezeigten Dialogfeld die folgenden Schritte aus:
Wählen Sie Automatische Upgrades (Vorschau) aus, um Config Sync-Versionen automatisch upgraden zu lassen, oder wählen Sie Manuelle Upgrades aus, um die Config Sync-Version selbst zu verwalten. Weitere Informationen zur Funktionsweise automatischer Upgrades finden Sie unter Config Sync aktualisieren.
Wenn Sie Manuelle Upgrades ausgewählt haben, wählen Sie in der Liste Version die gewünschte Config Sync-Version aus.
Klicken Sie auf Änderungen speichern.
Klicken Sie auf Konfigurieren.
Klicken Sie im Bestätigungsdialogfeld Flotteneinstellungen konfigurieren auf Bestätigen. Wenn Sie Config Sync noch nicht aktiviert haben, wird durch Klicken auf Bestätigen auch die
anthosconfigmanagement.googleapis.com
API aktiviert.
Terraform
Erstellen Sie ein Verzeichnis für die Terraform-Dateien der Standardkonfiguration der Flotte. Fügen Sie diesem Verzeichnis eine
main.tf
-Datei mit der folgenden Ressource hinzu, die die Einstellungen von Config Sync konfiguriert:git
terraform { required_providers { google = { source = "hashicorp/google" version = ">=5.16.0" } } } provider "google" { project = "PROJECT_ID" } resource "google_gke_hub_feature" "feature" { name = "configmanagement" location = "global" provider = google fleet_default_member_config { configmanagement { version = "VERSION" config_sync { source_format = "unstructured" git { sync_repo = "REPO" sync_branch = "BRANCH" policy_dir = "DIRECTORY" secret_type = "SECRET" } } } } }
Ersetzen Sie Folgendes:
PROJECT_ID
: die ID des Flotten-Hostprojekts.VERSION
: (optional) die Config Sync-Versionsnummer. Wenn Sie das Feld leer lassen, wird die aktuelle Version verwendet.REPO
: Die URL zu dem Repository, das Ihre Konfigurationsdateien enthält.BRANCH
: der Repository-Zweig, z. B.main
.DIRECTORY
: der Pfad innerhalb des Git-Repositorys, der die oberste Ebene des Repositorys darstellt, das Sie synchronisieren möchten.SECRET
: der Secret-Authentifizierungstyp.
Eine vollständige Liste der Einstellungen, die im Config Sync-Block
git
unterstützt werden, finden Sie in der Terraform-Referenzdokumentation für GKE-Hub-Features.OCI
terraform { required_providers { google = { source = "hashicorp/google" version = ">=5.16.0" } } } provider "google" { project = "PROJECT_ID" } resource "google_gke_hub_feature" "feature" { name = "configmanagement" location = "global" provider = google fleet_default_member_config { configmanagement { version = "VERSION" config_sync { source_format = "unstructured" oci { sync_repo = "REPO" policy_dir = "DIRECTORY" secret_type = "SECRET" } } } } }
Ersetzen Sie Folgendes:
PROJECT_ID
: die ID des Flotten-Hostprojekts.VERSION
: Die Versionsnummer von Config Sync. Muss auf Version 1.17.0 oder höher festgelegt sein. Wenn Sie das Feld leer lassen, wird die aktuelle Version verwendet.REPO
: Die URL zum OCI-Image-Repository, das die Konfigurationsdateien enthält.DIRECTORY
: der absolute Pfad des Verzeichnisses, das die Ressourcen enthält, die Sie synchronisieren möchten. Lassen Sie das Feld leer, um das Stammverzeichnis zu verwenden.SECRET
: der Secret-Authentifizierungstyp.
Eine vollständige Liste der Einstellungen, die im Config Sync-Block
oci
unterstützt werden, finden Sie in der Terraform-Referenzdokumentation für GKE-Hub-Features.Initialisieren Sie Terraform in dem von Ihnen erstellten Verzeichnis:
terraform init
Prüfen Sie, ob die mit Terraform vorgeschlagenen Änderungen mit dem erwarteten Plan übereinstimmen:
terraform plan
Erstellen Sie die Standardkonfigurationen für Flottenmitglieder:
terraform apply
Wenn Sie vorhandene Cluster aktualisieren möchten, um Ihre Config Sync-Standardeinstellungen zu verwenden, verwenden Sie die Google Cloud Console, um ausgewählte Flottencluster mit den Standardeinstellungen Ihrer Flotte zu synchronisieren. Alternativ können Sie jeden Cluster mithilfe von Terraform oder der gcloud CLI manuell mit denselben Einstellungen konfigurieren. Folgen Sie dazu der Anleitung unter Config Sync konfigurieren. Wenn Sie zuvor Terraform zur Angabe von Flottenstandardwerten verwendet haben, verwenden Sie denselben configmanagement
- und config_sync
-Block, mit dem Sie die Standardeinstellungen zum Konfigurieren der ausgewählten Cluster festgelegt haben.
So synchronisieren Sie Config Sync-Standardeinstellungen für Ihre gesamte Flotte:
Rufen Sie den Feature Manager auf:
Wählen Sie in der Clustertabelle die Cluster aus, die Sie mit den Flotteneinstellungen synchronisieren möchten.
Klicken Sie auf Mit Flotteneinstellungen synchronisieren.
Die Config Sync-Standardeinstellungen werden auf alle ausgewählten Cluster angewendet. Obwohl die Google Cloud Console nur einen Teil der Einstellungen anzeigt, wie die Config Sync-Version, werden alle Einstellungen auf Flottenebene mit den Clustern synchronisiert. Wenn Sie Config Sync beispielsweise für die Synchronisierung mit einem Git-Repository mithilfe von Terraform konfigurieren, wird diese Einstellung mit Ihren Clustern synchronisiert, aber nicht in der Google Cloud Console angezeigt.
Installation überprüfen
Nach der Installation und Konfiguration von Config Sync können Sie prüfen, ob die Installation erfolgreich abgeschlossen wurde.
Console
Gehen Sie folgendermaßen vor:
- Rufen Sie in der Google Cloud Console im Bereich Features die Seite Konfiguration auf.
- Prüfen Sie auf dem Tab Pakete in der Clustertabelle die Spalte Synchronisierungsstatus. Eine erfolgreiche Installation von Config Sync hat den Status Installiert. Eine erfolgreich konfigurierte „Source of Truth“ hat den Status Synchronisiert.
gcloud
Führen Sie dazu diesen Befehl aus:
gcloud beta container fleet config-management status \
--project=PROJECT_ID
Ersetzen Sie PROJECT_ID
durch die ID Ihres Projekts.
Eine erfolgreiche Installation hat den Status SYNCED
. Ab Config Sync-Version 1.18.0 wird in der Ausgabe auch angezeigt, welche Version von Config Sync installiert ist, und die Upgradeeinstellung von Config Sync.
Wenn nach dem Ausführen des vorherigen Befehls ein Fehler angezeigt wird, prüfen Sie, ob Sie das git-creds
-Secret erstellt haben. Wenn Sie das Secret erstellt haben, führen Sie den folgenden Befehl noch einmal aus:
gcloud beta container fleet config-management apply
Sie können auch den Befehl nomos status
verwenden, um zu prüfen, ob Config Sync erfolgreich installiert wurde. Eine gültige Installation ohne Probleme hat den Status PENDING
oder SYNCED
. Eine ungültige oder unvollständige Installation hat den Status NOT INSTALLED
oder NOT CONFIGURED
. Die Ausgabe enthält auch alle gemeldeten Fehler.
Rollenbasierte Zugriffssteuerung und Berechtigungen
Policy Controller, Config Sync und Config Controller umfassen Arbeitslasten mit umfassenden Berechtigungen. In der folgenden Tabelle sind die Berechtigungen für diese Arbeitslasten aufgeführt:
Komponente | Namespace | Dienstkonto | Berechtigungen | Beschreibung |
---|---|---|---|---|
ConfigManagement-Operator | config-management-system |
config-management-operator |
Clusteradministrator | Der ConfigManagement Operator installiert die anderen Komponenten in dieser Tabelle. Für einige dieser Komponenten sind Clusteradministratorberechtigungen erforderlich, sodass der ConfigManagement Operator diese Berechtigungen ebenfalls erfordert. |
Config Sync | config-management-system |
Erforderliche Berechtigungen finden Sie unter Config Sync-Berechtigungen. |
Ressourcenanforderungen
Im folgenden Abschnitt sind die Ressourcenanfragen für Config Sync aufgeführt.
In der folgenden Tabelle sind die Kubernetes-Ressourcenanforderungen für Config Sync-Komponenten aufgeführt. Weitere Informationen finden Sie unter Ressourcen für Container verwalten in der Kubernetes-Dokumentation.
Nicht alle aufgeführten Komponenten wurden erstellt. Die folgenden Bedingungen führen dazu, dass jede Komponente geplant wird:
config-management-operator
ist installiert, wenn Config Sync aktiviert ist.reconciler-manager
ist installiert, wenn Config Sync aktiviert ist.admission-webhook
ist installiert, wenn der Driftschutz aktiviert ist.- Für jede RootSync- und RepoSync-Datei wird jeweils ein
reconciler
installiert. otel-collector
ist installiert, wenn Config Sync aktiviert ist.
Weitere Informationen zu diesen Komponenten finden Sie unter Architektur von Config Sync.
1.17
Bereitstellungsname | CPU-Anfrage (m) pro Replikat | Speicheranfrage (Mi) pro Replikat |
---|---|---|
config-management-operator |
100 | 100 |
resource-group-controller-manager |
110 | 300 |
admission-webhook1 |
10 | 100 |
otel-collector |
200 | 400 |
reconciler-manager |
20 | 150 |
reconciler (einer pro RootSync und RepoSync) |
Weitere Informationen finden Sie unter Deployment des Abgleichs. |
1 Der Zulassungs-Webhook hat zwei Replikate. Wenn Sie also den Zulassungs-Webhook verwenden, müssen Sie bei der Berechnung der gesamten Ressourcenanfragen den Wert verdoppeln. Der Zulassungs-Webhook ist standardmäßig deaktiviert.
1.16
Bereitstellungsname | CPU-Anfrage (m) pro Replikat | Speicheranfrage (Mi) pro Replikat |
---|---|---|
config-management-operator |
100 | 100 |
resource-group-controller-manager |
110 | 300 |
admission-webhook1 |
10 | 100 |
otel-collector |
200 | 400 |
reconciler-manager |
20 | 150 |
reconciler (einer pro RootSync und RepoSync) |
Weitere Informationen finden Sie unter Deployment des Abgleichs. |
1 Der Zulassungs-Webhook hat zwei Replikate. Wenn Sie also den Zulassungs-Webhook verwenden, müssen Sie bei der Berechnung der gesamten Ressourcenanfragen den Wert verdoppeln. Der Zulassungs-Webhook ist standardmäßig deaktiviert.
1.15
Bereitstellungsname | CPU-Anfrage (m) pro Replikat | Speicheranfrage (Mi) pro Replikat |
---|---|---|
config-management-operator |
100 | 100 |
resource-group-controller-manager |
110 | 300 |
admission-webhook1 |
10 | 100 |
otel-collector |
200 | 400 |
reconciler-manager |
20 | 150 |
reconciler (einer pro RootSync und RepoSync) |
Weitere Informationen finden Sie unter Deployment des Abgleichs. |
1 Der Zulassungs-Webhook hat zwei Replikate. Wenn Sie also den Zulassungs-Webhook verwenden, müssen Sie bei der Berechnung der gesamten Ressourcenanfragen den Wert verdoppeln. Der Zulassungs-Webhook ist standardmäßig deaktiviert.
Abgleichsbereitstellung
Config Sync erstellt für jedes RootSync
- und RepoSync
-Objekt eine unabhängige Abgleichsbereitstellung, um die Synchronisierung auszuführen. Die Abgleichsbereitstellung besteht aus mehreren Containern. Weitere Informationen zu diesen Containern finden Sie unter Abgleichscontainer.
In Config Sync Version 1.17.0 und höher unterscheiden sich die Standardressourcenanfragen für Abgleicher für Standard- und Autopilot-Cluster. Bei allen anderen Clustertypen werden die Standardeinstellungen verwendet.
Standardcluster
1.17
Container name | CPU-Anfrage (m) | Speicheranfrage (Mi) |
---|---|---|
reconciler |
50 | 200 |
otel-agent |
10 | 100 |
hydration-controller (optional) |
10 | 100 |
git-sync |
10 | 16 |
gcenode-askpass-sidecar (optional) |
10 | 20 |
helm-sync |
75 | 128 |
oci-sync |
25 | 32 |
1.16
Container name | CPU-Anfrage (m) | Speicheranfrage (Mi) |
---|---|---|
reconciler |
50 | 200 |
otel-agent |
10 | 100 |
hydration-controller (optional) |
10 | 100 |
git-sync |
10 | 200 |
gcenode-askpass-sidecar (optional) |
10 | 20 |
helm-sync |
50 | 256 |
oci-sync |
10 | 200 |
1.15
Container name | CPU-Anfrage (m) | Speicheranfrage (Mi) |
---|---|---|
reconciler |
50 | 200 |
otel-agent |
10 | 100 |
hydration-controller (optional) |
10 | 100 |
git-sync |
10 | 200 |
gcenode-askpass-sidecar (optional) |
10 | 20 |
helm-sync |
50 | 256 |
oci-sync |
10 | 200 |
Autopilot-Cluster
1.17
Container name | CPU-Anfrage und -Limit (m) | Arbeitsspeicheranforderung und Limit (Mi) |
---|---|---|
reconciler |
700 | 512 |
otel-agent |
10 | 64 |
hydration-controller (optional) |
200 | 256 |
git-sync |
20 | 32 |
gcenode-askpass-sidecar (optional) |
50 | 64 |
helm-sync |
150 | 256 |
oci-sync |
50 | 64 |
1.16
In Config Sync-Versionen vor 1.17.0 sind die Ressourcenanfragen für Standard und Autopilot identisch.
1.15
In Config Sync-Versionen vor 1.17.0 sind die Ressourcenanfragen für Standard und Autopilot identisch.
Informationen zum Überschreiben der standardmäßigen Ressourcenanfragen und -limits finden Sie unter Ressourcenüberschreibungen.
Gebündelte Helm- und Kustomize-Versionen
Config Sync nutzt die ausführbaren Dateien von Helm und Kustomize, um die Konfigurationen im Hintergrund zu rendern. Die folgende Tabelle enthält eine Liste der Config Sync-Versionen, die die Renderingfunktion zusammen mit den gebündelten Helm- und Kustomize-Versionen unterstützen.
Config Sync-Versionen | Helm-Version | Kustomize-Version |
---|---|---|
1.16.0 und höher | v3.11.3 | v5.1.1 |
1.15.0 bis 1.15.3 | v3.11.3 | v5.0.1 |
1.11.0 bis 1.14.3 | v3.6.3 | v4.5.2 |
Informationen zum Rendern von Helm über Kustomize finden Sie unter Kubernetes mit Kustomize konfigurieren. Informationen zur Verwendung der Helm API finden Sie unter Helm-Diagramme aus Artifact Registry synchronisieren.
Nächste Schritte
- Hier erfahren Sie, wie Sie ein Upgrade von Config Sync durchführen.
- Weitere Informationen zu den
gcloud
-Befehlen zum Konfigurieren von Config Sync. - Synchronisierung aus Namespace-Repositories konfigurieren
nomos
-Befehl ausführen- Lesen Sie die Einführung in die Fehlerbehebung bei Config Sync.
- Informationen zum Deinstallieren von Config Sync
- Prüfen Sie die Standardberechtigungen für Config Sync.