Questa pagina mostra come installare Config Sync utilizzando i comandi kubectl
.
L'operatore ConfigManagement è un controller che gestisce Config Sync in un
in un cluster Kubernetes. Segui questi passaggi per installare e configurare
Operatore in ogni cluster che vuoi gestire utilizzando
Config Sync.
Prima di iniziare
Questa sezione descrive i prerequisiti da soddisfare prima
Installazione di Config Sync utilizzando kubectl
.
Prepara l'ambiente locale
Prima di installare l'operatore, assicurati di aver preparato dell'ambiente locale, completando le seguenti attività:
Creare o avere accesso a una fonte attendibile.
Installa e inizializza Google Cloud CLI, che fornisce il comando Comandi
gcloud
,kubectl
enomos
utilizzati in queste istruzioni. Se utilizzi Cloud Shell, Google Cloud CLI è preinstallato.kubectl
non è installato per impostazione predefinita da Google Cloud CLI. Per installarekubectl
, utilizza il seguente comando:gcloud components install kubectl
Esegui l'autenticazione su Google Cloud utilizzando il comando
gcloud auth login
per poter scaricare i componenti di Config Sync.
Prepara i cluster
Creare o avere accesso a un cluster Google Kubernetes Engine (GKE) Enterprise che soddisfi i requisiti per Config Sync.
Prepara le autorizzazioni
L'utente di Google Cloud che installa Config Sync ha bisogno delle autorizzazioni IAM per creare nuovi ruoli nel tuo cluster. Se necessario, concedi questi ruoli con i seguenti comandi:
gcloud container clusters get-credentials CLUSTER_NAME kubectl create clusterrolebinding cluster-admin-binding \ --clusterrole cluster-admin --user USER_ACCOUNT
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del clusterUSER_ACCOUNT
: l'indirizzo email del tuo account Google Cloud indirizzo
A seconda di come hai configurato Google Cloud CLI sul tuo sistema locale, potrebbe essere necessario aggiungere i campi --project
e --zone
.
Se devi concedere all'operatore l'accesso a OCI
usando gcpserviceaccount
come tipo di autenticazione per creare un criterio
è necessario disporre anche dell'autorizzazione iam.serviceAccounts.setIamPolicy
.
Puoi ottenere questa autorizzazione concedendo all'Amministratore account di servizio
(roles/iam.serviceAccountAdmin
) Ruolo IAM. Potresti anche riuscire a:
per ottenere questa autorizzazione con i ruoli personalizzati oppure
altri ruoli predefiniti.
Per ulteriori informazioni sulla concessione dei ruoli, consulta Gestisci accesso.
Registra un cluster
Per registrare un cluster in Config Sync, completa i seguenti passaggi:
- Esegui il deployment dell'operatore
- Concedi all'operatore l'accesso di sola lettura a uno dei seguenti elementi:
- Configura l'operatore
Esegui il deployment dell'operatore
Dopo aver verificato di soddisfare tutti i prerequisiti, puoi eseguire il deployment dell'operatore scaricando e applicando un manifest YAML.
Scarica la versione più recente dei manifest dell'operatore utilizzando il . Per scaricare una versione specifica, consulta Download.
gcloud storage cp gs://config-management-release/released/latest/config-management-operator.yaml config-management-operator.yaml
Applica i manifest:
kubectl apply -f config-management-operator.yaml
Se l'operazione non riesce a causa di un problema con l'oggetto ConfigManagement che non è
a causa di un errore di sintassi YAML o JSON, l'istanza dell'oggetto potrebbe essere creata
ma potrebbe non funzionare correttamente. In questa situazione, puoi utilizzare il comando nomos
status
per verificare la presenza di errori nell'oggetto.
Un'installazione valida senza problemi ha lo stato PENDING
o SYNCED
.
Un'installazione non valida ha lo stato NOT CONFIGURED
e elenca uno dei seguenti errori:
missing git-creds Secret
missing required syncRepo field
git-creds Secret is missing the key specified by secretType
Per risolvere il problema, correggi l'errore di configurazione. A seconda del tipo di errore, potrebbe essere necessario applicare nuovamente il manifest ConfigManagement al cluster.
Se il problema è che hai dimenticato di creare il secret git-creds
,
Config Sync rileva il secret non appena lo crei.
applicare di nuovo la configurazione.
Concedi all'operatore l'accesso di sola lettura
Se archivi le tue configurazioni in Git, devi concedere all'operatore l'accesso di sola lettura a Git. Se memorizzi le configurazioni come immagini OCI, devi concedere all'Operatore accesso di sola lettura a OCI. Se memorizzi le tue configurazioni in Helm, devi concedere all'operatore l'accesso di sola lettura a Helm.
Concedi all'operatore l'accesso di sola lettura a Git
Config Sync ha bisogno di accesso di sola lettura al tuo repository Git per poter leggere le configurazioni committate nel repository e applicarle ai tuoi cluster.
Se il repository non richiede l'autenticazione per l'accesso di sola lettura, puoi:
continua con la configurazione di Config Sync
usa none
come tipo di autenticazione. Ad esempio, se puoi sfogliare il repository utilizzando un'interfaccia web senza accedere o se puoi utilizzare git
clone
per creare una copia del repository localmente senza fornire le credenziali o utilizzare le credenziali salvate, non è necessario autenticarsi. In questo caso,
non è necessario creare un secret.
Tuttavia, la maggior parte degli utenti deve creare credenziali perché
l'accesso in lettura ai propri
con restrizioni. Se sono richieste le credenziali, queste vengono archiviate nel segreto git-creds
su ogni cluster registrato (a meno che non utilizzi un account di servizio Google). Il secret deve 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. Sia GitHub sia Bitbucket supportano l'utilizzo di una coppia di chiavi SSH. Tuttavia, se utilizzi un repository in Cloud Source Repositories, ti consigliamo di utilizzare un account di servizio Google, poiché la procedura è più semplice. Se il tuo repository è ospitato dalla tua organizzazione e non sai quali metodi di autenticazione sono supportati, contatta l'amministratore.
Per usare un repository in Cloud Source Repositories come repository di 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 del repository che vuoi utilizzare. Ad esempio:
REPO_NAME PROJECT_ID URL my-repo my-project https://source.developers.google.com/p/my-project/r/my-repo-csr
Devi utilizzare questo URL quando configurare Config Sync sezione successiva. Se configuri la sincronizzazione delle configurazioni 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
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 autenticarti nel 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 da 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 alla 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.
Configura il repository per riconoscere la chiave pubblica appena creata. Fai riferimento alla documentazione del tuo provider di hosting Git. Istruzioni per Alcuni provider host Git popolari sono inclusi per praticità:
- 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 mediante l'autenticazione SSH: puoi aggiungere la chiave host noti al campo
data.known_hosts
nellagit_creds
secret. Per disattivare il controllo diknown_hosts
, puoi rimuovere il componente Campoknown_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
Elimina la chiave privata dal disco locale o proteggila.
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 CloudPROJECT_ID
: l'ID del progetto Google Cloud in cui si trova il repositoryREPO_NAME
: il nome del repository
File dei cookie
La procedura per acquisire un cookiefile
dipende dalla configurazione del tuo
repository. Per un esempio, vedi
Genera credenziali statiche
nella documentazione di Cloud Source Repositories.
Solitamente, le credenziali sono archiviate nel file .gitcookies
nella home directory oppure ti potrebbero essere fornite da un amministratore della sicurezza.
Per utilizzare un cookiefile
, completa i seguenti passaggi:
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 segreto insieme a
cookiefile
eseguendo il seguente comando:kubectl create ns config-management-system && \ kubectl create secret generic git-creds \ --namespace=config-management-system \ --from-file=cookie_file=/path/to/COOKIEFILE \ --from-literal=https_proxy=HTTPS_PROXY_URL
Sostituisci quanto segue:
/path/to/COOKIEFILE
: il tipo appropriato percorso e nome fileHTTPS_PROXY_URL
: l'URL del proxy HTTPS che utilizzi per comunicare 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 utilizzare un token. Con Config Sync, puoi utilizzare i token di accesso personale (PAT) di GitHub, i PAT o le chiavi di deployment di GitLab o la password per l'app di Bitbucket come token.
Per creare un secret utilizzando il tuo token, segui questi passaggi:
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 una utente di macchina e associare il tuo PAT all'utente della macchina. - GitLab: Creare un PAT oppure 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 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 per comunicare con il repository Git.
Proteggi il token se ti occorre ancora a livello locale. In caso contrario, eliminalo.
Service account Google
Se il tuo repository si trova in Cloud Source Repositories e il tuo cluster utilizza la federazione delle identità per i carichi di lavoro di GKE o la federazione delle identità per i carichi di lavoro di Fleet per GKE, puoi concedere a Config Sync l'accesso a un repository nello stesso progetto del tuo cluster gestito utilizzando un account di servizio Google.
Se non hai ancora un account di servizio, creane uno.
Concedi il lettore Cloud Source Repositories (
roles/source.reader
) ruolo IAM all'account di servizio Google. Per maggiori 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
Se configuri Config Sync utilizzando la console Google Cloud, seleziona Federazione delle identità per i carichi di lavoro per GKE come Tipo di autenticazione, quindi aggiungi l'indirizzo email del tuo account di servizio.
Se configuri Config Sync utilizzando Google Cloud CLI, aggiungi
gcpserviceaccount
comesecretType
e poi aggiungi l'indirizzo email del tuo account di servizio agcpServiceAccountEmail
.Dopo aver configurato Config Sync, crea un'istanza 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 Workload Identity Federation for GKE. Con il concetto di identicità del parco risorse, se aggiungi il criterio IAM al tuo account di servizio Kubernetes in un cluster, anche l'account di servizio Kubernetes dello stesso spazio dei nomi su altri cluster nello stesso parco risorse riceve lo stesso criterio IAM.
Questa associazione consente all'account di servizio Kubernetes di Config Sync 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 Workload Identity Federation for GKE, è lo stesso valore diPROJECT_ID
. Se utilizzi la federazione delle identità per i carichi di lavoro del parco risorse per GKE, questo è l'ID progetto del parco risorse a cui è registrato il tuo cluster.GSA_NAME
: l'account di servizio Google personalizzato che vuoi utilizzare per connetterti ad Artifact Registry. L'account di servizio deve avere il ruolo IAM Artifact Registry Reader (roles/artifactregistry.reader
).KSA_NAME
: l'account di servizio Kubernetes per riconciliatore.- Per i repository principali, se il nome
RootSync
èroot-sync
, utilizzaroot-reconciler
. In caso contrario, usaroot-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 principali, se il nome
REPOSITORY
: il nome del repository.POLICY_FILE
: il file JSON o YAML con nel 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 la federazione delle identità per i carichi di lavoro per GKE disabilitata,
puoi utilizzare gcenode
come tipo di autenticazione.
Se configuri Config Sync utilizzando la console Google Cloud, seleziona Repository Google Cloud come Tipo di autenticazione.
Se configuri Config Sync utilizzando Google Cloud CLI, aggiungi gcenode
come secretType
.
La selezione di Google Cloud Repository o gcenode
consente di utilizzare
Account di servizio predefinito Compute Engine. Devi concedere il ruolo IAM Reader dei repository di codice sorgente di Cloud (roles/source.reader
) all'account di servizio predefinito di Compute Engine. Per ulteriori informazioni
i ruoli e le autorizzazioni di Cloud Source Repositories, consulta
Concedi le autorizzazioni per visualizzare i repository.
gcloud projects add-iam-policy-binding PROJECT_ID \
--role=roles/source.reader \
--member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"
Sostituisci PROJECT_ID
con l'ID progetto della tua organizzazione e
sostituisci PROJECT_NUMBER
con il progetto della tua organizzazione
numero.
Concedi all'operatore l'accesso di sola lettura a OCI
Config Sync ha bisogno di accesso di sola lettura all'immagine OCI archiviata in Artifact Registry per poter leggere le configurazioni incluse nell'immagine e applicarle ai tuoi cluster.
Se l'immagine non richiede l'autenticazione per l'accesso di sola lettura, puoi
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 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
)
Service account Kubernetes
Se archivi l'immagine OCI in Artifact Registry e il tuo cluster utilizza la federazione delle identità per i carichi di lavoro per GKE o la federazione delle identità per i carichi di lavoro per il parco risorse, puoi utilizzare k8sserviceaccount
come tipo di autenticazione nella versione 1.17.2 e successive. Questa opzione è consigliata per più di gcpserviceaccount
a causa dei suoi
processo di configurazione semplificato.
Concedi al lettore Artifact Registry (
roles/artifactregistry.reader
) ruolo IAM all'account di servizio Kubernetes con Federazione delle identità per i carichi di lavoro per il pool GKE. Per ulteriori informazioni sui ruoli e sulle autorizzazioni di Artifact Registry, consulta Configurare i ruoli e le autorizzazioni per Artifact Registry.Concedi l'autorizzazione a livello di progetto se le stesse autorizzazioni si applicano a tutti 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 abbiano livelli di accesso diversi per ogni repository del progetto.
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \ --location=LOCATION \ --role=roles/artifactregistry.reader \ --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \ --project=PROJECT_ID
Sostituisci quanto segue:
PROJECT_ID
: ID progetto dell'organizzazione.FLEET_HOST_PROJECT_ID
: se utilizzi Workload Identity Federation for GKE, è lo stesso valore diPROJECT_ID
. Se utilizzi la federazione delle identità per i carichi di lavoro del parco risorse per GKE, questo è l'ID progetto del parco risorse a cui è registrato il tuo cluster.KSA_NAME
: l'account di servizio Kubernetes per il Mediator.- Per i repository root, se il nome
RootSync
èroot-sync
, usaroot-reconciler
. Altrimenti, usaroot-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 posizione regionale o su più regioni del repository.
Service account Google
Se archivi l'immagine OCI in Artifact Registry e il cluster utilizza
Federazione delle identità per i carichi di lavoro GKE per GKE
o Federazione delle identità per i carichi di lavoro del parco risorse per GKE,
puoi usare gcpserviceaccount
come tipo di autenticazione. A partire da
versione 1.17.2, ti consigliamo di usare invece k8sserviceaccount
. Questa
opzione elimina i passaggi aggiuntivi per la creazione di un account di servizio Google e dell'associazione dei criteri IAM.
Se non hai ancora un account di servizio, creane uno.
Concedi il ruolo IAM Lettore del registry di elementi (
roles/artifactregistry.reader
) all'account di servizio Google. Per ulteriori informazioni sui ruoli e sulle autorizzazioni di Artifact Registry, consulta Configurare i ruoli e le autorizzazioni per Artifact Registry.Concedi l'autorizzazione a livello di progetto se le stesse autorizzazioni si applicano a tutti 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 abbiano livelli di accesso diversi per ogni repository del progetto.
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \ --location=LOCATION \ --role=roles/artifactregistry.reader \ --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \ --project=PROJECT_ID
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 Workload Identity Federation for GKE, è lo stesso valore diPROJECT_ID
. Se utilizzi la federazione delle identità per i carichi di lavoro del parco risorse per GKE, questo è l'ID progetto del parco risorse a cui è registrato il tuo cluster.GSA_NAME
: l'account di servizio Google personalizzato che vuoi utilizzare per connetterti ad Artifact Registry. L'account di servizio deve avere il ruolo IAM 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
, usaroot-reconciler
. Altrimenti, usaroot-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
: 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 la federazione delle identità per i carichi di lavoro per GKE disabilitata, puoi utilizzare gcenode
come tipo di autenticazione.
Config Sync utilizza l'account di servizio predefinito di Compute Engine.
Devi concedere all'account di servizio predefinito di Compute Engine l'accesso come lettore ad Artifact Registry.
Concedi all'account di servizio Compute Engine l'autorizzazione di lettura a Artifact Registry eseguendo il seguente comando:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \ --role=roles/artifactregistry.reader
Sostituisci
PROJECT_ID
con l'ID progetto della tua organizzazione e sostituisciPROJECT_NUMBER
con del progetto.
Configurare l'operatore per un'autorità di certificazione
Per i server configurati con certificati di un'autorità di certificazione (CA)
che non è già attendibile, Config Sync può essere configurato per utilizzare un certificato
CA per verificare le connessioni HTTPS al server. Questa opzione è supportata per i server Git,
Helm o OCI. Il certificato CA deve includere certificati SSL completi (radice/intermedio/foglia).
Se il server utilizza già una CA attendibile o non ti connetti tramite HTTPS,
puoi saltare questo passaggio e non impostare caCertSecretRef
.
RootSync
Recupera il certificato CA utilizzato per emettere il certificato per il tuo server Git e lo salvi in un file.
Per gli oggetti
RootSync
, il secret deve essere creato nello spazio dei nomiconfig-management-system
. Ad esempio:kubectl create ns config-management-system &&
kubectl create secret generic ROOT_CA_CERT_SECRET_NAME
--namespace=config-management-system
--from-file=cert=/path/to/CA_CERT_FILEQuando configuri Operator, imposta il valore del campo
caCertSecretRef.name
nel campoRootSync
oggetto in ROOT_CA_CERT_SECRET_NAME.
RepoSync
Recupera il certificato CA utilizzato per emettere il certificato per il tuo server Git e lo salvi in un file.
Per gli oggetti
RepoSync
, il segreto deve essere creato nello stesso spazio dei nomi di RepoSync. Ad esempio:kubectl create ns REPO_SYNC_NAMESPACE &&
kubectl create secret generic NAMESPACE_CA_CERT_SECRET_NAME
--namespace=REPO_SYNC_NAMESPACE
--from-file=cert=/path/to/CA_CERT_FILEQuando configuri
RepoSync
, imposta il valore del campocaCertSecretRef.name
nel moduloRepoSync
oggetto in NAMESPACE_CA_CERT_SECRET_NAME.
Concedi all'operatore l'accesso di sola lettura a Helm
Config Sync ha bisogno di accesso in sola lettura al tuo repository Helm per poter leggere i grafici Helm nel repository e installarli nei tuoi cluster.
Se il repository non richiede l'autenticazione per l'accesso di sola lettura, puoi
continuare a
configurare Config Sync
e utilizzare none
come tipo di autenticazione. Ad esempio, se il tuo repository Helm
è pubblico ed è accessibile a tutti su internet, quindi non occorre
autenticarsi.
Tuttavia, la maggior parte degli utenti deve creare credenziali per accedere ai repository Helm privati. Config Sync supporta i seguenti meccanismi per l'autenticazione:
- Token (
token
) - Service account 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 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
.
Service account Kubernetes
Se archivi il grafico Helm in Artifact Registry e il cluster utilizza
Federazione delle identità per i carichi di lavoro GKE per GKE
o Federazione delle identità per i carichi di lavoro del parco risorse per GKE,
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
processo di configurazione semplificato.
Concedi il ruolo IAM Lettore del registry di elementi (
roles/artifactregistry.reader
) all'account di servizio Kubernetes con il pool della federazione delle identità per i carichi di lavoro per GKE. Per ulteriori informazioni sui ruoli e sulle autorizzazioni di Artifact Registry, consulta Configurare i ruoli e le autorizzazioni per Artifact Registry.Concedi l'autorizzazione a livello di progetto se le stesse autorizzazioni si applicano a tutti 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 abbiano livelli di accesso diversi per ogni repository del progetto.
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \ --location=LOCATION \ --role=roles/artifactregistry.reader \ --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \ --project=PROJECT_ID
Sostituisci quanto segue:
PROJECT_ID
: ID progetto dell'organizzazione.FLEET_HOST_PROJECT_ID
: se utilizzi Workload Identity Federation for GKE, è lo stesso valore diPROJECT_ID
. Se utilizzi la federazione delle identità per i carichi di lavoro del parco risorse per GKE, questo è l'ID progetto del parco risorse a cui è registrato il tuo cluster.KSA_NAME
: l'account di servizio Kubernetes per il Mediator.- Per i repository root, se il nome
RootSync
èroot-sync
, usaroot-reconciler
. Altrimenti, usaroot-reconciler-ROOT_SYNC_NAME
.
- Per i repository root, se il nome
REPOSITORY
: l'ID del repository.LOCATION
: la posizione regionale o su più regioni del repository.
Service account Google
Se archivi il grafico Helm in Artifact Registry e il cluster utilizza
Federazione delle identità per i carichi di lavoro GKE per GKE
o Federazione delle identità per i carichi di lavoro del parco risorse per GKE,
puoi usare gcpserviceaccount
come tipo di autenticazione. A partire da
versione 1.17.2, ti consigliamo di usare invece k8sserviceaccount
. Questa
opzione elimina i passaggi aggiuntivi per la creazione di un account di servizio Google e dell'associazione dei criteri IAM.
Se non hai ancora un account di servizio, crea un account di servizio.
Concedi al lettore Artifact Registry (
roles/artifactregistry.reader
) ruolo IAM all'account di servizio Google. Per ulteriori informazioni sui ruoli e sulle autorizzazioni di Artifact Registry, consulta Configurare i ruoli e le autorizzazioni per Artifact Registry.Concedi l'autorizzazione a livello di progetto se le stesse autorizzazioni si applicano a tutti i repository del progetto.
gcloud projects add-iam-policy-binding PROJECT_ID \ --role=roles/artifactregistry.reader \ --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
Concedi l'autorizzazione specifica 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
Crea un'associazione dei criteri IAM tra l'account di servizio Kubernetes e l'account di servizio Google eseguendo il seguente comando:
gcloud iam service-accounts add-iam-policy-binding GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/iam.workloadIdentityUser \ --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" --project=PROJECT_ID
Sostituisci quanto segue:
PROJECT_ID
: ID progetto dell'organizzazione.FLEET_HOST_PROJECT_ID
: se utilizzi Workload Identity Federation for GKE, è lo stesso valore diPROJECT_ID
. Se utilizzi la federazione delle identità per i carichi di lavoro del parco risorse per GKE, questo è l'ID progetto del parco risorse a cui è registrato il tuo cluster.GSA_NAME
: l'account di servizio Google personalizzato che vuoi utilizzare per connetterti ad Artifact Registry. L'account di servizio deve avere il ruolo IAM 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
, usaroot-reconciler
. Altrimenti, usaroot-reconciler-ROOT_SYNC_NAME
.
- Per i repository root, se il nome
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 la federazione delle identità per i carichi di lavoro per GKE disabilitata, puoi utilizzare gcenode
come tipo di autenticazione.
Config Sync utilizza l'account di servizio predefinito di Compute Engine.
Devi concedere 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.
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 ePROJECT_NUMBER
con il numero del progetto della tua organizzazione.
Configura l'operatore
Per configurare la sincronizzazione dal repository principale, devi attivare la modalità multi-repository nel tuo oggetto ConfigManagement e creare un oggetto RootSync che sincronizzi il repository principale con il cluster. Puoi creare un solo repository principale per ciascun cluster e il repository principale può essere un repository non strutturato o un repository gerarchico.
Se utilizzi il webhook di ammissione Config Sync (il webhook di ammissione è disattivato per impostazione predefinita) e stai installando Config Sync in per un cluster privato, aggiungi una regola firewall per consentire la porta
10250
. Il webhook di ammissione di Config Sync utilizza la porta10250
per la prevenzione dello slittamento.Crea un file denominato
config-management.yaml
e copia al suo interno il seguente file YAML:# config-management.yaml apiVersion: configmanagement.gke.io/v1 kind: ConfigManagement metadata: name: config-management spec: # The `enableMultiRepo` field is set to true to enable RootSync and RepoSync APIs. enableMultiRepo: true preventDrift: PREVENT_DRIFT
Sostituisci quanto segue:
PREVENT_DRIFT
: se impostato sutrue
, consente al webhook di ammissione di Config Sync di evitare gli scostamenti rifiutando l'invio di modifiche in conflitto ai cluster attivi. L'impostazione predefinita èfalse
. Config Sync corregge sempre le derive indipendentemente dal valore di questo campo.
Applica le modifiche:
kubectl apply -f config-management.yaml
Attendi che i CRD
RootSync
eRepoSync
siano disponibili:until kubectl get customresourcedefinitions rootsyncs.configsync.gke.io reposyncs.configsync.gke.io; do date; sleep 1; echo ""; done
Salva uno dei seguenti manifest come
root-sync.yaml
. Utilizza la versione del manifest corrispondente al tipo di origine per le configurazioni.Git
# root-sync.yaml apiVersion: configsync.gke.io/v1beta1 kind: RootSync metadata: name: ROOT_SYNC_NAME namespace: config-management-system spec: sourceType: git sourceFormat: ROOT_FORMAT git: repo: ROOT_REPOSITORY revision: ROOT_REVISION branch: ROOT_BRANCH dir: ROOT_DIRECTORY auth: ROOT_AUTH_TYPE gcpServiceAccountEmail: ROOT_EMAIL secretRef: name: ROOT_SECRET_NAME noSSLVerify: ROOT_NO_SSL_VERIFY caCertSecretRef: name: ROOT_CA_CERT_SECRET_NAME
Sostituisci quanto segue:
ROOT_SYNC_NAME
: aggiungi il nome dell'oggetto RootSync.ROOT_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 ti consente di organizzare le configurazioni nel modo più pratico per te.ROOT_REPOSITORY
: aggiungi l'URL del repository Git da utilizzare come repository principale. Puoi inserire gli URL utilizzando il protocollo HTTPS HTTP(S) o SSH. Ad esempio,https://github.com/GoogleCloudPlatform/anthos-config-management-samples
utilizza il protocollo HTTPS. Questo campo è obbligatorio.ROOT_REVISION
: aggiungi la revisione Git (tag o hash) da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito èHEAD
. A partire da Config Sync versione 1.17.0, puoi anche specifica un nome ramo nel camporevision
. Quando utilizzi un hash nella versione 1.17.0 o successive, deve essere un hash completo e non una forma abbreviata.ROOT_BRANCH
: aggiungi il ramo di il repository da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito èmaster
. A partire dalla versione 1.17.0 di Config Sync, per semplicità è consigliato utilizzare il camporevision
per specificare un nome del ramo. Se sono specificati entrambi i campirevision
ebranch
,revision
ha la precedenza subranch
.ROOT_DIRECTORY
: aggiungi il percorso nel repository Git alla directory principale contenente la configurazione con cui vuoi eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è la directory radice (/
) di nel repository.ROOT_AUTH_TYPE
: aggiungi uno dei seguenti tipi di autenticazione:none
: non usare l'autenticazionessh
: usa una coppia di chiavi SSHcookiefile
: usa uncookiefile
token
: utilizza un tokengcpserviceaccount
: utilizza un account di servizio Google per accedere a Cloud Source Repositories.gcenode
: utilizza un account di servizio Google per accedere a Cloud Source Repositories. Seleziona questa opzione solo se Workload Identity Federation for GKE non è abilitato nel tuo cluster.
Per ulteriori informazioni su questi tipi di autenticazione, consulta la pagina Concedere a Config Sync l'accesso di sola lettura a Git.
Questo campo è obbligatorio.
ROOT_EMAIL
: se hai aggiuntogcpserviceaccount
comeROOT_AUTH_TYPE
, aggiungi il tuo indirizzo email dell'account del servizio Google. Ad esempio:acm@PROJECT_ID.iam.gserviceaccount.com
.ROOT_SECRET_NAME
: aggiungi il nome del secret. Se questo , devi aggiungere la chiave pubblica del secret il provider Git. Questo campo è facoltativo.ROOT_NO_SSL_VERIFY
: per disattivare la verifica del certificato SSL, imposta questo campo sutrue
. Il valore predefinito èfalse
.ROOT_CA_CERT_SECRET_NAME
: aggiungi il nome del tuo Secret. Se questo campo è impostato, il tuo provider Git deve utilizzare un certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominatacert
. Questo campo è facoltativo.Per saperne di più su come configurare l'oggetto Secret per la CA certificato, consulta Configurare l'autorità di certificazione
Per una spiegazione dei campi e un elenco completo dei campi che puoi aggiungere al campo
spec
, consulta Campi RootSync.Questo manifest crea un oggetto
RootSync
che utilizza Git come origine.OCI
# root-sync.yaml apiVersion: configsync.gke.io/v1beta1 kind: RootSync metadata: name: ROOT_SYNC_NAME namespace: config-management-system spec: sourceType: oci sourceFormat: ROOT_FORMAT oci: image: ROOT_IMAGE dir: ROOT_DIRECTORY auth: ROOT_AUTH_TYPE gcpServiceAccountEmail: ROOT_EMAIL caCertSecretRef: name: ROOT_CA_CERT_SECRET_NAME
Sostituisci quanto segue:
ROOT_SYNC_NAME
: aggiungi il nome dell'oggetto RootSync.ROOT_FORMAT
: aggiungiunstructured
per utilizzare un repository non strutturato ohierarchy
per utilizzare un repository gerarchico. Questi valori sono sensibili alle maiuscole. Questo campo è facoltativo e il valore predefinito èhierarchy
. Ti consigliamo di aggiungereunstructured
poiché questo formato consente puoi organizzare le configurazioni nel modo che preferisci.ROOT_IMAGE
: l'URL dell'immagine OCI da utilizzare come repository principale, ad esempioLOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME
. Per impostazione predefinita, l'immagine viene estratta dal taglatest
, ma puoi estrarre le immagini anche tramiteTAG
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
ROOT_DIRECTORY
: aggiungi il percorso nel repository a la directory principale che contiene la configurazione da sincronizzare a. Questo campo è facoltativo e il valore predefinito è la directory radice (/
) di nel repository.ROOT_AUTH_TYPE
: aggiungi uno dei seguenti tipi di autenticazione:none
: non usare l'autenticazionegcenode
: utilizza l'account di servizio predefinito di Compute Engine per accedere a un'immagine in Artifact Registry. Seleziona questa opzione solo se la federazione delle identità per i carichi di lavoro per GKE non è abilitata nel tuo cluster.gcpserviceaccount
: utilizza un account di servizio Google per accedere a un dell'immagine.
Questo campo è obbligatorio.
ROOT_EMAIL
: se hai aggiuntogcpserviceaccount
comeROOT_AUTH_TYPE
, aggiungi il tuo indirizzo email dell'account del servizio Google. Ad esempio:acm@PROJECT_ID.iam.gserviceaccount.com
.ROOT_CA_CERT_SECRET_NAME
: aggiungi il nome del tuo Secret. Se questo campo è impostato, il provider OCI deve utilizzare un certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA sotto una chiave denominatacert
. Questo campo è facoltativo.
Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'autorità di certificazione
Per una spiegazione dei campi e un elenco completo dei campi che puoi aggiungere al campo
spec
, consulta Campi RootSync.Questo file manifest crea un oggetto
RootSync
che utilizza un'immagine OCI come origine.Helm
# root-sync.yaml apiVersion: configsync.gke.io/v1beta1 kind: RootSync metadata: name: ROOT_SYNC_NAME namespace: config-management-system spec: sourceType: helm sourceFormat: ROOT_FORMAT helm: repo: ROOT_HELM_REPOSITORY chart: HELM_CHART_NAME version: HELM_CHART_VERSION releaseName: HELM_RELEASE_NAME namespace: HELM_RELEASE_NAMESPACE values: foo: bar: VALUE_1 baz: - qux: VALUE_2 xyz: VALUE_3 includeCRDs: HELM_INCLUDE_CRDS auth: ROOT_AUTH_TYPE gcpServiceAccountEmail: ROOT_EMAIL secretRef: name: ROOT_SECRET_NAME caCertSecretRef: name: ROOT_CA_CERT_SECRET_NAME
Sostituisci quanto segue:
ROOT_SYNC_NAME
: aggiungi il nome del tuo sistema RootSync .ROOT_FORMAT
: 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 ti consente di organizzare le configurazioni nel modo più pratico per te.ROOT_HELM_REPOSITORY
: l'URL del repository Helm da utilizzare come repository principale. Puoi inserire gli URL utilizzando il protocollo HTTPS o SSH. Ad esempio,https://github.com/GoogleCloudPlatform/anthos-config-management-samples
utilizza il protocollo HTTPS. Questo campo è obbligatorio.HELM_CHART_NAME
: aggiungi il nome del grafico Helm. Questo campo è obbligatorio.HELM_CHART_VERSION
: la versione del grafico. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzata la versione più recente.HELM_RELEASE_NAME
: il nome della release Helm. Questo campo è facoltativo.HELM_RELEASE_NAMESPACE
: lo spazio dei nomi di destinazione per una release. Imposta uno spazio dei nomi solo per le risorse che contengononamespace: {{ .Release.Namespace }}
nei relativi modelli. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzato lo spazio dei nomi predefinitoconfig-management-system
.HELM_INCLUDE_CRDS
: impostato sutrue
se vuoi che il modello Helm generi anche un CustomResourceDefinition. Questo campo è facoltativo. Se non viene specificato alcun valore, il valore predefinito èfalse
e non verrà generato alcun CRD.VALUE
: valori da utilizzare al posto dei valori predefiniti associati al grafico Helm. Formatta questo campo come quello del file helm chart's values.yaml. Questo campo è facoltativo.ROOT_AUTH_TYPE
: aggiungi uno dei seguenti tipi di autenticazione:none
: non utilizzare l'autenticazionetoken
: usa un nome utente e una password per accedere a un Helm privato repository Git.gcenode
: utilizza Account di servizio predefinito Compute Engine per accedere a un'immagine in Artifact Registry. Seleziona questa opzione solo se La federazione delle identità per i carichi di lavoro per GKE non è abilitata nel cluster.gcpserviceaccount
: utilizza un account di servizio Google per accedere a un dell'immagine.
Questo campo è obbligatorio.
ROOT_EMAIL
: se hai aggiuntogcpserviceaccount
come tuoROOT_AUTH_TYPE
, aggiungi l'indirizzo email del tuo account di servizio Google. Ad esempio,acm@PROJECT_ID.iam.gserviceaccount.com
.ROOT_SECRET_NAME
: aggiungi il nome del tuo secret setoken
è ilROOT_AUTH_TYPE
. Questo campo è facoltativo.ROOT_CA_CERT_SECRET_NAME
: aggiungi il nome del segreto. Se questo campo è impostato, il tuo provider Helm deve utilizzare un'istanza certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominatacert
. Questo campo è facoltativo.
Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'autorità di certificazione
Per una spiegazione dei campi e un elenco completo dei campi che che è possibile aggiungere al campo
spec
, consulta la sezione Campi RootSync.Questo manifest crea un oggetto
RootSync
che utilizza Helm come origine.Applica le modifiche:
kubectl apply -f root-sync.yaml
Verifica lo stato di sincronizzazione del repository radice
Puoi utilizzare il comando nomos status
per controllare lo stato della sincronizzazione del repository principale:
nomos status
Dovresti vedere un output simile all'esempio seguente:
my_managed_cluster-1
--------------------
<root> git@github.com:foo-corp/acme/admin@main
SYNCED f52a11e4
Verifica l'installazione di RootSync
Quando crei un oggetto RootSync, Config Sync crea un riconciliatore con
Prefisso root-reconciler
. Un riconciliatore è un pod di cui viene eseguito il deployment come deployment.
Sincronizza i manifest da un repository Git a un cluster.
Puoi verificare che l'oggetto RootSync funzioni correttamente controllando le stato del deployment del root-reconciler:
kubectl get -n config-management-system deployment \
-l configsync.gke.io/sync-name=ROOT_SYNC_NAME
Sostituisci ROOT_SYNC_NAME
con il nome di RootSync.
Dovresti vedere un output simile all'esempio seguente:
NAME READY UP-TO-DATE AVAILABLE AGE
root-reconciler 1/1 1 1 3h42m
Per scoprire altri modi per esaminare lo stato dell'oggetto RootSync, consulta Monitoraggio di oggetti RootSync e RepoSync.
Dopo aver completato la configurazione del repository radice, puoi facoltativamente scegli di configurare la sincronizzazione da più repository. Questi repository sono utili se vuoi un repository che contenga configurazioni basate sullo spazio dei nomi sincronizzate con uno spazio dei nomi particolare nei cluster.
Esegui l'upgrade di Config Sync
Per eseguire l'upgrade di Config Sync, esegui questi comandi per ogni cluster registrato:
Scarica il manifest di Config Sync e i comandi
nomos
per la nuova versione.Applica il manifest di Config Sync:
kubectl apply -f config-management-operator.yaml
Questo comando aggiorna l'immagine dell'operatore ConfigManagement. Kubernetes recupera la nuova versione e riavvia il pod Config Sync utilizzando il nuovo completamente gestita. Quando Config Sync si avvia, esegue un ciclo di riconciliazione che applica l'insieme di manifest raggruppati nella nuova immagine. In questo modo, viene aggiornato e riavviato ogni pod del componente.
Sostituisci il comando
nomos
su tutti i client con la nuova versione. Questa modifica garantisce che il comandonomos
possa sempre ottenere di tutti i cluster registrati e convalidare le configurazioni corrispondenti.
Disinstalla Config Sync
Per disinstallare Config Sync, completa i seguenti passaggi:
Un amministratore centrale deve rimuovere il repository principale:
Se hai attivato il webhook e vuoi conservare le tue risorse, disabilita la prevenzione della deviazione per le risorse abbandonate. Se non hai attivato il webhook, non devi intraprendere altre azioni per conservare le risorse.
Elimina l'oggetto
RootSync
eseguendo questo comando:kubectl delete -f root-sync.yaml
Rimuovi il campo
spec.enableMultiRepo
nel fileconfig-management.yaml
.Applica il file
config-management.yaml
al cluster.
Se vuoi disinstallare completamente Config Sync, consulta Rimuovere l'operatore ConfigManagement.
Passaggi successivi
- Scopri come configurare la sincronizzazione da più repository.