Wenn Sie den Multi-Repo-Modus in Config Sync aktivieren, können Sie die Konfiguration von mehreren Repositories mit demselben Satz von Clustern synchronisieren. Sie können die folgenden Arten von Repositories verwenden:
Stamm-Repository: Mit diesem Repository können Sie clusterbezogene und Namespace-bezogene Konfigurationen synchronisieren. Das Stamm-Repository verwendet Anmeldedaten auf Administratorebene, um Richtlinien für Anwendungs-Namespaces zu erzwingen und lokale Änderungen zu überschreiben, die vom gewünschten Zustand abweichen. Ein zentraler Administrator ist für das Stamm-Repository zuständig. Pro Cluster kann nur ein Stamm-Repository vorhanden sein.
Namespace-Repositories: Namespace-Repositories sind optional und können Namespace-bezogene Konfigurationen enthalten, die mit einem bestimmten Namespace in mehreren Clustern synchronisiert werden. Sie können die Einrichtung und Kontrolle eines Namespace-Repositories an Nutzer ohne Administratorberechtigung delegieren.
Jedes Repository hat eine einzelne Git-Referenz (Repository-Branch, Commit oder Tag und Verzeichnistupel), die Sie separat verwalten können. Diese Konfiguration entkoppelt den Lebenszyklus der Konfigurationsbereitstellung für verschiedene Teams. Es bietet Ihnen auch mehr Flexibilität bei der Auswahl, wo Sie das Repository speichern und wie Sie es strukturieren möchten.
Im folgenden Diagramm erhalten Sie einen Überblick darüber, wie Teams ein Stamm-Repository und Namespace-Repositories verwenden können:
In diesem Diagramm verwaltet ein zentraler Administrator die zentralisierte Infrastruktur für die Organisation und erzwingt Richtlinien auf dem Cluster und für alle Namespaces in der Organisation.
Die Anwendungsoperatoren, die für die Verwaltung von Live-Bereitstellungen zuständig sind, wenden Konfigurationen auf die Anwendungen in den Namespaces an, mit denen sie arbeiten.
Hinweis
Führen Sie die folgenden Aufgaben aus, bevor Sie den Multi-Repo-Modus aktivieren:
- Verwenden Sie Config Sync Version 1.5.1 oder höher.
Beschränkungen
Beim Multi-Repo-Modus gelten folgende Einschränkungen:
- Das Feld
spec.enableMultiRepo
ist nicht mit dem Feldspec.git
kompatibel. Wenn Siespec.git
dennoch verwenden müssen, lesen Sie den Abschnitt Legacy-Felder „spec.git“ verwenden. ClusterSelectors
undnamespaceSelectors
(einschließlich Annotationen, die auf Selektoren verweisen) funktionieren nur im Stamm-Repository.- Sie können
gcenode
nicht im Feldauth
Ihrer RootSync- oder RepoSync-Konfigurationen verwenden.
Synchronisierung vom Stamm-Repository konfigurieren
Konfiguration des Root-Git-Repositorys nach RootSync verschieben (empfohlen)
Wir empfehlen, die Git-Repository-Konfigurationen von Ihrer bestehenden config-management.yaml
-Datei in eine RootSync-YAML-Datei zu verschieben, wenn Sie den Multi-Repo-Modus aktivieren.
Führen Sie die folgenden Aufgaben aus, um das Stamm-Repository zu konfigurieren:
- Öffnen Sie Ihre
config-management.yaml
-Datei. - Notieren Sie sich die
spec.git
-Felder und entfernen Sie sie aus der Dateiconfig-management.yaml
. Sie können diese Konfigurationen beim nächsten Erstellen von RootSync verwenden. Setzen Sie das Feld
spec.enableMultiRepo
auftrue
:# config-management.yaml apiVersion: configmanagement.gke.io/v1 kind: ConfigManagement metadata: name: config-management spec: enableMultiRepo: true
Änderungen anwenden:
kubectl apply -f config-management.yaml
Erstellen Sie die Datei
root-sync.yaml
. Beispiele:# root-sync.yaml apiVersion: configsync.gke.io/v1alpha1 kind: RootSync metadata: name: root-sync namespace: config-management-system spec: git: repo: REPOSITORY revision: REVISION branch: BRANCH dir: "DIRECTORY" auth: AUTH_TYPE secretRef: name: SECRET_NAME
Dabei gilt:
- REPOSITORY: Fügen Sie die URL des Git-Repositorys hinzu, das als Stamm-Repository verwendet werden soll. Dies ist ein Pflichtfeld.
- REVISION: Fügen Sie die Git-Revision (Tag oder Hash) hinzu, um auszuchecken. Dieses Feld ist optional und der Standardwert ist
HEAD
. - BRANCH: Der Zweig des Repositorys, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist
master
. - DIRECTORY: Fügen Sie den Pfad innerhalb des Git-Repositories hinzu, das die oberste Ebene des zu synchronisierenden Repositories darstellt. Dieses Feld ist optional und das Standardverzeichnis ist das Stammverzeichnis des Repositories.
AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:
none
ssh
cookiefile
token
Dies ist ein Pflichtfeld.
SECRET_NAME: Fügen Sie den Namen hinzu, den Sie dem Secret geben möchten. Dies ist ein Pflichtfeld.
Erstellen Sie ein Secret auf der Grundlage Ihrer bevorzugten Authentifizierungsmethode.
Das Secret muss die folgenden Anforderungen erfüllen:
- Der Name des Secrets muss mit dem Namen
spec.git.secretRef
übereinstimmen, den Sie inrepo-sync.yaml
definiert haben. - Sie müssen den öffentlichen Schlüssel des Secrets dem Git-Anbieter hinzufügen.
- Der Name des Secrets muss mit dem Namen
Wenden Sie die Konfiguration an:
kubectl apply -f root-sync.yaml
Installation prüfen:
kubectl -n config-management-system get pods | grep reconciler-manager
Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:
reconciler-manager-6f988f5fdd-4r7tr 1/1 Running 0 26s
Root-Git-Repository in ConfigManagement beibehalten (nicht empfohlen)
Sie können Ihr vorhandenes Root-Git-Repository in der Datei config-management.yaml
beibehalten, während Sie den Multi-Repo-Modus aktivieren, anstatt es in RootSync zu verschieben. Dies wird nicht empfohlen, da dies künftig eingestellt wird.
Legen Sie für die Felder
spec.enableMultiRepo
undspec.enableLegacyFields
den Werttrue
fest:# config-management.yaml apiVersion: configmanagement.gke.io/v1 kind: ConfigManagement metadata: name: config-management spec: enableMultiRepo: true enableLegacyFields: true git: syncRepo: REPO syncBranch: BRANCH secretType: TYPE policyDir: "DIRECTORY" # ...other fields...
Weitere Informationen zu diesen Feldern finden Sie in den Feldern von config-management.yaml.
Änderungen anwenden:
kubectl apply -f config-management.yaml
Durch die Bereitstellung dieser YAML-Datei wird auch automatisch die Ressource RootSync
im Cluster generiert. Ändern Sie die RootSync
-Konfiguration nicht. Fahren Sie mit Synchronisierung von Namespace-Repositories konfigurieren fort, um weitere Namespace-Repositories hinzuzufügen.
Synchronisierung aus Namespace-Repositories konfigurieren
Es gibt zwei Optionen zum Konfigurieren von Namespace-Repositories:
Namespace-Repositories im Stamm-Repository steuern Diese Methode zentralisiert die gesamte Konfiguration von Namespace-Repositories im Stamm-Repository und ermöglicht es einem zentralen Administrator, die vollständige Einrichtung abzuschließen.
Namespace-Repositories mit der Kubernetes API steuern. Diese Methode delegiert die Kontrolle über die Namespace-Repositories an die Namespace-Inhaber.
Namespace-Repositories im Stamm-Repository steuern
Bei dieser Methode verwaltet der zentrale Administrator die Einrichtung von Namespace-Repositories direkt aus dem Stamm-Repository. Da Config Sync die Namespace-Repository-Ressourcen verwaltet, verhindert diese Methode alle lokalen Änderungen an den Namespace-Repository-Definitionen.
Führen Sie die folgenden Aufgaben aus, um dieses Methode zu verwenden:
Legen Sie im Stamm-Repository eine
namespace
-Konfiguration fest:# ROOT_REPO/namespaces/NAMESPACE/namespace.yaml apiVersion: v1 kind: Namespace metadata: name: NAMESPACE
Ersetzen Sie NAMESPACE durch einen Namen für den Namespace.
Legen Sie im Stamm-Repository eine
RepoSync
-Konfiguration im selben Namespace fest:# ROOT_REPO/namespaces/NAMESPACE/repo-sync.yaml apiVersion: configsync.gke.io/v1alpha1 kind: RepoSync metadata: name: repo-sync namespace: NAMESPACE spec: git: repo: REPOSITORY revision: REVISION branch: BRANCH dir: "DIRECTORY" auth: AUTH_TYPE secretRef: name: SECRET_NAME
Dabei gilt:
- NAMESPACE: Fügen Sie den Namen Ihres Namespace hinzu.
- REPOSITORY: Fügen Sie die URL des Git-Repositorys hinzu, das als Stamm-Repository verwendet werden soll. Dies ist ein Pflichtfeld.
- REVISION: Fügen Sie die Git-Revision (Tag oder Hash) hinzu, um auszuchecken. Dieses Feld ist optional und der Standardwert ist
HEAD
. - BRANCH: Der Zweig des Repositorys, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist
master
. - DIRECTORY: Fügen Sie den Pfad innerhalb des Git-Repositories hinzu, das die oberste Ebene des zu synchronisierenden Repositories darstellt. Dieses Feld ist optional und das Standardverzeichnis ist das Stammverzeichnis des Repositories.
AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:
none
ssh
cookiefile
token
Dies ist ein Pflichtfeld.
SECRET_NAME: Fügen Sie den Namen hinzu, den Sie dem Secret geben möchten. Dies ist ein Pflichtfeld.
Es kann höchstens eine RepoSync-Ressource pro Namespace vorhanden sein. Um dies zu erzwingen, muss der Objektname
repo-sync
sein. Alle Konfigurationen in dem Verzeichnis, auf dasRepoSync
verweist, müssen sich ebenfalls im selben Namespace wie dieRepoSync
-Ressource befinden.Deklarieren Sie im Stamm-Repository eine
RoleBinding
-Konfiguration, die dem Dienstkontons-reconciler-NAMESPACE
die Berechtigung zur Verwaltung von Ressourcen im Namespace gewährt. Config Sync erstellt automatisch das Dienstkontons-reconciler-NAMESPACE
, wenn die KonfigurationRepoSync
mit dem Cluster synchronisiert wird.Erstellen Sie das folgende Manifest, um das
RoleBinding
zu deklarieren:# 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: ns-reconciler-NAMESPACE namespace: config-management-system roleRef: kind: ClusterRole name: RECONCILER_ROLE apiGroup: rbac.authorization.k8s.io
Dabei gilt:
- NAMESPACE: Fügen Sie den Namen Ihres Namespace hinzu.
RECONCILER_ROLE: Als zentraler Administrator können Sie RECONCILER_ROLE festlegen, um zu erzwingen, welche Konfigurationsarten aus dem Namespace-Repository 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 im Stamm-Repository deklariert ist. Diese Rolle ermöglicht differenzierte Berechtigungen.
Übernehmen Sie die vorherigen Änderungen im Stamm-Repository:
git add . git commit -m 'Setting up new namespace repository.' git push
Erstellen Sie ein Secret auf der Grundlage Ihrer bevorzugten Authentifizierungsmethode.
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 inrepo-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 im Namespace-Repository, um die Konfiguration zu prüfen. Beispiele:kubectl get rolebindings -n NAMESPACE
Namespace-Repositories mit der Kubernetes API steuern.
Bei dieser Methode deklariert der zentrale Administrator nur den Namespace im Stamm-Repository und delegiert die Deklaration der Datei RepoSync
an den Anwendungsoperator.
Zentrale Administratoraufgaben
Der zentrale Administrator führt die folgenden Aufgaben aus:
Legen Sie im Stamm-Repository eine
namespace
-Konfiguration fest:# 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 im Stamm-Repository die Konfiguration
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: USER_NAME apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: OPERATOR_ROLE apiGroup: rbac.authorization.k8s.io
Dabei gilt:
- NAMESPACE: Fügen Sie den Namespace hinzu, den Sie im Stammverzeichnis erstellt haben.
- USER_NAME: Fügen Sie den Nutzernamen des Anwendungsoperators hinzu.
OPERATOR_ROLE: Als zentraler Administrator können Sie OPERATOR_ROLE festlegen, um zu erzwingen, welche Konfigurationsarten aus dem Namespace-Repository 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 im Stamm-Repository deklariert ist. Dies ermöglicht präzise Berechtigungen.
Übernehmen Sie die vorherigen Änderungen im Stamm-Repository:
git add . git commit -m 'Setting up new namespace repository.' git push
Aufgaben des Anwendungsoperators
Der Anwendungsoperator führt die folgenden Aufgaben aus:
Deklarieren Sie eine
RoleBinding
-Konfiguration, die dem automatisch bereitgestellten Dienstkontons-reconciler-NAMESPACE
die Berechtigung zur Verwaltung von Ressourcen im Namespace gewährt. Config Sync erstellt automatisch das Dienstkontons-reconciler-NAMESPACE
, wenn die KonfigurationRepoSync
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: ns-reconciler-NAMESPACE namespace: config-management-system roleRef: kind: ClusterRole name: RECONCILER_ROLE apiGroup: rbac.authorization.k8s.io
Dabei gilt:
- NAMESPACE: Fügen Sie den Namespace hinzu, den Sie im Stammverzeichnis erstellt haben.
- RECONCILER_ROLE: Als Anwendungsoperator können Sie mit RECONCILER_ROLE festlegen, welche Konfigurationsarten aus dem Namespace-Repository 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 auf der Grundlage Ihrer bevorzugten Authentifizierungsmethode.
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 inrepo-sync.yaml
definiert haben. - Sie müssen den öffentlichen Schlüssel des Secrets dem Git-Anbieter hinzufügen.
Deklarieren Sie eine
RepoSync
-Konfiguration:# repo-sync.yaml apiVersion: configsync.gke.io/v1alpha1 kind: RepoSync metadata: name: repo-sync namespace: NAMESPACE spec: git: repo: REPOSITORY revision: REVISION branch: BRANCH dir: "DIRECTORY" auth: AUTH_TYPE secretRef: name: SECRET_NAME
Dabei gilt:
- REPOSITORY: Fügen Sie die URL des Git-Repositorys hinzu, das als Stamm-Repository verwendet werden soll. Dies ist ein Pflichtfeld.
- REVISION: Fügen Sie die Git-Revision (Tag oder Hash) hinzu, um auszuchecken. Dieses Feld ist optional und der Standardwert ist
HEAD
. - BRANCH: Der Zweig des Repositorys, von dem aus synchronisiert werden soll. Dieses Feld ist optional und der Standardwert ist
master
. - DIRECTORY: Fügen Sie den Pfad innerhalb des Git-Repositories hinzu, das die oberste Ebene des zu synchronisierenden Repositories darstellt. Dieses Feld ist optional und das Standardverzeichnis ist das Stammverzeichnis des Repositories.
AUTH_TYPE: Fügen Sie einen der folgenden Authentifizierungstypen hinzu:
none
ssh
cookiefile
token
Dies ist ein Pflichtfeld.
SECRET_NAME: Fügen Sie den Namen hinzu, den Sie dem Secret geben möchten. Dies ist ein Pflichtfeld.
Es kann höchstens eine RepoSync-Ressource pro Namespace vorhanden sein. Damit dies erzwungen werden kann, muss der Objektname
repo-sync
lauten. Alle Konfigurationen in dem Verzeichnis, auf dasRepoSync
verweist, müssen sich ebenfalls im selben Namespace wie dieRepoSync
-Ressource befinden.Wenden Sie die Konfiguration
RepoSync
an:kubectl apply -f repo-sync.yaml
Verwenden Sie
kubectl get
für eines der Objekte im Namespace-Repository, um die Konfiguration zu prüfen. Beispiele:kubectl get rolebindings -n NAMESPACE
Synchronisierung anhalten und fortsetzen
In diesem Abschnitt erfahren Sie, wie Sie die Synchronisierung vorübergehend anhalten und fortsetzen können. Dies kann erforderlich sein, wenn aus Versehen eine falsche Konfiguration in Ihr Repository übergeben wird.
Nur ein zentraler Administrator kann die Synchronisierung im Stamm-Repository stoppen.
Ob Sie die Synchronisierung in Namespace-Repositories stoppen können, hängt davon ab, welche Konfigurationsmethode für Ihre Namespace-Repositories verwendet wurde.
Wenn die Methode Namespace-Repositories im Stamm-Repository steuern verwendet wurde, ist ein zentraler Administrator der einzige, der die Synchronisierung stoppen und wieder aufnehmen kann.
Wenn die Methode Namespace-Repositories mit der Kubernetes API steuern verwendet wurde, können Anwendungsoperatoren die Synchronisierung aus den Namespace-Repositories, in denen sie arbeiten, beenden und wieder aufnehmen.
Synchronisierung anhalten
In diesem Abschnitt erfahren Sie, wie Sie die Synchronisierung für das Stamm-Repository und für Namespace-Repositories beenden.
Synchronisierung aus dem Stamm-Repository beenden
Um die Synchronisierung aus dem Stamm-Repository zu stoppen, kann ein zentraler Administrator den folgenden Befehl ausführen:
kubectl -n config-management-system scale deployment root-reconciler --replicas=0
Mit diesem Befehl wird die replicas
-Anzahl in der Bereitstellung root-reconciler
auf 0 reduziert.
Synchronisierung aus Namespace-Repositories beenden
Wählen Sie den Tab Stamm-Repository-Methode oder Kubernetes API-Methode aus, um die relevanten Anleitungen aufzurufen.
Stamm-Repository-Methode
Wenn die Option Namespace-Repositories im Stamm-Repository steuern verwendet wurde, können zentrale Administratoren die folgenden Befehle ausführen, um die Synchronisierung aus einem Namespace-Repository zu beenden:
kubectl -n config-management-system scale deployment ns-reconciler-NAMESPACE --replicas=0
Der Befehl reduziert die Replikatzahl in der Bereitstellung ns-reconciler-NAMESPACE
auf 0.
Kubernetes API-Methode
Wenn die Option Namespace-Repositories mit der Kubernetes API steuern verwendet wurde, können Anwendungsoperatoren die Synchronisierung stoppen, wenn Sie die folgenden Befehle ausführen:
Rufen Sie die Konfiguration
RepoSync
ab und speichern Sie sie, um sie später zu verwenden, wenn Sie die Synchronisierung wieder aufnehmen möchten:kubectl -n NAMESPACE get reposyncs repo-sync -oyaml > repo-sync.yaml
Ersetzen Sie NAMESPACE durch den Namespace von RepoSync.
Löschen Sie die
RepoSync
-Konfiguration:kubectl -n NAMESPACE delete reposyncs repo-sync
Dieser Befehl veranlasst den Reconciler Manager, den Namespace-Reconciler (
ns-reconciler-NAMESPACE
) aus NAMESPACE zu entfernen und die Synchronisierung zu beenden.
Synchronisierung fortsetzen
In diesem Abschnitt erfahren Sie, wie Sie die Synchronisierung für das Stamm-Repository und für Namespace-Repositories fortsetzen.
Synchronisierung aus dem Stamm-Repository fortsetzen
Um die Synchronisierung aus einem Stamm-Repository fortzusetzen, kann ein zentraler Administrator den folgenden Befehl ausführen:
kubectl -n config-management-system scale deployment root-reconciler --replicas=1
Mit diesem Befehl wird das root-reconciler
-Deployment auf ein Replikat skaliert.
Synchronisierung von einem Namespace-Repository wieder aufnehmen
Wählen Sie den Tab Stamm-Repository-Methode oder Kubernetes API-Methode aus, um die relevanten Anleitungen aufzurufen.
Stamm-Repository-Methode
Wenn Sie die Option Namespace-Repositories im Stamm-Repository steuern verwenden, kann ein zentraler Administrator den folgenden Befehl ausführen:
kubectl -n config-management-system scale deployment ns-reconciler-NAMESPACE --replicas=1
Mit diesem Befehl wird das Deployment ns-reconciler-NAMESPACE auf ein Replikat skaliert.
Kubernetes API-Methode
Wenn Sie die Option Namespace-Repositories mit der Kubernetes API steuern verwenden, setzen Anwendungsoperatoren die Synchronisierung fort, indem Sie repo-sync.yaml
, das die Konfiguration RepoSync
enthält, neu anwenden:
kubectl apply -f repo-sync.yaml
Dieser Befehl löst den Reconciler Manager von tne aus, um einen Namespace-Reconciler-Ablauf und ein ns-reconciler-NAMESPACE
-Deployment zu erstellen.
Stamm- und Namespace-Repositories entfernen
Löschen Sie die Datei RootSync
, um das Stamm-Repository zu entfernen. Beispiel:
kubectl delete -f root-sync.yaml
Löschen Sie eine RepoSync
-Datei, um ein Namespace-Repository zu deinstallieren. Diese Aktion deinstalliert das übereinstimmende Namespace-Repository.
Konfliktlösung
Bei der Arbeit mit zwei Repositories können Konflikte auftreten, wenn dieselbe Ressource (übereinstimmende Gruppen, Arten, Namen und Namespaces) sowohl im Stamm- als auch im Namespace-Repository deklariert wird. In diesem Fall wird nur die Deklaration im Stamm-Repository auf den Cluster angewendet.
Da das Stamm-Repository immer Vorrang hat, können Sie den Konflikt beheben, indem Sie das Stamm-Repository aktualisieren, damit es mit dem Namespace-Repository übereinstimmt, oder indem Sie das in Konflikt stehende Objekt im Namespace-Repository löschen.
Nächste Schritte
- Weitere Informationen zu Repositories in Config Sync.
- Weitere Informationen zum Schreiben von configs.