Configurar a sincronização usando mais de uma fonte de verdade

Nesta página, explicamos como configurar mais de uma fonte de verdade com escopo raiz e namespace usando a criação de objetos RootSync e RepoSync.

Ter uma fonte raiz de verdade permite sincronizar configurações com escopo de cluster e com escopo de namespace. Uma fonte raiz de verdade pode usar credenciais no nível do administrador para aplicar políticas em namespaces de aplicativos e substituir mudanças locais que se desloquem do estado que você declarou nas configurações. Um administrador central normalmente rege as fontes raiz da verdade.

As fontes da verdade com escopo de namespace são opcionais e podem conter configurações com escopo de namespace sincronizadas com um namespace específico nos clusters. É possível delegar a configuração e o controle de uma fonte da verdade com escopo de namespace a usuários não administrativos. Embora o Config Sync detecte automaticamente mudanças da fonte de verdade, é possível adicionar uma camada extra de detecção de deslocamento adicionando um webhook de admissão a uma fonte de verdade com escopo de namespace. Para saber como fazer isso, consulte Evitar deslocamentos de configuração.

Antes de começar

• Crie ou verifique se você tem acesso a uma fonte de verdade não estruturada que pode conter as configurações com que o Config Sync é sincronizado. O Config Sync é compatível com repositórios Git, gráficos Helm e imagens OCI como a fonte da verdade. As fontes de verdade com escopo de namespace precisam usar o formato não estruturado.
• Crie ou verifique se você tem acesso a um cluster que está em uma plataforma e versão compatíveis da edição Google Kubernetes Engine (GKE) Enterprise e atende aos do Config Sync.

Limitações

• NamespaceSelectors (incluindo anotações que apontam para seletores) só funcionam em uma fonte raiz da verdade.
• Se você instalou o Config Sync usando o console do Google Cloud ou a Google Cloud CLI, o Config Sync criou automaticamente um objeto RootSync chamado root-sync. Por isso, não é possível nomear nenhum dos seus objetos RootSync como root-sync.

Escolher seu método de configuração preferido

Escolha um dos dois métodos de configuração de fontes:

• Controle as fontes em uma fonte raiz da verdade. Esse método centraliza toda a configuração de uma fonte de verdade em outra fonte de verdade, permitindo que um administrador central controle totalmente a configuração.

• Controle as origens com a API Kubernetes. Use esse método se você quiser delegar o controle da sua fonte de verdade a diferentes proprietários.

Controlar fontes em uma fonte raiz da verdade

Controlar as fontes raiz em uma fonte raiz de verdade

O Config Sync é compatível com a sincronização de mais de uma fonte de verdade. O administrador central pode usar uma fonte raiz de verdade para gerenciar todas as outras. Como o Config Sync gerencia objetos RootSync, esse método impede qualquer alteração local nas configurações RootSync no cluster.

Para usar esse recurso, conclua as seguintes tarefas:

1. Salve um dos seguintes manifestos como root-sync.yaml. Use a versão do manifesto que corresponde ao tipo de origem das suas configurações.

   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
   

   Substitua:

   • ROOT_SYNC_NAME: adicione o nome do objeto RootSync.
   • ROOT_FORMAT: adicione unstructured para usar um repositório não estruturado ou hierarchy para usar um repositório hierárquico. Esses valores diferenciam maiúsculas de minúsculas. Este campo é opcional e o valor padrão é hierarchy. Recomendamos que você adicione unstructured como esse formato para organizar suas configurações da maneira mais conveniente para você.
   • ROOT_REPOSITORY: adicione o URL do repositório Git para usar como repositório raiz. É possível inserir URLs usando o protocolo HTTPS ou SSH. Por exemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa o protocolo HTTPS. Este campo é obrigatório.
   • ROOT_REVISION: adicione a revisão Git (tag ou hash) de onde a sincronização será feita. Este campo é opcional e o valor padrão é HEAD. A partir da versão 1.17.0 do Config Sync, também é possível especificar um nome de ramificação no campo revision. Ao usar um hash na versão 1.17.0 ou mais recente, ele precisa ser um hash completo, e não uma forma abreviada.
   • ROOT_BRANCH: adicione a ramificação do repositório com que sincronizar. Este campo é opcional e o valor padrão é master. A partir da versão 1.17.0 do Config Sync, recomenda-se usar o campo revision para especificar um nome de ramificação para simplificação. Se o campo revision e o campo branch forem especificados, revision terá precedência sobre branch.
   • ROOT_DIRECTORY: adicione o caminho no repositório Git ao diretório raiz que contém a configuração com a qual você quer sincronizar. Esse campo é opcional, e o padrão é o diretório raiz (/) do repositório.

   • ROOT_AUTH_TYPE: adicione um dos seguintes tipos de autenticação:

     • none: não usa autenticação
     • ssh: use um par de chaves SSH
     • cookiefile: use um cookiefile
     • token: usar um token
     • gcpserviceaccount: use uma conta de serviço do Google para acessar um Cloud Source Repositories.
     • gcenode: use uma conta de serviço do Google para acessar um Cloud Source Repositories. Selecione esta opção somente se a Federação de Identidade da Carga de Trabalho para GKE não estiver ativada no cluster.

     Para mais informações sobre esses tipos de autenticação, consulte Como conceder acesso somente leitura do Config Sync ao Git.

     Este campo é obrigatório.

   • ROOT_EMAIL: se você adicionou gcpserviceaccount como ROOT_AUTH_TYPE, adicione o endereço de e-mail da sua conta de serviço do Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

   • ROOT_SECRET_NAME: adicione o nome do secret; Se este campo for definido, será necessário adicionar a chave pública do Secret ao provedor do Git. Este campo é opcional.

   • ROOT_NO_SSL_VERIFY: para desativar a verificação do certificado SSL, defina esse campo como true. O valor padrão é false.

   • ROOT_CA_CERT_SECRET_NAME: adicione o nome do secret; Se esse campo estiver definido, seu provedor Git precisará usar um certificado emitido por essa autoridade certificadora (CA, na sigla em inglês). O secret precisa conter o certificado de CA em uma chave chamada cert. Este campo é opcional.

     Para saber como configurar o objeto do secret para o certificado de AC, consulte Configurar a autoridade de certificação.

   Para uma explicação sobre os campos e uma lista completa de campos que você pode adicionar ao campo spec, consulte Campos RootSync.

   Esse manifesto cria um objeto RootSync que usa o Git como origem.

   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
   

   Substitua:

   • ROOT_SYNC_NAME: adicione o nome do objeto RootSync.
   • ROOT_FORMAT: adicione unstructured para usar um repositório não estruturado ou hierarchy para usar um repositório hierárquico. Esses valores diferenciam maiúsculas de minúsculas. Este campo é opcional e o valor padrão é hierarchy. Recomendamos que você adicione unstructured como esse formato para organizar suas configurações da maneira mais conveniente para você.
   • ROOT_IMAGE: o URL da imagem OCI para usar como repositório raiz, por exemplo, LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Por padrão, a imagem é extraída da tag latest, mas é possível extrair imagens por TAG ou DIGEST. Especifique TAG ou DIGEST no PACKAGE_NAME:
     • Para extrair por TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • Para extrair por DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST

   Cuidado: O Config Sync exige que a camada OCI seja compactada em tar ou tar+gzip Outros formatos (por exemplo, tar+bz2) não serão reconhecidos pelo Config Sync. A mudança de um REPO válido para uma imagem OCI com um formato incompatível fará com que os recursos gerenciados sejam removidos sem um erro.

   • ROOT_DIRECTORY: adicione o caminho no repositório Git ao diretório raiz que contém a configuração com a qual você quer sincronizar. Esse campo é opcional, e o padrão é o diretório raiz (/) do repositório.

   • ROOT_AUTH_TYPE: adicione um dos seguintes tipos de autenticação:

     • none: não usa autenticação
     • gcenode: use a conta de serviço padrão do Compute Engine para acessar uma imagem no Artifact Registry. Selecione esta opção somente se a Federação de Identidade da Carga de Trabalho para GKE não estiver ativada no cluster.
     • gcpserviceaccount: use uma conta de serviço do Google para acessar uma imagem.

     Este campo é obrigatório.

   • ROOT_EMAIL: se você adicionou gcpserviceaccount como ROOT_AUTH_TYPE, adicione o endereço de e-mail da sua conta de serviço do Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

   • ROOT_CA_CERT_SECRET_NAME: adicione o nome do secret; Se esse campo estiver definido, seu provedor OCI, precisará usar um certificado emitido por essa autoridade certificadora (CA, na sigla em inglês). O secret precisa conter o certificado de CA em uma chave chamada cert. Este campo é opcional.

   Para saber como configurar o objeto do secret para o certificado de AC, consulte Configurar a autoridade de certificação.

   Para uma explicação sobre os campos e uma lista completa de campos que você pode adicionar ao campo spec, consulte Campos RootSync.

   Esse manifesto cria um objeto RootSync que usa uma imagem OCI como origem.

   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
   

   Substitua:

   • ROOT_SYNC_NAME: adicione o nome do objeto RootSync.
   • ROOT_FORMAT: adicione unstructured para usar um repositório não estruturado ou hierarchy para usar um repositório hierárquico. Esses valores diferenciam maiúsculas de minúsculas. Este campo é opcional e o valor padrão é hierarchy. Recomendamos que você adicione unstructured como esse formato para organizar suas configurações da maneira mais conveniente para você.
   • ROOT_HELM_REPOSITORY: o URL do repositório do Helm a ser usado como o repositório raiz. É possível inserir URLs usando o protocolo HTTPS ou SSH. Por exemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa o protocolo HTTPS. Este campo é obrigatório.
   • HELM_CHART_NAME: adicione o nome do seu gráfico do Helm. Este campo é obrigatório.
   • HELM_CHART_VERSION: a versão do gráfico. Este campo é opcional. Se nenhum valor for especificado, a versão mais recente será usada.
   • HELM_RELEASE_NAME: o nome da versão do Helm. Este campo é opcional.
   • HELM_RELEASE_NAMESPACE: o namespace de destino de uma versão. Ele define apenas um namespace para os recursos que contêm namespace: {{ .Release.Namespace }} nos modelos. Este campo é opcional. Se nenhum valor for especificado, o namespace padrão config-management-system será usado.
   • HELM_INCLUDE_CRDS: defina como true se você quiser que o modelo do Helm também gere uma CustomResourceDefinition. Este campo é opcional. Se nenhum valor for especificado, o padrão será false e um CRD não será gerado.
   • VALUE: valores a serem usados em vez de valores padrão que acompanham o gráfico Helm. Formate esse campo da mesma forma que o arquivo values.yaml do gráfico do helm. Este campo é opcional.

   • ROOT_AUTH_TYPE: adicione um dos seguintes tipos de autenticação:

     • none: não usa autenticação
     • token: use um nome de usuário e uma senha para acessar um repositório particular do Helm.
     • gcenode: use a conta de serviço padrão do Compute Engine para acessar uma imagem no Artifact Registry. Selecione esta opção somente se a Federação de Identidade da Carga de Trabalho para GKE não estiver ativada no cluster.
     • gcpserviceaccount: use uma conta de serviço do Google para acessar uma imagem.

     Este campo é obrigatório.

   • ROOT_EMAIL: se você adicionou gcpserviceaccount como ROOT_AUTH_TYPE, adicione o endereço de e-mail da sua conta de serviço do Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

   • ROOT_SECRET_NAME: adicione o nome do secret se token for o ROOT_AUTH_TYPE. Este campo é opcional.

   • ROOT_CA_CERT_SECRET_NAME: adicione o nome do secret; Se esse campo estiver definido, seu provedor Helm precisará usar um certificado emitido por essa autoridade certificadora (CA, na sigla em inglês). O secret precisa conter o certificado de CA em uma chave chamada cert. Este campo é opcional.

   Para saber como configurar o objeto do secret para o certificado de AC, consulte Configurar a autoridade de certificação.

   Para uma explicação sobre os campos e uma lista completa de campos que você pode adicionar ao campo spec, consulte Campos RootSync.

   Esse manifesto cria um objeto RootSync que usa o Git como origem.

2. Confirme as mudanças na fonte raiz da verdade:

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

3. Repita as etapas acima se precisar configurar várias fontes raiz. Você também pode armazenar configurações de vários objetos RootSync em uma fonte raiz de verdade sincronizada por outro objeto RootSync para gerenciar vários objetos RootSync de maneira centralizada com o GitOps.

Controlar objetos com escopo de namespace em uma fonte raiz da verdade

As fontes de verdade com escopo de namespace podem ser gerenciadas por uma fonte de verdade raiz. Como as fontes com escopo de namespace são gerenciadas pelo Config Sync, esse método impede alterações locais nas definições de fonte com escopo do namespace.

Para usar esse recurso, conclua as seguintes tarefas:

1. Na fonte raiz da verdade, declare uma configuração namespace:

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

   Substitua NAMESPACE por um nome para o namespace.

2. Na fonte raiz da verdade, crie um dos seguintes objetos RepoSync no mesmo namespace. Use a versão do manifesto que corresponde ao tipo de origem das suas configurações.

   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
   

   Substitua:

   • REPO_SYNC_NAME: adicione o nome do objeto RepoSync. O nome precisa ser exclusivo em todo o namespace.
   • NAMESPACE: adicione o nome do namespace.
   • NAMESPACE_REPOSITORY: adicione o URL do repositório Git para usar como repositório do namespace. É possível inserir URLs usando o protocolo HTTPS ou SSH. Por exemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa o protocolo HTTPS. Se você não inserir um protocolo, o URL será tratado como um URL HTTPS. Este campo é obrigatório.
   • NAMESPACE_REVISION: adicione a revisão Git (tag ou hash) para sincronizar. Este campo é opcional e o valor padrão é HEAD. A partir da versão 1.17.0 do Config Sync, também é possível especificar um nome de ramificação no campo revision. Ao usar um hash na versão 1.17.0 ou mais recente, ele precisa ser um hash completo, e não uma forma abreviada.
   • NAMESPACE_BRANCH: adicione a ramificação do repositório com que sincronizar. Este campo é opcional e o valor padrão é master. A partir da versão 1.17.0 do Config Sync, recomenda-se usar o campo revision para especificar um nome de ramificação para simplificação. Se o campo revision e o campo branch forem especificados, revision terá precedência sobre branch.

   • NAMESPACE_AUTH_TYPE: adicione um dos seguintes tipos de autenticação:

     • none: não usa autenticação
     • ssh: use um par de chaves SSH
     • cookiefile: use um cookiefile
     • token: usar um token
     • gcpserviceaccount: use uma conta de serviço do Google para acessar um repositório no Cloud Source Repositories.

     • gcenode: use uma conta de serviço do Google para acessar um repositório no Cloud Source Repositories. Selecione esta opção somente se a Federação de Identidade da Carga de Trabalho para GKE não estiver ativada no cluster.

       Para mais informações sobre esses tipos de autenticação, consulte Como conceder acesso somente leitura do Config Sync ao Git.

     Este campo é obrigatório.

   • NAMESPACE_EMAIL: se você adicionou gcpserviceaccount como NAMESPACE_AUTH_TYPE, adicione o endereço de e-mail da sua conta de serviço do Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

   • NAMESPACE_SECRET_NAME: adicione o nome que você pretende dar ao secret; Este campo é opcional.

   • NAMESPACE_NO_SSL_VERIFY: para desativar a verificação do certificado SSL, defina esse campo como true. O valor padrão é false.

   • NAMESPACE_CA_CERT_SECRET_NAME: adicione o nome do secret; Se esse campo estiver definido, seu provedor Git precisará usar um certificado emitido por essa autoridade certificadora (CA, na sigla em inglês). O secret precisa conter o certificado de CA em uma chave chamada cert. Este campo é opcional.

     Para saber como configurar o objeto do secret para o certificado de AC, consulte Configurar a autoridade de certificação.

   Para uma explicação dos campos e uma lista completa de campos que podem ser adicionados ao campo spec, consulte Campos 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
   

   Substitua:

   • REPO_SYNC_NAME: adicione o nome do objeto RepoSync. O nome precisa ser exclusivo em todo o namespace.
   • NAMESPACE: adicione o nome do namespace.

   • NAMESPACE_IMAGE: o URL da imagem OCI a ser usada como origem do namespace. Por exemplo, LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Por padrão, a imagem é extraída da tag latest, mas é possível extrair imagens por TAG ou DIGEST. Especifique TAG ou DIGEST no PACKAGE_NAME:

     • Para extrair por TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • Para extrair por DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
     Cuidado: O Config Sync exige que a camada OCI seja compactada em tar ou tar+gzip Outros formatos (por exemplo, tar+bz2) não serão reconhecidos pelo Config Sync. A mudança de um REPO válido para uma imagem OCI com um formato incompatível fará com que os recursos gerenciados sejam removidos sem um erro.

   • NAMESPACE_DIRECTORY: adicione o caminho na fonte ao diretório raiz que contém a configuração com a qual você quer sincronizar. Esse campo é opcional, e o padrão é o diretório raiz (/) da fonte.

   • NAMESPACE_AUTH_TYPE: adicione um dos seguintes tipos de autenticação:

     • none: não usa autenticação
     • gcenode: use a conta de serviço padrão do Compute Engine para acessar uma imagem no Artifact Registry. Selecione esta opção somente se a Federação de Identidade da Carga de Trabalho para GKE não estiver ativada no cluster.
     • gcpserviceaccount: use uma conta de serviço do Google para acessar uma imagem.

     Este campo é obrigatório.

   • NAMESPACE_EMAIL: se você adicionou gcpserviceaccount como ROOT_AUTH_TYPE, adicione o endereço de e-mail da sua conta de serviço do Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

   • NAMESPACE_CA_CERT_SECRET_NAME: adicione o nome do secret; Se esse campo estiver definido, seu provedor OCI, precisará usar um certificado emitido por essa autoridade certificadora (CA, na sigla em inglês). O secret precisa conter o certificado de CA em uma chave chamada cert. Este campo é opcional.

     Para saber como configurar o objeto do secret para o certificado de AC, consulte Configurar a autoridade de certificação.

   Para uma explicação sobre os campos e uma lista completa de campos que você pode adicionar ao campo spec, consulte Campos 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
   

   Substitua:

   • REPO_SYNC_NAME: adicione o nome do objeto RepoSync. O nome precisa ser exclusivo em todo o namespace.
   • NAMESPACE: adicione o nome do namespace.
   • NAMESPACE_REPOSITORY: o URL do repositório do Helm a ser usado como o repositório raiz. É possível inserir URLs usando o protocolo HTTPS ou SSH. Por exemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa o protocolo HTTPS. Este campo é obrigatório.
   • HELM_CHART_NAME: adicione o nome do seu gráfico do Helm. Este campo é obrigatório.
   • HELM_CHART_VERSION: a versão do gráfico. Este campo é opcional. Se nenhum valor for especificado, a versão mais recente será usada.
   • HELM_RELEASE_NAME: o nome da versão do Helm. Este campo é opcional.
   • HELM_RELEASE_NAMESPACE: o namespace de destino de uma versão. Ele define apenas um namespace para os recursos que contêm namespace: {{ .Release.Namespace }} nos modelos. Este campo é opcional. Se nenhum valor for especificado, o namespace padrão config-management-system será usado.
   • HELM_INCLUDE_CRDS: defina como true se você quiser que o modelo do Helm também gere uma CustomResourceDefinition. Este campo é opcional. Se nenhum valor for especificado, o padrão será false e um CRD não será gerado.
   • VALUE: valores a serem usados em vez de valores padrão que acompanham o gráfico Helm. Formate esse campo da mesma forma que o arquivo values.yaml do gráfico do helm. Este campo é opcional.

   • ROOT_AUTH_TYPE: adicione um dos seguintes tipos de autenticação:

     • none: não usa autenticação
     • token: use um nome de usuário e uma senha para acessar um repositório particular do Helm.
     • gcenode: use a conta de serviço padrão do Compute Engine para acessar uma imagem no Artifact Registry. Selecione esta opção somente se a Federação de Identidade da Carga de Trabalho para GKE não estiver ativada no cluster.
     • gcpserviceaccount: use uma conta de serviço do Google para acessar uma imagem.

     Este campo é obrigatório.

   • NAMESPACE_EMAIL: se você adicionou gcpserviceaccount como ROOT_AUTH_TYPE, adicione o endereço de e-mail da sua conta de serviço do Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

   • NAMESPACE_SECRET_NAME: adicione o nome do secret se token for o ROOT_AUTH_TYPE. Este campo é opcional.

   • NAMESPACE_CA_CERT_SECRET_NAME: adicione o nome do secret; Se esse campo estiver definido, seu provedor Helm precisará usar um certificado emitido por essa autoridade certificadora (CA, na sigla em inglês). O secret precisa conter o certificado de CA em uma chave chamada cert. Este campo é opcional.

     Para saber como configurar o objeto do secret para o certificado de AC, consulte Configurar a autoridade de certificação.

   Para uma explicação sobre os campos e uma lista completa de campos que você pode adicionar ao campo spec, consulte Campos RootSync.

3. Se você estiver usando gcpserviceaccount como o tipo de autenticação e não tiver a Federação de Identidade da Carga de Trabalho para GKE ativada, crie uma vinculação de política do IAM entre a conta de serviço do Kubernetes para cada namespace e a conta de serviço do Google. Consulte Conceder acesso ao Git para instruções sobre como criar essa vinculação.

4. Na fonte raiz, declare uma configuração RoleBinding que conceda à conta de serviço SERVICE_ACCOUNT_NAME permissão para gerenciar objetos no namespace. O Config Sync cria automaticamente a conta de serviço SERVICE_ACCOUNT_NAME quando a configuração RepoSync é sincronizada com o cluster.

   Um RoleBinding pode referenciar um Role no mesmo namespace. Como alternativa, um RoleBinding pode referenciar um ClusterRole e vincular esse ClusterRole ao namespace do RoleBinding. É necessário aderir ao princípio do menor privilégio (em inglês) concedendo permissões granulares a um Role definido pelo usuário, mas é possível definir um ClusterRole ou use papéis voltados ao usuário e mencione o mesmo ClusterRole em vários RoleBindings em diferentes namespaces.

   Observação: um RoleBinding que faz referência a um ClusterRole só dá acesso ao namespace do RoleBinding, mas não em todo o cluster.

   ClusterRoles padrão

   É possível declarar um RoleBinding fazendo referência a um ClusterRole padrão, por exemplo, admin ou edit. Para saber mais, consulte Papéis voltados para o usuário.

   # 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
   

   Substitua:

   • NAMESPACE: adicione o nome do namespace.
   • SERVICE_ACCOUNT_NAME: adicione o nome da conta de serviço do reconciliador. Se o nome do RepoSync for repo-sync, SERVICE_ACCOUNT_NAME será ns-reconciler-NAMESPACE. Caso contrário, será ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Por exemplo, se o nome do RepoSync for prod, o SERVICE_ACCOUNT_NAME será ns-reconciler-NAMESPACE-prod-4. O número inteiro 4 é usado, já que o prod contém quatro caracteres.
   • CLUSTERROLE_NAME: adicione o nome do ClusterRole padrão.

   Papéis definidos pelo usuário

   É possível declarar uma ClusterRole ou uma Role concedendo uma lista de permissões para cada recurso gerenciado pelo objeto RepoSync. Assim é possível realizar permissões refinadas. Consulte Como se referir a recursos para mais detalhes.

   Por exemplo, o ClusterRole ou Role a seguir concede permissões para gerenciar objetos 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: ["*"]
   

   Para declarar um RoleBinding referenciando ClusterRole ou Role, crie o objeto a seguir. O RoleBinding concede outras permissões para permitir que o Config Sync gerencie recursos com escopo de namespace para um determinado 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
   

   Substitua:

   • ROLE_KIND: defina ClusterRole ou Role.
   • NAMESPACE: adicione o nome do namespace.
   • SERVICE_ACCOUNT_NAME: adicione o nome da conta de serviço do reconciliador. Se o nome do RepoSync for repo-sync, SERVICE_ACCOUNT_NAME será ns-reconciler-NAMESPACE. Caso contrário, será ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Por exemplo, se o nome do RepoSync for prod, o SERVICE_ACCOUNT_NAME será ns-reconciler-NAMESPACE-prod-4. O número inteiro 4 é usado, já que o prod contém quatro caracteres.
   • RECONCILER_ROLE: adicione o nome da ClusterRole ou do Role.

5. Confirme as mudanças na fonte raiz da verdade:

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

6. Se necessário, crie um secret com base no método de autenticação de sua preferência. Se você usou none como tipo de autenticação, pule esta etapa.

   O secret precisa atender aos seguintes requisitos:

   • Crie o secret no mesmo namespace que o RepoSync.
   • O nome do secret precisa corresponder ao nome spec.git.secretRef que você definiu em repo-sync.yaml.
   • Você precisa adicionar a chave pública do secret ao provedor Git.

7. Para verificar a configuração, use kubectl get em um dos objetos na fonte de namespace. Por exemplo:

   kubectl get rolebindings -n NAMESPACE
   

8. Repita as etapas acima se precisar configurar mais de uma fonte com escopo de namespace.

Controlar fontes com escopo de namespace em uma fonte com escopo de namespace

O Config Sync é compatível com a sincronização de mais de uma fonte da verdade com escopo de namespace por namespace. As fontes de verdade com escopo de namespace podem ser gerenciadas em uma fonte de verdade no mesmo namespace.

Para usar esse recurso, conclua as seguintes tarefas:

1. Na fonte da verdade com escopo de namespace, crie um dos seguintes objetos RepoSync no mesmo namespace. Use a versão do manifesto que corresponde ao tipo de origem das suas configurações.

   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
   

   Substitua:

   • REPO_SYNC_NAME: adicione o nome do objeto RepoSync. O nome precisa ser exclusivo em todo o namespace.
   • NAMESPACE: adicione o nome do namespace.
   • NAMESPACE_REPOSITORY: adicione o URL do repositório Git para usar como repositório do namespace. É possível inserir URLs usando o protocolo HTTPS ou SSH. Por exemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa o protocolo HTTPS. Se você não inserir um protocolo, o URL será tratado como um URL HTTPS. Este campo é obrigatório.
   • NAMESPACE_REVISION: adicione a revisão Git (tag ou hash) para sincronizar. Este campo é opcional e o valor padrão é HEAD. A partir da versão 1.17.0 do Config Sync, também é possível especificar um nome de ramificação no campo revision. Ao usar um hash na versão 1.17.0 ou mais recente, ele precisa ser um hash completo, e não uma forma abreviada.
   • NAMESPACE_BRANCH: adicione a ramificação do repositório com que sincronizar. Este campo é opcional e o valor padrão é master. A partir da versão 1.17.0 do Config Sync, recomenda-se usar o campo revision para especificar um nome de ramificação para simplificação. Se o campo revision e o campo branch forem especificados, revision terá precedência sobre branch.

   • NAMESPACE_AUTH_TYPE: adicione um dos seguintes tipos de autenticação:

     • none: não usa autenticação
     • ssh: use um par de chaves SSH
     • cookiefile: use um cookiefile
     • token: usar um token
     • gcpserviceaccount: use uma conta de serviço do Google para acessar um repositório no Cloud Source Repositories.

     • gcenode: use uma conta de serviço do Google para acessar um repositório no Cloud Source Repositories. Selecione esta opção somente se a Federação de Identidade da Carga de Trabalho para GKE não estiver ativada no cluster.

       Para mais informações sobre esses tipos de autenticação, consulte Como conceder acesso somente leitura do Config Sync ao Git.

     Este campo é obrigatório.

   • NAMESPACE_EMAIL: se você adicionou gcpserviceaccount como NAMESPACE_AUTH_TYPE, adicione o endereço de e-mail da sua conta de serviço do Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

   • NAMESPACE_SECRET_NAME: adicione o nome que você pretende dar ao secret; Este campo é opcional.

   • NAMESPACE_NO_SSL_VERIFY: para desativar a verificação do certificado SSL, defina esse campo como true. O valor padrão é false.

   • NAMESPACE_CA_CERT_SECRET_NAME: adicione o nome do secret; Se esse campo estiver definido, seu provedor Git precisará usar um certificado emitido por essa autoridade certificadora (CA, na sigla em inglês). O secret precisa conter o certificado de CA em uma chave chamada cert. Este campo é opcional.

     Para saber como configurar o objeto do secret para o certificado de AC, consulte Configurar a autoridade de certificação.

   Para uma explicação dos campos e uma lista completa de campos que podem ser adicionados ao campo spec, consulte Campos 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
   

   Substitua:

   • REPO_SYNC_NAME: adicione o nome do objeto RepoSync. O nome precisa ser exclusivo em todo o namespace.
   • NAMESPACE: adicione o nome do namespace.

   • NAMESPACE_IMAGE: o URL da imagem OCI a ser usada como origem do namespace. Por exemplo, LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Por padrão, a imagem é extraída da tag latest, mas é possível extrair imagens por TAG ou DIGEST. Especifique TAG ou DIGEST no PACKAGE_NAME:

     • Para extrair por TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • Para extrair por DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
     Cuidado: O Config Sync exige que a camada OCI seja compactada em tar ou tar+gzip Outros formatos (por exemplo, tar+bz2) não serão reconhecidos pelo Config Sync. A mudança de um REPO válido para uma imagem OCI com um formato incompatível fará com que os recursos gerenciados sejam removidos sem um erro.

   • NAMESPACE_DIRECTORY: adicione o caminho na fonte ao diretório raiz que contém a configuração com a qual você quer sincronizar. Esse campo é opcional, e o padrão é o diretório raiz (/) da fonte.

   • NAMESPACE_AUTH_TYPE: adicione um dos seguintes tipos de autenticação:

     • none: não usa autenticação
     • gcenode: use a conta de serviço padrão do Compute Engine para acessar uma imagem no Artifact Registry. Selecione esta opção somente se a Federação de Identidade da Carga de Trabalho para GKE não estiver ativada no cluster.
     • gcpserviceaccount: use uma conta de serviço do Google para acessar uma imagem.

     Este campo é obrigatório.

   • NAMESPACE_EMAIL: se você adicionou gcpserviceaccount como ROOT_AUTH_TYPE, adicione o endereço de e-mail da sua conta de serviço do Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

   • NAMESPACE_CA_CERT_SECRET_NAME: adicione o nome do secret; Se esse campo estiver definido, seu provedor OCI, precisará usar um certificado emitido por essa autoridade certificadora (CA, na sigla em inglês). O secret precisa conter o certificado de CA em uma chave chamada cert. Este campo é opcional.

     Para saber como configurar o objeto do secret para o certificado de AC, consulte Configurar a autoridade de certificação.

   Para uma explicação sobre os campos e uma lista completa de campos que você pode adicionar ao campo spec, consulte Campos 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
   

   Substitua:

   • REPO_SYNC_NAME: adicione o nome do objeto RepoSync. O nome precisa ser exclusivo em todo o namespace.
   • NAMESPACE: adicione o nome do namespace.
   • NAMESPACE_REPOSITORY: o URL do repositório do Helm a ser usado como o repositório raiz. É possível inserir URLs usando o protocolo HTTPS ou SSH. Por exemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa o protocolo HTTPS. Este campo é obrigatório.
   • HELM_CHART_NAME: adicione o nome do seu gráfico do Helm. Este campo é obrigatório.
   • HELM_CHART_VERSION: a versão do gráfico. Este campo é opcional. Se nenhum valor for especificado, a versão mais recente será usada.
   • HELM_RELEASE_NAME: o nome da versão do Helm. Este campo é opcional.
   • HELM_RELEASE_NAMESPACE: o namespace de destino de uma versão. Ele define apenas um namespace para os recursos que contêm namespace: {{ .Release.Namespace }} nos modelos. Este campo é opcional. Se nenhum valor for especificado, o namespace padrão config-management-system será usado.
   • HELM_INCLUDE_CRDS: defina como true se você quiser que o modelo do Helm também gere uma CustomResourceDefinition. Este campo é opcional. Se nenhum valor for especificado, o padrão será false e um CRD não será gerado.
   • VALUE: valores a serem usados em vez de valores padrão que acompanham o gráfico Helm. Formate esse campo da mesma forma que o arquivo values.yaml do gráfico do helm. Este campo é opcional.

   • ROOT_AUTH_TYPE: adicione um dos seguintes tipos de autenticação:

     • none: não usa autenticação
     • token: use um nome de usuário e uma senha para acessar um repositório particular do Helm.
     • gcenode: use a conta de serviço padrão do Compute Engine para acessar uma imagem no Artifact Registry. Selecione esta opção somente se a Federação de Identidade da Carga de Trabalho para GKE não estiver ativada no cluster.
     • gcpserviceaccount: use uma conta de serviço do Google para acessar uma imagem.

     Este campo é obrigatório.

   • NAMESPACE_EMAIL: se você adicionou gcpserviceaccount como ROOT_AUTH_TYPE, adicione o endereço de e-mail da sua conta de serviço do Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

   • NAMESPACE_SECRET_NAME: adicione o nome do secret se token for o ROOT_AUTH_TYPE. Este campo é opcional.

   • NAMESPACE_CA_CERT_SECRET_NAME: adicione o nome do secret; Se esse campo estiver definido, seu provedor Helm precisará usar um certificado emitido por essa autoridade certificadora (CA, na sigla em inglês). O secret precisa conter o certificado de CA em uma chave chamada cert. Este campo é opcional.

     Para saber como configurar o objeto do secret para o certificado de AC, consulte Configurar a autoridade de certificação.

   Para uma explicação sobre os campos e uma lista completa de campos que você pode adicionar ao campo spec, consulte Campos RootSync.

2. Se você estiver usando gcpserviceaccount como o tipo de autenticação e não tiver a Federação de Identidade da Carga de Trabalho para GKE ativada, crie uma vinculação de política do IAM entre a conta de serviço do Kubernetes para cada namespace e a conta de serviço do Google. Consulte Conceder acesso ao Git para instruções sobre como criar essa vinculação.

3. Na fonte raiz, declare uma configuração RoleBinding que conceda à conta de serviço SERVICE_ACCOUNT_NAME permissão para gerenciar objetos no namespace. O Config Sync cria automaticamente a conta de serviço SERVICE_ACCOUNT_NAME quando a configuração RepoSync é sincronizada com o cluster.

   Um RoleBinding pode referenciar um Role no mesmo namespace. Como alternativa, um RoleBinding pode referenciar um ClusterRole e vincular esse ClusterRole ao namespace do RoleBinding. É necessário aderir ao princípio do menor privilégio (em inglês) concedendo permissões granulares a um Role definido pelo usuário, mas é possível definir um ClusterRole ou use papéis voltados ao usuário e mencione o mesmo ClusterRole em vários RoleBindings em diferentes namespaces.

   Observação: um RoleBinding que faz referência a um ClusterRole só dá acesso ao namespace do RoleBinding, mas não em todo o cluster.

   ClusterRoles padrão

   É possível declarar um RoleBinding fazendo referência a um ClusterRole padrão, por exemplo, admin ou edit. Para saber mais, consulte Papéis voltados para o usuário.

   # 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
   

   Substitua:

   • NAMESPACE: adicione o nome do namespace.
   • SERVICE_ACCOUNT_NAME: adicione o nome da conta de serviço do reconciliador. Se o nome do RepoSync for repo-sync, SERVICE_ACCOUNT_NAME será ns-reconciler-NAMESPACE. Caso contrário, será ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Por exemplo, se o nome do RepoSync for prod, o SERVICE_ACCOUNT_NAME será ns-reconciler-NAMESPACE-prod-4. O número inteiro 4 é usado, já que o prod contém quatro caracteres.
   • CLUSTERROLE_NAME: adicione o nome do ClusterRole padrão.

   Papéis definidos pelo usuário

   É possível declarar uma ClusterRole ou uma Role concedendo uma lista de permissões para cada recurso gerenciado pelo objeto RepoSync. Assim é possível realizar permissões refinadas. Consulte Como se referir a recursos para mais detalhes.

   Por exemplo, o ClusterRole ou Role a seguir concede permissões para gerenciar objetos 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: ["*"]
   

   Para declarar um RoleBinding referenciando ClusterRole ou Role, crie o objeto a seguir. O RoleBinding concede outras permissões para permitir que o Config Sync gerencie recursos com escopo de namespace para um determinado 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
   

   Substitua:

   • ROLE_KIND: defina ClusterRole ou Role.
   • NAMESPACE: adicione o nome do namespace.
   • SERVICE_ACCOUNT_NAME: adicione o nome da conta de serviço do reconciliador. Se o nome do RepoSync for repo-sync, SERVICE_ACCOUNT_NAME será ns-reconciler-NAMESPACE. Caso contrário, será ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Por exemplo, se o nome do RepoSync for prod, o SERVICE_ACCOUNT_NAME será ns-reconciler-NAMESPACE-prod-4. O número inteiro 4 é usado, já que o prod contém quatro caracteres.
   • RECONCILER_ROLE: adicione o nome da ClusterRole ou do Role.

4. Confirme as mudanças na fonte raiz da verdade:

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

5. Se necessário, crie um secret com base no método de autenticação de sua preferência. Se você usou none como tipo de autenticação, pule esta etapa.

   O secret precisa atender aos seguintes requisitos:

   • Crie o secret no mesmo namespace que o RepoSync.
   • O nome do secret precisa corresponder ao nome spec.git.secretRef que você definiu em repo-sync.yaml.
   • Você precisa adicionar a chave pública do secret ao provedor Git.

6. Para verificar a configuração, use kubectl get em um dos objetos na fonte de verdade com escopo de namespace. Por exemplo:

   kubectl get rolebindings -n NAMESPACE
   

7. Repita as etapas acima se precisar configurar mais de uma fonte com escopo de namespace.

Controlar uma fonte de verdade com a API Kubernetes

Nesse método, o administrador central delega a declaração de outros objetos RootSync a outros administradores. Para objetos RepoSync, o administrador central só declara o namespace na fonte raiz da verdade e delega a declaração do objeto RepoSync ao operador do aplicativo.

Controlar mais de uma fonte raiz da verdade

Outros administradores podem controlar uma fonte raiz da verdade concluindo as seguintes tarefas:

1. Salve um dos seguintes manifestos como root-sync.yaml. Use a versão do manifesto que corresponde ao tipo de origem das suas configurações.

   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
   

   Substitua:

   • ROOT_SYNC_NAME: adicione o nome do objeto RootSync.
   • ROOT_FORMAT: adicione unstructured para usar um repositório não estruturado ou hierarchy para usar um repositório hierárquico. Esses valores diferenciam maiúsculas de minúsculas. Este campo é opcional e o valor padrão é hierarchy. Recomendamos que você adicione unstructured como esse formato para organizar suas configurações da maneira mais conveniente para você.
   • ROOT_REPOSITORY: adicione o URL do repositório Git para usar como repositório raiz. É possível inserir URLs usando o protocolo HTTPS ou SSH. Por exemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa o protocolo HTTPS. Este campo é obrigatório.
   • ROOT_REVISION: adicione a revisão Git (tag ou hash) de onde a sincronização será feita. Este campo é opcional e o valor padrão é HEAD. A partir da versão 1.17.0 do Config Sync, também é possível especificar um nome de ramificação no campo revision. Ao usar um hash na versão 1.17.0 ou mais recente, ele precisa ser um hash completo, e não uma forma abreviada.
   • ROOT_BRANCH: adicione a ramificação do repositório com que sincronizar. Este campo é opcional e o valor padrão é master. A partir da versão 1.17.0 do Config Sync, recomenda-se usar o campo revision para especificar um nome de ramificação para simplificação. Se o campo revision e o campo branch forem especificados, revision terá precedência sobre branch.
   • ROOT_DIRECTORY: adicione o caminho no repositório Git ao diretório raiz que contém a configuração com a qual você quer sincronizar. Esse campo é opcional, e o padrão é o diretório raiz (/) do repositório.

   • ROOT_AUTH_TYPE: adicione um dos seguintes tipos de autenticação:

     • none: não usa autenticação
     • ssh: use um par de chaves SSH
     • cookiefile: use um cookiefile
     • token: usar um token
     • gcpserviceaccount: use uma conta de serviço do Google para acessar um Cloud Source Repositories.
     • gcenode: use uma conta de serviço do Google para acessar um Cloud Source Repositories. Selecione esta opção somente se a Federação de Identidade da Carga de Trabalho para GKE não estiver ativada no cluster.

     Para mais informações sobre esses tipos de autenticação, consulte Como conceder acesso somente leitura do Config Sync ao Git.

     Este campo é obrigatório.

   • ROOT_EMAIL: se você adicionou gcpserviceaccount como ROOT_AUTH_TYPE, adicione o endereço de e-mail da sua conta de serviço do Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

   • ROOT_SECRET_NAME: adicione o nome do secret; Se este campo for definido, será necessário adicionar a chave pública do Secret ao provedor do Git. Este campo é opcional.

   • ROOT_NO_SSL_VERIFY: para desativar a verificação do certificado SSL, defina esse campo como true. O valor padrão é false.

   • ROOT_CA_CERT_SECRET_NAME: adicione o nome do secret; Se esse campo estiver definido, seu provedor Git precisará usar um certificado emitido por essa autoridade certificadora (CA, na sigla em inglês). O secret precisa conter o certificado de CA em uma chave chamada cert. Este campo é opcional.

     Para saber como configurar o objeto do secret para o certificado de AC, consulte Configurar a autoridade de certificação.

   Para uma explicação sobre os campos e uma lista completa de campos que você pode adicionar ao campo spec, consulte Campos RootSync.

   Esse manifesto cria um objeto RootSync que usa o Git como origem.

   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
   

   Substitua:

   • ROOT_SYNC_NAME: adicione o nome do objeto RootSync.
   • ROOT_FORMAT: adicione unstructured para usar um repositório não estruturado ou hierarchy para usar um repositório hierárquico. Esses valores diferenciam maiúsculas de minúsculas. Este campo é opcional e o valor padrão é hierarchy. Recomendamos que você adicione unstructured como esse formato para organizar suas configurações da maneira mais conveniente para você.
   • ROOT_IMAGE: o URL da imagem OCI para usar como repositório raiz, por exemplo, LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Por padrão, a imagem é extraída da tag latest, mas é possível extrair imagens por TAG ou DIGEST. Especifique TAG ou DIGEST no PACKAGE_NAME:
     • Para extrair por TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • Para extrair por DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST

   Cuidado: O Config Sync exige que a camada OCI seja compactada em tar ou tar+gzip Outros formatos (por exemplo, tar+bz2) não serão reconhecidos pelo Config Sync. A mudança de um REPO válido para uma imagem OCI com um formato incompatível fará com que os recursos gerenciados sejam removidos sem um erro.

   • ROOT_DIRECTORY: adicione o caminho no repositório Git ao diretório raiz que contém a configuração com a qual você quer sincronizar. Esse campo é opcional, e o padrão é o diretório raiz (/) do repositório.

   • ROOT_AUTH_TYPE: adicione um dos seguintes tipos de autenticação:

     • none: não usa autenticação
     • gcenode: use a conta de serviço padrão do Compute Engine para acessar uma imagem no Artifact Registry. Selecione esta opção somente se a Federação de Identidade da Carga de Trabalho para GKE não estiver ativada no cluster.
     • gcpserviceaccount: use uma conta de serviço do Google para acessar uma imagem.

     Este campo é obrigatório.

   • ROOT_EMAIL: se você adicionou gcpserviceaccount como ROOT_AUTH_TYPE, adicione o endereço de e-mail da sua conta de serviço do Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

   • ROOT_CA_CERT_SECRET_NAME: adicione o nome do secret; Se esse campo estiver definido, seu provedor OCI, precisará usar um certificado emitido por essa autoridade certificadora (CA, na sigla em inglês). O secret precisa conter o certificado de CA em uma chave chamada cert. Este campo é opcional.

   Para saber como configurar o objeto do secret para o certificado de AC, consulte Configurar a autoridade de certificação.

   Para uma explicação sobre os campos e uma lista completa de campos que você pode adicionar ao campo spec, consulte Campos RootSync.

   Esse manifesto cria um objeto RootSync que usa uma imagem OCI como origem.

   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
   

   Substitua:

   • ROOT_SYNC_NAME: adicione o nome do objeto RootSync.
   • ROOT_FORMAT: adicione unstructured para usar um repositório não estruturado ou hierarchy para usar um repositório hierárquico. Esses valores diferenciam maiúsculas de minúsculas. Este campo é opcional e o valor padrão é hierarchy. Recomendamos que você adicione unstructured como esse formato para organizar suas configurações da maneira mais conveniente para você.
   • ROOT_HELM_REPOSITORY: o URL do repositório do Helm a ser usado como o repositório raiz. É possível inserir URLs usando o protocolo HTTPS ou SSH. Por exemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa o protocolo HTTPS. Este campo é obrigatório.
   • HELM_CHART_NAME: adicione o nome do seu gráfico do Helm. Este campo é obrigatório.
   • HELM_CHART_VERSION: a versão do gráfico. Este campo é opcional. Se nenhum valor for especificado, a versão mais recente será usada.
   • HELM_RELEASE_NAME: o nome da versão do Helm. Este campo é opcional.
   • HELM_RELEASE_NAMESPACE: o namespace de destino de uma versão. Ele define apenas um namespace para os recursos que contêm namespace: {{ .Release.Namespace }} nos modelos. Este campo é opcional. Se nenhum valor for especificado, o namespace padrão config-management-system será usado.
   • HELM_INCLUDE_CRDS: defina como true se você quiser que o modelo do Helm também gere uma CustomResourceDefinition. Este campo é opcional. Se nenhum valor for especificado, o padrão será false e um CRD não será gerado.
   • VALUE: valores a serem usados em vez de valores padrão que acompanham o gráfico Helm. Formate esse campo da mesma forma que o arquivo values.yaml do gráfico do helm. Este campo é opcional.

   • ROOT_AUTH_TYPE: adicione um dos seguintes tipos de autenticação:

     • none: não usa autenticação
     • token: use um nome de usuário e uma senha para acessar um repositório particular do Helm.
     • gcenode: use a conta de serviço padrão do Compute Engine para acessar uma imagem no Artifact Registry. Selecione esta opção somente se a Federação de Identidade da Carga de Trabalho para GKE não estiver ativada no cluster.
     • gcpserviceaccount: use uma conta de serviço do Google para acessar uma imagem.

     Este campo é obrigatório.

   • ROOT_EMAIL: se você adicionou gcpserviceaccount como ROOT_AUTH_TYPE, adicione o endereço de e-mail da sua conta de serviço do Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

   • ROOT_SECRET_NAME: adicione o nome do secret se token for o ROOT_AUTH_TYPE. Este campo é opcional.

   • ROOT_CA_CERT_SECRET_NAME: adicione o nome do secret; Se esse campo estiver definido, seu provedor Helm precisará usar um certificado emitido por essa autoridade certificadora (CA, na sigla em inglês). O secret precisa conter o certificado de CA em uma chave chamada cert. Este campo é opcional.

   Para saber como configurar o objeto do secret para o certificado de AC, consulte Configurar a autoridade de certificação.

   Para uma explicação sobre os campos e uma lista completa de campos que você pode adicionar ao campo spec, consulte Campos RootSync.

   Esse manifesto cria um objeto RootSync que usa o Git como origem.

2. Aplique as alterações:

   kubectl apply -f root-sync.yaml
   

3. Repita as etapas acima se precisar configurar mais de uma fonte raiz de verdade.

Controlar fontes de verdade com escopo de namespace

Tarefas administrativas centrais

O administrador central conclui as seguintes tarefas:

1. Na fonte raiz da verdade, declare uma configuração namespace para fontes com escopo de namespace.

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

   Substitua NAMESPACE por um nome para o namespace.

2. Na fonte raiz da verdade, declare um RoleBinding para dar permissões aos operadores de aplicativo. Use a prevenção de encaminhamento do RBAC para garantir que o operador do aplicativo não possa aplicar posteriormente uma vinculação de papel com permissões não concedidas por essa vinculação de papel.

   Para declarar o RoleBinding, crie o seguinte manifesto:

   # 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
   

   Substitua:

   • NAMESPACE: adicione o namespace que você criou na fonte raiz da verdade.
   • USERNAME: adicione o nome de usuário do operador do aplicativo.

   • OPERATOR_ROLE: como administrador central, é possível definir o OPERATOR_ROLE para impor quais tipos de configuração podem ser sincronizados a partir da fonte com escopo de namespace. É possível escolher um dos seguintes papéis:

     • Um ClusterRole padrão:

       • admin
       • edit

       Para saber mais, consulte Papéis voltados para o usuário.

     • Um ClusterRole ou Role definido pelo usuário declarado na fonte raiz da verdade. Esse papel permite permissões detalhadas.

3. Confirme as mudanças na fonte raiz da verdade:

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

Tarefas do operador do aplicativo

O operador do aplicativo pode controlar fontes com escopo de namespace concluindo as seguintes tarefas:

1. Declare uma configuração RoleBinding que conceda permissão de conta de serviço SERVICE_ACCOUNT_NAME provisionada automaticamente para gerenciar objetos no namespace. O Config Sync cria automaticamente a conta de serviço SERVICE_ACCOUNT_NAME quando a configuração RepoSync é sincronizada com o cluster.

   Para declarar o RoleBinding, crie o seguinte manifesto:

   # 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
   

   Substitua:

   • NAMESPACE: adicione o namespace que você criou na fonte raiz da verdade.
   • SERVICE_ACCOUNT_NAME: adicione o nome da conta de serviço do reconciliador. Se o nome do RepoSync for repo-sync, SERVICE_ACCOUNT_NAME será ns-reconciler-NAMESPACE. Caso contrário, será ns-reconciler-NAMESPACE-REPO_SYNC_NAME.
   • RECONCILER_ROLE: como o operador do aplicativo, é possível definir RECONCILER_ROLE para impor quais tipos de configuração podem ser sincronizados a partir da fonte com escopo de namespace. Só é possível restringir ainda mais o conjunto de permissões que o administrador central concedeu a você. Como resultado, esse papel não pode ser mais permissivo do que o OPERATOR_ROLE que o administrador central declarou na seção anterior.

2. Aplique a configuração do RoleBinding:

   kubectl apply -f sync-rolebinding.yaml
   

3. Se necessário, crie um secret com base no método de autenticação de sua preferência. Se você usou none como tipo de autenticação, pule esta etapa.

   O secret precisa atender aos seguintes requisitos:

   • Crie o secret no mesmo namespace que o RepoSync.
   • O nome do secret precisa corresponder ao nome spec.git.secretRef que você definiu em root-sync.yaml.
   • Você precisa adicionar a chave pública do secret ao provedor Git.

4. Declare uma configuração 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
   

   Substitua:

   • REPO_SYNC_NAME: adicione o nome do objeto RepoSync. O nome precisa ser exclusivo em todo o namespace.
   • NAMESPACE: adicione o nome do namespace.
   • NAMESPACE_REPOSITORY: adicione o URL do repositório Git para usar como repositório do namespace. É possível inserir URLs usando o protocolo HTTPS ou SSH. Por exemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa o protocolo HTTPS. Se você não inserir um protocolo, o URL será tratado como um URL HTTPS. Este campo é obrigatório.
   • NAMESPACE_REVISION: adicione a revisão Git (tag ou hash) para sincronizar. Este campo é opcional e o valor padrão é HEAD. A partir da versão 1.17.0 do Config Sync, também é possível especificar um nome de ramificação no campo revision. Ao usar um hash na versão 1.17.0 ou mais recente, ele precisa ser um hash completo, e não uma forma abreviada.
   • NAMESPACE_BRANCH: adicione a ramificação do repositório com que sincronizar. Este campo é opcional e o valor padrão é master. A partir da versão 1.17.0 do Config Sync, recomenda-se usar o campo revision para especificar um nome de ramificação para simplificação. Se o campo revision e o campo branch forem especificados, revision terá precedência sobre branch.

   • NAMESPACE_AUTH_TYPE: adicione um dos seguintes tipos de autenticação:

     • none: não usa autenticação
     • ssh: use um par de chaves SSH
     • cookiefile: use um cookiefile
     • token: usar um token
     • gcpserviceaccount: use uma conta de serviço do Google para acessar um repositório no Cloud Source Repositories.

     • gcenode: use uma conta de serviço do Google para acessar um repositório no Cloud Source Repositories. Selecione esta opção somente se a Federação de Identidade da Carga de Trabalho para GKE não estiver ativada no cluster.

       Para mais informações sobre esses tipos de autenticação, consulte Como conceder acesso somente leitura do Config Sync ao Git.

     Este campo é obrigatório.

   • NAMESPACE_EMAIL: se você adicionou gcpserviceaccount como NAMESPACE_AUTH_TYPE, adicione o endereço de e-mail da sua conta de serviço do Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

   • NAMESPACE_SECRET_NAME: adicione o nome que você pretende dar ao secret; Este campo é opcional.

   • NAMESPACE_NO_SSL_VERIFY: para desativar a verificação do certificado SSL, defina esse campo como true. O valor padrão é false.

   • NAMESPACE_CA_CERT_SECRET_NAME: adicione o nome do secret; Se esse campo estiver definido, seu provedor Git precisará usar um certificado emitido por essa autoridade certificadora (CA, na sigla em inglês). O secret precisa conter o certificado de CA em uma chave chamada cert. Este campo é opcional.

     Para saber como configurar o objeto do secret para o certificado de AC, consulte Configurar a autoridade de certificação.

   Para uma explicação dos campos e uma lista completa de campos que podem ser adicionados ao campo spec, consulte Campos 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
   

   Substitua:

   • REPO_SYNC_NAME: adicione o nome do objeto RepoSync. O nome precisa ser exclusivo em todo o namespace.
   • NAMESPACE: adicione o nome do namespace.

   • NAMESPACE_IMAGE: o URL da imagem OCI a ser usada como origem do namespace. Por exemplo, LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Por padrão, a imagem é extraída da tag latest, mas é possível extrair imagens por TAG ou DIGEST. Especifique TAG ou DIGEST no PACKAGE_NAME:

     • Para extrair por TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • Para extrair por DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
     Cuidado: O Config Sync exige que a camada OCI seja compactada em tar ou tar+gzip Outros formatos (por exemplo, tar+bz2) não serão reconhecidos pelo Config Sync. A mudança de um REPO válido para uma imagem OCI com um formato incompatível fará com que os recursos gerenciados sejam removidos sem um erro.

   • NAMESPACE_DIRECTORY: adicione o caminho na fonte ao diretório raiz que contém a configuração com a qual você quer sincronizar. Esse campo é opcional, e o padrão é o diretório raiz (/) da fonte.

   • NAMESPACE_AUTH_TYPE: adicione um dos seguintes tipos de autenticação:

     • none: não usa autenticação
     • gcenode: use a conta de serviço padrão do Compute Engine para acessar uma imagem no Artifact Registry. Selecione esta opção somente se a Federação de Identidade da Carga de Trabalho para GKE não estiver ativada no cluster.
     • gcpserviceaccount: use uma conta de serviço do Google para acessar uma imagem.

     Este campo é obrigatório.

   • NAMESPACE_EMAIL: se você adicionou gcpserviceaccount como ROOT_AUTH_TYPE, adicione o endereço de e-mail da sua conta de serviço do Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

   • NAMESPACE_CA_CERT_SECRET_NAME: adicione o nome do secret; Se esse campo estiver definido, seu provedor OCI, precisará usar um certificado emitido por essa autoridade certificadora (CA, na sigla em inglês). O secret precisa conter o certificado de CA em uma chave chamada cert. Este campo é opcional.

     Para saber como configurar o objeto do secret para o certificado de AC, consulte Configurar a autoridade de certificação.

   Para uma explicação sobre os campos e uma lista completa de campos que você pode adicionar ao campo spec, consulte Campos 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
   

   Substitua:

   • REPO_SYNC_NAME: adicione o nome do objeto RepoSync. O nome precisa ser exclusivo em todo o namespace.
   • NAMESPACE: adicione o nome do namespace.
   • NAMESPACE_REPOSITORY: o URL do repositório do Helm a ser usado como o repositório raiz. É possível inserir URLs usando o protocolo HTTPS ou SSH. Por exemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa o protocolo HTTPS. Este campo é obrigatório.
   • HELM_CHART_NAME: adicione o nome do seu gráfico do Helm. Este campo é obrigatório.
   • HELM_CHART_VERSION: a versão do gráfico. Este campo é opcional. Se nenhum valor for especificado, a versão mais recente será usada.
   • HELM_RELEASE_NAME: o nome da versão do Helm. Este campo é opcional.
   • HELM_RELEASE_NAMESPACE: o namespace de destino de uma versão. Ele define apenas um namespace para os recursos que contêm namespace: {{ .Release.Namespace }} nos modelos. Este campo é opcional. Se nenhum valor for especificado, o namespace padrão config-management-system será usado.
   • HELM_INCLUDE_CRDS: defina como true se você quiser que o modelo do Helm também gere uma CustomResourceDefinition. Este campo é opcional. Se nenhum valor for especificado, o padrão será false e um CRD não será gerado.
   • VALUE: valores a serem usados em vez de valores padrão que acompanham o gráfico Helm. Formate esse campo da mesma forma que o arquivo values.yaml do gráfico do helm. Este campo é opcional.

   • ROOT_AUTH_TYPE: adicione um dos seguintes tipos de autenticação:

     • none: não usa autenticação
     • token: use um nome de usuário e uma senha para acessar um repositório particular do Helm.
     • gcenode: use a conta de serviço padrão do Compute Engine para acessar uma imagem no Artifact Registry. Selecione esta opção somente se a Federação de Identidade da Carga de Trabalho para GKE não estiver ativada no cluster.
     • gcpserviceaccount: use uma conta de serviço do Google para acessar uma imagem.

     Este campo é obrigatório.

   • NAMESPACE_EMAIL: se você adicionou gcpserviceaccount como ROOT_AUTH_TYPE, adicione o endereço de e-mail da sua conta de serviço do Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com.

   • NAMESPACE_SECRET_NAME: adicione o nome do secret se token for o ROOT_AUTH_TYPE. Este campo é opcional.

   • NAMESPACE_CA_CERT_SECRET_NAME: adicione o nome do secret; Se esse campo estiver definido, seu provedor Helm precisará usar um certificado emitido por essa autoridade certificadora (CA, na sigla em inglês). O secret precisa conter o certificado de CA em uma chave chamada cert. Este campo é opcional.

     Para saber como configurar o objeto do secret para o certificado de AC, consulte Configurar a autoridade de certificação.

   Para uma explicação sobre os campos e uma lista completa de campos que você pode adicionar ao campo spec, consulte Campos RootSync.

5. Aplique a configuração RepoSync:

   kubectl apply -f repo-sync.yaml
   

6. Para verificar a configuração, use kubectl get em um dos objetos na fonte com escopo de namespace. Por exemplo:

   kubectl get rolebindings -n NAMESPACE
   

7. Repita as etapas acima se precisar configurar várias fontes de verdade com escopo de namespace.

Verificar o status de sincronização da fonte de verdade

Você pode usar o comando nomos status para inspecionar o status de sincronização da fonte de verdade:

nomos status

O resultado será semelhante a:

my_managed_cluster-1
  --------------------
  <root>   [e-mail]:foo-corp/acme/admin@main
  SYNCED   f52a11e4
  --------------------
  bookstore  [e-mail]:foo-corp/acme/bookstore@v1
  SYNCED     34d1a8c8

Nesta saída de exemplo, a fonte com escopo de namespace, neste caso um repositório Git, está configurada para um namespace chamado bookstore.

Verificar a instalação do RootSync

Quando você cria um objeto RootSync, o Config Sync cria um reconciliador com o prefixo root-reconciler. Um reconciliador é um pod implantado como uma implantação. Ele sincroniza manifestos de uma fonte de verdade com um cluster.

Para verificar se o objeto RootSync está funcionando corretamente, verifique o status da implantação do root-reconciler:

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

Substitua ROOT_SYNC_NAME pelo nome de RootSync.

O resultado será semelhante a:

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

Para conhecer outras formas de explorar o status do objeto RootSync, consulte Como monitorar objetos RootSync e RepoSync.

Verificar a instalação do RepoSync

Quando você cria um objeto RepoSync, o Config Sync cria um reconciliador com o prefixo ns-reconciler-NAMESPACE, em que NAMESPACE é o namespace em que você criou seu objeto RepoSync.

É possível verificar se o objeto RepoSync está funcionando corretamente verificando o status da implantação do reconciliador de namespace:

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

Substitua REPO_SYNC_NAME pelo nome do RepoSync e NAMESPACE pelo namespace em que você criou a fonte da verdade com escopo de namespace.

Para outras maneiras de explorar o status do seu objeto RepoSync, consulte a seção Como explorar os objetos RootSync e RepoSync.

Remover uma fonte da verdade

Selecione a guia Método de controle central ou Método da API Kubernetes para visualizar as instruções relevantes.

Método de controle central

Se você usou o método Controlar fontes de verdade em uma fonte raiz da verdade, um administrador central pode seguir as duas etapas a seguir para remover uma fonte de verdade:

1. Decida se você quer excluir ou manter os recursos gerenciados pelos objetos RootSync e RepoSync.

   • Para excluir todos os recursos que seus objetos RootSync ou RepoSync gerenciam, sincronize seu objeto RootSync ou RepoSync com uma origem vazia. Por exemplo, um repositório do GitHub sem configurações. Caso seu objeto RootSync ou RepoSync contenha outro objeto RootSync ou RepoSync, o RootSync ou RepoSync interno precisa primeiro ser sincronizado em um repositório Git vazio.

   • Se você tiver ativado o webhook e quiser manter seus recursos, desative a prevenção de deslocamento para recursos abandonados. Se você não tiver ativado o webhook, não precisará fazer mais nada para manter os recursos.

2. Remova o objeto RootSync ou RepoSync da fonte da verdade.

Método da API Kubernetes

Se você usou o método Controlar fontes de verdade com escopo de namespace com a API Kubernetes, os operadores de aplicativo podem usar as etapas a seguir para remover uma fonte de verdade com escopo de namespace:

1. Decida se você quer excluir ou manter os recursos gerenciados pelos objetos RootSync e RepoSync.

   • Para excluir todos os recursos que seus objetos RootSync ou RepoSync gerenciam, sincronize seu objeto RootSync ou RepoSync com uma origem vazia. Por exemplo, um repositório do GitHub sem configurações. Caso seu objeto RootSync ou RepoSync contenha outro objeto RootSync ou RepoSync, o RootSync ou RepoSync interno precisa primeiro ser sincronizado em um repositório Git vazio.

   • Se você tiver ativado o webhook e quiser manter seus recursos, desative a prevenção de deslocamento para recursos abandonados. Se você não tiver ativado o webhook, não precisará fazer mais nada para manter os recursos.

2. Exclua o objeto RootSync ou RepoSync executando o seguinte comando:

   kubectl delete -f FILE_NAME
   

   Substitua FILE_NAME pelo nome do arquivo de configuração RootSync ou RepoSync. Por exemplo, root-sync.yaml.

A seguir

• Saiba como evitar desvios de configuração em fontes de verdade com escopo de namespace.
• Descubra como monitorar seus objetos RootSync e RepoSync.
• Saiba como dividir uma fonte de verdade em várias fontes.