Installa manualmente Config Sync utilizzando kubectl (non consigliato)

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

Prima di iniziare

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

Prepara l'ambiente locale

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

  • Creare o avere accesso a una fonte attendibile.

  • Installa e inizializza Google Cloud CLI, che fornisce il comando Comandi gcloud, gsutil, kubectl e nomos utilizzati in queste istruzioni. Se utilizzi Cloud Shell, Google Cloud CLI è preinstallato.

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

    gcloud components install kubectl

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

Prepara i cluster

Creare o avere accesso a un cluster della versione Google Kubernetes Engine (GKE) Enterprise che soddisfi questo requisito i requisiti per Config Sync.

Prepara le autorizzazioni

L'utente di Google Cloud che installa Config Sync ha bisogno delle autorizzazioni IAM per creare nuovi ruoli nel tuo cluster. Se necessario, concedi questi ruoli con quanto segue :

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 cluster
  • USER_ACCOUNT: l'indirizzo email del tuo account Google Cloud indirizzo

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 usando gcpserviceaccount come tipo di autenticazione per creare un criterio è necessario disporre anche dell'autorizzazione iam.serviceAccounts.setIamPolicy. Puoi ottenere questa autorizzazione concedendo all'Amministratore account di servizio (roles/iam.serviceAccountAdmin) Ruolo IAM. Potresti anche riuscire a: per ottenere questa autorizzazione con i ruoli personalizzati oppure e altri ruoli predefiniti.

Per ulteriori informazioni sulla concessione dei ruoli, consulta Gestisci accesso.

Registra un cluster

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

  1. 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 per il deployment dell'operatore scaricando e applicando un manifest YAML.

  1. Scarica la versione più recente dei manifest dell'operatore utilizzando il . Per scaricare una versione specifica, consulta 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 che non è A causa di un errore di sintassi YAML o JSON, è possibile che venga creata un'istanza nel ma potrebbe non funzionare correttamente. In questo caso, puoi utilizzare il comando nomos status per verificare la presenza di errori nell'oggetto.

Lo stato di un'installazione valida senza problemi è PENDING o SYNCED.

Un'installazione non valida presenta lo stato NOT CONFIGURED ed elenca uno dei i 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. In base al tipo di potresti dover applicare di nuovo 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. applicare di nuovo la configurazione.

Concedi all'operatore l'accesso in sola lettura

Se archivi le tue configurazioni in Git, devi concedere all'operatore l'accesso di sola lettura a Git. Se archivi le configurazioni come Immagini OCI, devi concedere alla classe Accesso di sola lettura dell'operatore a OCI. Se archivi le tue 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 ha bisogno dell'accesso di sola lettura al tuo repository Git può leggere le configurazioni impegnate nel repository e applicarle cluster.

Se il repository non richiede l'autenticazione per l'accesso di sola lettura, puoi: continua con la configurazione di Config Sync usa none come tipo di autenticazione. Ad esempio, puoi sfogliare utilizzando un'interfaccia web senza dover effettuare l'accesso oppure puoi usare git clone per creare un clone del repository in locale senza fornire le credenziali o utilizzando credenziali salvate, non devi autenticarti. In questo caso, non devi creare un secret.

Tuttavia, la maggior parte degli utenti deve creare credenziali perché l'accesso in lettura ai propri con restrizioni. Se sono necessarie le credenziali, queste vengono archiviate nella git-creds secret su ogni cluster registrato (a meno che non utilizzi un (account di servizio). Il secret deve essere denominato git-creds perché si tratta di un valore fisso.

Config Sync supporta i seguenti meccanismi per l'autenticazione:

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

Il meccanismo scelto dipende da ciò che è supportato dal tuo repository. In genere, consigliamo di utilizzare una coppia di chiavi SSH. GitHub e Bitbucket entrambi per il supporto tramite coppia di chiavi SSH. Tuttavia, se utilizzi un repository Cloud Source Repositories, ti consigliamo di usare un account di servizio Google poiché il processo è più semplice. Se la tua organizzazione ospita il tuo repository e non sai quali sono i metodi di autenticazione supportati, contatta il tuo amministratore.

Per usare un repository in Cloud Source Repositories come repository di 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 dal 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 configurare Config Sync sezione successiva. Se configuri Config Sync utilizzando Console Google Cloud, aggiungi l'URL nel campo URL. Se configurare 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. La la chiave pubblica in genere ha un'estensione .pub.

Per utilizzare una coppia di chiavi SSH, completa i seguenti passaggi:

  1. Crea una coppia di chiavi SSH per consentire a Config Sync di eseguire l'autenticazione su nel tuo repository Git. Questo passaggio è necessario se devi autenticarti il repository per clonarlo o leggerlo. Salta questo passaggio se un sistema di sicurezza ti fornisce una coppia di chiavi. Puoi usare una singola coppia di chiavi per tutti i cluster o una coppia di chiavi per cluster, a seconda i tuoi requisiti di sicurezza e conformità.

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

    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 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 usare un account di servizio con Cloud Source Repositories, consigliamo di usare un account separato.

  2. Configura il tuo repository in modo che riconosca la chiave pubblica appena creata. Fai riferimento alla documentazione del tuo provider host Git. Istruzioni per Alcuni provider host Git popolari sono inclusi per praticità:

  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 conosciuti mediante l'autenticazione SSH: puoi aggiungere la chiave host noti al campo data.known_hosts nella git_creds secret. Per disattivare il controllo di known_hosts, puoi rimuovere il componente Campo known_hosts del secret. Per aggiungere la chiave host nota, esegui:

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

    Poi, in data, aggiungi la voce hosts:

    known_hosts: KNOWN_HOSTS_KEY

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

  6. Quando configuri Config Sync e aggiungi l'URL del tuo repository Git, utilizza il protocollo SSH. Se utilizzi un in Cloud Source Repositories, devi usare 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 di Google Cloud progetto in cui si trova il repository
    • REPO_NAME: il nome del repository

File dei cookie

La procedura per acquisire un cookiefile dipende dalla configurazione del tuo repository Git. Per un esempio, vedi Genera credenziali statiche nella documentazione di Cloud Source Repositories. In genere le credenziali vengono memorizzate nel file .gitcookies di casa tua o potrebbero esserti 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 in nel cluster.

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

    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 tipo appropriato percorso e nome file
    • HTTPS_PROXY_URL: l'URL del proxy HTTPS che hai da usare per comunicare con il repository Git

  2. Proteggi i contenuti di cookiefile se ti occorre ancora a livello locale. In caso contrario, eliminalo.

Token

Se la tua organizzazione non consente l'uso di chiavi SSH, potresti preferire utilizzare un token. Con Config Sync, puoi utilizzare i token di accesso personale di GitHub (PAT), i PAT di GiLab o le chiavi di deployment o la password per l'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 seguente 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

    Sostituisci quanto segue:

    • USERNAME: il nome utente che vuoi utilizzare.
    • TOKEN: il token che hai 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 che hai creato nel passaggio precedente.
    • HTTPS_PROXY_URL: l'URL del proxy HTTPS che hai durante la comunicazione con il repository Git.

  3. Proteggi il token se ti occorre ancora a livello locale. Altrimenti, eliminarlo.

Account di servizio Google

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

  1. Se non hai ancora un account di servizio, crea un account di servizio.

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

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

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

    • Concedi l'autorizzazione specifica del repository quando vuoi che gli account di servizio avere diversi livelli di accesso per ogni repository nel tuo 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 (Identità carico di lavoro) come Authentication Type (Tipo di autenticazione), quindi aggiungi il tuo l'indirizzo email dell'account di servizio.

    Se configuri Config Sync utilizzando Google Cloud CLI, aggiungi gcpserviceaccount come secretType e aggiungi il tuo servizio email dell'account a gcpServiceAccountEmail.

  4. Dopo aver configurato Config Sync, crea un'istanza Associazione dei criteri IAM tra l'account di servizio Kubernetes e l'account di servizio Google. La 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 una volta per ogni parco risorse. Tutti i cluster registrati in un parco risorse condividono lo stesso pool di identità per carichi di lavoro. Con il concetto di flotta identicità, se aggiungi il criterio IAM all'account di servizio Kubernetes in uno cluster, quindi l'account di servizio Kubernetes dello stesso spazio dei nomi anche altri cluster nello stesso parco risorse ricevono lo stesso .

    Questa associazione consente all'account di servizio Kubernetes di Config Sync fungere da 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: ID progetto dell'organizzazione.
  • FLEET_HOST_PROJECT_ID: se utilizzi GKE Workload Identity, uguale a PROJECT_ID. Se utilizzi un parco risorse Workload Identity, si tratta dell'ID progetto del parco risorse che il tuo in cui è registrato un cluster.
  • GSA_NAME: l'account di servizio Google personalizzato che vuoi utilizzare per connetterti ad Artifact Registry. L'account di servizio deve avere il ruolo IAM Artifact Registry Reader (roles/artifactregistry.reader).
  • KSA_NAME: l'account di servizio Kubernetes per riconciliatore.
    • Per i repository root, se il nome RootSync è root-sync, usa root-reconciler. Altrimenti, 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 Identity and Access Management.

Account di servizio predefinito Compute Engine

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

Se configuri Config Sync utilizzando la console Google Cloud, seleziona Google Cloud Repository nel campo Authentication Type (Tipo di autenticazione).

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

La selezione di Google Cloud Repository o gcenode consente di utilizzare Account di servizio predefinito Compute Engine. Devi concedere ai Ruolo IAM Lettore Cloud Source Repositories (roles/source.reader) all'account di servizio predefinito di Compute Engine. Per ulteriori informazioni i ruoli e le autorizzazioni di Cloud Source Repositories, consulta Concedi 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 progetto della tua organizzazione numero.

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

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

Se l'immagine non richiede l'autenticazione per l'accesso di sola lettura, puoi continua con configura Config Sync e utilizza none come tipo di autenticazione. Ad esempio, se l'immagine è pubblica e sono accessibili a chiunque su internet, senza bisogno di autenticarsi.

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

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

  • Account di servizio predefinito Compute Engine (gcenode)

Account di servizio Kubernetes

Se archivi l'immagine OCI in Artifact Registry e il cluster utilizza GKE Workload Identity o del parco risorse Workload Identity, puoi utilizzare k8sserviceaccount come tipo di autenticazione nella versione 1.17.2 e successivi. Questa opzione è consigliata per più di gcpserviceaccount a causa dei suoi un processo di configurazione semplificato.

  1. Concedi al lettore Artifact Registry (roles/artifactregistry.reader) ruolo IAM all'account di servizio Kubernetes con Pool Workload Identity. Per ulteriori informazioni informazioni su ruoli e autorizzazioni di Artifact Registry, consulta Configura ruoli e autorizzazioni per Artifact Registry.

    • Concedi l'autorizzazione a livello di progetto se le stesse autorizzazioni si applicano a tutti repository di codice sorgente 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 l'autorizzazione specifica del repository quando vuoi che gli account di servizio avere diversi livelli di accesso per ogni repository nel tuo 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: ID progetto dell'organizzazione.
    • FLEET_HOST_PROJECT_ID: se utilizzi GKE Workload Identity, uguale a PROJECT_ID. Se utilizzi un parco risorse Workload Identity, si tratta dell'ID progetto del parco risorse che il tuo in cui è registrato un cluster.
    • KSA_NAME: l'account di servizio Kubernetes per riconciliatore.
      • Per i repository root, se il nome RootSync è root-sync, usa root-reconciler. Altrimenti, 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: a livello di 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 del parco risorse Workload Identity, puoi usare gcpserviceaccount come tipo di autenticazione. A partire da versione 1.17.2, ti consigliamo di usare invece k8sserviceaccount. Questo elimina i passaggi aggiuntivi della creazione di un account di servizio Google e l'associazione dei criteri IAM associata.

  1. Se non hai ancora un account di servizio, crea un account di servizio.

  2. Concedi al lettore Artifact Registry (roles/artifactregistry.reader) ruolo IAM all'account di servizio Google. Per ulteriori informazioni informazioni su ruoli e autorizzazioni di Artifact Registry, consulta Configura ruoli e autorizzazioni per Artifact Registry.

    • Concedi l'autorizzazione a livello di progetto se le stesse autorizzazioni si applicano a tutti repository di codice sorgente all'interno del progetto.

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

    • Concedi l'autorizzazione specifica del repository quando vuoi che gli account di servizio avere diversi livelli di accesso per ogni repository nel tuo 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 esegui 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: ID progetto dell'organizzazione.
  • FLEET_HOST_PROJECT_ID: se utilizzi GKE Workload Identity, uguale a PROJECT_ID. Se utilizzi un parco risorse Workload Identity, si tratta dell'ID progetto del parco risorse che il tuo in cui è registrato un cluster.
  • GSA_NAME: l'account di servizio Google personalizzato che vuoi utilizzare per connetterti ad Artifact Registry. L'account di servizio deve avere il ruolo IAM Artifact Registry Reader (roles/artifactregistry.reader).
  • KSA_NAME: l'account di servizio Kubernetes per riconciliatore.
    • Per i repository root, se il nome RootSync è root-sync, usa root-reconciler. Altrimenti, 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: a livello di 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 con Workload Identity disabilitato, puoi usare gcenode come di autenticazione. Config Sync utilizza l'account di servizio predefinito di Compute Engine. Devi concedere il tuo account di servizio predefinito Compute Engine con accesso in lettura ad Artifact Registry.

  1. Concedi l'autorizzazione di lettura all'account di servizio Compute Engine per Artifact Registry mediante l'esecuzione del comando seguente:

    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 del progetto.

Configura l'operatore per un'autorità di certificazione

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

RootSync

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

  2. Per gli oggetti RootSync, il secret deve essere creato in config-management-system nello spazio dei nomi. 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 Operator, imposta il valore del campo caCertSecretRef.name in RootSync oggetto in ROOT_CA_CERT_SECRET_NAME.

RepoSync

  1. Recupera il certificato CA utilizzato per emettere il certificato per il tuo server Git e lo salvi 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 caCertSecretRef.name nel modulo RepoSync oggetto in NAMESPACE_CA_CERT_SECRET_NAME.

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

Config Sync ha bisogno dell'accesso di sola lettura al tuo repository Helm per poter leggere i grafici Helm nel tuo repository e installarli nei tuoi cluster.

Se il repository non richiede l'autenticazione per l'accesso di sola lettura, puoi: continua con configura Config Sync e utilizza none come tipo di autenticazione. Ad esempio, se il tuo repository Helm è pubblico ed è accessibile a tutti su internet, quindi non occorre autenticarsi.

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 Compute Engine (gcenode)

Token

Crea un secret con un nome utente e una password di un 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 del parco risorse Workload Identity, puoi utilizzare k8sserviceaccount come tipo di autenticazione nella versione 1.17.2 e successivi. Questa opzione è consigliata per più di gcpserviceaccount a causa dei suoi un processo di configurazione semplificato.

  1. Concedi al lettore Artifact Registry (roles/artifactregistry.reader) ruolo IAM all'account di servizio Kubernetes con Pool Workload Identity. Per ulteriori informazioni informazioni su ruoli e autorizzazioni di Artifact Registry, consulta Configura ruoli e autorizzazioni per Artifact Registry.

    • Concedi l'autorizzazione a livello di progetto se le stesse autorizzazioni si applicano a tutti repository di codice sorgente 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 l'autorizzazione specifica del repository quando vuoi che gli account di servizio avere diversi livelli di accesso per ogni repository nel tuo 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: ID progetto dell'organizzazione.
    • FLEET_HOST_PROJECT_ID: se utilizzi GKE Workload Identity, uguale a PROJECT_ID. Se utilizzi un parco risorse Workload Identity, si tratta dell'ID progetto del parco risorse che il tuo in cui è registrato un cluster.
    • KSA_NAME: l'account di servizio Kubernetes per riconciliatore.
      • Per i repository root, se il nome RootSync è root-sync, usa root-reconciler. Altrimenti, usa root-reconciler-ROOT_SYNC_NAME.
    • REPOSITORY: l'ID del repository.
    • LOCATION: a livello di 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 del parco risorse Workload Identity, puoi usare gcpserviceaccount come tipo di autenticazione. A partire da versione 1.17.2, ti consigliamo di usare invece k8sserviceaccount. Questo elimina i passaggi aggiuntivi della creazione di un account di servizio Google e l'associazione dei criteri IAM associata.

  1. Se non hai ancora un account di servizio, crea un account di servizio.

  2. Concedi al lettore Artifact Registry (roles/artifactregistry.reader) ruolo IAM all'account di servizio Google. Per ulteriori informazioni informazioni su ruoli e autorizzazioni di Artifact Registry, consulta Configura ruoli e autorizzazioni per Artifact Registry.

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

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

    • Concedi l'autorizzazione specifica del repository quando vuoi che gli account di servizio avere diversi livelli di accesso per ogni repository nel tuo 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 esegui 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: ID progetto dell'organizzazione.
  • FLEET_HOST_PROJECT_ID: se utilizzi GKE Workload Identity, uguale a PROJECT_ID. Se utilizzi un parco risorse Workload Identity, si tratta dell'ID progetto del parco risorse che il tuo in cui è registrato un cluster.
  • GSA_NAME: l'account di servizio Google personalizzato che vuoi utilizzare per connetterti ad Artifact Registry. L'account di servizio deve avere il ruolo IAM Artifact Registry Reader (roles/artifactregistry.reader).
  • KSA_NAME: l'account di servizio Kubernetes per riconciliatore.
    • Per i repository root, se il nome RootSync è root-sync, usa root-reconciler. Altrimenti, usa root-reconciler-ROOT_SYNC_NAME.
  • REPOSITORY: l'ID del repository.
  • LOCATION: a livello di 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 con Workload Identity disabilitato, puoi usare gcenode come di autenticazione. Config Sync utilizza l'account di servizio predefinito di Compute Engine. Devi concedere il tuo account di servizio predefinito Compute Engine con accesso in lettura ad Artifact Registry. Potresti dover concedere all'accesso storage-ro ambito per concedere le autorizzazioni di sola lettura per eseguire il pull delle immagini.

  1. Concedi l'autorizzazione di lettura all'account di servizio Compute Engine per 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 del progetto.

Configura l'operatore

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

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

  2. Crea un file denominato config-management.yaml e copia quanto segue 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, attiva il webhook di ammissione Config Sync per prevenire le deviazioni rifiutando le modifiche in conflitto dal push ai cluster attivi. L'impostazione predefinita è false. Config Sync corregge sempre le deviazioni il valore di questo campo.

  3. Applica le modifiche:

    kubectl apply -f config-management.yaml

  4. Attendi che i 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. Utilizzare il file manifest che corrisponde 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: 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 del tuo sistema 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 consente puoi organizzare le configurazioni nel modo che preferisci.
    • ROOT_REPOSITORY: aggiungi l'URL del repository Git a da usare come repository radice. Puoi inserire gli URL utilizzando il protocollo HTTPS HTTP(S) 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 specifica un nome ramo nel campo revision. Quando si utilizza un hash in versione 1.17.0 o successiva, deve essere un hash completo e non un abbreviata.
    • ROOT_BRANCH: aggiungi il ramo di il repository da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è master. A partire da Config Sync versione 1.17.0, ti consigliamo di utilizzare il campo revision per specificare un nome ramo la semplicità. Se il campo revision e il campo branch sono entrambi specificato, revision ha la precedenza su branch.
    • ROOT_DIRECTORY: aggiungi il percorso nel repository Git a la directory principale che contiene la configurazione da sincronizzare a. Questo campo è facoltativo e il valore predefinito è la directory radice (/) di nel repository.

    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

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

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

      Questo campo è obbligatorio.

    • ROOT_EMAIL: se hai aggiunto gcpserviceaccount come tuo 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 questo , devi aggiungere la chiave pubblica del secret il 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'istanza certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominata cert. Questo campo è facoltativo.

      Per saperne di più su come configurare l'oggetto Secret per la CA vedi Configurare l'operatore per un'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo dei campi che che è possibile aggiungere al campo spec, consulta la sezione 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
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME

    Sostituisci quanto segue:

    • ROOT_SYNC_NAME: aggiungi il nome del tuo sistema 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 consente puoi organizzare le configurazioni nel modo che preferisci.
    • 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 recuperare le immagini in base a TAG o DIGEST. Specifica TAG o DIGEST in PACKAGE_NAME:
      • Per eseguire il pull per TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
      • Per eseguire il pull per DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
    • ROOT_DIRECTORY: aggiungi il percorso nel repository a la directory principale che contiene la configurazione da sincronizzare a. Questo campo è facoltativo e il valore predefinito è la directory radice (/) di nel repository.

    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: non usare l'autenticazione
      • gcenode: utilizza Account di servizio predefinito 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 dell'immagine.

      Questo campo è obbligatorio.

    • ROOT_EMAIL: se hai aggiunto gcpserviceaccount come tuo ROOT_AUTH_TYPE, aggiungi l'indirizzo email del tuo account di servizio Google. Ad esempio: acm@PROJECT_ID.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 saperne di più su come configurare l'oggetto Secret per la CA vedi Configurare l'operatore per un'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo dei campi che che è possibile aggiungere al campo spec, consulta la sezione Campi RootSync.

    Questo file 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
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME

    Sostituisci quanto segue:

    • ROOT_SYNC_NAME: aggiungi il nome del tuo sistema 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 consente puoi organizzare le configurazioni nel modo che preferisci.
    • ROOT_HELM_REPOSITORY: l'URL dell'Helm da utilizzare come repository radice. Puoi inserire gli URL utilizzando il protocollo HTTPS o SSH. Ad esempio, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilizza il protocollo HTTPS protocollo. Questo campo è obbligatorio.
    • HELM_CHART_NAME: aggiungi il nome del tuo Helm grafico. Questo campo è obbligatorio.
    • HELM_CHART_VERSION: la versione del grafico. Questo campo è facoltativo. Se non viene specificato alcun valore, l'ultima versione è in uso.
    • 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 modelli. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzato lo spazio dei nomi predefinito config-management-system.
    • HELM_INCLUDE_CRDS: imposta su true se vuoi il modello Helm per generare anche una CustomResourceDefinition. Questo è facoltativo. Se non viene specificato alcun valore, il valore predefinito è false e non verrà generato alcun CRD.
    • VALUE: valori da utilizzare al posto dei valori predefiniti associati al grafico Helm. Formatta questo campo come quello del file helm chart's values.yaml. Questo campo è facoltativo.

    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: non usare l'autenticazione
      • token: usa un nome utente e una password per accedere a un Helm privato repository Git.
      • gcenode: utilizza Account di servizio predefinito 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 dell'immagine.

      Questo campo è obbligatorio.

    • ROOT_EMAIL: se hai aggiunto gcpserviceaccount come tuo 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 nome del tuo secret se token è l'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'istanza certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominata cert. Questo campo è facoltativo.

    Per saperne di più su come configurare l'oggetto Secret per la CA vedi Configurare l'operatore per un'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo dei campi che che è possibile aggiungere al campo spec, consulta la sezione 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 radice

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

nomos status

Dovresti vedere un output simile all'esempio seguente:

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 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 le stato del deployment del 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 all'esempio seguente:

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

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

Dopo aver completato la configurazione del repository radice, puoi facoltativamente scegli di configurare la sincronizzazione da più repository. Questi repository sono utili se vuoi un repository che contenga configurazioni basate sullo spazio dei nomi sincronizzate con uno spazio dei nomi particolare nei cluster.

Esegui l'upgrade di Config Sync

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

  1. Scarica Config Sync manifest e i comandi nomos 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 il nuovo completamente gestita. All'avvio di Config Sync, viene eseguito un loop di riconciliazione che applica l'insieme di manifest raggruppati nella nuova immagine. Questi aggiornamenti e riavvia il pod di ogni componente.

  3. Sostituisci il comando nomos su tutti i client con la nuova completamente gestita. Questa modifica garantisce che il comando nomos possa sempre ottenere di tutti i cluster registrati e convalidare le configurazioni corrispondenti.

Disinstalla Config Sync

Per disinstallare Config Sync, completa i seguenti passaggi:

  1. Un amministratore centrale deve rimuovere il repository principale:

    1. Se hai attivato il webhook e vuoi conservare le tue risorse, disabilita la prevenzione della deviazione per le risorse abbandonate. Se non hai attivato il webhook, non è necessario eseguire altre per conservare le risorse.

    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 file config-management.yaml al cluster.

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

Passaggi successivi