Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Suddividere un repository in più repository

Quando gestisci migliaia di risorse Kubernetes in Config Sync, la suddivisione di un repository root o dello spazio dei nomi di grandi dimensioni in più repository più piccoli ti aiuta a migliorare la velocità di riconciliazione e a prevenire errori di sincronizzazione.

In Config Sync, un repository sincronizzato si riferisce alla combinazione di un repository Git, un branch, una revisione e una directory. Suddividendo un repository monolitico in più oggetti RootSync o RepoSync, riduci il numero di risorse monitorate e applicate da ogni strumento di riconciliazione.

Perché i repository di grandi dimensioni causano problemi di sincronizzazione

Quando il repository root contiene un numero elevato di risorse,ad esempio più di 5000,Config Sync potrebbe riscontrare problemi di prestazioni o sincronizzazione per i seguenti motivi:

L'oggetto ResourceGroup potrebbe superare il limite di dimensioni dell'oggetto etcd. L'oggetto ResourceGroup registra il gruppo, il tipo, lo spazio dei nomi e il nome di tutte le risorse nel repository Git. Un numero elevato di risorse può comportare un oggetto ResourceGroup di grandi dimensioni.
La sincronizzazione di un repository di grandi dimensioni richiede più tempo rispetto alla sincronizzazione di un repository più piccolo, perché Config Sync applica le risorse in sequenza al cluster. Se Config Sync non riesce ad applicare una risorsa al primo tentativo, deve riprovare.

Quando si verificano questi problemi, devi suddividere il repository root in più repository in modo che ogni repository root gestisca meno risorse.

Suddividi un repository root non strutturato

I passaggi seguenti utilizzano gli oggetti RootSync come esempio, ma puoi applicarli anche agli oggetti RepoSync.

1.21.0 o versioni successive (consigliata)

Questo metodo funziona per Config Sync versione 1.21.0 e successive grazie a un finalizzatore aggiunto in quella release, che interrompe la gestione degli oggetti quando viene eliminato un oggetto RootSync o RepoSync. In precedenza, gli oggetti orfani avevano metadati persistenti, che impedivano la loro gestione da parte di altri client o di nuovi oggetti RootSync o RepoSync.

Supponiamo che il repository root sia sincronizzato dall'oggetto RootSync single-root-sync. Dopo aver suddiviso il repository, avrai due repository root. Uno è sincronizzato dall'oggetto RootSync root-sync-1, mentre l'altro è sincronizzato dall'oggetto RootSync root-sync-2.

Per suddividere il repository, segui questi passaggi:

Assicurati che RootSync single-root-sync abbia il valore di annotazione configsync.gke.io/deletion-propagation-policy di Orphan o che non sia impostato. Il valore predefinito, se non impostato, è lo stesso di "Orfano". Questa impostazione garantisce che gli oggetti non vengano eliminati.

Elimina RootSync single-root-sync:

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

Per configurare i nuovi repository, segui questi passaggi:
1. Crea un nuovo repository o una nuova directory nel repository Git esistente.
2. Sposta le risorse nel nuovo repository o nella nuova directory.
3. Se stai suddividendo il repository root in più di due repository, ripeti questi passaggi in base alle necessità.

Esegui il commit e il push della modifica:

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

Applica gli oggetti RootSync root-sync-1 e root-sync-2. In questo modo, il nuovo repository o la nuova directory vengono sincronizzati in modo che gli oggetti esistenti nel cluster siano gestiti dai nuovi oggetti RootSync root-sync-1 e 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
```
Sostituisci quanto segue:
- NEW_ROOT_REPOSITORY: l'URL del repository Git da utilizzare come nuovo repository root. Puoi inserire gli URL utilizzando il protocollo HTTPS o SSH. Ad esempio, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilizza il protocollo HTTPS. Se non inserisci un protocollo, l'URL viene trattato come un URL HTTPS.
- NEW_ROOT_REVISION: (facoltativo) la revisione Git (tag o hash) del nuovo repository root di cui eseguire il checkout.
- NEW_ROOT_BRANCH: (facoltativo) il branch del nuovo repository root da cui eseguire la sincronizzazione.
- NEW_ROOT_DIRECTORY: (facoltativo) il percorso nel repository Git alla nuova directory root che contiene la configurazione con cui vuoi eseguire la sincronizzazione.
- ROOT_AUTH_TYPE: questo valore deve essere lo stesso dell'oggetto RootSync/root-sync esistente.
- ROOT_EMAIL: questo valore deve essere uguale all'oggetto RootSync/root-sync esistente.
Attendi la sincronizzazione del nuovo oggetto RootSync root-sync-1. Puoi controllare lo stato utilizzando il seguente comando:
```
nomos status
```

Qualsiasi versione

Questo metodo funziona per qualsiasi versione di Config Sync, inclusa la versione 1.21.0, ma ti consigliamo di utilizzare il metodo disponibile nella versione 1.21.0 e successive perché richiede meno passaggi. Se la tua versione di Config Sync è precedente alla 1.21.0, puoi utilizzare questo metodo.

Supponiamo che il repository root sia sincronizzato dall'oggetto RootSync root-sync. Dopo aver suddiviso il repository, avrai due repository root. Uno è sincronizzato dall'oggetto RootSync root-sync, mentre l'altro è sincronizzato dall'oggetto RootSync root-sync-1.

Per suddividere il repository, segui questi passaggi:

Nel repository root esistente, scegli le risorse che prevedi di spostare in un altro repository o in un'altra directory e aggiungi l'annotazione configmanagement.gke.io/managed: disabled. Questa annotazione garantisce che gli oggetti esistenti nel cluster non vengano interessati quando sposti la loro configurazione da un repository a un altro. Se utilizzi il formato Kustomize o i grafici Helm, puoi scegliere circa la metà delle basi e aggiungere l'annotazione comune al file kustomization.yaml, come in questo esempio:
```
# kustomization.yaml
commonAnnotations:
  configmanagement.gke.io/managed: disabled
```
Esegui il commit e il push della modifica: sh git commit -am 'disable Config Sync management on subset of the configuration'
Attendi la sincronizzazione dell'oggetto RootSync root-sync esistente utilizzando il seguente comando:
```
nomos status
```
Per configurare il secondo repository:
1. Crea un nuovo repository o una nuova directory nel repository Git esistente.
2. Copia le risorse con l'annotazione configmanagement.gke.io/managed: disabled nel nuovo repository o nella nuova directory.
3. Rimuovi l'annotazione configmanagement.gke.io/managed: disabled nel nuovo repository o nella nuova directory.
4. Se stai suddividendo il repository root in più di due repository, ripeti questi passaggi in base alle necessità.

Esegui il commit e il push della modifica:

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

Applica un oggetto RootSync root-sync-1 per sincronizzare il nuovo repository o la nuova directory in modo che gli oggetti esistenti nel cluster vengano gestiti dal nuovo oggetto 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
```
Sostituisci quanto segue:
- NEW_ROOT_REPOSITORY: l'URL del repository Git da utilizzare come nuovo repository root. Puoi inserire gli URL utilizzando il protocollo HTTPS o SSH. Ad esempio, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilizza il protocollo HTTPS. Se non inserisci un protocollo, l'URL viene trattato come un URL HTTPS.
- NEW_ROOT_REVISION: (facoltativo) la revisione Git (tag o hash) del nuovo repository root di cui eseguire il checkout.
- NEW_ROOT_BRANCH: (facoltativo) il branch del nuovo repository root da cui eseguire la sincronizzazione.
- NEW_ROOT_DIRECTORY: (facoltativo) il percorso nel repository Git alla nuova directory root che contiene la configurazione con cui vuoi eseguire la sincronizzazione.
- ROOT_AUTH_TYPE: questo valore deve essere lo stesso dell'oggetto RootSync/root-sync esistente.
- ROOT_EMAIL: questo valore deve essere uguale all'oggetto RootSync/root-sync esistente.
Attendi la sincronizzazione del nuovo oggetto RootSync root-sync-1. Puoi controllare lo stato utilizzando il seguente comando:
```
nomos status
```
Rimuovi le risorse con l'annotazione configmanagement.gke.io/managed: disabled dal repository originale. Esegui il commit e il push della modifica:
```
git commit -am 'remove configuration managed by the new root repository'
```
Attendi la sincronizzazione dell'oggetto RootSync root-sync esistente utilizzando il seguente comando:
```
nomos status
```

Suddividi un repository root gerarchico

I passaggi per suddividere un repository gerarchico sono simili a quelli per suddividere un repository non strutturato.

Le differenze principali sono tre:

Anche il nuovo repository root (o la nuova directory) deve essere gerarchico. Devi copiare le directory system/ e clusterregistry/ esistenti nel nuovo repository root (o nella nuova directory).
Le risorse in uno spazio dei nomi non possono essere distribuite in più repository. In caso contrario, i diversi riconciliatori si contendono la gestione dello spazio dei nomi.
L'oggetto RootSync root-sync-1 deve utilizzare spec.sourceFormat: hierarchical.

Poiché consigliamo i repository non strutturati, potresti anche prendere in considerazione la possibilità di convertire il tuo repository gerarchico in un repository non strutturato prima di suddividerlo.