Instalar o Config Sync

Com o Config Sync, é possível gerenciar recursos do Kubernetes usando arquivos, chamados configurações, que são armazenados em uma fonte confiável. O Config Sync é compatível com os repositórios Git, imagens OCI e gráficos Helm como fontes da verdade. Nesta página, mostramos como ativar e configurar o Config Sync para que ele seja sincronizado com seu repositório raiz. O Config Sync está disponível se você usar o Anthos ou o Google Kubernetes Engine (GKE).

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

Antes de começar

Antes de instalar o Config Sync, prepare o ambiente, os clusters e os papéis, além de ativar o Anthos Config Management.

Preparar o ambiente local

Prepare o ambiente local concluindo as tarefas a seguir:

  1. Crie ou verifique se você tem acesso a uma fonte de informações. Esse é o lugar em que você adiciona as configurações que o Config Sync sincroniza. Para saber mais sobre como definir as configurações e a fonte da verdade, consulte um dos seguintes guias:
  2. Instale e inicialize a Google Cloud CLI, que fornece os comandos gcloud e nomos. Se você usa o Cloud Shell, a Google Cloud CLI já vem pré-instalada.

Requisitos de cluster

Crie ou verifique se você tem acesso a um cluster que atenda aos seguintes requisitos:

Preparar o cluster

Depois de criar um cluster adequado, siga estas etapas:

  1. Se você estiver usando o Anthos Config Management pela primeira vez, ative o Anthos Config Management.

  2. Conceda os papéis do IAM ao usuário que registra o cluster.

  3. Se você planeja usar a Google Cloud CLI para configurar o Config Sync ou usar clusters fora do Google Cloud, verifique se os clusters do GKE ou clusters fora do Google Cloud estão registradas em uma frota agora. Se você planeja usar o console do Google Cloud, é possível registrar clusters do GKE ao configurar o Config Sync.

Instalar o Config Sync

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

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

Permitir acesso ao Git

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

Se o repositório não exigir autenticação para acesso somente leitura, será possível continuar a configurar o Config Sync e usar none como o tipo de autenticação. Por exemplo, se você puder navegar no repositório usando uma interface da Web sem fazer login ou se você puder 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
  • cookiefile
  • Token
  • Conta de serviço do Google (somente Google Source Repositories)

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.

Par de chaves SSH

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

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

  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.

  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:

  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. Exclua a chave privada do disco local ou a proteja.

  5. Ao configurar o Config Sync e adicionar o URL do repositório Git, use o protocolo SSH. Se você estiver usando um repositório no Cloud Source Repositories, será preciso usar o seguinte formato ao inserir o URL:

    ssh://EMAIL@source.developers.google.com:2022/p/PROJECT_ID/r/REPO_NAME

    Substitua:

    • EMAIL: seu nome de usuário do Google Cloud;
    • PROJECT_ID: o ID do projeto do Google Cloud em que o repositório está localizado;
    • REPO_NAME: o nome do repositório.

cookiefile

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

  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.

  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.

  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, será possível conceder ao Config Sync acesso a um repositório no mesmo projeto do cluster gerenciado usando uma conta de serviço do Google.

Para usar um repositório no Cloud Source Repositories como seu repositório do Config Sync, siga estas etapas:

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

  2. Ao configurar o Config Sync, selecione o tipo de autenticação apropriado. O tipo de autenticação que você precisa escolher depende do tipo de cluster que você tem e de como ativou a Identidade da carga de trabalho.

    • Identidade da carga de trabalho ativada: use esse método se a Identidade da carga de trabalho do GKE estiver ativada ou se você estiver usando a Identidade da carga de trabalho da frota. Se você estiver usando a Identidade da carga de trabalho da frota, poderá usar esse método de autenticação para clusters do GKE e de outros clusters.

      O Config Sync usará a Identidade da carga de trabalho da frota por padrão se o cluster estiver registrado em uma frota. Verifique se a Identidade da carga de trabalho da frota está ativada nos clusters registrados. Para mais informações, consulte Registrar um cluster. Se o cluster estiver em um projeto diferente do projeto host da frota, será necessário vincular a conta de serviço do Google à conta de serviço do Kubernetes no projeto host da frota.

    • Identidade da carga de trabalho não ativada: só é possível usar o método para clusters do GKE.

    Identidade da carga de trabalho ativada

    1. Se necessário, crie uma conta de serviço. Conceda à conta de serviço acesso de leitura ao Cloud Source Repositories concedendo a ela o papel source.reader.

    2. Se você configurar o Config Sync usando o Console do Google Cloud, selecione Identidade da carga de trabalho como o Tipo de autenticação e adicione o e-mail da sua conta de serviço.

      Se você configurar o Config Sync usando a Google Cloud CLI, adicione gcpserviceaccount como secretType e adicione o e-mail da conta de serviço a gcpServiceAccountEmail.

    3. 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ê estiver usando clusters registrados em uma frota, só precisará criar a vinculação de política uma vez por frota. Todos os clusters registrados em uma frota compartilham o mesmo Pool de Identidades de cargas de trabalho. 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 \
   --role roles/iam.workloadIdentityUser \
   --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
   GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

      Substitua:

      • PROJECT_ID: se você estiver usando a Identidade da carga de trabalho do GKE, adicione a ID do projeto da sua organização.

        Se você usa a Identidade da carga de trabalho da frota, é possível utilizar duas IDs de projetos diferentes. Em serviceAccount:PROJECT_ID, adicione a ID do projeto da frota em que o cluster está registrado. Em GSA_NAME@PROJECT_ID, adicione um ID para qualquer projeto que tenha acesso de leitura ao repositório no Cloud Source Repositories.

      • KSA_NAME: a conta de serviço do Kubernetes do reconciliador. Para repositórios raiz, se o nome RootSync for root-sync, KSA_NAME será root-reconciler. Caso contrário, será root-reconciler-ROOT_SYNC_NAME.

        Para repositórios de namespace, se o nome do RepoSync for repo-sync, KSA_NAME será ns-reconciler-NAMESPACE. Caso contrário, será ns-reconciler-NAMESPACE-REPO_SYNC_NAME.

      • GSA_NAME: a conta de serviço personalizada do Google que você quer usar para se conectar ao Cloud Source Repositories. Verifique se a conta de serviço do Google selecionada tem o papel source.reader.

    Identidade da carga de trabalho não ativada

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

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

    Ao selecionar Google Cloud Repository ou gcenode, é possível usar a conta de serviço padrão do Compute Engine. Por padrão, a conta de serviço padrão do Compute Engine, PROJECT_ID-compute@developer.gserviceaccount.com, tem acesso de source.reader ao repositório para o mesmo projeto. No entanto, se o Cloud Source Repositories estiver localizado em um projeto diferente do projeto do cluster, você precisará conceder a conta de serviço padrão do Compute Engine do projeto do cluster, o source.reader no projeto do Cloud Source Repositories.

    É possível adicionar o papel source.reader com o seguinte comando:

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

    Substitua:

    • PROJECT_ID: ID do projeto da organização
    • PROJECT_NUMBER: número do projeto da organização

    Não é possível modificar os escopos de acesso depois de criar um pool de nós. No entanto, é possível criar um novo pool de nós com o escopo de acesso apropriado e usar o mesmo cluster. O escopo gke-default padrão não inclui cloud-source-repos-ro.

Conceder acesso somente leitura do Config Sync ao OCI

O Config Sync precisa de acesso somente leitura à imagem OCI armazenada no Artifact Registry ou no Container 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. Para imagens com acesso de leitura restrito, use uma conta de serviço do Google para autenticação com gcenode ou gcpserviceaccount como o tipo de autenticação.

gcenode

Se o cluster for um cluster do GKE e a Identidade da carga de trabalho não estiver ativada, use gcenode como o tipo de autenticação. O Config Sync usa a conta de serviço padrão do Compute Engine. Conceda à conta de serviço padrão do Compute Engine acesso de leitura ao Artifact Registry ou ao Container Registry.

  1. Salve o número do projeto em uma variável de ambiente executando o seguinte comando:

    export PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID \
    --format=json | jq -r .projectNumber)

    Substitua PROJECT_ID pelo ID do projeto.

  2. Conceda à conta de serviço do Compute Engine permissão de leitura para o Artifact Registry ou o Container Registry:

    Artifact Registry

    Para conceder acesso ao Artifact Registry, execute o seguinte comando:

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

    Container Registry

    Para conceder acesso ao Container Registry, execute o seguinte comando:

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

gcpserviceaccount

Se o cluster usar a Identidade da carga de trabalho do GKE ou a Identidade da carga de trabalho da frota, será possível usar gcpserviceaccount como o tipo de autenticação.

  1. Se você ainda não tiver uma conta de serviço, crie uma e conceda a ela permissão para o Artifact Registry ou o Container Registry:

    Artifact Registry

    Conceda à conta de serviço o papel do IAM de leitor do Artifact Registry (roles/artifactregistry.reader).

    Container Registry

    Conceda à conta de serviço o papel de IAM de agente de serviço (roles/containerregistry.ServiceAgent) do Container Registry.

  2. 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 \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

    Substitua:

    • PROJECT_ID: se você está usando a identidade da carga de trabalho do GKE, esse é o ID do projeto da sua organização. Se você usa a Identidade da carga de trabalho da frota, é possível utilizar dois IDs de projetos diferentes. Em serviceAccount:PROJECT_ID, adicione o ID do projeto da frota em que o cluster está registrado. Em GSA_NAME@PROJECT_ID, adicione um ID para qualquer projeto que tenha acesso de leitura ao repositório no Cloud Source Repositories.
    • KSA_NAME: a conta de serviço do Kubernetes do reconciliador.
      • Para repositórios raiz, se o nome RootSync for root-sync, adicione root-reconciler. Caso contrário, adicione root-reconciler-ROOT_SYNC_NAME.
      • Para repositórios de namespace, se o nome RepoSync for repo-sync, adicione ns-reconciler-NAMESPACE. Caso contrário, adicione ns-reconciler-NAMESPACE-REPO_SYNC_NAME.
    • GSA_NAME: a conta de serviço personalizada do Google que você quer usar para se conectar ao Artifact Registry ou ao Container Registry.
      • Para o Artifact Registry, a conta de serviço precisa ter o papel do IAM de leitor do Artifact Registry (roles/artifactregistry.reader).
      • Para o Container Registry, a conta de serviço precisa ter o papel do IAM de agente de serviço do Container Registry (roles/containerregistry.ServiceAgent).

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

  • gcpserviceaccount

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 Config Management Operator, você usará o nome do secret escolhido para spec.helm.secretRef.name.

gcenode

Se o cluster for um cluster do GKE e a Identidade da carga de trabalho não estiver ativada, use gcenode como o 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. Salve o número do projeto em uma variável de ambiente:

    export PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format='value(projectNumber)')

    Substitua PROJECT_ID pelo ID do projeto.

  2. Conceda à conta de serviço do Compute Engine a permissão de leitura para o Artifact Registry:

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

gcpserviceaccount

Se você armazenar o gráfico do Helm no Artifact Registry e o cluster usar Identidade da carga de trabalho do GKE ouIdentidade da carga de trabalho da frota ,gcpserviceaccount como seu tipo de autenticação.

  1. Se você ainda não tiver uma conta de serviço, crie uma conta de serviço e conceda a ela o papel do IAM Leitor de Artifact Registry (roles/artifactregistry.reader). 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.

  2. 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 \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

    Substitua:

    • PROJECT_ID: se você está usando a identidade da carga de trabalho do GKE, esse é o ID do projeto da sua organização. Se você usa a Identidade da carga de trabalho da frota, é possível utilizar dois IDs de projetos diferentes. Em serviceAccount:PROJECT_ID, adicione o ID do projeto da frota em que o cluster está registrado. Em GSA_NAME@PROJECT_ID, adicione um ID para qualquer projeto que tenha acesso de leitura ao repositório no Cloud Source Repositories.
    • KSA_NAME: a conta de serviço do Kubernetes do reconciliador.
      • Para repositórios raiz, se o nome RootSync for root-sync, adicione root-reconciler. Caso contrário, adicione root-reconciler-ROOT_SYNC_NAME.
      • Para repositórios de namespace, se o nome RepoSync for repo-sync, adicione ns-reconciler-NAMESPACE. Caso contrário, adicione ns-reconciler-NAMESPACE-REPO_SYNC_NAME.
    • 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).

Configurar o Config Sync

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

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

Console

Registre seus clusters

Para usar o Config Management, primeiro é preciso registrar seus clusters. O registro dos clusters permite que eles compartilhem um conjunto comum de configurações e políticas.

Para registrar seus clusters, conclua as seguintes tarefas:

  1. No console do Google Cloud:

    • Se você usa o Google Kubernetes Engine, acesse a página Configuração do GKE na seção Configuração e política.

      Acessar o Config Management

    • Se você usa o Anthos, acesse a página Configuração do Anthos na seção Configuração e política.

      Acessar o Config Management

  2. Clique em Instalar o Config Sync.
  3. Na página Selecionar clusters registrados para o Config Management, localize a tabela Clusters não registrados deste projeto e encontre o cluster que você quer registrar.

  4. Clique em Registrar ao lado do cluster que você quer registrar.

    Depois que o cluster for registrado, ele aparecerá na tabela Selecionar clusters registrados para o Config Management.

Instalar o Config Sync

Depois de registrar os clusters, é possível continuar a instalação e a configuração do Config Sync.

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

  1. Na página Selecionar clusters registrados para o Config Management, escolha os clusters que você quer configurar e clique em Avançar.

  2. Caso você queira instalar o Policy Controller, deixe a caixa de seleção Ativar Policy Controller marcada e clique em Avançar.

  3. Na lista suspensa Repositório, selecione Usar amostra do Google ou Personalizar.

    Amostra do Google

    Selecione Usar amostra do Google para utilizar o repositório de amostra do Google. Esse repositório inclui pacotes do Policy Controller.

    Para selecionar esta opção, é necessário instalar o Policy Controller e a biblioteca de modelos de restrição dele, além de ativar as restrições referenciais. Essas opções do Policy Controller estão ativadas por padrão.

    Personalizado

    Selecione Personalizar para usar seu próprio repositório Git e configure os seguintes campos:

    1. No campo URL, adicione o URL do repositório Git para usar como fonte. Digite URLs usando o protocolo HTTPS ou SSH. Por exemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples. Se você planeja usar o SSH como o tipo de autenticação, insira o URL com o protocolo SSH.

    2. Clique em Exibir opções avançadas.

    3. Na lista suspensa Tipo de autenticação, selecione uma das seguintes opções:

      • Nenhum: não usar autenticação.
      • SSH: use um par de chaves SSH.
      • Cookiefile: use um cookiefile.
      • Token: use um token.
      • Google Cloud Repository: use uma conta de serviço do Google para acessar um repositório do Cloud Source Repositories. Selecione esta opção somente se a identidade da carga de trabalho não estiver ativada em seu cluster.
      • Identidade da carga de trabalho: use uma conta de serviço do Google para acessar um repositório do Cloud Source Repositories. Só é possível selecionar a Identidade da carga de trabalho ao usar os clusters do GKE com a Identidade da carga de trabalho ativada. A integração com a Identidade da carga de trabalho de frota para outros clusters do Anthos não é compatível. Ao selecionar Identidade da carga de trabalho, você precisa adicionar o endereço de e-mail da sua conta de serviço do Google. Por exemplo, acm@PROJECT_ID.iam.gserviceaccount.com. Se você selecionar esse tipo de autenticação, também precisará criar uma vinculação de política do IAM após a configuração do Config Sync. Para mais detalhes, consulte a guia "Conta de serviço do Google" da seção Conceder ao Config Sync acesso somente leitura ao Git.

    4. Siga as instruções no Console do Google Cloud para conceder acesso somente leitura do Config Sync ao Git e clique em Continuar.

    5. Opcional: no campo ramificação, adicione a ramificação do repositório para sincronizar. O padrão é a ramificação mestre.

    6. Opcional: no campo Tag/Confirmação, adicione a revisão do Git (tag ou hash) para finalizar. O padrão é HEAD.

    7. Opcional: no campo Diretório de configuração, adicione o caminho do diretório de onde sincronizar, em relação à raiz do repositório Git. Todos os subdiretórios do diretório especificado são incluídos e sincronizados com o cluster. O valor padrão é o diretório raiz do repositório.

    8. Opcional: no campo Espera de sincronização, adicione o período em segundos entre as sincronizações consecutivas. O padrão é 15 segundos.

    9. Opcional: no campo Proxy Git, insira o URL do proxy HTTPS a ser usado na comunicação com o repositório Git. Este é um campo opcional e, se ficar em branco, não será usado nenhum proxy. O proxy só é compatível quando usando o tipo de autorização cookiefile, none ou token.

      O URL do proxy HTTPS é mostrado como texto simples no recurso raiz criado pelo Config Sync. Se o URL tiver informações confidenciais, como um nome de usuário ou senha, e você precisar ocultar as informações confidenciais, deixe o Git Proxy vazio e adicione o URL para o proxy HTTPS no mesmo secret usado para a credencial do Git. O armazenamento do proxy no secret é compatível quando o tipo de autorização é cookiefile ou token.

    10. Opcional: na lista suspensaFormato de origem, escolha não estruturado ou hierarquia. O padrão é não estruturado, e recomendamos que você selecione não estruturado, já que esse formato permite organizar suas configurações da maneira mais conveniente para você.

    11. Opcional: na lista suspensa Versão do Config Management, selecione a versão do Anthos Config Management que você quer usar. O padrão é a versão atual.

  4. Clique em Concluir para terminar a instalação. Você vai ser redirecionado para a página Anthos Config Management.

gcloud

Antes de continuar, registre seus clusters em uma fleet.

  1. Prepare a configuração criando um novo manifesto apply-spec.yaml ou usando um existente. Se você escolher a última opção, é possível configurar um cluster com as mesmas configurações usadas por outro.

Criar novo manifesto

Para definir o Config Sync com novas configurações para o cluster, crie um arquivo chamado apply-spec.yaml e copie o arquivo YAML a seguir nele.

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

# apply-spec.yaml

applySpecVersion: 1
spec:
  configSync:
    # Set to true to install and enable Config Sync
    enabled: true
    # If you don't have a source of truth yet, omit the
    # following fields. You can configure them later.
    sourceType: SOURCE_TYPE
    sourceFormat: FORMAT
    syncRepo: REPO
    syncBranch: BRANCH
    secretType: SECRET_TYPE
    gcpServiceAccountEmail: EMAIL
    policyDir: DIRECTORY
    preventDrift: PREVENT_DRIFT

Substitua:

  • SOURCE_TYPE: adicione git para sincronizar de um repositório Git, oci para sincronizar de uma imagem OCI ou helm para sincronizar de um gráfico Helm. Se nenhum valor for especificado, o padrão será git.
  • FORMAT: adicione unstructured para usar um repositório não estruturado ou hierarchy para usar um repositório hierárquico. Esses valores diferenciam maiúsculas de minúsculas. Este campo é opcional e o valor padrão é hierarchy. Recomendamos que você adicione unstructured como esse formato para organizar suas configurações da melhor maneira para você.

  • REPO: adicione o URL da fonte da verdade. Os URLs dos repositórios Git e Helm usam o protocolo HTTPS ou SSH. Por exemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples. Se você planeja usar o SSH como o secretType, digite o URL com o protocolo SSH. Esse campo é obrigatório e, caso você não insira um protocolo, o URL será tratado como HTTPS.

    Os URLs da OCI usam o seguinte formato: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Por padrão, a imagem é extraída da tag latest, mas é possível extrair imagens por TAG ou DIGEST. Especifique TAG ou DIGEST no PACKAGE_NAME:

    • Para extrair por TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
    • Para extrair por DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST

  • BRANCH: a ramificação do repositório com que sincronizar. Este campo é opcional e o padrão é master.

  • SECRET_TYPE: uma das seguintes opções secretTypes:

    git

    • none: não usa autenticação.
    • ssh: usa um par de chaves SSH.
    • cookiefile: Use um cookiefile.
    • token: usar um token.
    • gcpserviceaccount: use uma conta de serviço do Google para acessar um Cloud Source Repositories. Se você selecionar esse tipo de autenticação, precisará criar uma vinculação de política do IAM depois de concluir a configuração do Config Sync. Para mais detalhes, consulte a guia "Conta de serviço do Google" da seção Conceder acesso somente de leitura do Config Sync ao Git.
    • gcenode: use uma conta de serviço do Google para acessar um Cloud Source Repositories. Selecione esta opção somente se a identidade da carga de trabalho não estiver ativada em seu cluster.

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

    oci

    • none: não usa autenticação
    • gcenode: use a conta de serviço padrão do Compute Engine para acessar uma imagem no Artifact Registry ou no Container Registry. Selecione esta opção somente se a identidade da carga de trabalho não estiver ativada em seu cluster.
    • gcpserviceaccount: use uma conta de serviço do Google para acessar uma imagem.

    helm

    • token: usar um token.
    • gcenode: use a conta de serviço padrão do Compute Engine para acessar uma imagem no Artifact Registry ou no Container Registry. Selecione esta opção somente se a identidade da carga de trabalho não estiver ativada em seu cluster.
    • gcpserviceaccount: use uma conta de serviço do Google para acessar uma imagem.

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

  • DIRECTORY: o caminho do diretório de onde sincronizar em relação à raiz do repositório Git. Todos os subdiretórios que você especificar serão incluídos e sincronizados com o cluster. O valor padrão é o diretório raiz do repositório.

  • PREVENT_DRIFT: se definido como true, ativa o webhook de admissão do Config Sync para evitar desvios, rejeitando alterações conflitantes de envio para clusters ativos. A configuração padrão é false. O Config Sync sempre corrige desvios, independentemente do valor desse campo.

Para uma lista completa de campos que podem ser adicionados ao campo spec, consulte gcloud.

Usar manifesto existente

Para definir o cluster com as mesmas configurações usadas por outro cluster, recupere as configurações de um cluster registrado:

gcloud alpha container fleet config-management fetch-for-apply \
    --membership=MEMBERSHIP_NAME \
    --project=PROJECT_ID \
    > CONFIG_YAML_PATH

Substitua:

  • MEMBERSHIP_NAME: o nome da assinatura do cluster registrado que tem as configurações do Config Sync que você quer usar
  • PROJECT_ID: ID do projeto
  • CONFIG_YAML_PATH: o caminho para o arquivo apply-spec.yaml que contém as configurações buscadas no cluster

2. Aplique o arquivo apply-spec.yaml. Se você estiver usando um manifesto atual, aplique o arquivo ao cluster que quer configurar com as configurações buscadas no comando anterior:

  gcloud beta container fleet config-management apply \
      --membership=MEMBERSHIP_NAME \
      --config=CONFIG_YAML_PATH \
      --project=PROJECT_ID

Substitua:

  • MEMBERSHIP_NAME: o nome da assinatura escolhido ao registrar o cluster. É possível encontrar o nome com gcloud container fleet memberships list.
  • CONFIG_YAML_PATH: o caminho para o arquivo apply-spec.yaml.
  • PROJECT_ID: o ID do projeto

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

Verificar a instalação

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

Console

Siga estas etapas:

  1. No console do Google Cloud:

    • Se você usa o Google Kubernetes Engine, acesse a página Configuração do GKE na seção Configuração e política.

      Acessar o Config Management

    • Se você usa o Anthos, acesse a página Configuração do Anthos na seção Configuração e política.

      Acessar o Config Management

  2. Na tabela do cluster, veja a coluna Status da sincronização de configuração. Uma instalação bem-sucedida apresenta o status Sincronizado.

gcloud

Execute este comando:

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

Substitua PROJECT_ID pelo ID do projeto.

Uma instalação bem-sucedida tem um status de SYNCED. Se você vir um erro depois de executar o comando anterior, verifique se você criou o Secret git-creds. Se você criou o Secret, tente executar novamente o comando a seguir:

gcloud beta container fleet config-management apply

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

Fazer upgrade do Config Sync

O Config Sync é atualizado sempre que você faz upgrade do Anthos Config Management. Para saber mais, consulte Fazer upgrade do Anthos Config Management.

Solicitações de recursos

Resumo do total de solicitações de recursos

As tabelas a seguir listam a quantidade combinada de solicitações de recursos para cada versão compatível do Config Sync, dependendo dos recursos que você está usando.

1.15

Recurso CPU (m) Memória (Mi)
Config Sync 330 m + 80 m * (número de objetos RootSync e RepoSync)1 600 Mi + 210 Mi * (número de objetos RootSync e RepoSync)
Config Sync com o webhook de admissão ativado 350 m + 80 m * (número de objetos RootSync e RepoSync)1 1050 Mi + 600 Mi * (número de objetos RootSync e RepoSync)
Controlador de hierarquia 200 m 200 Mi

1 Se o tipo de origem RootSync e RepoSync estiver definido como helm, a solicitação de CPU será 120m * (número de objetos RootSync e RepoSync).

1.14

Seleção de CPU (m) Memória (Mi)
Config Sync 330 m + 80 m * (número de objetos RootSync e RepoSync)1 600 Mi + 210 Mi * (número de objetos RootSync e RepoSync)
Config Sync com o webhook de admissão ativado 350 m + 80 m * (número de objetos RootSync e RepoSync)1 1050 Mi + 600 Mi * (número de objetos RootSync e RepoSync)
Controlador de hierarquia 200 m 200 Mi

1 Se o tipo de origem RootSync e RepoSync estiver definido como helm, a solicitação de CPU será 120m * (número de objetos RootSync e RepoSync).

1.13

Seleção de CPU (m) Memória (Mi)
Config Sync 330 m + 80 m * (número de objetos RootSync e RepoSync) 850 Mi + 600 Mi * (número de objetos RootSync e RepoSync)
Config Sync com o webhook de admissão ativado 350 m + 80 m * (número de objetos RootSync e RepoSync) 1050 Mi + 600 Mi * (número de objetos RootSync e RepoSync)
Controlador de hierarquia 200 m 200 Mi

Solicitações detalhadas de recursos

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

1.15

Nome da implantação Solicitação de CPU (m) por réplica Solicitação de memória (Mi) por réplica Repositórios únicos ou múltiplos
git-importer 450 400 Única
monitor Padrão1 Padrão Única
resource-group-controller-manager 110 300 Multi
admission-webhook2 10 100 Multi
otel-collector 200 400 Multi
reconciler-manager 20 150 Multi
reconciler (um por RootSync e RepoSync) 80 + padrão3 600 + padrão Multi
hnc-controller-manager 100 150 Controlador de hierarquia
gke-hc-controller-manager 100 50 Controlador de hierarquia

1A solicitação de recurso padrão usa uma solicitação de CPU de 10 miliCPU (mCPU) e uma solicitação de memória de 10 Mi.

2 O webhook de admissão tem duas réplicas. Portanto, ao calcular as solicitações de recursos totais, dobre o valor se estiver usando o webhook de admissão. O webhook de admissão é desativado por padrão.

3 Se o tipo de origem RootSync e RepoSync estiver definido como helm, a solicitação de CPU será 120m * (número de objetos RootSync e RepoSync).

1.14

Nome da implantação Solicitação de CPU (m) por réplica Solicitação de memória (Mi) por réplica Repositórios únicos ou múltiplos
git-importer 450 400 Única
monitor Padrão1 Padrão Única
resource-group-controller-manager 110 300 Multi
admission-webhook2 10 100 Multi
otel-collector 200 400 Multi
reconciler-manager 20 150 Multi
reconciler (um por RootSync e RepoSync) 80 + padrão3 600 + padrão Multi
hnc-controller-manager 100 150 Controlador de hierarquia
gke-hc-controller-manager 100 50 Controlador de hierarquia

1A solicitação de recurso padrão usa uma solicitação de CPU de 10 miliCPU (mCPU) e uma solicitação de memória de 10 Mi.

2 O webhook de admissão tem duas réplicas. Portanto, ao calcular as solicitações de recursos totais, dobre o valor se estiver usando o webhook de admissão. O webhook de admissão é desativado por padrão.

3 Se o tipo de origem RootSync e RepoSync estiver definido como helm, a solicitação de CPU será 120m * (número de objetos RootSync e RepoSync).

1.13

Nome da implantação Solicitação de CPU (m) por réplica Solicitação de memória (Mi) por réplica Repositórios únicos ou múltiplos
git-importer 450 400 Única
monitor Padrão1 Padrão Única
resource-group-controller-manager 110 300 Multi
admission-webhook2 10 100 Multi
otel-collector 200 400 Multi
reconciler-manager 20 150 Multi
reconciler (um por RootSync e RepoSync) 80 + padrão 600 + padrão Multi
hnc-controller-manager 100 150 Controlador de hierarquia
gke-hc-controller-manager 100 50 Controlador de hierarquia

1A solicitação de recurso padrão usa uma solicitação de CPU de 10 miliCPU (mCPU) e uma solicitação de memória de 10 Mi.

2 O webhook de admissão tem duas réplicas. Portanto, ao calcular as solicitações de recursos totais, dobre o valor se estiver usando o webhook de admissão. O webhook de admissão é desativado por padrão.

A seguir