Installare Config Sync manualmente utilizzando kubectl (sconsigliato)

Questa pagina mostra come installare Config Sync utilizzando i comandi kubectl. L'operatore ConfigManagement è un controller che gestisce Config Sync in un cluster Kubernetes. Segui questi passaggi per installare e configurare l'operatore in ogni cluster che vuoi gestire utilizzando Config Sync.

Prima di iniziare

In questa sezione vengono descritti i prerequisiti da soddisfare prima di installare Config Sync utilizzando kubectl.

prepara l'ambiente locale

Prima di installare l'operatore, assicurati di aver preparato il tuo ambiente locale completando le seguenti attività:

  • Creare o avere accesso a una fonte attendibile.

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

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

    gcloud components install kubectl

  • Esegui l'autenticazione in Google Cloud utilizzando il comando gcloud auth login per scaricare i componenti di Config Sync.

prepara i cluster

Crea o accedi a un cluster della versione Google Kubernetes Engine (GKE) Enterprise che soddisfa i requisiti per Config Sync.

Prepara le autorizzazioni

L'utente Google Cloud che installa Config Sync ha bisogno 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: nome del cluster
  • USER_ACCOUNT: l'indirizzo email del tuo account Google Cloud

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

Se devi concedere all'operatore l'accesso a OCI utilizzando gcpserviceaccount come tipo di autenticazione, per creare un'associazione dei criteri devi avere anche l'autorizzazione iam.serviceAccounts.setIamPolicy. Puoi ottenere questa autorizzazione concedendo il ruolo IAM Amministratore account di servizio (roles/iam.serviceAccountAdmin). Potresti anche essere in grado di ottenere questa autorizzazione con i ruoli personalizzati o altri ruoli predefiniti.

Per ulteriori informazioni sulla concessione dei ruoli, consulta Gestione dell'accesso.

Registra un cluster

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

  1. Eseguire il deployment dell'operatore
  2. Concedi all'operatore l'accesso di sola lettura a uno dei seguenti elementi:
  3. Configura l'operatore

esegui il deployment dell'operatore

Dopo aver verificato che tutti i prerequisiti siano soddisfatti, puoi eseguire il deployment dell'operatore scaricando e applicando un manifest YAML.

  1. Scarica la versione più recente dei manifest dell'operatore utilizzando il comando seguente. Per scaricare una versione specifica, consulta la sezione Download.

    gsutil cp gs://config-management-release/released/latest/config-management-operator.yaml config-management-operator.yaml

  2. Applica i manifest:

    kubectl apply -f config-management-operator.yaml

Se l'operazione non riesce a causa di un problema con l'oggetto ConfigManagement non dovuto a un errore di sintassi YAML o JSON, è possibile che l'oggetto venga creata un'istanza nel cluster, ma potrebbe non funzionare correttamente. In questo caso, puoi usare 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
  • missing required syncRepo field
  • 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 ConfigManagement al cluster.

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

Concedi all'operatore l'accesso in sola lettura

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

Concedi all'operatore l'accesso di sola lettura a Git

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

Se il repository 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 puoi sfogliare il repository utilizzando un'interfaccia web senza effettuare l'accesso oppure se puoi utilizzare git clone per creare un clone del repository in locale senza fornire credenziali o utilizzare credenziali salvate, l'autenticazione non è necessaria. In questo caso, non è necessario creare un secret.

Tuttavia, la maggior parte degli utenti deve creare le credenziali poiché l'accesso in lettura al repository è limitato. Se sono necessarie le credenziali, vengono archiviate nel secret di git-creds in ogni cluster registrato (a meno che non utilizzi un account di servizio Google). Il nome del secret deve essere git-creds perché questo è un valore fisso.

Config Sync supporta i seguenti meccanismi per l'autenticazione:

  • Coppia di chiavi SSH (ssh)
  • File cookie (cookiefile)
  • Token (token)
  • Account di servizio Google (gcpserviceaccount)
  • Account di servizio predefinito di Compute Engine (gcenode)

Il meccanismo che scegli dipende da ciò che supporta il tuo repository. In genere, si consiglia di utilizzare una coppia di chiavi SSH. GitHub e Bitbucket supportano entrambi l'uso di una coppia di chiavi SSH. Tuttavia, se utilizzi un repository in Cloud Source Repositories, ti consigliamo di usare un account di servizio Google perché il processo è più semplice. Se la tua organizzazione ospita il 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 passaggi seguenti 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 console Google Cloud, aggiungi l'URL nel campo URL. Se configuri Config Sync utilizzando Google Cloud CLI, aggiungi l'URL al campo syncRepo del file di configurazione.

Coppia di chiavi SSH

Una coppia di chiavi SSH è composta da due file: una chiave pubblica e una chiave privata. In genere, la chiave pubblica ha un'estensione .pub.

Per utilizzare una coppia di chiavi SSH, segui questi passaggi:

  1. Creare una coppia di chiavi SSH per consentire a Config Sync di eseguire l'autenticazione nel repository Git. Questo passaggio è necessario se devi eseguire l'autenticazione nel repository per clonarlo o leggerlo. Salta questo passaggio se un amministratore di sicurezza ti fornisce una coppia di chiavi. Puoi utilizzare una singola coppia di chiavi per tutti i cluster o una coppia di chiavi per cluster, a seconda dei requisiti di sicurezza e conformità.

    Il seguente comando crea una chiave RSA a 4096 bit. I valori più bassi non sono consigliati:

    ssh-keygen -t rsa -b 4096 \
-C "GIT_REPOSITORY_USERNAME" \
-N '' \
-f /path/to/KEYPAIR_FILENAME

    Sostituisci quanto segue:

    • GIT_REPOSITORY_USERNAME: il nome utente che vuoi che Config Sync utilizzi per l'autenticazione nel repository
    • /path/to/KEYPAIR_FILENAME: un percorso della coppia di chiavi

    Se utilizzi un host di repository Git di terze parti, come GitHub, o vuoi utilizzare un account di servizio con Cloud Source Repositories, ti consigliamo di utilizzare un account separato.

  2. Configura il tuo repository in modo che riconosca la chiave pubblica appena creata. Consulta la documentazione del tuo provider host Git. Per praticità, sono incluse le istruzioni per alcuni noti provider di hosting Git:

  3. Aggiungi la chiave privata a un nuovo secret nel cluster:

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
 --namespace=config-management-system \
 --from-file=ssh=/path/to/KEYPAIR_PRIVATE_KEY_FILENAME

    Sostituisci /path/to/KEYPAIR_PRIVATE_KEY_FILENAME con il nome della chiave privata (quella senza il suffisso .pub).

  4. (Consigliato) Per configurare il controllo degli host noti utilizzando l'autenticazione SSH, puoi aggiungere la chiave host noti al campo data.known_hosts nel secret di git_creds. Per disattivare il controllo di known_hosts, puoi rimuovere il campo known_hosts dal secret. Per aggiungere la chiave host nota, esegui:

    kubectl edit secret git-creds \
 --namespace=config-management-system

    Quindi, in data, aggiungi la voce host noti:

    known_hosts: KNOWN_HOSTS_KEY

  5. Elimina la chiave privata dal disco locale oppure proteggila.

  6. Quando configuri Config Sync e aggiungi l'URL per il repository Git, utilizza il protocollo SSH. Se utilizzi un repository in Cloud Source Repositories, devi utilizzare il formato seguente quando inserisci l'URL:

    ssh://EMAIL@source.developers.google.com:2022/p/PROJECT_ID/r/REPO_NAME

    Sostituisci quanto segue:

    • EMAIL: il tuo nome utente Google Cloud
    • PROJECT_ID: l'ID del progetto Google Cloud in cui si trova il repository
    • REPO_NAME: il nome del repository

File dei cookie

Il processo per l'acquisizione di un cookiefile dipende dalla configurazione del repository. Per un esempio, consulta Generare credenziali statiche nella documentazione di Cloud Source Repositories. In genere le credenziali sono archiviate nel file .gitcookies della tua home directory oppure potrebbero essere fornite da un amministratore della sicurezza.

Per usare un cookiefile, completa i seguenti passaggi:

  1. Dopo aver creato e ottenuto cookiefile, aggiungilo a un nuovo secret nel cluster.

    Se non utilizzi un proxy HTTPS, crea il secret con il comando seguente:

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
 --namespace=config-management-system \
 --from-file=cookie_file=/path/to/COOKIEFILE

    Se devi utilizzare un proxy HTTPS, aggiungilo al secret insieme a cookiefile eseguendo questo comando:

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
 --namespace=config-management-system \
 --from-file=cookie_file=/path/to/COOKIEFILE \
 --from-literal=https_proxy=HTTPS_PROXY_URL

    Sostituisci quanto segue:

    • /path/to/COOKIEFILE: il percorso e il nome file appropriati
    • HTTPS_PROXY_URL: l'URL del proxy HTTPS che utilizzi per comunicare con il repository Git

  2. Proteggi i contenuti di cookiefile se ti serve ancora localmente. In caso contrario, eliminalo.

Token

Se la tua organizzazione non consente l'uso di chiavi SSH, potresti preferire l'utilizzo di un token. Con Config Sync, puoi utilizzare i token di accesso personale (PAT) di GitHub, i PAT o le chiavi di deployment di GiLab oppure la password dell'app di Bitbucket come token.

Per creare un secret utilizzando il tuo token, completa i seguenti passaggi:

  1. Crea un token utilizzando GitHub, GitLab o Bitbucket:

  2. Dopo aver creato e ottenuto il token, aggiungilo a un nuovo secret nel cluster.

    Se non utilizzi un proxy HTTPS, crea il secret con il comando seguente:

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
  --namespace="config-management-system" \
  --from-literal=username=USERNAME \
  --from-literal=token=TOKEN

    Sostituisci quanto segue:

    • USERNAME: il nome utente che vuoi utilizzare.
    • TOKEN: il token creato nel passaggio precedente.

    Se devi utilizzare un proxy HTTPS, aggiungilo al secret insieme a username e token eseguendo questo comando:

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
 --namespace=config-management-system \
 --from-literal=username=USERNAME \
  --from-literal=token=TOKEN \
 --from-literal=https_proxy=HTTPS_PROXY_URL

    Sostituisci quanto segue:

    • USERNAME: il nome utente che vuoi utilizzare.
    • TOKEN: il token creato nel passaggio precedente.
    • HTTPS_PROXY_URL: l'URL del proxy HTTPS che utilizzi per comunicare con il repository Git.

  3. Proteggi il token se ti occorre ancora a livello locale. In caso contrario, eliminalo.

Account di servizio Google

Se il repository si trova in Cloud Source Repositories e il cluster utilizza GKE Workload Identity o Workload Identity del parco risorse, puoi concedere a Config Sync l'accesso a un repository nello stesso progetto del tuo cluster gestito utilizzando un account di servizio Google.

  1. Se non hai ancora un account di servizio, creane uno.

  2. Concedi il ruolo IAM Lettore Cloud Source Repositories (roles/source.reader) all'account di servizio Google. Per ulteriori informazioni sui ruoli e sulle autorizzazioni di Cloud Source Repositories, consulta Concedere le autorizzazioni per visualizzare i repository.

    • Concedi l'autorizzazione a livello di progetto se le stesse autorizzazioni si applicano a tutti i repository nel progetto.

      gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/source.reader \
  --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"

    • Concedi un'autorizzazione specifica per il repository quando vuoi che gli account di servizio abbiano livelli di accesso diversi per ogni repository nel progetto.

      gcloud source repos set-iam-policy REPOSITORY POLICY_FILE --project=PROJECT_ID

  3. Se configuri Config Sync utilizzando la console Google Cloud, seleziona Workload Identity come Tipo di autenticazione, quindi aggiungi l'indirizzo email del tuo account di servizio.

    Se configuri Config Sync utilizzando Google Cloud CLI, aggiungi gcpserviceaccount come secretType, quindi aggiungi l'indirizzo email dell'account di servizio a gcpServiceAccountEmail.

  4. Dopo aver configurato Config Sync, crea un'associazione dei criteri IAM tra l'account di servizio Kubernetes e l'account di servizio Google. L'account di servizio Kubernetes non viene creato finché non configuri Config Sync per la prima volta.

    Se utilizzi cluster registrati in un parco risorse, devi creare l'associazione dei criteri solo una volta per parco risorse. Tutti i cluster registrati in un parco risorse condividono lo stesso Workload Identitypool. Con il concetto di identicità del parco risorse, se aggiungi il criterio IAM al tuo account di servizio Kubernetes in un cluster, anche l'account di servizio Kubernetes dello stesso spazio dei nomi su altri cluster nello stesso parco risorse riceve lo stesso criterio IAM.

    Questa associazione consente all'account di servizio Kubernetes di Config Sync di agire come account di servizio Google:

    gcloud iam service-accounts add-iam-policy-binding \
    GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/iam.workloadIdentityUser \
    --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
    --project=PROJECT_ID

Sostituisci quanto segue:

  • PROJECT_ID: l'ID progetto dell'organizzazione.
  • FLEET_HOST_PROJECT_ID: se utilizzi GKE Workload Identity, equivale a PROJECT_ID. Se utilizzi Workload Identity del parco risorse, questo è l'ID progetto del parco risorse in cui è registrato il cluster.
  • GSA_NAME: l'account di servizio Google personalizzato che vuoi utilizzare per la connessione ad Artifact Registry. L'account di servizio deve avere il ruolo IAM Lettore Artifact Registry (roles/artifactregistry.reader).
  • KSA_NAME: l'account di servizio Kubernetes per il riconciliatore.
    • Per i repository root, se il nome di RootSync è root-sync, utilizza root-reconciler. In caso contrario, usa root-reconciler-ROOT_SYNC_NAME. Se installi Config Sync utilizzando la console Google Cloud o Google Cloud CLI, Config Sync crea automaticamente un oggetto RootSync denominato root-sync.
  • REPOSITORY: il nome del repository.
  • POLICY_FILE: il file JSON o YAML con il criterio Identity and Access Management.

Account di servizio predefinito Compute Engine

Se il repository si trova in Cloud Source Repositories e il cluster è GKE su Google Cloud con Workload Identity disabilitato, puoi utilizzare gcenode come tipo di autenticazione.

Se configuri Config Sync utilizzando la console Google Cloud, seleziona Google Cloud Repository come Tipo di autenticazione.

Se configuri Config Sync utilizzando Google Cloud CLI, aggiungi gcenode come secretType.

Se selezioni Google Cloud Repository o gcenode, puoi utilizzare l'account di servizio predefinito di Compute Engine. Devi concedere il ruolo IAM Lettore Cloud Source Repositories (roles/source.reader) all'account di servizio predefinito di Compute Engine. Per ulteriori informazioni sui ruoli e sulle autorizzazioni di Cloud Source Repositories, consulta Concedere le autorizzazioni per visualizzare i repository.

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

Sostituisci PROJECT_ID con l'ID progetto della tua organizzazione e sostituisci PROJECT_NUMBER con il numero di progetto della tua organizzazione.

Concedi all'operatore l'accesso di sola lettura a OCI

Config Sync ha bisogno dell'accesso di sola lettura all'immagine OCI archiviata in Artifact Registry in modo che possa leggere le configurazioni incluse nell'immagine e applicarle ai tuoi 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 tutti su internet, non è necessario autenticarsi.

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

  • Account di servizio Kubernetes (k8sserviceaccount)
  • Account di servizio Google (gcpserviceaccount)

  • Account di servizio predefinito di Compute Engine (gcenode)

Account di servizio Kubernetes

Se archivi l'immagine OCI in Artifact Registry e il cluster utilizza GKE Workload Identity o Workload Identity del parco risorse, puoi usare k8sserviceaccount come tipo di autenticazione nella versione 1.17.2 e successive. Questa opzione è consigliata per gcpserviceaccount a causa della procedura di configurazione semplificata.

  1. Concedi il ruolo IAM Lettore Artifact Registry (roles/artifactregistry.reader) all'account di servizio Kubernetes con il pool Workload Identity. Per ulteriori informazioni sui ruoli e sulle autorizzazioni di Artifact Registry, consulta Configurare i ruoli e le autorizzazioni per Artifact Registry.

    • Concedi l'autorizzazione a livello di progetto se le stesse autorizzazioni si applicano a tutti i repository nel progetto.

      gcloud projects add-iam-policy-binding PROJECT_ID \
      --role=roles/artifactregistry.reader \
      --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"

    • Concedi un'autorizzazione specifica per il repository quando vuoi che gli account di servizio abbiano livelli di accesso diversi per ogni repository nel progetto.

      gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
   --project=PROJECT_ID

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID progetto dell'organizzazione.
    • FLEET_HOST_PROJECT_ID: se utilizzi GKE Workload Identity, equivale a PROJECT_ID. Se utilizzi Workload Identity del parco risorse, questo è l'ID progetto del parco risorse in cui è registrato il cluster.
    • KSA_NAME: l'account di servizio Kubernetes per il riconciliatore.
      • Per i repository root, se il nome di RootSync è root-sync, utilizza root-reconciler. In caso contrario, usa root-reconciler-ROOT_SYNC_NAME. Se installi Config Sync utilizzando la console Google Cloud o Google Cloud CLI, Config Sync crea automaticamente un oggetto RootSync denominato root-sync.
    • REPOSITORY: l'ID del repository.
    • LOCATION: la località a una o più regioni del repository.

Account di servizio Google

Se archivi l'immagine OCI in Artifact Registry e il cluster utilizza GKE Workload Identity o Workload Identity del parco risorse, puoi utilizzare gcpserviceaccount come tipo di autenticazione. A partire dalla versione 1.17.2, ti consigliamo di usare invece k8sserviceaccount. Questa opzione elimina i passaggi aggiuntivi per la creazione di un account di servizio Google e dell'associazione dei criteri IAM associata.

  1. Se non hai ancora un account di servizio, creane uno.

  2. Concedi il ruolo IAM Lettore Artifact Registry (roles/artifactregistry.reader) all'account di servizio Google. Per ulteriori informazioni sui ruoli e sulle autorizzazioni di Artifact Registry, consulta Configurare i ruoli e le autorizzazioni per Artifact Registry.

    • Concedi l'autorizzazione a livello di progetto se le stesse autorizzazioni si applicano a tutti i repository nel progetto.

      gcloud projects add-iam-policy-binding PROJECT_ID  \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"

    • Concedi un'autorizzazione specifica per il repository quando vuoi che gli account di servizio abbiano livelli di accesso diversi per ogni repository nel progetto.

      gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
   --project=PROJECT_ID

  3. Crea un'associazione dei criteri IAM tra l'account di servizio Kubernetes e l'account di servizio Google eseguendo questo comando:

    gcloud iam service-accounts add-iam-policy-binding
  GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/iam.workloadIdentityUser \
    --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
    --project=PROJECT_ID

Sostituisci quanto segue:

  • PROJECT_ID: l'ID progetto dell'organizzazione.
  • FLEET_HOST_PROJECT_ID: se utilizzi GKE Workload Identity, equivale a PROJECT_ID. Se utilizzi Workload Identity del parco risorse, questo è l'ID progetto del parco risorse in cui è registrato il cluster.
  • GSA_NAME: l'account di servizio Google personalizzato che vuoi utilizzare per la connessione ad Artifact Registry. L'account di servizio deve avere il ruolo IAM Lettore Artifact Registry (roles/artifactregistry.reader).
  • KSA_NAME: l'account di servizio Kubernetes per il riconciliatore.
    • Per i repository root, se il nome di RootSync è root-sync, utilizza root-reconciler. In caso contrario, usa root-reconciler-ROOT_SYNC_NAME. Se installi Config Sync utilizzando la console Google Cloud o Google Cloud CLI, Config Sync crea automaticamente un oggetto RootSync denominato root-sync.
  • REPOSITORY: l'ID del repository.
  • LOCATION: la località a una o più regioni del repository.

Account di servizio predefinito Compute Engine

Se archivi il grafico Helm in Artifact Registry e il tuo cluster è GKE su Google Cloud con Workload Identity disabilitato, puoi utilizzare gcenode come tipo di autenticazione. Config Sync utilizza l'account di servizio predefinito di Compute Engine. Devi concedere al tuo account di servizio predefinito Compute Engine l'accesso come lettore ad Artifact Registry.

  1. Concedi all'account di servizio Compute Engine l'autorizzazione di lettura ad Artifact Registry eseguendo questo comando:

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

    Sostituisci PROJECT_ID con l'ID progetto della tua organizzazione e sostituisci PROJECT_NUMBER con il numero di progetto della tua organizzazione.

Configurare l'operatore per un'autorità di certificazione

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

RootSync

  1. Recupera il certificato CA utilizzato per emettere il certificato per il tuo server Git e salvalo in un file.

  2. Per gli oggetti RootSync, il secret deve essere creato nello spazio dei nomi config-management-system. Ad esempio: 

    kubectl create ns config-management-system && 
    
kubectl create secret generic ROOT_CA_CERT_SECRET_NAME 
    
 --namespace=config-management-system 
    
 --from-file=cert=/path/to/CA_CERT_FILE

  3. Quando configuri l'operatore, imposta il valore del campo spec.git.caCertSecretRef.name nell'oggetto RootSync su ROOT_CA_CERT_SECRET_NAME.

RepoSync

  1. Recupera il certificato CA utilizzato per emettere il certificato per il tuo server Git e salvalo in un file.

  2. Per gli oggetti RepoSync, il secret deve essere creato nello stesso spazio dei nomi del RepoSync. Ad esempio: 

    kubectl create ns REPO_SYNC_NAMESPACE && 
    
kubectl create secret generic NAMESPACE_CA_CERT_SECRET_NAME 
    
 --namespace=REPO_SYNC_NAMESPACE 
    
 --from-file=cert=/path/to/CA_CERT_FILE

  3. Quando configuri RepoSync, imposta il valore del campo spec.git.caCertSecretRef.name nell'oggetto RepoSync su NAMESPACE_CA_CERT_SECRET_NAME.

Concedi all'operatore l'accesso di sola lettura a Helm

Config Sync richiede l'accesso di sola lettura al repository Helm in modo che possa leggere i grafici Helm nel repository e installarli nei cluster.

Se il repository 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 il repository Helm è pubblico e accessibile a chiunque su internet, 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 per l'autenticazione:

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

Token

Crea un secret con nome utente e password del repository Helm:

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

Sostituisci quanto segue:

  • SECRET_NAME: il nome che vuoi assegnare al tuo secret.
  • USERNAME: il nome utente del repository Helm.
  • PASSWORD: la password del repository Helm.

Quando configuri l'operatore ConfigManagement, utilizzerai il nome del secret che hai scelto per spec.helm.secretRef.name.

Account di servizio Kubernetes

Se archivi il grafico Helm in Artifact Registry e il cluster utilizza GKE Workload Identity o Workload Identity del parco risorse, puoi utilizzare k8sserviceaccount come tipo di autenticazione nella versione 1.17.2 e successive. Questa opzione è consigliata per gcpserviceaccount a causa della procedura di configurazione semplificata.

  1. Concedi il ruolo IAM Lettore Artifact Registry (roles/artifactregistry.reader) all'account di servizio Kubernetes con il pool Workload Identity. Per ulteriori informazioni sui ruoli e sulle autorizzazioni di Artifact Registry, consulta Configurare i ruoli e le autorizzazioni per Artifact Registry.

    • Concedi l'autorizzazione a livello di progetto se le stesse autorizzazioni si applicano a tutti i repository nel progetto.

      gcloud projects add-iam-policy-binding PROJECT_ID \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"

    • Concedi un'autorizzazione specifica per il repository quando vuoi che gli account di servizio abbiano livelli di accesso diversi per ogni repository nel progetto.

      gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
   --project=PROJECT_ID

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID progetto dell'organizzazione.
    • FLEET_HOST_PROJECT_ID: se utilizzi GKE Workload Identity, equivale a PROJECT_ID. Se utilizzi Workload Identity del parco risorse, questo è l'ID progetto del parco risorse in cui è registrato il cluster.
    • KSA_NAME: l'account di servizio Kubernetes per il riconciliatore.
      • Per i repository root, se il nome di RootSync è root-sync, utilizza root-reconciler. In caso contrario, usa root-reconciler-ROOT_SYNC_NAME.
    • REPOSITORY: l'ID del repository.
    • LOCATION: la località a una o più regioni del repository.

Account di servizio Google

Se archivi il grafico Helm in Artifact Registry e il cluster utilizza GKE Workload Identity o Workload Identity del parco risorse, puoi utilizzare gcpserviceaccount come tipo di autenticazione. A partire dalla versione 1.17.2, ti consigliamo di usare invece k8sserviceaccount. Questa opzione elimina i passaggi aggiuntivi per la creazione di un account di servizio Google e dell'associazione dei criteri IAM associata.

  1. Se non hai ancora un account di servizio, creane uno.

  2. Concedi il ruolo IAM Lettore Artifact Registry (roles/artifactregistry.reader) all'account di servizio Google. Per ulteriori informazioni sui ruoli e sulle autorizzazioni di Artifact Registry, consulta Configurare i ruoli e le autorizzazioni per Artifact Registry.

    • Concedi l'autorizzazione a livello di progetto se le stesse autorizzazioni si applicano a tutti i repository nel progetto.

      gcloud projects add-iam-policy-binding PROJECT_ID  \
      --role=roles/artifactregistry.reader \
      --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"

    • Concedi un'autorizzazione specifica per il repository quando vuoi che gli account di servizio abbiano livelli di accesso diversi per ogni repository nel progetto.

      gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
   --project=PROJECT_ID

  3. Crea un'associazione dei criteri IAM tra l'account di servizio Kubernetes e l'account di servizio Google eseguendo questo comando:

    gcloud iam service-accounts add-iam-policy-binding
  GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/iam.workloadIdentityUser \
    --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
    --project=PROJECT_ID

Sostituisci quanto segue:

  • PROJECT_ID: l'ID progetto dell'organizzazione.
  • FLEET_HOST_PROJECT_ID: se utilizzi GKE Workload Identity, equivale a PROJECT_ID. Se utilizzi Workload Identity del parco risorse, questo è l'ID progetto del parco risorse in cui è registrato il cluster.
  • GSA_NAME: l'account di servizio Google personalizzato che vuoi utilizzare per la connessione ad Artifact Registry. L'account di servizio deve avere il ruolo IAM Lettore Artifact Registry (roles/artifactregistry.reader).
  • KSA_NAME: l'account di servizio Kubernetes per il riconciliatore.
    • Per i repository root, se il nome di RootSync è root-sync, utilizza root-reconciler. In caso contrario, usa root-reconciler-ROOT_SYNC_NAME.
  • REPOSITORY: l'ID del repository.
  • LOCATION: la località a una o più regioni del repository.

Account di servizio predefinito Compute Engine

Se archivi il grafico Helm in Artifact Registry e il tuo cluster è GKE su Google Cloud con Workload Identity disabilitato, puoi utilizzare gcenode come tipo di autenticazione. Config Sync utilizza l'account di servizio predefinito di Compute Engine. Devi concedere al tuo account di servizio predefinito Compute Engine l'accesso come lettore ad Artifact Registry. Potresti dover concedere l'ambito di accesso storage-ro per concedere l'autorizzazione di sola lettura al pull delle immagini.

  1. Concedi l'autorizzazione di lettura all'account di servizio Compute Engine ad Artifact Registry:

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

    Sostituisci PROJECT_ID con l'ID progetto della tua organizzazione e sostituisci PROJECT_NUMBER con il numero di progetto della tua organizzazione.

Configura l'operatore

Per configurare la sincronizzazione dal repository principale, devi abilitare la modalità multi-repo nell'oggetto ConfigManagement e creare un oggetto RootSync che sincronizzi il repository principale con il cluster. Puoi creare un solo repository radice per cluster e il repository radice può essere un repository non strutturato o un repository.

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

  2. Crea un file denominato config-management.yaml e copia al suo interno il seguente file YAML:

    # config-management.yaml
apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  # The `enableMultiRepo` field is set to true to enable RootSync and RepoSync APIs.
  enableMultiRepo: true
  preventDrift: PREVENT_DRIFT

    Sostituisci quanto segue:

    • PREVENT_DRIFT: se impostato su true, consente al webhook di ammissione Config Sync di prevenire le deviazioni rifiutando il push delle modifiche in conflitto ai cluster attivi. L'impostazione predefinita è false. Config Sync risolve sempre le deviazioni indipendentemente dal valore di questo campo.

  3. Applica le modifiche:

    kubectl apply -f config-management.yaml

  4. 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

  5. Salva uno dei seguenti manifest come root-sync.yaml. Utilizza la versione del manifest corrispondente al tipo di origine per le 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: ROOT_FORMAT
  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_FORMAT: aggiungi unstructured per utilizzare un repository non strutturato o aggiungi hierarchy per utilizzare un repository gerarchico. Questi valori sono sensibili alle maiuscole. Questo campo è facoltativo e il valore predefinito è hierarchy. Ti consigliamo di aggiungere unstructured poiché questo formato ti consente di organizzare le configurazioni nel modo più comodo per te.
    • ROOT_REPOSITORY: aggiungi l'URL del repository Git da utilizzare come repository principale. 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) da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è HEAD. A partire da Config Sync versione 1.17.0, puoi anche specificare un nome ramo nel campo revision. Quando utilizzi un hash nella versione 1.17.0 o successive, deve essere un hash completo e non una forma abbreviata.
    • ROOT_BRANCH: aggiungi il ramo del repository da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è master. A partire da Config Sync versione 1.17.0, consigliamo di utilizzare il campo revision per specificare un nome ramo per semplicità. Se sono specificati sia il campo revision che il campo branch, revision ha la precedenza su branch.
    • ROOT_DIRECTORY: aggiungi il percorso del repository Git alla directory radice contenente la configurazione da sincronizzare. Questo campo è facoltativo e il valore predefinito è la directory root (/) del repository.

    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

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

      Per maggiori informazioni su questi tipi di autenticazione, consulta Concedere a Config Sync l'accesso di sola lettura a Git.

      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.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 disabilitare 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 viene 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 Configurare l'operatore per un'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: ROOT_FORMAT
  oci:
    image: ROOT_IMAGE
    dir: ROOT_DIRECTORY
    auth: ROOT_AUTH_TYPE
    gcpServiceAccountEmail: ROOT_EMAIL

    Sostituisci quanto segue:

    • ROOT_SYNC_NAME: aggiungi il nome dell'oggetto RootSync.
    • ROOT_FORMAT: aggiungi unstructured per utilizzare un repository non strutturato o aggiungi hierarchy per utilizzare un repository gerarchico. Questi valori sono sensibili alle maiuscole. Questo campo è facoltativo e il valore predefinito è hierarchy. Ti consigliamo di aggiungere unstructured poiché questo formato ti consente di organizzare le configurazioni nel modo più comodo per te.
    • ROOT_IMAGE: l'URL dell'immagine OCI da utilizzare come repository principale, 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 in base a TAG o DIGEST. Specifica TAG o DIGEST in PACKAGE_NAME:
      • Per eseguire il pull in base a TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
      • Per eseguire il pull in base a DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
    • ROOT_DIRECTORY: aggiungi il percorso del repository alla directory radice contenente la configurazione da sincronizzare. Questo campo è facoltativo e il valore predefinito è la directory root (/) del repository.

    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: nessuna autenticazione
      • gcenode: utilizza l'account di servizio predefinito di Compute Engine per accedere a un'immagine in Artifact Registry. Seleziona questa opzione solo se Workload Identity 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.iam.gserviceaccount.com.

    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: ROOT_FORMAT
  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

    Sostituisci quanto segue:

    • ROOT_SYNC_NAME: aggiungi il nome dell'oggetto RootSync.
    • ROOT_FORMAT: aggiungi unstructured per utilizzare un repository non strutturato o aggiungi hierarchy per utilizzare un repository gerarchico. Questi valori sono sensibili alle maiuscole. Questo campo è facoltativo e il valore predefinito è hierarchy. Ti consigliamo di aggiungere unstructured poiché questo formato ti consente di organizzare le configurazioni nel modo più comodo per te.
    • ROOT_HELM_REPOSITORY: l'URL del repository Helm da utilizzare come repository principale. 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 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 target per una release. Imposta uno spazio dei nomi solo per le risorse che contengono namespace: {{ .Release.Namespace }} nei modelli. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzato lo spazio dei nomi predefinito config-management-system.
    • HELM_INCLUDE_CRDS: impostalo su true se vuoi che il modello Helm generi anche una CustomResourceDefinition. Questo campo è facoltativo. Se non viene specificato alcun valore, il valore predefinito è false e non verrà generato un CRD.
    • VALUE: valori da utilizzare al posto dei valori predefiniti che accompagnano il grafico Helm. Formatta questo campo come nel file helm chart's values.yaml. Questo campo è facoltativo.

    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: nessuna autenticazione
      • token: utilizza un nome utente e una password per accedere a un repository Helm privato.
      • gcenode: utilizza l'account di servizio predefinito di Compute Engine per accedere a un'immagine in Artifact Registry. Seleziona questa opzione solo se Workload Identity 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.iam.gserviceaccount.com.

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

    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.

  6. Applica le modifiche:

    kubectl apply -f root-sync.yaml

Verifica lo stato di sincronizzazione del repository principale

Puoi utilizzare il comando nomos status per esaminare lo stato di sincronizzazione del repository principale:

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 riconciliatore con il prefisso root-reconciler. Un riconciliatore è 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 del riconciliazione root:

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 radice, puoi facoltativamente scegliere di configurare la sincronizzazione da più repository. Questi repository sono utili se vuoi che un repository che contenga configurazioni basate sullo spazio dei nomi venga sincronizzato con un determinato spazio dei nomi nei vari cluster.

Esegui l'upgrade di Config Sync

Per eseguire l'upgrade di Config Sync, esegui questi comandi per ciascun cluster registrato:

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

  2. Applica il manifest di Config Sync:

    kubectl apply -f config-management-operator.yaml

    Questo comando aggiorna l'immagine dell'operatore ConfigManagement. Kubernetes recupera la nuova versione e riavvia il pod Config Sync utilizzando la nuova versione. All'avvio di Config Sync, viene eseguito un loop di riconciliazione che applica l'insieme di manifest raggruppati nella nuova immagine. Questa operazione aggiorna e riavvia ogni pod di componente.

  3. 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 possa convalidare le relative configurazioni.

Disinstallazione di Config Sync

Per disinstallare Config Sync, completa i seguenti passaggi:

  1. Un amministratore centrale deve rimuovere il repository principale:

    1. Annulla la gestione o elimina le risorse gestite dall'oggetto RootSync seguendo le istruzioni per la risoluzione dei problemi.

    2. Elimina l'oggetto RootSync eseguendo questo comando:

      kubectl delete -f root-sync.yaml

  2. Rimuovi tutti i repository.

  3. Rimuovi il campo spec.enableMultiRepo dal file config-management.yaml.

  4. Applica il tuo file config-management.yaml al cluster.

Se vuoi disinstallare completamente Config Sync, consulta Rimozione dell'operatore ConfigManagement.

Passaggi successivi