Synchronisierung von mehr als einer „Source of Truth“ 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-Source-of-Truth können Sie clusterbezogene und Namespace-bezogene Konfigurationen synchronisieren. Eine Root-Datenquelle kann mit Anmeldedaten auf Administratorebene Richtlinien für Anwendungs-Namespaces erzwingen und lokale Änderungen überschreiben, die von dem in Ihren Konfigurationen deklarierten Status abweichen. Die Root-Datenquellen werden in der Regel von einem zentralen Administrator verwaltet.

Namespace-bezogene „Source of Truth“-Quellen sind optional und können Namespace-bezogene Konfigurationen enthalten, die clusterübergreifend mit einem bestimmten Namespace synchronisiert sind. Sie können die Einrichtung und Steuerung einer Namespace-bezogenen Source of Truth an Nutzer ohne Administratorberechtigungen delegieren. Obwohl Config Sync Änderungen in Bezug auf die „Source of Truth“ automatisch erkennt, können Sie eine zusätzliche Ebene der Drifterkennung hinzufügen, indem Sie einer Namespace-bezogenen „Source of Truth“ einen Zulassungs-Webhook hinzufügen. Weitere Informationen finden Sie unter Konfigurationsabweichungen verhindern.

Hinweise

Erstellen Sie eine unstrukturierte Datenquelle, die die Konfigurationen enthalten kann, mit denen Config Sync synchronisiert wird, oder sorgen Sie dafür, dass Sie Zugriff darauf haben. 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, der sich auf einer unterstützten Plattform sowie in einer unterstützten Version der Google Kubernetes Engine (GKE) Enterprise-Version befindet und die Anforderungen für Config Sync erfüllt, oder prüfen Sie, ob Sie Zugriff darauf haben.

Beschränkungen

NamespaceSelectors (einschließlich Annotationen, die auf Selektoren verweisen) funktionieren nur in einer Root-Quelle.
Wenn Sie Config Sync über die Google Cloud Console oder die Google Cloud CLI installiert haben, hat Config Sync automatisch ein RootSync-Objekt mit dem Namen root-sync erstellt. Daher können Sie Ihre RootSync-Objekte nicht mit dem Namen root-sync versehen.

Bevorzugte Konfigurationsmethode auswählen

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

Steuern Sie Quellen in einer Root Source of Truth. Bei dieser Methode wird die gesamte Konfiguration einer „Source of Truth“ in einer anderen „Source of Truth“ zentralisiert, was einem zentralen Administrator die vollständige Kontrolle über die Einrichtung ermöglicht.
Quellen mit der Kubernetes API steuern Verwenden Sie diese Methode, wenn Sie die Kontrolle über Ihre zentrale Informationsquelle an verschiedene Inhaber delegieren möchten.

Quellen in einer Root Source of Truth verwalten

Root-Quellen in einer Root Source of Truth verwalten

Config Sync unterstützt die Synchronisierung von mehr als einer „Source of Truth“. Der zentrale Administrator kann eine Root Source of Truth verwenden, um alle anderen Quellen zu verwalten. Da Config Sync die RootSync-Objekte verwaltet, verhindert diese Methode lokale Änderungen an RootSync-Konfigurationen im Cluster.

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

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-Version (Tag oder Hash) hinzu, von der aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist HEAD. Ab Config Sync Version 1.17.0 können Sie im Feld revision auch einen Zweignamen angeben. In Version 1.17.0 oder höher muss ein Hashwert und keine verkürzte Form verwendet werden.
- ROOT_BRANCH: Fügen Sie den Zweig des Repositorys hinzu, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist master. Ab Config Sync Version 1.17.0 wird der Einfachheit halber empfohlen, das Feld revision zu verwenden, um einen Zweignamen anzugeben. Wenn sowohl das Feld revision als auch das Feld branch angegeben sind, hat revision Vorrang vor branch.
- ROOT_DIRECTORY: Fügen Sie den Pfad im Git-Repository zum Stammverzeichnis hinzu, das die Konfiguration enthält, mit der Sie die Synchronisierung durchführen möchten. Dieses Feld ist optional und die Standardeinstellung ist das Stammverzeichnis (/) des Repositorys.
- ROOT_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:
  - none: Keine Authentifizierung verwenden
  - ssh: Ein SSH-Schlüsselpaar verwenden
  - cookiefile: Nutzen Sie einen cookiefile.
  - token: Ein Token verwenden
  - gcpserviceaccount: Mit einem Google-Dienstkonto auf Cloud Source Repositories zugreifen
  - gcenode: Mit einem Google-Dienstkonto auf Cloud Source Repositories zugreifen Wählen Sie diese Option nur aus, wenn Workload Identity 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 mit dem Namen cert enthalten. Dieses Feld ist optional.
  
  Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Operator für eine 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
```
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 :Für Config Sync muss die OCI-Ebene in der tar oder der tar+gzip komprimiert werden. Andere Formate (z. B. tar+bz2) werden von Config Sync nicht erkannt. Wenn Sie von einem gültigen REPO zu einem OCI-Image mit einem nicht unterstützten Format wechseln, werden verwaltete Ressourcen ohne Fehler entfernt.
- 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 nicht in Ihrem Cluster 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.
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
```
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 Root-Repository verwendet werden soll. Sie können URLs entweder mit dem HTTPS- oder SSH-Protokoll 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-Diagramms hinzu. Dies ist ein Pflichtfeld.
- HELM_CHART_VERSION: die Version Ihres Diagramms. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird die neueste Version verwendet.
- HELM_RELEASE_NAME: der Name der Helm-Version. Dieses Feld ist optional.
- HELM_RELEASE_NAMESPACE: Der Ziel-Namespace für einen Release. Ein Namespace wird nur für Ressourcen festgelegt, die namespace: {{ .Release.Namespace }} in ihren Vorlagen enthalten. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird der Standard-Namespace config-management-system verwendet.
- HELM_INCLUDE_CRDS: Legen Sie dafür true fest, wenn die Helm-Vorlage auch eine CustomResourceDefinition generieren soll. Dieses Feld ist optional. Wenn kein Wert angegeben ist, ist der Standardwert false und es wird keine CRD generiert.
- VALUE: Werte, die anstelle der Standardwerte im Helm-Diagramm verwendet werden sollen. 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 nicht in Ihrem Cluster 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 Wert ROOT_AUTH_TYPE ist. Dieses Feld ist optional.
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.

Ü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

Sie können die oben genannten Schritte wiederholen, wenn Sie mehrere Stammquellen konfigurieren müssen. Sie können auch Konfigurationen mehrerer RootSync-Objekte in einer Root-Quelle speichern, die von einem anderen RootSync-Objekt synchronisiert wird, um mehrere RootSync-Objekte zentral in GitOps zu verwalten.

Namespace-bezogene Objekte in einer Root-Source of Truth steuern

Namespace-bezogene „Source of Truth“ kann eine Root-Source of Truth nutzen. Da die Namespace-bezogenen Quellen von Config Sync verwaltet werden, verhindert diese Methode lokale Änderungen an den Namespace-bezogenen Quelldefinitionen.

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

Deklarieren Sie in der Root-Source of Truth eine namespace-Konfiguration:
```
# ROOT_SOURCE/namespaces/NAMESPACE/namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: NAMESPACE
```
Ersetzen Sie NAMESPACE durch einen Namen für den Namespace.
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-Version (Tag oder Hash) hinzu, von der aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist HEAD. Ab Config Sync Version 1.17.0 können Sie im Feld revision auch einen Zweignamen angeben. In Version 1.17.0 oder höher muss ein Hashwert und keine verkürzte Form verwendet werden.
- NAMESPACE_BRANCH: Fügen Sie den Zweig des Repositorys hinzu, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist master. Ab Config Sync Version 1.17.0 wird der Einfachheit halber empfohlen, das Feld revision zu verwenden, um einen Zweignamen anzugeben. Wenn sowohl das Feld revision als auch das Feld branch angegeben sind, hat revision Vorrang vor branch.
- 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 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 mit dem Namen cert enthalten. Dieses Feld ist optional.
  
  Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Operator für eine 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
```
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 in 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 :Für Config Sync muss die OCI-Ebene in der tar oder der tar+gzip komprimiert werden. Andere Formate (z. B. tar+bz2) werden von Config Sync nicht erkannt. Wenn Sie von einem gültigen REPO zu einem OCI-Image mit einem nicht unterstützten Format wechseln, werden verwaltete Ressourcen ohne Fehler entfernt.
- NAMESPACE_DIRECTORY: Fügen Sie den Pfad in der Quelle dem Stammverzeichnis hinzu, das die Konfiguration enthält, mit der Sie synchronisieren möchten. Dieses Feld ist optional und standardmäßig 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 nicht in Ihrem Cluster 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.
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
```
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 Root-Repository verwendet werden soll. Sie können URLs entweder mit dem HTTPS- oder SSH-Protokoll 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-Diagramms hinzu. Dies ist ein Pflichtfeld.
- HELM_CHART_VERSION: die Version Ihres Diagramms. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird die neueste Version verwendet.
- HELM_RELEASE_NAME: der Name der Helm-Version. Dieses Feld ist optional.
- HELM_RELEASE_NAMESPACE: Der Ziel-Namespace für einen Release. Ein Namespace wird nur für Ressourcen festgelegt, die namespace: {{ .Release.Namespace }} in ihren Vorlagen enthalten. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird der Standard-Namespace config-management-system verwendet.
- HELM_INCLUDE_CRDS: Legen Sie dafür true fest, wenn die Helm-Vorlage auch eine CustomResourceDefinition generieren soll. Dieses Feld ist optional. Wenn kein Wert angegeben ist, ist der Standardwert false und es wird keine CRD generiert.
- VALUE: Werte, die anstelle der Standardwerte im Helm-Diagramm verwendet werden sollen. 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 nicht in Ihrem Cluster 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 Wert ROOT_AUTH_TYPE ist. Dieses Feld ist optional.
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.
Wenn Sie gcpserviceaccount als Authentifizierungstyp verwenden und Workload Identity 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.
Geben Sie in der Stammquelle eine RoleBinding-Konfiguration an, die dem Dienstkonto SERVICE_ACCOUNT_NAME die Berechtigung zum Verwalten von Objekten im Namespace erteilt. 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 einen ClusterRole verweisen und diesen ClusterRole an den Namespace von RoleBinding binden. Sie sollten zwar das Prinzip der geringsten Berechtigung einhalten, indem Sie einer benutzerdefinierten Role detaillierte Berechtigungen gewähren. Sie können jedoch eine ClusterRole definieren oder nutzerseitige Rollen verwenden und auf dieselbe ClusterRole in mehreren RoleBindings in verschiedenen Namespaces verweisen.

Hinweis: Ein RoleBinding, der auf einen ClusterRole verweist, ermöglicht Ihnen nur Zugriff auf den Namespace des RoleBinding, aber keinen clusterweiten Zugriff.
Standard-ClusterRoles
Sie können eine RoleBinding deklarieren, die auf eine Standard-ClusterRole verweist, z. B. admin oder edit. Weitere Informationen finden Sie unter Rollen für Nutzer.
```
# ROOT_REPO/namespaces/NAMESPACE/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: CLUSTERROLE_NAME
  apiGroup: rbac.authorization.k8s.io
```
Ersetzen Sie Folgendes:
- 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 lautet, 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 der Wert ns-reconciler-NAMESPACE-prod-4. Die Ganzzahl 4 wird verwendet, wenn prod 4 Zeichen enthält.
- CLUSTERROLE_NAME: Fügen Sie den Namen der Standard-ClusterRole hinzu.
Benutzerdefinierte Rollen
Sie können einen ClusterRole oder Role deklarieren, indem Sie jeder Ressource, die vom Objekt RepoSync verwaltet wird, eine Liste von Berechtigungen erteilen. Dies ermöglicht detaillierte Berechtigungen. Weitere Informationen finden Sie unter Auf Ressourcen verweisen.

Die folgende ClusterRole oder Role gewährt beispielsweise Berechtigungen zum Verwalten von Deployment- und ServiceAccount-Objekten.
```
# 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: ["*"]
```
Zum Deklarieren einer RoleBinding, die auf ClusterRole oder Role verweist, erstellen Sie das folgende Objekt. Die RoleBinding gewährt zusätzliche Berechtigungen, damit Config Sync Namespace-bezogene Ressourcen für eine bestimmte RepoSync verwalten kann.
```
# ROOT_REPO/namespaces/NAMESPACE/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: ROLE_KIND
  name: RECONCILER_ROLE
  apiGroup: rbac.authorization.k8s.io
```
Ersetzen Sie Folgendes:
- ROLE_KIND: Legen Sie ClusterRole oder Role fest.
- 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 lautet, 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 der Wert ns-reconciler-NAMESPACE-prod-4. Die Ganzzahl 4 wird verwendet, wenn prod 4 Zeichen enthält.
- RECONCILER_ROLE: Fügen Sie den Namen von ClusterRole oder Role hinzu.

Ü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

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.
Verwenden Sie zum Prüfen der Konfiguration kubectl get für eines der Objekte in der Namespace-Quelle. Beispiel:
```
kubectl get rolebindings -n NAMESPACE
```
Sie können die obigen 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“ mit einer Namespace-bezogenen „Source of Truth“ im selben Namespace.

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

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-Version (Tag oder Hash) hinzu, von der aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist HEAD. Ab Config Sync Version 1.17.0 können Sie im Feld revision auch einen Zweignamen angeben. In Version 1.17.0 oder höher muss ein Hashwert und keine verkürzte Form verwendet werden.
- NAMESPACE_BRANCH: Fügen Sie den Zweig des Repositorys hinzu, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist master. Ab Config Sync Version 1.17.0 wird der Einfachheit halber empfohlen, das Feld revision zu verwenden, um einen Zweignamen anzugeben. Wenn sowohl das Feld revision als auch das Feld branch angegeben sind, hat revision Vorrang vor branch.
- 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 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 mit dem Namen cert enthalten. Dieses Feld ist optional.
  
  Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Operator für eine 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
```
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 in 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 :Für Config Sync muss die OCI-Ebene in der tar oder der tar+gzip komprimiert werden. Andere Formate (z. B. tar+bz2) werden von Config Sync nicht erkannt. Wenn Sie von einem gültigen REPO zu einem OCI-Image mit einem nicht unterstützten Format wechseln, werden verwaltete Ressourcen ohne Fehler entfernt.
- NAMESPACE_DIRECTORY: Fügen Sie den Pfad in der Quelle dem Stammverzeichnis hinzu, das die Konfiguration enthält, mit der Sie synchronisieren möchten. Dieses Feld ist optional und standardmäßig 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 nicht in Ihrem Cluster 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.
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
```
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 Root-Repository verwendet werden soll. Sie können URLs entweder mit dem HTTPS- oder SSH-Protokoll 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-Diagramms hinzu. Dies ist ein Pflichtfeld.
- HELM_CHART_VERSION: die Version Ihres Diagramms. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird die neueste Version verwendet.
- HELM_RELEASE_NAME: der Name der Helm-Version. Dieses Feld ist optional.
- HELM_RELEASE_NAMESPACE: Der Ziel-Namespace für einen Release. Ein Namespace wird nur für Ressourcen festgelegt, die namespace: {{ .Release.Namespace }} in ihren Vorlagen enthalten. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird der Standard-Namespace config-management-system verwendet.
- HELM_INCLUDE_CRDS: Legen Sie dafür true fest, wenn die Helm-Vorlage auch eine CustomResourceDefinition generieren soll. Dieses Feld ist optional. Wenn kein Wert angegeben ist, ist der Standardwert false und es wird keine CRD generiert.
- VALUE: Werte, die anstelle der Standardwerte im Helm-Diagramm verwendet werden sollen. 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 nicht in Ihrem Cluster 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 Wert ROOT_AUTH_TYPE ist. Dieses Feld ist optional.
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.
Wenn Sie gcpserviceaccount als Authentifizierungstyp verwenden und Workload Identity 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.
Geben Sie in der Stammquelle eine RoleBinding-Konfiguration an, die dem Dienstkonto SERVICE_ACCOUNT_NAME die Berechtigung zum Verwalten von Objekten im Namespace erteilt. 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 einen ClusterRole verweisen und diesen ClusterRole an den Namespace von RoleBinding binden. Sie sollten zwar das Prinzip der geringsten Berechtigung einhalten, indem Sie einer benutzerdefinierten Role detaillierte Berechtigungen gewähren. Sie können jedoch eine ClusterRole definieren oder nutzerseitige Rollen verwenden und auf dieselbe ClusterRole in mehreren RoleBindings in verschiedenen Namespaces verweisen.

Hinweis: Ein RoleBinding, der auf einen ClusterRole verweist, ermöglicht Ihnen nur Zugriff auf den Namespace des RoleBinding, aber keinen clusterweiten Zugriff.
Standard-ClusterRoles
Sie können eine RoleBinding deklarieren, die auf eine Standard-ClusterRole verweist, z. B. admin oder edit. Weitere Informationen finden Sie unter Rollen für Nutzer.
```
# ROOT_REPO/namespaces/NAMESPACE/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: CLUSTERROLE_NAME
  apiGroup: rbac.authorization.k8s.io
```
Ersetzen Sie Folgendes:
- 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 lautet, 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 der Wert ns-reconciler-NAMESPACE-prod-4. Die Ganzzahl 4 wird verwendet, wenn prod 4 Zeichen enthält.
- CLUSTERROLE_NAME: Fügen Sie den Namen der Standard-ClusterRole hinzu.
Benutzerdefinierte Rollen
Sie können einen ClusterRole oder Role deklarieren, indem Sie jeder Ressource, die vom Objekt RepoSync verwaltet wird, eine Liste von Berechtigungen erteilen. Dies ermöglicht detaillierte Berechtigungen. Weitere Informationen finden Sie unter Auf Ressourcen verweisen.

Die folgende ClusterRole oder Role gewährt beispielsweise Berechtigungen zum Verwalten von Deployment- und ServiceAccount-Objekten.
```
# 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: ["*"]
```
Zum Deklarieren einer RoleBinding, die auf ClusterRole oder Role verweist, erstellen Sie das folgende Objekt. Die RoleBinding gewährt zusätzliche Berechtigungen, damit Config Sync Namespace-bezogene Ressourcen für eine bestimmte RepoSync verwalten kann.
```
# ROOT_REPO/namespaces/NAMESPACE/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: ROLE_KIND
  name: RECONCILER_ROLE
  apiGroup: rbac.authorization.k8s.io
```
Ersetzen Sie Folgendes:
- ROLE_KIND: Legen Sie ClusterRole oder Role fest.
- 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 lautet, 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 der Wert ns-reconciler-NAMESPACE-prod-4. Die Ganzzahl 4 wird verwendet, wenn prod 4 Zeichen enthält.
- RECONCILER_ROLE: Fügen Sie den Namen von ClusterRole oder Role hinzu.

Ü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

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.
Zum Prüfen der Konfiguration verwenden Sie kubectl get für eines der Objekte in der Namespace-bezogenen „Source of Truth“. Beispiel:
```
kubectl get rolebindings -n NAMESPACE
```
Sie können die obigen 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 den Namespace nur in der Root-Quelle der Wahrheit und delegiert die Deklaration des RepoSync-Objekts an den Anwendungsoperator.

Mehr als eine Root Source Of Truth verwalten

Andere Administratoren können eine „Root of Truth“ verwalten, indem sie die folgenden Aufgaben ausführen:

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-Version (Tag oder Hash) hinzu, von der aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist HEAD. Ab Config Sync Version 1.17.0 können Sie im Feld revision auch einen Zweignamen angeben. In Version 1.17.0 oder höher muss ein Hashwert und keine verkürzte Form verwendet werden.
- ROOT_BRANCH: Fügen Sie den Zweig des Repositorys hinzu, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist master. Ab Config Sync Version 1.17.0 wird der Einfachheit halber empfohlen, das Feld revision zu verwenden, um einen Zweignamen anzugeben. Wenn sowohl das Feld revision als auch das Feld branch angegeben sind, hat revision Vorrang vor branch.
- ROOT_DIRECTORY: Fügen Sie den Pfad im Git-Repository zum Stammverzeichnis hinzu, das die Konfiguration enthält, mit der Sie die Synchronisierung durchführen möchten. Dieses Feld ist optional und die Standardeinstellung ist das Stammverzeichnis (/) des Repositorys.
- ROOT_AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:
  - none: Keine Authentifizierung verwenden
  - ssh: Ein SSH-Schlüsselpaar verwenden
  - cookiefile: Nutzen Sie einen cookiefile.
  - token: Ein Token verwenden
  - gcpserviceaccount: Mit einem Google-Dienstkonto auf Cloud Source Repositories zugreifen
  - gcenode: Mit einem Google-Dienstkonto auf Cloud Source Repositories zugreifen Wählen Sie diese Option nur aus, wenn Workload Identity 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 mit dem Namen cert enthalten. Dieses Feld ist optional.
  
  Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Operator für eine 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
```
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 :Für Config Sync muss die OCI-Ebene in der tar oder der tar+gzip komprimiert werden. Andere Formate (z. B. tar+bz2) werden von Config Sync nicht erkannt. Wenn Sie von einem gültigen REPO zu einem OCI-Image mit einem nicht unterstützten Format wechseln, werden verwaltete Ressourcen ohne Fehler entfernt.
- 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 nicht in Ihrem Cluster 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.
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
```
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 Root-Repository verwendet werden soll. Sie können URLs entweder mit dem HTTPS- oder SSH-Protokoll 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-Diagramms hinzu. Dies ist ein Pflichtfeld.
- HELM_CHART_VERSION: die Version Ihres Diagramms. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird die neueste Version verwendet.
- HELM_RELEASE_NAME: der Name der Helm-Version. Dieses Feld ist optional.
- HELM_RELEASE_NAMESPACE: Der Ziel-Namespace für einen Release. Ein Namespace wird nur für Ressourcen festgelegt, die namespace: {{ .Release.Namespace }} in ihren Vorlagen enthalten. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird der Standard-Namespace config-management-system verwendet.
- HELM_INCLUDE_CRDS: Legen Sie dafür true fest, wenn die Helm-Vorlage auch eine CustomResourceDefinition generieren soll. Dieses Feld ist optional. Wenn kein Wert angegeben ist, ist der Standardwert false und es wird keine CRD generiert.
- VALUE: Werte, die anstelle der Standardwerte im Helm-Diagramm verwendet werden sollen. 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 nicht in Ihrem Cluster 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 Wert ROOT_AUTH_TYPE ist. Dieses Feld ist optional.
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.
Änderungen anwenden:
```
kubectl apply -f root-sync.yaml
```
Sie können die oben genannten Schritte wiederholen, wenn Sie mehr als eine Root of Truth konfigurieren müssen.

Namespace-bezogene „Sources of Truth“ steuern

Zentrale Administratoraufgaben

Der zentrale Administrator führt die folgenden Aufgaben aus:

Deklarieren Sie in der Root-Quelle 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.
Deklarieren Sie in der Root-Source of Truth einen 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 als Root Source of Truth erstellt haben.
- USERNAME: Fügen Sie den Nutzernamen des Anwendungsoperators hinzu.
- OPERATOR_ROLE: Als zentraler Administrator können Sie OPERATOR_ROLE festlegen, um zu erzwingen, welche Arten von Konfigurationen aus der Namespace-bezogenen Quelle 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-Quelle deklariert ist. Diese Rolle ermöglicht differenzierte Berechtigungen.

Ü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:

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 als 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 RECONCILER_ROLE festlegen, um zu erzwingen, welche Arten von Konfigurationen aus der Namespace-bezogenen Quelle 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.
Wenden Sie die RoleBinding-Konfiguration an:
```
kubectl apply -f sync-rolebinding.yaml
```
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.
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-Version (Tag oder Hash) hinzu, von der aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist HEAD. Ab Config Sync Version 1.17.0 können Sie im Feld revision auch einen Zweignamen angeben. In Version 1.17.0 oder höher muss ein Hashwert und keine verkürzte Form verwendet werden.
- NAMESPACE_BRANCH: Fügen Sie den Zweig des Repositorys hinzu, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist master. Ab Config Sync Version 1.17.0 wird der Einfachheit halber empfohlen, das Feld revision zu verwenden, um einen Zweignamen anzugeben. Wenn sowohl das Feld revision als auch das Feld branch angegeben sind, hat revision Vorrang vor branch.
- 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 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 mit dem Namen cert enthalten. Dieses Feld ist optional.
  
  Weitere Informationen zum Konfigurieren des Secret-Objekts für das CA-Zertifikat finden Sie unter Operator für eine 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
```
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 in 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 :Für Config Sync muss die OCI-Ebene in der tar oder der tar+gzip komprimiert werden. Andere Formate (z. B. tar+bz2) werden von Config Sync nicht erkannt. Wenn Sie von einem gültigen REPO zu einem OCI-Image mit einem nicht unterstützten Format wechseln, werden verwaltete Ressourcen ohne Fehler entfernt.
- NAMESPACE_DIRECTORY: Fügen Sie den Pfad in der Quelle dem Stammverzeichnis hinzu, das die Konfiguration enthält, mit der Sie synchronisieren möchten. Dieses Feld ist optional und standardmäßig 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 nicht in Ihrem Cluster 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.
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
```
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 Root-Repository verwendet werden soll. Sie können URLs entweder mit dem HTTPS- oder SSH-Protokoll 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-Diagramms hinzu. Dies ist ein Pflichtfeld.
- HELM_CHART_VERSION: die Version Ihres Diagramms. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird die neueste Version verwendet.
- HELM_RELEASE_NAME: der Name der Helm-Version. Dieses Feld ist optional.
- HELM_RELEASE_NAMESPACE: Der Ziel-Namespace für einen Release. Ein Namespace wird nur für Ressourcen festgelegt, die namespace: {{ .Release.Namespace }} in ihren Vorlagen enthalten. Dieses Feld ist optional. Wenn kein Wert angegeben ist, wird der Standard-Namespace config-management-system verwendet.
- HELM_INCLUDE_CRDS: Legen Sie dafür true fest, wenn die Helm-Vorlage auch eine CustomResourceDefinition generieren soll. Dieses Feld ist optional. Wenn kein Wert angegeben ist, ist der Standardwert false und es wird keine CRD generiert.
- VALUE: Werte, die anstelle der Standardwerte im Helm-Diagramm verwendet werden sollen. 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 nicht in Ihrem Cluster 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 Wert ROOT_AUTH_TYPE ist. Dieses Feld ist optional.
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.
Wenden Sie die Konfiguration RepoSync an:
```
kubectl apply -f repo-sync.yaml
```
Prüfen Sie die Konfiguration mit kubectl get für eines der Objekte in der Namespace-bezogenen Quelle. Beispiel:
```
kubectl get rolebindings -n NAMESPACE
```
Sie können die obigen 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>   git@github.com:foo-corp/acme/admin@main
  SYNCED   f52a11e4
  --------------------
  bookstore  git@github.com: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. Es synchronisiert Manifeste aus einer „Source of Truth“ mit einem Cluster.

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 Quellen der Wahrheit in einer Root-Datenquelle verwalten verwendet haben, kann ein zentraler Administrator die folgenden zwei Schritte ausführen, um eine „Source of Truth“ zu entfernen:

Entscheiden Sie, ob Sie die über Ihre RootSync- und RepoSync-Objekte verwalteten Ressourcen löschen oder behalten möchten.
- Wenn Sie alle Ressourcen löschen möchten, die von Ihren RootSync- oder RepoSync-Objekten verwaltet werden, synchronisieren Sie das RootSync- oder RepoSync-Objekt mit einer leeren Quelle. Beispiel: 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 die Ressourcen behalten möchten, heben Sie die Verwaltung der Ressourcen auf. Folgen Sie dazu der Anleitung zur Fehlerbehebung. Wenn Sie den Webhook nicht aktiviert haben, müssen Sie keine zusätzlichen Schritte unternehmen, um Ihre Ressourcen zu behalten.
Entfernen Sie das RootSync- oder RepoSync-Objekt aus der „Source of Truth“.

Kubernetes API-Methode

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

Entscheiden Sie, ob Sie die über Ihre RootSync- und RepoSync-Objekte verwalteten Ressourcen löschen oder behalten möchten.
- Wenn Sie alle Ressourcen löschen möchten, die von Ihren RootSync- oder RepoSync-Objekten verwaltet werden, synchronisieren Sie das RootSync- oder RepoSync-Objekt mit einer leeren Quelle. Beispiel: 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 die Ressourcen behalten möchten, heben Sie die Verwaltung der Ressourcen auf. Folgen Sie dazu der Anleitung zur Fehlerbehebung. Wenn Sie den Webhook nicht aktiviert haben, müssen Sie keine zusätzlichen Schritte unternehmen, um Ihre Ressourcen zu behalten.
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.

Synchronisierung von mehr als einer „Source of Truth“ konfigurieren

Hinweise

Beschränkungen

Bevorzugte Konfigurationsmethode auswählen

Quellen in einer Root Source of Truth verwalten

Root-Quellen in einer Root Source of Truth verwalten

Git

OCI

Helm

Namespace-bezogene Objekte in einer Root-Source of Truth steuern

Git

OCI

Helm

Standard-ClusterRoles

Benutzerdefinierte Rollen

Namespace-bezogene Quellen in einer Namespace-bezogenen Quelle steuern

Git

OCI

Helm

Standard-ClusterRoles

Benutzerdefinierte Rollen

„Source of Truth“ mit der Kubernetes API steuern

Mehr als eine Root Source Of Truth verwalten

Git

OCI

Helm

Namespace-bezogene „Sources of Truth“ steuern

Zentrale Administratoraufgaben

Aufgaben des Anwendungsoperators

Git

OCI

Helm

Synchronisierungsstatus der „Source of Truth“ prüfen

RootSync-Installation prüfen

RepoSync-Installation prüfen

„Source of Truth“ entfernen

Zentrale Steuerungsmethode

Kubernetes API-Methode

Nächste Schritte