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
sono abilitate per impostazione predefinita. Questo
offre funzionalità aggiuntive come la sincronizzazione da più repository
e la sincronizzazione delle configurazioni 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 il tuo ambiente locale completando le seguenti attività:
- Crea o assicurati di avere accesso a una fonte attendibile. Qui puoi aggiungere le configurazioni con cui si sincronizza Config Sync. Per scoprire di più su come configurare le configurazioni e la fonte attendibile, consulta una delle seguenti guide:
- Installa e inizializza Google Cloud CLI, che fornisce i comandi
gcloud
enomos
. Se utilizzi Cloud Shell, Google Cloud CLI è preinstallato. Se in precedenza hai installato Google Cloud CLI, scarica l'ultima versione eseguendogcloud components update
.
Requisiti per i cluster
Per utilizzare Config Sync, il cluster deve soddisfare i seguenti requisiti:La piattaforma e la versione supportate per Google Kubernetes Engine (GKE) Enterprise devono essere.
(Facoltativo) Se utilizzi i cluster GKE, assicurati che Workload Identity sia abilitato. Nei cluster Autopilot è abilitato Workload Identity per impostazione predefinita.
Dispone delle autorizzazioni di scrittura delle metriche corrette per consentire a Config Sync di inviare metriche a Cloud Monitoring.
Se vuoi eseguire l'upgrade automatico della versione di Config Sync, assicurati che il cluster GKE sia registrato in un canale di rilascio. Config Sync considera un cluster che non utilizza un canale di rilascio GKE come se utilizzasse 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 Configurazione di GKE di esempio. In alternativa, puoi abilitare l'accesso privato Google per connetterti al set di indirizzi IP esterni utilizzato dalle API e dai servizi Google.
Se vuoi utilizzare un account di servizio IAM quando concedi a Config Sync l'accesso alla tua origine attendibile, 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'ambitocloud-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 appropriato mentre utilizzi lo stesso cluster. L'ambito predefinito di
gke-default
non includecloud-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 si sincronizza 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.
Config Sync deve essere eseguito su un pool di nodi
amd64
. Le immagini container del componente di backend di Config Sync vengono create, distribuite e testate solo per l'architettura delle macchineamd64
. Se un componente di Config Sync è pianificato su un nodo Arm, si verifica l'erroreexec 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 i pod sui nodi arm64 senza tolleranza specifica. I nodi dei gruppi GKE hanno già un'incompatibilità predefinita, quindi non è necessario aggiungerne una.
Se il tuo è un cluster Autopilot, tieni presente anche che Autopilot regola i requisiti delle risorse di container per soddisfare le seguenti regole:
- I limiti delle risorse sono impostati sullo stesso valore delle richieste di risorse.
- Le vCPU di pod sono disponibili in incrementi di 0,25 vCPU (arrotondate per eccesso).
- Il valore minimo è 250 milliCPU (mCPU).
- Il rapporto tra memoria (in GiB) e vCPU deve essere compreso tra 1 e 6,5 vCPU.
A causa di queste regole, per i cluster Autopilot, Config Sync:
- regola i limiti di override delle risorse specificati dall'utente in base alle richieste di corrispondenza.
- applica override solo se esistono una o più richieste di risorse superiori all'output regolato corrispondente dichiarato nell'annotazione o esistono una o più richieste di risorse inferiori all'input corrispondente dichiarato nell'annotazione.
Prepara il cluster
Dopo aver creato un cluster adatto, completa i seguenti passaggi:
Concedi i ruoli IAM richiesti all'utente che registra il cluster.
Se prevedi di utilizzare Google Cloud CLI per configurare Config Sync o utilizzare cluster esterni a Google Cloud, assicurati che i tuoi cluster GKE o cluster esterni a Google Cloud siano registrati in un parco risorse ora. Se prevedi di utilizzare la console Google Cloud, puoi registrare i cluster GKE durante la configurazione di Config Sync.
Installazione di Config Sync
Nelle sezioni seguenti, concedi a Config Sync l'accesso a una delle seguenti fonti attendibili:
Dopo aver concesso l'accesso, puoi configurare Config Sync.
Concedi l'accesso a Git
Config Sync ha bisogno dell'accesso di sola lettura al repository Git per poter leggere le configurazioni impegnate nel repository e applicarle ai cluster.
Se il repository non richiede l'autenticazione per l'accesso di sola lettura, puoi continuare con la configurazione di Config Sync e utilizzare none
come tipo di autenticazione. Ad esempio, se puoi esplorare il repository utilizzando un'interfaccia web senza accedere o se puoi utilizzare git
clone
per creare un clone del repository localmente senza fornire credenziali o utilizzando credenziali salvate, non devi eseguire l'autenticazione. In questo caso,
non è necessario creare un secret.
Tuttavia, la maggior parte degli utenti deve creare le credenziali perché l'accesso in lettura al proprio
repository è limitato. Se sono richieste, le credenziali vengono archiviate nel secret di git-creds
in ogni cluster registrato (a meno che non utilizzi un account di servizio Google). 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 supportano entrambi l'uso di una coppia di chiavi SSH. Tuttavia, se utilizzi un repository in Cloud Source Repositories, ti consigliamo di utilizzare un account di servizio Google, poiché il processo è più semplice. Se la tua organizzazione ospita il tuo repository e non sai quali metodi di autenticazione sono supportati, contatta il tuo amministratore.
Per utilizzare un repository in Cloud Source Repositories come repository Config Sync, completa i seguenti passaggi per recuperare l'URL di Cloud Source Repositories:
Elenca tutti i repository:
gcloud source repos list
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 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. La
chiave pubblica in genere ha un'estensione .pub
.
Per utilizzare una coppia di chiavi SSH, completa i seguenti passaggi:
Crea 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 della sicurezza ti fornisce una coppia di chiavi. Puoi utilizzare un'unica 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.
Configura il tuo repository in modo che riconosca la chiave pubblica appena creata. Fai riferimento alla documentazione del tuo provider host Git. Per praticità, sono incluse le istruzioni per alcuni provider host Git popolari:
- Cloud Source Repositories
- Bitbucket
- GitHub Ti consigliamo di creare chiavi di deployment separate per fornire l'accesso di sola lettura a un singolo repository GitHub.
- GitLab
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
).(Consigliato) Per configurare il controllo degli host conosciuti tramite l'autenticazione SSH, puoi aggiungere la chiave host noti al campo
data.known_hosts
nel secretgit_creds
. Per disabilitare il controllo diknown_hosts
, puoi rimuovere il campoknown_hosts
dal 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
Elimina la chiave privata dal disco locale o proteggila.
Quando configuri Config Sync e aggiungi l'URL per il tuo 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 CloudPROJECT_ID
: l'ID del progetto Google Cloud in cui si trova il repositoryREPO_NAME
: il nome del repository
File dei cookie
Il processo per l'acquisizione di un cookiefile
dipende dalla configurazione del tuo repository. Per un esempio, consulta Generare credenziali statiche nella documentazione di Cloud Source Repositories.
In genere le credenziali vengono memorizzate nel file .gitcookies
della tua home directory oppure potrebbero esserti fornite da un amministratore della sicurezza.
Per usare un cookiefile
, completa i seguenti passaggi:
Dopo aver creato e ottenuto
cookiefile
, aggiungilo a un nuovo secret nel cluster.Se non utilizzi un proxy HTTPS, crea il secret con il seguente comando:
kubectl create ns config-management-system && \ kubectl create secret generic git-creds \ --namespace=config-management-system \ --from-file=cookie_file=/path/to/COOKIEFILE
Se devi utilizzare un proxy HTTPS, aggiungilo al 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 appropriatiHTTPS_PROXY_URL
: l'URL del proxy HTTPS che utilizzi durante la comunicazione con il repository Git
Proteggi i contenuti di
cookiefile
se ti occorre ancora a livello locale. In caso contrario, eliminalo.
Token
Se la tua organizzazione non consente l'uso di chiavi SSH, potresti preferire l'utilizzo di un token. Con Config Sync, puoi utilizzare i token di accesso personale (PAT) di GitHub, i PAT di GiLab o le chiavi di deployment oppure la password per l'app di Bitbucket come token.
Per creare un secret utilizzando il tuo token, completa i seguenti passaggi:
Crea un token utilizzando GitHub, GitLab o Bitbucket:
- GitHub: crea un PAT.
Concedi al token l'ambito
repo
in modo che possa leggere da repository privati. Poiché hai associato un PAT a un account GitHub, ti consigliamo inoltre di creare un utente della macchina e associare il tuo PAT a quest'ultimo. - GitLab: crea un PAT o crea un token di deployment
- Bitbucket: Crea una password per l'app.
- GitHub: crea un PAT.
Concedi al token l'ambito
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
etoken
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 utilizzi durante la comunicazione con il repository Git.
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 fleet Workload Identity, puoi concedere a Config Sync l'accesso a un repository nello stesso progetto del tuo cluster gestito utilizzando un account di servizio Google.
Se non lo hai già, creane uno.
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, vedi 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 l'autorizzazione specifica del 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
Se configuri Config Sync utilizzando la console Google Cloud, seleziona Workload Identity come Tipo di autenticazione, quindi aggiungi l'email del tuo account di servizio.
Se configuri Config Sync utilizzando Google Cloud CLI, aggiungi
gcpserviceaccount
comesecretType
, quindi aggiungi l'email del tuo account di servizio agcpServiceAccountEmail
.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 di criteri solo una volta per parco risorse. Tutti i cluster registrati in un parco risorse condividono lo stesso pool di identità per carichi di lavoro. Grazie al concetto di identicità del parco risorse, se aggiungi il criterio IAM all'account di servizio Kubernetes in un cluster, anche l'account di servizio Kubernetes proveniente dallo stesso spazio dei nomi su altri cluster nello stesso parco risorse riceverà 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
: ID progetto dell'organizzazione.FLEET_HOST_PROJECT_ID
: se utilizzi GKE Workload Identity, il valore è lo stesso diPROJECT_ID
. Se utilizzi Workload Identity, questo è l'ID progetto del parco risorse in cui è registrato il 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 il riconciliatore.- Per i repository root, se il nome
RootSync
èroot-sync
, usaroot-reconciler
. In caso contrario, utilizzaroot-reconciler-ROOT_SYNC_NAME
. Se installi Config Sync utilizzando la console Google Cloud o Google Cloud CLI, Config Sync crea automaticamente un oggetto RootSync denominatoroot-sync
.
- Per i repository root, se il nome
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 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 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 su ruoli e autorizzazioni di Cloud Source Repositories, vedi 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 del
progetto dell'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 per poter leggere le configurazioni incluse nell'immagine e applicarle ai cluster.
Se l'immagine non richiede l'autenticazione per l'accesso di sola lettura, puoi continuare con la configurazione di Config Sync e utilizzare none
come tipo di autenticazione. Ad esempio, se l'immagine è pubblica
e può essere visualizzata da chiunque su internet, l'autenticazione non è necessaria.
Tuttavia, la maggior parte degli utenti deve creare credenziali per accedere alle immagini con restrizioni. 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 successive. Questa opzione è consigliata rispetto a gcpserviceaccount
a causa del
processo di configurazione semplificato.
Concedi il ruolo IAM Artifact Registry Reader (
roles/artifactregistry.reader
) all'account di servizio Kubernetes con il pool Workload Identity. Per ulteriori informazioni su ruoli e autorizzazioni di Artifact Registry, consulta Configurare ruoli e 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 l'autorizzazione specifica del 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
: ID progetto dell'organizzazione.FLEET_HOST_PROJECT_ID
: se utilizzi GKE Workload Identity, il valore è lo stesso diPROJECT_ID
. Se utilizzi Workload Identity, 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
RootSync
èroot-sync
, usaroot-reconciler
. In caso contrario, utilizzaroot-reconciler-ROOT_SYNC_NAME
. Se installi Config Sync utilizzando la console Google Cloud o Google Cloud CLI, Config Sync crea automaticamente un oggetto RootSync denominatoroot-sync
.
- Per i repository root, se il nome
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 del parco risorse Workload Identity,
puoi utilizzare gcpserviceaccount
come tipo di autenticazione. A partire dalla
versione 1.17.2, ti consigliamo di utilizzare invece k8sserviceaccount
. Questa opzione elimina i passaggi aggiuntivi necessari per la creazione di un account di servizio Google e dell'associazione dei criteri IAM associata.
Se non lo hai già, creane uno.
Concedi il ruolo IAM Artifact Registry Reader (
roles/artifactregistry.reader
) all'account di servizio Google. Per ulteriori informazioni su ruoli e autorizzazioni di Artifact Registry, consulta Configurare ruoli e 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 l'autorizzazione specifica del 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
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
: ID progetto dell'organizzazione.FLEET_HOST_PROJECT_ID
: se utilizzi GKE Workload Identity, il valore è lo stesso diPROJECT_ID
. Se utilizzi Workload Identity, questo è l'ID progetto del parco risorse in cui è registrato il 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 il riconciliatore.- Per i repository root, se il nome
RootSync
èroot-sync
, usaroot-reconciler
. In caso contrario, utilizzaroot-reconciler-ROOT_SYNC_NAME
. Se installi Config Sync utilizzando la console Google Cloud o Google Cloud CLI, Config Sync crea automaticamente un oggetto RootSync denominatoroot-sync
.
- Per i repository root, se il nome
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 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 lettore dell'account di servizio predefinito di Compute Engine
l'accesso ad Artifact Registry.
Concedi ad Artifact Registry l'autorizzazione di lettura per l'account di servizio Compute Engine 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 ePROJECT_NUMBER
con il numero del progetto dell'organizzazione.
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
continuare a
configurare Config Sync
e utilizzare none
come tipo di autenticazione. Ad esempio, se il repository Helm
è pubblico ed è accessibile a chiunque su internet, non è necessaria
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 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 successive. Questa opzione è consigliata rispetto a gcpserviceaccount
a causa del
processo di configurazione semplificato.
Concedi il ruolo IAM Artifact Registry Reader (
roles/artifactregistry.reader
) all'account di servizio Kubernetes con il pool Workload Identity. Per ulteriori informazioni su ruoli e autorizzazioni di Artifact Registry, consulta Configurare ruoli e 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 l'autorizzazione specifica del 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
: ID progetto dell'organizzazione.FLEET_HOST_PROJECT_ID
: se utilizzi GKE Workload Identity, il valore è lo stesso diPROJECT_ID
. Se utilizzi Workload Identity, 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
RootSync
èroot-sync
, usaroot-reconciler
. In caso contrario, utilizzaroot-reconciler-ROOT_SYNC_NAME
.
- Per i repository root, se il nome
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 del parco risorse Workload Identity,
puoi utilizzare gcpserviceaccount
come tipo di autenticazione. A partire dalla
versione 1.17.2, ti consigliamo di utilizzare invece k8sserviceaccount
. Questa opzione elimina i passaggi aggiuntivi necessari per la creazione di un account di servizio Google e dell'associazione dei criteri IAM associata.
Se non lo hai già, creane uno.
Concedi il ruolo IAM Artifact Registry Reader (
roles/artifactregistry.reader
) all'account di servizio Google. Per ulteriori informazioni su ruoli e autorizzazioni di Artifact Registry, consulta Configurare ruoli e 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 l'autorizzazione specifica del 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
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
: ID progetto dell'organizzazione.FLEET_HOST_PROJECT_ID
: se utilizzi GKE Workload Identity, il valore è lo stesso diPROJECT_ID
. Se utilizzi Workload Identity, questo è l'ID progetto del parco risorse in cui è registrato il 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 il riconciliatore.- Per i repository root, se il nome
RootSync
èroot-sync
, usaroot-reconciler
. In caso contrario, utilizzaroot-reconciler-ROOT_SYNC_NAME
.
- Per i repository root, se il nome
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 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 lettore dell'account di servizio predefinito di Compute Engine
l'accesso ad Artifact Registry. Potresti dover concedere l'ambito di accesso storage-ro
per concedere l'autorizzazione di sola lettura per eseguire il pull delle immagini.
Concedi ad Artifact Registry l'autorizzazione di lettura per l'account di servizio Compute Engine:
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 ePROJECT_NUMBER
con il numero del progetto dell'organizzazione.
Configura Config Sync
In questa sezione configurerai le impostazioni per il repository principale. Se esegui la sincronizzazione con un repository Git, puoi utilizzare la console Google Cloud per guidarti nel 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 utilizzare i comandi kubectl
per modificare root-sync
e aggiungere
altre configurazioni di Config Sync. Per scoprire di più, consulta
Configurare Config Sync con i comandi kubectl
.
Console
Installazione di Config Sync
Per installare Config Sync, tutti i cluster devono essere registrati in un parco risorse. Quando installi Config Sync nella console Google Cloud, la selezione di singoli cluster registra automaticamente questi cluster nel tuo parco risorse.
- Nella console Google Cloud, vai alla pagina Configurazione nella sezione Funzionalità.
- Fai clic su add Installa Config Sync.
- Seleziona Upgrade automatici (Anteprima) per consentire a Config Sync di eseguire l'upgrade automatico delle versioni oppure seleziona 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.
- 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.
- Se stai installando Config Sync su singoli cluster, seleziona i cluster su cui vuoi installare Config Sync nella tabella Cluster disponibili.
- 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 aver installato Config Sync, puoi configurare Config Sync per il deployment di un pacchetto in un cluster da una fonte attendibile. Puoi eseguire il deployment dello stesso pacchetto su più cluster o di pacchetti diversi in cluster diversi. Puoi modificare un pacchetto dopo averlo distribuito, ad eccezione di alcune impostazioni come nome del pacchetto e tipo di sincronizzazione. Per ulteriori informazioni, consulta la sezione Gestione dei pacchetti.
Per eseguire il deployment di un pacchetto, completa i seguenti passaggi:
Nella console Google Cloud, vai alla dashboard di Config Sync.
Fai clic su Esegui il deployment del pacchetto.
Nella tabella Seleziona cluster per il deployment dei pacchetti, seleziona il cluster in cui vuoi eseguire il deployment di un pacchetto, quindi fai clic su Continua.
Seleziona Pacchetto ospitato su Git o Pacchetto ospitato su OCI come tipo di origine, quindi fai clic su Continua.
Nella sezione Dettagli del pacchetto, inserisci un Nome pacchetto, che identifica l'oggetto RootSync o RepoSync.
Nel campo Tipo di sincronizzazione, scegli Sincronizzazione con ambito cluster o Sincronizzazione con ambito spazio dei nomi come 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.
Nella sezione Origine, completa i seguenti passaggi:
Per le origini ospitate in un repository Git, inserisci i seguenti campi:
- Inserisci come fonte attendibile l'URL del repository Git che stai utilizzando come URL del repository.
- (Facoltativo) Aggiorna il campo Revisione per verificare se non utilizzi
il valore predefinito di
HEAD
. - (Facoltativo) Aggiorna il campo Percorso se non vuoi eseguire la sincronizzazione dal repository principale.
- (Facoltativo) Aggiorna il campo Ramo se non utilizzi il ramo
main
predefinito.
Per le origini ospitate in un'immagine OCI, compila i seguenti campi:
- Inserisci l'URL dell'immagine OCI che stai utilizzando come fonte attendibile come Immagine.
- Inserisci il percorso della directory da cui eseguire la sincronizzazione relativo alla directory principale in Directory.
(Facoltativo) Espandi la sezione Impostazioni avanzate per completare le seguenti operazioni:
Seleziona un Tipo di autenticazione. Config Sync ha bisogno dell'accesso di sola lettura alla 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 in sola lettura al repository Git, all'immagine OCI o al grafico Helm (solo gcloud CLI). Scegli lo stesso tipo di autenticazione che hai configurato durante l'installazione di 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 un repository Cloud Source Repositories. Seleziona questa opzione solo se Workload Identity non è abilitato nel cluster.
- Workload Identity: utilizza un account di servizio Google per accedere a un repository Cloud Source Repositories.
Inserisci un numero in secondi per impostare il Tempo di attesa per la sincronizzazione, che determina il tempo di attesa di Config Sync tra un tentativo e l'altro di eseguire il pull dalla fonte attendibile.
Inserisci un URL del proxy Git per il proxy HTTPS da utilizzare durante le comunicazioni con la fonte attendibile.
Scegli Gerarchia per modificare il Formato di origine.
Il valore predefinito Non strutturato è consigliato nella maggior parte dei casi perché consente di organizzare la fonte di riferimento come preferisci.
Fai clic su Esegui il deployment del pacchetto.
Si aprirà la pagina Pacchetti di Config Sync. Dopo alcuni minuti, dovresti vedere Sincronizzato nella colonna Stato sincronizzazione per il cluster che hai configurato.
gcloud
Prima di continuare, assicurati di aver registrato i cluster in un parco risorse.
Attiva la funzionalità del parco risorse
ConfigManagement
:gcloud beta container fleet config-management enable
Prepara la configurazione creando un nuovo manifest
apply-spec.yaml
o utilizzando un manifest esistente. L'utilizzo 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 nuove impostazioni per il tuo 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 durante la creazione del manifest e in seguito utilizzare i comandikubectl
per la configurazione. Puoi anche impostare il campospec.configSync.enabled
solo cometrue
e omettere i campi facoltativi. In seguito, potrai utilizzare i comandikubectl
per creare oggetti RootSync aggiuntivi o RepoSync che potrai gestire completamente con i comandikubectl
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 dal campo e imposta suauto
per configurare l'upgrade automatico di Config Sync. Imposta sumanual
per eseguire manualmente l'upgrade di Config Sync. Il valore predefinito èmanual
. Questo flag è supportato solo per i cluster GKE su Google Cloud. Per utilizzare questo campo, potresti dover aggiornare gcloud CLI eseguendogcloud components update
.SOURCE_TYPE
: aggiungigit
per la sincronizzazione da un repository Git,oci
per la sincronizzazione da un'immagine OCI ohelm
per la sincronizzazione da un grafico Helm. Se non viene specificato alcun valore, il valore predefinito ègit
.FORMAT
: aggiungiunstructured
per utilizzare un repository non strutturato o aggiungihierarchy
per utilizzare un repository gerarchico. Questi valori sono sensibili alle maiuscole. Questo campo è facoltativo e il valore predefinito èhierarchy
. Ti consigliamo di aggiungereunstructured
, perché questo formato consente di organizzare le configurazioni nel modo più comodo per te.REPO
: aggiungi l'URL della fonte attendibile. Gli URL dei repository Git e Helm utilizzano il protocollo HTTPS o SSH. Ad esempio,https://github.com/GoogleCloudPlatform/anthos-config-management-samples
. Se prevedi di utilizzare SSH comesecretType
, 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 taglatest
, ma puoi recuperare le immagini in base al valoreTAG
oDIGEST
. SpecificaTAG
oDIGEST
inPACKAGE_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
- Per eseguire il pull per
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 camposyncRev
. Se utilizzi un hash nella versione 1.17.0 o successive, deve essere un hash completo e non una forma abbreviata.BRANCH
: il ramo del repository da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito èmaster
. A partire da Config Sync versione 1.17.0, ti consigliamo di utilizzare il camposyncRev
per specificare un nome ramo per semplicità. Se sono specificati sia il camposyncRev
che il camposyncBranch
,syncRev
ha la precedenza susyncBranch
.SECRET_TYPE
: uno dei seguentisecretTypes
:git
none
: non utilizzare l'autenticazione.ssh
: utilizza una coppia di chiavi SSH.cookiefile
: usa uncookiefile
.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 Account di servizio Google nella sezione Concedi a Config Sync l'accesso in sola lettura a Git.gcenode
: utilizza un account di servizio Google per accedere a Cloud Source Repositories. Seleziona questa opzione solo se Workload Identity non è abilitato nel cluster.
Per ulteriori informazioni su questi tipi di autenticazione, consulta la pagina su come concedere a Config Sync l'accesso di sola lettura a Git.
oci
none
: non usare l'autenticazionegcenode
: 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 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 cluster.gcpserviceaccount
: utilizza un account di servizio Google per accedere a un'immagine.
EMAIL
: se hai aggiuntogcpserviceaccount
comesecretType
, aggiungi l'indirizzo email del tuo account di servizio Google. Ad esempio,acm@PROJECT_ID.iam.gserviceaccount.com
.METRICS_EMAIL
: l'indirizzo email dell'account di servizio Google Cloud utilizzato per esportare le metriche di Config Sync in Cloud Monitoring. Google Cloud deve avere il ruolo IAM Writer metriche Monitoring (roles/monitoring.metricWriter
). L'account di servizio Kubernetesdefault
nello spazio dei nomiconfig-management-monitoring
deve essere associato a Gboard.DIRECTORY
: il percorso della directory da cui eseguire la sincronizzazione, relativo alla radice del repository Git. Tutte le sottodirectory della directory specificata sono incluse e sincronizzate con il cluster. Il valore predefinito è la directory radice del repository.PREVENT_DRIFT
: se impostato sutrue
, consente al webhook di ammissione Config Sync di prevenire le deviazioni rifiutando l'invio di modifiche in conflitto ai cluster attivi. L'impostazione predefinita èfalse
. Config Sync corregge sempre le deviazioni indipendentemente dal valore di questo campo.
Per un elenco completo dei campi che puoi aggiungere al campo
spec
, consulta gcloud fields.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'appartenenza del cluster registrato con le impostazioni di Config Sync che vuoi utilizzarePROJECT_ID
: il tuo ID progettoCONFIG_YAML_PATH
: il percorso del fileapply-spec.yaml
contenente le impostazioni recuperate dal cluster
Applica il file
apply-spec.yaml
. Se utilizzi un manifest esistente, devi applicare il file al cluster che vuoi configurare con le impostazioni recuperate nel comando precedente:gcloud beta container fleet config-management apply \ --membership=MEMBERSHIP_NAME \ --config=CONFIG_YAML_PATH \ --project=PROJECT_ID
Sostituisci quanto segue:
MEMBERSHIP_NAME
: il nome dell'appartenenza al parco risorse che hai scelto al momento della registrazione del cluster. Puoi trovare il nome congcloud container fleet memberships list
.CONFIG_YAML_PATH
: il percorso del tuo fileapply-spec.yaml
.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 contenga 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 esempiomain
.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 scegliere di configurare la sincronizzazione da più repository, inclusi altri repository radice e repository di spazi dei nomi. I repository dello spazio dei nomi sono utili se vuoi un repository che contiene configurazioni basate sullo spazio dei nomi sincronizzati con uno specifico spazio dei nomi tra i cluster.
Configura valori predefiniti a livello di parco risorse
Se hai abilitato la versione Google Kubernetes Engine (GKE) Enterprise, puoi abilitare e configurare Config Sync come predefinito 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 sul cluster con le impostazioni specificate. 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 tuoi cluster e impostare la versione di Config Sync per il tuo parco risorse. Se utilizzi Terraform, puoi abilitare Config Sync per impostazione predefinita sui tuoi cluster, impostare la versione di Config Sync per il tuo parco risorse e configurare la connessione al repository Git o al repository di immagini OCI.
Per configurare valori predefiniti a livello di parco risorse per Config Sync, completa i seguenti passaggi:
Console
Nella console Google Cloud, vai alla pagina Gestore funzionalità.
Nel riquadro Config Sync, fai clic su Configura.
Rivedi le tue impostazioni a livello di parco risorse. Tutti i nuovi cluster che crei nel parco risorse ereditano queste impostazioni.
(Facoltativo) Per modificare le impostazioni predefinite, fai clic su Personalizza le impostazioni del parco risorse. Nella finestra di dialogo visualizzata, procedi nel seguente modo:
Seleziona Upgrade automatici (Anteprima) per fare in modo che le versioni di Config Sync eseguano automaticamente l'upgrade oppure seleziona 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.
Se hai selezionato Upgrade manuali, nell'elenco Versione, seleziona la versione di Config Sync che vuoi utilizzare.
Fai clic su Salva modifiche.
Fai clic su Configura.
Nella finestra di dialogo di conferma Configurazione delle impostazioni del parco risorse, fai clic su Conferma. Se non hai abilitato Config Sync in precedenza, facendo clic su Conferma viene abilitata anche l'API
anthosconfigmanagement.googleapis.com
.
Terraform
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 esempiomain
.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.Inizializza Terraform nella directory che hai creato:
terraform init
Verifica che le modifiche che proponi con Terraform corrispondano al piano previsto:
terraform plan
Crea le configurazioni predefinite dei membri del parco risorse:
terraform apply
Se hai cluster che vuoi aggiornare in modo da utilizzare le impostazioni predefinite di Config Sync, utilizza la console Google Cloud per sincronizzare i cluster del parco risorse selezionati 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 la configurazione di Config Sync. Se in precedenza hai utilizzato Terraform per specificare i valori predefiniti del parco risorse, utilizza 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 nel parco risorse:
Vai a Gestione funzionalità:
Nella tabella dei cluster, seleziona i cluster che vuoi sincronizzare con le impostazioni del parco risorse.
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, come la versione di Config Sync, tutte le impostazioni a livello di parco risorse vengono sincronizzate con i cluster. Ad esempio, se configuri Config Sync per la sincronizzazione con un repository Git utilizzando Terraform, l'impostazione viene sincronizzata con i tuoi cluster, ma non viene mostrata nella console Google Cloud.
Verifica l'installazione
Dopo aver installato e configurato Config Sync, puoi verificare che l'installazione sia stata completata correttamente.
Console
Completa i seguenti passaggi:
- Nella console Google Cloud, vai alla pagina Configurazione nella sezione Funzionalità.
- 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 la versione di Config Sync installata e l'impostazione di upgrade di Config Sync.
Se visualizzi un errore dopo aver eseguito il comando precedente, assicurati di aver creato il secret git-creds
. Se hai creato il secret, prova a eseguire di nuovo 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. Lo stato di un'installazione valida
senza problemi è PENDING
o SYNCED
. Un'installazione non valida o incompleta ha lo stato NOT INSTALLED
OPPURE NOT CONFIGURED
. L'output include anche gli eventuali errori segnalati.
Autorizzazioni e controlli di accesso basati sui ruoli (RBAC)
Config Sync include 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 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 tabella seguente elenca i requisiti delle risorse Kubernetes per i componenti di 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 determinano la pianificazione di ogni componente:
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 calcoli le richieste di risorse totali, devi raddoppiare il valore se utilizzi il webhook di ammissione. Il webhook di ammissione è disattivato per impostazione predefinita.
1,17
Nome deployment | Richiesta di CPU (m) per replica | Richiesta di memoria (Mi) per replica |
---|---|---|
config-management-operator |
100 | 200 |
resource-group-controller-manager |
110 | 300 |
admission-webhook1 |
10 | 100 |
otel-collector |
200 | 400 |
reconciler-manager |
20 | 150 |
reconciler (uno per RootSync e RepoSync) |
Per maggiori dettagli, consulta Deployment del riconciliatore. |
1 Il webhook di ammissione ha due repliche, quindi quando calcoli le richieste di risorse totali, devi raddoppiare il valore se utilizzi il webhook di ammissione. Il webhook di ammissione è disattivato per impostazione predefinita.
1,16
Nome deployment | Richiesta di CPU (m) per replica | Richiesta di memoria (Mi) per replica |
---|---|---|
config-management-operator |
100 | 200 |
resource-group-controller-manager |
110 | 300 |
admission-webhook1 |
10 | 100 |
otel-collector |
200 | 400 |
reconciler-manager |
20 | 150 |
reconciler (uno per RootSync e RepoSync) |
Per maggiori dettagli, consulta Deployment del riconciliatore. |
1 Il webhook di ammissione ha due repliche, quindi quando calcoli le richieste di risorse totali, devi raddoppiare il valore se utilizzi il webhook di ammissione. Il webhook di ammissione è disattivato per impostazione predefinita.
Deployment del riconciliatore
Per ogni oggetto RootSync
e RepoSync
, Config Sync crea un
deployment di riconciliatore indipendente per gestire la sincronizzazione. Il deployment del riconciliatore
è costituito da più container. Per scoprire di più su questi container, consulta
Container del riconciliatore.
In Config Sync versione 1.17.0 e successive, le richieste di risorse predefinite per i riconciliatori sono diverse per i cluster Standard e Autopilot. Tutti gli altri tipi di cluster usano 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, le richieste di risorse 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 delle configurazioni in background. La tabella seguente fornisce un elenco delle versioni di Config Sync che supportano la funzionalità di rendering, oltre alle versioni in bundle di Helm e Kustomize.
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, consulta Configurare Kubernetes con Kustomize. Per informazioni sull'utilizzo dell'API Helm, consulta Sincronizzazione dei grafici Helm da Artifact Registry.
Passaggi successivi
- Scopri come eseguire l'upgrade di Config Sync.
- Scopri di più sui comandi
gcloud
per configurare Config Sync. - Scopri come configurare la sincronizzazione da più repository.
- Usa il comando
nomos
. - Leggi l'introduzione alla risoluzione dei problemi di Config Sync.
- Scopri come disinstallare Config Sync.
- Esamina le autorizzazioni predefinite di Config Sync.