Configurare la sincronizzazione da più fonti di riferimento

Questa pagina spiega come configurare più di un ambito principale e con ambito dello spazio dei nomi fonte attendibile mediante la creazione Oggetti RootSync e RepoSync.

Avere una fonte attendibile consente di sincronizzare con ambito cluster con ambito con ambito a livello di spazio dei nomi. Una fonte attendibile può utilizzare le credenziali di livello amministratore applicare criteri sugli spazi dei nomi delle applicazioni ed eseguire l'override delle modifiche locali che deviano dallo stato che hai dichiarato nelle tue configurazioni. Un amministratore centrale in genere disciplina le fonti di dati reali.

Le origini attendibili con ambito a livello di spazio dei nomi sono facoltative e possono contenere configurazioni basate sugli spazi dei nomi sincronizzati con uno specifico spazio dei nomi nei cluster. Puoi delegare l'impostazione controllo di una fonte attendibile con ambito dei nomi per gli utenti non amministrativi. Sebbene Config Sync rileva automaticamente le modifiche dalla fonte attendibile, puoi aggiungi un ulteriore livello di rilevamento della deviazione aggiungendo un webhook di ammissione a basata sullo spazio dei nomi. Per maggiori dettagli su come eseguire questa operazione, vedi Previeni la deviazione della configurazione.

Prima di iniziare

  • Crea o assicurati di avere accesso a un fonte di dati non strutturata che può contenere le configurazioni con cui Config Sync si sincronizza. Config Sync supporta Repository Git, grafici Helm e immagini OCI come fonte attendibile. Le origini attendibili con ambito a livello di spazio dei nomi devono utilizzare il formato non strutturato.
  • Crea o assicurati di avere accesso a un cluster che si trova in una versione Google Kubernetes Engine (GKE) Enterprise piattaforma e versione supportate e soddisfa i requisiti requisiti per Config Sync.

Limitazioni

Scegli il tuo metodo di configurazione preferito

Scegli tra uno dei due metodi per configurare le origini:

Controlla le origini in una fonte attendibile

Controlla le origini principali in una fonte attendibile

Config Sync supporta la sincronizzazione da più fonti attendibili. Il fulcro amministratore può utilizzare una fonte di riferimento principale per gestire tutte le altre. Poiché Config Sync gestisce gli oggetti RootSync, questo metodo impedisce qualsiasi modifiche alle configurazioni RootSync nel cluster.

Per utilizzare questo metodo, completa le seguenti attività:

  1. Salva uno dei seguenti manifest come root-sync.yaml. Utilizzare il file manifest che corrisponde al tipo di origine delle 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 del tuo sistema 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 poiché questo formato consente puoi organizzare le configurazioni nel modo che preferisci.
    • ROOT_REPOSITORY: aggiungi l'URL del repository Git a da usare come repository radice. 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 campo revision. Quando si utilizza un hash in versione 1.17.0 o successiva, deve essere un hash completo e non un abbreviata.
    • ROOT_BRANCH: aggiungi il ramo di il repository da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è master. A partire da Config Sync versione 1.17.0, ti consigliamo di utilizzare il campo revision per specificare un nome ramo la semplicità. Se il campo revision e il campo branch sono entrambi specificato, revision ha la precedenza su branch.
    • ROOT_DIRECTORY: aggiungi il percorso nel repository Git 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'autenticazione
      • ssh: usa una coppia di chiavi SSH
      • cookiefile: usa un cookiefile
      • token: utilizza un token
      • gcpserviceaccount: usa un account di servizio Google per accedere a Cloud Source Repositories.
      • gcenode: utilizza un account di servizio Google per accedere a un Cloud Source Repositories. Seleziona questa opzione solo se Workload Identity non è abilitato nel tuo cluster.

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

      Questo campo è obbligatorio.

    • ROOT_EMAIL: se hai aggiunto gcpserviceaccount come tuo ROOT_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. 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 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'istanza certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominata cert. Questo campo è facoltativo.

      Per saperne di più su come configurare l'oggetto Secret per la CA vedi Configurare l'operatore per un'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 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 del tuo sistema 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 poiché questo formato consente puoi organizzare le configurazioni nel modo che preferisci.
    • ROOT_IMAGE: l'URL dell'immagine OCI da utilizzare come repository root, ad esempio LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Per impostazione predefinita, l'immagine viene estratta dal tag latest, ma puoi recuperare le immagini in base a TAG o DIGEST. Specifica TAG o DIGEST in PACKAGE_NAME:
      • Per eseguire il pull per TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
      • Per eseguire il pull per DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
    • 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'autenticazione
      • gcenode: utilizza Account di servizio predefinito Compute Engine per accedere a un'immagine in Artifact Registry. Seleziona questa opzione solo se Workload Identity non è abilitato nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un dell'immagine.

      Questo campo è obbligatorio.

    • ROOT_EMAIL: se hai aggiunto gcpserviceaccount come tuo ROOT_AUTH_TYPE, aggiungi l'indirizzo email del tuo 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 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 saperne di più su come configurare l'oggetto Secret per la CA vedi Configurare l'operatore per un'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 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: 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 poiché questo formato consente puoi organizzare le configurazioni nel modo che preferisci.
    • ROOT_HELM_REPOSITORY: l'URL dell'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 protocollo. Questo campo è obbligatorio.
    • HELM_CHART_NAME: aggiungi il nome del tuo Helm grafico. Questo campo è obbligatorio.
    • HELM_CHART_VERSION: la versione del grafico. Questo campo è facoltativo. Se non viene specificato alcun valore, l'ultima versione è in uso.
    • 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 contengono namespace: {{ .Release.Namespace }} nei modelli. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzato lo spazio dei nomi predefinito config-management-system.
    • HELM_INCLUDE_CRDS: imposta su true se vuoi il modello Helm per generare anche una CustomResourceDefinition. Questo è 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 usare l'autenticazione
      • token: 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 Workload Identity non è abilitato nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un dell'immagine.

      Questo campo è obbligatorio.

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

    • ROOT_SECRET_NAME: aggiungi nome del tuo secret se token è l'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'istanza certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominata cert. Questo campo è facoltativo.

    Per saperne di più su come configurare l'oggetto Secret per la CA vedi Configurare l'operatore per un'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.

  2. Esegui il commit delle modifiche alla fonte attendibile principale:

     git add .
 git commit -m 'Setting up a new root source of truth.'
 git push

  3. Puoi ripetere i passaggi precedenti se devi configurare più origini principali. Puoi inoltre memorizzare le configurazioni di più oggetti RootSync in una cartella sorgente attendibile sincronizzata da un altro oggetto RootSync, per gestire più Esegui il RootSync degli oggetti a livello centrale in modo GitOps.

Controlla gli oggetti con ambito dello spazio dei nomi in un'origine attendibile principale

Le fonti di dati attendibili con ambito a livello di spazio dei nomi possono essere gestite da una fonte attendibile. Poiché le origini con ambito dello spazio dei nomi sono gestite da Config Sync, questo metodo impedisce qualsiasi modifica locale alle definizioni dell'origine basate sullo spazio dei nomi.

Per utilizzare questo metodo, completa le seguenti attività:

  1. Nella fonte attendibile principale, dichiara una configurazione namespace:

    # ROOT_SOURCE/namespaces/NAMESPACE/namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: NAMESPACE

    Sostituisci NAMESPACE con un nome per lo spazio dei nomi.

  2. Nella fonte principale di dati, crea una delle seguenti RepoSync nello stesso spazio dei nomi. Utilizza il manifest che corrisponde all'origine tipo per le tue configurazioni:

    Git

    #ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: git
  # Since this is for a namespace repository, the format is unstructured
  sourceFormat: unstructured
  git:
    repo: NAMESPACE_REPOSITORY
    revision: NAMESPACE_REVISION
    branch: NAMESPACE_BRANCH
    dir: "NAMESPACE_DIRECTORY"
    auth: NAMESPACE_AUTH_TYPE
    gcpServiceAccountEmail: NAMESPACE_EMAIL
    secretRef:
      name: NAMESPACE_SECRET_NAME
    noSSLVerify: NAMESPACE_NO_SSL_VERIFY
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME

    Sostituisci quanto segue:

    • REPO_SYNC_NAME: aggiungi il nome del tuo RepoSync . Il nome deve essere univoco in tutto lo spazio dei nomi.
    • NAMESPACE: aggiungi il nome dello spazio dei nomi.
    • NAMESPACE_REPOSITORY: aggiungi l'URL del repository Git a da utilizzare come repository dello spazio dei nomi. Puoi inserire gli URL utilizzando il protocollo HTTPS HTTP(S) o SSH. Ad esempio: https://github.com/GoogleCloudPlatform/anthos-config-management-samples usi il protocollo HTTPS. Se non inserisci un protocollo, l'URL viene trattato come URL HTTPS. Questo campo è obbligatorio.
    • NAMESPACE_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 campo revision. Quando si utilizza un hash in versione 1.17.0 o successiva, deve essere un hash completo e non un abbreviata.
    • NAMESPACE_BRANCH: aggiungi il ramo di il repository da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è master. A partire da Config Sync versione 1.17.0, ti consigliamo di utilizzare il campo revision per specificare un nome ramo la semplicità. Se il campo revision e il campo branch sono entrambi specificato, revision ha la precedenza su branch.

    • NAMESPACE_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: non usare l'autenticazione
      • ssh: usa una coppia di chiavi SSH
      • cookiefile: usa un cookiefile
      • token: utilizza un token
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un un repository in Cloud Source Repositories.

      • gcenode: usa un account di servizio Google per accedere a un repository in Cloud Source Repositories. Seleziona questa opzione solo se Workload Identity non è abilitato nel tuo cluster.

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

      Questo campo è obbligatorio.

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

    • NAMESPACE_SECRET_NAME: aggiungi il nome che intendi assegnare al tuo secret. Questo campo è facoltativo.

    • NAMESPACE_NO_SSL_VERIFY: per disattivare la verifica del certificato SSL, imposta questo campo su true. Il valore predefinito è false.

    • NAMESPACE_CA_CERT_SECRET_NAME: aggiungi il nome del tuo Secret. Se questo campo è impostato, il tuo provider Git deve utilizzare un'istanza certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominata cert. Questo campo è facoltativo.

      Per saperne di più su come configurare l'oggetto Secret per la CA vedi Configurare l'operatore per un'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo dei campi che che è possibile aggiungere al campo spec, consulta Campi RepoSync.

    OCI

    # ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: oci
  # Since this is for a namespace repository, the format is unstructured
  sourceFormat: unstructured
  oci:
    image: NAMESPACE_IMAGE
    dir: NAMESPACE_DIRECTORY
    auth: NAMESPACE_AUTH_TYPE
    gcpServiceAccountEmail: NAMESPACE_EMAIL
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME

    Sostituisci quanto segue:

    • REPO_SYNC_NAME: aggiungi il nome del tuo RepoSync . Il nome deve essere univoco in tutto lo spazio dei nomi.
    • NAMESPACE: aggiungi il nome dello spazio dei nomi.

    • NAMESPACE_IMAGE: l'URL dell'immagine OCI da utilizzare come origine dello spazio dei nomi, ad esempio LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Per impostazione predefinita, l'immagine viene estratta dal tag latest, ma puoi recuperare le immagini in base a TAG o DIGEST. Specifica TAG o DIGEST in PACKAGE_NAME:

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

    • NAMESPACE_DIRECTORY: aggiungi il percorso nell'origine a la directory principale che contiene la configurazione da sincronizzare a. Questo campo è facoltativo e il valore predefinito è la directory radice (/) di la fonte.

    • NAMESPACE_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

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

      Questo campo è obbligatorio.

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

    • NAMESPACE_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 in una chiave denominata cert. Questo campo è facoltativo.

      Per saperne di più su come configurare l'oggetto Secret per la CA vedi Configurare l'operatore per un'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.

    Helm

    # ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: helm
  # Since this is for a namespace repository, the format is unstructured
  sourceFormat: unstructured
  helm:
    repo: NAMESPACE_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: NAMESPACE_AUTH_TYPE
      gcpServiceAccountEmail: NAMESPACE_EMAIL
      secretRef:
        name: NAMESPACE_SECRET_NAME
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME

    Sostituisci quanto segue:

    • REPO_SYNC_NAME: aggiungi il nome del tuo RepoSync . Il nome deve essere univoco in tutto lo spazio dei nomi.
    • NAMESPACE: aggiungi il nome dello spazio dei nomi.
    • NAMESPACE_REPOSITORY: l'URL dell'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 protocollo. Questo campo è obbligatorio.
    • HELM_CHART_NAME: aggiungi il nome del tuo Helm grafico. Questo campo è obbligatorio.
    • HELM_CHART_VERSION: la versione del grafico. Questo campo è facoltativo. Se non viene specificato alcun valore, l'ultima versione è in uso.
    • 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 contengono namespace: {{ .Release.Namespace }} nei modelli. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzato lo spazio dei nomi predefinito config-management-system.
    • HELM_INCLUDE_CRDS: imposta su true se vuoi il modello Helm per generare anche una CustomResourceDefinition. Questo è 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 nello stesso modo come file helm chart's values.yaml. Questo campo è facoltativo.

    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: non usare l'autenticazione
      • token: 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 Workload Identity non è abilitato nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un dell'immagine.

      Questo campo è obbligatorio.

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

    • NAMESPACE_SECRET_NAME: aggiungi nome del tuo secret se token è l'ROOT_AUTH_TYPE. Questo campo è facoltativo.

    • NAMESPACE_CA_CERT_SECRET_NAME: aggiungi il nome del tuo Secret. Se questo campo è impostato, il provider Helm deve utilizzare un'istanza certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominata cert. Questo campo è facoltativo.

      Per saperne di più su come configurare l'oggetto Secret per la CA vedi Configurare l'operatore per un'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.

  3. Se utilizzi gcpserviceaccount come tipo di autenticazione e non hai Workload Identity abilitato, devi creare un'istanza Associazione dei criteri IAM tra l'account di servizio Kubernetes per ogni spazio dei nomi e l'account di servizio. Consulta Concedi l'accesso a Git per istruzioni su come creare questa associazione.

  4. Nell'origine principale, dichiara una configurazione RoleBinding che concede il Autorizzazione dell'account di servizio SERVICE_ACCOUNT_NAME per per gestire gli oggetti nello spazio dei nomi. Config Sync crea automaticamente l'account di servizio SERVICE_ACCOUNT_NAME quando La configurazione di RepoSync è sincronizzata con il cluster.

    Un RoleBinding può fare riferimento a un Role nello stesso spazio dei nomi. In alternativa, un RoleBinding può fare riferimento a un ClusterRole e associarlo a ClusterRole lo spazio dei nomi di RoleBinding. Sebbene sia necessario rispettare le principio del privilegio minimo concedendo autorizzazioni granulari a un Role definito dall'utente, puoi definire un ClusterRole o utilizza ruoli rivolti agli utenti, e fare riferimento allo stesso ClusterRole in più RoleBindings diversi.

    ClusterRole predefiniti

    Puoi dichiarare un RoleBinding che fa riferimento a un ClusterRole predefinito, per ad esempio admin o edit. Per saperne di più, vedi Ruoli rivolti agli utenti.

    # ROOT_REPO/namespaces/NAMESPACE/sync-rolebinding.yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: syncs-repo
  namespace: NAMESPACE
subjects:
- kind: ServiceAccount
  name: SERVICE_ACCOUNT_NAME
  namespace: config-management-system
roleRef:
  kind: ClusterRole
  name: CLUSTERROLE_NAME
  apiGroup: rbac.authorization.k8s.io

    Sostituisci quanto segue:

    • NAMESPACE: aggiungi il nome dello spazio dei nomi.
    • SERVICE_ACCOUNT_NAME: aggiungi il nome del l'account di servizio del riconciliatore. Se il nome RepoSync è repo-sync, SERVICE_ACCOUNT_NAME è ns-reconciler-NAMESPACE. Altrimenti, ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Ad esempio, se il tuo nome RepoSync è prod, la classe SERVICE_ACCOUNT_NAME sarebbe ns-reconciler-NAMESPACE-prod-4. Il numero intero 4 viene utilizzato perché prod contiene 4 caratteri.
    • CLUSTERROLE_NAME: aggiungi il nome del valore predefinito ClusterRole.

    Ruoli definiti dall'utente

    Puoi dichiarare ClusterRole o Role concedendo un elenco di autorizzazioni per ogni risorsa gestita dall'oggetto RepoSync. Ciò consente autorizzazioni granulari. Consulta fare riferimento alle risorse per ulteriori dettagli.

    Ad esempio, la seguente ClusterRole o Role concede le autorizzazioni a gestire gli oggetti Deployment e ServiceAccount.

    # ROOT_REPO/namespaces/NAMESPACE/sync-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ROLE_KIND
metadata:
  namespace: NAMESPACE # only set this field for a 'Role'
  name: RECONCILER_ROLE
rules:
# Update 'apiGroups' and 'resources' to reference actual resources managed by 'RepoSync'.
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["*"]
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["*"]

    Per dichiarare un RoleBinding che fa riferimento a ClusterRole o Role, crea l'oggetto seguente. RoleBinding concede autorizzazioni aggiuntive a Consenti a Config Sync di gestire le risorse con ambito dello spazio dei nomi per una specifica RepoSync.

    # ROOT_REPO/namespaces/NAMESPACE/sync-rolebinding.yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: syncs-repo
  namespace: NAMESPACE
subjects:
- kind: ServiceAccount
  name: SERVICE_ACCOUNT_NAME
  namespace: config-management-system
roleRef:
  kind: ROLE_KIND
  name: RECONCILER_ROLE
  apiGroup: rbac.authorization.k8s.io

    Sostituisci quanto segue:

    • ROLE_KIND: imposta ClusterRole o Role.
    • NAMESPACE: aggiungi il nome dello spazio dei nomi.
    • SERVICE_ACCOUNT_NAME: aggiungi il nome del l'account di servizio del riconciliatore. Se il nome RepoSync è repo-sync, SERVICE_ACCOUNT_NAME è ns-reconciler-NAMESPACE. Altrimenti, ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Ad esempio, se il tuo nome RepoSync è prod, la classe SERVICE_ACCOUNT_NAME sarebbe ns-reconciler-NAMESPACE-prod-4. Il numero intero 4 viene utilizzato perché prod contiene 4 caratteri.
    • RECONCILER_ROLE: aggiungi il nome del ClusterRole o Role.

  5. Esegui il commit delle modifiche alla fonte attendibile principale:

     git add .
 git commit -m 'Setting up a new namespace-scoped source of truth.'
 git push

  6. Se necessario, crea un secret in base al metodo di autenticazione preferito. Se hai usato none come di autenticazione, puoi saltare questo passaggio.

    Il secret deve soddisfare i seguenti requisiti:

    • Crea il secret nello stesso spazio dei nomi di RepoSync.
    • Il nome del secret deve corrispondere al nome spec.git.secretRef che hai definito nel mese di repo-sync.yaml.
    • Devi aggiungere la chiave pubblica del secret al provider Git.

  7. Per verificare la configurazione, utilizza kubectl get su uno degli oggetti in dell'origine dello spazio dei nomi. Ad esempio:

    kubectl get rolebindings -n NAMESPACE

  8. Puoi ripetere i passaggi precedenti se devi configurare più di un'origine con ambito dello spazio dei nomi.

Controlla le origini basate sullo spazio dei nomi in un'origine con ambito spazio dei nomi

Config Sync supporta la sincronizzazione da più di una fonte attendibile con ambito dello spazio dei nomi per nello spazio dei nomi. Le origini attendibili con ambito a livello di spazio dei nomi possono essere gestite in una fonte attendibile con ambito dello spazio dei nomi in lo stesso spazio dei nomi.

Per utilizzare questo metodo, completa le seguenti attività:

  1. Nella fonte attendibile con ambito dello spazio dei nomi, crea una delle seguenti RepoSync nello stesso spazio dei nomi. Utilizza il manifest che corrisponde all'origine tipo per le tue configurazioni:

    Git

    #ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: git
  # Since this is for a namespace repository, the format is unstructured
  sourceFormat: unstructured
  git:
    repo: NAMESPACE_REPOSITORY
    revision: NAMESPACE_REVISION
    branch: NAMESPACE_BRANCH
    dir: "NAMESPACE_DIRECTORY"
    auth: NAMESPACE_AUTH_TYPE
    gcpServiceAccountEmail: NAMESPACE_EMAIL
    secretRef:
      name: NAMESPACE_SECRET_NAME
    noSSLVerify: NAMESPACE_NO_SSL_VERIFY
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME

    Sostituisci quanto segue:

    • REPO_SYNC_NAME: aggiungi il nome del tuo RepoSync . Il nome deve essere univoco in tutto lo spazio dei nomi.
    • NAMESPACE: aggiungi il nome dello spazio dei nomi.
    • NAMESPACE_REPOSITORY: aggiungi l'URL del repository Git a da utilizzare come repository dello spazio dei nomi. Puoi inserire gli URL utilizzando il protocollo HTTPS HTTP(S) o SSH. Ad esempio: https://github.com/GoogleCloudPlatform/anthos-config-management-samples usi il protocollo HTTPS. Se non inserisci un protocollo, l'URL viene trattato come URL HTTPS. Questo campo è obbligatorio.
    • NAMESPACE_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 campo revision. Quando si utilizza un hash in versione 1.17.0 o successiva, deve essere un hash completo e non un abbreviata.
    • NAMESPACE_BRANCH: aggiungi il ramo di il repository da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è master. A partire da Config Sync versione 1.17.0, ti consigliamo di utilizzare il campo revision per specificare un nome ramo la semplicità. Se il campo revision e il campo branch sono entrambi specificato, revision ha la precedenza su branch.

    • NAMESPACE_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: non usare l'autenticazione
      • ssh: usa una coppia di chiavi SSH
      • cookiefile: usa un cookiefile
      • token: utilizza un token
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un un repository in Cloud Source Repositories.

      • gcenode: usa un account di servizio Google per accedere a un repository in Cloud Source Repositories. Seleziona questa opzione solo se Workload Identity non è abilitato nel tuo cluster.

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

      Questo campo è obbligatorio.

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

    • NAMESPACE_SECRET_NAME: aggiungi il nome che intendi assegnare al tuo secret. Questo campo è facoltativo.

    • NAMESPACE_NO_SSL_VERIFY: per disattivare la verifica del certificato SSL, imposta questo campo su true. Il valore predefinito è false.

    • NAMESPACE_CA_CERT_SECRET_NAME: aggiungi il nome del tuo Secret. Se questo campo è impostato, il tuo provider Git deve utilizzare un'istanza certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominata cert. Questo campo è facoltativo.

      Per saperne di più su come configurare l'oggetto Secret per la CA vedi Configurare l'operatore per un'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo dei campi che che è possibile aggiungere al campo spec, consulta Campi RepoSync.

    OCI

    # ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: oci
  # Since this is for a namespace repository, the format is unstructured
  sourceFormat: unstructured
  oci:
    image: NAMESPACE_IMAGE
    dir: NAMESPACE_DIRECTORY
    auth: NAMESPACE_AUTH_TYPE
    gcpServiceAccountEmail: NAMESPACE_EMAIL
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME

    Sostituisci quanto segue:

    • REPO_SYNC_NAME: aggiungi il nome del tuo RepoSync . Il nome deve essere univoco in tutto lo spazio dei nomi.
    • NAMESPACE: aggiungi il nome dello spazio dei nomi.

    • NAMESPACE_IMAGE: l'URL dell'immagine OCI da utilizzare come origine dello spazio dei nomi, ad esempio LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Per impostazione predefinita, l'immagine viene estratta dal tag latest, ma puoi recuperare le immagini in base a TAG o DIGEST. Specifica TAG o DIGEST in PACKAGE_NAME:

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

    • NAMESPACE_DIRECTORY: aggiungi il percorso nell'origine a la directory principale che contiene la configurazione da sincronizzare a. Questo campo è facoltativo e il valore predefinito è la directory radice (/) di la fonte.

    • NAMESPACE_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

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

      Questo campo è obbligatorio.

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

    • NAMESPACE_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 in una chiave denominata cert. Questo campo è facoltativo.

      Per saperne di più su come configurare l'oggetto Secret per la CA vedi Configurare l'operatore per un'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.

    Helm

    # ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: helm
  # Since this is for a namespace repository, the format is unstructured
  sourceFormat: unstructured
  helm:
    repo: NAMESPACE_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: NAMESPACE_AUTH_TYPE
      gcpServiceAccountEmail: NAMESPACE_EMAIL
      secretRef:
        name: NAMESPACE_SECRET_NAME
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME

    Sostituisci quanto segue:

    • REPO_SYNC_NAME: aggiungi il nome del tuo RepoSync . Il nome deve essere univoco in tutto lo spazio dei nomi.
    • NAMESPACE: aggiungi il nome dello spazio dei nomi.
    • NAMESPACE_REPOSITORY: l'URL dell'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 protocollo. Questo campo è obbligatorio.
    • HELM_CHART_NAME: aggiungi il nome del tuo Helm grafico. Questo campo è obbligatorio.
    • HELM_CHART_VERSION: la versione del grafico. Questo campo è facoltativo. Se non viene specificato alcun valore, l'ultima versione è in uso.
    • 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 contengono namespace: {{ .Release.Namespace }} nei modelli. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzato lo spazio dei nomi predefinito config-management-system.
    • HELM_INCLUDE_CRDS: imposta su true se vuoi il modello Helm per generare anche una CustomResourceDefinition. Questo è 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 nello stesso modo come file helm chart's values.yaml. Questo campo è facoltativo.

    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: non usare l'autenticazione
      • token: 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 Workload Identity non è abilitato nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un dell'immagine.

      Questo campo è obbligatorio.

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

    • NAMESPACE_SECRET_NAME: aggiungi nome del tuo secret se token è l'ROOT_AUTH_TYPE. Questo campo è facoltativo.

    • NAMESPACE_CA_CERT_SECRET_NAME: aggiungi il nome del tuo Secret. Se questo campo è impostato, il provider Helm deve utilizzare un'istanza certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominata cert. Questo campo è facoltativo.

      Per saperne di più su come configurare l'oggetto Secret per la CA vedi Configurare l'operatore per un'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.

  2. Se utilizzi gcpserviceaccount come tipo di autenticazione e non hai Workload Identity abilitato, devi creare un'istanza Associazione dei criteri IAM tra l'account di servizio Kubernetes per ogni spazio dei nomi e l'account di servizio. Consulta Concedi l'accesso a Git per istruzioni su come creare questa associazione.

  3. Nell'origine principale, dichiara una configurazione RoleBinding che concede il Autorizzazione dell'account di servizio SERVICE_ACCOUNT_NAME per per gestire gli oggetti nello spazio dei nomi. Config Sync crea automaticamente l'account di servizio SERVICE_ACCOUNT_NAME quando La configurazione di RepoSync è sincronizzata con il cluster.

    Un RoleBinding può fare riferimento a un Role nello stesso spazio dei nomi. In alternativa, un RoleBinding può fare riferimento a un ClusterRole e associarlo a ClusterRole lo spazio dei nomi di RoleBinding. Sebbene sia necessario rispettare le principio del privilegio minimo concedendo autorizzazioni granulari a un Role definito dall'utente, puoi definire un ClusterRole o utilizza ruoli rivolti agli utenti, e fare riferimento allo stesso ClusterRole in più RoleBindings diversi.

    ClusterRole predefiniti

    Puoi dichiarare un RoleBinding che fa riferimento a un ClusterRole predefinito, per ad esempio admin o edit. Per saperne di più, vedi Ruoli rivolti agli utenti.

    # ROOT_REPO/namespaces/NAMESPACE/sync-rolebinding.yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: syncs-repo
  namespace: NAMESPACE
subjects:
- kind: ServiceAccount
  name: SERVICE_ACCOUNT_NAME
  namespace: config-management-system
roleRef:
  kind: ClusterRole
  name: CLUSTERROLE_NAME
  apiGroup: rbac.authorization.k8s.io

    Sostituisci quanto segue:

    • NAMESPACE: aggiungi il nome dello spazio dei nomi.
    • SERVICE_ACCOUNT_NAME: aggiungi il nome del l'account di servizio del riconciliatore. Se il nome RepoSync è repo-sync, SERVICE_ACCOUNT_NAME è ns-reconciler-NAMESPACE. Altrimenti, ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Ad esempio, se il tuo nome RepoSync è prod, la classe SERVICE_ACCOUNT_NAME sarebbe ns-reconciler-NAMESPACE-prod-4. Il numero intero 4 viene utilizzato perché prod contiene 4 caratteri.
    • CLUSTERROLE_NAME: aggiungi il nome del valore predefinito ClusterRole.

    Ruoli definiti dall'utente

    Puoi dichiarare ClusterRole o Role concedendo un elenco di autorizzazioni per ogni risorsa gestita dall'oggetto RepoSync. Ciò consente autorizzazioni granulari. Consulta fare riferimento alle risorse per ulteriori dettagli.

    Ad esempio, la seguente ClusterRole o Role concede le autorizzazioni a gestire gli oggetti Deployment e ServiceAccount.

    # ROOT_REPO/namespaces/NAMESPACE/sync-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ROLE_KIND
metadata:
  namespace: NAMESPACE # only set this field for a 'Role'
  name: RECONCILER_ROLE
rules:
# Update 'apiGroups' and 'resources' to reference actual resources managed by 'RepoSync'.
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["*"]
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["*"]

    Per dichiarare un RoleBinding che fa riferimento a ClusterRole o Role, crea l'oggetto seguente. RoleBinding concede autorizzazioni aggiuntive a Consenti a Config Sync di gestire le risorse con ambito dello spazio dei nomi per una specifica RepoSync.

    # ROOT_REPO/namespaces/NAMESPACE/sync-rolebinding.yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: syncs-repo
  namespace: NAMESPACE
subjects:
- kind: ServiceAccount
  name: SERVICE_ACCOUNT_NAME
  namespace: config-management-system
roleRef:
  kind: ROLE_KIND
  name: RECONCILER_ROLE
  apiGroup: rbac.authorization.k8s.io

    Sostituisci quanto segue:

    • ROLE_KIND: imposta ClusterRole o Role.
    • NAMESPACE: aggiungi il nome dello spazio dei nomi.
    • SERVICE_ACCOUNT_NAME: aggiungi il nome del l'account di servizio del riconciliatore. Se il nome RepoSync è repo-sync, SERVICE_ACCOUNT_NAME è ns-reconciler-NAMESPACE. Altrimenti, ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Ad esempio, se il tuo nome RepoSync è prod, la classe SERVICE_ACCOUNT_NAME sarebbe ns-reconciler-NAMESPACE-prod-4. Il numero intero 4 viene utilizzato perché prod contiene 4 caratteri.
    • RECONCILER_ROLE: aggiungi il nome del ClusterRole o Role.

  4. Esegui il commit delle modifiche alla fonte attendibile principale:

     git add .
 git commit -m 'Setting up a new namespace-scoped source of truth.'
 git push

  5. Se necessario, crea un secret in base al metodo di autenticazione preferito. Se hai usato none come di autenticazione, puoi saltare questo passaggio.

    Il secret deve soddisfare i seguenti requisiti:

    • Crea il secret nello stesso spazio dei nomi di RepoSync.
    • Il nome del secret deve corrispondere al nome spec.git.secretRef che hai definito nel mese di repo-sync.yaml.
    • Devi aggiungere la chiave pubblica del secret al provider Git.

  6. Per verificare la configurazione, utilizza kubectl get su uno degli oggetti in basata sullo spazio dei nomi. Ad esempio:

    kubectl get rolebindings -n NAMESPACE

  7. Puoi ripetere i passaggi precedenti se devi configurare più di un ambito basato sullo spazio dei nomi sorgente.

Controlla una fonte attendibile con l'API Kubernetes

Con questo metodo, l'amministratore centrale delega la dichiarazione di RootSync oggetti ad altri amministratori. Per RepoSync oggetti, lo spazio L'amministratore dichiara lo spazio dei nomi solo nella fonte attendibile principale e li delega dichiarazione dell'oggetto RepoSync all'operatore dell'applicazione.

Controllare più di una fonte attendibile principale

Altri amministratori possono controllare una fonte di riferimento principale svolgendo le seguenti attività:

  1. Salva uno dei seguenti manifest come root-sync.yaml. Utilizzare il file manifest che corrisponde al tipo di origine delle 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 del tuo sistema 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 poiché questo formato consente puoi organizzare le configurazioni nel modo che preferisci.
    • ROOT_REPOSITORY: aggiungi l'URL del repository Git a da usare come repository radice. 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 campo revision. Quando si utilizza un hash in versione 1.17.0 o successiva, deve essere un hash completo e non un abbreviata.
    • ROOT_BRANCH: aggiungi il ramo di il repository da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è master. A partire da Config Sync versione 1.17.0, ti consigliamo di utilizzare il campo revision per specificare un nome ramo la semplicità. Se il campo revision e il campo branch sono entrambi specificato, revision ha la precedenza su branch.
    • ROOT_DIRECTORY: aggiungi il percorso nel repository Git 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'autenticazione
      • ssh: usa una coppia di chiavi SSH
      • cookiefile: usa un cookiefile
      • token: utilizza un token
      • gcpserviceaccount: usa un account di servizio Google per accedere a Cloud Source Repositories.
      • gcenode: utilizza un account di servizio Google per accedere a un Cloud Source Repositories. Seleziona questa opzione solo se Workload Identity non è abilitato nel tuo cluster.

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

      Questo campo è obbligatorio.

    • ROOT_EMAIL: se hai aggiunto gcpserviceaccount come tuo ROOT_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. 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 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'istanza certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominata cert. Questo campo è facoltativo.

      Per saperne di più su come configurare l'oggetto Secret per la CA vedi Configurare l'operatore per un'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 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 del tuo sistema 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 poiché questo formato consente puoi organizzare le configurazioni nel modo che preferisci.
    • ROOT_IMAGE: l'URL dell'immagine OCI da utilizzare come repository root, ad esempio LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Per impostazione predefinita, l'immagine viene estratta dal tag latest, ma puoi recuperare le immagini in base a TAG o DIGEST. Specifica TAG o DIGEST in PACKAGE_NAME:
      • Per eseguire il pull per TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
      • Per eseguire il pull per DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
    • 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'autenticazione
      • gcenode: utilizza Account di servizio predefinito Compute Engine per accedere a un'immagine in Artifact Registry. Seleziona questa opzione solo se Workload Identity non è abilitato nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un dell'immagine.

      Questo campo è obbligatorio.

    • ROOT_EMAIL: se hai aggiunto gcpserviceaccount come tuo ROOT_AUTH_TYPE, aggiungi l'indirizzo email del tuo 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 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 saperne di più su come configurare l'oggetto Secret per la CA vedi Configurare l'operatore per un'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 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: 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 poiché questo formato consente puoi organizzare le configurazioni nel modo che preferisci.
    • ROOT_HELM_REPOSITORY: l'URL dell'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 protocollo. Questo campo è obbligatorio.
    • HELM_CHART_NAME: aggiungi il nome del tuo Helm grafico. Questo campo è obbligatorio.
    • HELM_CHART_VERSION: la versione del grafico. Questo campo è facoltativo. Se non viene specificato alcun valore, l'ultima versione è in uso.
    • 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 contengono namespace: {{ .Release.Namespace }} nei modelli. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzato lo spazio dei nomi predefinito config-management-system.
    • HELM_INCLUDE_CRDS: imposta su true se vuoi il modello Helm per generare anche una CustomResourceDefinition. Questo è 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 usare l'autenticazione
      • token: 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 Workload Identity non è abilitato nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un dell'immagine.

      Questo campo è obbligatorio.

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

    • ROOT_SECRET_NAME: aggiungi nome del tuo secret se token è l'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'istanza certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominata cert. Questo campo è facoltativo.

    Per saperne di più su come configurare l'oggetto Secret per la CA vedi Configurare l'operatore per un'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.

  2. Applica le modifiche:

    kubectl apply -f root-sync.yaml

  3. Puoi ripetere i passaggi precedenti se devi configurare più di una fonte attendibile principale.

Controlla le origini attendibili con ambito dello spazio dei nomi

Attività dell'amministratore centrale

L'amministratore centrale completa le seguenti attività:

  1. Nella fonte attendibile principale, dichiara una configurazione namespace per le origini basate sullo spazio dei nomi.

    # ROOT_REPO/namespaces/NAMESPACE/namespace.yaml
 apiVersion: v1
 kind: Namespace
 metadata:
   name: NAMESPACE

    Sostituisci NAMESPACE con un nome per lo spazio dei nomi.

  2. Nella fonte principale dei dati, dichiara un RoleBinding per fornire delle autorizzazioni degli operatori delle applicazioni. Utilizza le funzionalità di Prevenzione della riassegnazione RBAC per garantire che l'operatore dell'applicazione non possa applicare in un secondo momento un'associazione dei ruoli con autorizzazioni non concesse da questa associazione dei ruoli.

    Per dichiarare la risorsa RoleBinding, crea il seguente manifest:

    # ROOT_REPO/namespaces/NAMESPACE/operator-rolebinding.yaml
 kind: RoleBinding
 # Add RBAC escalation prevention
 apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   name: operator
   namespace: NAMESPACE
 subjects:
 - kind: User
   name: USERNAME
   apiGroup: rbac.authorization.k8s.io
 roleRef:
   kind: ClusterRole
   name: OPERATOR_ROLE
   apiGroup: rbac.authorization.k8s.io

    Sostituisci quanto segue:

    • NAMESPACE: aggiungi lo spazio dei nomi che hai creato nella fonte attendibile principale.
    • USERNAME: aggiungi il nome utente dell'operatore dell'applicazione.

    • OPERATOR_ROLE: in qualità di amministratore centrale, puoi impostare OPERATOR_ROLE per applicare in modo forzato i tipi di configurazioni che possono essere sincronizzati dall'origine con ambito dello spazio dei nomi. Puoi scegliere una delle seguenti opzioni: ruoli:

      • Un ClusterRole predefinito:

        • admin
        • edit

        Per saperne di più, vedi Ruoli rivolti agli utenti.

      • Un ClusterRole o Ruolo definito dall'utente dichiarato nella fonte attendibile principale. Questo consente autorizzazioni granulari.

  3. Esegui il commit delle modifiche alla fonte attendibile principale:

     git add .
 git commit -m 'Setting up new namespace-scoped source of truth.'
 git push

Attività dell'operatore dell'applicazione

L'operatore dell'applicazione può controllare le origini con ambito dello spazio dei nomi completando le seguenti attività:

  1. Dichiara una configurazione RoleBinding che concede il provisioning automatico Autorizzazione per l'account di servizio SERVICE_ACCOUNT_NAME per gestire gli oggetti nello spazio dei nomi. Config Sync crea automaticamente l'account di servizio SERVICE_ACCOUNT_NAME quando la configurazione di RepoSync viene sincronizzata con il cluster.

    Per dichiarare la risorsa RoleBinding, crea il seguente manifest:

    # sync-rolebinding.yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: syncs-repo
  namespace: NAMESPACE
subjects:
- kind: ServiceAccount
  name: SERVICE_ACCOUNT_NAME
  namespace: config-management-system
roleRef:
  kind: ClusterRole
  name: RECONCILER_ROLE
  apiGroup: rbac.authorization.k8s.io

    Sostituisci quanto segue:

    • NAMESPACE: aggiungi lo spazio dei nomi che hai creato nella fonte attendibile principale.
    • SERVICE_ACCOUNT_NAME: aggiungi il nome dell'account di servizio del riconciliatore. Se il nome RepoSync è repo-sync, SERVICE_ACCOUNT_NAME è ns-reconciler-NAMESPACE. Altrimenti, ns-reconciler-NAMESPACE-REPO_SYNC_NAME.
    • RECONCILER_ROLE: come operatore dell'applicazione che puoi impostare RECONCILER_ROLE per applicare quali tipi di configurazione possono essere sincronizzati dall'origine basata sullo spazio dei nomi. Tu può limitare ulteriormente l'insieme di autorizzazioni dell'amministratore centrale che ti ha concesso. Di conseguenza, questo ruolo non può essere più permissivo del OPERATOR_ROLE dichiarati dall'amministratore centrale nel sezione precedente.

  2. Applica la configurazione RoleBinding:

    kubectl apply -f sync-rolebinding.yaml

  3. Se necessario, crea un secret in base al metodo di autenticazione preferito. Se hai usato none come di autenticazione, puoi saltare questo passaggio.

    Il secret deve soddisfare i seguenti requisiti:

    • Crea il secret nello stesso spazio dei nomi di RepoSync.
    • Il nome del secret deve corrispondere al nome spec.git.secretRef che hai definito nel mese di root-sync.yaml.
    • Devi aggiungere la chiave pubblica del secret al provider Git.

  4. Dichiara una configurazione RepoSync:

    Git

    #ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: git
  # Since this is for a namespace repository, the format is unstructured
  sourceFormat: unstructured
  git:
    repo: NAMESPACE_REPOSITORY
    revision: NAMESPACE_REVISION
    branch: NAMESPACE_BRANCH
    dir: "NAMESPACE_DIRECTORY"
    auth: NAMESPACE_AUTH_TYPE
    gcpServiceAccountEmail: NAMESPACE_EMAIL
    secretRef:
      name: NAMESPACE_SECRET_NAME
    noSSLVerify: NAMESPACE_NO_SSL_VERIFY
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME

    Sostituisci quanto segue:

    • REPO_SYNC_NAME: aggiungi il nome del tuo RepoSync . Il nome deve essere univoco in tutto lo spazio dei nomi.
    • NAMESPACE: aggiungi il nome dello spazio dei nomi.
    • NAMESPACE_REPOSITORY: aggiungi l'URL del repository Git a da utilizzare come repository dello spazio dei nomi. Puoi inserire gli URL utilizzando il protocollo HTTPS HTTP(S) o SSH. Ad esempio: https://github.com/GoogleCloudPlatform/anthos-config-management-samples usi il protocollo HTTPS. Se non inserisci un protocollo, l'URL viene trattato come URL HTTPS. Questo campo è obbligatorio.
    • NAMESPACE_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 campo revision. Quando si utilizza un hash in versione 1.17.0 o successiva, deve essere un hash completo e non un abbreviata.
    • NAMESPACE_BRANCH: aggiungi il ramo di il repository da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è master. A partire da Config Sync versione 1.17.0, ti consigliamo di utilizzare il campo revision per specificare un nome ramo la semplicità. Se il campo revision e il campo branch sono entrambi specificato, revision ha la precedenza su branch.

    • NAMESPACE_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: non usare l'autenticazione
      • ssh: usa una coppia di chiavi SSH
      • cookiefile: usa un cookiefile
      • token: utilizza un token
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un un repository in Cloud Source Repositories.

      • gcenode: usa un account di servizio Google per accedere a un repository in Cloud Source Repositories. Seleziona questa opzione solo se Workload Identity non è abilitato nel tuo cluster.

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

      Questo campo è obbligatorio.

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

    • NAMESPACE_SECRET_NAME: aggiungi il nome che intendi assegnare al tuo secret. Questo campo è facoltativo.

    • NAMESPACE_NO_SSL_VERIFY: per disattivare la verifica del certificato SSL, imposta questo campo su true. Il valore predefinito è false.

    • NAMESPACE_CA_CERT_SECRET_NAME: aggiungi il nome del tuo Secret. Se questo campo è impostato, il tuo provider Git deve utilizzare un'istanza certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominata cert. Questo campo è facoltativo.

      Per saperne di più su come configurare l'oggetto Secret per la CA vedi Configurare l'operatore per un'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo dei campi che che è possibile aggiungere al campo spec, consulta Campi RepoSync.

    OCI

    # ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: oci
  # Since this is for a namespace repository, the format is unstructured
  sourceFormat: unstructured
  oci:
    image: NAMESPACE_IMAGE
    dir: NAMESPACE_DIRECTORY
    auth: NAMESPACE_AUTH_TYPE
    gcpServiceAccountEmail: NAMESPACE_EMAIL
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME

    Sostituisci quanto segue:

    • REPO_SYNC_NAME: aggiungi il nome del tuo RepoSync . Il nome deve essere univoco in tutto lo spazio dei nomi.
    • NAMESPACE: aggiungi il nome dello spazio dei nomi.

    • NAMESPACE_IMAGE: l'URL dell'immagine OCI da utilizzare come origine dello spazio dei nomi, ad esempio LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Per impostazione predefinita, l'immagine viene estratta dal tag latest, ma puoi recuperare le immagini in base a TAG o DIGEST. Specifica TAG o DIGEST in PACKAGE_NAME:

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

    • NAMESPACE_DIRECTORY: aggiungi il percorso nell'origine a la directory principale che contiene la configurazione da sincronizzare a. Questo campo è facoltativo e il valore predefinito è la directory radice (/) di la fonte.

    • NAMESPACE_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

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

      Questo campo è obbligatorio.

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

    • NAMESPACE_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 in una chiave denominata cert. Questo campo è facoltativo.

      Per saperne di più su come configurare l'oggetto Secret per la CA vedi Configurare l'operatore per un'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.

    Helm

    # ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: helm
  # Since this is for a namespace repository, the format is unstructured
  sourceFormat: unstructured
  helm:
    repo: NAMESPACE_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: NAMESPACE_AUTH_TYPE
      gcpServiceAccountEmail: NAMESPACE_EMAIL
      secretRef:
        name: NAMESPACE_SECRET_NAME
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME

    Sostituisci quanto segue:

    • REPO_SYNC_NAME: aggiungi il nome del tuo RepoSync . Il nome deve essere univoco in tutto lo spazio dei nomi.
    • NAMESPACE: aggiungi il nome dello spazio dei nomi.
    • NAMESPACE_REPOSITORY: l'URL dell'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 protocollo. Questo campo è obbligatorio.
    • HELM_CHART_NAME: aggiungi il nome del tuo Helm grafico. Questo campo è obbligatorio.
    • HELM_CHART_VERSION: la versione del grafico. Questo campo è facoltativo. Se non viene specificato alcun valore, l'ultima versione è in uso.
    • 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 contengono namespace: {{ .Release.Namespace }} nei modelli. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzato lo spazio dei nomi predefinito config-management-system.
    • HELM_INCLUDE_CRDS: imposta su true se vuoi il modello Helm per generare anche una CustomResourceDefinition. Questo è 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 nello stesso modo come file helm chart's values.yaml. Questo campo è facoltativo.

    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: non usare l'autenticazione
      • token: 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 Workload Identity non è abilitato nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un dell'immagine.

      Questo campo è obbligatorio.

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

    • NAMESPACE_SECRET_NAME: aggiungi nome del tuo secret se token è l'ROOT_AUTH_TYPE. Questo campo è facoltativo.

    • NAMESPACE_CA_CERT_SECRET_NAME: aggiungi il nome del tuo Secret. Se questo campo è impostato, il provider Helm deve utilizzare un'istanza certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA in una chiave denominata cert. Questo campo è facoltativo.

      Per saperne di più su come configurare l'oggetto Secret per la CA vedi Configurare l'operatore per un'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.

  5. Applica la configurazione RepoSync:

    kubectl apply -f repo-sync.yaml

  6. Per verificare la configurazione, utilizza kubectl get su uno degli oggetti in con ambito nello spazio dei nomi. Ad esempio:

    kubectl get rolebindings -n NAMESPACE

  7. Puoi ripetere i passaggi precedenti se devi configurare più fonti di riferimento basate sullo spazio dei nomi .

Verifica lo stato di sincronizzazione della fonte attendibile

Puoi utilizzare il comando nomos status per esaminare lo stato di sincronizzazione della fonte attendibile:

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
  --------------------
  bookstore  git@github.com:foo-corp/acme/bookstore@v1
  SYNCED     34d1a8c8

In questo output di esempio, l'origine con ambito dello spazio dei nomi, in questo caso un repository Git, è configurato per uno spazio dei nomi denominato bookstore.

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 una fonte attendibile 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 ulteriori modi per esaminare lo stato dell'oggetto RootSync, vedi Monitoraggio degli oggetti RootSync e RepoSync.

Verificare l'installazione di RepoSync

Quando crei un oggetto RepoSync, Config Sync crea un riconciliatore con Prefisso ns-reconciler-NAMESPACE, dove NAMESPACE è lo spazio dei nomi che hai creato con RepoSync l'oggetto in questione.

Puoi verificare che l'oggetto RepoSync funzioni correttamente controllando lo stato del deployment del riconciliatore dello spazio dei nomi:

kubectl get -n config-management-system deployment \
  -l configsync.gke.io/sync-name=REPO_SYNC_NAME \
  -l configsync.gke.io/sync-namespace=NAMESPACE

Sostituisci REPO_SYNC_NAME con il nome RepoSync e sostituisci NAMESPACE con lo spazio dei nomi che hai creato la tua fonte attendibile con ambito nello spazio dei nomi.

Per ulteriori modi per esplorare lo stato dell'oggetto RepoSync, vedi Esplorazione degli oggetti RootSync e RepoSync.

Rimuovere una fonte di riferimento

Seleziona la scheda Metodo di controllo centrale o Metodo API Kubernetes per visualizzarlo le relative istruzioni.

Metodo di controllo centrale

Se hai utilizzato il metodo Controlla le fonti attendibili in una fonte principale, un amministratore centrale può seguire i due passaggi seguenti per rimuovere un fonte attendibile:

  1. Decidi se vuoi eliminare o conservare le risorse gestite tramite gli oggetti RootSync e RepoSync.

    • Per eliminare tutte le risorse gestite dagli oggetti RootSync o RepoSync, sincronizzare l'oggetto RootSync o RepoSync con un'origine vuota. Ad esempio, un Repository GitHub senza configurazioni. Se l'oggetto RootSync o RepoSync contiene un altro oggetto RootSync o RepoSync, il file RootSync interno o RepoSync deve prima sincronizzarsi con un repository Git vuoto.

    • 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 è necessario eseguire altre per conservare le risorse.

  2. Rimuovi l'oggetto RootSync o RepoSync dalla fonte attendibile.

Metodo API Kubernetes

Se hai utilizzato le origini attendibili con ambito dello spazio dei nomi di controllo con l'API Kubernetes , gli operatori delle applicazioni possono utilizzare i seguenti passaggi per rimuovere fonte attendibile con ambito dello spazio dei nomi:

  1. Decidi se vuoi eliminare o conservare le risorse gestite tramite gli oggetti RootSync e RepoSync.

    • Per eliminare tutte le risorse gestite dagli oggetti RootSync o RepoSync, sincronizzare l'oggetto RootSync o RepoSync con un'origine vuota. Ad esempio, un Repository GitHub senza configurazioni. Se l'oggetto RootSync o RepoSync contiene un altro oggetto RootSync o RepoSync, il file RootSync interno o RepoSync deve prima sincronizzarsi con un repository Git vuoto.

    • Se hai attivato il webhook e vuoi conservare le risorse, disattiva la prevenzione della deviazione per le risorse abbandonate. Se non hai attivato il webhook, non è necessario eseguire altre per conservare le risorse.

  2. Elimina l'oggetto RootSync o RepoSync eseguendo questo comando:

    kubectl delete -f FILE_NAME

    Sostituisci FILE_NAME con il nome del tuo sistema RootSync o un file di configurazione RepoSync. Ad esempio, root-sync.yaml.

Passaggi successivi