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.
Clusteranforderungen
Erstellen Sie einen Cluster, der die folgenden Anforderungen erfüllt, oder verschaffen Sie sich darauf Zugriff:
- Sie nutzen eine unterstützte Plattform und Version der Google Kubernetes Engine (GKE) Enterprise-Version.
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) Workload Identity ist 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. Wenn Sie Workload Identity aktiviert haben und Cloud Monitoring für Config Sync aktivieren möchten, müssen Sie die richtigen Schreibberechtigungen für Messwerte gewähren.
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.
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 das PAT an den Computernutzer binden. - GitLab: Erstellen Sie ein PAT oder erstellen Sie ein Deployment-Token.
- 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
Damit Sie Config Sync verwenden können, müssen Sie zuerst Ihre Cluster registrieren. Wenn Sie Ihre Cluster registrieren, können sie einen gemeinsamen Satz von Konfigurationen und Richtlinien gemeinsam nutzen.
Führen Sie die folgenden Aufgaben aus, um Ihre Cluster zu registrieren:
- Rufen Sie in der Google Cloud Console im Bereich Features die Seite Konfiguration auf.
- Klicken Sie auf add Config Sync installieren.
Wählen Sie in der Tabelle Verfügbare Cluster den zu registrierenden Cluster aus und klicken Sie dann auf Config Sync installieren.
Nach einigen Minuten sollte in der Spalte Config Sync-Status für den ausgewählten Cluster Installiert 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.
- 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äter kubectl
-Befehle zur Konfiguration verwenden.
Sie können das Feld spec.configSync.enabled
auch als true
festlegen und die optionalen Felder weglassen. Sie können dann später kubectl
-Befehle verwenden, um zusätzliche RootSync-Objekte oder RepoSyncs zu erstellen, die Sie später vollständig mit kubectl
-Befehlen verwalten können.
# apply-spec.yaml
applySpecVersion: 1
spec:
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:
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.
2. 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
Dabei gilt:
MEMBERSHIP_NAME
: Name der Mitgliedschaft, den Sie bei der Registrierung Ihres 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.
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. Das bedeutet, dass Config Sync für jeden neuen GKE in Google Cloud-Cluster, der bei der Clustererstellung registriert wird, mit den von Ihnen angegebenen Einstellungen für den Cluster aktiviert ist. Weitere Informationen zur Flotten-Standardkonfiguration finden Sie unter Features auf Flottenebene verwalten.
Führen Sie die folgenden Schritte aus, um für Config Sync Standardeinstellungen auf Flottenebene zu konfigurieren:
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 bei der Flotte registrieren, ü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 in der Liste Version die Config Sync-Version aus, die Sie verwenden möchten.
- Klicken Sie auf Änderungen speichern.
Klicken Sie auf Konfigurieren.
Klicken Sie im Dialogfeld zur Bestätigung auf Bestätigen. Wenn Sie Config Sync noch nicht aktiviert haben, wird durch Klicken auf Bestätigen auch die
anthosconfigmanagement.googleapis.com
API aktiviert.Optional: Synchronisieren Sie vorhandene Cluster mit den Standardeinstellungen:
- Wählen Sie in der Liste Cluster in der Flotte die Cluster aus, die Sie synchronisieren möchten.
- Klicken Sie auf Mit Flotteneinstellungen synchronisieren und dann im angezeigten Bestätigungsdialogfeld auf Bestätigen. Dies kann einige Minuten dauern.
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
. Wenn nach Ausführen des vorherigen Befehls ein Fehler auftritt, 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.
Config Sync aktualisieren
Lesen Sie vor dem Upgrade von Config Sync die Versionshinweise. Dort finden Sie Einzelheiten zu den Änderungen zwischen den Versionen.
Führen Sie die folgenden Schritte aus, um ein Upgrade von Config Sync durchzuführen:
Console
- Rufen Sie in der Google Cloud Console im Bereich Features die Seite Konfiguration auf.
- Wählen Sie auf dem Tab Einstellungen neben dem Cluster, dessen Version Sie aktualisieren möchten, das Kontextmenü more_vert und dann edit Konfiguration bearbeiten aus.
- Wählen Sie in der Drop-down-Liste Version die Version aus, auf die Sie ein Upgrade durchführen möchten.
- Klicken Sie auf Config Sync aktualisieren.
gcloud
Führen Sie dazu diesen Befehl aus:
gcloud beta container fleet config-management upgrade \
--version=VERSION \
--membership=MEMBERSHIP_NAME
Ersetzen Sie Folgendes:
VERSION
: Version, auf die Sie ein Upgrade ausführen möchten.MEMBERSHIP_NAME
: Name der Mitgliedschaft, den Sie bei der Registrierung Ihres Clusters ausgewählt haben. Sie können den Namen der Mitgliedschaft ermitteln, indem Siegcloud container fleet memberships list
ausführen.
Config Management-Version prüfen
Wenn Sie vor dem Upgrade prüfen möchten, welche Config Sync-Version auf Ihren Clustern installiert ist, führen Sie den folgenden Befehl aus:
gcloud beta container fleet config-management version
Weitere Informationen zu diesem Befehl finden Sie in der Referenzdokumentation.
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 in der Kubernetes-Dokumentation unter Ressourcen für Container verwalten.
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.
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 jede RootSync- und RepoSync-Bereitstellung eine unabhängige Abgleichsbereitstellung, um die Synchronisierung durchzuführen. Dies verbessert die Zuverlässigkeit durch die Reduzierung von Single Points of Failure und ermöglicht, dass einzelne Abgleiche unabhängig skaliert werden können.
Die Abgleichsbereitstellung besteht aus mehreren Containern:
Container name | Beschreibung | Bedingung |
---|---|---|
reconciler |
übernimmt Synchronisierung und Driftkorrektur | immer aktiviert |
otel-agent |
sendet Messwerte an den Otel-Collector | immer aktiviert |
hydration-controller (optional) |
Kustomize-Rendering verarbeitet | aktiviert, wenn die Quelle eine kustomize.yaml -Datei enthält |
git-sync |
übernimmt den Git-Quellabruf | aktiviert, wenn spec.sourceType den Wert git hat |
gcenode-askpass-sidecar (optional) |
wird für die Git-Authentifizierung mit dem GKE-Metadatendienst verwendet | aktiviert, wenn spec.sourceType den Wert git hat und spec.git.auth den Wert gcenode oder gcpserviceaccount hat |
helm-sync |
übernimmt den Abruf der Helm-Quelle | aktiviert, wenn spec.sourceType den Wert helm hat |
oci-sync |
übernimmt den Abruf von OCI-Quellen | aktiviert, wenn spec.sourceType den Wert oci hat |
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
- 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.