Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Ein Repository in mehrere Repositories aufteilen

Wenn Sie Tausende von Kubernetes-Ressourcen in Config Sync verwalten, können Sie durch das Aufteilen eines großen Stamm- oder Namespace-Repositorys in mehrere kleinere Repositories die Abgleichgeschwindigkeit verbessern und Synchronisierungsfehler vermeiden.

In Config Sync bezieht sich ein synchronisiertes Repository auf die Kombination aus einem Git-Repository, einem Zweig, einer Überarbeitung und einem Verzeichnis. Wenn Sie ein monolithisches Repository auf mehrere RootSync- oder RepoSync-Objekte aufteilen, reduzieren Sie die Anzahl der Ressourcen, die von jedem Abgleicher verfolgt und angewendet werden.

Warum große Repositories Synchronisierungsprobleme verursachen

Wenn Ihr Root-Repository eine große Anzahl von Ressourcen enthält,z. B. mehr als 5.000,kann es bei Config Sync aus den folgenden Gründen zu Leistungs- oder Synchronisierungsproblemen kommen:

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 kann zu einem großen ResourceGroup-Objekt führen.
Die Synchronisierung eines großen Repositorys dauert länger als die eines kleineren Repositorys, da Config Sync Ressourcen nacheinander auf den Cluster anwendet. Wenn Config Sync eine Ressource beim ersten Versuch nicht anwenden kann, muss es den Vorgang wiederholen.

Wenn diese Probleme auftreten, sollten Sie Ihr Stamm-Repository in mehrere Repositories aufteilen, sodass jedes Stamm-Repository weniger Ressourcen verwaltet.

Unstrukturiertes Stamm-Repository auflösen

In den folgenden Schritten werden RootSync-Objekte als Beispiel verwendet. Sie können diese Schritte aber auch auf RepoSync-Objekte anwenden.

1.21.0 oder höher (empfohlen)

Diese Methode funktioniert für Config Sync-Versionen ab 1.21.0, da in dieser Version ein Finalizer hinzugefügt wurde, der die Verwaltung von Objekten beendet, wenn ein RootSync- oder RepoSync-Objekt gelöscht wird. Zuvor hatten verwaiste Objekte persistente Metadaten, was verhinderte, 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 das RootSync-Objekt single-root-sync den configsync.gke.io/deletion-propagation-policy-Annotationswert Orphan hat oder ob er nicht festgelegt ist. Der Standardwert, wenn nicht festgelegt, ist derselbe wie „Verwaist“. Durch diese Einstellung wird sichergestellt, dass Objekte nicht gelöscht werden.

Löschen Sie die RootSync-Ressource 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, das die Konfiguration enthält, mit der Sie die Synchronisierung ausfü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 jede Config Sync-Version, einschließlich Version 1.21.0. Wir empfehlen jedoch, die in Version 1.21.0 und höher verfügbare Methode zu verwenden, da sie weniger Schritte erfordert. Wenn Ihre Config Sync-Version älter als 1.21.0 ist, 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 RootSync-Objekt root-sync-1 an, um das neue Repository oder Verzeichnis zu synchronisieren, sodass die vorhandenen Objekte im Cluster vom neuen RootSync-Objekt root-sync-1 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, das die Konfiguration enthält, mit der Sie die Synchronisierung ausfü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.