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

Lorsque vous gérez des milliers de ressources Kubernetes dans Config Sync, diviser un grand dépôt racine ou d'espace de noms en plusieurs dépôts plus petits vous permet d'améliorer la vitesse de rapprochement et d'éviter les échecs de synchronisation.

Dans Config Sync, un dépôt synchronisé fait référence à la combinaison d'un dépôt Git, d'une branche, d'une révision et d'un répertoire. En divisant un dépôt monolithique en plusieurs objets RootSync ou RepoSync, vous réduisez le nombre de ressources que chaque rapprochement suit et applique.

Pourquoi les dépôts volumineux causent-ils des problèmes de synchronisation ?

Lorsque votre dépôt racine contient un grand nombre de ressources (par exemple,plus de 5 000), Config Sync peut rencontrer des problèmes de performances ou de synchronisation pour les raisons suivantes :

  • 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 peut être volumineux.
  • La synchronisation d'un dépôt volumineux prend plus de temps que celle d'un dépôt plus petit, car Config Sync applique les ressources de manière séquentielle au cluster. Si Config Sync ne parvient pas à appliquer une ressource lors de la première tentative, il doit réessayer.

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

Scinder un dépôt racine non structuré

Les étapes suivantes utilisent des objets RootSync comme exemple, mais vous pouvez également les appliquer aux objets RepoSync.

Cette méthode fonctionne pour Config Sync 1.21.0 et les versions ultérieures, car un finaliseur a été ajouté dans cette version, ce qui arrête la gestion des objets lorsqu'un objet RootSync ou RepoSync est supprimé. Auparavant, les objets orphelins avaient des métadonnées persistantes, ce qui empêchait leur gestion par d'autres clients ou par 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'objet RootSync single-root-sync possède la valeur d'annotation configsync.gke.io/deletion-propagation-policy de Orphan ou qu'elle n'est pas définie. La valeur par défaut lorsqu'elle n'est pas définie est identique à "Orphan". Ce paramètre garantit que les objets ne sont pas supprimés.

  2. Supprimez l'objet RootSync single-root-sync :

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

  3. Configurez vos nouveaux dépôts en procédant 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 vers 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 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 pour toutes les versions de Config Sync, y compris la version 1.21.0. Toutefois, 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.