Instalar o Config Sync

Com o Config Sync, é possível gerenciar recursos do Kubernetes usando arquivos, chamados configs, que são armazenados em um ou mais repositórios Git. 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 um repositório Git ou verifique se você tem acesso a ele. 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 o repositório, consulte Adicionar configurações aos repositórios Git. O repositório selecionado se tornará seu repositório raiz.
  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 CLI do Google Cloud para configurar o Config Sync, registre seus clusters do GKE ou clusters fora do Google Cloud para uma frota agora. Se você planeja usar o console do Google Cloud, registre seus clusters ao configurar o Config Sync.

Instalar o Config Sync

Nas seções a seguir, você concede ao Config Sync acesso ao seu repositório. Depois de conceder acesso, configure a instalação do seu repositório raiz.

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.

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

Configure o Config Sync

Nesta seção, você definirá as configurações do seu repositório raiz. O Console do Google Cloud orientará você no processo de instalação e automatizará muitas das etapas. Também é possível usar a Google Cloud CLI para concluir a instalação.

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:

    Nesta página, você verá quais clusters estão registrados e configurados atualmente e permite começar a registrar novos clusters.

  2. Clique em Nova configuração.

  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 está pré-preenchido com restrições de CIS. O Config Sync sincroniza essas restrições com o cluster e O Policy Controller faz a aplicação delas.

    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.

Se você usa o Anthos ou o GKE, conclua as etapas a seguir para configurar o Config Sync com a Google Cloud CLI.

  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 seguinte arquivo YAML nele:

# apply-spec.yaml

applySpecVersion: 1
spec:
  configSync:
    # Set to true to install and enable Config Sync
    enabled: true
    # If you don't have a Git repository, omit the following fields. You
    # can configure them later.
    sourceFormat: FORMAT
    syncRepo: REPO
    syncBranch: BRANCH
    secretType: TYPE
    gcpServiceAccountEmail: EMAIL
    policyDir: DIRECTORY
    # the `preventDrift` field is supported in Anthos Config Management version 1.10.0 and later.
    preventDrift: PREVENT_DRIFT

Substitua:

  • 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 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 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.
  • BRANCH: a ramificação do repositório com que sincronizar. Este campo é opcional e o padrão é master.
  • TYPE: uma das seguintes opções secretTypes:

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

  • 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 hub 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 hub 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, você pode optar por configurar a sincronização a partir de vários repositórios, incluindo outros repositórios raiz e repositórios de namespace. 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.

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:

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

É possível ter uma configuração inválida que não é detectada imediatamente, como um Secret git-creds ausente ou inválido. Para ver as etapas de solução de problemas, consulte Objeto ConfigManagement válido, mas incorreto na página "Solução de problemas".

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

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

1.11

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

1.10

Recurso CPU (m) Memória (Mi)
Config Sync 220 m + 80 m * (número de objetos RootSync e RepoSync) 600 Mi + 210 Mi * (número de objetos RootSync e RepoSync)
Config Sync com o webhook de admissão ativado 240 m + 80 m * (número de objetos RootSync e RepoSync) 620 Mi + 210 Mi * (número de objetos RootSync e RepoSync)
Controlador de hierarquia 220 m 220 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.12

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 300 Único
monitor Padrão1 Padrão Único
resource-group-controller-manager padrão 100+ padrão 50+ Multi
admission-webhook2 20 100 Multi
otel-collector 200 400 Multi
reconciler-manager 50 200 Multi
reconciler (um por RootSync e RepoSync) padrão 80+ padrão 200+ Multi
hnc-controller-manager padrão 100+ padrão 150+ Controlador de hierarquia
gke-hc-controller-manager padrão 100+ padrão 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 o total de solicitações de recursos, você precisa dobrar o valor. Antes da versão 1.10.0 do Anthos Config Management, o webhook de admissão é ativado por padrão. A partir da versão 1.10.0 do Anthos Config Management, o webhook de admissão está desativado por padrão.

1.11

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 300 Único
monitor Padrão1 Padrão Único
resource-group-controller-manager padrão 100+ padrão 50+ Multi
admission-webhook2 20 100 Multi
otel-collector 200 400 Multi
reconciler-manager 50 200 Multi
reconciler (um por RootSync e RepoSync) padrão 80+ padrão 200+ Multi
hnc-controller-manager padrão 100+ padrão 150+ Controlador de hierarquia
gke-hc-controller-manager padrão 100+ padrão 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 o total de solicitações de recursos, você precisa dobrar o valor. Antes da versão 1.10.0 do Anthos Config Management, o webhook de admissão é ativado por padrão. A partir da versão 1.10.0 do Anthos Config Management, o webhook de admissão está desativado por padrão.

1.10

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 300 Único
monitor Padrão1 Padrão Único
resource-group-controller-manager padrão 100+ padrão 50+ Multi
admission-webhook2 20 20 Multi
otel-collector 200 400 Multi
reconciler-manager 20 120 Multi
reconciler (um por RootSync e RepoSync) padrão 80+ padrão 200+ Multi
hnc-controller-manager padrão 100+ padrão 150+ Controlador de hierarquia
gke-hc-controller-manager padrão 100+ padrão 50+ Controlador de hierarquia

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

2 O webhook de admissão tem duas réplicas. Portanto, ao calcular o total de solicitações de recursos, você precisa dobrar o valor. Antes da versão 1.10.0 do Anthos Config Management, o webhook de admissão é ativado por padrão. A partir da versão 1.10.0 do Anthos Config Management, o webhook de admissão está desativado por padrão.

A seguir