Configurare la sincronizzazione da più di una fonte attendibile

Questa pagina spiega come configurare più di una fonte attendibile basata su ambito a livello di radice e dello spazio dei nomi creando oggetti RootSync e RepoSync.

Avere una fonte attendibile principale ti consente di sincronizzare le configurazioni a livello di cluster e a livello di spazio dei nomi. Una fonte attendibile principale può utilizzare credenziali a livello di amministratore per applicare i criteri agli spazi dei nomi dell'applicazione e sostituire le modifiche locali che si discostano dallo stato dichiarato nelle configurazioni. Un amministratore centrale solitamente gestisce le origini di verità principali.

Le fonti attendibili basate sullo spazio dei nomi sono facoltative e possono contenere configurazioni basate sullo spazio dei nomi sincronizzate con un determinato spazio dei nomi nei vari cluster. Puoi delegare la configurazione e il controllo di una verità di riferimento basata sul nome del dominio a utenti non amministrativi. Sebbene Config Sync rilevi automaticamente le modifiche dall'origine attendibile, puoi aggiungere un ulteriore livello di rilevamento della deriva aggiungendo un webhook di ammissione a un'origine attendibile basata su ambito dello spazio dei nomi. Per maggiori dettagli su come eseguire questa operazione, consulta Prevenire le deviazioni dalla configurazione.

Prima di iniziare

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

Limitazioni

Scegli il metodo di configurazione che preferisci

Scegli uno dei due metodi per configurare le origini:

Controllare le origini in una fonte attendibile principale

Controllare le origini principali in una fonte attendibile principale

Config Sync supporta la sincronizzazione da più di una fonte attendibile. L'amministratore centralizzato può utilizzare un'origine attendibile principale per gestire tutte le altre origini. Poiché Config Sync gestisce gli oggetti RootSync, questo metodo impedisce qualsiasi modifica locale alle configurazioni di 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 hierarchy per utilizzare un repository gerarchico. Questi valori sono sensibili alle maiuscole. Questo campo è facoltativo e il valore predefinito è hierarchy. Ti consigliamo di aggiungere unstructured perché questo formato ti consente di organizzare le configurazioni nel modo più pratico per te.
    • ROOT_REPOSITORY: aggiungi l'URL del repository Git da utilizzare come repository principale. Puoi inserire gli URL utilizzando il protocollo HTTPS o SSH. Ad esempio, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilizza il protocollo HTTPS. Questo campo è obbligatorio.
    • ROOT_REVISION: aggiungi la revisione Git (tag o hash) o il ramo da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è HEAD. Quando utilizzi un hash, deve essere un hash completo e non una forma abbreviata.
    • ROOT_BRANCH: aggiungi il ramo del repository da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è master. Per semplicità, ti consigliamo di utilizzare il campo revision per specificare un nome del ramo. Se sono specificati entrambi i campi revision e branch, revision ha la precedenza su branch.
    • ROOT_DIRECTORY: aggiungi il percorso nel repository Git alla directory principale contenente la configurazione con cui vuoi eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è la directory radice (/) del repository.

    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

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

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

      Questo campo è obbligatorio.

    • ROOT_EMAIL: se hai aggiunto gcpserviceaccount come ROOT_AUTH_TYPE, aggiungi il tuo indirizzo email dell'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 disattivare la verifica del certificato SSL, imposta questo campo su true. Il valore predefinito è false.

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

      Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo 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 hierarchy per utilizzare un repository gerarchico. Questi valori sono sensibili alle maiuscole. Questo campo è facoltativo e il valore predefinito è hierarchy. Ti consigliamo di aggiungere unstructured perché questo formato ti consente di organizzare le configurazioni nel modo più pratico 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 anche tramite TAG o DIGEST. Specifica TAG o DIGEST in PACKAGE_NAME:
      • Per estrarre per TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
      • Per estrarre per DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
    • ROOT_DIRECTORY: aggiungi il percorso nel repository alla directory principale contenente la configurazione da sincronizzare. Questo campo è facoltativo e il valore predefinito è la directory radice (/) del repository.

    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: non utilizzare l'autenticazione
      • gcenode: utilizza l'account di servizio predefinito di Compute Engine per accedere a un'immagine in Artifact Registry. Seleziona questa opzione solo se la federazione delle identità per i carichi di lavoro per GKE non è abilitata nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un'immagine.

      Questo campo è obbligatorio.

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

    • ROOT_CA_CERT_SECRET_NAME: aggiungi il nome del segreto. 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 sotto una chiave denominata cert. Questo campo è facoltativo.

    Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo 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 hierarchy per utilizzare un repository gerarchico. Questi valori sono sensibili alle maiuscole. Questo campo è facoltativo e il valore predefinito è hierarchy. Ti consigliamo di aggiungere unstructured perché questo formato ti consente di organizzare le configurazioni nel modo più pratico per te.
    • ROOT_HELM_REPOSITORY: l'URL del repository Helm da utilizzare come repository principale. Puoi inserire gli URL utilizzando il protocollo HTTPS o SSH. Ad esempio, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilizza il protocollo HTTPS. Questo campo è obbligatorio.
    • HELM_CHART_NAME: aggiungi il nome del grafico Helm. Questo campo è obbligatorio.
    • HELM_CHART_VERSION: la versione del grafico. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzata la versione più recente.
    • HELM_RELEASE_NAME: il nome della release Helm. Questo campo è facoltativo.
    • HELM_RELEASE_NAMESPACE: lo spazio dei nomi di destinazione per una release. Imposta uno spazio dei nomi solo per le risorse che contengono namespace: {{ .Release.Namespace }} nei relativi modelli. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzato lo spazio dei nomi predefinito config-management-system.
    • HELM_INCLUDE_CRDS: impostato su true se vuoi che il modello Helm generi anche un CustomResourceDefinition. Questo campo è facoltativo. Se non viene specificato alcun valore, il valore predefinito è false e non verrà generato un CRD.
    • VALUE: valori da utilizzare al posto dei valori predefiniti che accompagnano il grafico Helm. Formatta questo campo nello stesso modo in cui viene formattato il file values.yaml del grafico Helm. Questo campo è facoltativo.

    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: non utilizzare l'autenticazione
      • token: utilizza un nome utente e una password per accedere a un repository Helm privato.
      • gcenode: utilizza l'account di servizio predefinito di Compute Engine per accedere a un'immagine in Artifact Registry. Seleziona questa opzione solo se la federazione delle identità per i carichi di lavoro per GKE non è abilitata nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un'immagine.

      Questo campo è obbligatorio.

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

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

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

    Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo 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 all'origine della verità 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 memorizzare le configurazioni di più oggetti RootSync in una fonte attendibile principale sincronizzata da un altro oggetto RootSync per gestire più oggetti RootSync in modo centralizzato in un modo GitOps.

Controllare gli oggetti con ambito di spazio dei nomi in una fonte attendibile principale

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

Per utilizzare questo metodo, completa le seguenti attività:

  1. Nell'origine 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 corrispondente al tipo di origine per le 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 nello 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 trattato come un URL HTTPS. Questo campo è obbligatorio.
    • NAMESPACE_REVISION: aggiungi la revisione Git (tag o hash) o il ramo da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è HEAD. Quando utilizzi un hash, 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. Per semplicità, ti consigliamo di utilizzare il campo revision per specificare un nome del ramo. Se sono specificati entrambi i campi revision e branch, revision ha la precedenza su branch.

    • NAMESPACE_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

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

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

      Questo campo è obbligatorio.

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

    • NAMESPACE_SECRET_NAME: aggiungi il nome che vuoi assegnare al 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 segreto. Se questo campo è impostato, il tuo provider Git deve utilizzare un certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA sotto una chiave denominata cert. Questo campo è facoltativo.

      Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo dei campi 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 nello 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 anche tramite TAG o DIGEST. Specifica TAG o DIGEST in PACKAGE_NAME:

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

    • NAMESPACE_DIRECTORY: aggiungi il percorso nella directory di origine alla directory principale contenente la configurazione da sincronizzare. Questo campo è facoltativo e il valore predefinito è la directory principale (/) della fonte.

    • NAMESPACE_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: non utilizzare l'autenticazione
      • gcenode: utilizza l'account di servizio predefinito di Compute Engine per accedere a un'immagine in Artifact Registry. Seleziona questa opzione solo se la federazione delle identità per i carichi di lavoro per GKE non è abilitata nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un'immagine.

      Questo campo è obbligatorio.

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

    • NAMESPACE_CA_CERT_SECRET_NAME: aggiungi il nome del segreto. 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 sotto una chiave denominata cert. Questo campo è facoltativo.

      Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo 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 nello 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 la versione più recente.
    • HELM_RELEASE_NAME: il nome della release Helm. Questo campo è facoltativo.
    • HELM_RELEASE_NAMESPACE: lo spazio dei nomi di destinazione per una release. Imposta uno spazio dei nomi solo per le risorse che contengono namespace: {{ .Release.Namespace }} nei relativi modelli. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzato lo spazio dei nomi predefinito config-management-system.
    • HELM_INCLUDE_CRDS: impostato su true se vuoi che il modello Helm generi anche un CustomResourceDefinition. Questo campo è facoltativo. Se non viene specificato alcun valore, il valore predefinito è false e non verrà generato un CRD.
    • VALUE: valori da utilizzare al posto dei valori predefiniti che accompagnano il grafico Helm. Formatta questo campo nello stesso modo come il file values.yaml del grafico Helm. Questo campo è facoltativo.

    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: non utilizzare l'autenticazione
      • token: utilizza un nome utente e una password per accedere a un repository Helm privato.
      • gcenode: utilizza l'account di servizio predefinito di Compute Engine per accedere a un'immagine in Artifact Registry. Seleziona questa opzione solo se la federazione delle identità per i carichi di lavoro per GKE non è abilitata nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un'immagine.

      Questo campo è obbligatorio.

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

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

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

      Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'autorità di certificazione

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

  3. Se utilizzi gcpserviceaccount come tipo di autenticazione e non hai attivato la federazione Workload Identity per GKE, 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 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 RoleBinding può fare riferimento a un Role nello stesso spazio dei nomi. In alternativa, un RoleBinding può fare riferimento a un ClusterRole e associarlo allo spazio dei nomi del RoleBinding.ClusterRole 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 agli utenti, e fare riferimento allo stesso ClusterRole in più RoleBindings in spazi dei nomi diversi.

    ClusterRoles 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 di 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 di RepoSync è prod, il valore di SERVICE_ACCOUNT_NAME sarà ns-reconciler-NAMESPACE-prod-4. L'intero 4 viene utilizzato perché prod contiene 4 caratteri.
    • CLUSTERROLE_NAME: aggiungi il nome del ruolo predefinito.

    Ruoli definiti dall'utente

    Puoi dichiarare un ClusterRole o un Role concedendo un elenco di autorizzazioni a ogni risorsa gestita dall'oggetto RepoSync. In questo modo, puoi impostare autorizzazioni granulari. Per ulteriori dettagli, consulta la sezione Riferimento alle risorse.

    Ad esempio, il seguente ClusterRole o Role 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. RoleBinding concede autorizzazioni aggiuntive per consentire a Config Sync di gestire le risorse basate sullo spazio dei nomi per un determinato 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 di 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 di RepoSync è prod, il valore di SERVICE_ACCOUNT_NAME sarà ns-reconciler-NAMESPACE-prod-4. L'intero 4 viene utilizzato perché prod contiene 4 caratteri.
    • RECONCILER_ROLE: aggiungi il nome del ClusterRole o Role.

  5. Esegui il commit delle modifiche all'origine della verità principale:

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

  6. Se necessario, crea un segreto 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 segreto nello stesso spazio dei nomi di RepoSync.
    • Il nome del segreto deve corrispondere al nome spec.git.secretRef 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 basata sullo spazio dei nomi.

Controllare le origini con ambito a livello di spazio dei nomi in un'origine con ambito a livello di spazio dei nomi

Config Sync supporta la sincronizzazione da più di una fonte attendibile basata sullo spazio dei nomi per ogni spazio dei nomi. Le fonti attendibili basate sullo spazio dei nomi possono essere gestite in una fonte attendibile basata sullo spazio dei nomi nello 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 corrispondente al tipo di origine per le 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 nello 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 trattato come un URL HTTPS. Questo campo è obbligatorio.
    • NAMESPACE_REVISION: aggiungi la revisione Git (tag o hash) o il ramo da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è HEAD. Quando utilizzi un hash, 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. Per semplicità, ti consigliamo di utilizzare il campo revision per specificare un nome del ramo. Se sono specificati entrambi i campi revision e branch, revision ha la precedenza su branch.

    • NAMESPACE_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

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

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

      Questo campo è obbligatorio.

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

    • NAMESPACE_SECRET_NAME: aggiungi il nome che vuoi assegnare al 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 segreto. Se questo campo è impostato, il tuo provider Git deve utilizzare un certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA sotto una chiave denominata cert. Questo campo è facoltativo.

      Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo dei campi 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 nello 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 anche tramite TAG o DIGEST. Specifica TAG o DIGEST in PACKAGE_NAME:

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

    • NAMESPACE_DIRECTORY: aggiungi il percorso nella directory di origine alla directory principale contenente la configurazione da sincronizzare. Questo campo è facoltativo e il valore predefinito è la directory principale (/) della fonte.

    • NAMESPACE_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: non utilizzare l'autenticazione
      • gcenode: utilizza l'account di servizio predefinito di Compute Engine per accedere a un'immagine in Artifact Registry. Seleziona questa opzione solo se la federazione delle identità per i carichi di lavoro per GKE non è abilitata nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un'immagine.

      Questo campo è obbligatorio.

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

    • NAMESPACE_CA_CERT_SECRET_NAME: aggiungi il nome del segreto. 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 sotto una chiave denominata cert. Questo campo è facoltativo.

      Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo 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 nello 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 la versione più recente.
    • HELM_RELEASE_NAME: il nome della release Helm. Questo campo è facoltativo.
    • HELM_RELEASE_NAMESPACE: lo spazio dei nomi di destinazione per una release. Imposta uno spazio dei nomi solo per le risorse che contengono namespace: {{ .Release.Namespace }} nei relativi modelli. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzato lo spazio dei nomi predefinito config-management-system.
    • HELM_INCLUDE_CRDS: impostato su true se vuoi che il modello Helm generi anche un CustomResourceDefinition. Questo campo è facoltativo. Se non viene specificato alcun valore, il valore predefinito è false e non verrà generato un CRD.
    • VALUE: valori da utilizzare al posto dei valori predefiniti che accompagnano il grafico Helm. Formatta questo campo nello stesso modo come il file values.yaml del grafico Helm. Questo campo è facoltativo.

    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: non utilizzare l'autenticazione
      • token: utilizza un nome utente e una password per accedere a un repository Helm privato.
      • gcenode: utilizza l'account di servizio predefinito di Compute Engine per accedere a un'immagine in Artifact Registry. Seleziona questa opzione solo se la federazione delle identità per i carichi di lavoro per GKE non è abilitata nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un'immagine.

      Questo campo è obbligatorio.

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

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

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

      Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'autorità di certificazione

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

  2. Se utilizzi gcpserviceaccount come tipo di autenticazione e non hai attivato la federazione Workload Identity per GKE, 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 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 RoleBinding può fare riferimento a un Role nello stesso spazio dei nomi. In alternativa, un RoleBinding può fare riferimento a un ClusterRole e associarlo allo spazio dei nomi del RoleBinding.ClusterRole 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 agli utenti, e fare riferimento allo stesso ClusterRole in più RoleBindings in spazi dei nomi diversi.

    ClusterRoles 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 di 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 di RepoSync è prod, il valore di SERVICE_ACCOUNT_NAME sarà ns-reconciler-NAMESPACE-prod-4. L'intero 4 viene utilizzato perché prod contiene 4 caratteri.
    • CLUSTERROLE_NAME: aggiungi il nome del ruolo predefinito.

    Ruoli definiti dall'utente

    Puoi dichiarare un ClusterRole o un Role concedendo un elenco di autorizzazioni a ogni risorsa gestita dall'oggetto RepoSync. In questo modo, puoi impostare autorizzazioni granulari. Per ulteriori dettagli, consulta la sezione Riferimento alle risorse.

    Ad esempio, il seguente ClusterRole o Role 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. RoleBinding concede autorizzazioni aggiuntive per consentire a Config Sync di gestire le risorse basate sullo spazio dei nomi per un determinato 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 di 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 di RepoSync è prod, il valore di SERVICE_ACCOUNT_NAME sarà ns-reconciler-NAMESPACE-prod-4. L'intero 4 viene utilizzato perché prod contiene 4 caratteri.
    • RECONCILER_ROLE: aggiungi il nome del ClusterRole o Role.

  4. Esegui il commit delle modifiche all'origine della verità principale:

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

  5. Se necessario, crea un segreto 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 segreto nello stesso spazio dei nomi di RepoSync.
    • Il nome del segreto deve corrispondere al nome spec.git.secretRef 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 nella fonte attendibile basata sugli spazi dei nomi. Ad esempio:

    kubectl get rolebindings -n NAMESPACE

  7. Puoi ripetere i passaggi precedenti se devi configurare più di un'origine basata sul nome del dominio.

Controllare una fonte attendibile con l'API Kubernetes

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

Controllare più di una fonte attendibile principale

Gli 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 hierarchy per utilizzare un repository gerarchico. Questi valori sono sensibili alle maiuscole. Questo campo è facoltativo e il valore predefinito è hierarchy. Ti consigliamo di aggiungere unstructured perché questo formato ti consente di organizzare le configurazioni nel modo più pratico per te.
    • ROOT_REPOSITORY: aggiungi l'URL del repository Git da utilizzare come repository principale. Puoi inserire gli URL utilizzando il protocollo HTTPS o SSH. Ad esempio, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilizza il protocollo HTTPS. Questo campo è obbligatorio.
    • ROOT_REVISION: aggiungi la revisione Git (tag o hash) o il ramo da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è HEAD. Quando utilizzi un hash, deve essere un hash completo e non una forma abbreviata.
    • ROOT_BRANCH: aggiungi il ramo del repository da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è master. Per semplicità, ti consigliamo di utilizzare il campo revision per specificare un nome del ramo. Se sono specificati entrambi i campi revision e branch, revision ha la precedenza su branch.
    • ROOT_DIRECTORY: aggiungi il percorso nel repository Git alla directory principale contenente la configurazione con cui vuoi eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è la directory radice (/) del repository.

    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

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

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

      Questo campo è obbligatorio.

    • ROOT_EMAIL: se hai aggiunto gcpserviceaccount come ROOT_AUTH_TYPE, aggiungi il tuo indirizzo email dell'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 disattivare la verifica del certificato SSL, imposta questo campo su true. Il valore predefinito è false.

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

      Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo 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 hierarchy per utilizzare un repository gerarchico. Questi valori sono sensibili alle maiuscole. Questo campo è facoltativo e il valore predefinito è hierarchy. Ti consigliamo di aggiungere unstructured perché questo formato ti consente di organizzare le configurazioni nel modo più pratico 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 anche tramite TAG o DIGEST. Specifica TAG o DIGEST in PACKAGE_NAME:
      • Per estrarre per TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
      • Per estrarre per DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
    • ROOT_DIRECTORY: aggiungi il percorso nel repository alla directory principale contenente la configurazione da sincronizzare. Questo campo è facoltativo e il valore predefinito è la directory radice (/) del repository.

    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: non utilizzare l'autenticazione
      • gcenode: utilizza l'account di servizio predefinito di Compute Engine per accedere a un'immagine in Artifact Registry. Seleziona questa opzione solo se la federazione delle identità per i carichi di lavoro per GKE non è abilitata nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un'immagine.

      Questo campo è obbligatorio.

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

    • ROOT_CA_CERT_SECRET_NAME: aggiungi il nome del segreto. 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 sotto una chiave denominata cert. Questo campo è facoltativo.

    Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo 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 hierarchy per utilizzare un repository gerarchico. Questi valori sono sensibili alle maiuscole. Questo campo è facoltativo e il valore predefinito è hierarchy. Ti consigliamo di aggiungere unstructured perché questo formato ti consente di organizzare le configurazioni nel modo più pratico per te.
    • ROOT_HELM_REPOSITORY: l'URL del repository Helm da utilizzare come repository principale. Puoi inserire gli URL utilizzando il protocollo HTTPS o SSH. Ad esempio, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilizza il protocollo HTTPS. Questo campo è obbligatorio.
    • HELM_CHART_NAME: aggiungi il nome del grafico Helm. Questo campo è obbligatorio.
    • HELM_CHART_VERSION: la versione del grafico. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzata la versione più recente.
    • HELM_RELEASE_NAME: il nome della release Helm. Questo campo è facoltativo.
    • HELM_RELEASE_NAMESPACE: lo spazio dei nomi di destinazione per una release. Imposta uno spazio dei nomi solo per le risorse che contengono namespace: {{ .Release.Namespace }} nei relativi modelli. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzato lo spazio dei nomi predefinito config-management-system.
    • HELM_INCLUDE_CRDS: impostato su true se vuoi che il modello Helm generi anche un CustomResourceDefinition. Questo campo è facoltativo. Se non viene specificato alcun valore, il valore predefinito è false e non verrà generato un CRD.
    • VALUE: valori da utilizzare al posto dei valori predefiniti che accompagnano il grafico Helm. Formatta questo campo nello stesso modo in cui viene formattato il file values.yaml del grafico Helm. Questo campo è facoltativo.

    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: non utilizzare l'autenticazione
      • token: utilizza un nome utente e una password per accedere a un repository Helm privato.
      • gcenode: utilizza l'account di servizio predefinito di Compute Engine per accedere a un'immagine in Artifact Registry. Seleziona questa opzione solo se la federazione delle identità per i carichi di lavoro per GKE non è abilitata nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un'immagine.

      Questo campo è obbligatorio.

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

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

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

    Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo 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 le fonti attendibili 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 nello 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 della riassegnazione RBAC per assicurarti che l'operatore dell'applicazione non possa in un secondo momento applicare una associazione di ruoli con autorizzazioni non concesse da questa associazione.

    Per dichiarare 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 sorgente 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 ruolo o un ClusterRole definito dall'utente dichiarato nella fonte attendibile principale. Questo ruolo consente autorizzazioni granulari.

  3. Esegui il commit delle modifiche all'origine della verità principale:

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

Attività degli operatori delle applicazioni

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

  1. Dichiara una configurazione RoleBinding che concede all'account di servizio SERVICE_ACCOUNT_NAME sottoposto a provisioning automatico l'autorizzazione 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 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 sorgente attendibile principale.
    • SERVICE_ACCOUNT_NAME: aggiungi il nome dell'account di servizio del riconciliatore. Se il nome di 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 basata sullo spazio dei nomi. Puoi limitare ulteriormente solo l'insieme di autorizzazioni che ti sono state concesse dall'amministratore centrale. Di conseguenza, questo ruolo non può essere più permissivo del ruoloOPERATOR_ROLE dichiarato dall'amministratore centrale nella sezione precedente.

  2. Applica la configurazione del RoleBinding:

    kubectl apply -f sync-rolebinding.yaml

  3. Se necessario, crea un segreto in base al metodo di autenticazione che preferisci. Se hai utilizzato none come tipo di autenticazione, puoi saltare questo passaggio.

    Il segreto deve soddisfare i seguenti requisiti:

    • Crea il segreto nello stesso spazio dei nomi di RepoSync.
    • Il nome del segreto deve corrispondere al nome spec.git.secretRef 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 nello 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 trattato come un URL HTTPS. Questo campo è obbligatorio.
    • NAMESPACE_REVISION: aggiungi la revisione Git (tag o hash) o il ramo da cui eseguire la sincronizzazione. Questo campo è facoltativo e il valore predefinito è HEAD. Quando utilizzi un hash, 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. Per semplicità, ti consigliamo di utilizzare il campo revision per specificare un nome del ramo. Se sono specificati entrambi i campi revision e branch, revision ha la precedenza su branch.

    • NAMESPACE_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

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

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

      Questo campo è obbligatorio.

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

    • NAMESPACE_SECRET_NAME: aggiungi il nome che vuoi assegnare al 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 segreto. Se questo campo è impostato, il tuo provider Git deve utilizzare un certificato emesso da questa autorità di certificazione (CA). Il secret deve contenere il certificato CA sotto una chiave denominata cert. Questo campo è facoltativo.

      Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo dei campi 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 nello 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 anche tramite TAG o DIGEST. Specifica TAG o DIGEST in PACKAGE_NAME:

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

    • NAMESPACE_DIRECTORY: aggiungi il percorso nella directory di origine alla directory principale contenente la configurazione da sincronizzare. Questo campo è facoltativo e il valore predefinito è la directory principale (/) della fonte.

    • NAMESPACE_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: non utilizzare l'autenticazione
      • gcenode: utilizza l'account di servizio predefinito di Compute Engine per accedere a un'immagine in Artifact Registry. Seleziona questa opzione solo se la federazione delle identità per i carichi di lavoro per GKE non è abilitata nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un'immagine.

      Questo campo è obbligatorio.

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

    • NAMESPACE_CA_CERT_SECRET_NAME: aggiungi il nome del segreto. 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 sotto una chiave denominata cert. Questo campo è facoltativo.

      Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo 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 nello 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 la versione più recente.
    • HELM_RELEASE_NAME: il nome della release Helm. Questo campo è facoltativo.
    • HELM_RELEASE_NAMESPACE: lo spazio dei nomi di destinazione per una release. Imposta uno spazio dei nomi solo per le risorse che contengono namespace: {{ .Release.Namespace }} nei relativi modelli. Questo campo è facoltativo. Se non viene specificato alcun valore, viene utilizzato lo spazio dei nomi predefinito config-management-system.
    • HELM_INCLUDE_CRDS: impostato su true se vuoi che il modello Helm generi anche un CustomResourceDefinition. Questo campo è facoltativo. Se non viene specificato alcun valore, il valore predefinito è false e non verrà generato un CRD.
    • VALUE: valori da utilizzare al posto dei valori predefiniti che accompagnano il grafico Helm. Formatta questo campo nello stesso modo come il file values.yaml del grafico Helm. Questo campo è facoltativo.

    • ROOT_AUTH_TYPE: aggiungi uno dei seguenti tipi di autenticazione:

      • none: non utilizzare l'autenticazione
      • token: utilizza un nome utente e una password per accedere a un repository Helm privato.
      • gcenode: utilizza l'account di servizio predefinito di Compute Engine per accedere a un'immagine in Artifact Registry. Seleziona questa opzione solo se la federazione delle identità per i carichi di lavoro per GKE non è abilitata nel tuo cluster.
      • gcpserviceaccount: utilizza un account di servizio Google per accedere a un'immagine.

      Questo campo è obbligatorio.

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

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

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

      Per scoprire di più su come configurare l'oggetto Secret per il certificato CA, consulta Configurare l'autorità di certificazione

    Per una spiegazione dei campi e un elenco completo 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 dell'origine basata sullo spazio dei nomi. Ad esempio:

    kubectl get rolebindings -n NAMESPACE

  7. Puoi ripetere i passaggi precedenti se devi configurare più origini attendibili basate su spazio dei nomi .

Verificare lo stato della sincronizzazione della fonte attendibile

Puoi utilizzare il comando nomos status per controllare lo stato di sincronizzazione dell'origine attendibile:

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

Nell'output di questo esempio, l'origine basata sullo 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 di root-reconciler:

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

Sostituisci ROOT_SYNC_NAME con il nome di RootSync.

Dovresti vedere un output simile al seguente esempio:

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

Per scoprire altri modi per esaminare lo stato dell'oggetto RootSync, consulta Monitoraggio di oggetti RootSync e RepoSync.

Verificare l'installazione di RepoSync

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

Puoi verificare che l'oggetto RepoSync funzioni correttamente controllando lo stato del deployment del riconciliatore del nome di spazio:

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 la tua origine attendibile basata sullo spazio dei nomi.

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

Rimuovere una fonte attendibile

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

Metodo di controllo centralizzato

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

  1. Decidi se eliminare o conservare 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 una sorgente 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, disattiva la prevenzione della deriva per le risorse abbandonate. Se non hai attivato il webhook, non devi intraprendere altre azioni per conservare le risorse.

  2. Rimuovi l'oggetto RootSync o RepoSync dalla fonte di verità.

Metodo dell'API Kubernetes

Se hai utilizzato il metodo Controllare le sorgenti di dati basate sullo spazio dei nomi con l'API Kubernetes, gli operatori delle applicazioni possono seguire i passaggi che seguono per rimuovere una fonte di dati basata sullo spazio dei nomi:

  1. Decidi se eliminare o conservare 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 una sorgente 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, disattiva la prevenzione della deriva per le risorse abbandonate. Se non hai attivato il webhook, non devi intraprendere altre azioni per conservare le risorse.

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

    kubectl delete -f FILE_NAME

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

Passaggi successivi