Como instalar o Config Sync

O Config Sync permite que operadores de cluster gerenciem recursos do Kubernetes usando arquivos, chamados configs, armazenados em repositórios Git. Esta página mostra como ativar e configurar o Config Sync.

O Config Sync está disponível para usuários do Anthos e do Google Kubernetes Engine (GKE).

Antes de começar

Antes de instalar o Config Sync, verifique se você preparou o ambiente, os clusters e os papéis, além de ativar o Anthos Config Management.

Como preparar o ambiente local

Prepare o ambiente local concluindo as tarefas a seguir:

  1. Crie ou tenha acesso a um repositório Git que possa conter os configs a que o Config Sync sincroniza.
  2. Instale e inicialize o SDK do Cloud, que fornece os comandos gcloud e nomos. Se você usa o Cloud Shell, o SDK do Cloud vem pré-instalado.

Requisitos de cluster

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

  • está em uma plataforma e versão compatíveis com o Anthos;
  • Usa um Kubernetes versão 1.14.x ou posterior.
  • Não é um cluster do Autopilot.
  • Tem um pool de nós que usa um tipo de máquina com pelo menos quatro vCPUs.
  • Tem a Identidade da carga de trabalho ativada. A Identidade da carga de trabalho é a maneira recomendada para acessar os serviços do Google Cloud em aplicativos sendo executados no Google Kubernetes Engine (GKE). Esse método fornece propriedades de segurança e gerenciamento aprimorados.
  • Se você quiser usar um cluster particular do GKE, precisará configurar o Cloud NAT para permitir a saída de nós particulares do GKE. Para saber como fazer essa tarefa, consulte Exemplo de configuração do GKE. Se preferir, ative o Acesso privado do Google para se conectar ao conjunto de endereços IP externos usados pelas APIs e serviços do Google.

  • Se você quiser usar a conta de serviço do Google ao conceder acesso ao Config Sync ao seu repositório Git, depois os escopos de acesso dos nós no cluster. precisa incluir o escopo somente leitura para o Cloud Source Repositories.

    É possível adicionar esse escopo incluindo cloud-source-repos-ro na lista -- scopes especificada no momento da criação do cluster ou usando o escopo cloud- platform no momento da criação do cluster. Exemplo:

    gcloud container clusters create CLUSTER_NAME --scopes=cloud-platform
    

Como 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. Registre o cluster em uma frota. A frota do seu projeto fornece uma maneira unificada de visualizar e gerenciar seus clusters e suas cargas de trabalho como parte do Anthos, incluindo clusters fora do Google Cloud. As cobranças do Anthos se aplicam apenas aos seus clusters registrados.

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

Como 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 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 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. Se todos os mecanismos estiverem disponíveis, recomendamos o uso de um par de chaves SSH. O GitHub, o Cloud Source Repositories e o Bitbucket são compatíveis com o uso de um par de chaves SSH. 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.

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.

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

    Substitua /path/to/COOKIEFILE pelo caminho e nome de arquivo adequados.

  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:

    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
  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. 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
    
  3. Ao configurar o Config Sync na seção a seguir, adicione o URL à sua configuração. Se você estiver configurando o Config Sync usando o Console do Google Cloud, adicione o valor que você copiou no campo URL. Se você estiver configurando o Config Sync usando a ferramenta de linha de comando gcloud, adicione o valor que você copiou ao campo repo do seu objeto ConfigManagement.

  4. Ao configurar o Config Sync, selecione o tipo de autenticação apropriado.

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

    Se você estiver configurando o Config Sync usando a ferramenta de linha de comando gcloud, selecione gcpserviceaccount ou gcenode como seu secretType:

    • gcpserviceaccount: se a Identidade da carga de trabalho estiver ativada no cluster, adicione gcpserviceaccount como o tipo de autenticação.

      Se necessário, crie uma conta de serviço que possa ser usada ao configurar o Config Sync. Conceda à conta de serviço acesso de leitura ao Cloud Source Repositories concedendo a ela o papel source.reader.

      Quando você seleciona gcpserviceaccount como método de autenticação, também é necessário adicionar um gcpServiceAccountEmail ao configurar o Config Sync. Além de adicionar o gcpServiceAccountEmail, você precisa criar uma vinculação de papel após configurar o Config Sync. Para informações sobre essas etapas, consulte a seção Como usar o Cloud Source Repositories com a Identidade da carga de trabalho.

    • gcenode: se a Identidade da carga de trabalho não estiver ativada no cluster, adicione gcenode para 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 que não seja o do cluster, conceda a conta de serviço padrão do Compute Engine do projeto do cluster, o source.reader no projeto do Cloud Source Repositories.

      Se necessário, é 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.

Como configurar o Config Sync

O Console do Google Cloud orientará você no processo de instalação e automatizará muitas das etapas. Os comandos do console são um pouco diferentes para os clientes do Anthos e do GKE. Clique na guia relevante para visualizar as instruções apropriadas. Também é possível usar a ferramenta de linha de comando gcloud para concluir a instalação.

Console - Anthos

Antes de continuar, certifique-se de ter registrado seus clusters em uma frota.

Se você usa o Anthos, conclua as etapas a seguir para configurar o Config Sync:

  1. No Console do Cloud, acesse a página Anthos Config Management.

    Acessar o Anthos Config Management

  2. Selecione os clusters registrados e clique em Configurar.

  3. Na seção Autenticação de repositório do Git para ACM, 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 Cloud Source Repositories. Selecione esta opção somente se a identidade da carga de trabalho não estiver ativada em seu cluster.
  4. Se você ainda não tiver feito isso, siga as instruções no Console do Google Cloud para conceder acesso somente leitura ao Config Sync.

  5. Clique em Continuar.

  6. Na seção Configurações do ACM para os clusters, faça o seguinte:

    1. No campo Versão, selecione a versão 1.7.0 ou posterior para o Anthos Config Management, que permite a sincronização de vários repositórios por padrão.
    2. Marque a caixa de seleção Ativar Config Sync.
      1. No campo URL, adicione o URL do repositório Git para usar como fonte. É possível inserir URLs usando o protocolo HTTPS ou SSH. Por exemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa o protocolo HTTPS. Se você não inserir um protocolo, o URL será tratado como um URL HTTPS. Este campo é obrigatório.
      2. Opcional: no campo ramificação, adicione a ramificação do repositório para sincronizar. O padrão é a ramificação principal (mestre).
      3. Opcional: no campo Tag/Confirmação, adicione a revisão do Git (tag ou hash) para finalizar. O padrão é HEAD.
      4. Opcional: no campo Diretório de políticas, adicione o caminho dentro do repositório no topo da hierarquia de políticas para sincronizar. O padrão é o diretório raiz do repositório.
      5. Opcional: no campo Espera de sincronização, adicione o período em segundos entre as sincronizações consecutivas. O padrão é 15 segundos.
      6. 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 ou none.
      7. Opcional: no campo Formato de origem, escolha hierarquia (padrão) ou não estruturado (recomendado). É recomendável selecionar não estruturado, pois esse formato permite organizar as configurações da maneira mais conveniente para você.
  7. Clique em Concluído. Você será redirecionado para a página Anthos Config Management. Após alguns minutos, você verá Synced na coluna de status ao lado dos clusters configurados. Se você vir Error, clique na palavra Error para mais informações.

Console: GKE

Se você usa o GKE, conclua as etapas a seguir para configurar o Config Sync:

Como registrar seus clusters

Para usar o Config Management com o GKE, primeiro é necessário registrar os 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 Cloud, acesse a página Config Management.

    Acessar o Config Management

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

  2. Para iniciar o processo de registro, clique em Configurar o gerenciamento de configuração.

  3. Para ativar a API Config Management, clique em Avançar.

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

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

Como 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. Para instalar o Config Sync, selecione os clusters que você quer configurar e selecione Próxima. Selecionar vários clusters permite aplicar as mesmas configurações a qualquer cluster que você configurar.
  2. Na página Config Sync exibida, selecione a Versão do Anthos Config Management que você quer usar. O padrão é a versão atual.
  3. Na seção Configurações, deixe a caixa de seleção Ativar Config Sync marcada.
  4. No campo URL, adicione o URL do repositório Git para usar como fonte. É possível inserir URLs usando o protocolo HTTPS ou SSH. Por exemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa o protocolo HTTPS. Se você não inserir um protocolo, o URL será tratado como um URL HTTPS.
  5. 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 Cloud Source Repositories. Selecione esta opção somente se a identidade da carga de trabalho não estiver ativada em seu cluster.
  6. Siga as instruções no Console do Google Cloud para conceder acesso somente leitura do Config Sync ao Git e clique em Continuar.

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

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

  9. Opcional: no campo Diretório de políticas, adicione o caminho dentro do repositório no topo da hierarquia de políticas para sincronizar. O padrão é o diretório raiz do repositório.

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

  11. 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 ou none.

  12. Opcional: no campo Formato de origem, escolha hierarquia (padrão) ou não estruturado (recomendado). É recomendável selecionar não estruturado porque esse formato permite organizar as configurações da maneira mais conveniente para você.

  13. Se você não quiser instalar o Policy Controller, clique em Próximo e desmarque a caixa de seleção **Enable Policy Controller.

  14. Clique em Concluído para concluir a instalação do Config Sync.

gcloud

Antes de continuar, certifique-se de ter registrado seus clusters em uma frota.

Se você usa o Anthos ou o GKE, siga as etapas a seguir para configurar o Config Sync com a ferramenta de linha de comando gcloud.

  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
    sourceFormat: FORMAT
    syncRepo: REPO
    syncBranch: BRANCH
    secretType: TYPE
    gcpServiceAccountEmail: EMAIL
    policyDir: DIRECTORY

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. É possível inserir URLs usando o protocolo HTTPS ou SSH. Por exemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa o protocolo HTTPS. Se você não inserir um protocolo, o URL será tratado como um URL HTTPS. Este campo é obrigatório.
  • BRANCH: a ramificação do repositório com que sincronizar. O padrão é a ramificação principal (mestre).
  • TYPE: uma das seguintes opções secretTypes:

    • 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 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 no repositório Git ao diretório raiz que contém a configuração que você quer sincronizar. O padrão é o diretório raiz do repositório.

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

2. Aplique o arquivo apply-spec.yaml:

  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 hub memberships list.
  • CONFIG_YAML_PATH: o caminho para o arquivo apply-spec.yaml
  • PROJECT_ID: ID do projeto

Como usar o Cloud Source Repositories com a identidade da carga de trabalho

Se a Identidade da carga de trabalho estiver ativada no cluster e você tiver usado uma conta de serviço do Google como tipo de autenticação, será necessário concluir outras etapas.

Após concluir as etapas acima, crie uma vinculação de política do IAM entre a conta de serviço do Kubernetes e a conta de serviço do Google. A conta de serviço do Kubernetes não será criada até que você configure o Config Sync pela primeira vez.

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/root-reconciler]" \
   GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

Substitua:

  • PROJECT_ID: ID do projeto da organização
  • 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.

Como verificar a instalação

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

Console - Anthos

Siga estas etapas:

  1. No Console do Cloud, acesse a página Anthos Config Management.

    Acessar o Anthos Config Management

  2. Veja a coluna Status. Uma instalação bem-sucedida tem um status de Sincronizado.

Para uma visualização detalhada do status do cluster:

  • Selecione o cluster que você quer explorar. A página Detalhes do cluster é exibida. Nesta página, é possível ver detalhes do cluster e detalhes da instalação do Config Sync.

Console: GKE

Siga estas etapas:

  1. No Console do Cloud, acesse a página Config Management.

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

Solicitações de recursos

Resumo do total de solicitações de recursos

A tabela a seguir lista a quantidade combinada de solicitações de recursos para o Config Sync, dependendo dos recursos usados.

Recurso CPU Memória
Modo padrão (vários repositórios) 710 m + 260 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
Modo de repositório único 460 m 310 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.

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 100 20 Multi
otel-collector 200 400 Multi
reconciler-manager 200 120 Multi
reconciler (um por RootSync e RepoSync) padrão 250+ 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.

2O webhook de admissão tem duas réplicas. Portanto, ao calcular o total de solicitações de recursos, você precisa dobrar o valor.

A seguir