Configurar a sincronização de vários repositórios

Ao instalar o Config Sync, é possível configurar um repositório raiz. Depois de configurar um repositório raiz, você tem a opção de configurar outros repositórios raiz e de namespace. Os repositórios de namespaces permitem realizar tarefas como delegar a configuração e o controle de repositórios a usuários não administrativos. Para saber mais sobre esses tipos de repositórios, consulte a referência de repositórios.

Os repositórios de namespace exigem a API RepoSync. Se você instalou o Config Sync usando o Console do Google Cloud ou a Google Cloud CLI e uma versão 1.7.0 ou posterior, essa API já está ativada. Se você instalou o Config Sync usando kubectl e está usando um objeto ConfigManagement para configurar seu repositório Git, recomendamos que migre seu objeto ConfigManagement para ativar a API RepoSync.

O Config Sync detecta automaticamente alterações da fonte da verdade. No entanto, é possível adicionar uma camada extra de detecção de deslocamentos adicionando um webhook de admissão aos repositórios de namespace. Para ver detalhes sobre como fazer isso, consulte Impedir a configuração deslocamento.

Antes de começar

Crie ou verifique se você tem acesso a um repositório Git não estruturado que pode conter os configs com que o Config Sync é sincronizado. Os repositórios 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 com o Anthos.
Crie ou verifique se você tem acesso a um cluster do GKE que atenda aos requisitos do Config Sync.

Limitações

NamespaceSelectors (incluindo anotações que apontam para os seletores) só funciona em repositórios raiz.

Escolher seu método de configuração preferido

Escolha um dos dois métodos de configuração de repositórios:

Controlar repositórios em um repositório central. Esse método centraliza toda a configuração de um repositório em outro repositório, permitindo que um administrador central controle total da configuração.
Controlar repositórios com a API Kubernetes Use esse método se quiser delegar o controle do repositório para diferentes proprietários.

Controlar repositórios em um repositório central

Controlar repositórios raiz em um repositório raiz

O Config Sync é compatível com a sincronização de vários repositórios raiz. O administrador central pode usar um repositório raiz central para gerenciar vários repositórios raiz. 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:

No repositório raiz central, crie um objeto RootSync com um nome exclusivo.
```
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  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. O nome precisa ser exclusivo no cluster e ter no máximo 26 caracteres.
- 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. Se você não inserir um protocolo, o URL será tratado como um URL HTTPS. Este campo é obrigatório.
- ROOT_REVISION: adicione a revisão do Git (tag ou hash) para check-out. Este campo é opcional e o valor padrão é HEAD.
- ROOT_BRANCH: adicione a ramificação do repositório com que sincronizar. Este campo é opcional e o valor padrão é master.
- 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 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 identidade da carga de trabalho não estiver ativada em seu 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 mais sobre como configurar o objeto do secret para o certificado de CA, consulte Configurar operador de uma 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.

Confirme antes as mudanças no repositório:

 git add .
 git commit -m 'Setting up a new root repository.'
 git push

Repita as etapas acima se precisar configurar vários repositórios raiz.

Controlar repositórios de namespace em um repositório raiz

Os repositórios de namespaces podem ser gerenciados por um repositório raiz. Como os objetos do repositório de namespace são gerenciados pelo Config Sync, esse método impede qualquer alteração local para as definições de repositório de namespace.

Para usar esse recurso, conclua as seguintes tarefas:

No repositório raiz, declare uma configuração namespace:

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

Substitua NAMESPACE por um nome para o namespace.

No repositório raiz, crie um objeto RepoSync no mesmo namespace:
```
# ROOT_REPO/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  # Since this is for a namespace repository, the format should be 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. REPO_SYNC_NAME e NAMESPACE não podem ter mais de 24 caracteres. Se NAMESPACE_AUTH_TYPE for usado, REPO_SYNC_NAME, NAMESPACE e NAMESPACE_AUTH_TYPE não poderão ter mais de 44 caracteres.
- 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 do Git (tag ou hash) para check-out. Este campo é opcional e o valor padrão é HEAD.
- NAMESPACE_BRANCH: adicione a ramificação do repositório com que sincronizar. Este campo é opcional e o valor padrão é master.
- NAMESPACE_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.
- 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 identidade da carga de trabalho não estiver ativada em seu 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 mais sobre como configurar o objeto do secret para o certificado de CA, consulte Configurar operador de uma 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.
No repositório 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.

Para declarar o RoleBinding, crie o seguinte objeto:
```
# 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: RECONCILER_ROLE
   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.
- RECONCILER_ROLE: como administrador central, é possível definir o RECONCILER_ROLE para impor quais tipos de configuração podem ser sincronizados a partir do repositório 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 no repositório raiz. Esse papel permite permissões detalhadas.

Confirme antes as mudanças no repositório:

 git add .
 git commit -m 'Setting up a new namespace repository.'
 git push

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.
Para verificar a configuração, use kubectl get em um dos objetos no repositório de namespace. Exemplo:
```
kubectl get rolebindings -n NAMESPACE
```
Repita as etapas acima se precisar configurar vários repositórios de namespace.

Controlar repositórios de namespaces em um repositório de namespaces

O Config Sync é compatível com a sincronização de vários repositórios de namespace por namespace. Os repositórios de namespaces podem ser gerenciados em um repositório de namespace no mesmo namespace.

Para usar esse recurso, conclua as seguintes tarefas:

Em um repositório de namespaces, crie um objeto RepoSync no mesmo namespace:
```
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  # Since this is for a namespace repository, the format should be 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. REPO_SYNC_NAME e NAMESPACE não podem ter mais de 24 caracteres. Se NAMESPACE_AUTH_TYPE for usado, REPO_SYNC_NAME, NAMESPACE e NAMESPACE_AUTH_TYPE não poderão ter mais de 44 caracteres.
- 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 do Git (tag ou hash) para check-out. Este campo é opcional e o valor padrão é HEAD.
- NAMESPACE_BRANCH: adicione a ramificação do repositório com que sincronizar. Este campo é opcional e o valor padrão é master.
- NAMESPACE_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.
- 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 identidade da carga de trabalho não estiver ativada em seu 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 mais sobre como configurar o objeto do secret para o certificado de CA, consulte Configurar operador de uma 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.
No repositório de namespace, 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.

Para declarar o RoleBinding, crie o seguinte objeto:
```
# 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: RECONCILER_ROLE
   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.
- RECONCILER_ROLE: como administrador central, é possível definir o RECONCILER_ROLE para impor quais tipos de configuração podem ser sincronizados a partir do repositório 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 no repositório raiz. Esse papel permite permissões detalhadas.

Confirme antes as mudanças no repositório:

 git add .
 git commit -m 'Setting up a new namespace repository.'
 git push

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.
Para verificar a configuração, use kubectl get em um dos objetos no repositório de namespace. Exemplo:
```
kubectl get rolebindings -n NAMESPACE
```
Repita as etapas acima se precisar configurar vários repositórios de namespace.

Controlar repositórios 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 declara somente o namespace no repositório raiz e delega a declaração do objeto RepoSync ao operador do aplicativo.

Controlar repositórios raiz

Outros administradores podem controlar os repositórios raiz concluindo as seguintes tarefas:

Declare um objeto RootSync:
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  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. O nome precisa ser exclusivo no cluster e ter no máximo 26 caracteres.
- 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. Se você não inserir um protocolo, o URL será tratado como um URL HTTPS. Este campo é obrigatório.
- ROOT_REVISION: adicione a revisão do Git (tag ou hash) para check-out. Este campo é opcional e o valor padrão é HEAD.
- ROOT_BRANCH: adicione a ramificação do repositório com que sincronizar. Este campo é opcional e o valor padrão é master.
- 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 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 identidade da carga de trabalho não estiver ativada em seu 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 você estiver usando um secret, adicione 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 mais sobre como configurar o objeto do secret para o certificado de CA, consulte Configurar operador de uma 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.
Aplique as alterações:
```
kubectl apply -f root-sync.yaml
```
Repita as etapas acima se precisar configurar vários repositórios raiz.

Controlar repositórios de namespace

Tarefas administrativas centrais

O administrador central conclui as seguintes tarefas:

No repositório raiz, declare uma configuração namespace para repositórios de namespace.
```
# ROOT_REPO/namespaces/NAMESPACE/namespace.yaml
 apiVersion: v1
 kind: Namespace
 metadata:
   name: NAMESPACE
```
Substitua NAMESPACE por um nome para o namespace.
No repositório raiz, declare uma RoleBinding para conceder permissões aos operadores do 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 criado no repositório raiz.
- 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 do repositório 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 papel definido pelo usuário declarado no repositório raiz. Esse papel permite permissões detalhadas.

Confirme antes as mudanças no repositório:

 git add .
 git commit -m 'Setting up new namespace repository.'
 git push

Tarefas do operador do aplicativo

O operador do aplicativo pode controlar os repositórios de namespace concluindo as seguintes tarefas:

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 criado no repositório raiz.
- 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 do repositório 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.
Aplique a configuração do RoleBinding:
```
kubectl apply -f sync-rolebinding.yaml
```
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.
Declare uma configuração RepoSync:
```
# repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  # Since this is for a namespace repository, the format should be 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: REPO_SSL_VERIFY
   caCertSecretRef:
     name: NAMESPACE_CA_CERT_SECRET_NAME
```
Substitua:
- REPO_SYNC_NAME: adicione o nome do objeto RepoSync.
- 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 do Git (tag ou hash) para check-out. Este campo é opcional e o valor padrão é HEAD.
- NAMESPACE_BRANCH: adicione a ramificação do repositório com que sincronizar. Este campo é opcional e o valor padrão é master.
- NAMESPACE_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.
- 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 identidade da carga de trabalho não estiver ativada em seu 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 mais sobre como configurar o objeto do secret para o certificado de CA, consulte Configurar operador de uma 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.

Pode haver no máximo um objeto RepoSync por namespace. Para impor isso, o nome do objeto name precisa ser repo-sync. Todas as configurações contidas no diretório referenciado pelo RepoSync também precisam estar no mesmo namespace que o objeto RepoSync.
Aplique a configuração RepoSync:
```
kubectl apply -f repo-sync.yaml
```
Para verificar a configuração, use kubectl get em um dos objetos no repositório de namespace. Exemplo:
```
kubectl get rolebindings -n NAMESPACE
```
Repita as etapas acima se precisar configurar vários repositórios de namespace.

Verificar o status de sincronização do repositório

Use o comando nomos status para inspecionar o status de sincronização do repositório:

nomos status

O resultado será semelhante a:

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

Nesta saída de exemplo, o repositório de namespace é configurado para o 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 um repositório Git 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 substitua NAMESPACE pelo namespace em que você criou seu repositório de namespaces.

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

Remover um repositório

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 repositórios em um repositório central, um administrador central pode seguir as duas etapas a seguir para remover um repositório:

Remova ou exclua os recursos gerenciados pelo objeto RootSync ou RepoSync seguindo as instruções de solução.
Remova o objeto RootSync ou RepoSync do repositório Git

Método da API Kubernetes

Se você usou o método Controlar repositórios de namespaces com a API Kubernetes, os operadores de aplicativos poderão seguir as duas etapas a seguir para remover um repositório de namespace:

Remova ou exclua os recursos gerenciados pelo objeto RootSync ou RepoSync seguindo as instruções de solução.
Exclua o objeto RootSync ou RepoSync executando o seguinte comando:
```
kubectl delete -f FILE_NAME
```
Substitua FILE_NAME por root-sync.yaml ou repo-sync.yaml.

A seguir

Saiba como evitar desvios de configuração em repositórios de namespace.
Descubra como monitorar seus objetos RootSync e RepoSync.
Saiba como dividir um repositório em vários repositórios.