Diese Seite wurde von der Cloud Translation API übersetzt.

Ein Repository in mehrere Repositories aufteilen

Auf dieser Seite erfahren Sie, wie Sie ein Stamm-Repository sicher in zwei oder mehr Stamm-Repositories aufteilen können. Die Schritte können auch auf Namespace-Repositories angewendet werden.

Ein von Config Sync synchronisiertes Repository bezieht sich auf die Kombination aus einem Git-Repository, einem Zweig, einer Überarbeitung und einem Verzeichnis.

Wenn sich in Ihrem Stamm-Repository eine große Anzahl an Ressourcen befindet, z. B. mehr als 5.000, verhält sich Config Sync aus den folgenden beiden Gründen möglicherweise nicht richtig:

Das ResourceGroup-Objekt kann das Größenlimit für etcd-Objekte überschreiten. Das ResourceGroup-Objekt zeichnet die Gruppe, Art, Namespace und den Namen aller Ressourcen im Git-Repository auf. Eine große Anzahl von Ressourcen führt zu einem großen ResourceGroup-Objekt.
Es dauert länger, alle Ressourcen zu synchronisieren als ein Repository mit einer kleineren Anzahl von Ressourcen. Config Sync wendet die Ressourcen nacheinander auf den Cluster an. Manchmal können die Ressourcen beim ersten Mal nicht erfolgreich angewendet werden und Config Sync muss sie dann noch einmal anwenden.

Wenn diese Probleme auftreten, können Sie Ihr Stamm-Repository von einem in mehrere aufteilen, sodass jedes Stamm-Repository weniger Ressourcen hat.

Unstrukturiertes Stamm-Repository auflösen

Die Schritte werden mithilfe von RootSync-Objekten erläutert. Die Schritte können auch auf die RepoSync-Objekte angewendet werden.

1.21.0 oder höher (empfohlen)

Diese Methode funktioniert für Config Sync-Version 1.21.0 und höher, da in dieser Version ein Finalizer hinzugefügt wurde, der die Verwaltung von Objekten beendet, wenn ein RootSync- oder RepoSync-Objekt gelöscht wird. Bisher hatten verwaiste Objekte persistente Metadaten, die verhinderten, dass sie von anderen Clients oder neuen RootSync- oder RepoSync-Objekten verwaltet werden konnten.

Angenommen, Ihr Stamm-Repository wird vom Objekt RootSync single-root-sync synchronisiert. Nach der Aufteilung des Repositorys haben Sie zwei Stamm-Repositories. Eines wird vom RootSync-Objekt root-sync-1 synchronisiert, das andere vom RootSync-Objekt root-sync-2.

So teilen Sie das Repository auf:

Prüfen Sie, ob für das RootSync-Objekt single-root-sync der Annotationswert configsync.gke.io/deletion-propagation-policy auf Orphan festgelegt ist oder nicht festgelegt ist. Der Standardwert, wenn er nicht festgelegt ist, ist derselbe wie bei „Orphan“. Mit dieser Einstellung wird dafür gesorgt, dass Objekte nicht gelöscht werden.

Löschen Sie das RootSync-Objekt single-root-sync:

kubectl delete rootsync single-root-sync -n config-management-system

So richten Sie Ihre neuen Repositories ein:
1. Erstellen Sie ein neues Repository oder ein neues Verzeichnis in Ihrem bestehenden Git-Repository.
2. Verschieben Sie die Ressourcen in das neue Repository oder in das neue Verzeichnis.
3. Wenn Sie Ihr Stamm-Repository in mehr als zwei Repositories aufteilen, wiederholen Sie diese Schritte nach Bedarf.

Führen Sie einen Commit durch und übertragen Sie die Änderung:

git commit -am 'add configuration for the new root repository'

Wenden Sie die RootSync-Objekte root-sync-1 und root-sync-2 an. Dadurch wird das neue Repository oder Verzeichnis synchronisiert, sodass die vorhandenen Objekte im Cluster von den neuen RootSync-Objekten root-sync-1 und root-sync-2 verwaltet werden:
```
 apiVersion: configsync.gke.io/v1beta1
 kind: RootSync
 metadata:
   name: ROOT_SYNC_NAME
   namespace: config-management-system
 spec:
   sourceFormat: unstructured
   git:
     repo: NEW_ROOT_REPOSITORY
     revision: NEW_ROOT_REVISION
     branch: NEW_ROOT_BRANCH
     dir: "NEW_ROOT_DIRECTORY"
     auth: ROOT_AUTH_TYPE
     gcpServiceAccountEmail: ROOT_EMAIL
     # secretRef should be omitted if the auth type is none, gcenode, or gcpserviceaccount.
     secretRef:
       name: git-creds
```
Ersetzen Sie Folgendes:
- NEW_ROOT_REPOSITORY: die URL des Git-Repositorys, das als neues Root-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.
- NEW_ROOT_REVISION: (Optional) die Git-Revision (Tag oder Hash) des neuen Stamm-Repositorys, das ausgecheckt werden soll.
- NEW_ROOT_BRANCH: (Optional) Der Zweig des neuen Stamm-Repositorys, von dem aus synchronisiert werden soll.
- NEW_ROOT_DIRECTORY: (Optional) der Pfad im Git-Repository zum neuen Stammverzeichnis mit der Konfiguration, mit der Sie die Synchronisierung durchführen möchten
- ROOT_AUTH_TYPE: Dieser Wert muss mit dem vorhandenen RootSync-/Root-Sync-Objekt übereinstimmen.
- ROOT_EMAIL: Dieser Wert muss mit dem vorhandenen RootSync-/Root-Sync-Objekt übereinstimmen.
Warten Sie, bis das neue RootSync-Objekt root-sync-1 synchronisiert ist. Sie können den Status mit dem folgenden Befehl prüfen:
```
nomos status
```

Alle Versionen

Diese Methode funktioniert für alle Config Sync-Versionen, einschließlich Version 1.21.0. Wir empfehlen jedoch, die Methode in Version 1.21.0 und höher zu verwenden, da sie weniger Schritte erfordert. Wenn Ihre Config Sync-Version vor 1.21.0 liegt, können Sie stattdessen diese Methode verwenden.

Angenommen, Ihr Stamm-Repository wird vom Objekt RootSync root-sync synchronisiert. Nach der Aufteilung des Repositorys haben Sie zwei Stamm-Repositories. Eines wird vom RootSync-Objekt root-sync synchronisiert, das andere vom RootSync-Objekt root-sync-1.

So teilen Sie das Repository auf:

Wählen Sie in Ihrem vorhandenen Stamm-Repository die Ressourcen aus, die Sie in ein anderes Repository oder ein anderes Verzeichnis verschieben möchten, und fügen Sie ihnen die Annotation configmanagement.gke.io/managed: disabled hinzu. Diese Annotation sorgt dafür, dass die vorhandenen Objekte im Cluster nicht betroffen sind, wenn Sie ihre Konfiguration von einem Repository in ein anderes Repository verschieben. Wenn Sie das Kustomize-Format oder Helm-Diagramme verwenden, können Sie etwa die Hälfte der Basen auswählen und der Datei kustomization.yaml die gemeinsame Anmerkung hinzufügen, wie in diesem Beispiel:
```
# kustomization.yaml
commonAnnotations:
  configmanagement.gke.io/managed: disabled
```
Führen Sie einen Commit durch und übertragen Sie die Änderung: sh git commit -am 'disable Config Sync management on subset of the configuration'
Warten Sie mit dem folgenden Befehl, bis das vorhandene RootSync-Objekt root-sync synchronisiert wurde:
```
nomos status
```
Richten Sie Ihr zweites Repository mit den folgenden Schritten ein:
1. Erstellen Sie ein neues Repository oder ein neues Verzeichnis in Ihrem bestehenden Git-Repository.
2. Kopieren Sie die Ressourcen mit der Annotation configmanagement.gke.io/managed: disabled in das neue Repository oder in das neue Verzeichnis.
3. Entfernen Sie die Annotation configmanagement.gke.io/managed: disabled im neuen Repository oder Verzeichnis.
4. Wenn Sie Ihr Stamm-Repository in mehr als zwei Repositories aufteilen, wiederholen Sie diese Schritte nach Bedarf.

Führen Sie einen Commit durch und übertragen Sie die Änderung:

git commit -am 'add configuration for the new root repository'

Wenden Sie ein root-sync-1-RootSync-Objekt an, um das neue Repository oder Verzeichnis zu synchronisieren, sodass die vorhandenen Objekte im Cluster vom neuen root-sync-1-RootSync-Objekt verwaltet werden.
```
 apiVersion: configsync.gke.io/v1beta1
 kind: RootSync
 metadata:
   name: root-sync-1
   namespace: config-management-system
 spec:
   sourceFormat: unstructured
   git:
     repo: NEW_ROOT_REPOSITORY
     revision: NEW_ROOT_REVISION
     branch: NEW_ROOT_BRANCH
     dir: "NEW_ROOT_DIRECTORY"
     auth: ROOT_AUTH_TYPE
     gcpServiceAccountEmail: ROOT_EMAIL
     # secretRef should be omitted if the auth type is none, gcenode, or gcpserviceaccount.
     secretRef:
       name: git-creds
```
Ersetzen Sie Folgendes:
- NEW_ROOT_REPOSITORY: die URL des Git-Repositorys, das als neues Root-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.
- NEW_ROOT_REVISION: (Optional) die Git-Revision (Tag oder Hash) des neuen Stamm-Repositorys, das ausgecheckt werden soll.
- NEW_ROOT_BRANCH: (Optional) Der Zweig des neuen Stamm-Repositorys, von dem aus synchronisiert werden soll.
- NEW_ROOT_DIRECTORY: (Optional) der Pfad im Git-Repository zum neuen Stammverzeichnis mit der Konfiguration, mit der Sie die Synchronisierung durchführen möchten
- ROOT_AUTH_TYPE: Dieser Wert muss mit dem vorhandenen RootSync-/Root-Sync-Objekt übereinstimmen.
- ROOT_EMAIL: Dieser Wert muss mit dem vorhandenen RootSync-/Root-Sync-Objekt übereinstimmen.
Warten Sie, bis das neue RootSync-Objekt root-sync-1 synchronisiert ist. Sie können den Status mit dem folgenden Befehl prüfen:
```
nomos status
```
Entfernen Sie die Ressourcen mit der Annotation configmanagement.gke.io/managed: disabled aus dem ursprünglichen Repository. Führen Sie einen Commit durch und übertragen Sie die Änderung:
```
git commit -am 'remove configuration managed by the new root repository'
```
Warten Sie mit dem folgenden Befehl, bis das vorhandene RootSync-Objekt root-sync synchronisiert wurde:
```
nomos status
```

Hierarchische Stamm-Repositories aufteilen

Die Schritte zum Aufteilen eines hierarchischen Repositorys ähneln den Schritten zum Aufteilen eines unstrukturierten Repositorys.

Es gibt drei Hauptunterschiede:

Das neue Stamm-Repository (oder das neue Verzeichnis) sollte ebenfalls hierarchisch sein. Sie müssen die vorhandenen Verzeichnisse system/ und clusterregistry/ in das neue Stamm-Repository (oder das neue Verzeichnis) kopieren.
Die Ressourcen in einem Namespace können nicht auf mehrere Repositories verteilt werden. Andernfalls konkurrieren verschiedene Abgleicher um die Verwaltung des Namespace.
Das RootSync-Objekt root-sync-1 sollte spec.sourceFormat: hierarchical verwenden.

Da wir die Verwendung von unstrukturierten Repositories empfehlen, können Sie auch Ihr hierarchisches Repository in ein unstrukturiertes Repository umwandeln, bevor Sie es aufteilen.