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 (GKE) Enterprise (GKE) Enterprise-Version 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.

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

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:

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) 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 auch einen Zweignamen im Feld revision angeben. Wenn Sie einen Hash in Version 1.17.0 oder höher 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. Ab Config Sync Version 1.17.0 wird 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 namens 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
    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 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_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 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 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 des 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 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: Legen Sie 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: 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 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 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 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 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 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:

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.
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) 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 auch einen Zweignamen im Feld revision angeben. Wenn Sie einen Hash in Version 1.17.0 oder höher 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. Ab Config Sync Version 1.17.0 wird 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 namens 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
    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 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_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 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.
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 des 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 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: Legen Sie 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: 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 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 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 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.
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 das Google-Dienstkonto erstellen. Eine Anleitung zum Erstellen dieser Bindung finden Sie unter Zugriff auf Git gewähren.
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 einen 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 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 Ihnen nur Zugriff auf den Namespace von RoleBinding, aber nicht auf den 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 Nutzerbezogene Rollen.
```
# 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 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 4 Zeichen enthält.
- CLUSTERROLE_NAME: Fügen Sie den Namen der Standard-ClusterRole hinzu.
Benutzerdefinierte Rollen
Sie können eine ClusterRole oder Role deklarieren, indem Sie jeder Ressource, die vom Objekt RepoSync verwaltet wird, eine Liste von Berechtigungen zuweisen. Dies ermöglicht präzise Berechtigungen. Weitere Informationen finden Sie unter Auf Ressourcen verweisen.

Die folgenden ClusterRole oder Role gewähren beispielsweise Berechtigungen zum Verwalten der Objekte Deployment und ServiceAccount.
```
# 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: ["*"]
```
Erstellen Sie das folgende Objekt, um eine RoleBinding zu deklarieren, die auf ClusterRole oder Role verweist. RoleBinding gewährt zusätzliche Berechtigungen, damit Config Sync Namespace-bezogene Ressourcen für eine 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 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 4 Zeichen enthält.
- RECONCILER_ROLE: Fügen Sie den Namen von ClusterRole oder Role hinzu.

Übernehmen Sie die Änderungen für die Root 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 kubectl get für eines der Objekte in der Namespace Source um die Konfiguration zu prüfen. Beispiel:
```
kubectl get rolebindings -n NAMESPACE
```
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:

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) 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 auch einen Zweignamen im Feld revision angeben. Wenn Sie einen Hash in Version 1.17.0 oder höher 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. Ab Config Sync Version 1.17.0 wird 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 namens 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
    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 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_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 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.
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 des 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 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: Legen Sie 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: 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 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 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 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.
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 das Google-Dienstkonto erstellen. Eine Anleitung zum Erstellen dieser Bindung finden Sie unter Zugriff auf Git gewähren.
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 einen 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 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 Ihnen nur Zugriff auf den Namespace von RoleBinding, aber nicht auf den 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 Nutzerbezogene Rollen.
```
# 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 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 4 Zeichen enthält.
- CLUSTERROLE_NAME: Fügen Sie den Namen der Standard-ClusterRole hinzu.
Benutzerdefinierte Rollen
Sie können eine ClusterRole oder Role deklarieren, indem Sie jeder Ressource, die vom Objekt RepoSync verwaltet wird, eine Liste von Berechtigungen zuweisen. Dies ermöglicht präzise Berechtigungen. Weitere Informationen finden Sie unter Auf Ressourcen verweisen.

Die folgenden ClusterRole oder Role gewähren beispielsweise Berechtigungen zum Verwalten der Objekte Deployment und ServiceAccount.
```
# 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: ["*"]
```
Erstellen Sie das folgende Objekt, um eine RoleBinding zu deklarieren, die auf ClusterRole oder Role verweist. RoleBinding gewährt zusätzliche Berechtigungen, damit Config Sync Namespace-bezogene Ressourcen für eine 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 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 4 Zeichen enthält.
- RECONCILER_ROLE: Fügen Sie den Namen von ClusterRole oder Role hinzu.

Übernehmen Sie die Änderungen für die Root 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 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
```
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:

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) 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 auch einen Zweignamen im Feld revision angeben. Wenn Sie einen Hash in Version 1.17.0 oder höher 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. Ab Config Sync Version 1.17.0 wird 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 namens 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
    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 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_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 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 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 des 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 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: Legen Sie 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: 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 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 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 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 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 Source 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 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.
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.

Übernehmen Sie die Änderungen für die Root 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 in der Root 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.
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-Revision (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 auch einen Zweignamen im Feld revision angeben. Wenn Sie einen Hash in Version 1.17.0 oder höher 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. Ab Config Sync Version 1.17.0 wird 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 namens 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
    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 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_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 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.
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 des 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 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: Legen Sie 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: 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 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 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 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.
Wenden Sie die Konfiguration RepoSync an:
```
kubectl apply -f repo-sync.yaml
```
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
```
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>   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. 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:

Entscheiden Sie, ob Sie die Ressourcen, die über Ihre RootSync- und RepoSync-Objekte verwaltet werden, löschen oder beibehalten möchten.
- Um alle Ressourcen zu löschen, die von Ihren RootSync- oder RepoSync-Objekten verwaltet werden, synchronisieren Sie Ihr 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 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.
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:

Entscheiden Sie, ob Sie die Ressourcen, die über Ihre RootSync- und RepoSync-Objekte verwaltet werden, löschen oder beibehalten möchten.
- Um alle Ressourcen zu löschen, die von Ihren RootSync- oder RepoSync-Objekten verwaltet werden, synchronisieren Sie Ihr 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 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.
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

Synchronisierung aus mehreren Quellen konfigurieren

Hinweise

Beschränkungen

Bevorzugte Konfigurationsmethode auswählen

Quellen in einer Root Source of Truth steuern

Stammquellen in einer Root Source of Truth steuern

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