Configurare la sincronizzazione da più fonti attendibili

In questa pagina viene spiegato come configurare più di una fonte di attendibilità con ambito radice e ambito spazio dei nomi creando oggetti RootSync e RepoSync.

Una fonte attendibile principale ti consente di sincronizzare le configurazioni con ambito cluster e con ambito di spazio dei nomi. Una fonte attendibile principale può utilizzare le credenziali a livello di amministratore per applicare criteri negli spazi dei nomi delle applicazioni e sostituire le modifiche locali che deviano dallo stato dichiarato nelle configurazioni. Di solito un amministratore centrale regola le fonti radice dei dati.

Le origini dati basate sullo spazio dei nomi sono facoltative e possono contenere configurazioni basate sullo spazio dei nomi sincronizzate con un determinato spazio dei nomi nei cluster. Puoi delegare la configurazione e il controllo di una sorgente di dati basata sullo spazio dei nomi a utenti non amministrativi. Sebbene Config Sync rilevi automaticamente le modifiche dalla fonte attendibile, puoi aggiungere un ulteriore livello di rilevamento delle deviazioni aggiungendo un webhook di ammissione a una fonte di riferimento basata sullo spazio dei nomi. Per maggiori dettagli su come eseguire questa operazione, consulta Impedire la deriva della configurazione.

Prima di iniziare

  • Crea una fonte attendibile non strutturata, o assicurati di avere accesso, che può contenere le configurazioni con cui Config Sync esegue la sincronizzazione. Config Sync supporta repository Git, grafici Helm e immagini OCI come fonte di riferimento. Le origini attendibili basate sullo spazio dei nomi devono utilizzare il formato non strutturato.
  • Crea un cluster, o assicurati di avere accesso, su una piattaforma e una versione supportate della versione Google Kubernetes Engine (GKE) Enterprise e che soddisfa i requisiti di Config Sync.

Limitazioni

Scegli il tuo metodo di configurazione preferito

Scegli tra uno dei due metodi di configurazione delle origini:

Controlla le fonti in una fonte attendibile principale

Controlla le fonti radice in una fonte attendibile principale

Config Sync supporta la sincronizzazione da più fonti attendibili. L'amministratore centrale può utilizzare una fonte attendibile principale per gestire tutte le altre. Poiché Config Sync gestisce gli oggetti RootSync, questo metodo impedisce qualsiasi modifica locale alle configurazioni RootSync nel cluster.

Per utilizzare questo metodo, completa le seguenti attività:

  1. Salva uno dei seguenti manifest come root-sync.yaml. Utilizza la versione del manifest corrispondente al tipo di origine per le configurazioni.

    Git

    # root-sync.yaml
    apiVersion: configsync.gke.io/v1beta1
    kind: RootSync
    metadata:
      name: ROOT_SYNC_NAME
      namespace: config-management-system
    spec:
      sourceType: git
      sourceFormat: ROOT_FORMAT
      git:
        repo: ROOT_REPOSITORY
        revision: ROOT_REVISION
        branch: ROOT_BRANCH
        dir: ROOT_DIRECTORY
        auth: ROOT_AUTH_TYPE
        gcpServiceAccountEmail: ROOT_EMAIL
        secretRef:
          name: ROOT_SECRET_NAME
        noSSLVerify: ROOT_NO_SSL_VERIFY
        caCertSecretRef:
          name: ROOT_CA_CERT_SECRET_NAME
    

    Sostituisci quanto segue:

    • ROOT_SYNC_NAME: aggiungi il nome dell'oggetto RootSync.
    • ROOT_FORMAT: 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 ti consente di organizzare le configurazioni nel modo più comodo 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) da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è HEAD. A partire da Config Sync versione 1.17.0, puoi anche specificare un nome ramo nel campo revision. Quando utilizzi un hash nella versione 1.17.0 o successive, deve essere un hash completo e non una forma abbreviata.
    • ROOT_BRANCH: aggiungi il ramo del repository da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è master. A partire da Config Sync versione 1.17.0, consigliamo di utilizzare il campo revision per specificare un nome ramo per semplicità. Se sono specificati sia il campo revision che il campo branch, revision ha la precedenza su branch.
    • ROOT_DIRECTORY: aggiungi il percorso del repository Git alla directory radice contenente la configurazione da sincronizzare. Questo campo è facoltativo e il valore predefinito è la directory root (/) del repository.
    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: nessuna autenticazione
      • ssh: utilizza una coppia di chiavi SSH
      • cookiefile: usa un cookiefile
      • token: usa un token
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a Cloud Source Repositories.
      • gcenode: utilizza un account di servizio Google per accedere a Cloud Source Repositories. Seleziona questa opzione solo se Workload Identity non è abilitato nel tuo cluster.

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

      Questo campo è obbligatorio.

    • ROOT_EMAIL: se hai aggiunto gcpserviceaccount come 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 secret. Se questo campo è impostato, devi aggiungere la chiave pubblica del secret al provider Git. Questo campo è facoltativo.

    • ROOT_NO_SSL_VERIFY: per disabilitare 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 viene 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'operatore per un'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo dei campi che puoi aggiungere al campo spec, consulta Campi RootSync.

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

    OCI

    # root-sync.yaml
    apiVersion: configsync.gke.io/v1beta1
    kind: RootSync
    metadata:
      name: ROOT_SYNC_NAME
      namespace: config-management-system
    spec:
      sourceType: oci
      sourceFormat: ROOT_FORMAT
      oci:
        image: ROOT_IMAGE
        dir: ROOT_DIRECTORY
        auth: ROOT_AUTH_TYPE
        gcpServiceAccountEmail: ROOT_EMAIL
        caCertSecretRef:
          name: ROOT_CA_CERT_SECRET_NAME
    

    Sostituisci quanto segue:

    • ROOT_SYNC_NAME: aggiungi il nome dell'oggetto RootSync.
    • ROOT_FORMAT: 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 ti consente di organizzare le configurazioni nel modo più comodo per te.
    • ROOT_IMAGE: l'URL dell'immagine OCI da utilizzare come repository principale, 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 eseguire il pull in base a TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
      • Per eseguire il pull in base a DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
    • ROOT_DIRECTORY: aggiungi il percorso del repository alla directory radice contenente la configurazione da sincronizzare. Questo campo è facoltativo e il valore predefinito è la directory root (/) del repository.
    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: nessuna 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 non è abilitato 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 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 viene 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 scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'operatore per un'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo dei campi che puoi aggiungere al campo spec, consulta Campi RootSync.

    Questo manifest crea un oggetto RootSync che utilizza 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 poiché questo formato ti consente di organizzare le configurazioni nel modo più comodo per te.
    • ROOT_HELM_REPOSITORY: l'URL del repository Helm da utilizzare come repository principale. Puoi inserire gli URL utilizzando il protocollo HTTPS o SSH. Ad esempio, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilizza il protocollo HTTPS. Questo campo è obbligatorio.
    • HELM_CHART_NAME: aggiungi il nome del grafico Helm. Questo campo è obbligatorio.
    • HELM_CHART_VERSION: la versione del grafico. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzata l'ultima versione.
    • HELM_RELEASE_NAME: il nome della release Helm. Questo campo è facoltativo.
    • HELM_RELEASE_NAMESPACE: lo spazio dei nomi target 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: 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 un CRD.
    • VALUE: valori da utilizzare al posto dei valori predefiniti che accompagnano il grafico Helm. Formatta questo campo come nel file helm chart's values.yaml. Questo campo è facoltativo.
    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: nessuna 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 non è abilitato 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 tuo account di servizio Google. Ad esempio, acm@PROJECT_ID.iam.gserviceaccount.com.

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

    • ROOT_CA_CERT_SECRET_NAME: aggiungi il nome del tuo Secret. Se questo campo viene 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'operatore per un'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo dei campi che puoi aggiungere al campo spec, consulta Campi RootSync.

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

  2. Esegui il commit delle modifiche nella 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 anche archiviare le configurazioni di più oggetti RootSync in una fonte attendibile principale sincronizzata da un altro oggetto RootSync, per gestire centralmente più oggetti RootSync in modo GitOps.

Controlla gli oggetti con ambito dello spazio dei nomi in una fonte attendibile principale

Le origini attendibili basate sullo spazio dei nomi possono essere gestite da una fonte attendibile principale. Poiché le origini basate sullo spazio dei nomi sono gestite da Config Sync, questo metodo impedisce eventuali modifiche locali alle definizioni delle origini 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 attendibile principale, crea uno dei seguenti oggetti RepoSync nello stesso spazio dei nomi. Utilizza il manifest che corrisponde al tipo di origine 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 dell'oggetto RepoSync. Il nome deve essere univoco all'interno dello spazio dei nomi.
    • NAMESPACE: aggiungi il nome dello spazio dei nomi.
    • NAMESPACE_REPOSITORY: aggiungi l'URL del repository Git da utilizzare come repository dello spazio dei nomi. Puoi inserire gli URL utilizzando il protocollo HTTPS o SSH. Ad esempio, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilizza il protocollo HTTPS. Se non inserisci un protocollo, l'URL viene considerato come un 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 specificare un nome ramo nel campo revision. Quando utilizzi un hash nella versione 1.17.0 o successive, deve essere un hash completo e non una forma abbreviata.
    • NAMESPACE_BRANCH: aggiungi il ramo del repository da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è master. A partire da Config Sync versione 1.17.0, consigliamo di utilizzare il campo revision per specificare un nome ramo per semplicità. Se sono specificati sia il campo revision che il campo branch, revision ha la precedenza su branch.
    • NAMESPACE_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: nessuna autenticazione
      • ssh: utilizza una coppia di chiavi SSH
      • cookiefile: usa un cookiefile
      • token: usa un token
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un repository in Cloud Source Repositories.
      • gcenode: utilizza 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 maggiori informazioni su questi tipi di autenticazione, consulta Concedere a Config Sync l'accesso di sola lettura a Git.

      Questo campo è obbligatorio.

    • NAMESPACE_EMAIL: se hai aggiunto gcpserviceaccount come 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 secret. Questo campo è facoltativo.

    • NAMESPACE_NO_SSL_VERIFY: per disabilitare 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 viene 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'operatore per un'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo di quelli che puoi 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 dell'oggetto RepoSync. Il nome deve essere univoco all'interno dello 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 estrarre le immagini in base a TAG o DIGEST. Specifica TAG o DIGEST nel campo PACKAGE_NAME:

      • Per eseguire il pull in base a TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
      • Per eseguire il pull in base a DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
    • NAMESPACE_DIRECTORY: aggiungi il percorso nell'origine alla directory principale contenente la configurazione da sincronizzare. Questo campo è facoltativo e la predefinita è la directory root (/) dell'origine.

    • NAMESPACE_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: nessuna 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 non è abilitato nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un'immagine.

      Questo campo è obbligatorio.

    • NAMESPACE_EMAIL: se hai aggiunto gcpserviceaccount come 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 viene 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 scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'operatore per un'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo dei campi che puoi aggiungere al campo spec, consulta 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 dell'oggetto RepoSync. Il nome deve essere univoco all'interno dello spazio dei nomi.
    • NAMESPACE: aggiungi il nome dello spazio dei nomi.
    • NAMESPACE_REPOSITORY: l'URL del repository Helm da utilizzare come repository principale. Puoi inserire gli URL utilizzando il protocollo HTTPS o SSH. Ad esempio, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilizza il protocollo HTTPS. Questo campo è obbligatorio.
    • HELM_CHART_NAME: aggiungi il nome del grafico Helm. Questo campo è obbligatorio.
    • HELM_CHART_VERSION: la versione del grafico. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzata l'ultima versione.
    • HELM_RELEASE_NAME: il nome della release Helm. Questo campo è facoltativo.
    • HELM_RELEASE_NAMESPACE: lo spazio dei nomi target 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: 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 un CRD.
    • VALUE: valori da utilizzare al posto dei valori predefiniti che accompagnano il grafico Helm. Formatta questo campo come nel file helm chart's values.yaml. Questo campo è facoltativo.
    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: nessuna 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 non è abilitato nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un'immagine.

      Questo campo è obbligatorio.

    • NAMESPACE_EMAIL: se hai aggiunto gcpserviceaccount come 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 il nome del tuo secret se token è ROOT_AUTH_TYPE. Questo campo è facoltativo.

    • NAMESPACE_CA_CERT_SECRET_NAME: aggiungi il nome del tuo Secret. Se questo campo viene 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'operatore per un'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo dei campi che puoi aggiungere al campo spec, consulta Campi RootSync.

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

  4. Nell'origine principale, dichiara una configurazione RoleBinding che concede all'account di servizio SERVICE_ACCOUNT_NAME l'autorizzazione 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.

    Un elemento RoleBinding può fare riferimento a un Role nello stesso spazio dei nomi. In alternativa, un RoleBinding può fare riferimento a un ClusterRole e associarlo ClusterRole allo spazio dei nomi di RoleBinding. Anche se devi rispettare il principio del privilegio minimo concedendo autorizzazioni granulari a un Role definito dall'utente, puoi definire un ClusterRole o utilizzare ruoli rivolti all'utente e fare riferimento allo stesso ClusterRole in più RoleBindings in diversi spazi dei nomi.

    ClusterRole predefiniti

    Puoi dichiarare un RoleBinding che fa riferimento a un ClusterRole predefinito, ad esempio admin o edit. Per scoprire di più, consulta 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 dell'account di servizio del riconciliatore. Se il nome del RepoSync è repo-sync, SERVICE_ACCOUNT_NAME è ns-reconciler-NAMESPACE. In caso contrario, è ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Ad esempio, se il nome del tuo RepoSync è prod, allora SERVICE_ACCOUNT_NAME sarà ns-reconciler-NAMESPACE-prod-4. Il numero intero 4 viene utilizzato poiché prod contiene 4 caratteri.
    • CLUSTERROLE_NAME: aggiungi il nome del ClusterRole predefinito.

    Ruoli definiti dall'utente

    Puoi dichiarare un oggetto ClusterRole o Role concedendo un elenco di autorizzazioni a ogni risorsa gestita dall'oggetto RepoSync. Ciò consente di avere autorizzazioni granulari. Per ulteriori dettagli, consulta la pagina Fare riferimento alle risorse.

    Ad esempio, l'elemento ClusterRole o Role seguente concede le autorizzazioni per 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. L'RoleBinding concede autorizzazioni aggiuntive per consentire a Config Sync di gestire le risorse con ambito dello spazio dei nomi per un compito 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 dell'account di servizio del riconciliatore. Se il nome del RepoSync è repo-sync, SERVICE_ACCOUNT_NAME è ns-reconciler-NAMESPACE. In caso contrario, è ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Ad esempio, se il nome del tuo RepoSync è prod, allora SERVICE_ACCOUNT_NAME sarà ns-reconciler-NAMESPACE-prod-4. Il numero intero 4 viene utilizzato poiché prod contiene 4 caratteri.
    • RECONCILER_ROLE: aggiungi il nome di ClusterRole o Role.
  5. Esegui il commit delle modifiche nella 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 che preferisci. Se hai utilizzato none come tipo di autenticazione, puoi saltare questo passaggio.

    Il secret deve soddisfare i seguenti requisiti:

    • Crea il secret nello stesso spazio dei nomi del RepoSync.
    • Il nome del secret deve corrispondere al nome spec.git.secretRef che hai definito in 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 nell'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 con ambito dello spazio dei nomi in un'origine con ambito dello spazio dei nomi

Config Sync supporta la sincronizzazione da più origini dati basate sullo spazio dei nomi per spazio dei nomi. Le origini dati basate sullo spazio dei nomi possono essere gestite in una fonte di riferimento con ambito dello spazio dei nomi all'interno dello stesso spazio dei nomi.

Per utilizzare questo metodo, completa le seguenti attività:

  1. Nella fonte attendibile basata sullo spazio dei nomi, crea uno dei seguenti oggetti RepoSync nello stesso spazio dei nomi. Utilizza il manifest che corrisponde al tipo di origine 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 dell'oggetto RepoSync. Il nome deve essere univoco all'interno dello spazio dei nomi.
    • NAMESPACE: aggiungi il nome dello spazio dei nomi.
    • NAMESPACE_REPOSITORY: aggiungi l'URL del repository Git da utilizzare come repository dello spazio dei nomi. Puoi inserire gli URL utilizzando il protocollo HTTPS o SSH. Ad esempio, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilizza il protocollo HTTPS. Se non inserisci un protocollo, l'URL viene considerato come un 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 specificare un nome ramo nel campo revision. Quando utilizzi un hash nella versione 1.17.0 o successive, deve essere un hash completo e non una forma abbreviata.
    • NAMESPACE_BRANCH: aggiungi il ramo del repository da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è master. A partire da Config Sync versione 1.17.0, consigliamo di utilizzare il campo revision per specificare un nome ramo per semplicità. Se sono specificati sia il campo revision che il campo branch, revision ha la precedenza su branch.
    • NAMESPACE_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: nessuna autenticazione
      • ssh: utilizza una coppia di chiavi SSH
      • cookiefile: usa un cookiefile
      • token: usa un token
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un repository in Cloud Source Repositories.
      • gcenode: utilizza 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 maggiori informazioni su questi tipi di autenticazione, consulta Concedere a Config Sync l'accesso di sola lettura a Git.

      Questo campo è obbligatorio.

    • NAMESPACE_EMAIL: se hai aggiunto gcpserviceaccount come 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 secret. Questo campo è facoltativo.

    • NAMESPACE_NO_SSL_VERIFY: per disabilitare 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 viene 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'operatore per un'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo di quelli che puoi 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 dell'oggetto RepoSync. Il nome deve essere univoco all'interno dello 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 estrarre le immagini in base a TAG o DIGEST. Specifica TAG o DIGEST nel campo PACKAGE_NAME:

      • Per eseguire il pull in base a TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
      • Per eseguire il pull in base a DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
    • NAMESPACE_DIRECTORY: aggiungi il percorso nell'origine alla directory principale contenente la configurazione da sincronizzare. Questo campo è facoltativo e la predefinita è la directory root (/) dell'origine.

    • NAMESPACE_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: nessuna 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 non è abilitato nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un'immagine.

      Questo campo è obbligatorio.

    • NAMESPACE_EMAIL: se hai aggiunto gcpserviceaccount come 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 viene 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 scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'operatore per un'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo dei campi che puoi aggiungere al campo spec, consulta 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 dell'oggetto RepoSync. Il nome deve essere univoco all'interno dello spazio dei nomi.
    • NAMESPACE: aggiungi il nome dello spazio dei nomi.
    • NAMESPACE_REPOSITORY: l'URL del repository Helm da utilizzare come repository principale. Puoi inserire gli URL utilizzando il protocollo HTTPS o SSH. Ad esempio, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilizza il protocollo HTTPS. Questo campo è obbligatorio.
    • HELM_CHART_NAME: aggiungi il nome del grafico Helm. Questo campo è obbligatorio.
    • HELM_CHART_VERSION: la versione del grafico. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzata l'ultima versione.
    • HELM_RELEASE_NAME: il nome della release Helm. Questo campo è facoltativo.
    • HELM_RELEASE_NAMESPACE: lo spazio dei nomi target 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: 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 un CRD.
    • VALUE: valori da utilizzare al posto dei valori predefiniti che accompagnano il grafico Helm. Formatta questo campo come nel file helm chart's values.yaml. Questo campo è facoltativo.
    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: nessuna 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 non è abilitato nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un'immagine.

      Questo campo è obbligatorio.

    • NAMESPACE_EMAIL: se hai aggiunto gcpserviceaccount come 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 il nome del tuo secret se token è ROOT_AUTH_TYPE. Questo campo è facoltativo.

    • NAMESPACE_CA_CERT_SECRET_NAME: aggiungi il nome del tuo Secret. Se questo campo viene 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'operatore per un'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo dei campi che puoi aggiungere al campo spec, consulta Campi RootSync.

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

  3. Nell'origine principale, dichiara una configurazione RoleBinding che concede all'account di servizio SERVICE_ACCOUNT_NAME l'autorizzazione 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.

    Un elemento RoleBinding può fare riferimento a un Role nello stesso spazio dei nomi. In alternativa, un RoleBinding può fare riferimento a un ClusterRole e associarlo ClusterRole allo spazio dei nomi di RoleBinding. Anche se devi rispettare il principio del privilegio minimo concedendo autorizzazioni granulari a un Role definito dall'utente, puoi definire un ClusterRole o utilizzare ruoli rivolti all'utente e fare riferimento allo stesso ClusterRole in più RoleBindings in diversi spazi dei nomi.

    ClusterRole predefiniti

    Puoi dichiarare un RoleBinding che fa riferimento a un ClusterRole predefinito, ad esempio admin o edit. Per scoprire di più, consulta 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 dell'account di servizio del riconciliatore. Se il nome del RepoSync è repo-sync, SERVICE_ACCOUNT_NAME è ns-reconciler-NAMESPACE. In caso contrario, è ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Ad esempio, se il nome del tuo RepoSync è prod, allora SERVICE_ACCOUNT_NAME sarà ns-reconciler-NAMESPACE-prod-4. Il numero intero 4 viene utilizzato poiché prod contiene 4 caratteri.
    • CLUSTERROLE_NAME: aggiungi il nome del ClusterRole predefinito.

    Ruoli definiti dall'utente

    Puoi dichiarare un oggetto ClusterRole o Role concedendo un elenco di autorizzazioni a ogni risorsa gestita dall'oggetto RepoSync. Ciò consente di avere autorizzazioni granulari. Per ulteriori dettagli, consulta la pagina Fare riferimento alle risorse.

    Ad esempio, l'elemento ClusterRole o Role seguente concede le autorizzazioni per 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. L'RoleBinding concede autorizzazioni aggiuntive per consentire a Config Sync di gestire le risorse con ambito dello spazio dei nomi per un compito 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 dell'account di servizio del riconciliatore. Se il nome del RepoSync è repo-sync, SERVICE_ACCOUNT_NAME è ns-reconciler-NAMESPACE. In caso contrario, è ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Ad esempio, se il nome del tuo RepoSync è prod, allora SERVICE_ACCOUNT_NAME sarà ns-reconciler-NAMESPACE-prod-4. Il numero intero 4 viene utilizzato poiché prod contiene 4 caratteri.
    • RECONCILER_ROLE: aggiungi il nome di ClusterRole o Role.
  4. Esegui il commit delle modifiche nella 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 che preferisci. Se hai utilizzato none come tipo di autenticazione, puoi saltare questo passaggio.

    Il secret deve soddisfare i seguenti requisiti:

    • Crea il secret nello stesso spazio dei nomi del RepoSync.
    • Il nome del secret deve corrispondere al nome spec.git.secretRef che hai definito in 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 nell'origine dati basata sullo spazio dei nomi. Ad esempio:

    kubectl get rolebindings -n NAMESPACE
    
  7. Puoi ripetere i passaggi precedenti se devi configurare più di un'origine con ambito dello spazio dei nomi.

Controlla una fonte attendibile con l'API Kubernetes

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

Controllare più di una fonte di dati principale

Altri amministratori possono controllare una fonte attendibile principale completando le seguenti attività:

  1. Salva uno dei seguenti manifest come root-sync.yaml. Utilizza la versione del manifest corrispondente al tipo di origine per le configurazioni.

    Git

    # root-sync.yaml
    apiVersion: configsync.gke.io/v1beta1
    kind: RootSync
    metadata:
      name: ROOT_SYNC_NAME
      namespace: config-management-system
    spec:
      sourceType: git
      sourceFormat: ROOT_FORMAT
      git:
        repo: ROOT_REPOSITORY
        revision: ROOT_REVISION
        branch: ROOT_BRANCH
        dir: ROOT_DIRECTORY
        auth: ROOT_AUTH_TYPE
        gcpServiceAccountEmail: ROOT_EMAIL
        secretRef:
          name: ROOT_SECRET_NAME
        noSSLVerify: ROOT_NO_SSL_VERIFY
        caCertSecretRef:
          name: ROOT_CA_CERT_SECRET_NAME
    

    Sostituisci quanto segue:

    • ROOT_SYNC_NAME: aggiungi il nome dell'oggetto RootSync.
    • ROOT_FORMAT: 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 ti consente di organizzare le configurazioni nel modo più comodo 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) da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è HEAD. A partire da Config Sync versione 1.17.0, puoi anche specificare un nome ramo nel campo revision. Quando utilizzi un hash nella versione 1.17.0 o successive, deve essere un hash completo e non una forma abbreviata.
    • ROOT_BRANCH: aggiungi il ramo del repository da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è master. A partire da Config Sync versione 1.17.0, consigliamo di utilizzare il campo revision per specificare un nome ramo per semplicità. Se sono specificati sia il campo revision che il campo branch, revision ha la precedenza su branch.
    • ROOT_DIRECTORY: aggiungi il percorso del repository Git alla directory radice contenente la configurazione da sincronizzare. Questo campo è facoltativo e il valore predefinito è la directory root (/) del repository.
    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: nessuna autenticazione
      • ssh: utilizza una coppia di chiavi SSH
      • cookiefile: usa un cookiefile
      • token: usa un token
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a Cloud Source Repositories.
      • gcenode: utilizza un account di servizio Google per accedere a Cloud Source Repositories. Seleziona questa opzione solo se Workload Identity non è abilitato nel tuo cluster.

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

      Questo campo è obbligatorio.

    • ROOT_EMAIL: se hai aggiunto gcpserviceaccount come 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 secret. Se questo campo è impostato, devi aggiungere la chiave pubblica del secret al provider Git. Questo campo è facoltativo.

    • ROOT_NO_SSL_VERIFY: per disabilitare 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 viene 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'operatore per un'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo dei campi che puoi aggiungere al campo spec, consulta Campi RootSync.

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

    OCI

    # root-sync.yaml
    apiVersion: configsync.gke.io/v1beta1
    kind: RootSync
    metadata:
      name: ROOT_SYNC_NAME
      namespace: config-management-system
    spec:
      sourceType: oci
      sourceFormat: ROOT_FORMAT
      oci:
        image: ROOT_IMAGE
        dir: ROOT_DIRECTORY
        auth: ROOT_AUTH_TYPE
        gcpServiceAccountEmail: ROOT_EMAIL
        caCertSecretRef:
          name: ROOT_CA_CERT_SECRET_NAME
    

    Sostituisci quanto segue:

    • ROOT_SYNC_NAME: aggiungi il nome dell'oggetto RootSync.
    • ROOT_FORMAT: 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 ti consente di organizzare le configurazioni nel modo più comodo per te.
    • ROOT_IMAGE: l'URL dell'immagine OCI da utilizzare come repository principale, 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 eseguire il pull in base a TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
      • Per eseguire il pull in base a DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
    • ROOT_DIRECTORY: aggiungi il percorso del repository alla directory radice contenente la configurazione da sincronizzare. Questo campo è facoltativo e il valore predefinito è la directory root (/) del repository.
    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: nessuna 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 non è abilitato 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 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 viene 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 scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'operatore per un'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo dei campi che puoi aggiungere al campo spec, consulta Campi RootSync.

    Questo manifest crea un oggetto RootSync che utilizza 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 poiché questo formato ti consente di organizzare le configurazioni nel modo più comodo per te.
    • ROOT_HELM_REPOSITORY: l'URL del repository Helm da utilizzare come repository principale. Puoi inserire gli URL utilizzando il protocollo HTTPS o SSH. Ad esempio, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilizza il protocollo HTTPS. Questo campo è obbligatorio.
    • HELM_CHART_NAME: aggiungi il nome del grafico Helm. Questo campo è obbligatorio.
    • HELM_CHART_VERSION: la versione del grafico. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzata l'ultima versione.
    • HELM_RELEASE_NAME: il nome della release Helm. Questo campo è facoltativo.
    • HELM_RELEASE_NAMESPACE: lo spazio dei nomi target 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: 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 un CRD.
    • VALUE: valori da utilizzare al posto dei valori predefiniti che accompagnano il grafico Helm. Formatta questo campo come nel file helm chart's values.yaml. Questo campo è facoltativo.
    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: nessuna 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 non è abilitato 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 tuo account di servizio Google. Ad esempio, acm@PROJECT_ID.iam.gserviceaccount.com.

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

    • ROOT_CA_CERT_SECRET_NAME: aggiungi il nome del tuo Secret. Se questo campo viene 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'operatore per un'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo dei campi che puoi aggiungere al campo spec, consulta Campi RootSync.

    Questo manifest crea un oggetto RootSync che utilizza 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 origini di verità basate sullo 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 con ambito dello 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 attendibile principale, dichiara un RoleBinding per concedere le autorizzazioni agli operatori dell'applicazione. Utilizza la prevenzione dell'escalation RBAC per assicurarti che l'operatore dell'applicazione non possa applicare in un secondo momento un'associazione dei ruoli con autorizzazioni non concesse da questa associazione di ruoli.

    Per dichiarare il 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 i tipi di configurazioni che possono essere sincronizzati dall'origine basata sullo spazio dei nomi. Puoi scegliere uno dei seguenti ruoli:

      • Un ClusterRole predefinito:

        • admin
        • edit

        Per scoprire di più, consulta Ruoli rivolti agli utenti.

      • Un ClusterRole o un Role definito dall'utente dichiarato nella fonte di riferimento principale. Questo ruolo consente autorizzazioni granulari.

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

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

Attività degli operatori dell'applicazione

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

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

    Per dichiarare il 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. In caso contrario, è ns-reconciler-NAMESPACE-REPO_SYNC_NAME.
    • RECONCILER_ROLE: in qualità di operatore dell'applicazione, puoi impostare RECONCILER_ROLE per applicare i tipi di configurazione che possono essere sincronizzati dall'origine con ambito dello spazio dei nomi. Puoi limitare ulteriormente solo l'insieme di autorizzazioni che ti è stato concesso dall'amministratore centrale. Di conseguenza, questo ruolo non può essere più permissivo del valore OPERATOR_ROLE dichiarato dall'amministratore centrale nella sezione precedente.
  2. Applica la configurazione di RoleBinding:

    kubectl apply -f sync-rolebinding.yaml
    
  3. Se necessario, crea un secret in base al metodo di autenticazione che preferisci. Se hai utilizzato none come tipo di autenticazione, puoi saltare questo passaggio.

    Il secret deve soddisfare i seguenti requisiti:

    • Crea il secret nello stesso spazio dei nomi del RepoSync.
    • Il nome del secret deve corrispondere al nome spec.git.secretRef che hai definito in root-sync.yaml.
    • Devi aggiungere la chiave pubblica del secret al provider Git.
  4. Dichiara una configurazione di 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 dell'oggetto RepoSync. Il nome deve essere univoco all'interno dello spazio dei nomi.
    • NAMESPACE: aggiungi il nome dello spazio dei nomi.
    • NAMESPACE_REPOSITORY: aggiungi l'URL del repository Git da utilizzare come repository dello spazio dei nomi. Puoi inserire gli URL utilizzando il protocollo HTTPS o SSH. Ad esempio, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilizza il protocollo HTTPS. Se non inserisci un protocollo, l'URL viene considerato come un 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 specificare un nome ramo nel campo revision. Quando utilizzi un hash nella versione 1.17.0 o successive, deve essere un hash completo e non una forma abbreviata.
    • NAMESPACE_BRANCH: aggiungi il ramo del repository da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è master. A partire da Config Sync versione 1.17.0, consigliamo di utilizzare il campo revision per specificare un nome ramo per semplicità. Se sono specificati sia il campo revision che il campo branch, revision ha la precedenza su branch.
    • NAMESPACE_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: nessuna autenticazione
      • ssh: utilizza una coppia di chiavi SSH
      • cookiefile: usa un cookiefile
      • token: usa un token
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un repository in Cloud Source Repositories.
      • gcenode: utilizza 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 maggiori informazioni su questi tipi di autenticazione, consulta Concedere a Config Sync l'accesso di sola lettura a Git.

      Questo campo è obbligatorio.

    • NAMESPACE_EMAIL: se hai aggiunto gcpserviceaccount come 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 secret. Questo campo è facoltativo.

    • NAMESPACE_NO_SSL_VERIFY: per disabilitare 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 viene 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'operatore per un'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo di quelli che puoi 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 dell'oggetto RepoSync. Il nome deve essere univoco all'interno dello 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 estrarre le immagini in base a TAG o DIGEST. Specifica TAG o DIGEST nel campo PACKAGE_NAME:

      • Per eseguire il pull in base a TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
      • Per eseguire il pull in base a DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
    • NAMESPACE_DIRECTORY: aggiungi il percorso nell'origine alla directory principale contenente la configurazione da sincronizzare. Questo campo è facoltativo e la predefinita è la directory root (/) dell'origine.

    • NAMESPACE_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: nessuna 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 non è abilitato nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un'immagine.

      Questo campo è obbligatorio.

    • NAMESPACE_EMAIL: se hai aggiunto gcpserviceaccount come 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 viene 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 scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'operatore per un'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo dei campi che puoi aggiungere al campo spec, consulta 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 dell'oggetto RepoSync. Il nome deve essere univoco all'interno dello spazio dei nomi.
    • NAMESPACE: aggiungi il nome dello spazio dei nomi.
    • NAMESPACE_REPOSITORY: l'URL del repository Helm da utilizzare come repository principale. Puoi inserire gli URL utilizzando il protocollo HTTPS o SSH. Ad esempio, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilizza il protocollo HTTPS. Questo campo è obbligatorio.
    • HELM_CHART_NAME: aggiungi il nome del grafico Helm. Questo campo è obbligatorio.
    • HELM_CHART_VERSION: la versione del grafico. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzata l'ultima versione.
    • HELM_RELEASE_NAME: il nome della release Helm. Questo campo è facoltativo.
    • HELM_RELEASE_NAMESPACE: lo spazio dei nomi target 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: 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 un CRD.
    • VALUE: valori da utilizzare al posto dei valori predefiniti che accompagnano il grafico Helm. Formatta questo campo come nel file helm chart's values.yaml. Questo campo è facoltativo.
    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: nessuna 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 non è abilitato nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un'immagine.

      Questo campo è obbligatorio.

    • NAMESPACE_EMAIL: se hai aggiunto gcpserviceaccount come 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 il nome del tuo secret se token è ROOT_AUTH_TYPE. Questo campo è facoltativo.

    • NAMESPACE_CA_CERT_SECRET_NAME: aggiungi il nome del tuo Secret. Se questo campo viene 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'operatore per un'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo dei campi che puoi aggiungere al campo spec, consulta 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 nell'origine con ambito dello spazio dei nomi. Ad esempio:

    kubectl get rolebindings -n NAMESPACE
    
  7. Puoi ripetere i passaggi precedenti se devi configurare più fonti di dati con ambito di spazio dei nomi .

Verificare lo stato di sincronizzazione della fonte attendibile

Puoi usare il comando nomos status per esaminare lo stato di sincronizzazione della fonte di riferimento:

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
  --------------------
  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, è configurata per uno spazio dei nomi denominato bookstore.

Verifica 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 una fonte attendibile a un cluster.

Puoi verificare che l'oggetto RootSync funzioni correttamente controllando lo stato del deployment del riconciliazione root:

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 ulteriori modi per esplorare lo stato dell'oggetto RootSync, consulta Monitoraggio degli oggetti RootSync e RepoSync.

Verifica l'installazione di RepoSync

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

Puoi verificare che l'oggetto RepoSync funzioni correttamente controllando lo stato del deployment dello strumento di riconciliazione 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 di RepoSync e NAMESPACE con lo spazio dei nomi in cui hai creato l'origine attendibile con ambito dello spazio dei nomi.

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

Rimuovere una fonte attendibile

Seleziona la scheda Metodo di controllo centrale o Metodo API Kubernetes per visualizzare le istruzioni pertinenti.

Metodo di controllo centrale

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

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

    • Per eliminare tutte le risorse gestite dagli oggetti RootSync o RepoSync, sincronizza 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, l'oggetto RootSync o RepoSync interno deve prima essere sincronizzato con un repository Git vuoto.

    • Se hai attivato il webhook e vuoi conservare le risorse, annulla la gestione delle risorse seguendo le istruzioni per la risoluzione dei problemi. Se non hai abilitato il webhook, non devi eseguire altri passaggi per conservare le risorse.

  2. Rimuovi l'oggetto RootSync o RepoSync dalla fonte dei dati.

Metodo API Kubernetes

Se hai usato il metodo Controlla origini attendibili con ambito di spazio dei nomi con l'API Kubernetes, gli operatori delle applicazioni possono utilizzare i seguenti passaggi per rimuovere una fonte attendibile con ambito di spazio dei nomi:

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

    • Per eliminare tutte le risorse gestite dagli oggetti RootSync o RepoSync, sincronizza 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, l'oggetto RootSync o RepoSync interno deve prima essere sincronizzato con un repository Git vuoto.

    • Se hai attivato il webhook e vuoi conservarle, annulla la gestione delle risorse seguendo le istruzioni per la risoluzione dei problemi. Se non hai abilitato il webhook, non devi eseguire altri passaggi 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 file di configurazione RootSync o RepoSync. Ad esempio, root-sync.yaml.

Passaggi successivi