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

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:

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

    Git

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

    Ersetzen Sie Folgendes:

    • ROOT_SYNC_NAME: Fügen Sie den Namen Ihres RootSync-Objekts hinzu.
    • ROOT_FORMAT: Fügen Sie unstructured hinzu, um ein unstrukturiertes Repository zu verwenden, oder fügen Sie hierarchy hinzu, um ein hierarchisches Repository zu verwenden. Bei diesen Werten wird zwischen Groß- und Kleinschreibung unterschieden. Dieses Feld ist optional und der Standardwert ist hierarchy. Wir empfehlen das Hinzufügen von unstructured, da Sie damit Ihre Konfigurationen so organisieren können, wie es für Sie am besten ist.
    • ROOT_REPOSITORY: Fügen Sie die URL des Git-Repositorys hinzu, das als Stamm-Repository verwendet werden soll. Sie können URLs mithilfe des HTTPS- oder SSH-Protokolls eingeben. https://github.com/GoogleCloudPlatform/anthos-config-management-samples verwendet beispielsweise das HTTPS-Protokoll. Dies ist ein Pflichtfeld.
    • ROOT_REVISION: Fügen Sie die Git-Revision (Tag oder Hash) 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
    • 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.

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

     git add .
     git commit -m 'Setting up a new root source of truth.'
     git push
    
  3. Sie können die oben genannten Schritte wiederholen, wenn Sie mehrere Root Sources konfigurieren müssen. Sie können auch Konfigurationen mehrerer RootSync-Objekte in einer " Root Source of Truth" speichern, die von einem anderen RootSync-Objekt synchronisiert wird, um mehrere RootSync-Objekte zentral auf GitOps-Art zu verwalten.

Namespace-bezogene Objekte in einer Root Source of Truth steuern

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

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

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

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

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

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

    Git

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

    Ersetzen Sie Folgendes:

    • REPO_SYNC_NAME: Fügen Sie den Namen Ihres RepoSync-Objekts hinzu. Der Name sollte im gesamten Namespace eindeutig sein.
    • NAMESPACE: Fügen Sie den Namen Ihres Namespace hinzu.
    • NAMESPACE_REPOSITORY: Fügen Sie die URL des Git-Repositorys hinzu, das als Namespace-Repository verwendet werden soll. Sie können URLs mithilfe des HTTPS- oder SSH-Protokolls eingeben. https://github.com/GoogleCloudPlatform/anthos-config-management-samples verwendet beispielsweise das HTTPS-Protokoll. Wenn Sie kein Protokoll eingeben, wird die URL als HTTPS-URL behandelt. Dies ist ein Pflichtfeld.
    • NAMESPACE_REVISION: Fügen Sie die Git-Revision (Tag oder Hash) 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
    • 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.

  3. 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.

  4. 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.

    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.
  5. Ü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
    
  6. 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.
  7. 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
    
  8. Sie können die oben genannten Schritte wiederholen, wenn Sie mehr als eine Namespace-bezogene Quelle konfigurieren müssen.

Namespace-bezogene Quellen in einer Namespace-bezogenen Quelle steuern

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

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

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

    Git

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

    Ersetzen Sie Folgendes:

    • REPO_SYNC_NAME: Fügen Sie den Namen Ihres RepoSync-Objekts hinzu. Der Name sollte im gesamten Namespace eindeutig sein.
    • NAMESPACE: Fügen Sie den Namen Ihres Namespace hinzu.
    • NAMESPACE_REPOSITORY: Fügen Sie die URL des Git-Repositorys hinzu, das als Namespace-Repository verwendet werden soll. Sie können URLs mithilfe des HTTPS- oder SSH-Protokolls eingeben. https://github.com/GoogleCloudPlatform/anthos-config-management-samples verwendet beispielsweise das HTTPS-Protokoll. Wenn Sie kein Protokoll eingeben, wird die URL als HTTPS-URL behandelt. Dies ist ein Pflichtfeld.
    • NAMESPACE_REVISION: Fügen Sie die Git-Revision (Tag oder Hash) 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
    • 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.

  2. 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.

  3. 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.

    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.
  4. Ü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
    
  5. Erstellen Sie ein Secret, falls erforderlich, mit Ihrer bevorzugten Authentifizierungsmethode. Wenn Sie none als Authentifizierungstyp verwendet haben, können Sie diesen Schritt überspringen.

    Das Secret muss die folgenden Anforderungen erfüllen:

    • Erstellen Sie das Secret im selben Namespace wie RepoSync.
    • Der Name des Secrets muss mit dem Namen spec.git.secretRef übereinstimmen, den Sie in repo-sync.yaml definiert haben.
    • Sie müssen den öffentlichen Schlüssel des Secrets dem Git-Anbieter hinzufügen.
  6. Verwenden Sie kubectl get für eines der Objekte in der Namespace-bezogenen "Source of Truth", um die Konfiguration zu prüfen. Beispiel:

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

"Source of Truth" mit der Kubernetes API steuern

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

Mehr als eine Root Source of Truth verwalten

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

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

    Git

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

    Ersetzen Sie Folgendes:

    • ROOT_SYNC_NAME: Fügen Sie den Namen Ihres RootSync-Objekts hinzu.
    • ROOT_FORMAT: Fügen Sie unstructured hinzu, um ein unstrukturiertes Repository zu verwenden, oder fügen Sie hierarchy hinzu, um ein hierarchisches Repository zu verwenden. Bei diesen Werten wird zwischen Groß- und Kleinschreibung unterschieden. Dieses Feld ist optional und der Standardwert ist hierarchy. Wir empfehlen das Hinzufügen von unstructured, da Sie damit Ihre Konfigurationen so organisieren können, wie es für Sie am besten ist.
    • ROOT_REPOSITORY: Fügen Sie die URL des Git-Repositorys hinzu, das als Stamm-Repository verwendet werden soll. Sie können URLs mithilfe des HTTPS- oder SSH-Protokolls eingeben. https://github.com/GoogleCloudPlatform/anthos-config-management-samples verwendet beispielsweise das HTTPS-Protokoll. Dies ist ein Pflichtfeld.
    • ROOT_REVISION: Fügen Sie die Git-Revision (Tag oder Hash) 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
    • 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.

  2. Änderungen anwenden:

    kubectl apply -f root-sync.yaml
    
  3. Sie können die oben genannten Schritte wiederholen, wenn Sie mehr als eine Root Source of Truth konfigurieren müssen.

Namespace-bezogene "Sources of Truth" steuern

Zentrale Administratoraufgaben

Der zentrale Administrator führt die folgenden Aufgaben aus:

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

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

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

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

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

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

    Ersetzen Sie Folgendes:

    • NAMESPACE: Fügen Sie den Namespace hinzu, den Sie in der Root Source of Truth erstellt haben.
    • USERNAME: Fügen Sie den Nutzernamen des Anwendungsoperators hinzu.
    • OPERATOR_ROLE: Als zentraler Administrator können Sie mit OPERATOR_ROLE festlegen, welche Konfigurationsarten aus der Namespace-bezogenen Source synchronisiert werden können. Sie können eine der folgenden Rollen auswählen:

      • Eine Standard-ClusterRole:

        • admin
        • edit

        Weitere Informationen finden Sie unter Nutzerbezogene Rollen.

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

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

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

Aufgaben des Anwendungsoperators

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

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

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

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

    Ersetzen Sie Folgendes:

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

    kubectl apply -f sync-rolebinding.yaml
    
  3. Erstellen Sie ein Secret, falls erforderlich, mit Ihrer bevorzugten Authentifizierungsmethode. Wenn Sie none als Authentifizierungstyp verwendet haben, können Sie diesen Schritt überspringen.

    Das Secret muss die folgenden Kriterien erfüllen:

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

    Git

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

    Ersetzen Sie Folgendes:

    • REPO_SYNC_NAME: Fügen Sie den Namen Ihres RepoSync-Objekts hinzu. Der Name sollte im gesamten Namespace eindeutig sein.
    • NAMESPACE: Fügen Sie den Namen Ihres Namespace hinzu.
    • NAMESPACE_REPOSITORY: Fügen Sie die URL des Git-Repositorys hinzu, das als Namespace-Repository verwendet werden soll. Sie können URLs mithilfe des HTTPS- oder SSH-Protokolls eingeben. https://github.com/GoogleCloudPlatform/anthos-config-management-samples verwendet beispielsweise das HTTPS-Protokoll. Wenn Sie kein Protokoll eingeben, wird die URL als HTTPS-URL behandelt. Dies ist ein Pflichtfeld.
    • NAMESPACE_REVISION: Fügen Sie die Git-Revision (Tag oder Hash) 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
    • 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.

  5. Wenden Sie die Konfiguration RepoSync an:

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

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

Synchronisierungsstatus der „Source of Truth“ prüfen

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

nomos status

Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

my_managed_cluster-1
  --------------------
  <root>   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:

  1. 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.

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

Kubernetes API-Methode

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

  1. Entscheiden Sie, ob Sie die Ressourcen, 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.

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

    kubectl delete -f FILE_NAME
    

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

Nächste Schritte