Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Divide un repositorio en varios repositorios

Cuando administras miles de recursos de Kubernetes en el Sincronizador de configuración, dividir un repositorio raíz o de espacio de nombres grande en varios repositorios más pequeños te ayuda a mejorar la velocidad de conciliación y evitar fallas de sincronización.

En el Sincronizador de configuración, un repositorio sincronizado hace referencia a la combinación de un repositorio de Git, una rama, una revisión y un directorio. Si divides un repositorio monolítico en varios objetos RootSync o RepoSync, reduces la cantidad de recursos de los que cada conciliador hace un seguimiento y aplica.

Por qué los repositorios grandes causan problemas de sincronización

Cuando tu repositorio raíz contiene una gran cantidad de recursos, por ejemplo, más de 5,000, el Sincronizador de configuración puede experimentar problemas de rendimiento o sincronización por los siguientes motivos:

El objeto ResourceGroup puede exceder el límite de tamaño del objeto etcd. El objeto ResourceGroup registra el grupo, la categoría, el espacio de nombres y el nombre de todos los recursos en el repositorio de Git. Una gran cantidad de recursos puede generar un objeto ResourceGroup grande.
Sincronizar un repositorio grande lleva más tiempo que sincronizar uno más pequeño, ya que el Sincronizador de configuración aplica los recursos al clúster de manera secuencial. Si el Sincronizador de configuración no puede aplicar un recurso en el primer intento, debe volver a intentarlo.

Cuando encuentras estos problemas, debes dividir tu repositorio raíz en varios de ellos para que cada repositorio raíz administre menos recursos.

Divide un repositorio raíz no estructurado

En los siguientes pasos, se usan objetos RootSync como ejemplo, pero también puedes aplicarlos a los objetos RepoSync.

1.21.0 o posterior (recomendado)

Este método funciona para la versión 1.21.0 y posteriores del Sincronizador de configuración debido a un finalizador que se agregó en esa versión, que deja de administrar objetos cuando se borra un objeto RootSync o RepoSync. Anteriormente, los objetos huérfanos tenían metadatos persistentes, lo que impedía que otros clientes o nuevos objetos RootSync o RepoSync los administraran.

Supongamos que tu repositorio raíz está sincronizado con el objeto RootSync single-root-sync. Después de dividir el repositorio, tendrás dos repositorios raíz. Uno se sincroniza con el objeto RootSync root-sync-1, mientras que el otro se sincroniza con el objeto RootSync root-sync-2.

Para dividir el repositorio, sigue estos pasos:

Asegúrate de que el RootSync single-root-sync tenga el valor de anotación configsync.gke.io/deletion-propagation-policy de Orphan o que no esté configurado. El valor predeterminado cuando no se establece es el mismo que "Huérfano". Este parámetro de configuración garantiza que no se borren los objetos.

Borra el RootSync single-root-sync:

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

Para configurar tus repositorios nuevos, sigue estos pasos:
1. Crea un repositorio o un directorio nuevo en tu repositorio de Git existente.
2. Mueve los recursos al repositorio o directorio nuevo.
3. Si divides tu repositorio raíz en más de dos repositorios, repite estos pasos según sea necesario.

Confirma y envía el cambio:

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

Aplica los objetos RootSync root-sync-1 y root-sync-2. De esta manera, se sincroniza el repositorio o directorio nuevo para que los objetos existentes en el clúster se administren con los objetos RootSync nuevos root-sync-1 y 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
```
Reemplaza lo siguiente:
- NEW_ROOT_REPOSITORY: Es la URL del repositorio de Git que se usará como repositorio raíz nuevo. Puedes ingresar las URL con el protocolo HTTPS o SSH. Por ejemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa el protocolo HTTPS. Si no ingresas un protocolo, la URL se trata como una URL HTTPS.
- NEW_ROOT_REVISION: Es la revisión de Git (etiqueta o hash) del nuevo repositorio raíz que se debe pagar (opcional).
- NEW_ROOT_BRANCH: Es la rama del repositorio raíz nuevo desde la que se realiza la sincronización (opcional).
- NEW_ROOT_DIRECTORY: (Opcional) Es la ruta de acceso en el repositorio de Git al directorio raíz nuevo que contiene la configuración con la que deseas sincronizar.
- ROOT_AUTH_TYPE: Este valor debe ser el mismo que el del objeto RootSync/root-sync existente.
- ROOT_EMAIL: Este valor debe ser el mismo que el objeto RootSync/root-sync existente.
Espera a que se sincronice el nuevo objeto RootSync root-sync-1. Puedes verificar el estado con el siguiente comando:
```
nomos status
```

Cualquier versión

Este método funciona para cualquier versión del Sincronizador de configuración, incluida la versión 1.21.0, pero te recomendamos que uses el método disponible en la versión 1.21.0 y posteriores, ya que requiere menos pasos. Si tu versión del Sincronizador de configuración es anterior a la 1.21.0, puedes usar este método en su lugar.

Supongamos que tu repositorio raíz está sincronizado con el objeto RootSync root-sync. Después de dividir el repositorio, tendrás dos repositorios raíz. Uno se sincroniza con el objeto RootSync root-sync, mientras que el otro se sincroniza con el objeto RootSync root-sync-1.

Para dividir el repositorio, sigue estos pasos:

En tu repositorio raíz existente, elige los recursos que planeas mover a un repositorio diferente o a un directorio y agrégales la anotación configmanagement.gke.io/managed: disabled. Esta anotación garantiza que los objetos existentes en el clúster no se vean afectados cuando mueves su configuración de un repositorio a otro. Si usas el formato Kustomize o los gráficos de Helm, puedes elegir aproximadamente la mitad de las bases y agregar la anotación común al archivo kustomization.yaml, como en este ejemplo:
```
# kustomization.yaml
commonAnnotations:
  configmanagement.gke.io/managed: disabled
```
Confirme y envíe el cambio: sh git commit -am 'disable Config Sync management on subset of the configuration'
Espera a que se sincronice el objeto RootSync root-sync existente con el siguiente comando:
```
nomos status
```
Para configurar tu segundo repositorio, sigue estos pasos:
1. Crea un repositorio o un directorio nuevo en tu repositorio de Git existente.
2. Copia los recursos con la anotación configmanagement.gke.io/managed: disabled en el repositorio o directorio nuevo.
3. Quita la anotación configmanagement.gke.io/managed: disabled en el repositorio o directorio nuevo.
4. Si divides tu repositorio raíz en más de dos repositorios, repite estos pasos según sea necesario.

Confirma y envía el cambio:

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

Aplica un objeto RootSync root-sync-1 para sincronizar el nuevo repositorio o directorio, de modo que el nuevo objeto RootSync root-sync-1 administre los objetos existentes en el clúster.
```
 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
```
Reemplaza lo siguiente:
- NEW_ROOT_REPOSITORY: Es la URL del repositorio de Git que se usará como repositorio raíz nuevo. Puedes ingresar las URL con el protocolo HTTPS o SSH. Por ejemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa el protocolo HTTPS. Si no ingresas un protocolo, la URL se trata como una URL HTTPS.
- NEW_ROOT_REVISION: Es la revisión de Git (etiqueta o hash) del nuevo repositorio raíz que se debe pagar (opcional).
- NEW_ROOT_BRANCH: Es la rama del repositorio raíz nuevo desde la que se realiza la sincronización (opcional).
- NEW_ROOT_DIRECTORY: (Opcional) Es la ruta de acceso en el repositorio de Git al directorio raíz nuevo que contiene la configuración con la que deseas sincronizar.
- ROOT_AUTH_TYPE: Este valor debe ser el mismo que el del objeto RootSync/root-sync existente.
- ROOT_EMAIL: Este valor debe ser el mismo que el objeto RootSync/root-sync existente.
Espera a que se sincronice el nuevo objeto RootSync root-sync-1. Puedes verificar el estado con el siguiente comando:
```
nomos status
```
Quita los recursos con la anotación configmanagement.gke.io/managed: disabled del repositorio original. Confirma y envía el cambio:
```
git commit -am 'remove configuration managed by the new root repository'
```
Espera a que se sincronice el objeto RootSync root-sync existente con el siguiente comando:
```
nomos status
```

Divide un repositorio raíz jerárquico

Los pasos para dividir un repositorio jerárquico son similares a los pasos para dividir un repositorio no estructurado.

Hay tres diferencias principales:

El nuevo repositorio raíz (o nuevo directorio) también debe ser jerárquico. Debes copiar los directorios existentes system/ y clusterregistry/ del directorio en el nuevo repositorio raíz (o en el directorio nuevo).
Los recursos de un espacio de nombres no se pueden distribuir a través de varios repositorios. De lo contrario, diferentes conciliadores luchan para administrar el espacio de nombres.
El objeto RootSync root-sync-1 debe usar spec.sourceFormat: hierarchical.

Dado que recomendamos repositorios no estructurados, también puedes considerar convertir tu repositorio jerárquico en un repositorio no estructurado antes de dividirlo.