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:

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

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. Zuvor hatten verwaiste Objekte persistente Metadaten, die verhinderten, dass sie von anderen Clients oder neuen RootSync- oder RepoSync-Objekten verwaltet wurden.

Angenommen, Ihr Stamm-Repository wird vom Objekt RootSync single-root-sync synchronisiert. Nach dem Aufteilen 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:

  1. Prüfen Sie, ob für das RootSync-Objekt single-root-sync der Wert der Annotation configsync.gke.io/deletion-propagation-policy auf Orphan gesetzt ist oder ob die Annotation nicht festgelegt ist. Wenn die Annotation nicht festgelegt ist, ist der Standardwert derselbe wie „Orphan“. Mit dieser Einstellung wird sichergestellt, dass Objekte nicht gelöscht werden.

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

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

  3. Richten Sie Ihre neuen Repositories mit den folgenden Schritten 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.

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

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

  5. 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 sollte mit dem vorhandenen RootSync-Objekt `root-sync` übereinstimmen.
    • ROOT_EMAIL: Dieser Wert sollte mit dem vorhandenen RootSync-Objekt `root-sync` übereinstimmen.

  6. 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, die in Version 1.21.0 und höher verfügbar ist, 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 dem Aufteilen des Repositorys haben Sie zwei Stamm-Repositories. Eines wird vom root-sync RootSync-Objekt synchronisiert, das andere vom root-sync-1 RootSync-Objekt.

So teilen Sie das Repository auf:

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

  2. Führen Sie einen Commit durch und übertragen Sie die Änderung: sh git commit -am 'disable Config Sync management on subset of the configuration'

  3. Warten Sie, bis das vorhandene RootSync-Objekt root-sync synchronisiert ist. Verwenden Sie dazu den folgenden Befehl:

    nomos status

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

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

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

  6. 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 sollte mit dem vorhandenen RootSync-Objekt `root-sync` übereinstimmen.
    • ROOT_EMAIL: Dieser Wert sollte mit dem vorhandenen RootSync-Objekt `root-sync` übereinstimmen.

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

  8. 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'

  9. Warten Sie, bis das vorhandene RootSync-Objekt root-sync synchronisiert ist. Verwenden Sie dazu den folgenden Befehl:

    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:

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

  2. Die Ressourcen in einem Namespace können nicht auf mehrere Repositories verteilt werden. Andernfalls konkurrieren verschiedene Abgleicher um die Verwaltung des Namespace.

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