Installa Config Sync manualmente utilizzando kubectl (sconsigliato)

Questa pagina mostra come installare Config Sync utilizzando i comandi kubectl.

Prima di iniziare

Questa sezione descrive i prerequisiti da soddisfare prima di installare Config Sync utilizzando kubectl.

Preparare l'ambiente locale

Prima di installare Config Sync, assicurati di aver preparato l'ambiente locale completando le seguenti attività:

  • Crea o accedi a una fonte attendibile.

  • Installa e inizializza Google Cloud CLI, che fornisce i comandi gcloud, kubectl e nomos utilizzati in queste istruzioni. Se utilizzi Cloud Shell, Google Cloud CLI è preinstallato.

  • kubectl non è installato per impostazione predefinita da Google Cloud CLI. Per installare kubectl, utilizza il seguente comando:

    gcloud components install kubectl

  • Esegui l'autenticazione a Google Cloud utilizzando il comando gcloud auth login in modo da poter scaricare i componenti di Config Sync.

Prepara i cluster

Crea o accedi a un cluster Google Kubernetes Engine che soddisfi i requisiti per Config Sync.

Preparare le autorizzazioni

L' Google Cloud utente che installa Config Sync deve disporre delle autorizzazioni IAM per creare nuovi ruoli nel 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 cluster
  • USER_ACCOUNT: l'indirizzo email del tuo account Google Cloud

A seconda di come hai configurato Google Cloud CLI sul tuo sistema locale, potresti dover aggiungere i campi --project e --zone.

Se devi concedere l'accesso a Config Sync a OCI utilizzando gcpserviceaccount come tipo di autenticazione, per creare un binding dei criteri, devi disporre anche dell'autorizzazione iam.serviceAccounts.setIamPolicy. Puoi ottenere questa autorizzazione concedendo il ruolo IAM Amministratore service account (roles/iam.serviceAccountAdmin). Potresti anche ottenere questa autorizzazione con ruoli personalizzati o altri ruoli predefiniti.

Per ulteriori informazioni sulla concessione dei ruoli, consulta Gestire l'accesso.

Registrare un cluster

Per registrare un cluster in Config Sync, completa i seguenti passaggi:

  1. Implementare Config Sync
  2. Concedi a Config Sync l'accesso di sola lettura a uno dei seguenti elementi:
  3. Configura Config Sync

Esegui il deployment di Config Sync

Dopo aver verificato di soddisfare tutti i prerequisiti, puoi eseguire il deployment di Config Sync scaricando e applicando un manifest YAML:

  1. Scarica l'ultima versione dei manifest di Config Sync utilizzando il seguente comando. Per scaricare una versione specifica, vedi Download.

    gcloud storage cp gs://config-management-release/released/latest/config-sync.tar.gz config-sync.tar.gz

  2. Estrai l'archivio:

    tar -xzvf config-sync.tar.gz

  3. Nell'archivio estratto nel passaggio precedente, segui le istruzioni nel file README fornito per modificare la personalizzazione.

  4. Per aggiornare l'installazione di Config Sync, applica il manifest sottoposto a rendering che hai creato seguendo le istruzioni per README: 

    kubectl apply -f CONFIG_SYNC_MANIFEST

    Sostituisci CONFIG_SYNC_MANIFEST con il nome del manifest di rendering.

  5. Sostituisci il comando nomos su tutti i client con la nuova versione. Questa modifica garantisce che il comando nomos possa sempre ottenere lo stato di tutti i cluster registrati e convalidarne le configurazioni.

Se l'operazione non riesce a causa di un problema con Config Sync che non è dovuto a un errore di sintassi YAML o JSON, l'oggetto potrebbe essere istanziato nel cluster, 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 ed elenca uno dei seguenti errori:

  • missing git-creds Secret
  • 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, potresti dover riapplicare il manifest Config Sync al cluster.

Se il problema è che hai dimenticato di creare il secret git-creds, Config Sync rileva il secret non appena lo crei e non devi riapplicare la configurazione.

Concedere l'accesso di sola lettura a Config Sync

Se memorizzi le configurazioni in Git, devi concedere a Config Sync l'accesso in sola lettura a Git. Se memorizzi le configurazioni come immagini OCI, devi concedere a Config Sync l'accesso di sola lettura a OCI. Se memorizzi le configurazioni in Helm, devi concedere a Config Sync l'accesso di sola lettura a Helm.

Concedere a Config Sync l'accesso di sola lettura a Git

Config Sync richiede l'accesso di sola lettura al tuo repository Git in modo da poter leggere le configurazioni di cui è stato eseguito il commit nel repository e applicarle ai 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 puoi sfogliare il repository utilizzando un'interfaccia web senza eseguire l'accesso o se puoi utilizzare git clone per creare un clone del repository in locale senza fornire credenziali o utilizzare credenziali salvate, non devi autenticarti. In questo caso, non è necessario creare un secret.

Tuttavia, la maggior parte degli utenti deve creare credenziali perché l'accesso in lettura al proprio repository è limitato. Se sono richieste credenziali, queste vengono archiviate nel secret git-creds su ogni cluster registrato (a meno che tu non stia utilizzando 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 di autenticazione:

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

Il meccanismo che scegli dipende da ciò che supporta il tuo repository. In genere, consigliamo di utilizzare una coppia di chiavi SSH. GitHub e Bitbucket supportano entrambi l'utilizzo di una coppia di chiavi SSH. Tuttavia, se utilizzi un repository in Cloud Source Repositories o Secure Source Manager, ti consigliamo di utilizzare unaccount di serviziot Google in quanto la procedura è più semplice. Se la tua organizzazione ospita il 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:

  1. Elenca tutti i repository:

    gcloud source repos list

  2. Copia l'URL dal repository che vuoi utilizzare dall'output. 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 consoleGoogle 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 è costituita da due file: una chiave pubblica e una chiave privata. La chiave pubblica in genere ha un'estensione .pub.

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

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

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

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

    Sostituisci quanto segue:

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

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

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

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

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

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

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

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

    Quindi, in data, aggiungi la voce degli host noti:

    known_hosts: KNOWN_HOSTS_KEY

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

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

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

    Sostituisci quanto segue:

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

File dei cookie

La procedura per acquisire un cookiefile dipende dalla configurazione del tuo repository. Per un esempio, vedi Generare 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:

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

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

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

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

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

    Sostituisci quanto segue:

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

  2. Proteggi i contenuti di cookiefile se ti occorrono 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 personali (PAT) di GitHub, i PAT o le chiavi di deployment di GitLab o la password per l'app di Bitbucket come token.

Per creare un secret utilizzando il tuo token, segui questi passaggi:

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

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

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

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

    Sostituisci quanto segue:

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

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

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

    Sostituisci quanto segue:

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

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

Service account Google

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

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

  2. Concedi i ruoli IAM corretti al account di servizio in modo che possa accedere al repository:

    Cloud Source Repositories

    Concedi il ruolo IAM Cloud Source Repositories Reader (roles/source.reader) al account di servizio Google. Per ulteriori informazioni su ruoli e autorizzazioni di Cloud Source Repositories, consulta Concedere autorizzazioni per visualizzare i repository.

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

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

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

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

    Secure Source Manager

    Concedi i ruoli IAM Secure Source Manager Instance Accessor (roles/securesourcemanager.instanceAccessor) e Secure Source Manager Repo Reader (roles/securesourcemanager.repoReader) al account di servizio Google. Per ulteriori informazioni sui ruoli e sulle autorizzazioni di Secure Source Manager, consulta Gestione dei ruoli del repository.

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

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

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

    • Per concedere autorizzazioni specifiche per il repository, puoi utilizzare l'interfaccia web di Secure Source Manager per il repository. Per saperne di più, vedi Concedere agli utenti ruoli a livello di repository.

  3. Se configuri Config Sync utilizzando la console Google Cloud , seleziona Federazione delle identità per i carichi di lavoro per GKE come Tipo di autenticazione e poi aggiungi l'email delaccount di serviziot.

    Se configuri Config Sync utilizzando Google Cloud CLI, aggiungi gcpserviceaccount come secretType e poi aggiungi l'indirizzo email del service account a gcpServiceAccountEmail.

  4. Se utilizzi un repository in Secure Source Manager, devi utilizzare il seguente formato quando configuri Config Sync e aggiungi l'URL del tuo repository Git:

    https://INSTANCE_ID-PROJECT_NUMBER-git.LOCATION.sourcemanager.dev/PROJECT_ID/REPO_NAME.git

    Sostituisci quanto segue:

    • INSTANCE_ID: il nome dell'istanza Secure Source Manager.
    • PROJECT_ID: l'ID del progetto Google Cloud in cui si trova l'istanza.
    • PROJECT_NUMBER: il Google Cloud numero di progetto in cui si trova l'istanza.
    • LOCATION: la regione in cui si trova l'istanza.
    • REPO_NAME: il nome del repository.

  5. Dopo aver configurato Config Sync, crea un'associazione dei criteri IAM tra il account di servizio Kubernetes e il account di servizio Google. Il 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 policy una sola volta per parco risorse. Tutti i cluster registrati in un parco risorse condividono lo stesso pool di federazione delle identità per i carichi di lavoro per GKE. Con il concetto di identicità del parco risorse, se aggiungi la policy IAM al account di servizio Kubernetes in un cluster, anche il account di servizio Kubernetes dello stesso spazio dei nomi sugli altri cluster dello stesso parco risorse riceve la stessa policy IAM.

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

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

Sostituisci quanto segue:

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

Account di servizio predefinito Compute Engine

Se il repository si trova in Cloud Source Repositories e il cluster è GKE con la federazione delle identità dei 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.

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

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

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

App GitHub

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

Per utilizzare un'app GitHub, completa i seguenti passaggi:

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

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

    Utilizzo dell'ID client 

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

    Utilizzo dell'ID applicazione 

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

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

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

Concedere l'accesso di sola lettura a Config Sync 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 tuoi cluster.

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

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

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

  • Account di servizio predefinito di Compute Engine (gcenode)

Service account Kubernetes

Puoi utilizzare un account di servizio Kubernetes come tipo di autenticazione se memorizzi l'immagine OCI in Artifact Registry e il tuo cluster utilizza Workload Identity Federation for GKE o Workload Identity Federation for GKE per il parco risorse.

  1. Concedi il ruolo IAM Lettore Artifact Registry (roles/artifactregistry.reader) al account di servizio Kubernetes con il pool Workload Identity Federation for GKE. 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 del progetto.

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

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

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

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID progetto dell'organizzazione.
    • FLEET_HOST_PROJECT_ID: se utilizzi Workload Identity Federation for GKE, questo valore è uguale a PROJECT_ID. Se utilizzi la federazione delle identità per i carichi di lavoro per GKE del parco risorse, questo è l'ID progetto del parco risorse a cui è registrato il cluster.
    • KSA_NAME: il account di servizio Kubernetes per il reconciler.
      • Per i repository radice, se il nome RootSync è root-sync, utilizza root-reconciler. Altrimenti, utilizza root-reconciler-ROOT_SYNC_NAME. Se installi Config Sync utilizzando la console Google Cloud o Google Cloud CLI, Config Sync crea automaticamente un oggetto RootSync denominato root-sync.
    • REPOSITORY: l'ID del repository.
    • LOCATION: la posizione regionale o multiregionale del repository.

Account di servizio predefinito Compute Engine

Se memorizzi il grafico Helm in Artifact Registry e il tuo cluster è GKE con la federazione delle identità dei carichi di lavoro per GKE disabilitata, puoi utilizzare gcenode come tipo di autenticazione. Config Sync utilizza il account di servizio predefinito di Compute Engine. Devi concedere all'account di servizio Compute Engine predefinito l'accesso in lettura ad Artifact Registry.

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

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

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

Configurare Config Sync per un'autorità di certificazione

Per i server configurati con certificati di un'autorità di certificazione (CA) non ancora attendibile, Config Sync può essere configurato per utilizzare un certificato CA per verificare le connessioni HTTPS al server. Questo attributo è supportato per i server Git, Helm o OCI. Il certificato CA deve includere certificati SSL completi (radice/intermedio/foglia). Se il tuo server utilizza già una CA attendibile o non ti connetti tramite HTTPS, puoi saltare questo passaggio e lasciare caCertSecretRef non impostato.

RootSync

  1. Recupera il certificato CA utilizzato per emettere il certificato per il tuo server Git e salvalo in un file.

  2. Per gli oggetti RootSync, il secret deve essere creato nello spazio dei nomi config-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_FILE

  3. Quando configuri Config Sync, imposta il valore del campo caCertSecretRef.name nell'oggetto RootSync su ROOT_CA_CERT_SECRET_NAME.

RepoSync

  1. Recupera il certificato CA utilizzato per emettere il certificato per il tuo server Git e salvalo in un file.

  2. Per gli oggetti RepoSync, il secret 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_FILE

  3. Quando configuri RepoSync, imposta il valore del campo caCertSecretRef.name nell'oggetto RepoSync su NAMESPACE_CA_CERT_SECRET_NAME.

Concedere l'accesso di sola lettura a Config Sync per Helm

Config Sync ha bisogno dell'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 repository Helm è pubblico e chiunque su internet può accedervi, non è necessario eseguire l'autenticazione.

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

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

Token

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

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

Sostituisci quanto segue:

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

Quando configuri Config Sync, utilizzerai il nome del secret che hai scelto per spec.helm.secretRef.name.

Service account Kubernetes

Puoi utilizzare un account di servizio Kubernetes come tipo di autenticazione se memorizzi il grafico Helm in Artifact Registry e il tuo cluster utilizza Workload Identity Federation for GKE o Workload Identity Federation for GKE per il parco risorse.

  1. Concedi il ruolo IAM Lettore Artifact Registry (roles/artifactregistry.reader) al account di servizio Kubernetes con il pool Workload Identity Federation for GKE. 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 del progetto.

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

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

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

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID progetto dell'organizzazione.
    • FLEET_HOST_PROJECT_ID: se utilizzi Workload Identity Federation for GKE, questo valore è uguale a PROJECT_ID. Se utilizzi la federazione delle identità per i carichi di lavoro per GKE del parco risorse, questo è l'ID progetto del parco risorse a cui è registrato il cluster.
    • KSA_NAME: il account di servizio Kubernetes per il reconciler.
      • Per i repository radice, se il nome RootSync è root-sync, utilizza root-reconciler. Altrimenti, utilizza root-reconciler-ROOT_SYNC_NAME.
    • REPOSITORY: l'ID del repository.
    • LOCATION: la posizione regionale o multiregionale del repository.

Account di servizio predefinito Compute Engine

Se memorizzi il grafico Helm in Artifact Registry e il tuo cluster è GKE con la federazione delle identità dei carichi di lavoro per GKE disabilitata, puoi utilizzare gcenode come tipo di autenticazione. Config Sync utilizza il account di servizio predefinito di Compute Engine. Devi concedere all'account di servizio Compute Engine predefinito l'accesso in lettura ad Artifact Registry. Potresti dover concedere l'storage-ro accesso all'ambito per concedere l'autorizzazione di sola lettura per estrarre le immagini.

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

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

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

Configurare Config Sync

Per configurare la sincronizzazione dal repository radice, devi creare un oggetto RootSync che sincronizzi il repository radice con il cluster. Puoi creare un solo repository radice per cluster e il repository radice può essere un repository non strutturato o un repository gerarchico.

  1. Se utilizzi il webhook di ammissione di Config Sync (il webhook di ammissione è disattivato per impostazione predefinita) e stai installando Config Sync in un cluster privato, aggiungi una regola firewall per consentire la porta 10250. L'webhook di ammissione di Config Sync utilizza la porta 10250 per la prevenzione della deriva.

  2. Attendi che i CRD RootSync e RepoSync siano disponibili:

    until kubectl get customresourcedefinitions rootsyncs.configsync.gke.io reposyncs.configsync.gke.io; do date; sleep 1; echo ""; done

  3. Salva uno dei seguenti manifest come root-sync.yaml. Utilizza la versione del manifest che corrisponde al tipo di origine per le tue 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: aggiungi unstructured per utilizzare un repository non strutturato o aggiungi hierarchy per utilizzare un repository gerarchico. Questi valori sono sensibili alle maiuscole. Questo campo è facoltativo e il valore predefinito è hierarchy. Ti consigliamo di aggiungere unstructured perché questo formato ti consente di organizzare le configurazioni nel modo più conveniente per te.
    • ROOT_REPOSITORY: aggiungi l'URL del repository Git 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.
    • ROOT_REVISION: aggiungi la revisione Git (tag o hash) o il ramo da cui sincronizzare. Questo campo è facoltativo e il valore predefinito è HEAD. Quando utilizzi un hash, deve essere un hash completo e non una forma abbreviata.
    • ROOT_BRANCH: aggiungi il ramo del repository da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è master. Per semplicità, ti consigliamo di utilizzare il campo revision per specificare un nome di ramo. Se vengono specificati sia il campo revision che il campo branch, revision ha la precedenza su branch.
    • ROOT_DIRECTORY: aggiungi il percorso nel repository Git alla directory principale che contiene la configurazione da sincronizzare. Questo campo è facoltativo e il valore predefinito è la directory radice (/) del repository.

    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: Non utilizzare l'autenticazione
      • ssh: Utilizza una coppia di chiavi SSH
      • cookiefile: utilizza un cookiefile
      • token: utilizza un token
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un 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 è abilitata nel tuo cluster.

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

      Questo campo è obbligatorio.

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

    • ROOT_SECRET_NAME: aggiungi il nome del tuo secret. Se questo campo è impostato, devi aggiungere la chiave pubblica del secret al provider Git. Questo campo è facoltativo.

    • ROOT_NO_SSL_VERIFY: per disattivare la verifica del certificato SSL, imposta questo campo su true. 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 denominata cert. 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 di quelli 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: aggiungi unstructured per utilizzare un repository non strutturato o aggiungi hierarchy per utilizzare un repository gerarchico. Questi valori sono sensibili alle maiuscole. Questo campo è facoltativo e il valore predefinito è hierarchy. Ti consigliamo di aggiungere unstructured perché questo formato ti consente di organizzare le configurazioni nel modo più conveniente per te.
    • ROOT_IMAGE: l'URL dell'immagine OCI da utilizzare come repository radice, ad esempio LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Per impostazione predefinita, l'immagine viene estratta dal tag latest, ma puoi estrarre le immagini in base a TAG o DIGEST. Specifica TAG o DIGEST in PACKAGE_NAME:
      • Per estrarre per TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
      • Per estrarre per DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
    • ROOT_DIRECTORY: aggiungi il percorso nel repository alla directory principale che contiene la configurazione da sincronizzare. Questo campo è facoltativo e il valore predefinito è la directory radice (/) del repository.

    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

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

      Questo campo è obbligatorio.

    • ROOT_EMAIL: se hai aggiunto gcpserviceaccount come ROOT_AUTH_TYPE, aggiungi l'indirizzo email del account di 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 tuo provider OCI deve utilizzare un certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominata cert. 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 di quelli che puoi aggiungere al campo spec, consulta Campi RootSync.

    Questo 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 dell'oggetto RootSync.
    • ROOT_FORMAT: aggiungi unstructured per utilizzare un repository non strutturato o aggiungi hierarchy per utilizzare un repository gerarchico. Questi valori sono sensibili alle maiuscole. Questo campo è facoltativo e il valore predefinito è hierarchy. Ti consigliamo di aggiungere unstructured perché questo formato ti consente di organizzare le configurazioni nel modo più conveniente per te.
    • ROOT_HELM_REPOSITORY: l'URL del repository Helm da utilizzare come repository radice. 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 tuo grafico Helm. Questo campo è obbligatorio.
    • HELM_CHART_VERSION: la versione del grafico. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzata l'ultima versione.
    • HELM_RELEASE_NAME: il nome della release di 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 contengono namespace: {{ .Release.Namespace }} nei relativi modelli. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzato lo spazio dei nomi predefinito config-management-system.
    • HELM_INCLUDE_CRDS: impostalo su true se vuoi che il modello Helm generi anche una 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 che accompagnano il grafico Helm. Formatta questo campo nello stesso modo del file values.yaml del grafico Helm. Questo campo è facoltativo.

    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: Non utilizzare l'autenticazione
      • token: utilizza un nome utente e una password per accedere a un repository Helm privato.
      • 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 Federation per GKE non è abilitata nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un'immagine.

      Questo campo è obbligatorio.

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

    • ROOT_SECRET_NAME: aggiungi il nome del secret se token è ROOT_AUTH_TYPE. Questo campo è facoltativo.

    • ROOT_CA_CERT_SECRET_NAME: aggiungi il nome del tuo secret. Se questo campo è impostato, il provider Helm deve utilizzare un certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominata cert. 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 di quelli che puoi aggiungere al campo spec, consulta Campi RootSync.

    Questo manifest crea un oggetto RootSync che utilizza Helm come origine.

  4. Applica le modifiche:

    kubectl apply -f root-sync.yaml

Verificare lo stato di sincronizzazione del repository radice

Puoi utilizzare il comando nomos status per esaminare lo stato di sincronizzazione del repository radice:

nomos status

Dovresti vedere un output simile al seguente esempio:

my_managed_cluster-1
  --------------------
  <root>   git@github.com:foo-corp/acme/admin@main
  SYNCED   f52a11e4

Verificare l'installazione di RootSync

Quando crei un oggetto RootSync, Config Sync crea un riconciliatore con il 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 lo stato del deployment di 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 al seguente esempio:

NAME              READY   UP-TO-DATE   AVAILABLE   AGE
root-reconciler   1/1     1            1           3h42m

Per altri modi per esplorare lo stato dell'oggetto RootSync, vedi Monitoraggio di oggetti RootSync e RepoSync.

Dopo aver terminato la configurazione del repository principale, puoi facoltativamente scegliere di configurare la sincronizzazione da più repository. Questi repository sono utili se vuoi che un repository contenente configurazioni con ambito spazio dei nomi venga sincronizzato con uno spazio dei nomi specifico nei cluster.

Esegui l'upgrade di Config Sync

I passaggi per eseguire l'upgrade di Config Sync dipendono dalla versione a cui esegui l'upgrade e da quella di partenza. A partire dalla versione 1.20.0, Config Sync viene fornito come installazione autonoma senza l'operatore ConfigManagement. Se esegui l'upgrade da una versione precedente alla 1.20.0 alla versione 1.20.0 o successive, devi prima disinstallare l'operatore ConfigManagement prima di eseguire l'upgrade.

Se esegui l'upgrade da una versione non supportata, devi eseguire un upgrade passo passo con incrementi non superiori a tre versioni secondarie alla volta. Ad esempio, se la versione attuale di Config Sync è 1.14.0, esegui prima l'upgrade alla versione 1.17.0 e poi alla versione 1.20.0.

Disinstalla l'operatore ConfigManagement

Se esegui l'upgrade da una versione precedente alla 1.20.0 alla versione 1.20.0 o successive, devi prima disinstallare l'operatore ConfigManagement prima di eseguire l'upgrade.

Puoi controllare se Config Management è installato sul tuo cluster eseguendo questo comando:

kubectl get configmanagement

Se l'output non è vuoto, Config Management è installato sul cluster. Per disinstallare Config Management, completa i seguenti passaggi per disinstallare Config Management ma lascia Config Sync installato sul cluster. Ti consigliamo di utilizzare nomos CLI per disinstallare l'operatore ConfigManagement perché ha un'interfaccia più ricca e una gestione degli errori più solida. Devi utilizzare lo script shell solo se non hai accesso a nomos CLI.

  1. Assicurati che la CLI nomos sia l'ultima versione.

  2. Esegui questo comando per aggiornare il cluster nel contesto kubectl corrente:

    nomos migrate --remove-configmanagement

script shell

Copia il seguente script shell in un file ed eseguilo per aggiornare il cluster nel contesto kubectl corrente.

 #!/bin/bash

 set -euox pipefail

 hnc_enabled="$(kubectl get configmanagements.configmanagement.gke.io config-management -o=jsonpath="{.spec.hierarchyController.enabled}" --ignore-not-found)"

 if [[ "${hnc_enabled}" == "true" ]]; then
   echo "Hierarchy Controller is enabled on the ConfigManagement object. It must be disabled before migrating."
   echo "This can be done by unsetting the spec.hierarchyController field on ConfigManagement."
   exit 1
 fi

 kubectl delete deployment -n config-management-system config-management-operator --ignore-not-found --cascade=foreground

 if kubectl get configmanagement config-management &> /dev/null ; then
   kubectl patch configmanagement config-management --type="merge" -p '{"metadata":{"finalizers":[]}}'
   kubectl delete configmanagement config-management --cascade=orphan --ignore-not-found
 fi

 kubectl delete clusterrolebinding config-management-operator --ignore-not-found
 kubectl delete clusterrole config-management-operator --ignore-not-found
 kubectl delete serviceaccount -n config-management-system config-management-operator --ignore-not-found
 kubectl delete customresourcedefinition configmanagements.configmanagement.gke.io --ignore-not-found

Installa la nuova versione di Config Sync

Per eseguire l'upgrade di Config Sync, completa i seguenti passaggi per ogni cluster registrato:

  1. Scarica il manifest di Config Sync e i comandi nomos per la nuova versione.

  2. Estrai l'archivio:

    tar -xzvf config-sync.tar.gz

  3. Nell'archivio estratto nel passaggio precedente, segui le istruzioni nel file README fornito per modificare la personalizzazione.

  4. Per aggiornare l'installazione di Config Sync, applica il manifest sottoposto a rendering che hai creato seguendo le istruzioni per README: 

    kubectl apply -f CONFIG_SYNC_MANIFEST

    Sostituisci CONFIG_SYNC_MANIFEST con il nome del manifest di rendering.

  5. Sostituisci il comando nomos su tutti i client con la nuova versione. Questa modifica garantisce che il comando nomos possa sempre ottenere lo stato di tutti i cluster registrati e convalidarne le configurazioni.

Disinstalla Config Sync

Per disinstallare Config Sync, completa i seguenti passaggi:

  1. Un amministratore centrale deve rimuovere il repository principale:

    1. Se hai attivato il webhook e vuoi conservare le risorse, disattiva la prevenzione della deriva per le risorse abbandonate. Se non hai attivato il webhook, non devi eseguire ulteriori passaggi per conservare le risorse.

    2. Elimina l'oggetto RootSync eseguendo questo comando:

      kubectl delete -f root-sync.yaml

  2. Rimuovi eventuali repository.

  3. Con i manifest che hai utilizzato per installare Config Sync, puoi anche disinstallare Config Sync.

       kubectl delete -f CONFIG_SYNC_MANIFEST --ignore-not-found

Passaggi successivi