Scinder un dépôt en plusieurs dépôts

Cette page explique comment scinder en toute sécurité un dépôt racine en plusieurs dépôts racines. La procédure peut également être appliquée aux dépôts d'espaces de noms.

Un dépôt synchronisé par Config Sync fait référence à la combinaison d'un dépôt Git, d'une branche, d'une révision et d'un répertoire.

Lorsque le dépôt racine contient un grand nombre de ressources, par exemple plus de 5 000, Config Sync peut ne pas se comporter correctement pour les deux raisons suivantes :

  1. L'objet ResourceGroup peut dépasser la limite de taille de l'objet etcd. L'objet ResourceGroup enregistre le groupe, le genre, l'espace de noms et le nom de toutes les ressources dans le dépôt Git. Si vous disposez d'un grand nombre de ressources, l'objet ResourceGroup est volumineux.
  2. La synchronisation de toutes les ressources prend plus de temps qu'un dépôt contenant un plus petit nombre de ressources. Config Sync applique les ressources de manière séquentielle au cluster. Parfois, les ressources ne peuvent pas être appliquées correctement la première fois, et Config Sync doit réessayer de les appliquer.

Lorsque vous rencontrez ces problèmes, vous pouvez scinder votre dépôt racine en plusieurs dépôts afin que chacun d'eux dispose de moins de ressources.

Scinder un dépôt racine non structuré

Les objets RootSync sont utilisés pour expliquer les étapes. Ces étapes peuvent également être appliquées aux objets RepoSync.

1.21.0 ou version ultérieure

Cette méthode fonctionne pour Config Sync 1.21.0 et les versions ultérieures en raison d'un finaliseur ajouté dans cette version, qui cesse de gérer les objets lorsqu'un objet RootSync ou RepoSync est supprimé. Auparavant, les objets orphelins disposaient de métadonnées persistantes, ce qui les empêchait d'être gérés par d'autres clients ou de nouveaux objets RootSync ou RepoSync.

Supposons que votre dépôt racine est synchronisé par l'objet RootSync single-root-sync. Après avoir scindé le dépôt, vous disposez de deux dépôts racines. L'un est synchronisé par l'objet RootSync root-sync-1, tandis que l'autre est synchronisé par l'objet RootSync root-sync-2.

Pour scinder le dépôt, procédez comme suit :

  1. Assurez-vous que l'annotation configsync.gke.io/deletion-propagation-policy de single-root-sync RootSync est définie sur Orphan ou qu'elle n'est pas définie. La valeur par défaut est identique à "Orphan" (Orphelin) si elle n'est pas définie. Ce paramètre garantit que les objets ne sont pas supprimés.

  2. Supprimez le single-root-sync RootSync:

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

  3. Pour configurer vos nouveaux dépôts, procédez comme suit:

    1. Créez un dépôt ou un répertoire dans votre dépôt Git existant.
    2. Déplacez les ressources dans le nouveau dépôt ou le nouveau répertoire.
    3. Si vous scindez votre dépôt racine en plus de deux dépôts, répétez ces étapes si nécessaire.

  4. Procédez au commit et au transfert de la modification :

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

  5. Appliquez les objets RootSync root-sync-1 et root-sync-2. Cela permet de synchroniser le nouveau dépôt ou le nouveau répertoire afin que les objets existants du cluster soient gérés par les nouveaux objets RootSync root-sync-1 et root-sync-2:

     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

    Remplacez les éléments suivants :

    • NEW_ROOT_REPOSITORY : URL du dépôt Git à utiliser comme nouveau dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Si vous ne saisissez pas de protocole, l'URL est traitée comme une URL HTTPS.
    • NEW_ROOT_REVISION (facultatif) : révision Git (tag ou hachage) du nouveau dépôt racine à examiner.
    • NEW_ROOT_BRANCH (facultatif) : branche du nouveau dépôt racine à partir duquel vous souhaitez effectuer la synchronisation.
    • NEW_ROOT_DIRECTORY: (facultatif) chemin d'accès dans le dépôt Git au nouveau répertoire racine contenant la configuration que vous souhaitez synchroniser.
    • ROOT_AUTH_TYPE: cette valeur doit être identique à l'objet RootSync/root-sync existant.
    • ROOT_EMAIL: cette valeur doit être identique à l'objet RootSync/root-sync existant.

  6. Attendez que le nouvel objet RootSync root-sync-1 soit synchronisé. Vous pouvez vérifier l'état à l'aide de la commande suivante:

    nomos status

Toutes les versions

Cette méthode fonctionne avec n'importe quelle version de Config Sync, y compris la version 1.21.0, mais nous vous recommandons d'utiliser la méthode disponible dans la version 1.21.0 et les versions ultérieures, car elle nécessite moins d'étapes. Si votre version de Config Sync est antérieure à la version 1.21.0, vous pouvez utiliser cette méthode à la place.

Supposons que votre dépôt racine est synchronisé par l'objet RootSync root-sync. Après avoir scindé le dépôt, vous disposez de deux dépôts racines. L'un est synchronisé par l'objet RootSync root-sync, tandis que l'autre est synchronisé par l'objet RootSync root-sync-1.

Pour scinder le dépôt, procédez comme suit :

  1. Dans votre dépôt racine existant, choisissez les ressources que vous souhaitez déplacer vers un autre dépôt ou répertoire, puis ajoutez-y l'annotation configmanagement.gke.io/managed: disabled. Cette annotation garantit que les objets existants du cluster ne sont pas affectés lorsque vous déplacez leur configuration d'un dépôt vers un autre. Si vous utilisez le format Kustomize ou des charts Helm, vous pouvez choisir environ la moitié des bases et ajouter l'annotation commune au fichier kustomization.yaml, comme dans l'exemple suivant :

    # kustomization.yaml
commonAnnotations:
  configmanagement.gke.io/managed: disabled

  2. Procédez au commit et au transfert de la modification : sh git commit -am 'disable Config Sync management on subset of the configuration'

  3. Attendez que l'objet RootSync root-sync existant soit synchronisé à l'aide de la commande suivante:

    nomos status

  4. Configurez votre deuxième dépôt en procédant comme suit :

    1. Créez un dépôt ou un répertoire dans votre dépôt Git existant.
    2. Copiez les ressources avec l'annotation configmanagement.gke.io/managed: disabled dans le nouveau dépôt ou le nouveau répertoire.
    3. Supprimez l'annotation configmanagement.gke.io/managed: disabled dans le nouveau dépôt ou le nouveau répertoire.
    4. Si vous scindez votre dépôt racine en plus de deux dépôts, répétez ces étapes si nécessaire.

  5. Procédez au commit et au transfert de la modification :

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

  6. Appliquez un objet RootSync root-sync-1 pour synchroniser le nouveau dépôt ou le nouveau répertoire afin que les objets existants du cluster soient gérés par le nouvel objet RootSync root-sync-1.

     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

    Remplacez les éléments suivants :

    • NEW_ROOT_REPOSITORY : URL du dépôt Git à utiliser comme nouveau dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Si vous ne saisissez pas de protocole, l'URL est traitée comme une URL HTTPS.
    • NEW_ROOT_REVISION (facultatif) : révision Git (tag ou hachage) du nouveau dépôt racine à examiner.
    • NEW_ROOT_BRANCH (facultatif) : branche du nouveau dépôt racine à partir duquel vous souhaitez effectuer la synchronisation.
    • NEW_ROOT_DIRECTORY: (facultatif) chemin d'accès dans le dépôt Git au nouveau répertoire racine contenant la configuration que vous souhaitez synchroniser.
    • ROOT_AUTH_TYPE: cette valeur doit être identique à l'objet RootSync/root-sync existant.
    • ROOT_EMAIL: cette valeur doit être identique à l'objet RootSync/root-sync existant.

  7. Attendez que le nouvel objet RootSync root-sync-1 soit synchronisé. Vous pouvez vérifier l'état à l'aide de la commande suivante:

    nomos status

  8. Supprimez les ressources avec l'annotation configmanagement.gke.io/managed: disabled du dépôt d'origine. Procédez au commit et au transfert de la modification :

    git commit -am 'remove configuration managed by the new root repository'

  9. Attendez que l'objet RootSync root-sync existant soit synchronisé à l'aide de la commande suivante:

    nomos status

Scinder un dépôt racine hiérarchique

La procédure permettant de scinder un dépôt hiérarchique est semblable à celle d'un dépôt non structuré.

Il existe trois différences principales :

  1. Le nouveau dépôt racine (ou le nouveau répertoire) doit également être hiérarchique. Vous devez copier les répertoires existants system/ et clusterregistry/ dans le nouveau dépôt racine (ou le nouveau répertoire).

  2. Les ressources d'un espace de noms ne peuvent pas être réparties dans plusieurs dépôts. Sinon, les différents rapprochements auront du mal à gérer l'espace de noms.

  3. L'objet RootSync root-sync-1 doit utiliser spec.sourceFormat: hierarchical.

Comme nous recommandons des dépôts non structurés, vous pouvez également envisager de convertir votre dépôt hiérarchique en dépôt non structuré avant de le diviser.