Installa Config Sync manualmente utilizzando kubectl

Quando il tuo ambiente richiede la gestione diretta delle risorse Kubernetes da riga di comando, l'installazione di Config Sync con i comandi kubectl ti consente di sincronizzare le configurazioni dei cluster da una fonte di verità centrale. Sebbene questo metodo di installazione sia supportato, non è compatibile con la consoleCloud de Confiance o con Google Cloud CLI. Per gestire Config Sync utilizzando questi strumenti, consulta Personalizza l'installazione di Config Sync.

Prima di iniziare

Questa sezione descrive i prerequisiti da soddisfare prima di installare Config Sync utilizzando kubectl.

Prepara l'ambiente locale

Prima di installare Config Sync, assicurati di aver preparato l'ambiente locale completando le seguenti attività:

• Creare o avere accesso a una fonte di riferimento.

• Installa e inizializza Google Cloud CLI, che fornisce i comandi gcloud, kubectl e nomos utilizzati in queste istruzioni. Se utilizzi Cloud Shell, Google Cloud CLI è preinstallato.

• kubectl non viene installato per impostazione predefinita da Google Cloud CLI. Per installare kubectl, utilizza il seguente comando:

  gcloud components install kubectl
  

• Autenticati su Cloud de Confiance by S3NS utilizzando il comando gcloud auth login in modo da poter scaricare i componenti di Config Sync.

Prepara i cluster

Crea o accedi a un cluster Google Kubernetes Engine che soddisfi i requisiti per Config Sync.

Prepara le autorizzazioni

L'utente Cloud de Confiance che installa Config Sync deve disporre delle autorizzazioni IAM per creare nuovi ruoli nel cluster. Se necessario, concedi questi ruoli con i seguenti comandi:

gcloud container clusters get-credentials CLUSTER_NAME

kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole cluster-admin --user USER_ACCOUNT

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del tuo cluster
• USER_ACCOUNT: l'indirizzo email del tuo account Cloud de Confiance

A seconda di come hai configurato Google Cloud CLI sul tuo sistema locale, potresti dover aggiungere i campi --project e --zone.

Se devi concedere a Config Sync l'accesso a OCI utilizzando gcpserviceaccount come tipo di autenticazione, per creare un'associazione di policy devi disporre anche dell'autorizzazione iam.serviceAccounts.setIamPolicy. Puoi ottenere questa autorizzazione concedendo il ruolo IAM Amministratore service account (roles/iam.serviceAccountAdmin). Potresti anche ottenere questa autorizzazione con ruoli personalizzati o altri ruoli predefiniti.

Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso.

Registra un cluster

Per registrare un cluster in Config Sync, completa i seguenti passaggi:

1. Esegui il deployment di Config Sync
2. Concedi a Config Sync l'accesso di sola lettura a uno dei seguenti elementi:
   • Git
   • OCI
   • Helm
3. Configura Config Sync

Esegui il deployment di Config Sync

Dopo aver verificato di soddisfare tutti i prerequisiti, puoi eseguire il deployment di Config Sync scaricando e applicando un manifest YAML:

1. Scarica l'ultima versione dei manifest di Config Sync utilizzando il seguente comando. Per scaricare una versione specifica, consulta Download.

   gcloud storage cp gs://config-management-release/released/latest/config-sync.tar.gz config-sync.tar.gz
   

2. Estrai l'archivio:

   tar -xzvf config-sync.tar.gz

3. Nell'archivio che hai estratto nel passaggio precedente, segui le istruzioni nel file README.md fornito per modificare la kustomization.

4. Per aggiornare l'installazione di Config Sync, applica il manifest di cui è stato eseguito il rendering che hai creato seguendo le istruzioni di README.md:

   kubectl apply -f CONFIG_SYNC_MANIFEST
   

   Sostituisci CONFIG_SYNC_MANIFEST con il nome del manifest sottoposto a rendering.

5. Sostituisci il comando nomos su tutti i client con la nuova versione. Questa modifica garantisce che il comando nomos possa sempre ottenere lo stato di tutti i cluster registrati e convalidare le relative configurazioni.

Se l'operazione non riesce a causa di un problema con Config Sync che non è dovuto a un errore di sintassi YAML o JSON, l'oggetto potrebbe essere istanziato nel cluster, ma potrebbe non funzionare correttamente. In questo caso, puoi utilizzare il comando nomos status per verificare la presenza di errori nell'oggetto.

Un'installazione valida senza problemi ha lo stato PENDING o SYNCED.

Un'installazione non valida ha lo stato NOT CONFIGURED ed elenca uno dei seguenti errori:

• missing git-creds Secret
• git-creds Secret is missing the key specified by secretType

Per risolvere il problema, correggi l'errore di configurazione. A seconda del tipo di errore, potrebbe essere necessario applicare nuovamente il manifest di Config Sync al cluster.

Se il problema è che hai dimenticato di creare il secret git-creds, Config Sync lo rileva non appena lo crei e non è necessario applicare nuovamente la configurazione.

Concedi l'accesso di sola lettura a Config Sync

Se archivi le configurazioni in Git, devi concedere a Config Sync l'accesso di sola lettura a Git. Se archivi le configurazioni come immagini OCI, devi concedere a Config Sync l'accesso di sola lettura a OCI. Se archivi le tue configurazioni in Helm, devi concedere a Config Sync l'accesso di sola lettura a Helm.

Concedi a Config Sync l'accesso di sola lettura a Git

Config Sync richiede l'accesso di sola lettura al tuo repository Git per poter leggere le configurazioni di cui è stato eseguito il commit nel repository e applicarle ai tuoi cluster.

Se il repository non richiede l'autenticazione per l'accesso in sola lettura, puoi continuare a configurare Config Sync e utilizzare none come tipo di autenticazione. Ad esempio, se puoi sfogliare il repository utilizzando un'interfaccia web senza eseguire l'accesso o se puoi utilizzare git clone per creare un clone del repository localmente senza fornire credenziali o utilizzando credenziali salvate, non è necessario eseguire l'autenticazione. In questo caso, non è necessario creare un secret.

Tuttavia, la maggior parte degli utenti deve creare le credenziali perché l'accesso in lettura al proprio repository è limitato. Se sono richieste credenziali, queste vengono archiviate nel secret git-creds su ogni cluster registrato (a meno che tu non utilizzi un account di servizio Google). Il secret deve essere denominato git-creds perché si tratta di un valore fisso.

Config Sync supporta i seguenti meccanismi di autenticazione:

• Coppia di chiavi SSH (ssh)
• Cookiefile (cookiefile)
• Token (token)
• Account di servizio Google (gcpserviceaccount)
• Account di servizio predefinito di Compute Engine (gcenode)
• App GitHub (githubapp)

Il meccanismo che scegli dipende da ciò che è supportato dal tuo repository. In genere, consigliamo di utilizzare una coppia di chiavi SSH. Sia GitHub che Bitbucket supportano l'utilizzo di una coppia di chiavi SSH. Tuttavia, se utilizzi un repository in Cloud Source Repositories o Secure Source Manager, ti consigliamo di utilizzare un account di servizio Google, poiché la procedura è più semplice. Se la tua organizzazione ospita il tuo repository e non sai quali metodi di autenticazione sono supportati, contatta l'amministratore.

Per utilizzare un repository in Cloud Source Repositories come repository Config Sync, completa i seguenti passaggi per recuperare l'URL di Cloud Source Repositories:

1. Elenca tutti i repository:

   gcloud source repos list
   

2. Dall'output, copia l'URL del repository che vuoi utilizzare. Ad esempio:

   REPO_NAME  PROJECT_ID  URL
   my-repo    my-project  https://source.developers.google.com/p/my-project/r/my-repo-csr
   

   Devi utilizzare questo URL quando configuri Config Sync nella sezione seguente. Se configuri Config Sync utilizzando la consoleCloud de Confiance , aggiungi l'URL nel campo URL. Se configuri Config Sync utilizzando Google Cloud CLI, aggiungi l'URL al campo syncRepo del file di configurazione.

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/source.reader \
  --member="serviceAccount:PROJECT_NUMBER-compute@developer.s3ns-system.iam.gserviceaccount.com"

Concedi a Config Sync l'accesso di sola lettura a OCI

Config Sync richiede l'accesso di sola lettura all'immagine OCI archiviata in Artifact Registry per poter leggere le configurazioni incluse nell'immagine e applicarle ai cluster.

Se l'immagine non richiede l'autenticazione per l'accesso di sola lettura, puoi continuare a configurare Config Sync e utilizzare none come tipo di autenticazione. Ad esempio, se l'immagine è pubblica e accessibile a chiunque su internet, non è necessario eseguire l'autenticazione.

Tuttavia, la maggior parte degli utenti deve creare credenziali per accedere alle immagini limitate. Config Sync supporta i seguenti meccanismi di autenticazione:

• ServiceAccount Kubernetes (k8sserviceaccount)

• Account di servizio predefinito di Compute Engine (gcenode)

gcloud projects add-iam-policy-binding PROJECT_ID \
   --member=serviceAccount:PROJECT_NUMBER-compute@developer.s3ns-system.iam.gserviceaccount.com \
   --role=roles/artifactregistry.reader

Configura Config Sync per un'autorità di certificazione

Per i server configurati con certificati di un'autorità di certificazione (CA) non ancora attendibile, Config Sync può essere configurato in modo da utilizzare un certificato CA per verificare le connessioni HTTPS al server. Questa opzione è supportata per i server Git, Helm o OCI. Il certificato CA deve includere certificati SSL completi (radice/intermedio/foglia). Se il tuo server utilizza già una CA attendibile o non ti connetti tramite HTTPS, puoi saltare questo passaggio e lasciare caCertSecretRef non impostato.

Concedi a Config Sync l'accesso di sola lettura a Helm

Config Sync richiede l'accesso di sola lettura al repository Helm per poter leggere i grafici Helm nel repository e installarli nei cluster.

Se il repository non richiede l'autenticazione per l'accesso in sola lettura, puoi continuare a configurare Config Sync e utilizzare none come tipo di autenticazione. Ad esempio, se il tuo repository Helm è pubblico e chiunque su internet può accedervi, non è necessario eseguire l'autenticazione.

Tuttavia, la maggior parte degli utenti deve creare credenziali per accedere ai repository Helm privati. Config Sync supporta i seguenti meccanismi di autenticazione:

• Token (token)
• ServiceAccount Kubernetes (k8sserviceaccount)
• Account di servizio predefinito di Compute Engine (gcenode)

kubectl create secret generic SECRET_NAME \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
    --from-literal=password=PASSWORD

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:PROJECT_NUMBER-compute@developer.s3ns-system.iam.gserviceaccount.com \
    --role=roles/artifactregistry.reader

Configura Config Sync

Per configurare Config Sync dal repository root, devi creare un oggetto RootSync che sincronizzi il repository root con il cluster. Puoi creare un solo repository root per cluster e il repository root può essere un repository non strutturato o un repository gerarchico.

1. Se utilizzi il webhook di ammissione di Config Sync (il webhook di ammissione è disabilitato per impostazione predefinita) e installi Config Sync in un cluster privato, aggiungi una regola firewall per consentire la porta 10250. Il webhook di ammissione di Config Sync utilizza la porta 10250 per la prevenzione della deviazione.

2. Attendi che le CRD RootSync e RepoSync siano disponibili:

   until kubectl get customresourcedefinitions rootsyncs.configsync.gke.io reposyncs.configsync.gke.io; do date; sleep 1; echo ""; done
   

3. Salva uno dei seguenti manifest come root-sync.yaml. Utilizza la versione del manifest corrispondente al tipo di origine delle tue configurazioni.

   Git

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: git
     sourceFormat: unstructured
     git:
       repo: ROOT_REPOSITORY
       revision: ROOT_REVISION
       branch: ROOT_BRANCH
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       secretRef:
         name: ROOT_SECRET_NAME
       noSSLVerify: ROOT_NO_SSL_VERIFY
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   Sostituisci quanto segue:

   • ROOT_SYNC_NAME: aggiungi il nome dell'oggetto RootSync.
   • ROOT_REPOSITORY: aggiungi l'URL del repository Git da utilizzare come 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. Questo campo è obbligatorio.
   • ROOT_REVISION: aggiungi la revisione Git (tag o hash) o il branch da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è HEAD. Quando utilizzi un hash, deve essere un hash completo e non una forma abbreviata.
   • ROOT_BRANCH: aggiungi il branch del repository da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è master. Per semplicità, ti consigliamo di utilizzare il campo revision per specificare un nome di branch. Se vengono specificati sia il campo revision sia il campo branch, revision ha la precedenza su branch.
   • ROOT_DIRECTORY: aggiungi il percorso nel repository Git alla directory root che contiene la configurazione con cui vuoi eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è la directory root (/) del repository.

   • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

     • none: non utilizzare l'autenticazione
     • ssh: utilizza una coppia di chiavi SSH
     • cookiefile: utilizza un cookiefile
     • token: utilizza un token
     • gcpserviceaccount: utilizza un account di servizio Google per accedere a un repository Cloud Source Repositories.
     • gcenode: utilizza un account di servizio Google per accedere a un repository Cloud Source Repositories. Seleziona questa opzione solo se Workload Identity Federation for GKE non è abilitato nel tuo cluster.

     Per ulteriori informazioni su questi tipi di autenticazione, consulta Concessione dell'accesso di sola lettura a Git per Config Sync.

     Questo campo è obbligatorio.

   • ROOT_EMAIL: se hai aggiunto gcpserviceaccount come ROOT_AUTH_TYPE, aggiungi l'indirizzo email del tuo account di servizio Google. Ad esempio acm@PROJECT_ID.s3ns.iam.gserviceaccount.com.

   • ROOT_SECRET_NAME: aggiungi il nome del secret. Se questo campo è impostato, devi aggiungere la chiave pubblica del secret al provider Git. Questo campo è facoltativo.

   • ROOT_NO_SSL_VERIFY: per disattivare la verifica del certificato SSL, imposta questo campo su true. Il valore predefinito è false.

   • ROOT_CA_CERT_SECRET_NAME: aggiungi il nome del tuo secret. Se questo campo è impostato, il tuo provider Git deve utilizzare un certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominata cert. Questo campo è facoltativo.

     Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configura l'autorità di certificazione

   Per una spiegazione dei campi e un elenco completo dei campi che puoi aggiungere al campo spec, consulta Campi RootSync.

   Questo manifest crea un oggetto RootSync che utilizza Git come origine.

   OCI

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: oci
     sourceFormat: unstructured
     oci:
       image: ROOT_IMAGE
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   Sostituisci quanto segue:

   • ROOT_SYNC_NAME: aggiungi il nome dell'oggetto RootSync.
   • ROOT_IMAGE: l'URL dell'immagine OCI da utilizzare come repository root, ad esempio LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Per impostazione predefinita, l'immagine viene estratta dal tag latest, ma puoi estrarre le immagini anche da TAG o DIGEST. Specifica TAG o DIGEST in PACKAGE_NAME:
     • Per eseguire il pull entro il giorno TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • Per eseguire il pull entro il giorno DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST

   • ROOT_DIRECTORY: aggiungi il percorso nel repository alla directory root che contiene la configurazione con cui vuoi eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è la directory root (/) del repository.

   • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

     • none: non utilizzare l'autenticazione
     • gcenode: utilizza il account di servizio predefinito di Compute Engine per accedere a un'immagine in Artifact Registry. Seleziona questa opzione solo se Workload Identity Federation for GKE non è abilitato nel tuo cluster.
     • gcpserviceaccount: utilizza un account di servizio Google per accedere a un'immagine.

     Questo campo è obbligatorio.

   • ROOT_EMAIL: se hai aggiunto gcpserviceaccount come ROOT_AUTH_TYPE, aggiungi l'indirizzo email del tuo account di servizio Google. Ad esempio acm@PROJECT_ID.s3ns.iam.gserviceaccount.com.

   • ROOT_CA_CERT_SECRET_NAME: aggiungi il nome del tuo secret. Se questo campo è impostato, il provider OCI deve utilizzare un certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominata cert. Questo campo è facoltativo.

   Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configura l'autorità di certificazione

   Per una spiegazione dei campi e un elenco completo dei campi che puoi aggiungere al campo spec, consulta Campi RootSync.

   Questo manifest crea un oggetto RootSync che utilizza un'immagine OCI come origine.

   Helm

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: helm
     sourceFormat: unstructured
     helm:
       repo: ROOT_HELM_REPOSITORY
       chart: HELM_CHART_NAME
       version: HELM_CHART_VERSION
       releaseName: HELM_RELEASE_NAME
       namespace: HELM_RELEASE_NAMESPACE
       values:
         foo:
           bar: VALUE_1
         baz:
         - qux: VALUE_2
           xyz: VALUE_3
       includeCRDs: HELM_INCLUDE_CRDS
       auth: ROOT_AUTH_TYPE
         gcpServiceAccountEmail: ROOT_EMAIL
         secretRef:
           name: ROOT_SECRET_NAME
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   Sostituisci quanto segue:

   • ROOT_SYNC_NAME: aggiungi il nome dell'oggetto RootSync.
   • ROOT_HELM_REPOSITORY: l'URL del repository Helm da utilizzare come 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. Questo campo è obbligatorio.
   • HELM_CHART_NAME: aggiungi il nome del tuo grafico Helm. Questo campo è obbligatorio.
   • HELM_CHART_VERSION: la versione del grafico. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzata l'ultima versione.
   • HELM_RELEASE_NAME: il nome della release Helm. Questo campo è facoltativo.
   • HELM_RELEASE_NAMESPACE: lo spazio dei nomi di destinazione per una release. Imposta uno spazio dei nomi solo per le risorse che contengono namespace: {{ .Release.Namespace }} nei relativi template. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzato lo spazio dei nomi predefinito config-management-system.
   • HELM_INCLUDE_CRDS: impostato su true se vuoi che il template Helm generi anche una CustomResourceDefinition. Questo campo è facoltativo. Se non viene specificato alcun valore, il valore predefinito è false e non verrà generata una CRD.
   • VALUE: i valori da utilizzare al posto dei valori predefiniti che accompagnano il grafico Helm. Formatta questo campo nello stesso modo del file values.yaml del grafico Helm. Questo campo è facoltativo.

   • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

     • none: non utilizzare l'autenticazione
     • token: utilizza un nome utente e una password per accedere a un repository Helm privato.
     • gcenode: utilizza il account di servizio predefinito di Compute Engine per accedere a un'immagine in Artifact Registry. Seleziona questa opzione solo se Workload Identity Federation for GKE non è abilitato nel tuo cluster.
     • gcpserviceaccount: utilizza un account di servizio Google per accedere a un'immagine.

     Questo campo è obbligatorio.

   • ROOT_EMAIL: se hai aggiunto gcpserviceaccount come ROOT_AUTH_TYPE, aggiungi l'indirizzo email del tuo account di servizio Google. Ad esempio acm@PROJECT_ID.s3ns.iam.gserviceaccount.com.

   • ROOT_SECRET_NAME: aggiungi il nome del secret se token è ROOT_AUTH_TYPE. Questo campo è facoltativo.

   • ROOT_CA_CERT_SECRET_NAME: aggiungi il nome del tuo secret. Se questo campo è impostato, il provider Helm deve utilizzare un certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominata cert. Questo campo è facoltativo.

   Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configura l'autorità di certificazione

   Per una spiegazione dei campi e un elenco completo dei campi che puoi aggiungere al campo spec, consulta Campi RootSync.

   Questo manifest crea un oggetto RootSync che utilizza Helm come origine.

4. Applica le modifiche:

   kubectl apply -f root-sync.yaml
   

(Facoltativo) Specifica un nome cluster per i selettori di cluster

Se vuoi utilizzare cluster-name-selectors, devi fornire un nome cluster a Config Sync. Questo passaggio è facoltativo ed è obbligatorio solo se utilizzi i selettori dei nomi dei cluster.

Per fornire un nome del cluster, completa i seguenti passaggi:

1. Aggiungi la variabile di ambiente CLUSTER_NAME al deployment reconciler-manager:

   kubectl set env deployment/reconciler-manager -n config-management-system CLUSTER_NAME=CLUSTER_NAME
   

   Sostituisci CLUSTER_NAME con il nome del cluster o del membership.

2. Per propagare il nome del cluster ai riconciliatori RootSync e RepoSync, riavvia il deployment reconciler-manager:

   kubectl rollout restart deployment/reconciler-manager -n config-management-system
   

Verifica lo stato di sincronizzazione del repository root

Puoi utilizzare il comando nomos status per controllare lo stato di sincronizzazione del repository root:

nomos status

Dovresti vedere un output simile al seguente esempio:

my_managed_cluster-1
  --------------------
  <root>   git@github.com:foo-corp/acme/admin@main
  SYNCED   f52a11e4

Verifica l'installazione di RootSync

Quando crei un oggetto RootSync, Config Sync crea un reconciler con il prefisso root-reconciler. Un reconciler è un pod di cui viene eseguito il deployment come deployment. Sincronizza i manifest da un repository Git a un cluster.

Puoi verificare che l'oggetto RootSync funzioni correttamente controllando lo stato del deployment root-reconciler:

kubectl get -n config-management-system deployment \
    -l configsync.gke.io/sync-name=ROOT_SYNC_NAME

Sostituisci ROOT_SYNC_NAME con il nome di RootSync.

Dovresti vedere un output simile al seguente esempio:

NAME              READY   UP-TO-DATE   AVAILABLE   AGE
root-reconciler   1/1     1            1           3h42m

Per ulteriori modi per esplorare lo stato dell'oggetto RootSync, consulta Monitoraggio degli oggetti RootSync e RepoSync.

Dopo aver completato la configurazione del repository root, puoi facoltativamente scegliere di configurare la sincronizzazione da più repository. Questi repository sono utili se vuoi un repository che contenga configurazioni con ambito dello spazio dei nomi sincronizzate con un determinato spazio dei nomi tra i cluster.

Esegui l'upgrade di Config Sync

I passaggi per eseguire l'upgrade di Config Sync dipendono dalla versione da cui esegui l'upgrade e da quella a cui esegui l'upgrade. A partire dalla versione 1.20.0, Config Sync viene fornito come installazione autonoma senza l'operatore ConfigManagement. Se esegui l'upgrade da una versione precedente alla 1.20.0 alla versione 1.20.0 o successiva, devi prima disinstallare l'operatore ConfigManagement prima di eseguire l'upgrade.

Per eseguire l'upgrade da una versione non supportata, esegui un upgrade passo passo con incrementi di non più di tre versioni secondarie alla volta. Ad esempio, se la versione attuale di Config Sync è 1.16.0, esegui prima l'upgrade alla versione 1.19.0 e poi alla versione 1.22.0.

Disinstalla l'operatore ConfigManagement

Se esegui l'upgrade da una versione precedente alla 1.20.0 alla versione 1.20.0 o successive, devi prima disinstallare l'operatore ConfigManagement.

Puoi verificare se Config Management è installato sul tuo cluster eseguendo questo comando:

kubectl get configmanagement

Se l'output non è vuoto, Config Management è installato sul cluster. Per disinstallare Config Management, completa i seguenti passaggi per disinstallare Config Management, ma lascia Config Sync installato sul cluster. Ti consigliamo di utilizzare nomos CLI per disinstallare l'operatore ConfigManagement perché ha un'interfaccia più completa e una gestione degli errori più efficace. Devi utilizzare lo script shell solo se non hai accesso a nomos CLI.

 #!/bin/bash

 set -euox pipefail

 hnc_enabled="$(kubectl get configmanagements.configmanagement.gke.io config-management -o=jsonpath="{.spec.hierarchyController.enabled}" --ignore-not-found)"

 if [[ "${hnc_enabled}" == "true" ]]; then
   echo "Hierarchy Controller is enabled on the ConfigManagement object. It must be disabled before migrating."
   echo "This can be done by unsetting the spec.hierarchyController field on ConfigManagement."
   exit 1
 fi

 kubectl delete deployment -n config-management-system config-management-operator --ignore-not-found --cascade=foreground

 if kubectl get configmanagement config-management &> /dev/null ; then
   kubectl patch configmanagement config-management --type="merge" -p '{"metadata":{"finalizers":[]}}'
   kubectl delete configmanagement config-management --cascade=orphan --ignore-not-found
 fi

 kubectl delete clusterrolebinding config-management-operator --ignore-not-found
 kubectl delete clusterrole config-management-operator --ignore-not-found
 kubectl delete serviceaccount -n config-management-system config-management-operator --ignore-not-found
 kubectl delete customresourcedefinition configmanagements.configmanagement.gke.io --ignore-not-found

Installa la nuova versione di Config Sync

Per eseguire l'upgrade di Config Sync, completa i seguenti passaggi per ogni cluster registrato:

1. Scarica il manifest di Config Sync e i comandi nomos per la nuova versione.

2. Estrai l'archivio:

   tar -xzvf config-sync.tar.gz

3. Nell'archivio che hai estratto nel passaggio precedente, segui le istruzioni nel file README.md fornito per modificare la kustomization.

4. Per aggiornare l'installazione di Config Sync, applica il manifest di cui è stato eseguito il rendering che hai creato seguendo le istruzioni di README.md:

   kubectl apply -f CONFIG_SYNC_MANIFEST
   

   Sostituisci CONFIG_SYNC_MANIFEST con il nome del manifest sottoposto a rendering.

5. Sostituisci il comando nomos su tutti i client con la nuova versione. Questa modifica garantisce che il comando nomos possa sempre ottenere lo stato di tutti i cluster registrati e convalidare le relative configurazioni.

Disinstalla Config Sync

Per disinstallare Config Sync, completa i seguenti passaggi:

1. Un amministratore centrale deve rimuovere il repository root:

   1. Se hai attivato il webhook e vuoi conservare le tue risorse, disattiva la prevenzione della deviazione per le risorse abbandonate. Se non hai attivato il webhook, non devi eseguire ulteriori passaggi per conservare le tue risorse.

   2. Elimina l'oggetto RootSync eseguendo questo comando:

      kubectl delete -f root-sync.yaml
      

2. Rimuovi eventuali repository.

3. Con i manifest che hai utilizzato per installare Config Sync, puoi anche disinstallare Config Sync.

      kubectl delete -f CONFIG_SYNC_MANIFEST --ignore-not-found
   

Passaggi successivi

• Scopri come configurare la sincronizzazione da più repository.