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

Nesta página, mostramos como instalar o Config Sync usando comandos kubectl.

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 Google Cloud ou 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 Config Sync, 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

Crie ou tenha acesso a um cluster do Google Kubernetes Engine que atenda aos requisitos do Config Sync.

Preparar permissões

O usuário Google Cloud que está instalando o Config Sync precisa 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ê precisar conceder ao Config Sync 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. Implantar o Config Sync
2. Conceda ao Config Sync acesso somente leitura a uma das seguintes opções:
   • Git
   • OCI
   • Helm
3. Configurar o Config Sync

Implantar o Config Sync

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

1. Faça o download da versão mais recente dos manifestos do Config Sync 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-sync.tar.gz config-sync.tar.gz
   

2. Extraia o arquivo:

   tar -xzvf config-sync.tar.gz

3. No arquivo extraído na etapa anterior, siga as instruções no arquivo README.md fornecido para editar a personalização.

4. Para atualizar a instalação do Config Sync, aplique o manifesto renderizado que você criou seguindo as instruções de README.md:

   kubectl apply -f CONFIG_SYNC_MANIFEST
   

   Substitua CONFIG_SYNC_MANIFEST pelo nome do manifesto renderizado.

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

Se o processo falhar devido a um problema com o Config Sync 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
• 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 do Config Sync 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.

Conceder acesso somente leitura do Config Sync

Se você armazenar suas configurações no Git, precisará conceder ao Config Sync acesso somente leitura ao Git. Se você armazenar as configurações como imagens OCI, será necessário conceder ao Config Sync acesso somente leitura ao OCI. Se você armazenar suas configurações no Helm, será necessário conceder acesso somente leitura do Config Sync ao Helm.

Conceder acesso somente leitura do Config Sync 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)
• App do GitHub (githubapp)

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 ou no Secure Source Manager, 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 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 consoleGoogle 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 Google Cloud nome de usuário
   • 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 motivos de segurança, não recomendamos usar um proxy HTTP.

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 criado 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 criado 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 motivos de segurança, não recomendamos usar um proxy HTTP.

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 ou no Secure Source Manager 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 tiver uma conta de serviço, crie uma.

2. Conceda os papéis corretos do IAM à conta de serviço para que ela possa acessar o repositório:

   Cloud Source Repositories

   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
     

   Secure Source Manager

   Conceda os papéis do IAM Acessador da instância do Secure Source Manager (roles/securesourcemanager.instanceAccessor) e Leitor do repositório do Secure Source Manager (roles/securesourcemanager.repoReader) à conta de serviço do Google. Para mais informações sobre os papéis e permissões do Secure Source Manager, consulte Gerenciamento de papéis do repositório.

   • 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/securesourcemanager.instanceAccessor \
       --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

     gcloud projects add-iam-policy-binding PROJECT_ID \
       --role=roles/securesourcemanager.repoReader \
       --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

   • Para conceder permissões específicas do repositório, use a interface da Web do Secure Source Manager. Para mais informações, consulte Conceder aos usuários papéis no nível do repositório.

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

4. Se você estiver usando um repositório no Secure Source Manager, use o seguinte formato ao configurar o Config Sync e adicionar o URL do repositório Git:

   https://INSTANCE_ID-PROJECT_NUMBER-git.LOCATION.sourcemanager.dev/PROJECT_ID/REPO_NAME.git
   

   Substitua:

   • INSTANCE_ID: o nome da sua instância do Secure Source Manager.
   • PROJECT_ID: o ID do projeto Google Cloud em que a instância está localizada.
   • PROJECT_NUMBER: o número do projeto Google Cloud em que a instância está localizada.
   • LOCATION: a região em que a instância está localizada.
   • REPO_NAME: o nome do repositório.

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

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.

App do GitHub

Se o repositório estiver no GitHub, use githubapp como tipo de autenticação.

Para usar um app do GitHub, siga estas etapas:

1. Siga as instruções no GitHub para provisionar um app do GitHub e conceder a ele permissão para ler seu repositório.

2. Adicione a configuração do GitHub App a um novo Secret no cluster:

   Como usar o ID do cliente

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-client-id=CLIENT_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • Substitua CLIENT_ID pelo ID do cliente do app GitHub.
   • Substitua INSTALLATION_ID pelo ID de instalação do app GitHub.
   • Substitua /path/to/GITHUB_PRIVATE_KEY pelo nome do arquivo que contém a chave privada.
   • Substitua BASE_URL pelo URL base do endpoint de API do GitHub. Isso só é necessário quando o repositório não está hospedado em www.github.com. Caso contrário, o argumento pode ser omitido e o padrão será https://api.github.com/.

   Como usar o ID do aplicativo

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-application-id=APPLICATION_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • Substitua APPLICATION_ID pelo ID do aplicativo do GitHub.
   • Substitua INSTALLATION_ID pelo ID de instalação do app GitHub.
   • Substitua /path/to/GITHUB_PRIVATE_KEY pelo nome do arquivo que contém a chave privada.
   • Substitua BASE_URL pelo URL base do endpoint de API do GitHub. Isso só é necessário quando o repositório não está hospedado em www.github.com. Caso contrário, o argumento pode ser omitido e o padrão será https://api.github.com/.

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

4. Ao configurar o Config Sync e adicionar o URL do repositório Git, use o tipo de autenticação githubapp.

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.

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

É possível usar uma conta de serviço do Kubernetes como tipo de autenticação 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.

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 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 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 Config Sync para 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. 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 Config Sync, 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 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.

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 Google Cloud ou a Google Cloud CLI. É 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 Secret.
• USERNAME: o nome de usuário do repositório do Helm.
• PASSWORD: a senha do repositório do Helm.

Ao configurar o Config Sync, você usará o nome do secret escolhido para spec.helm.secretRef.name.

Conta de serviço do Kubernetes

É possível usar uma conta de serviço do Kubernetes como tipo de autenticação 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.

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

Configurar o Config Sync

Para configurar a sincronização do repositório raiz, você precisa criar um objeto RootSync que sincronize seu repositório raiz com o 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. 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
   

3. 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 do Git (tag ou hash) ou a ramificação para sincronizar. Este campo é opcional e o valor padrão é HEAD. Ao usar um hash, ele precisa ser 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. Recomendamos 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.

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

As etapas para fazer upgrade do Config Sync dependem da versão para a qual você está fazendo upgrade e da versão de origem. A partir da versão 1.20.0, o Config Sync é fornecido como uma instalação independente sem o ConfigManagement Operator. Se você estiver fazendo upgrade de uma versão anterior à 1.20.0 para a versão 1.20.0 ou posterior, desinstale o ConfigManagement Operator antes de fazer o upgrade.

Se você estiver fazendo upgrade de uma versão sem suporte, faça um upgrade passo a passo 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.14.0, faça upgrade para a versão 1.17.0 e, depois, para a versão 1.20.0.

Desinstalar o ConfigManagement Operator

Se você estiver fazendo upgrade de uma versão anterior à 1.20.0 para a versão 1.20.0 ou mais recente, primeiro desinstale o operador do ConfigManagement antes de fazer upgrade.

Para verificar se o Config Management está instalado no cluster, execute o seguinte comando:

kubectl get configmanagement

Se a saída não estiver vazia, o Config Management estará instalado no cluster. Para desinstalar o Config Management, conclua as etapas a seguir, mas deixe o Config Sync instalado no cluster. Recomendamos usar o nomos CLI para desinstalar o operador ConfigManagement, porque ele tem uma interface mais completa e um tratamento de erros mais robusto. Use o script shell apenas se não tiver acesso ao nomos CLI.

Atenção: verifique se o Controlador de hierarquia está desativado antes de continuar.

nomos (recomendado)

1. Verifique se a CLI nomos está na versão mais recente.

2. Execute o comando a seguir para atualizar o cluster no contexto kubectl atual:

   nomos migrate --remove-configmanagement
   

script de shell

Copie o script da shell a seguir para um arquivo e execute-o para atualizar o cluster no contexto kubectl atual.

 #!/bin/bash

 set -euox pipefail

 hnc_enabled="$(kubectl get configmanagements.configmanagement.gke.io config-management -o=jsonpath="{.spec.hierarchyController.enabled}" --ignore-not-found)"

 if [[ "${hnc_enabled}" == "true" ]]; then
   echo "Hierarchy Controller is enabled on the ConfigManagement object. It must be disabled before migrating."
   echo "This can be done by unsetting the spec.hierarchyController field on ConfigManagement."
   exit 1
 fi

 kubectl delete deployment -n config-management-system config-management-operator --ignore-not-found --cascade=foreground

 if kubectl get configmanagement config-management &> /dev/null ; then
   kubectl patch configmanagement config-management --type="merge" -p '{"metadata":{"finalizers":[]}}'
   kubectl delete configmanagement config-management --cascade=orphan --ignore-not-found
 fi

 kubectl delete clusterrolebinding config-management-operator --ignore-not-found
 kubectl delete clusterrole config-management-operator --ignore-not-found
 kubectl delete serviceaccount -n config-management-system config-management-operator --ignore-not-found
 kubectl delete customresourcedefinition configmanagements.configmanagement.gke.io --ignore-not-found

Instalar a nova versão do Config Sync

Para fazer upgrade do Config Sync, siga estas etapas para cada cluster inscrito:

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

2. Extraia o arquivo:

   tar -xzvf config-sync.tar.gz

3. No arquivo extraído na etapa anterior, siga as instruções no arquivo README.md fornecido para editar a personalização.

   Observação: a edição do kustomization.yaml é necessária para algumas configurações, por exemplo, definir um nome de cluster para uso com um ClusterSelector ou incluir o arquivo admission-webhook.yaml para uso com prevenção de desvios.

4. Para atualizar a instalação do Config Sync, aplique o manifesto renderizado que você criou seguindo as instruções de README.md:

   kubectl apply -f CONFIG_SYNC_MANIFEST
   

   Substitua CONFIG_SYNC_MANIFEST pelo nome do manifesto renderizado.

5. 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. Com os manifestos usados para instalar o Config Sync, também é possível desinstalá-lo.

      kubectl delete -f CONFIG_SYNC_MANIFEST --ignore-not-found
   

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

A seguir

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