Instalar o Config Sync manualmente usando o kubectl (não recomendado)

Nesta página, mostramos como instalar o Config Sync usando comandos kubectl. O ConfigManagement Operator é um controlador que gerencia o Config Sync em um cluster do Kubernetes. Siga estas etapas para instalar e configurar o Operator em cada cluster que você quer gerenciar usando o Config Sync.

Cuidado: os métodos de instalação usados nesta página não são recomendados porque não são compatíveis com o console do Google Cloud ou com a Google Cloud CLI.

Antes de começar

Nesta seção, descrevemos os pré-requisitos que você precisa atender antes de instalar o Config Sync usando kubectl.

Preparar o ambiente local

Antes de instalar o Operator, confira se você preparou o ambiente local realizando as seguintes tarefas:

• Criar ou ter acesso a uma fonte da verdade.

• Instale e inicialize a CLI do Google Cloud, que fornece os comandos gcloud, kubectl e nomos usados nestas instruções. Se você usa o Cloud Shell, a CLI do Google Cloud já vem instalada.

• O kubectl não é instalado por padrão pela Google Cloud CLI. Para instalar o kubectl, use o seguinte comando:

  gcloud components install kubectl
  

• Autentique-se no Google Cloud usando o comando gcloud auth login para fazer o download de componentes do Config Sync.

Prepare seus clusters

Criar ou ter acesso a um cluster da edição Google Kubernetes Engine (GKE) Enterprise que atenda aos requisitos do Config Sync.

Preparar permissões

Usuários do Google Cloud que estão instalando o Config Sync precisam de permissões do IAM para criar novos papéis no cluster. Se necessário, conceda esses papéis com os seguintes comandos:

gcloud container clusters get-credentials CLUSTER_NAME

kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole cluster-admin --user USER_ACCOUNT

Substitua:

• CLUSTER_NAME: o nome do cluster
• USER_ACCOUNT: o endereço de e-mail da sua conta do Google Cloud

Dependendo de como você configurou a Google Cloud CLI no sistema local, talvez seja necessário adicionar os campos --project e --zone.

Se você precisarpermitir que o Operator tenha acesso ao OCI usando gcpserviceaccount como tipo de autenticação, para criar uma vinculação de política, é preciso ter a permissão iam.serviceAccounts.setIamPolicy. Para consegui-la, conceda o papel de administrador da conta de serviço do IAM (roles/iam.serviceAccountAdmin). Também é possível conseguir essa permissão com papéis personalizados ou outros papéis predefinidos.

Para mais informações sobre como conceder papéis, consulte Gerenciar acesso.

Registrar um cluster

Para inscrever um cluster no Config Sync, siga estas etapas:

1. Implante o operador
2. Conceda ao operador acesso somente leitura a uma das seguintes opções:
   • Git
   • OCI
   • Helm
3. Configure o operador

Implante o operador

Depois de garantir que você atende a todos os pré-requisitos, implante o Operator fazendo o download e aplicando um manifesto YAML.

1. Faça o download da versão mais recente dos manifestos do Operator usando o comando a seguir. Para fazer o download de uma versão específica, consulte Downloads.

   gcloud storage cp gs://config-management-release/released/latest/config-management-operator.yaml config-management-operator.yaml
   

2. Aplique os manifestos:

   kubectl apply -f config-management-operator.yaml

Se o processo falhar devido a um problema com o objeto ConfigManagement que não seja devido a um erro de sintaxe YAML ou JSON, o objeto pode ser instanciado no cluster, mas pode não funcionar corretamente. Nessa situação, use o comando nomos status para verificar se há erros no objeto.

Uma instalação válida sem problemas tem o status PENDING ou SYNCED.

Uma instalação inválida tem o status NOT CONFIGURED e lista um dos seguintes erros:

• missing git-creds Secret
• missing required syncRepo field
• git-creds Secret is missing the key specified by secretType

Para resolver o problema, corrija o erro de configuração. Dependendo do tipo de erro, talvez seja necessário reaplicar o manifesto ConfigManagement ao cluster.

Se o problema for que você esqueceu de criar o Secret git-creds, o Config Sync detectará o Secret assim que ele for criado e você não precisará reaplicar a configuração.

Permitir acesso de somente leitura ao Operator

Se você armazenar suas configurações no Git, precisará conceder ao Operator acesso somente leitura ao Git. Se você armazenar as configurações como imagens OCI, será necessário conceder ao Operator acesso somente leitura a OCI. Se você armazenar suas configurações no Helm, será necessário conceder acesso somente leitura ao operador para o Helm.

Conceder ao operador acesso somente leitura 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:

1. Liste todos os repositórios:

   gcloud source repos list
   

2. No resultado, copie o URL do repositório que você quer usar. Por 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.

Aviso: proteja os arquivos criados por este comando. Eles permitem ler seu repositório.

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

1. 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.

2. 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

3. 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).

4. (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
   

5. Exclua a chave privada do disco local ou a proteja.

6. 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://[e-mail]: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

Observação: o uso de credenciais cookiefile só é compatível com o Cloud Source Repositories. Se você quiser usar o GitHub com autenticação cookiefile, use o Cloud Source Repositories para espelhar seu repositório do GitHub.

O processo para adquirir um cookiefile depende da configuração no repositório. Por 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:

1. 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.

2. 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.

1. 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.

2. 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.

3. 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 Federação de Identidade da Carga de Trabalho para GKE do GKE ou a Federação de Identidade da Carga de Trabalho para GKE da frota, é possível conceder acesso ao Config Sync a um repositório no mesmo projeto que o cluster gerenciado usando uma conta de serviço do Google.

1. Se você não tem uma conta de serviço, crie uma.

2. 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
     

3. Se você configurar o Config Sync usando o console do Google Cloud, selecione Federação de Identidade da Carga de Trabalho para GKE 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 CLI do Google Cloud, adicione gcpserviceaccount como secretType e adicione o e-mail da conta de serviço a gcpServiceAccountEmail.

4. Depois de configurar o Config Sync, crie uma Vinculação de políticas 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ê usa clusters registrados em uma frota, basta criar a vinculação de política uma vez por frota. Todos os clusters registrados em uma frota compartilham a mesma federação de identidade da carga de trabalho para o pool do GKE. Com o conceito de integridade de frota, se você adicionar a política de IAM à conta de serviço do Kubernetes em um cluster, a conta de serviço do Kubernetes do mesmo namespace em outros clusters na mesma frota também recebem 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 Federação de Identidade da Carga de Trabalho para GKE do GKE, será igual a PROJECT_ID. Se você estiver usando a Federação de Identidade da Carga de Trabalho para GKE 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. Do contrário, use root-reconciler-ROOT_SYNC_NAME. Se você instalar o Config Sync usando o console do Google Cloud ou o 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 de gerenciamento de identidade e acesso.

Observação: a criação dessa vinculação de política requer a permissão iam.serviceAccounts.setIamPolicy.

Conta de serviço padrão do Compute Engine

Se o repositório estiver no Cloud Source Repositories e o cluster for do GKE com a Federação de Identidade da Carga de Trabalho para GKE 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 o Cloud Repository do Google como o Tipo de autenticação.

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

Ao selecionar Google Cloud Repository ou gcenode, é possível usar 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:[e-mail]"

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

Conceder ao Operator acesso somente leitura a 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.

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 a imagem for pública e puder ser acessada por qualquer pessoa na Internet, você não precisará fazer a autenticação.

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ê armazena sua imagem OCI no Artifact Registry e o cluster usa Federação de Identidade da Carga de Trabalho para GKE do GKE ou Federação de Identidade da Carga de Trabalho para GKE da frota, é possível usar k8sserviceaccount como o 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.

1. Conceda o papel do IAM de leitor do Artifact Registry (roles/artifactregistry.reader) à conta de serviço do Kubernetes com o pool da Federação de Identidade da Carga de Trabalho para GKE. Para mais informações sobre os papéis e permissões do Artifact Registry, acesse Configurar papéis e permissões para o 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 Federação de Identidade da Carga de Trabalho para GKE do GKE, será igual a PROJECT_ID. Se você estiver usando a Federação de Identidade da Carga de Trabalho para GKE 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. Do contrário, use root-reconciler-ROOT_SYNC_NAME. Se você instalar o Config Sync usando o console do Google Cloud ou o 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 o cluster usar a Federação de Identidade da Carga de Trabalho para GKE do GKE ou a Federação de Identidade da Carga de Trabalho para GKE da frota, é 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.

1. Se você não tiver uma conta de serviço, crie uma.

2. Conceda o papel do IAM de leitor do Artifact Registry (roles/artifactregistry.reader) à conta de serviço do Google. Para ver mais informações sobre os papéis e permissões do Artifact Registry, consulte Configurar papéis e permissões para o 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
     

3. 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 Federação de Identidade da Carga de Trabalho para GKE do GKE, será igual a PROJECT_ID. Se você estiver usando a Federação de Identidade da Carga de Trabalho para GKE 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. Do contrário, use root-reconciler-ROOT_SYNC_NAME. Se você instalar o Config Sync usando o console do Google Cloud ou o 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 padrão do Compute Engine

Se você armazenar o gráfico Helm no Artifact Registry e o cluster for do GKE com a Federação de Identidade da Carga de Trabalho para GKE 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.

1. 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:[e-mail] \
      --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 operador de uma autoridade certificadora

No caso dos servidores configurados com certificados de uma autoridade certificadora (CA, na sigla em inglês) que ainda não é confiável, o Config Sync pode ser configurado para usar um certificado CA para verificar as conexões HTTPS com o servidor. Isso é compatível com servidores Git, Helm ou OCI. O certificado de CA precisa incluir certificados SSL completos (raiz/intermediário/folha). Se o servidor já estiver usando uma CA confiável ou se você não estiver se conectando por HTTPS, pule esta etapa e deixe caCertSecretRef não definido.

RootSync

1. Busque e salve o certificado de CA usado para emitir o certificado do seu servidor Git.

2. Para objetos RootSync, o Secret precisa ser criado no namespace config-management-system. Por exemplo:

   kubectl create ns config-management-system && 
   
   kubectl create secret generic ROOT_CA_CERT_SECRET_NAME 
   
    --namespace=config-management-system 
   
    --from-file=cert=/path/to/CA_CERT_FILE
   

3. Ao configurar o operador, defina o valor do campo caCertSecretRef.name no objeto RootSync como ROOT_CA_CERT_SECRET_NAME.

RepoSync

1. Busque e salve o certificado de CA usado para emitir o certificado do seu servidor Git.

2. Para objetos RepoSync, o Secret precisa ser criado no mesmo namespace que o RepoSync. Por exemplo:

   kubectl create ns REPO_SYNC_NAMESPACE && 
   
   kubectl create secret generic NAMESPACE_CA_CERT_SECRET_NAME 
   
    --namespace=REPO_SYNC_NAMESPACE 
   
    --from-file=cert=/path/to/CA_CERT_FILE
   

3. Ao configurar o RepoSync, defina o valor do campo caCertSecretRef.name no objeto RepoSync como NAMESPACE_CA_CERT_SECRET_NAME.

Conceder ao operador acesso somente leitura ao Git

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.

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 o repositório do Helm for público e puder ser acessado por qualquer pessoa na Internet, não será necessário autenticar.

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)

Observação :o Config Sync não oferece suporte à configuração de helm como o tipo de origem usando o console do Google Cloud ou a CLI do Google Cloud , É possível configurar o objeto RootSync ou RepoSync para sincronizar de um repositório do Helm usando a API Kubernetes ou declará-lo em outra origem. de verdade. Consulte Configuração do repositório Helm para mais informações.

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.

Ao 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 o cluster usar a Federação de Identidade da Carga de Trabalho para GKE do GKE ou a Federação de Identidade da Carga de Trabalho para GKE da frota, é possível usar k8sserviceaccount como o 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.

1. Conceda o papel do IAM de leitor do Artifact Registry (roles/artifactregistry.reader) à conta de serviço do Kubernetes com o pool da Federação de Identidade da Carga de Trabalho para GKE. Para mais informações sobre os papéis e permissões do Artifact Registry, acesse Configurar papéis e permissões para o 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 Federação de Identidade da Carga de Trabalho para GKE do GKE, será igual a PROJECT_ID. Se você estiver usando a Federação de Identidade da Carga de Trabalho para GKE 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. Do contrário, use root-reconciler-ROOT_SYNC_NAME.
   • 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 o gráfico Helm no Artifact Registry e o cluster usar a Federação de Identidade da Carga de Trabalho para GKE do GKE ou a Federação de Identidade da Carga de Trabalho para GKE da frota, é 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.

1. Se você não tiver uma conta de serviço, crie uma.

2. Conceda o papel do IAM de leitor do Artifact Registry (roles/artifactregistry.reader) à conta de serviço do Google. Para ver mais informações sobre os papéis e permissões do Artifact Registry, consulte Configurar papéis e permissões para o 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
     

3. 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 Federação de Identidade da Carga de Trabalho para GKE do GKE, será igual a PROJECT_ID. Se você estiver usando a Federação de Identidade da Carga de Trabalho para GKE 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. Do contrário, use root-reconciler-ROOT_SYNC_NAME.
• 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 padrão do Compute Engine

Se você armazenar o gráfico Helm no Artifact Registry e o cluster for do GKE com a Federação de Identidade da Carga de Trabalho para GKE 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. Talvez seja necessário conceder acesso ao escopo storage-ro para conceder permissão somente leitura para extrair imagens.

1. 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:[e-mail] \
       --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.

Configure o operador

Para configurar a sincronização a partir do repositório raiz, é preciso ativar o modo de vários repositórios no objeto ConfigManagement e criar um objeto RootSync que sincroniza o repositório raiz ao cluster. Só é possível criar um repositório raiz por cluster, e ele pode ser um repositório não estruturado ou um repositório hierárquico.

1. Se você estiver usando o webhook de admissão do Config Sync (o webhook de admissão está desativado por padrão) e instalando o Config Sync em um cluster particular, adicione uma regra de firewall para permitir a porta 10250. O webhook de admissão do Config Sync usa a porta 10250 para prevenção de deslocamento.

2. Crie um arquivo chamado config-management.yaml e copie o arquivo YAML a seguir nele:

   # config-management.yaml
   apiVersion: configmanagement.gke.io/v1
   kind: ConfigManagement
   metadata:
     name: config-management
   spec:
     # The `enableMultiRepo` field is set to true to enable RootSync and RepoSync APIs.
     enableMultiRepo: true
     preventDrift: PREVENT_DRIFT
   

   Substitua:

   • 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.

3. Aplique as alterações:

   kubectl apply -f config-management.yaml
   

4. Aguarde até que os CRDs RootSync e RepoSync estejam disponíveis:

   until kubectl get customresourcedefinitions rootsyncs.configsync.gke.io reposyncs.configsync.gke.io; do date; sleep 1; echo ""; done
   

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

   Git

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

   Substitua:

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

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

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

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

     Este campo é obrigatório.

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

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

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

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

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

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

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

   OCI

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

   Substitua:

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

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

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

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

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

     Este campo é obrigatório.

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

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

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

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

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

   Helm

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: helm
     sourceFormat: ROOT_FORMAT
     helm:
       repo: ROOT_HELM_REPOSITORY
       chart: HELM_CHART_NAME
       version: HELM_CHART_VERSION
       releaseName: HELM_RELEASE_NAME
       namespace: HELM_RELEASE_NAMESPACE
       values:
         foo:
           bar: VALUE_1
         baz:
         - qux: VALUE_2
           xyz: VALUE_3
       includeCRDs: HELM_INCLUDE_CRDS
       auth: ROOT_AUTH_TYPE
         gcpServiceAccountEmail: ROOT_EMAIL
         secretRef:
           name: ROOT_SECRET_NAME
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   Substitua:

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

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

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

     Este campo é obrigatório.

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

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

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

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

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

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

6. Aplique as alterações:

   kubectl apply -f root-sync.yaml
   

Verifique o status de sincronização do repositório raiz

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

nomos status

O resultado será semelhante a:

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

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.

Depois de concluir a configuração do repositório raiz, será possível configurar a sincronização a partir de vários repositórios. Esses repositórios são úteis se você quiser um repositório que contenha configurações com escopo de namespace sincronizadas com um namespace específico nos clusters.

Fazer upgrade do Config Sync

Observação: o upgrade de uma versão anterior à 1.10.0 remove todos os recursos de webhook de admissão do Config Sync.

Observação: se você estiver fazendo upgrade de uma versão sem suporte, faça um upgrade por etapas e com incrementos para, no máximo, três versões secundárias por vez. Por exemplo, se a versão atual do Config Sync for 1.11.0, faça upgrade para a versão 1.14.0 e, depois, para a versão 1.17.0.

Para fazer upgrade do Config Sync, execute estes comandos para cada cluster inscrito:

1. Faça o download do manifesto do Config Sync e dos comandos nomos para a nova versão.

2. Aplique o manifesto do Config Sync:

   kubectl apply -f config-management-operator.yaml
   

   Este comando atualiza a imagem do ConfigManagement Operator. O Kubernetes recupera a nova versão e reinicia o pod do Config Sync com ela. Quando o Config Sync é iniciado, ele executa um loop de reconciliação que aplica o conjunto de manifestos agrupados na nova imagem. Isso atualiza e reinicia o pod de cada componente.

3. Substitua o comando nomos em todos os clientes com a nova versão. Essa mudança garante que o comando nomos sempre consiga o status de todos os clusters registrados e valide as configurações para eles.

Desinstalar o Config Sync

Aviso: a exclusão de um objeto RootSync ou RepoSync não limpa as anotações e rótulos do Config Sync, e o webhook de admissão do Config Sync nega solicitações que tentam alterar ou excluir esses recursos se o Config Sync ainda estiver ativado no cluster. A solução alternativa é cancelar o gerenciamento ou excluir esses recursos gerenciados antes de excluir o objeto RootSync ou RepoSync correspondente.

Para desinstalar o Config Sync, conclua as etapas a seguir:

1. Um administrador central deve remover o repositório raiz:

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

   2. Exclua o objeto RootSync executando este comando:

      kubectl delete -f root-sync.yaml
      

2. Remova todos os repositórios.

3. Remova o campo spec.enableMultiRepo do arquivo config-management.yaml.

4. Aplique o arquivo config-management.yaml ao cluster.

Observação: a desativação desse recurso não afeta as configurações aplicadas anteriormente pelo Config Sync aos clusters.

Se você quiser desinstalar totalmente o Config Sync, consulte Como remover o ConfigManagement Operator.

A seguir

• Descubra como configurar a sincronização a partir de vários repositórios.