Synchronisierung aus mehreren Quellen konfigurieren

Auf dieser Seite wird erläutert, wie Sie mehr als eine Stamm- und Namespace-bezogene Source of Truth durch Erstellen von RootSync- und RepoSync-Objekten konfigurieren.

Mit einer Root of Truth können Sie clusterbezogene und Namespace-bezogene Konfigurationen synchronisieren. Eine Root of Truth kann Anmeldedaten auf Administratorebene verwenden, um Richtlinien für Anwendungs-Namespaces zu erzwingen und lokale Änderungen zu überschreiben, die von dem in Ihren Konfigurationen angegebenen Status abweichen. Ein zentraler Administrator ist normalerweise für die Root of Truth zuständig.

Namespace-bezogene "Source of Truth"-Quellen sind optional und können Namespace-bezogene Konfigurationen enthalten, die clusterübergreifend mit einem bestimmten Namespace synchronisiert werden. Sie können die Einrichtung und Kontrolle einer Namespace-bezogenen "Source of Truth" an Nutzer ohne Administratorberechtigung delegieren. Obwohl Config Sync automatisch Änderungen aus der "Source of Truth" erkennt, können Sie eine zusätzliche Drift-Erkennungs-Ebene hinzufügen, indem Sie einer Namespace-bezogenen "Source of Truth" einen Zulassungs-Webhook hinzufügen. Weitere Informationen dazu finden Sie unter Konfigurationsabweichungen verhindern.

Hinweise

• Erstellen Sie eine unstrukturierte "Source of Truth", die die Konfigurationen enthalten kann, mit denen Config Sync synchronisiert wird, oder verschaffen Sie sich darauf Zugriff. Config Sync unterstützt Git-Repositories, Helm-Diagramme und OCI-Images als "Source of Truth". Namespace-bezogene "Sources of Truth" müssen das unstrukturierte Format verwenden.
• Erstellen Sie einen Cluster auf einer von Google Kubernetes Engine unterstützten Plattform und Version oder sorgen Sie dafür, dass Sie darauf zugreifen können und die Anforderungen für Config Sync erfüllt sind.

Ein RoleBinding erstellen

Eine RoleBinding ist erforderlich, um dem RepoSync, das Sie in dieser Anleitung erstellen, Berechtigungen zu erteilen. Führen Sie zum Erstellen des RoleBinding die folgenden Schritte aus:

1. Deklarieren Sie in der Root Source eine RoleBinding-Konfiguration, die dem Dienstkonto SERVICE_ACCOUNT_NAME die Berechtigung zur Verwaltung von Objekten im Namespace gewährt. Config Sync erstellt automatisch das Dienstkonto SERVICE_ACCOUNT_NAME, wenn die RepoSync-Konfiguration mit dem Cluster synchronisiert wird.

   Ein RoleBinding kann auf ein Role im selben Namespace verweisen. Alternativ kann ein RoleBinding auf ein ClusterRole verweisen und dieses ClusterRole an den Namespace des RoleBinding binden. Sie sollten zwar das Prinzip der geringsten Berechtigung einhalten, indem Sie einem benutzerdefinierten Role detaillierte Berechtigungen erteilen, aber Sie können einen ClusterRole definieren oder auch nutzerbezogene Rollen verwenden und auf dieselbe ClusterRole in mehreren RoleBindings in verschiedenen Namespaces verweisen.

   Hinweis: Ein RoleBinding, der auf einen ClusterRole verweist, gewährt nur Zugriff auf den Namespace des RoleBinding, nicht auf den gesamten Cluster.

   Standard-ClusterRoles

   Speichern Sie das RoleBinding-Manifest, das auf ein Standard-ClusterRole verweist, z. B. admin oder edit, als FILENAME:

   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: syncs-repo
     namespace: NAMESPACE
   subjects:
   - kind: ServiceAccount
     name: SERVICE_ACCOUNT_NAME
     namespace: config-management-system
   roleRef:
     kind: ClusterRole
     name: CLUSTERROLE_NAME
     apiGroup: rbac.authorization.k8s.io
   

   Ersetzen Sie Folgendes:

   • FILENAME: der Name des RoleBinding-Manifests.
   • NAMESPACE: Fügen Sie den Namen Ihres Namespace hinzu.
   • SERVICE_ACCOUNT_NAME: Fügen Sie den Namen des Dienstkontos des Abgleichs hinzu. Wenn der RepoSync-Name repo-sync ist, ist SERVICE_ACCOUNT_NAME ns-reconciler-NAMESPACE. Andernfalls ist es ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Wenn Ihr RepoSync-Name beispielsweise prod lautet, ist SERVICE_ACCOUNT_NAME ns-reconciler-NAMESPACE-prod-4. Die Ganzzahl 4 wird verwendet, da prod vier Zeichen enthält.
   • CLUSTERROLE_NAME: Fügen Sie den Namen der Standard-ClusterRole hinzu.

   Benutzerdefinierte Rollen

   Sie können ein ClusterRole oder ein Role deklarieren, indem Sie jeder Ressource, die vom RepoSync-Objekt verwaltet wird, eine Liste mit Berechtigungen zuweisen. Dies ermöglicht präzise Berechtigungen. Weitere Informationen finden Sie unter Auf Ressourcen verweisen.

   Mit dem folgenden ClusterRole oder Role werden beispielsweise Berechtigungen zum Verwalten von Deployment- und ServiceAccount-Objekten gewährt:

   # ROOT_REPO/namespaces/NAMESPACE/sync-role.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ROLE_KIND
   metadata:
     namespace: NAMESPACE # only set this field for a 'Role'
     name: RECONCILER_ROLE
   rules:
   # Update 'apiGroups' and 'resources' to reference actual resources managed by 'RepoSync'.
   - apiGroups: ["apps"]
     resources: ["deployments"]
     verbs: ["*"]
   - apiGroups: [""]
     resources: ["serviceaccounts"]
     verbs: ["*"]
   

   Speichern Sie das RoleBinding-Manifest, das auf ClusterRole oder Role verweist, als FILENAME:

   # ROOT_REPO/namespaces/NAMESPACE/FILENAME.yaml
   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: syncs-repo
     namespace: NAMESPACE
   subjects:
   - kind: ServiceAccount
     name: SERVICE_ACCOUNT_NAME
     namespace: config-management-system
   roleRef:
     kind: ROLE_KIND
     name: RECONCILER_ROLE
     apiGroup: rbac.authorization.k8s.io
   

   Ersetzen Sie Folgendes:

   • FILENAME: der Name des RoleBinding-Manifests.
   • ROLE_KIND: ClusterRole oder Role festlegen.
   • NAMESPACE: Fügen Sie den Namen Ihres Namespace hinzu.
   • SERVICE_ACCOUNT_NAME: Fügen Sie den Namen des Dienstkontos des Abgleichs hinzu. Wenn der RepoSync-Name repo-sync ist, ist SERVICE_ACCOUNT_NAME ns-reconciler-NAMESPACE. Andernfalls ist es ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Wenn Ihr RepoSync-Name beispielsweise prod lautet, ist SERVICE_ACCOUNT_NAME ns-reconciler-NAMESPACE-prod-4. Die Ganzzahl 4 wird verwendet, da prod vier Zeichen enthält.
   • RECONCILER_ROLE: Fügen Sie den Namen des ClusterRole oder Role hinzu.

2. Wenden Sie die RoleBinding an:

   kubectl apply -f FILENAME
   

Beschränkungen

• NamespaceSelectors (einschließlich Annotationen, die auf Selektoren verweisen) funktionieren nur in einer Root Source of Truth.
• Wenn Sie Config Sync mit der Google Cloud Console oder der Google Cloud CLI installiert haben, hat Config Sync automatisch ein RootSync-Objekt namens root-sync erstellt. Aus diesem Grund können Sie keines Ihrer RootSync-Objekte root-sync nennen.

Bevorzugte Konfigurationsmethode auswählen

Wählen Sie eine der beiden Methoden zum Konfigurieren von Ihrer Quellen aus:

• Quellen in einer Root Source of Truth steuern. Mit dieser Methode wird die gesamte Konfiguration einer "Source of Truth" in einer anderen "Source of Truth" zentralisiert, sodass ein zentraler Administrator die vollständige Kontrolle über die Einrichtung erhält.

• Quellen mit der Kubernetes API steuern. Verwenden Sie diese Methode, wenn Sie die Kontrolle über Ihre "Source of Truth" an verschiedene Inhaber delegieren möchten.

Quellen in einer Root Source of Truth steuern

Wenn Sie Quellen mit einer Root-Quelle steuern möchten, benötigen Sie ein RoleBinding, um den Zugriff zu autorisieren. Wenn Sie keine haben, lesen Sie den Abschnitt RoleBinding erstellen.

Stammquellen in einer Root Source of Truth steuern

Config Sync unterstützt die Synchronisierung aus mehr als einer "Source of Truth". Der zentrale Administrator kann eine Root Source of Truth für die Verwaltung aller anderen Quellen verwenden. Da Config Sync die RootSync-Objekte verwaltet, verhindert diese Methode alle lokalen Änderungen an RootSync-Konfigurationen im Cluster.

Führen Sie die folgenden Aufgaben aus, um diese Methode zu verwenden:

1. Speichern Sie eines der folgenden Manifeste als root-sync.yaml. Verwenden Sie die Manifestversion, die dem Quelltyp für Ihre Konfigurationen entspricht.

   Git

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: git
     sourceFormat: ROOT_FORMAT
     git:
       repo: ROOT_REPOSITORY
       revision: ROOT_REVISION
       branch: ROOT_BRANCH
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       secretRef:
         name: ROOT_SECRET_NAME
       noSSLVerify: ROOT_NO_SSL_VERIFY
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   Ersetzen Sie Folgendes:

   • ROOT_SYNC_NAME: Fügen Sie den Namen Ihres RootSync-Objekts hinzu.
   • ROOT_FORMAT: Fügen Sie unstructured hinzu, um ein unstrukturiertes Repository zu verwenden, oder fügen Sie hierarchy hinzu, um ein hierarchisches Repository zu verwenden. Bei diesen Werten wird zwischen Groß- und Kleinschreibung unterschieden. Dieses Feld ist optional und der Standardwert ist hierarchy. Wir empfehlen das Hinzufügen von unstructured, da Sie damit Ihre Konfigurationen so organisieren können, wie es für Sie am besten ist.
   • ROOT_REPOSITORY: Fügen Sie die URL des Git-Repositorys hinzu, das als Stamm-Repository verwendet werden soll. Sie können URLs mithilfe des HTTPS- oder SSH-Protokolls eingeben. https://github.com/GoogleCloudPlatform/anthos-config-management-samples verwendet beispielsweise das HTTPS-Protokoll. Dies ist ein Pflichtfeld.
   • ROOT_REVISION: Fügen Sie die Git-Revision (Tag oder Hash) oder den Zweig hinzu, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist HEAD. Wenn Sie einen Hash verwenden, muss es sich um einen vollständigen Hash (nicht um eine abgekürzte Form) handeln.
   • ROOT_BRANCH: Der Zweig des Repositorys, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist master. Wir empfehlen, das Feld revision zu verwenden, um einen Branch-Namen anzugeben. Wenn sowohl das Feld revision als auch das Feld branch angegeben ist, hat revision Vorrang vor branch.
   • ROOT_DIRECTORY: Fügen Sie den Pfad im Git-Repository zum Stammverzeichnis hinzu, das die Konfiguration enthält, mit der Sie die Synchronisierung durchführen möchten. Dieses Feld ist optional und die Standardeinstellung ist das Stammverzeichnis (/) des Repositorys.

   • ROOT_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:

     • none: Keine Authentifizierung verwenden
     • ssh: Ein SSH-Schlüsselpaar verwenden
     • cookiefile: Nutzen Sie einen cookiefile.
     • token: Ein Token verwenden
     • gcpserviceaccount: Mit einem Google-Dienstkonto auf Cloud Source Repositories zugreifen
     • gcenode: Mit einem Google-Dienstkonto auf Cloud Source Repositories zugreifen Wählen Sie diese Option nur aus, wenn Workload Identity Federation for GKE nicht in Ihrem Cluster aktiviert ist.

     Weitere Informationen zu diesen Authentifizierungstypen finden Sie unter Config Sync Lesezugriff auf Git gewähren.

     Dies ist ein Pflichtfeld.

   • ROOT_EMAIL: Wenn Sie gcpserviceaccount für ROOT_AUTH_TYPE angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.

   • ROOT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, müssen Sie dem Git-Anbieter den öffentlichen Schlüssel des Secrets hinzufügen. Dieses Feld ist optional.

   • ROOT_NO_SSL_VERIFY: Setzen Sie dieses Feld auf true, um die SSL-Zertifikatsüberprüfung zu deaktivieren. Der Standardwert ist false.

   • ROOT_CA_CERT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, muss Ihr Git-Anbieter ein Zertifikat verwenden, das von dieser Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Das Secret muss das CA-Zertifikat unter einem Schlüssel namens cert enthalten. Dieses Feld ist optional.

     Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Zertifizierungsstelle konfigurieren.

   Eine Erläuterung der Felder und eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter RootSync-Felder.

   Dieses Manifest erstellt ein RootSync-Objekt, das Git als Quelle verwendet.

   OCI

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: oci
     sourceFormat: ROOT_FORMAT
     oci:
       image: ROOT_IMAGE
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   Ersetzen Sie Folgendes:

   • ROOT_SYNC_NAME: Fügen Sie den Namen Ihres RootSync-Objekts hinzu.
   • ROOT_FORMAT: Fügen Sie unstructured hinzu, um ein unstrukturiertes Repository zu verwenden, oder fügen Sie hierarchy hinzu, um ein hierarchisches Repository zu verwenden. Bei diesen Werten wird zwischen Groß- und Kleinschreibung unterschieden. Dieses Feld ist optional und der Standardwert ist hierarchy. Wir empfehlen das Hinzufügen von unstructured, da Sie damit Ihre Konfigurationen so organisieren können, wie es für Sie am besten ist.
   • ROOT_IMAGE: Die URL des OCI-Images, das als Root-Repository verwendet werden soll, z. B. LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Standardmäßig wird das Image aus dem Tag latest abgerufen, aber Sie können stattdessen Images von TAG oder DIGEST abrufen. Geben Sie TAG oder DIGEST im PACKAGE_NAME an:
     • Zum Abrufen von TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • Zum Abrufen von DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST

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

   • ROOT_DIRECTORY: Fügen Sie den Pfad im Repository zum Stammverzeichnis hinzu, das die Konfiguration enthält, mit der Sie die Synchronisierung durchführen möchten. Dieses Feld ist optional und die Standardeinstellung ist das Stammverzeichnis (/) des Repositorys.

   • ROOT_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:

     • none: Keine Authentifizierung verwenden
     • gcenode: Verwenden Sie das Compute Engine-Standarddienstkonto, um auf ein Image in Artifact Registry zuzugreifen. Wählen Sie diese Option nur aus, wenn Workload Identity Federation for GKE in Ihrem Cluster nicht aktiviert ist.
     • gcpserviceaccount: Verwenden Sie ein Google-Dienstkonto für den Zugriff auf ein Image.

     Dies ist ein Pflichtfeld.

   • ROOT_EMAIL: Wenn Sie gcpserviceaccount für ROOT_AUTH_TYPE angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.

   • ROOT_CA_CERT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, muss IhrOCI-Anbieter ein Zertifikat verwenden, das von dieser Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Das Secret muss das CA-Zertifikat unter einem Schlüssel namens cert enthalten. Dieses Feld ist optional.

   Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Zertifizierungsstelle konfigurieren.

   Eine Erläuterung der Felder und eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter RootSync-Felder.

   Dieses Manifest erstellt ein RootSync-Objekt, das ein OCI-Image als Quelle verwendet.

   Helm

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: helm
     sourceFormat: ROOT_FORMAT
     helm:
       repo: ROOT_HELM_REPOSITORY
       chart: HELM_CHART_NAME
       version: HELM_CHART_VERSION
       releaseName: HELM_RELEASE_NAME
       namespace: HELM_RELEASE_NAMESPACE
       values:
         foo:
           bar: VALUE_1
         baz:
         - qux: VALUE_2
           xyz: VALUE_3
       includeCRDs: HELM_INCLUDE_CRDS
       auth: ROOT_AUTH_TYPE
         gcpServiceAccountEmail: ROOT_EMAIL
         secretRef:
           name: ROOT_SECRET_NAME
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   Ersetzen Sie Folgendes:

   • ROOT_SYNC_NAME: Fügen Sie den Namen Ihres RootSync-Objekts hinzu.
   • ROOT_FORMAT: Fügen Sie unstructured hinzu, um ein unstrukturiertes Repository zu verwenden, oder fügen Sie hierarchy hinzu, um ein hierarchisches Repository zu verwenden. Bei diesen Werten wird zwischen Groß- und Kleinschreibung unterschieden. Dieses Feld ist optional und der Standardwert ist hierarchy. Wir empfehlen das Hinzufügen von unstructured, da Sie damit Ihre Konfigurationen so organisieren können, wie es für Sie am besten ist.
   • ROOT_HELM_REPOSITORY: die URL des Helm-Repositorys, das als Stamm-Repository verwendet werden soll. Sie können URLs mithilfe des HTTPS- oder SSH-Protokolls eingeben. https://github.com/GoogleCloudPlatform/anthos-config-management-samples verwendet beispielsweise das HTTPS-Protokoll. Dies ist ein Pflichtfeld.
   • HELM_CHART_NAME: Fügen Sie den Namen Ihres Helm-Charts hinzu. Dies ist ein Pflichtfeld.
   • HELM_CHART_VERSION: die Version Ihres Diagramms. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird die aktuelle Version verwendet.
   • HELM_RELEASE_NAME: Der Name des Helm-Release. Dieses Feld ist optional.
   • HELM_RELEASE_NAMESPACE: der Ziel-Namespace für einen Release. Ein Namespace wird nur für Ressourcen festgelegt, die in ihren Vorlagen namespace: {{ .Release.Namespace }} enthalten. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird der Standard-Namespace config-management-system verwendet.
   • HELM_INCLUDE_CRDS: Auf true setzen, wenn das Helm-Template auch eine CustomResourceDefinition generieren soll. Dieses Feld ist optional. Wenn kein Wert angegeben ist, lautet der Standardwert false und es wird keine CRD generiert.
   • VALUE: Anstelle der Standardwerte des Helm-Diagramms zu verwendende Werte Formatieren Sie dieses Feld genauso wie die Datei values.yaml des Helm-Diagramms. Dieses Feld ist optional.

   • ROOT_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:

     • none: Keine Authentifizierung verwenden
     • token: Verwenden Sie einen Nutzernamen und ein Passwort, um auf ein privates Helm-Repository zuzugreifen.
     • gcenode: Verwenden Sie das Compute Engine-Standarddienstkonto, um auf ein Image in Artifact Registry zuzugreifen. Wählen Sie diese Option nur aus, wenn Workload Identity Federation for GKE in Ihrem Cluster nicht aktiviert ist.
     • gcpserviceaccount: Verwenden Sie ein Google-Dienstkonto für den Zugriff auf ein Image.

     Dies ist ein Pflichtfeld.

   • ROOT_EMAIL: Wenn Sie gcpserviceaccount für ROOT_AUTH_TYPE angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.

   • ROOT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu, wenn token der ROOT_AUTH_TYPE ist. Dieses Feld ist optional.

   • ROOT_CA_CERT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, muss Ihr Helm-Anbieter ein Zertifikat verwenden, das von dieser Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Das Secret muss das CA-Zertifikat unter einem Schlüssel namens cert enthalten. Dieses Feld ist optional.

   Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Zertifizierungsstelle konfigurieren.

   Eine Erläuterung der Felder und eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter RootSync-Felder.

   Dieses Manifest erstellt ein RootSync-Objekt, das Helm als Quelle verwendet.

2. Übernehmen Sie die Änderungen für die Root Source of Truth:

    git add .
    git commit -m 'Setting up a new root source of truth.'
    git push
   

3. Sie können die oben genannten Schritte wiederholen, wenn Sie mehrere Root Sources konfigurieren müssen. Sie können auch Konfigurationen mehrerer RootSync-Objekte in einer " Root Source of Truth" speichern, die von einem anderen RootSync-Objekt synchronisiert wird, um mehrere RootSync-Objekte zentral auf GitOps-Art zu verwalten.

Namespace-bezogene Objekte in einer Root Source of Truth steuern

Namespace-bezogene "Source of Truth" kann von einer Root Source of Truth verwaltet werden. Da die Namespace-bezogenen Quellen von Config Sync verwaltet werden, werden lokale Änderungen an den Namespace-bezogenen Quelldefinitionen verhindert.

Führen Sie die folgenden Aufgaben aus, um diese Methode zu verwenden:

1. Legen Sie in der Root Source of Truth eine namespace-Konfiguration fest:

   # ROOT_SOURCE/namespaces/NAMESPACE/namespace.yaml
   apiVersion: v1
   kind: Namespace
   metadata:
     name: NAMESPACE
   

   Ersetzen Sie NAMESPACE durch einen Namen für den Namespace.

2. Erstellen Sie in der Root Source of Truth eines der folgenden RepoSync-Objekte im selben Namespace. Verwenden Sie das Manifest, das dem Quelltyp für Ihre Konfigurationen entspricht:

   Git

   #ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RepoSync
   metadata:
     name: REPO_SYNC_NAME
     namespace: NAMESPACE
   spec:
     sourceType: git
     # Since this is for a namespace repository, the format is unstructured
     sourceFormat: unstructured
     git:
       repo: NAMESPACE_REPOSITORY
       revision: NAMESPACE_REVISION
       branch: NAMESPACE_BRANCH
       dir: "NAMESPACE_DIRECTORY"
       auth: NAMESPACE_AUTH_TYPE
       gcpServiceAccountEmail: NAMESPACE_EMAIL
       secretRef:
         name: NAMESPACE_SECRET_NAME
       noSSLVerify: NAMESPACE_NO_SSL_VERIFY
       caCertSecretRef:
         name: NAMESPACE_CA_CERT_SECRET_NAME
   

   Ersetzen Sie Folgendes:

   • REPO_SYNC_NAME: Fügen Sie den Namen Ihres RepoSync-Objekts hinzu. Der Name sollte im gesamten Namespace eindeutig sein.
   • NAMESPACE: Fügen Sie den Namen Ihres Namespace hinzu.
   • NAMESPACE_REPOSITORY: Fügen Sie die URL des Git-Repositorys hinzu, das als Namespace-Repository verwendet werden soll. Sie können URLs mithilfe des HTTPS- oder SSH-Protokolls eingeben. https://github.com/GoogleCloudPlatform/anthos-config-management-samples verwendet beispielsweise das HTTPS-Protokoll. Wenn Sie kein Protokoll eingeben, wird die URL als HTTPS-URL behandelt. Dies ist ein Pflichtfeld.
   • NAMESPACE_REVISION: Fügen Sie die Git-Revision (Tag oder Hash) oder den Zweig hinzu, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist HEAD. Wenn Sie einen Hash verwenden, muss es sich um einen vollständigen Hash (nicht um eine abgekürzte Form) handeln.
   • NAMESPACE_BRANCH: Der Zweig des Repositorys, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist master. Wir empfehlen, das Feld revision zu verwenden, um einen Branch-Namen anzugeben. Wenn sowohl das Feld revision als auch das Feld branch angegeben ist, hat revision Vorrang vor branch.

   • NAMESPACE_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:

     • none: Keine Authentifizierung verwenden
     • ssh: Ein SSH-Schlüsselpaar verwenden
     • cookiefile: Nutzen Sie einen cookiefile.
     • token: Ein Token verwenden
     • gcpserviceaccount: Verwenden Sie ein Google-Dienstkonto, um auf ein Repository in Cloud Source Repositories zuzugreifen.

     • gcenode: Verwenden Sie ein Google-Dienstkonto, um auf ein Repository in Cloud Source Repositories zuzugreifen. Wählen Sie diese Option nur aus, wenn Workload Identity Federation for GKE nicht in Ihrem Cluster aktiviert ist.

       Weitere Informationen zu diesen Authentifizierungstypen finden Sie unter Config Sync Lesezugriff auf Git gewähren.

     Dies ist ein Pflichtfeld.

   • NAMESPACE_EMAIL: Wenn Sie gcpserviceaccount für NAMESPACE_AUTH_TYPE angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.

   • NAMESPACE_SECRET_NAME: Fügen Sie den Namen hinzu, den Sie dem Secret geben möchten. Dieses Feld ist optional.

   • NAMESPACE_NO_SSL_VERIFY: Setzen Sie dieses Feld auf true, um die SSL-Zertifikatsüberprüfung zu deaktivieren. Der Standardwert ist false.

   • NAMESPACE_CA_CERT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, muss Ihr Git-Anbieter ein Zertifikat verwenden, das von dieser Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Das Secret muss das CA-Zertifikat unter einem Schlüssel namens cert enthalten. Dieses Feld ist optional.

     Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Zertifizierungsstelle konfigurieren.

   Eine Erläuterung der Felder und eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter RepoSync-Felder.

   OCI

   # ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RepoSync
   metadata:
     name: REPO_SYNC_NAME
     namespace: NAMESPACE
   spec:
     sourceType: oci
     # Since this is for a namespace repository, the format is unstructured
     sourceFormat: unstructured
     oci:
       image: NAMESPACE_IMAGE
       dir: NAMESPACE_DIRECTORY
       auth: NAMESPACE_AUTH_TYPE
       gcpServiceAccountEmail: NAMESPACE_EMAIL
       caCertSecretRef:
         name: NAMESPACE_CA_CERT_SECRET_NAME
   

   Ersetzen Sie Folgendes:

   • REPO_SYNC_NAME: Fügen Sie den Namen Ihres RepoSync-Objekts hinzu. Der Name sollte im gesamten Namespace eindeutig sein.
   • NAMESPACE: Fügen Sie den Namen Ihres Namespace hinzu.

   • NAMESPACE_IMAGE: Die URL des OCI-Images, das als Namespace-Quelle verwendet werden soll, z. B. LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Standardmäßig wird das Image aus dem Tag latest abgerufen, aber Sie können stattdessen Images von TAG oder DIGEST abrufen. Geben Sie TAG oder DIGEST im PACKAGE_NAME an:

     • Zum Abrufen von TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • Zum Abrufen von DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
     Achtung: Config Sync erfordert, dass die OCI-Ebene in der tar oder tar+gzip-Format. Andere Formate (z. B. tar+bz2) werden von Config Sync nicht erkannt. Der Wechsel von einem gültigen REPO-Konto zu einem OCI-Image mit einem nicht unterstützten Format führt dazu, dass verwaltete Ressourcen fehlerfrei gelöscht werden.

   • NAMESPACE_DIRECTORY: Fügen Sie den Pfad in der Quelle zum Stammverzeichnis hinzu, das die Konfiguration enthält, mit der Sie die Synchronisierung durchführen möchten. Dieses Feld ist optional und die Standardeinstellung ist das Stammverzeichnis (/) der Quelle.

   • NAMESPACE_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:

     • none: Keine Authentifizierung verwenden
     • gcenode: Verwenden Sie das Compute Engine-Standarddienstkonto, um auf ein Image in Artifact Registry zuzugreifen. Wählen Sie diese Option nur aus, wenn Workload Identity Federation for GKE in Ihrem Cluster nicht aktiviert ist.
     • gcpserviceaccount: Verwenden Sie ein Google-Dienstkonto für den Zugriff auf ein Image.

     Dies ist ein Pflichtfeld.

   • NAMESPACE_EMAIL: Wenn Sie gcpserviceaccount für ROOT_AUTH_TYPE angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.

   • NAMESPACE_CA_CERT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, muss IhrOCI-Anbieter ein Zertifikat verwenden, das von dieser Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Das Secret muss das CA-Zertifikat unter einem Schlüssel namens cert enthalten. Dieses Feld ist optional.

     Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Zertifizierungsstelle konfigurieren.

   Eine Erläuterung der Felder und eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter RootSync-Felder.

   Helm

   # ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RepoSync
   metadata:
     name: REPO_SYNC_NAME
     namespace: NAMESPACE
   spec:
     sourceType: helm
     # Since this is for a namespace repository, the format is unstructured
     sourceFormat: unstructured
     helm:
       repo: NAMESPACE_REPOSITORY
       chart: HELM_CHART_NAME
       version: HELM_CHART_VERSION
       releaseName: HELM_RELEASE_NAME
       namespace: HELM_RELEASE_NAMESPACE
       values:
         foo:
           bar: VALUE_1
         baz:
         - qux: VALUE_2
           xyz: VALUE_3
       includeCRDs: HELM_INCLUDE_CRDS
       auth: NAMESPACE_AUTH_TYPE
         gcpServiceAccountEmail: NAMESPACE_EMAIL
         secretRef:
           name: NAMESPACE_SECRET_NAME
       caCertSecretRef:
         name: NAMESPACE_CA_CERT_SECRET_NAME
   

   Ersetzen Sie Folgendes:

   • REPO_SYNC_NAME: Fügen Sie den Namen Ihres RepoSync-Objekts hinzu. Der Name sollte im gesamten Namespace eindeutig sein.
   • NAMESPACE: Fügen Sie den Namen Ihres Namespace hinzu.
   • NAMESPACE_REPOSITORY: die URL des Helm-Repositorys, das als Stamm-Repository verwendet werden soll. Sie können URLs mithilfe des HTTPS- oder SSH-Protokolls eingeben. https://github.com/GoogleCloudPlatform/anthos-config-management-samples verwendet beispielsweise das HTTPS-Protokoll. Dies ist ein Pflichtfeld.
   • HELM_CHART_NAME: Fügen Sie den Namen Ihres Helm-Charts hinzu. Dies ist ein Pflichtfeld.
   • HELM_CHART_VERSION: die Version Ihres Diagramms. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird die aktuelle Version verwendet.
   • HELM_RELEASE_NAME: Der Name des Helm-Release. Dieses Feld ist optional.
   • HELM_RELEASE_NAMESPACE: der Ziel-Namespace für einen Release. Ein Namespace wird nur für Ressourcen festgelegt, die in ihren Vorlagen namespace: {{ .Release.Namespace }} enthalten. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird der Standard-Namespace config-management-system verwendet.
   • HELM_INCLUDE_CRDS: Auf true setzen, wenn das Helm-Template auch eine CustomResourceDefinition generieren soll. Dieses Feld ist optional. Wenn kein Wert angegeben ist, lautet der Standardwert false und es wird keine CRD generiert.
   • VALUE: Anstelle der Standardwerte des Helm-Diagramms zu verwendende Werte Formatieren Sie dieses Feld genauso wie die Datei values.yaml des Helm-Diagramms. Dieses Feld ist optional.

   • ROOT_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:

     • none: Keine Authentifizierung verwenden
     • token: Verwenden Sie einen Nutzernamen und ein Passwort, um auf ein privates Helm-Repository zuzugreifen.
     • gcenode: Verwenden Sie das Compute Engine-Standarddienstkonto, um auf ein Image in Artifact Registry zuzugreifen. Wählen Sie diese Option nur aus, wenn Workload Identity Federation for GKE in Ihrem Cluster nicht aktiviert ist.
     • gcpserviceaccount: Verwenden Sie ein Google-Dienstkonto für den Zugriff auf ein Image.

     Dies ist ein Pflichtfeld.

   • NAMESPACE_EMAIL: Wenn Sie gcpserviceaccount für ROOT_AUTH_TYPE angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.

   • NAMESPACE_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu, wenn token der ROOT_AUTH_TYPE ist. Dieses Feld ist optional.

   • NAMESPACE_CA_CERT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, muss Ihr Helm-Anbieter ein Zertifikat verwenden, das von dieser Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Das Secret muss das CA-Zertifikat unter einem Schlüssel namens cert enthalten. Dieses Feld ist optional.

     Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Zertifizierungsstelle konfigurieren.

   Eine Erläuterung der Felder und eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter RootSync-Felder.

3. Wenn Sie gcpserviceaccount als Authentifizierungstyp verwenden und die Workload Identity-Föderation für GKE nicht aktiviert haben, müssen Sie eine IAM-Richtlinienbindung zwischen dem Kubernetes-Dienstkonto für jeden Namespace und dem Google-Dienstkonto erstellen. Eine Anleitung zum Erstellen dieser Bindung finden Sie unter Zugriff auf Git gewähren.

4. Übernehmen Sie die Änderungen für die Root Source of Truth:

    git add .
    git commit -m 'Setting up a new namespace-scoped source of truth.'
    git push
   

5. Erstellen Sie ein Secret, falls erforderlich, mit Ihrer bevorzugten Authentifizierungsmethode. Wenn Sie none als Authentifizierungstyp verwendet haben, können Sie diesen Schritt überspringen.

   Das Secret muss die folgenden Anforderungen erfüllen:

   • Erstellen Sie das Secret im selben Namespace wie RepoSync.
   • Der Name des Secrets muss mit dem Namen spec.git.secretRef übereinstimmen, den Sie in repo-sync.yaml definiert haben.
   • Sie müssen den öffentlichen Schlüssel des Secrets dem Git-Anbieter hinzufügen.

6. Verwenden Sie kubectl get für eines der Objekte in der Namespace Source um die Konfiguration zu prüfen. Beispiel:

   kubectl get rolebindings -n NAMESPACE
   

7. Sie können die oben genannten Schritte wiederholen, wenn Sie mehr als eine Namespace-bezogene Quelle konfigurieren müssen.

Namespace-bezogene Quellen in einer Namespace-bezogenen Quelle steuern

Config Sync unterstützt die Synchronisierung von mehr als einer Namespace-bezogenen "Source of Truth" pro Namespace. Namespace-bezogene "Source of Truth" können in einer Namespace-bezogenen "Source of Truth" im selben Namespace verwaltet werden.

Führen Sie die folgenden Aufgaben aus, um diese Methode zu verwenden:

1. Erstellen Sie in der Namespace-bezogenen "Source of Truth" eines der folgenden RepoSync-Objekte im selben Namespace. Verwenden Sie das Manifest, das dem Quelltyp für Ihre Konfigurationen entspricht:

   Git

   #ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RepoSync
   metadata:
     name: REPO_SYNC_NAME
     namespace: NAMESPACE
   spec:
     sourceType: git
     # Since this is for a namespace repository, the format is unstructured
     sourceFormat: unstructured
     git:
       repo: NAMESPACE_REPOSITORY
       revision: NAMESPACE_REVISION
       branch: NAMESPACE_BRANCH
       dir: "NAMESPACE_DIRECTORY"
       auth: NAMESPACE_AUTH_TYPE
       gcpServiceAccountEmail: NAMESPACE_EMAIL
       secretRef:
         name: NAMESPACE_SECRET_NAME
       noSSLVerify: NAMESPACE_NO_SSL_VERIFY
       caCertSecretRef:
         name: NAMESPACE_CA_CERT_SECRET_NAME
   

   Ersetzen Sie Folgendes:

   • REPO_SYNC_NAME: Fügen Sie den Namen Ihres RepoSync-Objekts hinzu. Der Name sollte im gesamten Namespace eindeutig sein.
   • NAMESPACE: Fügen Sie den Namen Ihres Namespace hinzu.
   • NAMESPACE_REPOSITORY: Fügen Sie die URL des Git-Repositorys hinzu, das als Namespace-Repository verwendet werden soll. Sie können URLs mithilfe des HTTPS- oder SSH-Protokolls eingeben. https://github.com/GoogleCloudPlatform/anthos-config-management-samples verwendet beispielsweise das HTTPS-Protokoll. Wenn Sie kein Protokoll eingeben, wird die URL als HTTPS-URL behandelt. Dies ist ein Pflichtfeld.
   • NAMESPACE_REVISION: Fügen Sie die Git-Revision (Tag oder Hash) oder den Zweig hinzu, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist HEAD. Wenn Sie einen Hash verwenden, muss es sich um einen vollständigen Hash (nicht um eine abgekürzte Form) handeln.
   • NAMESPACE_BRANCH: Der Zweig des Repositorys, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist master. Wir empfehlen, das Feld revision zu verwenden, um einen Branch-Namen anzugeben. Wenn sowohl das Feld revision als auch das Feld branch angegeben ist, hat revision Vorrang vor branch.

   • NAMESPACE_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:

     • none: Keine Authentifizierung verwenden
     • ssh: Ein SSH-Schlüsselpaar verwenden
     • cookiefile: Nutzen Sie einen cookiefile.
     • token: Ein Token verwenden
     • gcpserviceaccount: Verwenden Sie ein Google-Dienstkonto, um auf ein Repository in Cloud Source Repositories zuzugreifen.

     • gcenode: Verwenden Sie ein Google-Dienstkonto, um auf ein Repository in Cloud Source Repositories zuzugreifen. Wählen Sie diese Option nur aus, wenn Workload Identity Federation for GKE nicht in Ihrem Cluster aktiviert ist.

       Weitere Informationen zu diesen Authentifizierungstypen finden Sie unter Config Sync Lesezugriff auf Git gewähren.

     Dies ist ein Pflichtfeld.

   • NAMESPACE_EMAIL: Wenn Sie gcpserviceaccount für NAMESPACE_AUTH_TYPE angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.

   • NAMESPACE_SECRET_NAME: Fügen Sie den Namen hinzu, den Sie dem Secret geben möchten. Dieses Feld ist optional.

   • NAMESPACE_NO_SSL_VERIFY: Setzen Sie dieses Feld auf true, um die SSL-Zertifikatsüberprüfung zu deaktivieren. Der Standardwert ist false.

   • NAMESPACE_CA_CERT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, muss Ihr Git-Anbieter ein Zertifikat verwenden, das von dieser Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Das Secret muss das CA-Zertifikat unter einem Schlüssel namens cert enthalten. Dieses Feld ist optional.

     Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Zertifizierungsstelle konfigurieren.

   Eine Erläuterung der Felder und eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter RepoSync-Felder.

   OCI

   # ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RepoSync
   metadata:
     name: REPO_SYNC_NAME
     namespace: NAMESPACE
   spec:
     sourceType: oci
     # Since this is for a namespace repository, the format is unstructured
     sourceFormat: unstructured
     oci:
       image: NAMESPACE_IMAGE
       dir: NAMESPACE_DIRECTORY
       auth: NAMESPACE_AUTH_TYPE
       gcpServiceAccountEmail: NAMESPACE_EMAIL
       caCertSecretRef:
         name: NAMESPACE_CA_CERT_SECRET_NAME
   

   Ersetzen Sie Folgendes:

   • REPO_SYNC_NAME: Fügen Sie den Namen Ihres RepoSync-Objekts hinzu. Der Name sollte im gesamten Namespace eindeutig sein.
   • NAMESPACE: Fügen Sie den Namen Ihres Namespace hinzu.

   • NAMESPACE_IMAGE: Die URL des OCI-Images, das als Namespace-Quelle verwendet werden soll, z. B. LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Standardmäßig wird das Image aus dem Tag latest abgerufen, aber Sie können stattdessen Images von TAG oder DIGEST abrufen. Geben Sie TAG oder DIGEST im PACKAGE_NAME an:

     • Zum Abrufen von TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • Zum Abrufen von DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
     Achtung: Config Sync erfordert, dass die OCI-Ebene in der tar oder tar+gzip-Format. Andere Formate (z. B. tar+bz2) werden von Config Sync nicht erkannt. Der Wechsel von einem gültigen REPO-Konto zu einem OCI-Image mit einem nicht unterstützten Format führt dazu, dass verwaltete Ressourcen fehlerfrei gelöscht werden.

   • NAMESPACE_DIRECTORY: Fügen Sie den Pfad in der Quelle zum Stammverzeichnis hinzu, das die Konfiguration enthält, mit der Sie die Synchronisierung durchführen möchten. Dieses Feld ist optional und die Standardeinstellung ist das Stammverzeichnis (/) der Quelle.

   • NAMESPACE_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:

     • none: Keine Authentifizierung verwenden
     • gcenode: Verwenden Sie das Compute Engine-Standarddienstkonto, um auf ein Image in Artifact Registry zuzugreifen. Wählen Sie diese Option nur aus, wenn Workload Identity Federation for GKE in Ihrem Cluster nicht aktiviert ist.
     • gcpserviceaccount: Verwenden Sie ein Google-Dienstkonto für den Zugriff auf ein Image.

     Dies ist ein Pflichtfeld.

   • NAMESPACE_EMAIL: Wenn Sie gcpserviceaccount für ROOT_AUTH_TYPE angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.

   • NAMESPACE_CA_CERT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, muss IhrOCI-Anbieter ein Zertifikat verwenden, das von dieser Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Das Secret muss das CA-Zertifikat unter einem Schlüssel namens cert enthalten. Dieses Feld ist optional.

     Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Zertifizierungsstelle konfigurieren.

   Eine Erläuterung der Felder und eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter RootSync-Felder.

   Helm

   # ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RepoSync
   metadata:
     name: REPO_SYNC_NAME
     namespace: NAMESPACE
   spec:
     sourceType: helm
     # Since this is for a namespace repository, the format is unstructured
     sourceFormat: unstructured
     helm:
       repo: NAMESPACE_REPOSITORY
       chart: HELM_CHART_NAME
       version: HELM_CHART_VERSION
       releaseName: HELM_RELEASE_NAME
       namespace: HELM_RELEASE_NAMESPACE
       values:
         foo:
           bar: VALUE_1
         baz:
         - qux: VALUE_2
           xyz: VALUE_3
       includeCRDs: HELM_INCLUDE_CRDS
       auth: NAMESPACE_AUTH_TYPE
         gcpServiceAccountEmail: NAMESPACE_EMAIL
         secretRef:
           name: NAMESPACE_SECRET_NAME
       caCertSecretRef:
         name: NAMESPACE_CA_CERT_SECRET_NAME
   

   Ersetzen Sie Folgendes:

   • REPO_SYNC_NAME: Fügen Sie den Namen Ihres RepoSync-Objekts hinzu. Der Name sollte im gesamten Namespace eindeutig sein.
   • NAMESPACE: Fügen Sie den Namen Ihres Namespace hinzu.
   • NAMESPACE_REPOSITORY: die URL des Helm-Repositorys, das als Stamm-Repository verwendet werden soll. Sie können URLs mithilfe des HTTPS- oder SSH-Protokolls eingeben. https://github.com/GoogleCloudPlatform/anthos-config-management-samples verwendet beispielsweise das HTTPS-Protokoll. Dies ist ein Pflichtfeld.
   • HELM_CHART_NAME: Fügen Sie den Namen Ihres Helm-Charts hinzu. Dies ist ein Pflichtfeld.
   • HELM_CHART_VERSION: die Version Ihres Diagramms. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird die aktuelle Version verwendet.
   • HELM_RELEASE_NAME: Der Name des Helm-Release. Dieses Feld ist optional.
   • HELM_RELEASE_NAMESPACE: der Ziel-Namespace für einen Release. Ein Namespace wird nur für Ressourcen festgelegt, die in ihren Vorlagen namespace: {{ .Release.Namespace }} enthalten. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird der Standard-Namespace config-management-system verwendet.
   • HELM_INCLUDE_CRDS: Auf true setzen, wenn das Helm-Template auch eine CustomResourceDefinition generieren soll. Dieses Feld ist optional. Wenn kein Wert angegeben ist, lautet der Standardwert false und es wird keine CRD generiert.
   • VALUE: Anstelle der Standardwerte des Helm-Diagramms zu verwendende Werte Formatieren Sie dieses Feld genauso wie die Datei values.yaml des Helm-Diagramms. Dieses Feld ist optional.

   • ROOT_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:

     • none: Keine Authentifizierung verwenden
     • token: Verwenden Sie einen Nutzernamen und ein Passwort, um auf ein privates Helm-Repository zuzugreifen.
     • gcenode: Verwenden Sie das Compute Engine-Standarddienstkonto, um auf ein Image in Artifact Registry zuzugreifen. Wählen Sie diese Option nur aus, wenn Workload Identity Federation for GKE in Ihrem Cluster nicht aktiviert ist.
     • gcpserviceaccount: Verwenden Sie ein Google-Dienstkonto für den Zugriff auf ein Image.

     Dies ist ein Pflichtfeld.

   • NAMESPACE_EMAIL: Wenn Sie gcpserviceaccount für ROOT_AUTH_TYPE angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.

   • NAMESPACE_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu, wenn token der ROOT_AUTH_TYPE ist. Dieses Feld ist optional.

   • NAMESPACE_CA_CERT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, muss Ihr Helm-Anbieter ein Zertifikat verwenden, das von dieser Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Das Secret muss das CA-Zertifikat unter einem Schlüssel namens cert enthalten. Dieses Feld ist optional.

     Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Zertifizierungsstelle konfigurieren.

   Eine Erläuterung der Felder und eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter RootSync-Felder.

2. Wenn Sie gcpserviceaccount als Authentifizierungstyp verwenden und die Workload Identity-Föderation für GKE nicht aktiviert haben, müssen Sie eine IAM-Richtlinienbindung zwischen dem Kubernetes-Dienstkonto für jeden Namespace und dem Google-Dienstkonto erstellen. Eine Anleitung zum Erstellen dieser Bindung finden Sie unter Zugriff auf Git gewähren.

3. Übernehmen Sie die Änderungen für die Root Source of Truth:

    git add .
    git commit -m 'Setting up a new namespace-scoped source of truth.'
    git push
   

4. Erstellen Sie ein Secret, falls erforderlich, mit Ihrer bevorzugten Authentifizierungsmethode. Wenn Sie none als Authentifizierungstyp verwendet haben, können Sie diesen Schritt überspringen.

   Das Secret muss die folgenden Anforderungen erfüllen:

   • Erstellen Sie das Secret im selben Namespace wie RepoSync.
   • Der Name des Secrets muss mit dem Namen spec.git.secretRef übereinstimmen, den Sie in repo-sync.yaml definiert haben.
   • Sie müssen den öffentlichen Schlüssel des Secrets dem Git-Anbieter hinzufügen.

5. Verwenden Sie kubectl get für eines der Objekte in der Namespace-bezogenen "Source of Truth", um die Konfiguration zu prüfen. Beispiel:

   kubectl get rolebindings -n NAMESPACE
   

6. Sie können die oben genannten Schritte wiederholen, wenn Sie mehr als eine Namespace-bezogene Quelle konfigurieren müssen.

"Source of Truth" mit der Kubernetes API steuern

Bei dieser Methode delegiert der zentrale Administrator die Deklaration anderer RootSync-Objekte an andere Administratoren. Bei RepoSync-Objekten deklariert der zentrale Administrator nur den Namespace in der Root Source of Truth und delegiert die Deklaration des RepoSync-Objekts an den Anwendungsoperator.

Mehr als eine Root Source of Truth verwalten

Andere Administratoren können durch Ausführen der folgenden Aufgaben eine Root Source of Truth steuern:

1. Speichern Sie eines der folgenden Manifeste als root-sync.yaml. Verwenden Sie die Manifestversion, die dem Quelltyp für Ihre Konfigurationen entspricht.

   Git

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: git
     sourceFormat: ROOT_FORMAT
     git:
       repo: ROOT_REPOSITORY
       revision: ROOT_REVISION
       branch: ROOT_BRANCH
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       secretRef:
         name: ROOT_SECRET_NAME
       noSSLVerify: ROOT_NO_SSL_VERIFY
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   Ersetzen Sie Folgendes:

   • ROOT_SYNC_NAME: Fügen Sie den Namen Ihres RootSync-Objekts hinzu.
   • ROOT_FORMAT: Fügen Sie unstructured hinzu, um ein unstrukturiertes Repository zu verwenden, oder fügen Sie hierarchy hinzu, um ein hierarchisches Repository zu verwenden. Bei diesen Werten wird zwischen Groß- und Kleinschreibung unterschieden. Dieses Feld ist optional und der Standardwert ist hierarchy. Wir empfehlen das Hinzufügen von unstructured, da Sie damit Ihre Konfigurationen so organisieren können, wie es für Sie am besten ist.
   • ROOT_REPOSITORY: Fügen Sie die URL des Git-Repositorys hinzu, das als Stamm-Repository verwendet werden soll. Sie können URLs mithilfe des HTTPS- oder SSH-Protokolls eingeben. https://github.com/GoogleCloudPlatform/anthos-config-management-samples verwendet beispielsweise das HTTPS-Protokoll. Dies ist ein Pflichtfeld.
   • ROOT_REVISION: Fügen Sie die Git-Revision (Tag oder Hash) oder den Zweig hinzu, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist HEAD. Wenn Sie einen Hash verwenden, muss es sich um einen vollständigen Hash (nicht um eine abgekürzte Form) handeln.
   • ROOT_BRANCH: Der Zweig des Repositorys, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist master. Wir empfehlen, das Feld revision zu verwenden, um einen Branch-Namen anzugeben. Wenn sowohl das Feld revision als auch das Feld branch angegeben ist, hat revision Vorrang vor branch.
   • ROOT_DIRECTORY: Fügen Sie den Pfad im Git-Repository zum Stammverzeichnis hinzu, das die Konfiguration enthält, mit der Sie die Synchronisierung durchführen möchten. Dieses Feld ist optional und die Standardeinstellung ist das Stammverzeichnis (/) des Repositorys.

   • ROOT_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:

     • none: Keine Authentifizierung verwenden
     • ssh: Ein SSH-Schlüsselpaar verwenden
     • cookiefile: Nutzen Sie einen cookiefile.
     • token: Ein Token verwenden
     • gcpserviceaccount: Mit einem Google-Dienstkonto auf Cloud Source Repositories zugreifen
     • gcenode: Mit einem Google-Dienstkonto auf Cloud Source Repositories zugreifen Wählen Sie diese Option nur aus, wenn Workload Identity Federation for GKE nicht in Ihrem Cluster aktiviert ist.

     Weitere Informationen zu diesen Authentifizierungstypen finden Sie unter Config Sync Lesezugriff auf Git gewähren.

     Dies ist ein Pflichtfeld.

   • ROOT_EMAIL: Wenn Sie gcpserviceaccount für ROOT_AUTH_TYPE angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.

   • ROOT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, müssen Sie dem Git-Anbieter den öffentlichen Schlüssel des Secrets hinzufügen. Dieses Feld ist optional.

   • ROOT_NO_SSL_VERIFY: Setzen Sie dieses Feld auf true, um die SSL-Zertifikatsüberprüfung zu deaktivieren. Der Standardwert ist false.

   • ROOT_CA_CERT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, muss Ihr Git-Anbieter ein Zertifikat verwenden, das von dieser Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Das Secret muss das CA-Zertifikat unter einem Schlüssel namens cert enthalten. Dieses Feld ist optional.

     Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Zertifizierungsstelle konfigurieren.

   Eine Erläuterung der Felder und eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter RootSync-Felder.

   Dieses Manifest erstellt ein RootSync-Objekt, das Git als Quelle verwendet.

   OCI

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: oci
     sourceFormat: ROOT_FORMAT
     oci:
       image: ROOT_IMAGE
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   Ersetzen Sie Folgendes:

   • ROOT_SYNC_NAME: Fügen Sie den Namen Ihres RootSync-Objekts hinzu.
   • ROOT_FORMAT: Fügen Sie unstructured hinzu, um ein unstrukturiertes Repository zu verwenden, oder fügen Sie hierarchy hinzu, um ein hierarchisches Repository zu verwenden. Bei diesen Werten wird zwischen Groß- und Kleinschreibung unterschieden. Dieses Feld ist optional und der Standardwert ist hierarchy. Wir empfehlen das Hinzufügen von unstructured, da Sie damit Ihre Konfigurationen so organisieren können, wie es für Sie am besten ist.
   • ROOT_IMAGE: Die URL des OCI-Images, das als Root-Repository verwendet werden soll, z. B. LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Standardmäßig wird das Image aus dem Tag latest abgerufen, aber Sie können stattdessen Images von TAG oder DIGEST abrufen. Geben Sie TAG oder DIGEST im PACKAGE_NAME an:
     • Zum Abrufen von TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • Zum Abrufen von DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST

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

   • ROOT_DIRECTORY: Fügen Sie den Pfad im Repository zum Stammverzeichnis hinzu, das die Konfiguration enthält, mit der Sie die Synchronisierung durchführen möchten. Dieses Feld ist optional und die Standardeinstellung ist das Stammverzeichnis (/) des Repositorys.

   • ROOT_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:

     • none: Keine Authentifizierung verwenden
     • gcenode: Verwenden Sie das Compute Engine-Standarddienstkonto, um auf ein Image in Artifact Registry zuzugreifen. Wählen Sie diese Option nur aus, wenn Workload Identity Federation for GKE in Ihrem Cluster nicht aktiviert ist.
     • gcpserviceaccount: Verwenden Sie ein Google-Dienstkonto für den Zugriff auf ein Image.

     Dies ist ein Pflichtfeld.

   • ROOT_EMAIL: Wenn Sie gcpserviceaccount für ROOT_AUTH_TYPE angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.

   • ROOT_CA_CERT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, muss IhrOCI-Anbieter ein Zertifikat verwenden, das von dieser Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Das Secret muss das CA-Zertifikat unter einem Schlüssel namens cert enthalten. Dieses Feld ist optional.

   Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Zertifizierungsstelle konfigurieren.

   Eine Erläuterung der Felder und eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter RootSync-Felder.

   Dieses Manifest erstellt ein RootSync-Objekt, das ein OCI-Image als Quelle verwendet.

   Helm

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: helm
     sourceFormat: ROOT_FORMAT
     helm:
       repo: ROOT_HELM_REPOSITORY
       chart: HELM_CHART_NAME
       version: HELM_CHART_VERSION
       releaseName: HELM_RELEASE_NAME
       namespace: HELM_RELEASE_NAMESPACE
       values:
         foo:
           bar: VALUE_1
         baz:
         - qux: VALUE_2
           xyz: VALUE_3
       includeCRDs: HELM_INCLUDE_CRDS
       auth: ROOT_AUTH_TYPE
         gcpServiceAccountEmail: ROOT_EMAIL
         secretRef:
           name: ROOT_SECRET_NAME
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   Ersetzen Sie Folgendes:

   • ROOT_SYNC_NAME: Fügen Sie den Namen Ihres RootSync-Objekts hinzu.
   • ROOT_FORMAT: Fügen Sie unstructured hinzu, um ein unstrukturiertes Repository zu verwenden, oder fügen Sie hierarchy hinzu, um ein hierarchisches Repository zu verwenden. Bei diesen Werten wird zwischen Groß- und Kleinschreibung unterschieden. Dieses Feld ist optional und der Standardwert ist hierarchy. Wir empfehlen das Hinzufügen von unstructured, da Sie damit Ihre Konfigurationen so organisieren können, wie es für Sie am besten ist.
   • ROOT_HELM_REPOSITORY: die URL des Helm-Repositorys, das als Stamm-Repository verwendet werden soll. Sie können URLs mithilfe des HTTPS- oder SSH-Protokolls eingeben. https://github.com/GoogleCloudPlatform/anthos-config-management-samples verwendet beispielsweise das HTTPS-Protokoll. Dies ist ein Pflichtfeld.
   • HELM_CHART_NAME: Fügen Sie den Namen Ihres Helm-Charts hinzu. Dies ist ein Pflichtfeld.
   • HELM_CHART_VERSION: die Version Ihres Diagramms. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird die aktuelle Version verwendet.
   • HELM_RELEASE_NAME: Der Name des Helm-Release. Dieses Feld ist optional.
   • HELM_RELEASE_NAMESPACE: der Ziel-Namespace für einen Release. Ein Namespace wird nur für Ressourcen festgelegt, die in ihren Vorlagen namespace: {{ .Release.Namespace }} enthalten. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird der Standard-Namespace config-management-system verwendet.
   • HELM_INCLUDE_CRDS: Auf true setzen, wenn das Helm-Template auch eine CustomResourceDefinition generieren soll. Dieses Feld ist optional. Wenn kein Wert angegeben ist, lautet der Standardwert false und es wird keine CRD generiert.
   • VALUE: Anstelle der Standardwerte des Helm-Diagramms zu verwendende Werte Formatieren Sie dieses Feld genauso wie die Datei values.yaml des Helm-Diagramms. Dieses Feld ist optional.

   • ROOT_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:

     • none: Keine Authentifizierung verwenden
     • token: Verwenden Sie einen Nutzernamen und ein Passwort, um auf ein privates Helm-Repository zuzugreifen.
     • gcenode: Verwenden Sie das Compute Engine-Standarddienstkonto, um auf ein Image in Artifact Registry zuzugreifen. Wählen Sie diese Option nur aus, wenn Workload Identity Federation for GKE in Ihrem Cluster nicht aktiviert ist.
     • gcpserviceaccount: Verwenden Sie ein Google-Dienstkonto für den Zugriff auf ein Image.

     Dies ist ein Pflichtfeld.

   • ROOT_EMAIL: Wenn Sie gcpserviceaccount für ROOT_AUTH_TYPE angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.

   • ROOT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu, wenn token der ROOT_AUTH_TYPE ist. Dieses Feld ist optional.

   • ROOT_CA_CERT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, muss Ihr Helm-Anbieter ein Zertifikat verwenden, das von dieser Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Das Secret muss das CA-Zertifikat unter einem Schlüssel namens cert enthalten. Dieses Feld ist optional.

   Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Zertifizierungsstelle konfigurieren.

   Eine Erläuterung der Felder und eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter RootSync-Felder.

   Dieses Manifest erstellt ein RootSync-Objekt, das Helm als Quelle verwendet.

2. Änderungen anwenden:

   kubectl apply -f root-sync.yaml
   

3. Sie können die oben genannten Schritte wiederholen, wenn Sie mehr als eine Root Source of Truth konfigurieren müssen.

Namespace-bezogene "Sources of Truth" steuern

Zentrale Administratoraufgaben

Der zentrale Administrator führt die folgenden Aufgaben aus:

1. Deklarieren Sie in der Root Source of Truth eine namespace-Konfiguration für Namespace-bezogene Quellen.

   # ROOT_REPO/namespaces/NAMESPACE/namespace.yaml
    apiVersion: v1
    kind: Namespace
    metadata:
      name: NAMESPACE
   

   Ersetzen Sie NAMESPACE durch einen Namen für den Namespace.

2. Deklarieren Sie in der Root Source of Truth die RoleBinding, um den Anwendungsoperatoren Berechtigungen zu erteilen. Verwenden Sie die RBAC-Eskalationsprävention, damit der Anwendungsoperator später keine Rollenbindung mit Berechtigungen anwenden kann, die von dieser Rollenbindung nicht erteilt wurden.

   Erstellen Sie das folgende Manifest, um das RoleBinding zu deklarieren:

   # ROOT_REPO/namespaces/NAMESPACE/operator-rolebinding.yaml
    kind: RoleBinding
    # Add RBAC escalation prevention
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: operator
      namespace: NAMESPACE
    subjects:
    - kind: User
      name: USERNAME
      apiGroup: rbac.authorization.k8s.io
    roleRef:
      kind: ClusterRole
      name: OPERATOR_ROLE
      apiGroup: rbac.authorization.k8s.io
   

   Ersetzen Sie Folgendes:

   • NAMESPACE: Fügen Sie den Namespace hinzu, den Sie in der Root Source of Truth erstellt haben.
   • USERNAME: Fügen Sie den Nutzernamen des Anwendungsoperators hinzu.

   • OPERATOR_ROLE: Als zentraler Administrator können Sie mit OPERATOR_ROLE festlegen, welche Konfigurationsarten aus der Namespace-bezogenen Source synchronisiert werden können. Sie können eine der folgenden Rollen auswählen:

     • Eine Standard-ClusterRole:

       • admin
       • edit

       Weitere Informationen finden Sie unter Nutzerbezogene Rollen.

     • Eine benutzerdefinierte ClusterRole oder Role, die in der Root Source of Truth deklariert ist. Diese Rolle ermöglicht differenzierte Berechtigungen.

3. Übernehmen Sie die Änderungen für die Root Source of Truth:

    git add .
    git commit -m 'Setting up new namespace-scoped source of truth.'
    git push
   

Aufgaben des Anwendungsoperators

Der Anwendungsoperator kann Namespace-bezogene Quellen steuern. Dazu führt er die folgenden Aufgaben aus:

1. Deklarieren Sie eine RoleBinding-Konfiguration, die dem automatisch bereitgestellten Dienstkonto SERVICE_ACCOUNT_NAME die Berechtigung zur Verwaltung von Objekten im Namespace gewährt. Config Sync erstellt automatisch das Dienstkonto SERVICE_ACCOUNT_NAME, wenn die Konfiguration RepoSync mit dem Cluster synchronisiert wird.

   Erstellen Sie das folgende Manifest, um das RoleBinding zu deklarieren:

   # sync-rolebinding.yaml
   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: syncs-repo
     namespace: NAMESPACE
   subjects:
   - kind: ServiceAccount
     name: SERVICE_ACCOUNT_NAME
     namespace: config-management-system
   roleRef:
     kind: ClusterRole
     name: RECONCILER_ROLE
     apiGroup: rbac.authorization.k8s.io
   

   Ersetzen Sie Folgendes:

   • NAMESPACE: Fügen Sie den Namespace hinzu, den Sie in der Root Source of Truth erstellt haben.
   • SERVICE_ACCOUNT_NAME: Fügen Sie den Namen des Dienstkontos des Abgleichs hinzu. Wenn der RepoSync-Name repo-sync ist, ist SERVICE_ACCOUNT_NAME ns-reconciler-NAMESPACE. Andernfalls ist es ns-reconciler-NAMESPACE-REPO_SYNC_NAME.
   • RECONCILER_ROLE: Als Anwendungsoperator können Sie mit RECONCILER_ROLE festlegen, welche Konfigurationsarten aus der Namespace-bezogenen Source synchronisiert werden können. Sie können die Berechtigungen, die Ihnen der zentrale Administrator gewährt hat, weiterhin einschränken. Daher kann diese Rolle nicht umfangreicher sein als die OPERATOR_ROLE, die der zentrale Administrator im vorherigen Abschnitt deklariert hat.

2. Wenden Sie die RoleBinding-Konfiguration an:

   kubectl apply -f sync-rolebinding.yaml
   

3. Erstellen Sie ein Secret, falls erforderlich, mit Ihrer bevorzugten Authentifizierungsmethode. Wenn Sie none als Authentifizierungstyp verwendet haben, können Sie diesen Schritt überspringen.

   Das Secret muss die folgenden Kriterien erfüllen:

   • Erstellen Sie das Secret im selben Namespace wie RepoSync.
   • Der Name des Secrets muss mit dem Namen spec.git.secretRef übereinstimmen, den Sie in root-sync.yaml definiert haben.
   • Sie müssen den öffentlichen Schlüssel des Secrets dem Git-Anbieter hinzufügen.

4. Deklarieren Sie eine RepoSync-Konfiguration:

   Git

   #ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RepoSync
   metadata:
     name: REPO_SYNC_NAME
     namespace: NAMESPACE
   spec:
     sourceType: git
     # Since this is for a namespace repository, the format is unstructured
     sourceFormat: unstructured
     git:
       repo: NAMESPACE_REPOSITORY
       revision: NAMESPACE_REVISION
       branch: NAMESPACE_BRANCH
       dir: "NAMESPACE_DIRECTORY"
       auth: NAMESPACE_AUTH_TYPE
       gcpServiceAccountEmail: NAMESPACE_EMAIL
       secretRef:
         name: NAMESPACE_SECRET_NAME
       noSSLVerify: NAMESPACE_NO_SSL_VERIFY
       caCertSecretRef:
         name: NAMESPACE_CA_CERT_SECRET_NAME
   

   Ersetzen Sie Folgendes:

   • REPO_SYNC_NAME: Fügen Sie den Namen Ihres RepoSync-Objekts hinzu. Der Name sollte im gesamten Namespace eindeutig sein.
   • NAMESPACE: Fügen Sie den Namen Ihres Namespace hinzu.
   • NAMESPACE_REPOSITORY: Fügen Sie die URL des Git-Repositorys hinzu, das als Namespace-Repository verwendet werden soll. Sie können URLs mithilfe des HTTPS- oder SSH-Protokolls eingeben. https://github.com/GoogleCloudPlatform/anthos-config-management-samples verwendet beispielsweise das HTTPS-Protokoll. Wenn Sie kein Protokoll eingeben, wird die URL als HTTPS-URL behandelt. Dies ist ein Pflichtfeld.
   • NAMESPACE_REVISION: Fügen Sie die Git-Revision (Tag oder Hash) oder den Zweig hinzu, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist HEAD. Wenn Sie einen Hash verwenden, muss es sich um einen vollständigen Hash (nicht um eine abgekürzte Form) handeln.
   • NAMESPACE_BRANCH: Der Zweig des Repositorys, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist master. Wir empfehlen, das Feld revision zu verwenden, um einen Branch-Namen anzugeben. Wenn sowohl das Feld revision als auch das Feld branch angegeben ist, hat revision Vorrang vor branch.

   • NAMESPACE_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:

     • none: Keine Authentifizierung verwenden
     • ssh: Ein SSH-Schlüsselpaar verwenden
     • cookiefile: Nutzen Sie einen cookiefile.
     • token: Ein Token verwenden
     • gcpserviceaccount: Verwenden Sie ein Google-Dienstkonto, um auf ein Repository in Cloud Source Repositories zuzugreifen.

     • gcenode: Verwenden Sie ein Google-Dienstkonto, um auf ein Repository in Cloud Source Repositories zuzugreifen. Wählen Sie diese Option nur aus, wenn Workload Identity Federation for GKE nicht in Ihrem Cluster aktiviert ist.

       Weitere Informationen zu diesen Authentifizierungstypen finden Sie unter Config Sync Lesezugriff auf Git gewähren.

     Dies ist ein Pflichtfeld.

   • NAMESPACE_EMAIL: Wenn Sie gcpserviceaccount für NAMESPACE_AUTH_TYPE angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.

   • NAMESPACE_SECRET_NAME: Fügen Sie den Namen hinzu, den Sie dem Secret geben möchten. Dieses Feld ist optional.

   • NAMESPACE_NO_SSL_VERIFY: Setzen Sie dieses Feld auf true, um die SSL-Zertifikatsüberprüfung zu deaktivieren. Der Standardwert ist false.

   • NAMESPACE_CA_CERT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, muss Ihr Git-Anbieter ein Zertifikat verwenden, das von dieser Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Das Secret muss das CA-Zertifikat unter einem Schlüssel namens cert enthalten. Dieses Feld ist optional.

     Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Zertifizierungsstelle konfigurieren.

   Eine Erläuterung der Felder und eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter RepoSync-Felder.

   OCI

   # ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RepoSync
   metadata:
     name: REPO_SYNC_NAME
     namespace: NAMESPACE
   spec:
     sourceType: oci
     # Since this is for a namespace repository, the format is unstructured
     sourceFormat: unstructured
     oci:
       image: NAMESPACE_IMAGE
       dir: NAMESPACE_DIRECTORY
       auth: NAMESPACE_AUTH_TYPE
       gcpServiceAccountEmail: NAMESPACE_EMAIL
       caCertSecretRef:
         name: NAMESPACE_CA_CERT_SECRET_NAME
   

   Ersetzen Sie Folgendes:

   • REPO_SYNC_NAME: Fügen Sie den Namen Ihres RepoSync-Objekts hinzu. Der Name sollte im gesamten Namespace eindeutig sein.
   • NAMESPACE: Fügen Sie den Namen Ihres Namespace hinzu.

   • NAMESPACE_IMAGE: Die URL des OCI-Images, das als Namespace-Quelle verwendet werden soll, z. B. LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Standardmäßig wird das Image aus dem Tag latest abgerufen, aber Sie können stattdessen Images von TAG oder DIGEST abrufen. Geben Sie TAG oder DIGEST im PACKAGE_NAME an:

     • Zum Abrufen von TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • Zum Abrufen von DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
     Achtung: Config Sync erfordert, dass die OCI-Ebene in der tar oder tar+gzip-Format. Andere Formate (z. B. tar+bz2) werden von Config Sync nicht erkannt. Der Wechsel von einem gültigen REPO-Konto zu einem OCI-Image mit einem nicht unterstützten Format führt dazu, dass verwaltete Ressourcen fehlerfrei gelöscht werden.

   • NAMESPACE_DIRECTORY: Fügen Sie den Pfad in der Quelle zum Stammverzeichnis hinzu, das die Konfiguration enthält, mit der Sie die Synchronisierung durchführen möchten. Dieses Feld ist optional und die Standardeinstellung ist das Stammverzeichnis (/) der Quelle.

   • NAMESPACE_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:

     • none: Keine Authentifizierung verwenden
     • gcenode: Verwenden Sie das Compute Engine-Standarddienstkonto, um auf ein Image in Artifact Registry zuzugreifen. Wählen Sie diese Option nur aus, wenn Workload Identity Federation for GKE in Ihrem Cluster nicht aktiviert ist.
     • gcpserviceaccount: Verwenden Sie ein Google-Dienstkonto für den Zugriff auf ein Image.

     Dies ist ein Pflichtfeld.

   • NAMESPACE_EMAIL: Wenn Sie gcpserviceaccount für ROOT_AUTH_TYPE angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.

   • NAMESPACE_CA_CERT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, muss IhrOCI-Anbieter ein Zertifikat verwenden, das von dieser Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Das Secret muss das CA-Zertifikat unter einem Schlüssel namens cert enthalten. Dieses Feld ist optional.

     Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Zertifizierungsstelle konfigurieren.

   Eine Erläuterung der Felder und eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter RootSync-Felder.

   Helm

   # ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RepoSync
   metadata:
     name: REPO_SYNC_NAME
     namespace: NAMESPACE
   spec:
     sourceType: helm
     # Since this is for a namespace repository, the format is unstructured
     sourceFormat: unstructured
     helm:
       repo: NAMESPACE_REPOSITORY
       chart: HELM_CHART_NAME
       version: HELM_CHART_VERSION
       releaseName: HELM_RELEASE_NAME
       namespace: HELM_RELEASE_NAMESPACE
       values:
         foo:
           bar: VALUE_1
         baz:
         - qux: VALUE_2
           xyz: VALUE_3
       includeCRDs: HELM_INCLUDE_CRDS
       auth: NAMESPACE_AUTH_TYPE
         gcpServiceAccountEmail: NAMESPACE_EMAIL
         secretRef:
           name: NAMESPACE_SECRET_NAME
       caCertSecretRef:
         name: NAMESPACE_CA_CERT_SECRET_NAME
   

   Ersetzen Sie Folgendes:

   • REPO_SYNC_NAME: Fügen Sie den Namen Ihres RepoSync-Objekts hinzu. Der Name sollte im gesamten Namespace eindeutig sein.
   • NAMESPACE: Fügen Sie den Namen Ihres Namespace hinzu.
   • NAMESPACE_REPOSITORY: die URL des Helm-Repositorys, das als Stamm-Repository verwendet werden soll. Sie können URLs mithilfe des HTTPS- oder SSH-Protokolls eingeben. https://github.com/GoogleCloudPlatform/anthos-config-management-samples verwendet beispielsweise das HTTPS-Protokoll. Dies ist ein Pflichtfeld.
   • HELM_CHART_NAME: Fügen Sie den Namen Ihres Helm-Charts hinzu. Dies ist ein Pflichtfeld.
   • HELM_CHART_VERSION: die Version Ihres Diagramms. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird die aktuelle Version verwendet.
   • HELM_RELEASE_NAME: Der Name des Helm-Release. Dieses Feld ist optional.
   • HELM_RELEASE_NAMESPACE: der Ziel-Namespace für einen Release. Ein Namespace wird nur für Ressourcen festgelegt, die in ihren Vorlagen namespace: {{ .Release.Namespace }} enthalten. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird der Standard-Namespace config-management-system verwendet.
   • HELM_INCLUDE_CRDS: Auf true setzen, wenn das Helm-Template auch eine CustomResourceDefinition generieren soll. Dieses Feld ist optional. Wenn kein Wert angegeben ist, lautet der Standardwert false und es wird keine CRD generiert.
   • VALUE: Anstelle der Standardwerte des Helm-Diagramms zu verwendende Werte Formatieren Sie dieses Feld genauso wie die Datei values.yaml des Helm-Diagramms. Dieses Feld ist optional.

   • ROOT_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:

     • none: Keine Authentifizierung verwenden
     • token: Verwenden Sie einen Nutzernamen und ein Passwort, um auf ein privates Helm-Repository zuzugreifen.
     • gcenode: Verwenden Sie das Compute Engine-Standarddienstkonto, um auf ein Image in Artifact Registry zuzugreifen. Wählen Sie diese Option nur aus, wenn Workload Identity Federation for GKE in Ihrem Cluster nicht aktiviert ist.
     • gcpserviceaccount: Verwenden Sie ein Google-Dienstkonto für den Zugriff auf ein Image.

     Dies ist ein Pflichtfeld.

   • NAMESPACE_EMAIL: Wenn Sie gcpserviceaccount für ROOT_AUTH_TYPE angegeben haben, fügen Sie die E-Mail-Adresse Ihres Google-Dienstkontos hinzu. Beispiel: acm@PROJECT_ID.iam.gserviceaccount.com.

   • NAMESPACE_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu, wenn token der ROOT_AUTH_TYPE ist. Dieses Feld ist optional.

   • NAMESPACE_CA_CERT_SECRET_NAME: Fügen Sie den Namen Ihres Secrets hinzu. Ist dieses Feld festgelegt, muss Ihr Helm-Anbieter ein Zertifikat verwenden, das von dieser Zertifizierungsstelle (CA, Certification Authority) ausgestellt wurde. Das Secret muss das CA-Zertifikat unter einem Schlüssel namens cert enthalten. Dieses Feld ist optional.

     Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Zertifizierungsstelle konfigurieren.

   Eine Erläuterung der Felder und eine vollständige Liste der Felder, die Sie dem Feld spec hinzufügen können, finden Sie unter RootSync-Felder.

5. Wenden Sie die Konfiguration RepoSync an:

   kubectl apply -f repo-sync.yaml
   

6. Verwenden Sie kubectl get für eines der Objekte in der Namespace-bezogenen Quelle, um die Konfiguration zu prüfen. Beispiel:

   kubectl get rolebindings -n NAMESPACE
   

7. Sie können die oben genannten Schritte wiederholen, wenn Sie mehrere Namespace-bezogene "Source of Truth" konfigurieren müssen.

Synchronisierungsstatus der „Source of Truth“ prüfen

Mit dem Befehl nomos status können Sie den Synchronisierungsstatus der "Source of Truth" prüfen:

nomos status

Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

my_managed_cluster-1
  --------------------
  <root>   [e-mail]:foo-corp/acme/admin@main
  SYNCED   f52a11e4
  --------------------
  bookstore  [e-mail]:foo-corp/acme/bookstore@v1
  SYNCED     34d1a8c8

In dieser Beispielausgabe wird die Namespace-bezogene Quelle, in diesem Fall ein Git-Repository, für einen Namespace mit dem Namen bookstore konfiguriert.

RootSync-Installation prüfen

Wenn Sie ein RootSync-Objekt erstellen, erstellt Config Sync einen Abgleicher mit dem Präfix root-reconciler. Ein Abgleich ist ein Pod, der als Deployment bereitgestellt wird. Damit werden Manifeste aus einer „Source of Truth“ mit einem Cluster synchronisiert.

Sie können prüfen, ob das RootSync-Objekt ordnungsgemäß funktioniert. Prüfen Sie dazu den Status der Root-Abgleichsbereitstellung:

kubectl get -n config-management-system deployment \
    -l configsync.gke.io/sync-name=ROOT_SYNC_NAME

Ersetzen Sie ROOT_SYNC_NAME durch den Namen von RootSync.

Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

NAME              READY   UP-TO-DATE   AVAILABLE   AGE
root-reconciler   1/1     1            1           3h42m

Weitere Möglichkeiten zur Untersuchung des Status Ihres RootSync-Objekts finden Sie unter RootSync- und RepoSync-Objekte überwachen.

RepoSync-Installation prüfen

Wenn Sie ein RepoSync-Objekt erstellen, erstellt Config Sync einen Abgleich mit dem Präfix ns-reconciler-NAMESPACE, wobei NAMESPACE der Namespace ist, in dem Sie Ihr RepoSync-Objekt erstellt haben.

Sie können prüfen, ob das RepoSync-Objekt ordnungsgemäß funktioniert. Prüfen Sie dazu den Status der Namespace-Abgleichsbereitstellung:

kubectl get -n config-management-system deployment \
  -l configsync.gke.io/sync-name=REPO_SYNC_NAME \
  -l configsync.gke.io/sync-namespace=NAMESPACE

Ersetzen Sie REPO_SYNC_NAME durch den Namen von RepoSync und NAMESPACE durch den Namespace, in dem Sie die Namespace-bezogene "Source of Truth" erstellt haben.

Weitere Möglichkeiten, den Status Ihres RepoSync-Objekts zu untersuchen, finden Sie im Abschnitt RootSync- und RepoSync-Objekte untersuchen.

„Source of Truth“ entfernen

Wählen Sie den Tab Zentrale Steuerungsmethode oder Kubernetes API-Methode aus, um die entsprechende Anleitung aufzurufen.

Zentrale Steuerungsmethode

Wenn Sie die Methode „Source of Truth“ in einer Root of Truth steuern verwendet haben, kann ein zentraler Administrator die folgenden zwei Schritte ausführen, um eine „Source of Truth“ zu entfernen:

1. Entscheiden Sie, ob Sie die Ressourcen löschen oder behalten möchten, die über Ihre RootSync- und RepoSync-Objekte verwaltet werden.

   • Wenn Sie alle Ressourcen löschen möchten, die von Ihren RootSync- oder RepoSync-Objekten verwaltet werden, synchronisieren Sie Ihr RootSync- oder RepoSync-Objekt mit einer leeren Quelle. Ein Beispiel ist ein GitHub-Repository ohne Konfigurationen. Wenn Ihr RootSync- oder RepoSync-Objekt ein anderes RootSync- oder RepoSync-Objekt enthält, muss das innere RootSync- oder RepoSync-Objekt zuerst mit einem leeren Git-Repository synchronisiert werden.

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

2. Entfernen Sie das RootSync- oder RepoSync-Objekt aus der "Source of Truth".

Kubernetes API-Methode

Wenn Sie die Option Namespace-bezogene „Source of Truth“ mit der Kubernetes API steuern verwendet, können Anwendungsoperatoren die folgenden Schritte ausführen, um eine Namespace-bezogene „Source of Truth“ zu entfernen:

1. Entscheiden Sie, ob Sie die Ressourcen löschen oder behalten möchten, die über Ihre RootSync- und RepoSync-Objekte verwaltet werden.

   • Wenn Sie alle Ressourcen löschen möchten, die von Ihren RootSync- oder RepoSync-Objekten verwaltet werden, synchronisieren Sie Ihr RootSync- oder RepoSync-Objekt mit einer leeren Quelle. Ein Beispiel ist ein GitHub-Repository ohne Konfigurationen. Wenn Ihr RootSync- oder RepoSync-Objekt ein anderes RootSync- oder RepoSync-Objekt enthält, muss das innere RootSync- oder RepoSync-Objekt zuerst mit einem leeren Git-Repository synchronisiert werden.

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

2. Löschen Sie das RootSync- oder RepoSync-Objekt. Führen Sie dazu den folgenden Befehl aus:

   kubectl delete -f FILE_NAME
   

   Ersetzen Sie FILE_NAME durch den Namen Ihrer RootSync- oder RepoSync-Konfigurationsdatei. Beispiel: root-sync.yaml.

Nächste Schritte

• Erfahren Sie, wie Sie Konfigurations-Drift in Namespace-bezogenen "Sources of Truth" verhindern können.
• Monitoring von RootSync- und RepoSync-Objekten.
• Weitere Informationen dazu, wie Sie eine „Source of Truth“ in mehrere „Sources of Truth“ aufteilen