Instalar o Config Sync

Com o Config Sync, é possível gerenciar os recursos do Kubernetes com arquivos de configuração armazenados em uma fonte de verdade. O Config Sync é compatível com repositórios Git, imagens OCI e gráficos do Helm como uma fonte de verdade. Nesta página, mostramos como ativar e configurar o Config Sync para que ele seja sincronizado com seu repositório raiz. O Config Sync está disponível com a edição Google Kubernetes Engine (GKE) Enterprise.

Quando você instala o Config Sync usando o Console do Google Cloud ou a Google Cloud CLI, as APIs RootSync e RepoSync são ativadas por padrão. Com esse operador, você tem recursos adicionais como a sincronização de vários repositórios e a sincronização das configurações do Kustomize e do Helm.

Antes de começar

Antes de instalar o Config Sync, prepare seu ambiente, verifique se você atende aos requisitos do cluster e conceda os papéis de usuário certos.

Preparar o ambiente local

Prepare o ambiente local concluindo as tarefas a seguir:

Crie ou verifique se você tem acesso a uma fonte de informações. Esse é o lugar em que você adiciona as configurações que o Config Sync sincroniza. Para saber mais sobre como definir as configurações e a fonte de informações, consulte um destes guias:
Instale e inicialize a Google Cloud CLI, que fornece os comandos gcloud e nomos. Se você usa o Cloud Shell, a Google Cloud CLI já vem pré-instalada. Se você já instalou a Google Cloud CLI, instale a versão mais recente executando gcloud components update.
Ative a API GKE Enterprise.

Ativar a API GKE Enterprise

Requisitos de cluster

Crie ou tenha acesso a um cluster que atenda aos seguintes requisitos:

O cluster está em uma plataforma e versão compatíveis da edição Google Kubernetes Engine (GKE) Enterprise.
Se você usar clusters do Autopilot, ele vai ajustar os requisitos de recursos do contêiner para atender às seguintes regras:
Observação: se os requisitos de recursos forem ajustados, o Autopilot vai adicionar uma anotação autopilot.gke.io/resource-adjustment à carga de trabalho, que indica os recursos de entrada e saída.

Devido a essas regras, para clusters do Autopilot, o Config Sync:
- ajusta os limites de substituição de recursos especificados pelo usuário para corresponder às solicitações.
- aplica as substituições apenas quando existe uma ou mais solicitações de recursos superiores à saída ajustada correspondente declarada na anotação ou existe uma ou mais solicitações de recursos inferiores à entrada correspondente declarada na anotação.
(Opcional) O cluster terá a Identidade da carga de trabalho ativada se você usar clusters do GKE. A Identidade da carga de trabalho é a maneira indicada para acessar os serviços do Google Cloud em aplicativos executados no GKE. Esse método fornece propriedades de segurança e gerenciamento aprimorados. Os clusters do Autopilot têm a identidade da carga de trabalho ativada por padrão.
Conceda as permissões de gravação de métrica corretas para que o Config Sync possa enviar métricas para o Cloud Monitoring. Isso é obrigatório se você quiser usar upgrades automáticos.
Se você quiser fazer upgrade automático da versão do Config Sync, verifique se o cluster do GKE está inscrito em um canal de lançamento. Um cluster que não usa canais de lançamento do GKE é tratado como um cluster que usa o canal de lançamento Stable.
Se você quiser usar um cluster particular do GKE, configure o Cloud NAT para permitir a saída de nós particulares do GKE. Para detalhes, consulte Exemplo de configuração do GKE. Se preferir, ative o Acesso privado do Google para se conectar ao conjunto de endereços IP externos usados pelas APIs e serviços do Google.

Observação: o Acesso privado do Google não é compatível com SSH na porta 2022. No entanto, quando você concede acesso somente leitura ao Config Sync ao Git, é possível usar credenciais de cookiefile.
Se você quiser usar uma conta de serviço do Google ao conceder acesso ao Config Sync à sua fonte de informações, inclua o escopo somente leitura nos escopos de acesso dos nós no cluster do Cloud Source Repositories.

É possível adicionar o escopo somente leitura incluindo cloud-source-repos-ro na lista --scopes especificada no momento da criação do cluster ou usando o escopo cloud-platform no momento da criação do cluster. Exemplo:
```
gcloud container clusters create CLUSTER_NAME --scopes=cloud-platform
```
Não é possível modificar os escopos de acesso depois de criar um pool de nós. No entanto, é possível criar um novo pool de nós com o escopo de acesso apropriado e usar o mesmo cluster. O escopo gke-default padrão não inclui cloud-source-repos-ro.
Se você tiver requisitos rígidos de firewall da VPC que bloqueiam qualquer tráfego desnecessário, será necessário Criar regras de firewall para permitir o tráfego a seguir em clusters públicos do GKE:
- TCP: permite a entrada e a saída nas portas 53 e 443
- UDP: permitir a saída na porta 53
Se você não incluir essas regras, o Config Sync não será sincronizado corretamente, com nomos status informando o seguinte erro:

Error: KNV2004: unable to sync repo Error in the git-sync container

Pule essas etapas se estiver usando um cluster particular do GKE.
Execute o Config Sync em um pool de nós amd64. As imagens de contêiner do componente de back-end do Config Sync são criadas, distribuídas e testadas apenas para a arquitetura de máquina amd64. Se um componente do Config Sync estiver programado em um nó do ARM, ele apresentará o erro exec format e falhará.

Se você tiver nós Arm no cluster, adicione um ou mais nós amd64 ao cluster e, se não estiver usando um cluster do GKE, adicione um taint aos nós arm64 para evitar a programação de pods nos nós arm64 sem uma tolerância específica. Os nós do grupo do GKE já têm um taint padrão, então você não precisa adicionar um.

Preparar o cluster

Depois de criar um cluster adequado, siga estas etapas:

Conceda os papéis do IAM ao usuário que registra o cluster.
Se você planeja usar a Google Cloud CLI para configurar o Config Sync ou usar clusters fora do Google Cloud, verifique se os clusters do GKE ou clusters fora do Google Cloud estão registradas em uma frota agora. Se você planeja usar o console do Google Cloud, é possível registrar clusters do GKE ao configurar o Config Sync.

Instalar o Config Sync

Nas seções a seguir, você concede ao Config Sync acesso a uma destas fontes de verdade:

Repositório do Git
Imagem da OCI
Gráfico do Helm

Depois de conceder o acesso, é possível configurar o Config Sync.

Permitir acesso ao Git

O Config Sync precisa de acesso somente leitura ao seu repositório Git para ler os configs confirmados no repositório e aplicá-los aos clusters.

Se o repositório não exigir autenticação para acesso somente leitura, será possível continuar a configurar o Config Sync e usar none como o tipo de autenticação. Por exemplo, se for possível navegar no repositório usando uma interface da Web sem fazer login ou usar git clone para criar um clone do repositório localmente sem fornecer credenciais ou usar credenciais salvas, não será necessário fazer a autenticação. Nesse caso, você não precisa criar um secret.

No entanto, a maioria dos usuários precisa criar credenciais porque o acesso de leitura ao repositório é restrito. Se as credenciais forem necessárias, elas serão armazenadas no secret git-creds em cada cluster registrado (a menos que você esteja usando uma conta de serviço do Google). O secret precisa ser nomeado como git-creds porque esse é um valor fixo.

O Config Sync é compatível com os seguintes mecanismos de autenticação:

Par de chaves SSH (ssh)
Cookiefile (cookiefile)
Token (token)
Conta de serviço do Google (gcpserviceaccount)
Conta de serviço padrão do Compute Engine (gcenode)

O mecanismo que você escolhe depende do suporte que seu repositório oferece. Geralmente, recomendamos o uso de um par de chaves SSH. O GitHub e o Bitbucket são compatíveis com o uso de um par de chaves SSH. No entanto, se você estiver usando um repositório no Cloud Source Repositories, recomendamos que utilize uma conta de serviço do Google, já que o processo é mais simples. Caso sua organização hospede o repositório e você não saiba quais métodos de autenticação são compatíveis, entre em contato com o administrador.

Para usar um repositório no Cloud Source Repositories como seu repositório do Config Sync, conclua as etapas a seguir para recuperar o URL do Cloud Source Repositories:

Liste todos os repositórios:
```
gcloud source repos list
```
No resultado, copie o URL do repositório que você quer usar. Exemplo:
```
REPO_NAME  PROJECT_ID  URL
my-repo    my-project  https://source.developers.google.com/p/my-project/r/my-repo-csr
```
Você precisa usar esse URL ao configurar o Config Sync na seção a seguir. Se você configurar o Config Sync usando o Console do Google Cloud, adicione o URL no campo URL. Se você configurar o Config Sync usando a Google Cloud CLI, adicione o URL ao campo syncRepo do arquivo de configuração.

Par de chaves SSH

Um par de chaves SSH consiste em dois arquivos, uma chave pública e uma chave privada. A chave pública normalmente tem uma extensão .pub.

Para usar um par de chaves SSH, conclua estas etapas:

Crie um par de chaves SSH para permitir que o Config Sync faça a autenticação no seu repositório Git. Essa etapa é necessária se você precisar se autenticar no repositório para cloná-lo ou lê-lo. Pule esta etapa se um administrador de segurança fornecer um par de chaves a você. É possível usar um único par de chaves para todos os clusters ou um par de chaves por cluster, dependendo dos seus requisitos de segurança e conformidade.

O comando a seguir cria uma chave RSA de 4.096 bits. Valores inferiores não são recomendados:
```
ssh-keygen -t rsa -b 4096 \
-C "GIT_REPOSITORY_USERNAME" \
-N '' \
-f /path/to/KEYPAIR_FILENAME
```
Substitua:
- GIT_REPOSITORY_USERNAME: o nome de usuário que você quer que o Config Sync use para se autenticar no repositório
- /path/to/KEYPAIR_FILENAME: um caminho para o par de chaves
Se você estiver usando um host de repositório Git de terceiros, como o GitHub, ou quiser usar uma conta de serviço com o Cloud Source Repositories, recomendamos usar uma conta separada.

Observação: crie a chave SSH sem uma senha longa. O Config Sync não é compatível com senhas longas de chave SSH.
Configure seu repositório para reconhecer a chave pública recém-criada. Consulte a documentação do seu provedor de hospedagem Git. Instruções para alguns provedores de hospedagem Git conhecidos estão incluídas por conveniência:
- Cloud Source Repositories
- Bitbucket
- GitHub Recomendamos que você crie chaves de implantação separadas para fornecer acesso somente leitura a um único repositório do GitHub.
- GitLab

Adicione a chave privada a um novo Secret no cluster:

kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
 --namespace=config-management-system \
 --from-file=ssh=/path/to/KEYPAIR_PRIVATE_KEY_FILENAME

Substitua /path/to/KEYPAIR_PRIVATE_KEY_FILENAME pelo nome da chave privada (aquela sem o sufixo .pub).

(Recomendado) Para configurar a verificação de hosts conhecidos usando a autenticação SSH, adicione a chave de hosts conhecida ao campo data.known_hosts no secret git_creds. Para desativar a verificação de known_hosts, remova o campo known_hosts do secret. Para adicionar a chave de hosts conhecida, execute:
```
kubectl edit secret git-creds \
 --namespace=config-management-system
```
Em seguida, em data, adicione a entrada de hosts conhecida:
```
known_hosts: KNOWN_HOSTS_KEY
```
Exclua a chave privada do disco local ou a proteja.
Ao configurar o Config Sync e adicionar o URL do repositório Git, use o protocolo SSH. Se você estiver usando um repositório no Cloud Source Repositories, será preciso usar o seguinte formato ao inserir o URL:
```
ssh://EMAIL@source.developers.google.com:2022/p/PROJECT_ID/r/REPO_NAME
```
Substitua:
- EMAIL: seu nome de usuário do Google Cloud;
- PROJECT_ID: o ID do projeto do Google Cloud em que o repositório está localizado;
- REPO_NAME: o nome do repositório.

Cookiefile

O processo para adquirir um cookiefile depende da configuração no repositório. Para ver um exemplo, consulte Gerar credenciais estáticas na documentação do Cloud Source Repositories. As credenciais geralmente são armazenadas no arquivo .gitcookies no diretório principal ou podem ser fornecidas a você por um administrador de segurança.

Para criar um cookiefile, conclua as etapas a seguir:

Depois de criar e conseguir o cookiefile, adicione-o a um novo Secret no cluster.

Se você não usa um proxy HTTPS, crie o Secret com o seguinte comando:
```
kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
 --namespace=config-management-system \
 --from-file=cookie_file=/path/to/COOKIEFILE
```
Se você precisar usar um proxy HTTPS, adicione-o ao secret junto de cookiefile executando o comando a seguir:
```
kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
 --namespace=config-management-system \
 --from-file=cookie_file=/path/to/COOKIEFILE \
 --from-literal=https_proxy=HTTPS_PROXY_URL
```
Substitua:
- /path/to/COOKIEFILE: o caminho e nome de arquivo adequados;
- HTTPS_PROXY_URL: o URL do proxy HTTPS que você usa ao se comunicar com o repositório Git.
Observação: por questões de segurança, o proxy HTTP não é suportado.
Proteja o conteúdo do cookiefile se você ainda precisar dele localmente. Caso contrário, exclua-o.

Token

Se sua organização não permitir o uso de chaves SSH, talvez você prefira usar um token. Com o Config Sync, é possível usar os tokens de acesso pessoal (PATs, na sigla em inglês) do GitHub ou do GiLab, chaves de implantação ou a senha do app Bitbucket como token.

Para criar um secret usando seu token, execute as etapas a seguir.

Crie um token usando o GitHub, o GitLab ou o Bitbucket.
- GitHub: crie um PAT. Conceda ao token o escopo repo para que ele possa ler os repositórios particulares. Como você vincula um PAT a uma conta do GitHub, também recomendamos criar um usuário de máquina e vincular seu PAT a ele.
- GitLab: crie um PAT ou um token de implantação
- Bitbucket: crie uma senha de app.
Depois de criar e receber o token, adicione-o a um novo secret no cluster.

Se você não usa um proxy HTTPS, crie o Secret com o seguinte comando:
```
kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
  --namespace="config-management-system" \
  --from-literal=username=USERNAME \
  --from-literal=token=TOKEN
```
Substitua:
- USERNAME: o nome de usuário que você quer usar
- TOKEN: o token que você criou na etapa anterior
Se você precisar usar um proxy HTTPS, adicione-o ao secret junto de username e token executando o comando a seguir:
```
kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
 --namespace=config-management-system \
 --from-literal=username=USERNAME \
  --from-literal=token=TOKEN \
 --from-literal=https_proxy=HTTPS_PROXY_URL
```
Substitua:
- USERNAME: o nome de usuário que você quer usar
- TOKEN: o token que você criou na etapa anterior
- HTTPS_PROXY_URL: o URL do proxy HTTPS que você usa ao se comunicar com o repositório Git.
Observação: por questões de segurança, o proxy HTTP não é suportado.
Proteja o token se você ainda precisar dele localmente. Caso contrário, exclua-o.

Conta de serviço do Google.

Se o repositório estiver no Cloud Source Repositories e o cluster usar a Identidade da carga de trabalho do GKE ou a Identidade da carga de trabalho da frota, será possível conceder ao Config Sync acesso a um repositório no mesmo projeto que o cluster gerenciado usando uma conta de serviço do Google.

Crie uma conta de serviço se você ainda não tiver uma.
Conceda o papel do IAM de Leitor do Cloud Source Repositories (roles/source.reader) à conta de serviço do Google. Para mais informações sobre os papéis e permissões do Cloud Source Repositories, consulte Conceder permissões para visualizar repositórios.
- Conceda permissão a todo o projeto se as mesmas permissões se aplicarem a todos os repositórios no projeto.
```
gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/source.reader \
  --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
```
- Conceda permissão específica do repositório quando quiser que as contas de serviço tenham diferentes níveis de acesso para cada repositório no projeto.
```
gcloud source repos set-iam-policy REPOSITORY POLICY_FILE --project=PROJECT_ID
```
Se você configurar o Config Sync usando o Console do Google Cloud, selecione Identidade da carga de trabalho como o Tipo de autenticação e adicione o e-mail da sua conta de serviço.

Se você configurar o Config Sync usando a Google Cloud CLI, adicione gcpserviceaccount como secretType e adicione o e-mail da conta de serviço a gcpServiceAccountEmail.
Depois configurar o Config Sync, crie uma vinculação de política do IAM entre a conta de serviço do Kubernetes e a conta de serviço do Google. A conta de serviço do Kubernetes não será criada até que você configure o Config Sync pela primeira vez.

Se você estiver usando clusters registrados em uma frota, só precisará criar a vinculação de política uma vez por frota. Todos os clusters registrados em uma frota compartilham o mesmo pool de Identidade da carga de trabalho. Com o conceito de semelhança da frota, se você adicionar a política do IAM à sua conta de serviço do Kubernetes em um cluster, a conta de serviço do Kubernetes do mesmo namespace em outros clusters da mesma frota também receberá a mesma política do IAM.

Essa vinculação permite que a conta de serviço do Kubernetes do Config Sync atue como a conta de serviço do Google:
```
gcloud iam service-accounts add-iam-policy-binding \
    GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/iam.workloadIdentityUser \
    --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
    --project=PROJECT_ID
```

Substitua:

PROJECT_ID: ID do projeto da organização.
FLEET_HOST_PROJECT_ID: se você estiver usando a Identidade da carga de trabalho do GKE, será igual a PROJECT_ID. Se você estiver usando a identidade da carga de trabalho da frota, esse será o ID do projeto da frota em que o cluster está registrado.
GSA_NAME: a conta de Serviço do Google personalizada que você quer usar para se conectar ao Artifact Registry. Essa conta de serviço precisa ter o papel do IAM "Leitor do Artifact Registry" (roles/artifactregistry.reader).
KSA_NAME: a conta de serviço do Kubernetes do reconciliador.
- Para repositórios raiz, se o nome RootSync for root-sync, use root-reconciler. Caso contrário, use root-reconciler-ROOT_SYNC_NAME. Se você instalar o Config Sync usando o console do Google Cloud ou a Google Cloud CLI, o Config Sync criará automaticamente um objeto RootSync chamado root-sync.
REPOSITORY: o nome do repositório.
POLICY_FILE: o arquivo JSON ou YAML com a política do Identity and Access Management.

Conta de serviço padrão do Compute Engine

Se o repositório estiver no Cloud Source Repositories e o cluster for do GKE no Google Cloud com a Identidade da carga de trabalho desativada, será possível usar gcenode como o tipo de autenticação.

Se você configurar o Config Sync usando o Console do Google Cloud, selecione Google Cloud Repository como o Tipo de autenticação.

Se você configurar o Config Sync usando a Google Cloud CLI, adicione gcenode como secretType.

Selecionar o Google Cloud Repository ou gcenode permite que você use a conta de serviço padrão do Compute Engine. Conceda o papel do IAM de Leitor do Cloud Source Repositories (roles/source.reader) à conta de serviço padrão do Compute Engine. Para mais informações sobre os papéis e permissões do Cloud Source Repositories, consulte Conceder permissões para visualizar repositórios.

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/source.reader \
  --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

Substitua PROJECT_ID pelo ID do projeto da organização e PROJECT_NUMBER pelo número do projeto da organização.

Conceder acesso somente leitura do Config Sync ao OCI

O Config Sync precisa de acesso somente leitura à imagem OCI armazenada no Artifact Registry para ler as configurações incluídas na imagem e aplicá-las aos clusters.

No entanto, a maioria dos usuários precisa criar credenciais para acessar imagens restritas. O Config Sync é compatível com os seguintes mecanismos de autenticação:

Conta de serviço do Kubernetes (k8sserviceaccount)
Conta de serviço do Google (gcpserviceaccount)
Conta de serviço padrão do Compute Engine (gcenode)

Conta de serviço do Kubernetes

Se você armazenar sua imagem OCI no Artifact Registry e seu cluster usar a Identidade da carga de trabalho do GKE ou a Identidade da carga de trabalho da frota, será possível usar k8sserviceaccount como seu tipo de autenticação na versão 1.17.2 e mais recentes. Essa opção é recomendada em vez de gcpserviceaccount devido ao processo de configuração simplificado.

Conceda o papel do IAM de Leitor do Artifact Registry (roles/artifactregistry.reader) à conta de serviço do Kubernetes com o pool de Identidade da carga de trabalho. Para mais informações sobre os papéis e permissões do Artifact Registry, consulte Configurar papéis e permissões do Artifact Registry.
- Conceda permissão a todo o projeto se as mesmas permissões se aplicarem a todos os repositórios no projeto.
```
gcloud projects add-iam-policy-binding PROJECT_ID \
      --role=roles/artifactregistry.reader \
      --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
```
- Conceda permissão específica do repositório quando quiser que as contas de serviço tenham diferentes níveis de acesso para cada repositório no projeto.
```
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
   --project=PROJECT_ID
```
Substitua:
- PROJECT_ID: ID do projeto da organização.
- FLEET_HOST_PROJECT_ID: se você estiver usando a Identidade da carga de trabalho do GKE, será igual a PROJECT_ID. Se você estiver usando a identidade da carga de trabalho da frota, esse será o ID do projeto da frota em que o cluster está registrado.
- KSA_NAME: a conta de serviço do Kubernetes do reconciliador.
  - Para repositórios raiz, se o nome RootSync for root-sync, use root-reconciler. Caso contrário, use root-reconciler-ROOT_SYNC_NAME. Se você instalar o Config Sync usando o console do Google Cloud ou a Google Cloud CLI, o Config Sync criará automaticamente um objeto RootSync chamado root-sync.
- REPOSITORY: o ID do repositório.
- LOCATION: o local regional ou multirregional do repositório.
Observação: a criação dessa vinculação de política requer a permissão iam.serviceAccounts.setIamPolicy.

Conta de serviço do Google.

Se você armazenar sua imagem OCI no Artifact Registry e seu cluster usar a Identidade da carga de trabalho do GKE ou a Identidade da carga de trabalho da frota, será possível usar gcpserviceaccount como o tipo de autenticação. A partir da versão 1.17.2, é recomendável usar k8sserviceaccount. Essa opção elimina as etapas extras da criação de uma conta de serviço do Google e a vinculação de política do IAM associada.

Crie uma conta de serviço se você ainda não tiver uma.
Conceda o papel do IAM de leitor do Artifact Registry (roles/artifactregistry.reader) à conta de serviço do Google. Para mais informações sobre os papéis e permissões do Artifact Registry, consulte Configurar papéis e permissões do Artifact Registry.
- Conceda permissão a todo o projeto se as mesmas permissões se aplicarem a todos os repositórios no projeto.
```
gcloud projects add-iam-policy-binding PROJECT_ID  \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
```
- Conceda permissão específica do repositório quando quiser que as contas de serviço tenham diferentes níveis de acesso para cada repositório no projeto.
```
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
   --project=PROJECT_ID
```

Crie uma vinculação de política do IAM entre a conta de serviço do Kubernetes e a conta de serviço do Google executando o seguinte comando:

gcloud iam service-accounts add-iam-policy-binding
  GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/iam.workloadIdentityUser \
    --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
    --project=PROJECT_ID

Substitua:

PROJECT_ID: ID do projeto da organização.
FLEET_HOST_PROJECT_ID: se você estiver usando a Identidade da carga de trabalho do GKE, será igual a PROJECT_ID. Se você estiver usando a identidade da carga de trabalho da frota, esse será o ID do projeto da frota em que o cluster está registrado.
GSA_NAME: a conta de Serviço do Google personalizada que você quer usar para se conectar ao Artifact Registry. Essa conta de serviço precisa ter o papel do IAM "Leitor do Artifact Registry" (roles/artifactregistry.reader).
KSA_NAME: a conta de serviço do Kubernetes do reconciliador.
- Para repositórios raiz, se o nome RootSync for root-sync, use root-reconciler. Caso contrário, use root-reconciler-ROOT_SYNC_NAME. Se você instalar o Config Sync usando o console do Google Cloud ou a Google Cloud CLI, o Config Sync criará automaticamente um objeto RootSync chamado root-sync.
REPOSITORY: o ID do repositório.
LOCATION: o local regional ou multirregional do repositório.

Conta de serviço padrão do Compute Engine

Se você armazenar o gráfico Helm no Artifact Registry e seu cluster for do GKE no Google Cloud com a Identidade da carga de trabalho desativada, será possível usar gcenode como tipo de autenticação. O Config Sync usa a conta de serviço padrão do Compute Engine. Conceda ao leitor de conta de serviço padrão do Compute Engine o acesso ao Artifact Registry.

Conceda à conta de serviço do Compute Engine permissão de leitura para o Artifact Registry executando o seguinte comando:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
   --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
   --role=roles/artifactregistry.reader
```
Substitua PROJECT_ID pelo ID do projeto da organização e PROJECT_NUMBER pelo número do projeto da organização.

Conceder acesso somente leitura do Config Sync ao Helm

O Config Sync precisa de acesso somente leitura ao seu repositório do Helm para ler os gráficos do Helm no repositório e instalá-los nos clusters.

No entanto, a maioria dos usuários precisa criar credenciais para acessar repositórios particulares do Helm. O Config Sync é compatível com os seguintes mecanismos de autenticação:

Token (token)
Conta de serviço do Kubernetes (k8sserviceaccount)
Conta de serviço do Google (gcpserviceaccount)
Conta de serviço padrão do Compute Engine (gcenode)

Token

Crie um Secret com um nome de usuário e uma senha do repositório Helm:

kubectl create secret generic SECRET_NAME \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
    --from-literal=password=PASSWORD

Substitua:

SECRET_NAME: o nome que você quer dar ao controlador.
USERNAME: o nome de usuário do repositório do Helm.
PASSWORD: a senha do repositório do Helm.

Quando você configurar o ConfigManagement Operator, você usará o nome do secret escolhido para spec.helm.secretRef.name.

Conta de serviço do Kubernetes

Se você armazenar o gráfico Helm no Artifact Registry e seu cluster usar a Identidade da carga de trabalho do GKE ou a Identidade da carga de trabalho da frota, será possível utilizar k8sserviceaccount como tipo de autenticação na versão 1.17.2 e mais recentes. Essa opção é recomendada em vez de gcpserviceaccount devido ao processo de configuração simplificado.

Conceda o papel do IAM de Leitor do Artifact Registry (roles/artifactregistry.reader) à conta de serviço do Kubernetes com o pool de Identidade da carga de trabalho. Para mais informações sobre os papéis e permissões do Artifact Registry, consulte Configurar papéis e permissões do Artifact Registry.
- Conceda permissão a todo o projeto se as mesmas permissões se aplicarem a todos os repositórios no projeto.
```
gcloud projects add-iam-policy-binding PROJECT_ID \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
```
- Conceda permissão específica do repositório quando quiser que as contas de serviço tenham diferentes níveis de acesso para cada repositório no projeto.
```
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
   --project=PROJECT_ID
```
Substitua:
- PROJECT_ID: ID do projeto da organização.
- FLEET_HOST_PROJECT_ID: se você estiver usando a Identidade da carga de trabalho do GKE, será igual a PROJECT_ID. Se você estiver usando a identidade da carga de trabalho da frota, esse será o ID do projeto da frota em que o cluster está registrado.
- KSA_NAME: a conta de serviço do Kubernetes do reconciliador.
  - Para repositórios raiz, se o nome RootSync for root-sync, use root-reconciler. Caso contrário, use root-reconciler-ROOT_SYNC_NAME.
- REPOSITORY: o ID do repositório.
- LOCATION: o local regional ou multirregional do repositório.

Conta de serviço do Google.

Se você armazenar o gráfico do Helm no Artifact Registry e o cluster usar Identidade da carga de trabalho do GKE ouIdentidade da carga de trabalho da frota ,gcpserviceaccount como seu tipo de autenticação. A partir da versão 1.17.2, é recomendável usar k8sserviceaccount. Essa opção elimina as etapas extras da criação de uma conta de serviço do Google e a vinculação de política do IAM associada.

Crie uma conta de serviço se você ainda não tiver uma.
Conceda o papel do IAM de leitor do Artifact Registry (roles/artifactregistry.reader) à conta de serviço do Google. Para mais informações sobre os papéis e permissões do Artifact Registry, consulte Configurar papéis e permissões do Artifact Registry.
- Conceda permissão a todo o projeto se as mesmas permissões se aplicarem a todos os repositórios no projeto.
```
gcloud projects add-iam-policy-binding PROJECT_ID  \
      --role=roles/artifactregistry.reader \
      --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
```
- Conceda permissão específica do repositório quando quiser que as contas de serviço tenham diferentes níveis de acesso para cada repositório no projeto.
```
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
   --project=PROJECT_ID
```

Crie uma vinculação de política do IAM entre a conta de serviço do Kubernetes e a conta de serviço do Google executando o seguinte comando:

gcloud iam service-accounts add-iam-policy-binding
  GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/iam.workloadIdentityUser \
    --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
    --project=PROJECT_ID

Substitua:

PROJECT_ID: ID do projeto da organização.
FLEET_HOST_PROJECT_ID: se você estiver usando a Identidade da carga de trabalho do GKE, será igual a PROJECT_ID. Se você estiver usando a identidade da carga de trabalho da frota, esse será o ID do projeto da frota em que o cluster está registrado.
GSA_NAME: a conta de Serviço do Google personalizada que você quer usar para se conectar ao Artifact Registry. Essa conta de serviço precisa ter o papel do IAM "Leitor do Artifact Registry" (roles/artifactregistry.reader).
KSA_NAME: a conta de serviço do Kubernetes do reconciliador.
- Para repositórios raiz, se o nome RootSync for root-sync, use root-reconciler. Caso contrário, use root-reconciler-ROOT_SYNC_NAME.
REPOSITORY: o ID do repositório.
LOCATION: o local regional ou multirregional do repositório.

Conta de serviço padrão do Compute Engine

Conceda à conta de serviço do Compute Engine a permissão de leitura para o Artifact Registry:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
    --role=roles/artifactregistry.reader
```
Substitua PROJECT_ID pelo ID do projeto da organização e PROJECT_NUMBER pelo número do projeto da organização.

Configurar o Config Sync

Nesta seção, você definirá as configurações do seu repositório raiz. Se você estiver sincronizando com um repositório Git, use o console do Google Cloud para orientar você no processo de instalação e automatizar algumas etapas.

Quando você instala o Config Sync usando o console do Google Cloud ou a Google Cloud CLI, o Config Sync cria automaticamente um objeto RootSync chamado root-sync. É possível usar comandos kubectl para modificar root-sync e adicionar outras configurações do Config Sync. Para saber mais, consulte Configurar o Config Sync com comandos kubectl.

Console

Instalar o Config Sync

Para instalar o Config Sync, todos os clusters precisam estar registrados em uma frota. Quando você instala o Config Sync no console do Google Cloud, a seleção de clusters individuais registra automaticamente esses clusters na sua frota.

No console do Google Cloud, acesse a página Configuração na seção Recursos.

Acessar "Configuração"

Clique em Instalar o Config Sync.
Selecione Upgrades automáticos (Visualizar) para ativar o Config Sync para fazer upgrade das versões automaticamente ou selecione Upgrades manuais para gerenciar a versão do Config Sync por conta própria. Para mais informações sobre como os upgrades automáticos funcionam, consulte Fazer upgrade do Config Sync.
Em Opções de instalação, selecione uma das seguintes opções:
- Instalar o Config Sync em toda a frota (recomendado): o Config Sync será instalado em todos os clusters na frota.
- Instale o Config Sync em clusters individuais: todos os clusters selecionados serão registrados automaticamente em uma frota. O Config Sync será instalado em todos os clusters na frota.
Se você estiver instalando o Config Sync em clusters individuais, na tabela Clusters disponíveis, selecione os clusters em que você quer instalar o Config Sync.
Clique em Instalar Config Sync. Na guia Configurações, após alguns minutos, será exibido Ativado na coluna Status dos clusters na sua frota.

Implantar um pacote

Depois de registrar os clusters, é possível implantar um pacote de uma fonte de verdade no cluster do Config Sync. É possível implantar um pacote em mais de um cluster por vez e adicionar vários pacotes a um único cluster.

Para implantar um pacote, siga estas etapas:

No console do Google Cloud, acesse o painel do Config Sync.

Acessar o painel do Config Sync
Clique em Implantar pacote.
Na tabela Selecionar clusters para implantação do pacote, selecione o cluster em que você quer implantar um pacote e clique em Continuar.
Selecione Pacote hospedado no Git ou Pacote hospedado na OCI como tipo de origem e clique em Continuar.
Na seção Package details, insira um Package name, que identifica o objeto RootSync ou RepoSync.
Na seção Origem, faça o seguinte:
- Para fontes hospedadas em um repositório Git, insira os seguintes campos:
  1. Informe um Package name, que identifica o objeto RootSync ou RepoSync.
  2. Digite o URL do repositório Git que você está usando como fonte de verdade como o URL do repositório.
  3. Opcional: atualize o campo Revisão para verificar se você não está usando o HEAD padrão.
  4. Opcional: atualize o campo Path se você não quiser sincronizar a partir do repositório raiz.
  5. Opcional: atualize o campo Ramificação se você não estiver usando a ramificação main padrão.
- Para fontes hospedadas em uma imagem OCI, insira os seguintes campos:
  1. Insira o URL da imagem OCI que você está usando como fonte de verdade como a Imagem.
  2. Insira o caminho do diretório de onde sincronizar, relativo ao diretório raiz, como o Diretório.
No campo Sync type, escolha RootSync ou RepoSync como o tipo de sincronização.

Os objetos RootSync têm escopo de cluster e o objeto RepoSync tem escopo de namespace. Para ver mais informações sobre esses objetos, consulte Campos RootSync e RepoSync.
(Opcional): expanda a seção Configurações avançadas para concluir o seguinte:
1. Selecione um Tipo de autenticação:
  
  Observação: para a OCI, só é possível selecionar a Identidade da carga de trabalho para autenticação.
  - Nenhum: não usar autenticação.
  - SSH: use um par de chaves SSH.
  - Cookiefile: use um cookiefile.
  - Token: use um token.
  - Google Cloud Repository: use uma conta de serviço do Google para acessar um repositório do Cloud Source Repositories. Selecione esta opção somente se a identidade da carga de trabalho não estiver ativada em seu cluster.
  - Identidade da carga de trabalho: use uma conta de serviço do Google para acessar um repositório do Cloud Source Repositories.
2. Insira um número em segundos para definir o Tempo de espera da sincronização, que determina quanto tempo o Config Sync espera entre a sincronização da fonte de verdade.
3. Insira um URL de proxy Git para o proxy HTTPS a ser usado ao se comunicar com a fonte da verdade.
4. Escolha Hierarquia para mudar o Formato de origem.
  
  O valor padrão Não estruturado é recomendado na maioria dos casos, porque permite organizar a fonte de verdade como você quiser.
Clique em Implantar pacote.

Você será redirecionado para a página Pacotes do Config Sync. Após alguns minutos, a mensagem Sincronizado vai aparecer na coluna Status da sincronização do cluster configurado.
Para atualizar um pacote, na guia Packages, expanda o nome do pacote que você quer editar e clique em Edit.

gcloud

Antes de continuar, registre seus clusters em uma fleet.

Ative o recurso de frota ConfigManagement:

gcloud beta container fleet config-management enable

Prepare a configuração criando um novo manifesto apply-spec.yaml ou usando um existente. Se você escolher a última opção, é possível configurar um cluster com as mesmas configurações usadas por outro.
Criar novo manifesto
Para definir o Config Sync com novas configurações para o cluster, crie um arquivo chamado apply-spec.yaml e copie o arquivo YAML a seguir nele.

É possível definir todos os campos spec.configSyncopcionais que são necessários ao criar o manifesto e depois usar comandos kubectl para a configuração. Também é possível definir apenas o campo spec.configSync.enabled como true e omitir os campos opcionais. Posteriormente, é possível usar comandos kubectl para criar outros objetos RootSync ou RepoSyncs que poderão ser gerenciados totalmente mais tarde por meio de comandos kubectl.
```
# apply-spec.yaml

applySpecVersion: 1
spec:
  upgrades: UPGRADE_SETTING
  configSync:
    # Set to true to install and enable Config Sync
    enabled: true
    # If you don't have a source of truth yet, omit the
    # following fields. You can configure them later.
    sourceType: SOURCE_TYPE
    sourceFormat: FORMAT
    syncRepo: REPO
    syncRev: REVISION
    syncBranch: BRANCH
    secretType: SECRET_TYPE
    gcpServiceAccountEmail: EMAIL
    metricsGcpServiceAccountEmail: METRICS_EMAIL
    policyDir: DIRECTORY
    preventDrift: PREVENT_DRIFT
```
Substitua:
- (Prévia) UPGRADE_SETTING: defina como auto para configurar o Config Sync para fazer upgrade automaticamente. Defina como manual para fazer upgrade manual do Config Sync por conta própria. O valor padrão é manual. Essa sinalização é compatível apenas com clusters do GKE no Google Cloud.
  
  Cuidado: não é possível desativar os upgrades automáticos definindo a sinalização de upgrades de volta para manual. Para mudar de upgrades automáticos para manuais, desinstale o Config Sync e reinstale-o.
- SOURCE_TYPE: adicione git para sincronizar de um repositório Git, oci para sincronizar de uma imagem OCI ou helm para sincronizar de um gráfico do Helm. Se nenhum valor for especificado, o padrão será git.
- 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 melhor maneira para você.
- REPO: adiciona o URL da fonte da verdade. Os URLs dos repositórios Git e Helm usam o protocolo HTTPS ou SSH. Por exemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples. Se você planeja usar o SSH como o secretType, digite o URL com o protocolo SSH. Esse campo é obrigatório e, caso você não insira um protocolo, o URL será tratado como HTTPS.
  
  Os URLs da OCI usam o seguinte formato: 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 no formato 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 não compatível fará com que os recursos gerenciados sejam removidos sem um erro.
- REVISION: a revisão Git (tag ou hash) da qual sincronizar. Esse 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 syncRev. 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.
- BRANCH: a ramificação do repositório com que sincronizar. Este campo é opcional e o padrão é master. A partir da versão 1.17.0 do Config Sync, é recomendável usar o campo syncRev para especificar um nome de ramificação para simplificar. Se os campos syncRev e syncBranch forem especificados, syncRev terá precedência sobre syncBranch.
- SECRET_TYPE: uma das seguintes opções secretTypes:
  git
  
  none: não usa autenticação.
  
  ssh: usa 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. Se você selecionar esse tipo de autenticação, precisará criar uma vinculação de política do IAM depois de concluir a configuração do Config Sync. Para mais detalhes, consulte a guia "Conta de serviço do Google" da seção Conceder acesso somente de leitura do Config Sync ao Git.
  
  gcenode: use uma conta de serviço do Google para acessar um 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.
  
  oci
  
  none: nenhuma autenticação é usada
  
  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 identidade da carga de trabalho não estiver ativada em seu cluster.
  
  gcpserviceaccount: use uma conta de serviço do Google para acessar uma imagem.
  
  helm
  
  token: usar um token.
  
  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 identidade da carga de trabalho não estiver ativada em seu cluster.
  
  gcpserviceaccount: use uma conta de serviço do Google para acessar uma imagem.
- EMAIL: se você adicionou gcpserviceaccount como secretType, adicione o endereço de e-mail da sua conta de serviço do Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com.
- METRICS_EMAIL: o e-mail da conta de serviço do Google Cloud (GSA) usada para exportar as métricas do Config Sync para o Cloud Monitoring. A GSA precisa ter o papel do IAM de Gravador de métricas do Monitoring (roles/monitoring.metricWriter). A conta de serviço do Kubernetes default no namespace config-management-monitoring precisa ser vinculada ao GSA.
- DIRECTORY: o caminho do diretório de onde sincronizar em relação à raiz do repositório Git. Todos os subdiretórios que você especificar serão incluídos e sincronizados com o cluster. O valor padrão é o diretório raiz do repositório.
- PREVENT_DRIFT: se definido como true, ativa o webhook de admissão do Config Sync para evitar desvios, rejeitando alterações conflitantes de envio para clusters ativos. A configuração padrão é false. O Config Sync sempre corrige desvios, independentemente do valor desse campo.
Para uma lista completa de campos que podem ser adicionados ao campo spec, consulte gcloud.

Observação: se você ainda não tiver uma fonte de verdade preparada, poderá ativar o Config Sync sem definir nenhuma configuração. Basta configurar spec.configSync.enabled para true e omitir todos os outros campos spec.configSync. Após preparar o repositório, edite apply-spec.yaml para adicionar as configurações.
Usar manifesto existente
Para definir o cluster com as mesmas configurações usadas por outro cluster, recupere as configurações de um cluster registrado:
```
gcloud alpha container fleet config-management fetch-for-apply \
    --membership=MEMBERSHIP_NAME \
    --project=PROJECT_ID \
    > CONFIG_YAML_PATH
```
Substitua:
- MEMBERSHIP_NAME: o nome da assinatura do cluster registrado que tem as configurações do Config Sync que você quer usar
- PROJECT_ID: ID do projeto;
- CONFIG_YAML_PATH: o caminho para o arquivo apply-spec.yaml que contém as configurações buscadas no cluster
Aplique o arquivo apply-spec.yaml. Se você estiver usando um manifesto atual, aplique o arquivo ao cluster que você quer definir com as configurações buscadas no comando anterior:
```
gcloud beta container fleet config-management apply \
    --membership=MEMBERSHIP_NAME \
    --config=CONFIG_YAML_PATH \
    --project=PROJECT_ID
```
Substitua:
- MEMBERSHIP_NAME: o nome da associação da frota que você escolheu quando registrou o cluster. O nome pode ser encontrado com gcloud container fleet memberships list.
- CONFIG_YAML_PATH: o caminho para o arquivo apply-spec.yaml.
- PROJECT_ID: o ID do projeto.

Terraform

Para cada cluster em que você quer configurar o Config Sync, aplique um bloco de recursos google_gkehub_feature_membership que contenha um bloco configmanagement e config_sync:

git

resource "google_container_cluster" "cluster" {
 name = EXISTING_CLUSTER_NAME
 location = "EXISTING_CLUSTER_LOCATION"
}

resource "google_gke_hub_membership" "membership" {
 membership_id = "MEMBERSHIP_ID"
 endpoint {
   gke_cluster {
     resource_link = "//container.googleapis.com/${google_container_cluster.cluster.id}"
   }
 }

resource "google_gke_hub_feature" "feature" {
  name = "configmanagement"
  location = "global"
  }
}

resource "google_gke_hub_feature_membership" "feature_member" {
 location = "global"
 feature = google_gke_hub_feature.feature.name
 membership = google_gke_hub_membership.membership.membership_id
 configmanagement {
   version = "VERSION"
   config_sync {
     git {
       sync_repo = "REPO"
       sync_branch = "BRANCH"
       policy_dir = "DIRECTORY"
       secret_type = "SECRET"
     }
   }
 }
}

Substitua:

EXISTING_CLUSTER_NAME: o nome do cluster atual.
EXISTING_CLUSTER_LOCATION: o local do cluster atual.
MEMBERSHIP_ID: o ID de vinculação de assinatura.
VERSION: (opcional) o número da versão do Config Sync. Precisa ser definido para a versão 1.17.0 ou mais recente. Se deixado em branco, o padrão será a versão mais recente.
REPO: o URL para o repositório que contém os arquivos de configuração.
BRANCH: a ramificação do repositório, por exemplo, main.
DIRECTORY: o caminho no repositório Git que representa o nível superior do repositório que você quer sincronizar.
SECRET: o tipo de autenticação do secret.

OCI

resource "google_container_cluster" "cluster" {
 name = EXISTING_CLUSTER_NAME
 location = "EXISTING_CLUSTER_LOCATION"
}

resource "google_gke_hub_membership" "membership" {
 membership_id = "MEMBERSHIP_ID"
 endpoint {
   gke_cluster {
     resource_link = "//container.googleapis.com/${google_container_cluster.cluster.id}"
   }
 }

resource "google_gke_hub_feature" "feature" {
  name = "configmanagement"
  location = "global"
  }
}

resource "google_gke_hub_feature_membership" "feature_member" {
 location = "global"
 feature = google_gke_hub_feature.feature.name
 membership = google_gke_hub_membership.membership.membership_id
 configmanagement {
   version = "VERSION"
   config_sync {
     oci {
       sync_repo = "REPO"
       policy_dir = "DIRECTORY"
       secret_type = "SECRET"
     }
   }
 }
}

Substitua:

EXISTING_CLUSTER_NAME: o nome do cluster atual.
EXISTING_CLUSTER_LOCATION: o local do cluster atual.
MEMBERSHIP_ID: o ID de vinculação de assinatura.
VERSION: (opcional) o número da versão do Config Sync. Se deixado em branco, o padrão será a versão mais recente.
REPO: o URL do repositório de imagens OCI que contém os arquivos de configuração.
DIRECTORY: o caminho absoluto do diretório que contém os recursos que você quer sincronizar. Deixe em branco para usar o diretório raiz.
SECRET: o tipo de autenticação do secret.

Repita esse processo para cada cluster que quiser sincronizar.

Depois de configurar o repositório raiz, é possível optar por configurar a sincronização de vários repositórios, incluindo outros repositórios raiz e repositórios de namespace. Os repositórios de namespace são úteis caso você queira um repositório que contenha configurações com escopo de namespace sincronizadas com um namespace específico nos clusters.

Configurar padrões no nível da frota

Se você tiver ativado o Google Kubernetes Engine (GKE) Enterprise, poderá ativar e configurar o Config Sync como um padrão no nível da frota para seus clusters. Isso significa que cada novo cluster do GKE no Google Cloud criado na frota terá o Config Sync ativado no cluster com as configurações especificadas. Saiba mais sobre a configuração padrão da frota em Gerenciar recursos no nível da frota.

Se você usa apenas o console do Google Cloud, é possível ativar o Config Sync por padrão nos clusters e definir a versão dele para sua frota. Se você usa o Terraform, é possível ativar o Config Sync por padrão nos clusters, definir a versão do Config Sync para sua frota e configurar a conexão com seu repositório Git ou o repositório de imagens OCI.

Para configurar os padrões da frota para o Config Sync, siga estas etapas:

Console

No console do Google Cloud, acesse a página Gerenciador de recursos.

Acessar o gerenciador de recursos
No painel Config Sync, clique em Configurar.
Revisar as configurações da frota Todos os novos clusters criados na frota herdam essas configurações.
Opcional: para mudar as configurações padrão, clique em Personalizar configurações da frota. Na caixa de diálogo exibida, execute as ações a seguir:
Selecione Upgrades automáticos (Pré-lançamento) para que as versões do Config Sync sejam atualizadas automaticamente ou selecione Upgrades manuais para gerenciar a versão do Config Sync por conta própria. Para mais informações sobre como os upgrades automáticos funcionam, consulte Fazer upgrade do Config Sync.
Se você selecionou Upgrades manuais, na lista Versão, escolha a versão do Config Sync que você quer usar.
Clique em Salvar.
Clique em Configurar.
Na caixa de diálogo Definir configurações da frota, clique em Confirmar. Se você não tiver ativado o Config Sync anteriormente, clicar em Confirmar também ativará a API anthosconfigmanagement.googleapis.com.

Terraform

Crie um diretório para os arquivos de configuração padrão da frota do Terraform. Nesse diretório, adicione um arquivo main.tf com o seguinte recurso que define as configurações do Config Sync:
git
```
terraform {
  required_providers {
    google = {
      source = "hashicorp/google"
      version = ">=5.16.0"
      }
    }
  }

provider "google" {
  project = "PROJECT_ID"
}

resource "google_gke_hub_feature" "feature" {
  name = "configmanagement"
  location = "global"
  provider = google
  fleet_default_member_config {
    configmanagement {
    version = "VERSION"
    config_sync {
    source_format = "unstructured"
      git {
        sync_repo = "REPO"
        sync_branch = "BRANCH"
        policy_dir = "DIRECTORY"
        secret_type = "SECRET"
      }
    }
    }
  }
}
```
Substitua:
- PROJECT_ID: o ID do projeto host da frota.
- VERSION: (opcional) o número da versão do Config Sync. Se deixado em branco, o padrão será a versão mais recente.
- REPO: o URL para o repositório que contém os arquivos de configuração.
- BRANCH: a ramificação do repositório, por exemplo, main.
- DIRECTORY: o caminho no repositório Git que representa o nível superior do repositório que você quer sincronizar.
- SECRET: o tipo de autenticação do secret.
Para uma lista completa de configurações compatíveis com o bloco git do Config Sync, consulte a documentação de referência do Terraform para recursos de hub do GKE.
OCI
```
terraform {
  required_providers {
    google = {
      source = "hashicorp/google"
      version = ">=5.16.0"
      }
    }
  }

provider "google" {
  project = "PROJECT_ID"
}

resource "google_gke_hub_feature" "feature" {
  name = "configmanagement"
  location = "global"
  provider = google
  fleet_default_member_config {
    configmanagement {
    version = "VERSION"
    config_sync {
    source_format = "unstructured"
      oci {
        sync_repo = "REPO"
        policy_dir = "DIRECTORY"
        secret_type = "SECRET"
      }
    }
    }
  }
}
```
Substitua:
- PROJECT_ID: o ID do projeto host da frota.
- VERSION: o número da versão do Config Sync. Precisa ser definido para a versão 1.17.0 ou mais recente. Se deixado em branco, o padrão será a versão mais recente.
- REPO: o URL para o repositório de imagens OCI que contém arquivos de configuração.
- DIRECTORY: o caminho absoluto do diretório que contém os recursos que você quer sincronizar. Deixe em branco para usar o diretório raiz.
- SECRET: o tipo de autenticação do secret.
Para uma lista completa de configurações compatíveis com o bloco oci do Config Sync, consulte a documentação de referência do Terraform para recursos de hub do GKE.
Inicialize o Terraform no diretório que você criou:
```
terraform init
```
Verifique se as alterações propostas com o Terraform correspondem ao plano esperado:
```
terraform plan
```
Crie as configurações padrão de membros da frota:
```
terraform apply
```

Se você tiver clusters que gostaria de atualizar para usar as configurações padrão do Config Sync, use o console do Google Cloud para sincronizar clusters selecionados da frota com os padrões da frota. Como alternativa, é possível configurar manualmente cada cluster com as mesmas configurações usando o Terraform ou a CLI gcloud seguindo as instruções para configurar o Config Sync. Se você já usou o Terraform para especificar os padrões da frota, use os mesmos blocos configmanagement e config_sync usados para definir os padrões e configurar os clusters escolhidos.

Para sincronizar as configurações padrão do Config Sync em toda a frota, siga estas etapas:

Acesse o Gerenciador de recursos:

Acessar o Gerenciador de recursos: Config Sync
Na tabela de clusters, selecione os clusters que você quer sincronizar com as configurações da frota.
Clique em Sincronizar com as configurações da frota.

As configurações padrão do Config Sync serão aplicadas a todos os clusters selecionados. Embora o console do Google Cloud mostre apenas um subconjunto de configurações, como a versão do Config Sync, todas as configurações da frota são sincronizadas com os clusters. Por exemplo, se você configurar o Config Sync para sincronizar com um repositório Git usando o Terraform, essa configuração será sincronizada com seus clusters, mas não será exibida no console do Google Cloud.

Verifique a instalação

Depois de instalar e configurar o Config Sync, verifique se a instalação foi concluída com êxito.

Console

Siga estas etapas:

No console do Google Cloud, acesse a página Configuração na seção Recursos.

Acessar "Configuração"

Na guia Pacotes, verifique a coluna Status da sincronização na tabela de clusters. Uma instalação bem-sucedida do Config Sync tem o status Instalado. Uma fonte de verdade configurada tem o status Sincronizado.

gcloud

Execute este comando:

gcloud beta container fleet config-management status \
    --project=PROJECT_ID

Substitua PROJECT_ID pelo ID do projeto.

Uma instalação bem-sucedida tem um status de SYNCED. A partir da versão 1.18.0 do Config Sync, a saída também mostra qual versão do Config Sync está instalada e a configuração de upgrade do Config Sync.

Se você encontrar um erro depois de executar o comando anterior, verifique se criou o secret git-creds. Se você criou o Secret, tente executar novamente o comando a seguir:

gcloud beta container fleet config-management apply

Também é possível usar o comando nomos status para verificar se o Config Sync foi instalado com sucesso. Uma instalação válida sem problemas tem o status PENDING ou SYNCED. Uma instalação inválida ou incompleta tem o status de NOT INSTALLED ou NOT CONFIGURED. A saída também inclui todos os erros informados.

Permissões e controles de acesso baseados em função (RBAC)

O Policy Controller, o Config Sync e o Config Controller incluem cargas de trabalho altamente privilegiadas. A tabela a seguir lista as permissões para essas cargas de trabalho:

Componente	Namespace	Conta de serviço	Permissões	Descrição
Operador ConfigManagement	`config-management-system`	`config-management-operator`	Administrador de clusters	O ConfigManagement Operator instala os outros componentes nesta tabela. Alguns desses componentes exigem permissões de administrador do cluster, portanto, o ConfigManagement Operator também as exige.
Config Sync	`config-management-system`			Consulte as permissões necessárias do Config Sync.

Solicitações de recursos

A seção a seguir lista as solicitações de recursos do Config Sync.

A tabela a seguir lista os requisitos de recursos do Kubernetes para componentes do Config Sync. Para mais informações, consulte Como gerenciar recursos para contêineres na documentação do Kubernetes.

Nem todos os componentes listados foram criados. As condições a seguir fazem com que cada componente seja programado:

O config-management-operator será instalado quando o Config Sync estiver ativado.
O reconciler-manager será instalado quando o Config Sync estiver ativado.
O admission-webhook é instalado quando a prevenção contra desvio está ativada.
Um reconciler é instalado para cada RootSync e RepoSync.
O otel-collector será instalado quando o Config Sync estiver ativado.

Para saber mais sobre esses componentes, consulte Arquitetura do Config Sync.

1.17

Nome da implantação	Solicitação de CPU (m) por réplica	Solicitação de memória (Mi) por réplica
`config-management-operator`	100	100
`resource-group-controller-manager`	110	300
`admission-webhook¹`	10	100
`otel-collector`	200	400
`reconciler-manager`	20	150
`reconciler` (um por RootSync e RepoSync)	Consulte a implantação do reconciliador para ver mais detalhes.

¹ O webhook de admissão tem duas réplicas. Portanto, ao calcular o total de solicitações de recursos, você precisa dobrar o valor se estiver usando o webhook de admissão. O webhook de admissão é desativado por padrão.

1.16

Nome da implantação	Solicitação de CPU (m) por réplica	Solicitação de memória (Mi) por réplica
`config-management-operator`	100	100
`resource-group-controller-manager`	110	300
`admission-webhook¹`	10	100
`otel-collector`	200	400
`reconciler-manager`	20	150
`reconciler` (um por RootSync e RepoSync)	Consulte a implantação do reconciliador para ver mais detalhes.

1.15

Nome da implantação	Solicitação de CPU (m) por réplica	Solicitação de memória (Mi) por réplica
`config-management-operator`	100	100
`resource-group-controller-manager`	110	300
`admission-webhook¹`	10	100
`otel-collector`	200	400
`reconciler-manager`	20	150
`reconciler` (um por RootSync e RepoSync)	Consulte a implantação do reconciliador para ver mais detalhes.

Implantação do reconciliador

Para cada objeto RootSync e RepoSync, o Config Sync cria uma implantação de reconciliador independente para processar a sincronização. A implantação do reconciliador consiste em vários contêineres. Para saber mais sobre esses contêineres, consulte Reconciliação de contêineres.

No Config Sync versão 1.17.0 e mais recentes, as solicitações de recursos padrão para reconciliadores são diferentes para clusters Standard e Autopilot. Todos os outros tipos de cluster usam os padrões padrão.

Clusters padrão

1.17

Nome do contêiner	Solicitação de CPU (m)	Solicitação de memória (Mi)
`reconciler`	50	200
`otel-agent`	10	100
`hydration-controller` (opcional)	10	100
`git-sync`	10	16
`gcenode-askpass-sidecar` (opcional)	10	20
`helm-sync`	75	128
`oci-sync`	25	32

1.16

Nome do contêiner	Solicitação de CPU (m)	Solicitação de memória (Mi)
`reconciler`	50	200
`otel-agent`	10	100
`hydration-controller` (opcional)	10	100
`git-sync`	10	200
`gcenode-askpass-sidecar` (opcional)	10	20
`helm-sync`	50	256
`oci-sync`	10	200

1.15

Nome do contêiner	Solicitação de CPU (m)	Solicitação de memória (Mi)
`reconciler`	50	200
`otel-agent`	10	100
`hydration-controller` (opcional)	10	100
`git-sync`	10	200
`gcenode-askpass-sidecar` (opcional)	10	20
`helm-sync`	50	256
`oci-sync`	10	200

Clusters do Autopilot

1.17

Nome do contêiner	Solicitação e limite de CPU (m)	Solicitação e limite de memória (Mi)
`reconciler`	700	512
`otel-agent`	10	64
`hydration-controller` (opcional)	200	256
`git-sync`	20	32
`gcenode-askpass-sidecar` (opcional)	50	64
`helm-sync`	150	256
`oci-sync`	50	64

1.16

Nas versões do Config Sync anteriores à 1.17.0, as solicitações de recursos são as mesmas para Standard e Autopilot.

1.15

Nas versões do Config Sync anteriores à 1.17.0, as solicitações de recursos são as mesmas para Standard e Autopilot.

Para saber como modificar as solicitações e os limites padrão de recursos, consulte Modificações de recursos.

Versões Helm e Kustomize agrupadas

O Config Sync aproveita os executáveis Helm e Kustomize para renderizar as configurações em segundo plano. A tabela a seguir fornece uma lista de versões do Config Sync compatíveis com o recurso de renderização, junto com as versões agrupadas do Helm e do Kustomize.

Versões do Config Sync	Versão do Helm	Versão do Kustomize
1.16.0 e superior	v3.11.3	v5.1.1
1.15.0 a 1.15.3	v3.11.3	v5.0.1
1.11.0 a 1.14.3	v3.6.3	v4.5.2

Para mais informações sobre como renderizar o Helm por meio do Kustomize, consulte Configurar o Kubernetes com o Kustomize. Para informações sobre como usar a API Helm, consulte Como sincronizar gráficos do Helm a partir do Artifact Registry.

A seguir

Saiba como fazer upgrade do Config Sync.
Saiba mais sobre os comandos gcloud para configurar o Config Sync.
Descubra como configurar a sincronização a partir de repositórios de namespace.
Use o comando nomos
Leia a Introdução à solução de problemas do Config Sync.
Saiba como desinstalar o Config Sync.
Consulte as permissões padrão do Config Sync.

Instalar o Config Sync

Antes de começar

Preparar o ambiente local

Requisitos de cluster

Preparar o cluster

Instalar o Config Sync

Permitir acesso ao Git

Par de chaves SSH

Cookiefile

Token

Conta de serviço do Google.

Conta de serviço padrão do Compute Engine

Conceder acesso somente leitura do Config Sync ao OCI

Conta de serviço do Kubernetes

Conta de serviço do Google.

Conta de serviço padrão do Compute Engine

Conceder acesso somente leitura do Config Sync ao Helm

Token

Conta de serviço do Kubernetes

Conta de serviço do Google.

Conta de serviço padrão do Compute Engine

Configurar o Config Sync

Console

Instalar o Config Sync

Implantar um pacote

gcloud

Criar novo manifesto

git

oci

helm

Usar manifesto existente

Terraform

git

OCI

Configurar padrões no nível da frota

Console

Terraform

git

OCI

Verifique a instalação

Console

gcloud

Permissões e controles de acesso baseados em função (RBAC)

Solicitações de recursos

1.17

1.16

1.15

Implantação do reconciliador

Clusters padrão

1.17

1.16

1.15

Clusters do Autopilot

1.17

1.16

1.15

Versões Helm e Kustomize agrupadas

A seguir