Installa Config Sync

Con Config Sync puoi gestire le risorse Kubernetes con file di configurazione archiviati in una fonte attendibile. Config Sync supporta i repository Git, le immagini OCI e i grafici Helm come fonte attendibile. Questa pagina mostra come attivare e configurare Config Sync in modo che venga eseguito il sincronismo dal repository principale. Config Sync è disponibile con la versione Enterprise di Google Kubernetes Engine (GKE).

Quando installi Config Sync utilizzando la console Google Cloud o Google Cloud CLI, le API RootSync e RepoSync sono abilitate per impostazione predefinita. In questo modo, hai a disposizione funzionalità aggiuntive come la sincronizzazione da più repository e la sincronizzazione delle configurazioni di Kustomize e Helm.

Prima di iniziare

Prima di installare Config Sync, prepara il tuo ambiente, assicurati di soddisfare i requisiti del cluster e concedi i ruoli utente corretti.

Prepara l'ambiente locale

Prepara l'ambiente locale completando le seguenti attività:

  1. Crea o assicurati di avere accesso a una fonte attendibile. Qui puoi aggiungere le configurazioni con cui Config Sync esegue la sincronizzazione. Per scoprire di più su come configurare le configurazioni e l'origine attendibile, consulta una delle seguenti guide:
  2. Installa e inizializza Google Cloud CLI, che fornisce i comandi gcloud e nomos. Se utilizzi Cloud Shell, Google Cloud CLI è preinstallato. Se hai già installato Google Cloud CLI, ottieni la versione più recente eseguendo gcloud components update.

  3. Abilita l'API GKE Enterprise.

    Abilita l'API GKE Enterprise

Esamina i requisiti del cluster

Prima di installare Config Sync nel cluster, consulta i consigli e i requisiti per la configurazione del cluster.

Prepara il cluster

Dopo aver creato un cluster adatto, completa i seguenti passaggi:

  1. Concedi i ruoli IAM richiesti all'utente che registra il cluster.

  2. Se prevedi di utilizzare Google Cloud CLI per configurare Config Sync o utilizzare cluster esterni a Google Cloud, assicurati che i tuoi cluster GKE o cluster esterni a Google Cloud siano già registrati a un pool. Se prevedi di utilizzare la console Google Cloud, puoi registrare i cluster GKE quando configuri Config Sync.

Installazione di Config Sync

Nelle sezioni seguenti, concedi a Config Sync l'accesso a una delle seguenti fonti attendibili:

Dopo aver concesso l'accesso, puoi configurare Config Sync.

Concedi l'accesso a Git

Config Sync ha bisogno di accesso di sola lettura al tuo repository Git per poter leggere le configurazioni committate nel repository e applicarle ai tuoi cluster.

Se il repository non richiede l'autenticazione per l'accesso di sola lettura, puoi continuare a configurare la sincronizzazione della configurazione e utilizzare none come tipo di autenticazione. Ad esempio, se puoi sfogliare il repository utilizzando un'interfaccia web senza accedere o se puoi utilizzare git clone per creare una copia del repository localmente senza fornire le credenziali o utilizzare le credenziali salvate, non è necessario autenticarsi. In questo caso, non è necessario creare un secret.

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

Config Sync supporta i seguenti meccanismi di autenticazione:

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

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

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

  1. Elenca tutti i repository:

    gcloud source repos list

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

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

    Devi utilizzare questo URL quando configuri Config Sync nella sezione successiva. 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. 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 nel repository Git. Questo passaggio è necessario se devi autenticarti 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 tuoi requisiti di sicurezza e conformità.

    Il seguente comando crea una chiave RSA da 4096 bit. I valori inferiori 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 autenticarsi nel repository
    • /path/to/KEYPAIR_FILENAME: un percorso alla coppia di chiavi

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

  2. Configura il repository per riconoscere la chiave pubblica appena creata. Fai riferimento alla documentazione del tuo provider host Git. Per comodità, sono incluse le istruzioni per alcuni provider di hosting Git molto diffusi:

  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 degli host noti al campo data.known_hosts nel git_creds segreto. Per disattivare il controllo known_hosts, puoi rimuovere il campo known_hosts dal secret. Per aggiungere la chiave degli host noti, esegui:

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

    Quindi, in data, aggiungi la voce degli 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 del tuo repository Git, utilizza il protocollo SSH. Se utilizzi un repository in Cloud Source Repositories, devi utilizzare il seguente formato 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

La procedura per acquisire un cookiefile dipende dalla configurazione del tuo repository. Per un esempio, consulta Genera credenziali statiche nella documentazione di Cloud Source Repositories. In genere, le credenziali sono archiviate nel file .gitcookies nella home directory oppure ti potrebbero essere fornite da un amministratore della sicurezza.

Per utilizzare un cookiefile, completa i seguenti passaggi:

  1. Dopo aver creato e ottenuto il cookiefile, 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-file=cookie_file=/path/to/COOKIEFILE

    Se devi utilizzare un proxy HTTPS, aggiungilo al segreto insieme a cookiefile eseguendo 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 \
 --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 occorre ancora a livello locale. 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 GitLab o la password per l'app di Bitbucket come token.

Per creare un secret utilizzando il tuo token, segui questi 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 creato nel passaggio precedente.

    Se devi utilizzare un proxy HTTPS, aggiungilo al segreto insieme a username e token eseguendo 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 \
 --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.

Service account Google

Se il tuo repository si trova in Cloud Source Repositories e il tuo cluster utilizza la federazione delle identità per i carichi di lavoro di GKE o la federazione delle identità per i carichi di lavoro di Fleet per GKE, 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 Cloud Source Repositories Reader (roles/source.reader) all'account di servizio Google. Per ulteriori informazioni su ruoli e autorizzazioni di Cloud Source Repositories, consulta Concedere autorizzazioni per visualizzare i repository.

    • Concedi l'autorizzazione a livello di progetto se le stesse autorizzazioni si applicano a tutti i repository del 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 per il repository quando vuoi che gli account di servizio abbiano livelli di accesso diversi per ogni repository del progetto.

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

  3. Se configuri Config Sync utilizzando la console Google Cloud, seleziona Federazione delle identità per i carichi di lavoro per GKE 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 e poi aggiungi l'indirizzo email del tuo 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 pool Workload Identity Federation for GKE. 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 Workload Identity Federation for GKE, è lo stesso valore di PROJECT_ID. Se utilizzi la federazione delle identità per i carichi di lavoro del parco risorse per GKE, questo è l'ID progetto del parco risorse a cui è registrato il tuo 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 Lettore di Artifact Registry (roles/artifactregistry.reader).
  • KSA_NAME: l'account di servizio Kubernetes per il Mediatore.
    • Per i repository principali, se il nome 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 di Identity and Access Management.

Account di servizio predefinito Compute Engine

Se il tuo repository si trova in Cloud Source Repositories e il tuo cluster è GKE con la federazione delle identità per i carichi di lavoro per GKE disattivata, puoi utilizzare gcenode come tipo di autenticazione.

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

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

Se selezioni Repository Google Cloud o gcenode, puoi utilizzare l'account di servizio predefinito di Compute Engine. Devi concedere il ruolo IAM Reader dei repository di codice sorgente di Cloud (roles/source.reader) all'account di servizio predefinito di Compute Engine. Per ulteriori informazioni su ruoli e autorizzazioni di Cloud Source Repositories, consulta Concedere 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 PROJECT_NUMBER con il numero del progetto della tua organizzazione.

App GitHub

Se il tuo repository si trova su GitHub, puoi utilizzare githubapp come tipo di autenticazione.

Per utilizzare un'app GitHub:

  1. Segui le istruzioni su GitHub per eseguire il provisioning di un'app GitHub e concederle l'autorizzazione di lettura dal tuo repository.

  2. Aggiungi la configurazione dell'app GitHub a un nuovo secret nel cluster:

    Utilizzo dell'ID client 

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
  --namespace=config-management-system \
  --from-literal=github-app-client-id=CLIENT_ID \
  --from-literal=github-app-installation-id=INSTALLATION_ID \
  --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
  --from-literal=github-app-base-url=BASE_URL
    • Sostituisci CLIENT_ID con l'ID client per l'app GitHub.
    • Sostituisci INSTALLATION_ID con l'ID installazione dell'app GitHub.
    • Sostituisci /path/to/GITHUB_PRIVATE_KEY con il nome del file contenente la chiave privata.
    • Sostituisci BASE_URL con l'URL di base per l'endpoint dell'API GitHub. Questo è necessario solo se il repository non è ospitato su www.github.com. In caso contrario, l'argomento può essere omesso e il valore predefinito sarà https://api.github.com/.

    Utilizzo dell'ID applicazione 

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
  --namespace=config-management-system \
  --from-literal=github-app-application-id=APPLICATION_ID \
  --from-literal=github-app-installation-id=INSTALLATION_ID \
  --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
  --from-literal=github-app-base-url=BASE_URL
    • Sostituisci APPLICATION_ID con l'ID applicazione per l'app GitHub.
    • Sostituisci INSTALLATION_ID con l'ID installazione dell'app GitHub.
    • Sostituisci /path/to/GITHUB_PRIVATE_KEY con il nome del file contenente la chiave privata.
    • Sostituisci BASE_URL con l'URL di base per l'endpoint dell'API GitHub. Questo è necessario solo se il repository non è ospitato su www.github.com. In caso contrario, l'argomento può essere omesso e il valore predefinito sarà https://api.github.com/.

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

  4. Quando configuri Config Sync e aggiungi l'URL del tuo repository Git, utilizza il tipo di autenticazione githubapp.

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

Config Sync ha bisogno di accesso di sola lettura all'immagine OCI archiviata in Artifact Registry per poter 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 può essere visualizzata da chiunque su internet, non è necessario autenticarsi.

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

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

  • Account di servizio predefinito Compute Engine (gcenode)

Service account Kubernetes

Se archivi l'immagine OCI in Artifact Registry e il tuo cluster utilizza la federazione delle identità per i carichi di lavoro per GKE o la federazione delle identità per i carichi di lavoro per il parco risorse, puoi utilizzare k8sserviceaccount come tipo di autenticazione nella versione 1.17.2 e successive. Questa opzione è consigliata rispetto a gcpserviceaccount per il suo procedura di configurazione semplificata.

  1. Concedi il ruolo IAM Lettore del registry degli elementi (roles/artifactregistry.reader) all'account di servizio Kubernetes con il pool della federazione delle identità per i carichi di lavoro per GKE. 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 del 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 per il repository quando vuoi che gli account di servizio abbiano livelli di accesso diversi per ogni repository del 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 Workload Identity Federation for GKE, è lo stesso valore di PROJECT_ID. Se utilizzi la federazione delle identità per i carichi di lavoro del parco risorse per GKE, questo è l'ID progetto del parco risorse a cui è registrato il tuo cluster.
    • KSA_NAME: l'account di servizio Kubernetes per il Mediatore.
      • Per i repository principali, se il nome 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 posizione regionale o su più regioni del repository.

Service account Google

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

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

  2. Concedi il ruolo IAM Lettore del registry di elementi (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 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 per il repository quando vuoi che gli account di servizio abbiano livelli di accesso diversi per ogni repository del 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 il seguente 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 Workload Identity Federation for GKE, è lo stesso valore di PROJECT_ID. Se utilizzi la federazione delle identità per i carichi di lavoro del parco risorse per GKE, questo è l'ID progetto del parco risorse a cui è registrato il tuo 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 Lettore di Artifact Registry (roles/artifactregistry.reader).
  • KSA_NAME: l'account di servizio Kubernetes per il Mediatore.
    • Per i repository principali, se il nome 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 posizione regionale o multiregionale del repository.

Account di servizio predefinito Compute Engine

Se archivi il grafico Helm in Artifact Registry e il tuo cluster è GKE con la federazione delle identità per i carichi di lavoro per GKE disattivata, puoi utilizzare gcenode come tipo di autenticazione. Config Sync utilizza l'account di servizio predefinito di Compute Engine. Devi concedere all'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 a Artifact Registry eseguendo il seguente 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 PROJECT_NUMBER con il numero del progetto della tua organizzazione.

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

Config Sync ha bisogno di accesso in sola lettura al tuo repository Helm per poter leggere i grafici Helm nel repository e installarli nei tuoi 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 tuo repository Helm è pubblico e chiunque su internet può accedervi, non è necessario autenticarsi.

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

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

Token

Crea un secret con il nome utente e la 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 secret.
  • USERNAME: il nome utente del repository Helm.
  • PASSWORD: la password del repository Helm.

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

Service account Kubernetes

Se memorizzi il tuo diagramma Helm in Artifact Registry e il tuo cluster utilizza la federazione delle identità per i carichi di lavoro di GKE o la federazione delle identità per i carichi di lavoro del parco risorse di GKE, puoi utilizzare k8sserviceaccount come tipo di autenticazione nella versione 1.17.2 e successive. Questa opzione è consigliata rispetto a gcpserviceaccount per il suo procedura di configurazione semplificata.

  1. Concedi il ruolo IAM Lettore del registry degli elementi (roles/artifactregistry.reader) all'account di servizio Kubernetes con il pool della federazione delle identità per i carichi di lavoro per GKE. 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 del 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 per il repository quando vuoi che gli account di servizio abbiano livelli di accesso diversi per ogni repository del 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 Workload Identity Federation for GKE, è lo stesso valore di PROJECT_ID. Se utilizzi la federazione delle identità per i carichi di lavoro del parco risorse per GKE, questo è l'ID progetto del parco risorse a cui è registrato il tuo cluster.
    • KSA_NAME: l'account di servizio Kubernetes per il Mediatore.
      • Per i repository principali, se il nome RootSync è root-sync, utilizza root-reconciler. In caso contrario, usa root-reconciler-ROOT_SYNC_NAME.
    • REPOSITORY: l'ID del repository.
    • LOCATION: la posizione regionale o su più regioni del repository.

Service account Google

Se memorizzi il grafico Helm in Artifact Registry e il tuo cluster utilizza la federazione delle identità per i carichi di lavoro di GKE o la federazione delle identità per i carichi di lavoro del parco risorse di GKE, puoi utilizzare gcpserviceaccount come tipo di autenticazione. A partire dalla versione 1.17.2, ti consigliamo di utilizzare k8sserviceaccount. Questa opzione elimina i passaggi aggiuntivi per la creazione di un account di servizio Google e dell'associazione dei criteri IAM.

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

  2. Concedi il ruolo IAM Lettore del registry di elementi (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 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 per il repository quando vuoi che gli account di servizio abbiano livelli di accesso diversi per ogni repository del 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 il seguente 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 Workload Identity Federation for GKE, è lo stesso valore di PROJECT_ID. Se utilizzi la federazione delle identità per i carichi di lavoro del parco risorse per GKE, questo è l'ID progetto del parco risorse a cui è registrato il tuo 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 Lettore di Artifact Registry (roles/artifactregistry.reader).
  • KSA_NAME: l'account di servizio Kubernetes per il Mediatore.
    • Per i repository principali, se il nome RootSync è root-sync, utilizza root-reconciler. In caso contrario, usa root-reconciler-ROOT_SYNC_NAME.
  • REPOSITORY: l'ID del repository.
  • LOCATION: la posizione regionale o multiregionale del repository.

Account di servizio predefinito Compute Engine

Se archivi il grafico Helm in Artifact Registry e il tuo cluster è GKE con la federazione delle identità per i carichi di lavoro per GKE disabilitata, puoi utilizzare gcenode come tipo di autenticazione. Config Sync utilizza l'account di servizio predefinito di Compute Engine. Devi concedere all'account di servizio predefinito di 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 per estrarre le immagini.

  1. Concedi all'account di servizio Compute Engine l'autorizzazione di lettura 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 PROJECT_NUMBER con il numero del progetto della tua organizzazione.

Configura Config Sync

In questa sezione configuri le impostazioni per il repository principale. Se effettui la sincronizzazione con un repository Git, puoi utilizzare la console Google Cloud per seguire la procedura di installazione e automatizzare alcuni passaggi.

Quando installi Config Sync utilizzando la console Google Cloud o Google Cloud CLI, Config Sync crea automaticamente un oggetto RootSync denominatoroot-sync. Puoi utilizzare i comandi kubectl per modificare root-sync e aggiungere altre configurazioni di Config Sync. Per scoprire di più, consulta Configurare Config Sync con i comandi kubectl.

Console

Installazione di Config Sync

Per installare Config Sync, tutti i cluster devono essere registrati in un parco risorse. Quando installi Config Sync nella console Google Cloud, la selezione di singoli cluster li registra automaticamente nel tuo parco risorse.

  1. Nella console Google Cloud, vai alla pagina Configurazione nella sezione Funzionalità.

    Vai a Config

  2. Fai clic su Installa Config Sync.
  3. Seleziona Upgrade automatici (Anteprima) per consentire a Config Sync di eseguire l'upgrade delle versioni automaticamente o seleziona Upgrade manuali per gestire autonomamente la versione di Config Sync. Per ulteriori informazioni sul funzionamento degli upgrade automatici, consulta Eseguire l'upgrade di Config Sync.
  4. In Opzioni di installazione, seleziona una delle seguenti opzioni:
    • Installa Config Sync nell'intero parco risorse (consigliato): Config Sync verrà installato su tutti i cluster del parco risorse.
    • Installa Config Sync su singoli cluster: tutti i cluster selezionati verranno registrati automaticamente in un parco risorse. Config Sync verrà installato su tutti i cluster del parco risorse.
  5. Se stai installando Config Sync su singoli cluster, nella tabella Cluster disponibili, seleziona i cluster su cui vuoi installare Config Sync.
  6. Fai clic su Installa Config Sync. Nella scheda Impostazioni, dopo alcuni minuti dovresti vedere Attivato nella colonna Stato per i cluster del tuo parco risorse.

Deployment di un pacchetto

Dopo aver registrato i cluster in un parco risorse e installato Config Sync, puoi configurare Config Sync per eseguire il deployment di un pacchetto in un cluster da una fonte attendibile. Puoi eseguire il deployment dello stesso pacchetto su più cluster o di pacchetti diversi su cluster diversi. Puoi modificare un pacchetto dopo averlo disegnato, ad eccezione di alcune impostazioni come il nome del pacchetto e il tipo di sincronizzazione. Per saperne di più, consulta Gestire i pacchetti.

Per eseguire il deployment di un pacchetto, completa i seguenti passaggi:

  1. Nella console Google Cloud, vai alla dashboard di Config Sync.

    Vai alla dashboard di Config Sync

  2. Fai clic su Esegui il deployment del pacchetto.

  3. Nella tabella Seleziona i cluster per il deployment del pacchetto, seleziona il cluster su cui vuoi eseguire il deployment di un pacchetto e poi fai clic su Continua.

  4. Seleziona Pacchetto ospitato su Git o Pacchetto ospitato su OCI come tipo di origine e poi fai clic su Continua.

  5. Nella sezione Dettagli del pacchetto, inserisci un nome del pacchetto che identifica l'oggetto RootSync o RepoSync.

  6. Nel campo Tipo di sincronizzazione, scegli Sincronizzazione basata sul cluster o Sincronizzazione basata sullo spazio dei nomi come tipo di sincronizzazione.

    La sincronizzazione basata sul cluster crea un oggetto RootSync e la sincronizzazione basata sullo spazio dei nomi crea un oggetto RepoSync. Per ulteriori informazioni su questi oggetti, consulta la Architettura di Config Sync.

  7. Nella sezione Origine, completa quanto segue:

    • Per le origini ospitate in un repository Git, inserisci i seguenti campi:

      1. Inserisci l'URL del repository Git che utilizzi come fonte attendibile come URL del repository.
      2. (Facoltativo) Aggiorna il campo Revisione per verificare se non utilizzi il valore predefinito HEAD.
      3. (Facoltativo) Aggiorna il campo Percorso se non vuoi eseguire la sincronizzazione dal repository principale.
      4. (Facoltativo) Aggiorna il campo Ramo se non utilizzi il ramo predefinito main.

    • Per le origini ospitate in un'immagine OCI, inserisci i seguenti campi:

      1. Inserisci l'URL dell'immagine OCI che utilizzi come fonte di riferimento come Immagine.
      2. Inserisci il percorso della directory da cui eseguire la sincronizzazione, rispetto alla directory principale, come Directory.

  8. (Facoltativo) Espandi la sezione Impostazioni avanzate per completare quanto segue:

    1. Seleziona un Tipo di autenticazione. Config Sync ha bisogno di accesso in sola lettura alla fonte attendibile per leggere i file di configurazione al suo interno e applicarli ai cluster. A meno che l'origine non richieda l'autenticazione, ad esempio un repository pubblico, assicurati di concedere a Config Sync l'accesso di sola lettura al tuo repository Git, all'immagine OCI o al grafico Helm (solo gcloud CLI). Scegli lo stesso tipo di autenticazione configurato durante l'installazione di Config Sync:

      • Nessuna: non utilizzare l'autenticazione.
      • SSH: esegui l'autenticazione utilizzando una coppia di chiavi SSH.
      • Cookiefile: esegui l'autenticazione utilizzando un cookiefile.
      • Token: esegui l'autenticazione utilizzando un token di accesso o una password.
      • Repository Google Cloud: utilizza un account di servizio Google per accedere a un repository Cloud Source Repositories. Seleziona questa opzione solo se la federazione delle identità per i carichi di lavoro per GKE non è abilitata nel tuo cluster.
      • Workload Identity: utilizza un account di servizio Google per accedere a un repository Cloud Source Repositories.

    2. Inserisci un numero in secondi per impostare il tempo di attesa della sincronizzazione, che determina il tempo di attesa di Config Sync tra i tentativi di estrazione dalla fonte di riferimento.

    3. Inserisci un URL di proxy Git per il proxy HTTPS da utilizzare per la comunicazione con la fonte di verità.

    4. Scegli Gerarchia per modificare il Formato dell'origine.

      Il valore predefinito Non strutturato è consigliato nella maggior parte dei casi, poiché consente di organizzare l'origine attendibile come preferisci.

  9. Fai clic su Esegui il deployment del pacchetto.

    Ti reindirizzeremo alla pagina Pacchetti di Config Sync. Dopo qualche minuto, dovresti vedere Sincronizzato nella colonna Stato sincronizzazione per il cluster che hai configurato.

gcloud

Prima di continuare, assicurati di avere registrato i tuoi cluster in un parco risorse.

  1. Attiva la funzionalità del parco risorse ConfigManagement:

    gcloud beta container fleet config-management enable

  2. Prepara la configurazione creando un nuovo apply-spec.yaml manifest o utilizzandone uno esistente. L'utilizzo di un manifest esistente consente di configurare il cluster con le stesse impostazioni utilizzate da un altro cluster.

    Crea nuovo manifest

    Per configurare Config Sync con nuove impostazioni per il cluster, crea un file denominato apply-spec.yaml e copia al suo interno il seguente file YAML.

    Puoi impostare tutti i campi spec.configSync facoltativi di cui hai bisogno quando crei il manifest e in un secondo momento utilizzare i comandi kubectl per la configurazione. Puoi anche impostare solo il campo spec.configSync.enabled come true e ommettere i campi facoltativi. In un secondo momento, puoi utilizzare i comandi kubectl per creare altri oggetti RootSync o RepoSync che potrai gestire completamente utilizzando i comandi kubectl.

    # apply-spec.yaml

applySpecVersion: 1
spec:
  # upgrades: UPGRADE_SETTING
  configSync:
    # Set to true to install and enable Config Sync
    enabled: true
    # If you don't have a source of truth yet, omit the
    # following fields. You can configure them later.
    sourceType: SOURCE_TYPE
    sourceFormat: FORMAT
    syncRepo: REPO
    syncRev: REVISION
    syncBranch: BRANCH
    secretType: SECRET_TYPE
    gcpServiceAccountEmail: EMAIL
    metricsGcpServiceAccountEmail: METRICS_EMAIL
    policyDir: DIRECTORY
    preventDrift: PREVENT_DRIFT

    Sostituisci quanto segue:

    • (Anteprima) UPGRADE_SETTING: rimuovi il commento dal campo e impostalo su auto per configurare Config Sync in modo che esegua l'upgrade automaticamente. Imposta su manual per eseguire manualmente l'upgrade di Config Sync. Il valore predefinito è manual. Questo flag è supportato solo per i cluster GKE su Google Cloud. Per utilizzare questo campo, potrebbe essere necessario aggiornare l'interfaccia a riga di comando gcloud eseguendo gcloud components update.

    • SOURCE_TYPE: aggiungi git per eseguire la sincronizzazione da un repository Git, oci per eseguire la sincronizzazione da un'immagine OCI o helm per eseguire la sincronizzazione da un grafico Helm. Se non viene specificato alcun valore, il valore predefinito è git.

    • FORMAT: aggiungi unstructured per utilizzare un repository non strutturato o 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, perché questo formato consente di organizzare le configurazioni nel modo più comodo per te.

    • REPO: aggiungi l'URL della fonte attendibile. Gli URL dei repository Git e Helm utilizzano il protocollo HTTPS o SSH. Ad esempio, https://github.com/GoogleCloudPlatform/anthos-config-management-samples. Se prevedi di utilizzare SSH come secretType, inserisci l'URL con il protocollo SSH. Questo campo è obbligatorio e se non inserisci un protocollo, l'URL viene trattato come un URL HTTPS.

      Gli URL OCI utilizzano il seguente formato: 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 anche tramite TAG o DIGEST. Specifica TAG o DIGEST nel PACKAGE_NAME:

      • Per estrarre per TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
      • Per estrarre per DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST

    • REVISION: la revisione Git (tag o hash) da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è HEAD. A partire dalla versione 1.17.0 di Config Sync, puoi anche specificare un nome del ramo nel campo syncRev. Quando utilizzi un hash nella versione 1.17.0 o successive, deve essere un hash completo e non una forma abbreviata.

    • BRANCH: il ramo del repository da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è master. A partire dalla versione 1.17.0 di Config Sync, per semplicità ti consigliamo di utilizzare il campo syncRev per specificare un nome del ramo. Se sono specificati sia il campo syncRev che il campo syncBranch, syncRev ha la precedenza su syncBranch.

    • SECRET_TYPE: uno dei seguenti secretTypes:

      git

      • none: non utilizzare l'autenticazione.
      • ssh: utilizza una coppia di chiavi SSH.
      • cookiefile: utilizza un cookiefile.
      • token: utilizza un token.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a Cloud Source Repositories. Se selezioni questo tipo di autenticazione, devi creare un'associazione di criteri IAM al termine della configurazione di Config Sync. Per maggiori dettagli, consulta la scheda dell'account di servizio Google della sezione Concedere a Config Sync l'accesso di sola lettura a Git.
      • gcenode: utilizza un account di servizio Google per accedere a Cloud Source Repositories. Seleziona questa opzione solo se Workload Identity Federation for GKE non è abilitato nel tuo cluster.
      • githubapp: utilizza un'app GitHub per autenticarti in un repository GitHub.

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

      oci

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

      helm

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

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

    • METRICS_EMAIL: l'indirizzo email del service account Google Cloud (GSA) utilizzato per esportare le metriche di Config Sync in Cloud Monitoring. L'amministratore globale della sicurezza deve disporre del ruolo IAM Writer metriche Monitoring (roles/monitoring.metricWriter). L'account di servizio Kubernetes default nello spazio dei nomi config-management-monitoring deve essere legato al GSA.

    • DIRECTORY: il percorso della directory da cui eseguire la sincronizzazione, relativo alla radice del repository Git. Tutte le sottodirectory della directory specificata vengono incluse e sincronizzate con il cluster. Il valore predefinito è la directory radice del repository.

    • PREVENT_DRIFT: se impostato su true, consente al webhook di ammissione di Config Sync di impedire gli scostamenti rifiutando l'invio di modifiche in conflitto ai cluster attivi. L'impostazione predefinita è false. Config Sync corregge sempre le derive indipendentemente dal valore di questo campo.

    Per un elenco completo dei campi che puoi aggiungere al campo spec, consulta Campi gcloud.

    Utilizza il manifest esistente

    Per configurare il cluster con le stesse impostazioni utilizzate da un altro cluster, recupera le impostazioni da un cluster registrato:

    gcloud alpha container fleet config-management fetch-for-apply \
    --membership=MEMBERSHIP_NAME \
    --project=PROJECT_ID \
    > CONFIG_YAML_PATH

    Sostituisci quanto segue:

    • MEMBERSHIP_NAME: il nome dell'appartenenza al cluster registrato con le impostazioni di Config Sync che vuoi utilizzare
    • PROJECT_ID: il tuo ID progetto
    • CONFIG_YAML_PATH: il percorso del apply-spec.yaml file contenente le impostazioni recuperate dal cluster

  3. Applica il file apply-spec.yaml. Se utilizzi un manifest esistente, devi applicare il file al cluster che vuoi configurare con le impostazioni recuperate nel comando precedente:

    gcloud beta container fleet config-management apply \
    --membership=MEMBERSHIP_NAME \
    --config=CONFIG_YAML_PATH \
    --project=PROJECT_ID

    Sostituisci quanto segue:

    • MEMBERSHIP_NAME: il nome dell'appartenenza al parco risorse che hai scelto quando hai registrato il cluster. Puoi trovare il nome con gcloud container fleet memberships list.
    • CONFIG_YAML_PATH: il percorso del apply-spec.yaml file.
    • PROJECT_ID: il tuo ID progetto.

Terraform

Per ogni cluster in cui vuoi configurare Config Sync, applica un blocco di risorse google_gkehub_feature_membership contenente un blocco configmanagement e config_sync:

git

resource "google_container_cluster" "cluster" {
 name = "EXISTING_CLUSTER_NAME"
 location = "EXISTING_CLUSTER_LOCATION"
}

resource "google_gke_hub_membership" "membership" {
 membership_id = "MEMBERSHIP_ID"
 endpoint {
   gke_cluster {
     resource_link = "//container.googleapis.com/${google_container_cluster.cluster.id}"
   }
 }
}

resource "google_gke_hub_feature" "feature" {
 name = "configmanagement"
 location = "global"
}

resource "google_gke_hub_feature_membership" "feature_member" {
 location = "global"
 feature = google_gke_hub_feature.feature.name
 membership = google_gke_hub_membership.membership.membership_id
 configmanagement {
   version = "VERSION"
   config_sync {
     # The field `enabled` was introduced in Terraform version 5.41.0, and
     # needs to be set to `true` explicitly to install Config Sync.
     enabled = true
     git {
       sync_repo = "REPO"
       sync_branch = "BRANCH"
       policy_dir = "DIRECTORY"
       secret_type = "SECRET"
     }
   }
 }
}

Sostituisci quanto segue:

  • EXISTING_CLUSTER_NAME: il nome del cluster esistente.
  • EXISTING_CLUSTER_LOCATION: la posizione del cluster esistente.
  • MEMBERSHIP_ID: l'ID associazione all'abbonamento.
  • VERSION: (facoltativo) il numero di versione di Config Sync. Deve essere impostata sulla versione 1.17.0 o successive. Se non la specifichi, il valore predefinito è la versione più recente.
  • REPO: l'URL del repository contenente i file di configurazione.
  • BRANCH: il ramo del repository, ad esempio main.
  • DIRECTORY: il percorso all'interno del repository Git che rappresenta il livello superiore del repository da sincronizzare.
  • SECRET: il tipo di autorizzazione mediante secret.

oci

resource "google_container_cluster" "cluster" {
 name = "EXISTING_CLUSTER_NAME"
 location = "EXISTING_CLUSTER_LOCATION"
}

resource "google_gke_hub_membership" "membership" {
 membership_id = "MEMBERSHIP_ID"
 endpoint {
   gke_cluster {
     resource_link = "//container.googleapis.com/${google_container_cluster.cluster.id}"
   }
 }
}

resource "google_gke_hub_feature" "feature" {
 name = "configmanagement"
 location = "global"
}

resource "google_gke_hub_feature_membership" "feature_member" {
 location = "global"
 feature = google_gke_hub_feature.feature.name
 membership = google_gke_hub_membership.membership.membership_id
 configmanagement {
   version = "VERSION"
   config_sync {
     # The field `enabled` was introduced in Terraform version 5.41.0, and
     # needs to be set to `true` explicitly to install Config Sync.
     enabled = true
     oci {
       sync_repo = "REPO"
       policy_dir = "DIRECTORY"
       secret_type = "SECRET"
     }
   }
 }
}

Sostituisci quanto segue:

  • EXISTING_CLUSTER_NAME: il nome del cluster esistente.
  • EXISTING_CLUSTER_LOCATION: la posizione del cluster esistente.
  • MEMBERSHIP_ID: l'ID associazione all'abbonamento.
  • VERSION: (facoltativo) il numero di versione di Config Sync. Se non la specifichi, il valore predefinito è la versione più recente.
  • REPO: l'URL del repository di immagini OCI contenente i file di configurazione.
  • DIRECTORY: il percorso assoluto della directory contenente le risorse da sincronizzare. Lascia vuoto per utilizzare la home directory.
  • SECRET: il tipo di autorizzazione mediante secret.

Ripeti questa procedura per ogni cluster che vuoi sincronizzare.

Al termine della configurazione del repository principale, facoltativamente puoi scegliere di configurare la sincronizzazione da più repository, inclusi altri repository principali e di spazi dei nomi. I repository dello spazio dei nomi sono utili se vuoi un repository contenente configurazioni basate sullo spazio dei nomi sincronizzate con uno spazio dei nomi specifico nei cluster.

Configura i valori predefiniti a livello di parco risorse

Se hai abilitato la versione Enterprise di Google Kubernetes Engine (GKE), puoi attivare e configurare Config Sync come impostazione predefinita a livello di parco per i tuoi cluster. Ciò significa che in ogni nuovo cluster GKE su Google Cloud creato nel parco risorse verrà attivata la funzionalità Config Sync con le impostazioni specificate. Puoi approfondire la configurazione predefinita del parco risorse in Gestire le funzionalità a livello di parco risorse.

Se utilizzi solo la console Google Cloud, puoi attivare Config Sync per impostazione predefinita sui tuoi cluster e impostare la versione di Config Sync per il tuo parco risorse. Se utilizzi gcloud CLI o Terraform, puoi attivare Config Sync per impostazione predefinita sui tuoi cluster, impostare la versione di Config Sync per il tuo parco risorse e configurare la connessione al tuo repository Git o al repository di immagini OCI.

Per configurare i valori predefiniti a livello di parco risorse per Config Sync, completa i seguenti passaggi:

gcloud

Esegui il comando enable per la funzionalità, passando il file di configurazione apply-spec.yaml che hai creato quando hai configurato Config Sync su un singolo cluster:

gcloud beta container fleet config-management enable \
    --fleet-default-member-config=apply-spec.yaml

Puoi utilizzare questo comando per aggiornare le impostazioni predefinite del parco risorse in qualsiasi momento. Se aggiorni le impostazioni predefinite del parco, devi sincronizzare nuovamente i cluster esistenti con le impostazioni predefinite.

Console

  1. Nella console Google Cloud, vai alla pagina Gestione funzionalità.

    Vai a Gestione funzionalità

  2. Nel riquadro Config Sync, fai clic su Configura.

  3. Rivedi le impostazioni a livello di parco risorse. Tutti i nuovi cluster che crei nel parco risorse erediteranno queste impostazioni.

  4. (Facoltativo) Per modificare le impostazioni predefinite, fai clic su Personalizza le impostazioni del parco. Nella finestra di dialogo visualizzata, procedi nel seguente modo:

  5. Seleziona Upgrade automatici (Anteprima) per eseguire automaticamente l'upgrade delle versioni di Config Sync o Upgrade manuali per gestire autonomamente la versione di Config Sync. Per saperne di più sul funzionamento degli upgrade automatici, consulta Eseguire l'upgrade di Config Sync.

  6. Se hai selezionato Upgrade manuali, nell'elenco Versione seleziona la versione di Config Sync che vuoi utilizzare.

  7. Fai clic su Salva modifiche.

  8. Fai clic su Configura.

  9. Nella finestra di dialogo di conferma Configurazione delle impostazioni del parco, fai clic su Conferma. Se non hai precedentemente attivato Config Sync, facendo clic su Conferma viene attivata anche l'API anthosconfigmanagement.googleapis.com.

Terraform

  1. Crea una directory per i file Terraform di configurazione predefinita del parco risorse. Aggiungi a questa directory un file main.tf con la seguente risorsa che configura le impostazioni di Config Sync:

    git

    terraform {
  required_providers {
    google = {
      source = "hashicorp/google"
      version = ">=5.16.0"
      }
    }
  }

provider "google" {
  project = "PROJECT_ID"
}

resource "google_gke_hub_feature" "feature" {
  name = "configmanagement"
  location = "global"
  provider = google
  fleet_default_member_config {
    configmanagement {
    version = "VERSION"
    config_sync {
    source_format = "unstructured"
      git {
        sync_repo = "REPO"
        sync_branch = "BRANCH"
        policy_dir = "DIRECTORY"
        secret_type = "SECRET"
      }
    }
    }
  }
}

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID progetto host del parco risorse.
    • VERSION: (facoltativo) il numero di versione di Config Sync. Se non la specifichi, il valore predefinito è la versione più recente.
    • REPO: l'URL del repository contenente i file di configurazione.
    • BRANCH: il ramo del repository, ad esempio main.
    • DIRECTORY: il percorso all'interno del repository Git che rappresenta il livello superiore del repository da sincronizzare.
    • SECRET: il tipo di autorizzazione mediante secret.

    Per un elenco completo delle impostazioni supportate nel blocco git di Config Sync, consulta la documentazione di riferimento di Terraform per le funzionalità dell'hub GKE.

    OCI

    terraform {
  required_providers {
    google = {
      source = "hashicorp/google"
      version = ">=5.16.0"
      }
    }
  }

provider "google" {
  project = "PROJECT_ID"
}

resource "google_gke_hub_feature" "feature" {
  name = "configmanagement"
  location = "global"
  provider = google
  fleet_default_member_config {
    configmanagement {
    version = "VERSION"
    config_sync {
    source_format = "unstructured"
      oci {
        sync_repo = "REPO"
        policy_dir = "DIRECTORY"
        secret_type = "SECRET"
      }
    }
    }
  }
}

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID progetto host del parco risorse.
    • VERSION: il numero di versione di Config Sync. Deve essere impostata sulla versione 1.17.0 o successive. Se non la specifichi, il valore predefinito è la versione più recente.
    • REPO: l'URL del repository di immagini OCI contenente i file di configurazione.
    • DIRECTORY: il percorso assoluto della directory contenente le risorse da sincronizzare. Lascia vuoto per utilizzare la home directory.
    • SECRET: il tipo di autorizzazione mediante secret.

    Per un elenco completo delle impostazioni supportate nel blocco oci di Config Sync, consulta la documentazione di riferimento di Terraform per le funzionalità dell'hub GKE.

  2. Inizializza Terraform nella directory che hai creato:

    terraform init

  3. Verifica che le modifiche proposte con Terraform corrispondano al piano previsto:

    terraform plan

  4. Crea le configurazioni dei membri del parco risorse predefinite:

    terraform apply

Per aggiornare i cluster esistenti in modo che utilizzino le impostazioni predefinite di Config Sync, puoi utilizzare la console Google Cloud o lgcloud CLI per sincronizzare i cluster del parco risorse selezionati con i valori predefiniti del parco risorse. In alternativa, puoi configurare manualmente ogni cluster con le stesse impostazioni utilizzando Terraform seguendo le istruzioni per la configurazione di Config Sync. Se in precedenza hai utilizzato Terraform per specificare i valori predefiniti del parco, utilizza gli stessi blocchi configmanagement e config_sync che hai utilizzato per impostare i valori predefiniti per configurare i cluster scelti.

Per sincronizzare le impostazioni predefinite di Config Sync nel parco risorse:

gcloud

  1. Sincronizza un abbonamento esistente con la configurazione predefinita del parco risorse:

    gcloud beta container fleet config-management apply \
    --origin=FLEET \
    --membership=MEMBERSHIP_NAME

    Sostituisci MEMBERSHIP_NAME con il nome dell'appartenenza al parco risorse del cluster che vuoi sincronizzare con la configurazione predefinita del parco risorse.

  2. Verifica che le configurazioni degli abbonamenti siano sincronizzate con quelle predefinite del parco:

    gcloud beta container fleet config-management status

    L'output di questo comando dovrebbe essere Yes per lo stato Synced_to_Fleet_Default per l'abbonamento che hai sincronizzato.

console

  1. Vai a Gestore funzionalità:

    Vai a Gestore funzionalità: Config Sync

  2. Nella tabella dei cluster, seleziona i cluster che vuoi sincronizzare con le impostazioni del parco risorse.

  3. Fai clic su Sincronizza con le impostazioni del parco risorse.

Per disattivare le impostazioni predefinite di Config Sync nel parco risorse, segui questi passaggi:

  1. Per disattivare la configurazione predefinita del parco, esegui il seguente comando:

    gcloud beta container fleet config-management disable --fleet-default-member-config

  2. Verifica che la configurazione predefinita del parco risorse sia disattivata:

    gcloud beta container fleet config-management status

Le impostazioni predefinite di Config Sync vengono applicate a tutti i cluster selezionati. Sebbene la console Google Cloud mostri solo un sottoinsieme di impostazioni, come la versione di Config Sync, tutte le impostazioni a livello di parco risorse vengono sincronizzate con i cluster. Ad esempio, se configuri Config Sync per eseguire la sincronizzazione con un repository Git utilizzando Terraform o gcloud CLI, l'impostazione viene sincronizzata con i tuoi cluster, ma non viene visualizzata nella console Google Cloud.

Verificare l'installazione

Dopo aver installato e configurato Config Sync, puoi verificare che l'installazione sia stata completata correttamente.

Console

Completa i seguenti passaggi:

  1. Nella console Google Cloud, vai alla pagina Configurazione nella sezione Funzionalità.

    Vai a Config

  2. Nella scheda Pacchetti, controlla la colonna Stato sincronizzazione nella tabella del cluster. Un'installazione di Config Sync riuscita ha lo stato Installato. Una sorgente di dati configurata correttamente ha lo stato Sincronizzata.

gcloud

Esegui questo comando:

gcloud beta container fleet config-management status \
    --project=PROJECT_ID

Sostituisci PROJECT_ID con l'ID del tuo progetto.

Un'installazione riuscita ha uno stato SYNCED. A partire dalla versione 1.18.0 di Config Sync, l'output mostra anche la versione di Config Sync installata e l'impostazione di upgrade di Config Sync.

Se viene visualizzato un errore dopo l'esecuzione del comando precedente, assicurati di aver creato il secret git-creds. Se hai creato il segreto, prova a eseguire nuovamente il seguente comando:

gcloud beta container fleet config-management apply

Puoi anche utilizzare il comando nomos status per verificare se Config Sync è stato installato correttamente. Un'installazione valida senza problemi ha lo stato PENDING o SYNCED. Un'installazione non valida o incompleta ha lo stato NOT INSTALLED OPPURE NOT CONFIGURED. L'output include anche eventuali errori segnalati.

Controllo degli accessi basato sui ruoli (RBAC) e autorizzazioni

Config Sync include carichi di lavoro con privilegi elevati. La tabella seguente elenca le autorizzazioni per questi workload:

Componente Spazio dei nomi Account di servizio Autorizzazioni Descrizione
Operatore ConfigManagement config-management-system config-management-operator cluster-admin ConfigManagement Operator installa gli altri componenti in questa tabella. Alcuni di questi componenti richiedono autorizzazioni di amministratore del cluster, quindi anche ConfigManagement Operator le richiede.
Config Sync config-management-system Per informazioni sulle autorizzazioni richieste, consulta Autorizzazioni di sincronizzazione della configurazione.

Richieste di risorse

La sezione seguente elenca le richieste di risorse per Config Sync.

La tabella seguente elenca i requisiti delle risorse Kubernetes per i componenti di Config Sync. Per ulteriori informazioni, consulta Gestire le risorse per i container nella documentazione di Kubernetes.

Non vengono creati tutti i componenti elencati. Le seguenti condizioni determinano la pianificazione di ogni componente:

  • config-management-operator è installato quando Config Sync è abilitato.
  • reconciler-manager è installato quando Config Sync è abilitato.
  • admission-webhook viene installato quando è attiva la prevenzione del drift.
  • un reconciler è installato per ogni RootSync e RepoSync.
  • otel-collector è installato quando Config Sync è abilitato.

Per scoprire di più su questi componenti, consulta la sezione Architettura di Config Sync.

1,18

Nome deployment Richiesta di CPU (m) per replica Richiesta di memoria (Mi) per replica
config-management-operator 100 200
resource-group-controller-manager 110 300
admission-webhook1 10 100
otel-collector 200 400
reconciler-manager 20 150
reconciler (uno per RootSync e RepoSync) Per informazioni dettagliate, consulta il deployment del riconciliatore.

1 Il webhook di ammissione ha due repliche, quindi quando calcolhi le richieste totali di risorse, devi raddoppiare il valore se utilizzi il webhook di ammissione. Il webhook di ammissione è disattivato per impostazione predefinita.

1,17

Nome deployment Richiesta di CPU (m) per replica Richiesta di memoria (Mi) per replica
config-management-operator 100 200
resource-group-controller-manager 110 300
admission-webhook1 10 100
otel-collector 200 400
reconciler-manager 20 150
reconciler (uno per RootSync e RepoSync) Per informazioni dettagliate, consulta il deployment del riconciliatore.

1 Il webhook di ammissione ha due repliche, quindi quando calcolhi le richieste totali di risorse, devi raddoppiare il valore se utilizzi il webhook di ammissione. Il webhook di ammissione è disattivato per impostazione predefinita.

1.16

Nome deployment Richiesta di CPU (m) per replica Richiesta di memoria (Mi) per replica
config-management-operator 100 200
resource-group-controller-manager 110 300
admission-webhook1 10 100
otel-collector 200 400
reconciler-manager 20 150
reconciler (uno per RootSync e RepoSync) Per informazioni dettagliate, consulta il deployment del riconciliatore.

1 Il webhook di ammissione ha due repliche, quindi quando calcolhi le richieste totali di risorse, devi raddoppiare il valore se utilizzi il webhook di ammissione. Il webhook di ammissione è disattivato per impostazione predefinita.

Deployment del riconciliatore

Per ogni oggetto RootSync e RepoSync, Config Sync crea un deployment indipendente del riconciliatore per gestire la sincronizzazione. Il deployment del riconciliatore è costituito da più container. Per scoprire di più su questi contenitori, consulta Contenitori del riconciliatore.

In Config Sync versione 1.17.0 e successive, le richieste di risorse predefinite per i riconciliatori sono diverse per i cluster Standard e Autopilot. Tutti gli altri tipi di cluster utilizzano i valori predefiniti standard.

Cluster standard

1,18

Nome del contenitore Richiesta CPU (m) Richiesta di memoria (Mi)
reconciler 50 200
otel-agent 10 100
hydration-controller (Facoltativo) 10 100
git-sync 10 16
gcenode-askpass-sidecar (Facoltativo) 10 20
helm-sync 75 128
oci-sync 25 32

1,17

Nome del contenitore Richiesta CPU (m) Richiesta di memoria (Mi)
reconciler 50 200
otel-agent 10 100
hydration-controller (Facoltativo) 10 100
git-sync 10 16
gcenode-askpass-sidecar (Facoltativo) 10 20
helm-sync 75 128
oci-sync 25 32

1.16

Nome del contenitore Richiesta CPU (m) Richiesta di memoria (Mi)
reconciler 50 200
otel-agent 10 100
hydration-controller (Facoltativo) 10 100
git-sync 10 200
gcenode-askpass-sidecar (Facoltativo) 10 20
helm-sync 50 256
oci-sync 10 200

Cluster Autopilot

1,18

Nome del contenitore Richiesta e limite CPU (m) Richiesta e limite di memoria (Mi)
reconciler 700 512
otel-agent 10 64
hydration-controller (Facoltativo) 200 256
git-sync 20 32
gcenode-askpass-sidecar (Facoltativo) 50 64
helm-sync 250 384
oci-sync 50 64

1,17

Nome del contenitore Richiesta e limite CPU (m) Richiesta e limite di memoria (Mi)
reconciler 700 512
otel-agent 10 64
hydration-controller (Facoltativo) 200 256
git-sync 20 32
gcenode-askpass-sidecar (Facoltativo) 50 64
helm-sync 150 256
oci-sync 50 64

1.16

Nelle versioni di Config Sync precedenti alla 1.17.0, le richieste di risorse sono le stesse per Standard e Autopilot.

Per scoprire come ignorare le richieste e i limiti delle risorse predefiniti, consulta Sostituzioni delle risorse.

Versioni di Helm e Kustomize in bundle

Config Sync sfrutta gli eseguibili Helm e Kustomize per eseguire il rendering delle configurazioni sotto il cofano. La tabella seguente fornisce un elenco delle versioni di Config Sync che supportano la funzionalità di rendering, oltre alle versioni di Helm e Kustomize in bundle.

Versioni di Config Sync Versione Helm Versione di Kustomize
1.18.0 v3.14.3 v5.3.0
1.17.1 e 1.17.3 v3.13.3 v5.3.0
1.16.3 e 1.17.0 v3.13.1 v5.1.1
1.16.1 e 1.16.2 v3.12.3 v5.1.1
1.16.0 v3.12.2 v5.1.1
1.15.3 v3.12.2 v5.1.0
Da 1.15.1 a 1.15.2 v3.11.3 v5.0.3
1.15.0 v3.11.3 v5.0.1
Da 1.11.0 a 1.14.3 v3.6.3 v4.5.2

Per informazioni sul rendering di Helm tramite Kustomize, consulta Configurare Kubernetes con Kustomize. Per informazioni sull'utilizzo dell'API Helm, consulta Sincronizzazione dei grafici Helm da Artifact Registry.

Passaggi successivi