Installa Config Sync

Con Config Sync, puoi gestire le risorse Kubernetes con la configurazione archiviati in una fonte attendibile. Config Sync supporta Git repository di dati, immagini OCI e grafici Helm come fonte di dati. Questa pagina mostra come attivare e configurare Config Sync in modo che esegua la sincronizzazione dalla repository Git. 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 sono abilitate per impostazione predefinita. Questo offre funzionalità aggiuntive come la sincronizzazione da più repository e sulla sincronizzazione delle configurazioni Kustomize e Helm.

Prima di iniziare

Prima di installare Config Sync, prepara di soddisfare i requisiti del cluster e concedere i ruoli utente corretti.

Prepara l'ambiente locale

Prepara il tuo ambiente locale completando le seguenti attività:

  1. Crea o assicurati di avere accesso a una fonte attendibile. È qui che e aggiungi le configurazioni con cui si sincronizza Config Sync. Per scoprire di più su come impostare le configurazioni e la fonte di riferimento, consulta una delle seguenti guide:
  2. Installa e inizializza Google Cloud CLI, che fornisce il comando gcloud e nomos. Se utilizzi Cloud Shell, Google Cloud CLI è preinstallato. Se in precedenza hai installato Google Cloud CLI, per ricevere l'ultima versione eseguendo gcloud components update.

  3. Abilita l'API GKE Enterprise.

    Abilita l'API GKE Enterprise

Requisiti per i cluster

Per utilizzare Config Sync, il cluster deve soddisfare i seguenti requisiti:

  • Deve essere una versione Google Kubernetes Engine (GKE) Enterprise piattaforma e versione supportate.

  • (Facoltativo) Se utilizzi i cluster GKE, assicurati che Identità carico di lavoro è in un bucket con il controllo delle versioni attivo. Nei cluster Autopilot è abilitato Workload Identity per impostazione predefinita.

  • Dispone delle autorizzazioni di scrittura delle metriche corrette per consentire a Config Sync di inviare le metriche a Cloud Monitoring.

  • Se vuoi eseguire l'upgrade automatico della versione di Config Sync, assicurati che Il cluster GKE è registrato in un canale di rilascio. Config Sync tratta un cluster che non utilizza un canale di rilascio GKE come usando il canale di rilascio Stabile.

  • Se vuoi utilizzare un cluster GKE privato, configurare Cloud NAT per consentire il traffico in uscita di nodi GKE privati. Per maggiori dettagli, vedi Configurazione GKE di esempio. In alternativa, puoi attivare Accesso privato Google a connettersi all'insieme di indirizzi IP esterni utilizzati API e servizi Google.

  • Se vuoi utilizzare un account di servizio IAM quando concedi a Config Sync l'accesso alla tua fonte attendibile, devi includere l'ambito di sola lettura ambiti di accesso dei nodi nel cluster per Cloud Source Repositories.

    Puoi aggiungere l'ambito di sola lettura includendo cloud-source-repos-ro nel Elenco --scopes specificato al momento della creazione del cluster o utilizzando cloud-platform ambito 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 appropriato mentre utilizzando lo stesso cluster. L'ambito predefinito di gke-default non include cloud-source-repos-ro.

  • Se hai requisiti rigidi per il firewall VPC che bloccano il traffico non necessario, Crea 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 si sincronizza correttamente, con nomos status che 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.

  • Config Sync deve essere eseguito su un pool di nodi amd64. Backend di Config Sync le immagini container dei componenti vengono create, distribuite e testate solo per dell'architettura della macchina amd64. Se un componente di Config Sync è pianificato su un Al nodo ARM viene riscontrato l'errore exec format e si arresta in modo anomalo.

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

Inoltre, se il tuo cluster è un cluster Autopilot, che Autopilot regola i requisiti delle risorse container per soddisfare le seguenti regole:

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

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 cluster GKE o di cluster esterni a Google Cloud ora sono registrati in un parco. Se prevedi di utilizzare nella console Google Cloud, puoi registrare i cluster GKE configurare Config Sync.

Installazione di Config Sync

Nelle sezioni seguenti, concedi l'accesso a Config Sync a uno dei seguenti fonti attendibili:

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

Concedi l'accesso a Git

Config Sync ha bisogno dell'accesso di sola lettura al tuo repository Git può leggere le configurazioni impegnate nel repository e applicarle cluster.

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

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

Config Sync supporta i seguenti meccanismi per l'autenticazione:

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

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

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

  1. Elenca tutti i repository:

    gcloud source repos list

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

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

    Devi utilizzare questo URL quando configurare Config Sync sezione successiva. Se configuri Config Sync utilizzando Console Google Cloud, aggiungi l'URL nel campo URL. Se configurare Config Sync utilizzando Google Cloud CLI, aggiungi l'URL al campo syncRepo del file di configurazione.

Coppia di chiavi SSH

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

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

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

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

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

    Sostituisci quanto segue:

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

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

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

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

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

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

  4. (Consigliato) Per configurare il controllo degli host conosciuti mediante l'autenticazione SSH: puoi aggiungere la chiave host noti al campo data.known_hosts nella git_creds secret. Per disattivare il controllo di known_hosts, puoi rimuovere il componente Campo known_hosts del secret. Per aggiungere la chiave host nota, esegui:

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

    Poi, in data, aggiungi la voce hosts:

    known_hosts: KNOWN_HOSTS_KEY

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

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

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

    Sostituisci quanto segue:

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

File dei cookie

La procedura per acquisire un cookiefile dipende dalla configurazione del tuo repository Git. Per un esempio, vedi Genera credenziali statiche nella documentazione di Cloud Source Repositories. In genere le credenziali vengono memorizzate nel file .gitcookies di casa tua o potrebbero esserti fornite da un amministratore della sicurezza.

Per usare un cookiefile, completa i seguenti passaggi:

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

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

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

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

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

    Sostituisci quanto segue:

    • /path/to/COOKIEFILE: il tipo appropriato percorso e nome file
    • HTTPS_PROXY_URL: l'URL del proxy HTTPS che hai da usare per comunicare con il repository Git

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

Token

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

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

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

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

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

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

    Sostituisci quanto segue:

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

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

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

    Sostituisci quanto segue:

    • USERNAME: il nome utente che vuoi utilizzare.
    • TOKEN: il token che hai creato nel passaggio precedente.
    • HTTPS_PROXY_URL: l'URL del proxy HTTPS che hai durante la comunicazione con il repository Git.

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

Account di servizio Google

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

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

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

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

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

    • Concedi l'autorizzazione specifica del repository quando vuoi che gli account di servizio avere diversi livelli di accesso per ogni repository nel tuo progetto.

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

  3. Se configuri Config Sync utilizzando la console Google Cloud, seleziona Workload Identity (Identità carico di lavoro) come Authentication Type (Tipo di autenticazione), quindi aggiungi il tuo l'indirizzo email dell'account di servizio.

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

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

    Se utilizzi cluster registrati in un parco risorse, devi creare l'associazione dei criteri una volta per ogni parco risorse. Tutti i cluster registrati in un parco risorse condividono lo stesso pool di identità per carichi di lavoro. Con il concetto di flotta identicità, se aggiungi il criterio IAM all'account di servizio Kubernetes in uno cluster, quindi l'account di servizio Kubernetes dello stesso spazio dei nomi anche altri cluster nello stesso parco risorse ricevono lo stesso .

    Questa associazione consente all'account di servizio Kubernetes di Config Sync fungere da account di servizio Google:

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

Sostituisci quanto segue:

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

Account di servizio predefinito Compute Engine

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

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

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

La selezione di Google Cloud Repository o gcenode consente di utilizzare Account di servizio predefinito Compute Engine. Devi concedere ai Ruolo IAM Lettore Cloud Source Repositories (roles/source.reader) all'account di servizio predefinito di Compute Engine. Per ulteriori informazioni i ruoli e le autorizzazioni di Cloud Source Repositories, consulta Concedi le autorizzazioni per visualizzare i repository.

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

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

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

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

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

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

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

  • Account di servizio predefinito Compute Engine (gcenode)

Account di servizio Kubernetes

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

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

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

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

    • Concedi l'autorizzazione specifica del repository quando vuoi che gli account di servizio avere diversi livelli di accesso per ogni repository nel tuo progetto.

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

    Sostituisci quanto segue:

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

Account di servizio Google

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

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

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

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

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

    • Concedi l'autorizzazione specifica del repository quando vuoi che gli account di servizio avere diversi livelli di accesso per ogni repository nel tuo progetto.

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

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

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

Sostituisci quanto segue:

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

Account di servizio predefinito Compute Engine

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

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

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

    Sostituisci PROJECT_ID con l'ID progetto della tua organizzazione e sostituisci PROJECT_NUMBER con del progetto.

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

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

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

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

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

Token

Crea un secret con un nome utente e una password di un repository Helm:

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

Sostituisci quanto segue:

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

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

Account di servizio Kubernetes

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

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

    • Concedi l'autorizzazione a livello di progetto se le stesse autorizzazioni si applicano a tutti repository di codice sorgente all'interno 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 del repository quando vuoi che gli account di servizio avere diversi livelli di accesso per ogni repository nel tuo progetto.

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

    Sostituisci quanto segue:

    • PROJECT_ID: ID progetto dell'organizzazione.
    • FLEET_HOST_PROJECT_ID: se utilizzi GKE Workload Identity, uguale a PROJECT_ID. Se utilizzi un parco risorse Workload Identity, si tratta dell'ID progetto del parco risorse che il tuo in cui è registrato un cluster.
    • KSA_NAME: l'account di servizio Kubernetes per riconciliatore.
      • Per i repository root, se il nome RootSync è root-sync, usa root-reconciler. Altrimenti, usa root-reconciler-ROOT_SYNC_NAME.
    • REPOSITORY: l'ID del repository.
    • LOCATION: a livello di una o più regioni del repository.

Account di servizio Google

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

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

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

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

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

    • Concedi l'autorizzazione specifica del repository quando vuoi che gli account di servizio avere diversi livelli di accesso per ogni repository nel tuo progetto.

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

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

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

Sostituisci quanto segue:

  • PROJECT_ID: ID progetto dell'organizzazione.
  • FLEET_HOST_PROJECT_ID: se utilizzi GKE Workload Identity, uguale a PROJECT_ID. Se utilizzi un parco risorse Workload Identity, si tratta dell'ID progetto del parco risorse che il tuo in cui è registrato un cluster.
  • GSA_NAME: l'account di servizio Google personalizzato che vuoi utilizzare per connetterti ad Artifact Registry. L'account di servizio deve avere il ruolo IAM Artifact Registry Reader (roles/artifactregistry.reader).
  • KSA_NAME: l'account di servizio Kubernetes per riconciliatore.
    • Per i repository root, se il nome RootSync è root-sync, usa root-reconciler. Altrimenti, usa root-reconciler-ROOT_SYNC_NAME.
  • REPOSITORY: l'ID del repository.
  • LOCATION: a livello di una o più regioni del repository.

Account di servizio predefinito Compute Engine

Se archivi il grafico Helm in Artifact Registry e il tuo cluster è GKE con Workload Identity disabilitato, puoi usare gcenode come di autenticazione. Config Sync utilizza l'account di servizio predefinito di Compute Engine. Devi concedere il tuo account di servizio predefinito Compute Engine con accesso in lettura ad Artifact Registry. Potresti dover concedere all'accesso storage-ro ambito per concedere le autorizzazioni di sola lettura per eseguire il pull delle immagini.

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

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

    Sostituisci PROJECT_ID con l'ID progetto della tua organizzazione e sostituisci PROJECT_NUMBER con del progetto.

Configura Config Sync

In questa sezione configurerai le impostazioni per il repository principale. Se la sincronizzazione con un repository Git, puoi utilizzare la console Google Cloud il processo 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 usare i comandi kubectl per modificare root-sync e aggiungere configurazioni aggiuntive di Config Sync. Per saperne di più, vedi Configura 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 le singole registra automaticamente i cluster 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 abilita Config Sync per eseguire l'upgrade automatico delle versioni o seleziona Upgrade manuali per gestire autonomamente la versione di Config Sync. Per saperne di più su come funzionano gli upgrade automatici, consulta Esegui 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 del parco risorse.
  5. Se installi Config Sync su singoli cluster, nel 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 Abilitato 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 il deployment di un pacchetto in un cluster da una fonte attendibile. Puoi eseguire il deployment o eseguire il deployment di pacchetti diversi in cluster diversi. Puoi modificare un pacchetto dopo il deployment, ad eccezione di alcune impostazioni come il nome del pacchetto e il tipo di sincronizzazione. Per ulteriori informazioni, vedi 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 dei pacchetti, 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 seleziona il tipo di origine e fai clic su Continua.

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

  6. Nel campo Tipo di sincronizzazione, scegli Sincronizzazione con ambito cluster o Sincronizzazione con ambito spazio dei nomi come il tipo di sincronizzazione.

    La sincronizzazione con ambito cluster crea un oggetto RootSync, mentre la sincronizzazione con ambito spazio dei nomi crea un oggetto RepoSync. Per ulteriori informazioni su questi oggetti, consulta Architettura di Config Sync.

  7. Nella sezione Origine, completa i seguenti passaggi:

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

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

    • Per le origini ospitate in un'immagine OCI, compila 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, rispetto alla directory radice, come Directory.

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

    1. Seleziona un Tipo di autenticazione. Config Sync richiede l'accesso di sola lettura a la tua fonte attendibile per leggere i file di configurazione nell'origine e applicarli ai cluster. A meno che la tua 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 Immagine OCI o grafico Helm (solo gcloud CLI). Scegli lo stesso tipo di autenticazione che hai configurato durante l'installazione Config Sync:

      • Nessuna: non viene utilizzata l'autenticazione.
      • SSH: esegui l'autenticazione mediante una coppia di chiavi SSH.
      • Cookiefile: esegui l'autenticazione utilizzando un cookiefile.
      • Token: esegui l'autenticazione utilizzando un token di accesso o una password.
      • Google Cloud Repository: utilizza un account di servizio Google per accedere a il repository Cloud Source Repositories. Seleziona questa opzione solo se Workload Identity non è abilitato nel tuo cluster.
      • Identità carico di lavoro: utilizza un account di servizio Google per accedere a un il repository Cloud Source Repositories.

    2. Inserisci un numero in secondi per impostare il Tempo di attesa sincronizzazione, che determina tempo che Config Sync attende tra un tentativo e l'altro per eseguire il pull dalla fonte attendibile.

    3. Inserisci un URL del proxy Git per il proxy HTTPS da utilizzare quando comunicando con la fonte dei dati.

    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 si desidera.

  9. Fai clic su Esegui il deployment del pacchetto.

    Si aprirà la pagina Pacchetti di Config Sync. Dopo alcune minuti, dovresti vedere Sincronizzato in Stato sincronizzazione per il cluster che hai configurato.

gcloud

Prima di continuare, assicurati di avere ha 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 o utilizzando un manifest esistente. L'utilizzo di un manifest esistente devi 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 seguito utilizzi Comandi kubectl per la configurazione. Puoi anche impostare il campo spec.configSync.enabled solo come true e ometti i campi facoltativi. Dopodiché potrai utilizzare i comandi kubectl in un secondo momento per creare oggetti RootSync aggiuntivi o RepoSync che puoi gestire completamente con 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: rimuovi il commento al campo e impostalo su auto per configurare l'upgrade automatico di Config Sync. Imposta su manual per eseguire manualmente l'upgrade di Config Sync. La il valore predefinito è manual. Questo flag è supportato solo per GKE su cluster Google Cloud. Per utilizzare questo campo, potresti dover aggiornare gcloud CLI eseguendo gcloud components update.

    • SOURCE_TYPE: aggiungi git per la sincronizzazione da un repository Git, oci per sincronizzare da un'immagine OCI o helm per sincronizzare 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 consente di organizzare le configurazioni nel modo più pratico 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 estrai le immagini in base a TAG o DIGEST. Specifica TAG o DIGEST nel PACKAGE_NAME:

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

    • REVISION: la revisione Git (tag o hash) da sincronizzare da cui proviene. Questo campo è facoltativo e il valore predefinito è HEAD. A partire da Config Sync versione 1.17.0, puoi specificare anche un il nome del ramo nel campo syncRev. Quando si utilizza un hash nella versione 1.17.0 o versioni 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 da Config Sync versione 1.17.0, ti consigliamo di utilizzare lo syncRev per specificare un nome ramo per semplicità. Se syncRev e il campo syncBranch sono specificati, syncRev richiede precedenza su syncBranch.

    • SECRET_TYPE: uno dei seguenti secretTypes:

      git

      • none: non utilizzare l'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 un Cloud Source Repositories. Se selezioni questa opzione di autenticazione, dovrai creare un'associazione di criteri IAM hai terminato la configurazione di Config Sync. Per maggiori dettagli, consulta le della account di servizio Concedi a Config Sync l'accesso di sola lettura a Git .
      • gcenode: utilizza un account di servizio Google per accedere a un Cloud Source Repositories. Seleziona questa opzione solo se Workload Identity non è abilitato nel tuo cluster.

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

      oci

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

      helm

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

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

    • METRICS_EMAIL: l'email di Google Cloud Account di servizio (GSA) utilizzato per esportare le metriche di Config Sync in e configurazione in Cloud Monitoring. La console deve avere il Writer metriche Monitoring (roles/monitoring.metricWriter) Ruolo IAM. L'account di servizio Kubernetes default nello spazio dei nomi config-management-monitoring deve essere associati a Gboard.

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

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

    Per un elenco completo dei campi che puoi aggiungere al campo spec: consulta i campi dei campi.

    Utilizza 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'utente registrato con le impostazioni di Config Sync che vuoi utilizzare
    • PROJECT_ID: il tuo ID progetto
    • CONFIG_YAML_PATH: il percorso 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 configurala 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. Lo puoi trovare con gcloud container fleet memberships list.
    • CONFIG_YAML_PATH: il percorso apply-spec.yaml file.
    • PROJECT_ID: il tuo ID progetto.

Terraform

Per ogni cluster per cui vuoi configurare Config Sync, applica un blocco di risorse google_gkehub_feature_membership che contiene 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 delle iscrizioni.
  • VERSION: (facoltativo) il numero di versione di Config Sync. Deve essere impostato sulla versione 1.17.0 o successiva. Se viene lasciato vuoto, viene utilizzata 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 che vuoi sincronizzare.
  • SECRET: il tipo di autenticazione segreto.

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 delle iscrizioni.
  • VERSION: (facoltativo) il numero di versione di Config Sync. Se viene lasciato vuoto, viene utilizzata 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 che vuoi sincronizzare. Lascia vuoto per utilizzare la directory principale.
  • SECRET: il tipo di autenticazione segreto.

Ripeti questa procedura per ogni cluster che vuoi sincronizzare.

Dopo aver completato la configurazione del repository radice, puoi facoltativamente scegli di configurare la sincronizzazione da più repository, inclusi altri repository root e repository spazio dei nomi. Lo spazio dei nomi sono utili se vuoi un repository che contenga un ambito sincronizzate con uno spazio dei nomi particolare tra i cluster.

Configura valori predefiniti a livello di parco risorse

Se disponi di Google Kubernetes Engine (GKE) Enterprise abilitata, puoi Abilita e configura Config Sync come predefinito a livello di parco risorse per i tuoi cluster. Ciò significa che ogni nuovo cluster GKE su Google Cloud creati nel parco risorse Config Sync sarà abilitato sul cluster con le impostazioni che hai specificato. Tu puoi scoprire di più sulla configurazione predefinita del parco risorse in Gestire le funzionalità a livello di parco risorse.

Se utilizzi solo la console Google Cloud, puoi abilitare Config Sync per impostazione predefinita sui cluster e imposta la versione di Config Sync per il parco risorse. Se se usi Terraform, puoi abilitare Config Sync per impostazione predefinita sui tuoi cluster imposta la versione di Config Sync per il parco risorse e configura la connessione un repository Git o un repository di immagini OCI.

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

Console

  1. Nella console Google Cloud, vai alla pagina Gestore 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 che crei del parco risorse ereditano queste impostazioni.

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

  5. Seleziona Upgrade automatici (anteprima) per fare in modo che le versioni di Config Sync eseguano automaticamente l'upgrade o selezionare Upgrade manuali per gestire autonomamente la versione di Config Sync. Per saperne di più su come funzionano gli 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 risorse, fai clic su Conferma. Se non hai mai abilitato Config Sync, facendo clic su Conferma attivi anche API anthosconfigmanagement.googleapis.com.

Terraform

  1. Crea una directory per i file Terraform di configurazione predefiniti del parco risorse. Alla directory, aggiungi un file main.tf con la risorsa seguente 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 viene lasciato vuoto, viene utilizzata 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 che vuoi sincronizzare.
    • SECRET: il tipo di autenticazione segreto.

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

    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 successiva. Se viene lasciato vuoto, viene utilizzata 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 che vuoi sincronizzare. Lascia vuoto per utilizzare la directory principale.
    • SECRET: il tipo di autenticazione segreto.

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

  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 esistono già cluster che vuoi aggiornare per utilizzare il tuo Impostazioni di Config Sync, utilizza la console Google Cloud per sincronizzare il parco risorse selezionato i cluster alle impostazioni predefinite del parco risorse. In alternativa, puoi configurare manualmente ogni con le stesse impostazioni utilizzando Terraform o gcloud CLI seguendo le istruzioni per configurazione di Config Sync. Se in precedenza utilizzavi Terraform per specificare i valori predefiniti del parco risorse, utilizza gli stessi valori configmanagement e config_sync che hai utilizzato per impostare le impostazioni predefinite per cluster scelti.

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

  1. Vai a Gestione 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.

Le impostazioni predefinite di Config Sync verranno applicate a tutti i cluster selezionare. Anche se la console Google Cloud mostra solo un sottoinsieme di impostazioni, come la versione di Config Sync, tutte le impostazioni a livello di parco risorse sono sincronizzate cluster. Ad esempio, se configuri Config Sync per la sincronizzazione con un repository Git mediante Terraform, l'impostazione viene sincronizzata con i tuoi cluster, ma non viene mostrato nella console Google Cloud.

Verifica l'installazione

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

Console

Completa 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 dei cluster. Se l'installazione di Config Sync è riuscita, lo stato è Installato. Una fonte di riferimento configurata correttamente presenta lo stato 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 eseguita correttamente è SYNCED. A partire da Config Sync versione 1.18.0, l'output mostra anche quale versione di Config Sync e l'impostazione di upgrade di Config Sync.

Se visualizzi un errore dopo eseguendo il comando precedente, assicurati di aver creato git-creds Secret. Se hai creato il secret, prova a eseguire di nuovo il comando seguente:

gcloud beta container fleet config-management apply

Puoi utilizzare anche Comando nomos status per verifica se Config Sync è stato installato correttamente. Un'installazione valida senza problemi ha lo stato PENDING o SYNCED. Un indirizzo non valido o incompleto lo stato dell'installazione è NOT INSTALLED OPPURE NOT CONFIGURED. L'output include anche eventuali errori segnalati.

Autorizzazioni e controlli di accesso basati sui ruoli (RBAC)

Config Sync include carichi di lavoro con privilegi elevati. La tabella seguente le autorizzazioni per i seguenti 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 di questa tabella. Alcuni di questi componenti richiedono le autorizzazioni cluster-admin, quindi sono richieste anche da ConfigManagement Operator.
Config Sync config-management-system Per le autorizzazioni richieste, consulta Autorizzazioni di 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 Componenti di Config Sync. Per ulteriori informazioni, vedi Gestione delle risorse per i container nella documentazione di Kubernetes.

Non tutti i componenti elencati sono stati creati. Le seguenti condizioni causano componente da pianificare:

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

Per scoprire di più su questi componenti, consulta 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 maggiori dettagli, consulta Deployment del riconciliatore.

1 Il webhook di ammissione ha due repliche, quindi quando calcolare le richieste totali di risorse, devi raddoppiare il valore se utilizzano 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 maggiori dettagli, consulta Deployment del riconciliatore.

1 Il webhook di ammissione ha due repliche, quindi quando calcolare le richieste totali di risorse, devi raddoppiare il valore se utilizzano 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 maggiori dettagli, consulta Deployment del riconciliatore.

1 Il webhook di ammissione ha due repliche, quindi quando calcolare le richieste totali di risorse, devi raddoppiare il valore se utilizzano 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 del deployment di un riconciliatore indipendente per gestire la sincronizzazione. Deployment del riconciliatore è costituito da più container. Per scoprire di più su questi container, consulta Container 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. Tutti gli altri tipi di cluster utilizza i valori predefiniti standard.

Cluster standard

1,18

Nome container 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,17

Nome container 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 container 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,18

Nome container 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 container 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, la risorsa richiede sono le stesse per Standard e Autopilot.

Per informazioni su come eseguire l'override delle richieste e dei limiti predefiniti delle risorse, consulta override delle risorse.

Versioni Helm e Kustomize in bundle

Config Sync utilizza gli eseguibili Helm e Kustomize per eseguire il rendering dietro le quinte. La tabella seguente fornisce un elenco Le versioni di Config Sync che supportano la funzionalità di rendering, insieme alle le versioni Helm e Kustomize in bundle.

Versioni di Config Sync Versione Helm Versione 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, vedi Configura Kubernetes con Kustomize. Per informazioni sull'uso dell'API Helm, vedi Sincronizzazione dei grafici Helm da Artifact Registry.

Passaggi successivi