Installazione di 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 abilitare e configurare Config Sync in modo che venga sincronizzato dal repository principale. Config Sync è disponibile con la versione Google Kubernetes Engine (GKE) Enterprise.

Quando installi Config Sync utilizzando la console Google Cloud o Google Cloud CLI, le API RootSync e RepoSync vengono abilitate per impostazione predefinita. Questo fornisce 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 l'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. Creare una fonte attendibile o assicurati di avere accesso. Qui puoi aggiungere le configurazioni in cui Config Sync sincronizza. Per scoprire di più su come configurare le configurazioni e la sorgente di dati, 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, scarica la versione più recente eseguendo gcloud components update.

  3. Abilita l'API GKE Enterprise.

    Abilita l'API GKE Enterprise

Requisiti per i cluster

Crea o accedi a un cluster che soddisfi i seguenti requisiti:

  • Il cluster si trova su una piattaforma e una versione supportate dell'edizione Google Kubernetes Engine (GKE) Enterprise.

  • Se utilizzi cluster Autopilot, Autopilot regola i requisiti delle risorse dei container per soddisfare le seguenti regole:

    A causa di queste regole, per i cluster Autopilot, Config Sync:

  • (Facoltativo) Workload Identity è abilitato nel cluster se utilizzi cluster GKE. Workload Identity è il modo consigliato per accedere ai servizi Google Cloud dalle applicazioni in esecuzione all'interno di GKE, grazie al miglioramento delle sue proprietà di sicurezza e della sua gestibilità. Workload Identity è abilitato per impostazione predefinita nei cluster Autopilot.

  • Concedi le autorizzazioni di scrittura delle metriche corrette in modo che Config Sync possa inviare le metriche a Cloud Monitoring. Questa operazione è obbligatoria se vuoi utilizzare gli upgrade automatici.

  • Se vuoi eseguire l'upgrade automatico della versione di Config Sync, assicurati che il cluster GKE sia registrato in un canale di rilascio. Un cluster che non utilizza canali di rilascio di GKE viene considerato come un cluster utilizzando il canale di rilascio stabile.

  • Se vuoi utilizzare un cluster GKE privato, configura Cloud NAT per consentire il traffico in uscita dai nodi GKE privati. Per maggiori dettagli, consulta Esempio di configurazione di GKE. In alternativa, puoi abilitare l'accesso privato Google per connetterti al gruppo di indirizzi IP esterni utilizzati dalle API e dai servizi Google.

  • Se vuoi utilizzare un account di servizio Google quando concedi l'accesso a Config Sync alla tua origine di riferimento, devi includere l'ambito di sola lettura negli ambiti di accesso per i nodi nel cluster per Cloud Source Repositories.

    Puoi aggiungere l'ambito di sola lettura includendo cloud-source-repos-ro nell'elenco --scopes specificato al momento della creazione del cluster oppure utilizzando l'ambito cloud-platform al momento della creazione del cluster. Ad esempio:

    gcloud container clusters create CLUSTER_NAME --scopes=cloud-platform

    Non puoi modificare gli ambiti di accesso dopo aver creato un pool di nodi. Tuttavia, puoi creare un nuovo pool di nodi con l'ambito di accesso corretto utilizzando lo stesso cluster. L'ambito gke-default predefinito non include cloud-source-repos-ro.

  • Se hai requisiti rigidi per il firewall VPC che bloccano il traffico non necessario, devi creare regole firewall per consentire il seguente traffico sui cluster GKE pubblici:

    • TCP: consenti il traffico in entrata e in uscita sulle porte 53 e 443

    • UDP: consenti il traffico in uscita sulla porta 53

    Se non includi queste regole, Config Sync non viene sincronizzato correttamente e nomos status segnala il seguente errore:

    Error: KNV2004: unable to sync repo Error in the git-sync container

    Puoi saltare questi passaggi se utilizzi un cluster GKE privato.

  • Devi eseguire Config Sync su un pool di nodi amd64. Le immagini container del componente di backend Config Sync vengono create, distribuite e testate solo per l'architettura della macchina amd64. Se un componente di Config Sync viene pianificato su un nodo Arm, si verifica l'errore exec format e si arresta in modo anomalo.

    Se nel cluster sono presenti nodi Arm64, aggiungi uno o più nodi amd64 al cluster e, se non utilizzi un cluster GKE, aggiungi un'incompatibilità ai nodi Arm64 per evitare di pianificare pod sui nodi arm64 senza una tolleranza specifica. I nodi di gruppo GKE hanno già un'incompatibilità predefinita, quindi non è necessario aggiungerne una.

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 cluster GKE o i cluster esterni a Google Cloud siano registrati in un parco risorse ora. 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 richiede l'accesso di sola lettura al repository Git per poter leggere le configurazioni di cui è stato eseguito il commit nel repository e applicarle ai cluster.

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

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

Config Sync supporta i seguenti meccanismi per l'autenticazione:

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

Il meccanismo che scegli dipende da ciò che supporta il tuo repository. In genere, si consiglia di utilizzare una coppia di chiavi SSH. GitHub e Bitbucket supportano entrambi l'uso di una coppia di chiavi SSH. Tuttavia, se utilizzi un repository in Cloud Source Repositories, ti consigliamo di usare un account di servizio Google perché il processo è più semplice. Se la tua organizzazione ospita il repository e non sai quali metodi di autenticazione sono supportati, contatta l'amministratore.

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

  1. Elenca tutti i repository:

    gcloud source repos list

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

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

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

Coppia di chiavi SSH

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

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

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

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

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

    Sostituisci quanto segue:

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

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

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

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

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

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

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

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

    Quindi, in data, aggiungi la voce host noti:

    known_hosts: KNOWN_HOSTS_KEY

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

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

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

    Sostituisci quanto segue:

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

File dei cookie

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

Per usare un cookiefile, completa i seguenti passaggi:

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

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

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

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

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

    Sostituisci quanto segue:

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

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

Token

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

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

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

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

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

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

    Sostituisci quanto segue:

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

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

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

    Sostituisci quanto segue:

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

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

Account di servizio Google

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

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

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

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

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

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

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

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

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

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

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

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

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

Sostituisci quanto segue:

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

Account di servizio predefinito Compute Engine

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

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

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

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

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

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

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

Config Sync ha bisogno dell'accesso di sola lettura all'immagine OCI archiviata in Artifact Registry in modo che possa leggere le configurazioni incluse nell'immagine e applicarle ai tuoi cluster.

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

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

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

  • Account di servizio predefinito di Compute Engine (gcenode)

Account di servizio Kubernetes

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

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

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

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

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

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

    Sostituisci quanto segue:

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

Account di servizio Google

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

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

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

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

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

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

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

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

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

Sostituisci quanto segue:

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

Account di servizio predefinito Compute Engine

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

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

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

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

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

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

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

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

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

Token

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

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

Sostituisci quanto segue:

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

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

Account di servizio Kubernetes

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

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

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

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

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

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

    Sostituisci quanto segue:

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

Account di servizio Google

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

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

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

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

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

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

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

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

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

Sostituisci quanto segue:

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

Account di servizio predefinito Compute Engine

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

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

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

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

Configura Config Sync

In questa sezione configurerai le impostazioni per il repository radice. Se esegui la sincronizzazione con un repository Git, puoi utilizzare la console Google Cloud per guidarti nella 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 denominato root-sync. Puoi utilizzare i comandi kubectl per modificare root-sync e aggiungere ulteriori configurazioni di Config Sync. Per saperne 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, selezionando i singoli cluster questi vengono registrati automaticamente nel parco risorse.

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

    Vai a Configurazione

  2. Fai clic su Installa Config Sync.
  3. Seleziona Upgrade automatici (Anteprima) per abilitare Config Sync per eseguire automaticamente l'upgrade delle versioni oppure seleziona Upgrade manuali per gestire autonomamente la versione di Config Sync. Per ulteriori informazioni su come funzionano gli upgrade automatici, consulta Eseguire l'upgrade di Config Sync.
  4. In Opzioni di installazione, seleziona una delle seguenti opzioni:
    • Installa Config Sync sull'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 nel parco risorse.
  5. Se stai installando Config Sync su singoli cluster, nella tabella Cluster disponibili seleziona quelli su cui vuoi installare Config Sync.
  6. Fai clic su Installa Config Sync. Dopo alcuni minuti nella scheda Impostazioni dovresti vedere Abilitato nella colonna Stato per i cluster del parco risorse.

Deployment di un pacchetto

Dopo aver registrato i cluster, puoi eseguire il deployment di un pacchetto da una fonte attendibile al cluster di Config Sync. Puoi eseguire il deployment di un pacchetto in più cluster alla volta e aggiungere più pacchetti a un singolo cluster.

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 in cui vuoi eseguire il deployment di un pacchetto, quindi fai clic su Continua.

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

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

  6. Nella sezione Origine, completa i seguenti campi:

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

      1. Inserisci un Nome pacchetto, che identifica l'oggetto RootSync o RepoSync.
      2. Inserisci l'URL del repository Git che stai utilizzando come fonte attendibile come URL repository.
      3. (Facoltativo) Aggiorna il campo Revisione per verificare se non stai utilizzando il valore predefinito di HEAD.
      4. (Facoltativo) Aggiorna il campo Percorso se non vuoi eseguire la sincronizzazione dal repository principale.
      5. (Facoltativo) Aggiorna il campo Ramo se non utilizzi il ramo main predefinito.

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

      1. Inserisci l'URL dell'immagine OCI che stai utilizzando come fonte attendibile come immagine.
      2. Inserisci il percorso della directory da cui eseguire la sincronizzazione, relativo alla directory radice, come Directory.

  7. Nel campo Tipo di sincronizzazione, scegli RootSync o RepoSync come tipo di sincronizzazione.

    Gli oggetti RootSync hanno un ambito a livello di cluster, mentre gli oggetti RepoSync sono a livello di spazio dei nomi. Per ulteriori informazioni su questi oggetti, consulta la sezione Campi RootSync e RepoSync.

  8. (Facoltativo) Espandi la sezione Impostazioni avanzate per eseguire le seguenti operazioni:

    1. Seleziona un tipo di autenticazione:

      • Nessuna: non utilizzare alcuna autenticazione.
      • SSH: utilizza una coppia di chiavi SSH.
      • Cookiefile: utilizza un cookiefile.
      • Token: utilizza un token.
      • Google Cloud Repository: utilizza un account di servizio Google per accedere a un repository Cloud Source Repositories. Seleziona questa opzione solo se Workload Identity non è abilitato 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 Tempo di attesa sincronizzazione, che determina il tempo di attesa di Config Sync tra la sincronizzazione dalla fonte attendibile.

    3. Inserisci un URL proxy Git per il proxy HTTPS da utilizzare durante la comunicazione con la fonte attendibile.

    4. Scegli Gerarchia per modificare il Formato di origine.

      Il valore predefinito Non strutturato è consigliato nella maggior parte dei casi poiché consente di organizzare la fonte di riferimento come preferisci.

  9. Fai clic su Esegui il deployment del pacchetto.

    Verrai reindirizzato alla pagina Pacchetti di Config Sync. Dopo alcuni minuti, verrà visualizzato il messaggio Sincronizzato nella colonna Stato sincronizzazione per il cluster che hai configurato.

  10. Per aggiornare un pacchetto, nella scheda Pacchetti, espandi il nome del pacchetto che vuoi modificare, quindi fai clic su Modifica.

gcloud

Prima di continuare, assicurati di aver registrato i 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 manifest apply-spec.yaml o utilizzando un manifest esistente. L'uso di un manifest esistente ti consente di configurare il cluster con le stesse impostazioni utilizzate da un altro cluster.

    Crea nuovo manifest

    Per configurare Config Sync con le 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 facoltativi spec.configSync di cui hai bisogno quando crei il manifest per poi utilizzare i comandi kubectl per la configurazione in un secondo momento. Inoltre, puoi impostare solo il campo spec.configSync.enabled su true e omettere i campi facoltativi. In seguito, potrai utilizzare i comandi kubectl per creare altri oggetti RootSync o RepoSync che puoi gestire completamente utilizzando i comandi kubectl in un secondo momento.

    # 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: imposta su auto per configurare Config Sync per l'upgrade automatico. Impostalo 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.

    • SOURCE_TYPE: aggiungi git per la sincronizzazione da un repository Git, oci per la sincronizzazione da un'immagine OCI o helm per 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 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, perché questo formato ti 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 considerato 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 estrarre le immagini utilizzando TAG o DIGEST. Specifica TAG o DIGEST nel PACKAGE_NAME:

      • Per eseguire il pull in base a TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
      • Per eseguire il pull in base a DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST

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

    • 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, ti consigliamo di utilizzare il campo syncRev per specificare il nome di un ramo per semplificare l'operazione. Se vengono 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 alcuna autenticazione.
      • ssh: utilizza una coppia di chiavi SSH.
      • cookiefile: usa 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 dopo aver completato la configurazione di Config Sync. Per maggiori dettagli, consulta la scheda dell'account di servizio Google nella sezione Concedi l'accesso di sola lettura a Git di Config Sync.
      • gcenode: utilizza un account di servizio Google per accedere a Cloud Source Repositories. Seleziona questa opzione solo se Workload Identity non è abilitato nel tuo cluster.

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

      OCI

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

      helm

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

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

    • METRICS_EMAIL: l'email dell'account di servizio Google Cloud (GSA) utilizzato per esportare le metriche di Config Sync in Cloud Monitoring. L'unità organizzativa GSA deve avere il ruolo IAM "Autore metriche di monitoraggio" (roles/monitoring.metricWriter). L'account di servizio Kubernetes default nello spazio dei nomi config-management-monitoring deve essere associato a Currents.

    • DIRECTORY: il percorso della directory da cui eseguire la sincronizzazione, relativo alla directory principale 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 Config Sync di prevenire le deviazioni rifiutando il push delle modifiche in conflitto ai cluster attivi. L'impostazione predefinita è false. Config Sync risolve sempre le deviazioni indipendentemente dal valore di questo campo.

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

    Usa 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 del cluster registrato con le impostazioni di Config Sync che vuoi utilizzare
    • PROJECT_ID: il tuo ID progetto
    • CONFIG_YAML_PATH: il percorso al file apply-spec.yaml, che contiene 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 del parco risorse che hai scelto al momento della registrazione del cluster. Puoi trovare il nome con gcloud container fleet memberships list.
    • CONFIG_YAML_PATH: il percorso del file apply-spec.yaml.
    • 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 {
     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 località del cluster esistente.
  • MEMBERSHIP_ID: l'ID di associazione dell'appartenenza.
  • VERSION: (facoltativo) il numero di versione di Config Sync. Deve essere impostato 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 autenticazione del 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 {
     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 località del cluster esistente.
  • MEMBERSHIP_ID: l'ID di associazione dell'appartenenza.
  • 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 directory root.
  • SECRET: il tipo di autenticazione del secret.

Ripeti questa procedura per ogni cluster che vuoi sincronizzare.

Dopo aver completato la configurazione del repository principale, puoi facoltativamente scegliere di configurare la sincronizzazione da più repository, compresi altri repository radice e repository dello spazio dei nomi. I repository degli spazi dei nomi sono utili se vuoi che un repository che contenga configurazioni con ambito dello spazio dei nomi venga sincronizzato con un determinato spazio dei nomi tra i cluster.

Configura impostazioni predefinite a livello di parco risorse

Se hai abilitato la versione Google Kubernetes Engine (GKE) Enterprise, puoi abilitare e configurare Config Sync come impostazione predefinita a livello di parco risorse per i tuoi cluster. Ciò significa che per ogni nuovo cluster GKE su Google Cloud creato nel parco risorse sarà abilitato Config Sync nel cluster con le impostazioni da te specificate. Per saperne di più sulla configurazione predefinita del parco risorse, consulta Gestire le funzionalità a livello di parco risorse.

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

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

Console

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

    Vai a Gestore funzionalità

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

  3. Rivedi le tue impostazioni a livello di parco risorse. Tutti i nuovi cluster creati nel parco risorse ereditano queste impostazioni.

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

  5. Seleziona Upgrade automatici (Anteprima) per attivare automaticamente le versioni di upgrade di Config Sync oppure seleziona Upgrade manuali per gestire autonomamente la versione di Config Sync. Per saperne di più su come funzionano gli upgrade automatici, vedi 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 risorse, fai clic su Conferma. Se non hai mai abilitato Config Sync, fai clic su Conferma per attivare anche l'API anthosconfigmanagement.googleapis.com.

Terraform

  1. Crea una directory per i file Terraform di configurazione predefiniti del parco risorse. A quella directory, aggiungi 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 autenticazione del secret.

    Per un elenco completo delle impostazioni supportate nel blocco git di Config Sync, consulta la documentazione di riferimento 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 impostato 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 directory root.
    • SECRET: il tipo di autenticazione del secret.

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

  2. Inizializza Terraform nella directory che hai creato:

    terraform init

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

    terraform plan

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

    terraform apply

Se hai già dei cluster che vuoi aggiornare in modo da utilizzare le impostazioni predefinite di Config Sync, utilizza la console Google Cloud per sincronizzare i cluster selezionati del parco risorse con le impostazioni predefinite del parco risorse. In alternativa, puoi configurare manualmente ogni cluster con le stesse impostazioni utilizzando Terraform o gcloud CLI seguendo le istruzioni per configurare Config Sync. Se in precedenza hai utilizzato Terraform per specificare i valori predefiniti del parco risorse, usa lo stesso blocco 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 in tutto il parco risorse:

  1. Vai a Gestione funzionalità:

    Vai a Gestore funzionalità: Config Sync

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

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

Le impostazioni predefinite di Config Sync verranno applicate a tutti i cluster selezionati. Anche se la console Google Cloud mostra solo un sottoinsieme di impostazioni, ad esempio 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 la sincronizzazione con un repository Git utilizzando Terraform, l'impostazione viene sincronizzata con i tuoi cluster, ma non viene visualizzata nella console Google Cloud.

Verifica l'installazione

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

Console

Procedi con i seguenti passaggi:

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

    Vai a Configurazione

  2. Nella scheda Pacchetti, controlla la colonna Stato sincronizzazione nella tabella del cluster. Lo stato di un'installazione riuscita di Config Sync è Installato. Lo stato di una fonte attendibile configurata correttamente è Sincronizzato.

gcloud

Esegui questo comando:

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

Sostituisci PROJECT_ID con l'ID del progetto.

Lo stato di un'installazione riuscita è SYNCED. A partire da Config Sync versione 1.18.0, l'output mostra anche la versione di Config Sync installata e l'impostazione di upgrade di Config Sync.

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

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 O NOT CONFIGURED. L'output include anche eventuali errori segnalati.

Autorizzazioni e controlli dell'accesso basati sui ruoli (RBAC)

Policy Controller, Config Sync e Config Controller includono carichi di lavoro con privilegi elevati. La seguente tabella elenca le autorizzazioni per questi carichi di lavoro:

Componente Spazio dei nomi Account di servizio Autorizzazioni Descrizione
Operatore ConfigManagement config-management-system config-management-operator amministratore-cluster L'operatore ConfigManagement installa gli altri componenti in questa tabella. Alcuni di questi componenti richiedono le autorizzazioni cluster-admin, quindi sono richieste anche da ConfigManagement.
Config Sync config-management-system Per le autorizzazioni richieste, vedi Autorizzazioni Config Sync.

Richieste di risorse

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

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

Non tutti i componenti elencati sono stati creati. Le seguenti condizioni causano la pianificazione di ogni componente:

  • config-management-operator viene installato quando è abilitato Config Sync.
  • reconciler-manager viene installato quando è abilitato Config Sync.
  • L'app admission-webhook è installata quando è attiva la prevenzione delle derivazioni.
  • È installato un reconciler per ogni RootSync e RepoSync.
  • otel-collector viene installato quando è abilitato Config Sync.

Per saperne di più su questi componenti, consulta Architettura di Config Sync.

1,17

Nome deployment Richiesta di CPU (m) per replica Richiesta di memoria (Mi) per replica
config-management-operator 100 100
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 maggiori dettagli, consulta la sezione Deployment della riconciliazione.

1 Il webhook di ammissione ha due repliche, quindi quando calcoli 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 100
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 maggiori dettagli, consulta la sezione Deployment della riconciliazione.

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

1,15

Nome deployment Richiesta di CPU (m) per replica Richiesta di memoria (Mi) per replica
config-management-operator 100 100
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 maggiori dettagli, consulta la sezione Deployment della riconciliazione.

1 Il webhook di ammissione ha due repliche, quindi quando calcoli 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 riconciliazione

Per ogni oggetto RootSync e RepoSync, Config Sync crea un deployment del riconciliazione indipendente per gestire la sincronizzazione. Il deployment del riconciliazioneer consiste di più container. Per scoprire di più su questi container, consulta Contenitori di riconciliazione.

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. Per tutti gli altri tipi di cluster vengono usati i valori predefiniti standard.

Cluster standard

1,17

Nome contenitore Richiesta di 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 contenitore Richiesta di 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

1,15

Nome contenitore Richiesta di 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,17

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

1,15

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

Per scoprire come eseguire l'override delle richieste e dei limiti predefiniti per le risorse, vedi Override delle risorse.

Versioni di Helm e Kustomize in bundle

Config Sync utilizza gli eseguibili Helm e Kustomize per il rendering delle configurazioni più avanzate. La seguente tabella fornisce un elenco delle versioni di Config Sync che supportano la funzionalità di rendering, insieme alle versioni di Helm e Kustomize in bundle.

Versioni di Config Sync Versione Helm Versione Kustomize
1.16.0 e versioni successive v3.11.3 v5.1.1
Da 1.15.0 a 1.15.3 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 la pagina relativa alla sincronizzazione dei grafici Helm da Artifact Registry.

Passaggi successivi