Instale o Config Sync

Com a sincronização de configuração, pode gerir recursos do Kubernetes com ficheiros de configuração armazenados numa fonte de informação fidedigna. O Config Sync suporta repositórios Git, imagens OCI e gráficos Helm como fonte de informações fidedignas. Esta página mostra-lhe como ativar e configurar a sincronização de configuração para que seja sincronizada a partir do seu repositório raiz. O Config Sync está disponível com o Google Kubernetes Engine.

Quando instala o Config Sync através da Google Cloud consola ou da CLI Google Cloud, as APIs RootSync e RepoSync são ativadas por predefinição. Isto oferece-lhe funcionalidades adicionais, como a sincronização a partir de vários repositórios e a sincronização de configurações do Kustomize e do Helm.

Antes de começar

Antes de instalar o Config Sync, prepare o seu ambiente, certifique-se de que cumpre os requisitos do cluster e conceda as funções de utilizador certas.

Prepare o seu ambiente local

Prepare o seu ambiente local concluindo as seguintes tarefas:

  1. Crie ou certifique-se de que tem acesso a uma fonte de informações fidedignas. É aqui que adiciona as configurações que o Config Sync sincroniza. Para saber como configurar as suas configurações e fonte de dados fidedigna, consulte um dos seguintes guias:
  2. Instale e inicialize a CLI do Google Cloud, que fornece os comandos gcloud e nomos. Se usar o Cloud Shell, a Google Cloud CLI é pré-instalada. Se instalou anteriormente a CLI Google Cloud, obtenha a versão mais recente executando gcloud components update.

  3. Ative a API GKE.

    Ative a API GKE

Reveja os requisitos do cluster

Antes de instalar o Config Sync no seu cluster, reveja as recomendações e os requisitos de configuração do cluster.

Prepare o cluster

Depois de criar um cluster adequado, conclua os seguintes passos:

  1. Conceda as funções de IAM necessárias ao utilizador que está a registar o cluster.

  2. Se planeia usar a CLI do Google Cloud para configurar o Config Sync ou usar clusters fora do Google Cloud, certifique-se de que os seus clusters do GKE ou clusters fora do Google Cloud estão registados numa frota agora. Se planeia usar a Google Cloud consola, pode registar clusters do GKE quando configurar o Config Sync.

Instale o Config Sync

Nas secções seguintes, concede ao Config Sync acesso a uma das seguintes fontes de verdade:

Depois de conceder acesso, pode configurar o Config Sync.

Conceda acesso ao Git

O Config Sync precisa de acesso só de leitura ao seu repositório Git para poder ler as configurações comprometidas com o repositório e aplicá-las aos seus clusters.

Se o seu repositório não exigir autenticação para acesso só de leitura, pode continuar a configurar a sincronização de configuração e usar none como tipo de autenticação. Por exemplo, se puder procurar o repositório através de uma interface Web sem iniciar sessão ou se puder usar git clone para criar um clone do repositório localmente sem fornecer credenciais ou usar credenciais guardadas, não precisa de autenticar. Neste caso, não precisa de criar um Secret.

No entanto, a maioria dos utilizadores tem de criar credenciais porque o acesso de leitura ao respetivo repositório está restrito. Se forem necessárias credenciais, estas são armazenadas no git-creds segredo em cada cluster inscrito (a menos que esteja a usar uma conta de serviço Google). O Secret tem de ter o nome git-creds porque este é um valor fixo.

A sincronização de configurações suporta os seguintes mecanismos de autenticação:

  • Par de chaves SSH (ssh)
  • Cookiefile (cookiefile)
  • Token (token)
  • Conta de serviço Google (gcpserviceaccount)
  • Conta de serviço predefinida do Compute Engine (gcenode)
  • App GitHub (githubapp)

O mecanismo que escolher depende do que o seu repositório suporta. Geralmente, recomendamos a utilização de um par de chaves SSH. O GitHub e o Bitbucket suportam a utilização de um par de chaves SSH. No entanto, se estiver a usar um repositório nos Cloud Source Repositories ou no Secure Source Manager, recomendamos que use uma conta de serviço Google em vez disso, uma vez que o processo é mais simples. Se a sua organização alojar o repositório e não souber que métodos de autenticação são suportados, contacte o seu administrador.

Para usar um repositório no Cloud Source Repositories como o seu repositório do Config Sync, conclua os seguintes passos para obter o URL do Cloud Source Repositories:

  1. Apresentar todos os repositórios:

    gcloud source repos list

  2. Na saída, copie o URL do repositório que quer usar. Por exemplo:

    REPO_NAME  PROJECT_ID  URL
my-repo    my-project  https://source.developers.google.com/p/my-project/r/my-repo-csr

    Tem de usar este URL quando configurar o Config Sync na secção seguinte. Se configurar o Config Sync através da Google Cloud consola, adiciona o URL no campo URL. Se configurar o Config Sync através da Google Cloud CLI, adiciona o URL ao campo syncRepo do ficheiro de configuração.

Par de chaves SSH

Um par de chaves SSH consiste em dois ficheiros: uma chave pública e uma chave privada. Normalmente, a chave pública tem uma extensão .pub.

Para usar um par de chaves SSH, conclua os seguintes passos:

  1. Crie um par de chaves SSH para permitir que o Config Sync se autentique no seu repositório Git. Este passo é necessário se tiver de fazer a autenticação no repositório para o clonar ou ler a partir dele. Ignore este passo se um administrador de segurança lhe fornecer um par de chaves. Pode usar um único par de chaves para todos os clusters ou um par de chaves por cluster, consoante os seus requisitos de segurança e conformidade.

    O comando seguinte cria uma chave RSA de 4096 bits. Não recomendamos valores inferiores:

    ssh-keygen -t rsa -b 4096 \
-C "GIT_REPOSITORY_USERNAME" \
-N '' \
-f /path/to/KEYPAIR_FILENAME

    Substitua o seguinte:

    • GIT_REPOSITORY_USERNAME: o nome de utilizador que quer que o Config Sync use para autenticar no repositório
    • /path/to/KEYPAIR_FILENAME: um caminho para o par de chaves

    Se estiver a usar um anfitrião de repositório Git de terceiros, como o GitHub, ou quiser usar uma conta de serviço com o Cloud Source Repositories, recomendamos que use uma conta separada.

  2. Configure o seu repositório para reconhecer a chave pública recém-criada. Consulte a documentação do seu fornecedor de alojamento Git. Para sua conveniência, incluímos instruções para alguns fornecedores de alojamento Git populares:

  3. Adicione a chave privada a um novo segredo 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 (a que não tem o sufixo .pub).

  4. (Recomendado) Para configurar a verificação de anfitriões conhecidos através da autenticação SSH, pode adicionar a chave de anfitriões conhecidos ao campo data.known_hosts no segredo git_creds. Para desativar a verificação known_hosts, pode remover o campo known_hosts do segredo. Para adicionar a chave de anfitriões conhecidos, execute o seguinte comando:

    kubectl edit secret git-creds \
 --namespace=config-management-system

    Em seguida, em data, adicione a entrada de anfitriões conhecidos:

    known_hosts: KNOWN_HOSTS_KEY

  5. Elimine a chave privada do disco local ou proteja-a de outra forma.

  6. Quando configurar o Config Sync e adicionar o URL do seu repositório Git, use o protocolo SSH. Se estiver a usar um repositório nos Cloud Source Repositories, tem de usar o seguinte formato quando introduzir o URL:

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

    Substitua o seguinte:

    • EMAIL: o seu Google Cloud nome de utilizador
    • PROJECT_ID: o ID do Google Cloud projeto onde o repositório está localizado
    • REPO_NAME: o nome do repositório

Cookiefile

O processo de aquisição de um cookiefile depende da configuração do seu repositório. Para ver um exemplo, consulte o artigo Gere credenciais estáticas na documentação dos Cloud Source Repositories. Normalmente, as credenciais são armazenadas no ficheiro .gitcookies no seu diretório inicial ou podem ser-lhe fornecidas por um administrador de segurança.

Para usar um cookiefile, conclua os seguintes passos:

  1. Depois de criar e obter o cookiefile, adicione-o a um novo segredo no cluster.

    Se não usar um proxy HTTPS, crie o segredo 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 precisar de usar um proxy HTTPS, adicione-o ao segredo juntamente com cookiefile executando 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 \
 --from-literal=https_proxy=HTTPS_PROXY_URL

    Substitua o seguinte:

    • /path/to/COOKIEFILE: o caminho e o nome do ficheiro adequados
    • HTTPS_PROXY_URL: o URL do proxy HTTPS que usa quando comunica com o repositório Git

  2. Proteja o conteúdo da cookiefile se ainda precisar dele localmente. Caso contrário, elimine-o.

Símbolo

Se a sua organização não permitir a utilização de chaves SSH, pode preferir utilizar um token. Com a sincronização de configuração, pode usar tokens de acesso pessoal (PATs) do GitHub, PATs ou chaves de implementação do GitLab ou a palavra-passe da app do Bitbucket como token.

Para criar um segredo com o seu token, conclua os seguintes passos:

  1. Crie um token através do GitHub, GitLab ou Bitbucket:

  2. Depois de criar e obter o token, adicione-o a um novo segredo no cluster.

    Se não usar um proxy HTTPS, crie o segredo 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 o seguinte:

    • USERNAME: o nome de utilizador que quer usar.
    • TOKEN: o token que criou no passo anterior.

    Se precisar de usar um proxy HTTPS, adicione-o ao segredo juntamente com username e token executando 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 \
 --from-literal=https_proxy=HTTPS_PROXY_URL

    Substitua o seguinte:

    • USERNAME: o nome de utilizador que quer usar.
    • TOKEN: o token que criou no passo anterior.
    • HTTPS_PROXY_URL: o URL do proxy HTTPS que usa quando comunica com o repositório Git.

  3. Proteja o token se ainda precisar dele localmente. Caso contrário, elimine-o.

Conta de serviço Google

Se o seu repositório estiver no Cloud Source Repositories ou no Secure Source Manager, e o seu cluster usar a Federação do Workload Identity do GKE para o GKE ou a Federação do Workload Identity da frota para o GKE, pode conceder ao Config Sync acesso a um repositório no mesmo projeto que o seu cluster gerido através de uma conta de serviço Google.

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

  2. Conceda as funções IAM corretas à conta de serviço para que possa aceder ao repositório:

    Cloud Source Repositories

    Conceda a função de leitor do Cloud Source Repositories (roles/source.reader) do IAM à conta de serviço da Google. Para mais informações sobre as funções e as autorizações dos Cloud Source Repositories, consulte o artigo Conceda autorizações para ver repositórios.

    • Conceda autorização ao nível do projeto se as mesmas autorizações se aplicarem a todos os repositórios no projeto.

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

    • Conceda autorização específica do repositório quando quiser que as contas de serviço tenham diferentes níveis de acesso para cada repositório no seu projeto.

      gcloud source repos set-iam-policy REPOSITORY POLICY_FILE --project=PROJECT_ID

    Secure Source Manager

    Conceda as funções do IAM Secure Source Manager Instance Accessor (roles/securesourcemanager.instanceAccessor) e Secure Source Manager Repo Reader (roles/securesourcemanager.repoReader) à conta de serviço Google. Para mais informações sobre as funções e as autorizações do Secure Source Manager, consulte Gestão de funções do repositório.

    • Conceda autorização ao nível do projeto se as mesmas autorizações se aplicarem a todos os repositórios no projeto.

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

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

    • Para conceder autorizações específicas do repositório, pode usar a interface Web do Secure Source Manager para o repositório. Para mais informações, consulte o artigo Conceda funções ao nível do repositório aos utilizadores.

  3. Se configurar a sincronização de configuração através da Google Cloud consola, selecione Workload Identity Federation para GKE como o tipo de autenticação e, em seguida, adicione o email da sua conta de serviço.

    Se configurar o Config Sync através da CLI do Google Cloud, adicione gcpserviceaccount como secretType e, de seguida, adicione o email da conta de serviço a gcpServiceAccountEmail.

  4. Se estiver a usar um repositório no Secure Source Manager, tem de usar o seguinte formato quando configurar o Config Sync e adicionar o URL do seu repositório Git:

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

    Substitua o seguinte:

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

  5. Depois de configurar o Config Sync, crie uma associação de políticas de IAM entre a conta de serviço do Kubernetes e a conta de serviço Google. A conta de serviço do Kubernetes não é criada até configurar o Config Sync pela primeira vez.

    Se estiver a usar clusters registados numa frota, só tem de criar a associação de políticas uma vez por frota. Todos os clusters registados numa frota partilham a mesma federação de identidade da carga de trabalho para o GKEpool. Com o conceito de igualdade da frota, se adicionar a política de IAM à sua conta de serviço do Kubernetes num cluster, a conta de serviço do Kubernetes do mesmo espaço de nomes noutros clusters na mesma frota também recebe a mesma política de IAM.

    Esta associação permite que a conta de serviço do Kubernetes do Config Sync atue como a conta de serviço Google:

    gcloud iam service-accounts add-iam-policy-binding \
    GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/iam.workloadIdentityUser \
    --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
    --project=PROJECT_ID

Substitua o seguinte:

  • PROJECT_ID: o ID do projeto da organização.
  • FLEET_HOST_PROJECT_ID: se estiver a usar a Workload Identity Federation do GKE para o GKE, é o mesmo que PROJECT_ID. Se estiver a usar a Workload Identity Federation para o GKE, este é o ID do projeto da frota no qual o seu cluster está registado.
  • GSA_NAME: a conta de serviço Google personalizada que quer usar para estabelecer ligação ao Artifact Registry. A conta de serviço tem de ter a função de IAM Leitor do Artifact Registry (roles/artifactregistry.reader).
  • KSA_NAME: a conta de serviço do Kubernetes para o reconciliador.
    • Para repositórios raiz, se o nome RootSync for root-sync, use root-reconciler. Caso contrário, use root-reconciler-ROOT_SYNC_NAME. Se instalar o Config Sync através da Google Cloud consola ou da CLI do Google Cloud, o Config Sync cria automaticamente um objeto RootSync denominado root-sync.
  • REPOSITORY: o nome do repositório.
  • POLICY_FILE: o ficheiro JSON ou YAML com a política de gestão de identidades e acessos.

Conta de serviço predefinida do Compute Engine

Se o seu repositório estiver no Cloud Source Repositories, e o seu cluster for o GKE com a Workload Identity Federation para o GKE desativada, pode usar gcenode como tipo de autenticação.

Se configurar a sincronização de configuração através da Google Cloud consola, selecione repositório do Google Cloud como o tipo de autenticação.

Se configurar o Config Sync através da Google Cloud CLI, adicione gcenode como secretType.

Se selecionar Repositório do Google Cloud ou gcenode, pode usar a conta de serviço predefinida do Compute Engine. Tem de conceder a função de IAM Leitor dos repositórios de origem da nuvem (roles/source.reader) à conta de serviço predefinida do Compute Engine. Para mais informações sobre as funções e as autorizações dos Cloud Source Repositories, consulte o artigo Conceda autorizações para ver repositórios.

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

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

App GitHub

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

Para usar uma app GitHub, conclua os seguintes passos:

  1. Siga as instruções no GitHub para aprovisionar uma app GitHub e conceder-lhe autorização para ler a partir do seu repositório.

  2. Adicione a configuração da app GitHub a um novo segredo no cluster:

    Usar o ID de cliente 

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
  --namespace=config-management-system \
  --from-literal=github-app-client-id=CLIENT_ID \
  --from-literal=github-app-installation-id=INSTALLATION_ID \
  --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
  --from-literal=github-app-base-url=BASE_URL
    • Substitua CLIENT_ID pelo ID de cliente da app GitHub.
    • Substitua INSTALLATION_ID pelo ID de instalação da app GitHub.
    • Substitua /path/to/GITHUB_PRIVATE_KEY pelo nome do ficheiro que contém a chave privada.
    • Substitua BASE_URL pelo URL base do ponto final da API GitHub. Isto só é necessário quando o repositório não está alojado em www.github.com. Caso contrário, o argumento pode ser omitido e é predefinido como https://api.github.com/.

    Usar o ID da aplicação 

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
  --namespace=config-management-system \
  --from-literal=github-app-application-id=APPLICATION_ID \
  --from-literal=github-app-installation-id=INSTALLATION_ID \
  --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
  --from-literal=github-app-base-url=BASE_URL
    • Substitua APPLICATION_ID pelo ID da aplicação para a app GitHub.
    • Substitua INSTALLATION_ID pelo ID de instalação da app GitHub.
    • Substitua /path/to/GITHUB_PRIVATE_KEY pelo nome do ficheiro que contém a chave privada.
    • Substitua BASE_URL pelo URL base do ponto final da API GitHub. Isto só é necessário quando o repositório não está alojado em www.github.com. Caso contrário, o argumento pode ser omitido e é predefinido como https://api.github.com/.

  3. Elimine a chave privada do disco local ou proteja-a de outra forma.

  4. Quando configurar a sincronização de configuração e adicionar o URL do seu repositório Git, use o tipo de autenticação githubapp.

Conceda acesso só de leitura do Config Sync ao OCI

O Config Sync precisa de acesso só de leitura à sua imagem OCI armazenada no Artifact Registry para poder ler as configurações incluídas na imagem e aplicá-las aos seus clusters.

Se a sua imagem não exigir autenticação para acesso só de leitura, pode continuar a configurar a sincronização de configuração e usar none como tipo de autenticação. Por exemplo, se a sua imagem for pública e qualquer pessoa na Internet puder aceder à mesma, não precisa de autenticar.

No entanto, a maioria dos utilizadores tem de criar credenciais para aceder a imagens restritas. A sincronização de configurações suporta os seguintes mecanismos de autenticação:

  • Conta de serviço do Kubernetes (k8sserviceaccount)
  • Conta de serviço Google (gcpserviceaccount)

  • Conta de serviço predefinida do Compute Engine (gcenode)

Conta de serviço do Kubernetes

Pode usar uma conta de serviço do Kubernetes como tipo de autenticação se armazenar a sua imagem OCI no Artifact Registry e o seu cluster usar a federação de identidades da carga de trabalho do GKE para o GKE ou a federação de identidades da carga de trabalho da frota para o GKE.

  1. Conceda a função de IAM Artifact Registry Reader (roles/artifactregistry.reader) à conta de serviço do Kubernetes com a federação de identidades da carga de trabalho para o pool do GKE. Para mais informações sobre as funções e as autorizações do Artifact Registry, consulte o artigo Configure funções e autorizações para o Artifact Registry.

    • Conceda autorização ao nível do projeto se as mesmas autorizações se aplicarem a todos os repositórios no projeto.

      gcloud projects add-iam-policy-binding PROJECT_ID \
      --role=roles/artifactregistry.reader \
      --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"

    • Conceda autorização específica do repositório quando quiser que as contas de serviço tenham diferentes níveis de acesso para cada repositório no seu projeto.

      gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
   --project=PROJECT_ID

    Substitua o seguinte:

    • PROJECT_ID: o ID do projeto da organização.
    • FLEET_HOST_PROJECT_ID: se estiver a usar a Workload Identity Federation do GKE para o GKE, é o mesmo que PROJECT_ID. Se estiver a usar a Workload Identity Federation para o GKE, este é o ID do projeto da frota no qual o seu cluster está registado.
    • KSA_NAME: a conta de serviço do Kubernetes para o reconciliador.
      • Para repositórios raiz, se o nome RootSync for root-sync, use root-reconciler. Caso contrário, use root-reconciler-ROOT_SYNC_NAME. Se instalar o Config Sync através da Google Cloud consola ou da CLI do Google Cloud, o Config Sync cria automaticamente um objeto RootSync denominado root-sync.
    • REPOSITORY: o ID do repositório.
    • LOCATION: a localização regional ou multirregional do repositório.

Conta de serviço predefinida do Compute Engine

Se armazenar o seu gráfico Helm no Artifact Registry e o seu cluster for GKE com a Workload Identity Federation para GKE desativada, pode usar gcenode como o seu tipo de autenticação. O Config Sync usa a conta de serviço predefinida do Compute Engine. Tem de conceder à sua conta de serviço predefinida do Compute Engine acesso de leitor ao Artifact Registry.

  1. Conceda à conta de serviço do Compute Engine autorização de leitura ao Artifact Registry executando o seguinte comando:

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

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

Conceda acesso só de leitura da Config Sync ao Helm

O Config Sync precisa de acesso só de leitura ao seu repositório Helm para poder ler os gráficos Helm no seu repositório e instalá-los nos seus clusters.

Se o seu repositório não exigir autenticação para acesso só de leitura, pode continuar a configurar a sincronização de configuração e usar none como tipo de autenticação. Por exemplo, se o seu repositório Helm for público e qualquer pessoa na Internet puder aceder ao mesmo, não precisa de autenticar.

No entanto, a maioria dos utilizadores tem de criar credenciais para aceder a repositórios Helm privados. A sincronização de configurações suporta os seguintes mecanismos de autenticação:

  • Token (token)
  • Conta de serviço do Kubernetes (k8sserviceaccount)
  • Conta de serviço Google (gcpserviceaccount)
  • Conta de serviço predefinida do Compute Engine (gcenode)

Símbolo

Crie um Secret com um nome de utilizador e uma palavra-passe do repositório Helm:

kubectl create secret generic SECRET_NAME \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
    --from-literal=password=PASSWORD

Substitua o seguinte:

  • SECRET_NAME: o nome que quer dar ao seu segredo.
  • USERNAME: o nome de utilizador do repositório Helm.
  • PASSWORD: a palavra-passe do repositório Helm.

Quando configurar a sincronização de configuração, vai usar o nome do segredo que escolheu para spec.helm.secretRef.name.

Conta de serviço do Kubernetes

Pode usar uma conta de serviço do Kubernetes como tipo de autenticação se armazenar o seu gráfico Helm no Artifact Registry e o seu cluster usar a federação de identidades da carga de trabalho do GKE para o GKE ou a federação de identidades da carga de trabalho da frota para o GKE.

  1. Conceda a função de IAM Artifact Registry Reader (roles/artifactregistry.reader) à conta de serviço do Kubernetes com a federação de identidades da carga de trabalho para o pool do GKE. Para mais informações sobre as funções e as autorizações do Artifact Registry, consulte o artigo Configure funções e autorizações para o Artifact Registry.

    • Conceda autorização ao nível do projeto se as mesmas autorizações se aplicarem a todos os repositórios no projeto.

      gcloud projects add-iam-policy-binding PROJECT_ID \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"

    • Conceda autorização específica do repositório quando quiser que as contas de serviço tenham diferentes níveis de acesso para cada repositório no seu projeto.

      gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
   --project=PROJECT_ID

    Substitua o seguinte:

    • PROJECT_ID: o ID do projeto da organização.
    • FLEET_HOST_PROJECT_ID: se estiver a usar a Workload Identity Federation do GKE para o GKE, é o mesmo que PROJECT_ID. Se estiver a usar a Workload Identity Federation para o GKE, este é o ID do projeto da frota no qual o seu cluster está registado.
    • KSA_NAME: a conta de serviço do Kubernetes para o reconciliador.
      • Para repositórios raiz, se o nome RootSync for root-sync, use root-reconciler. Caso contrário, use root-reconciler-ROOT_SYNC_NAME.
    • REPOSITORY: o ID do repositório.
    • LOCATION: a localização regional ou multirregional do repositório.

Conta de serviço predefinida do Compute Engine

Se armazenar o seu gráfico Helm no Artifact Registry e o seu cluster for GKE com a Workload Identity Federation para GKE desativada, pode usar gcenode como o seu tipo de autenticação. O Config Sync usa a conta de serviço predefinida do Compute Engine. Tem de conceder à sua conta de serviço predefinida do Compute Engine acesso de leitor ao Artifact Registry. Pode ter de conceder o âmbito de storage-ro acesso para conceder autorização de leitura para obter imagens.

  1. Conceda à conta de serviço do Compute Engine autorização de leitura ao Artifact Registry:

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

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

Configure o Config Sync

Nesta secção, configura as definições do repositório de raiz. Se estiver a sincronizar com um repositório Git, pode usar a Google Cloud consola para receber orientações ao longo do processo de instalação e automatizar alguns passos.

Quando instala o Config Sync através da Google Cloud consola ou da CLI Google Cloud, o Config Sync cria automaticamente um objeto RootSync denominado root-sync. Pode usar comandos kubectl para modificar root-sync e adicionar configurações do Config Sync adicionais. Para saber mais, consulte o artigo Configure a sincronização de configuração com comandos kubectl.

Consola

Instale o Config Sync

Para instalar o Config Sync, todos os clusters têm de estar registados numa frota. Quando instala o Config Sync na Google Cloud consola, a seleção de clusters individuais regista automaticamente esses clusters na sua frota.

  1. Na Google Cloud consola, aceda à página Configuração na secção Funcionalidades.

    Aceda à configuração

  2. Clique em Instalar Config Sync.
  3. Selecione a versão do Config Sync que quer usar.
  4. Em Opções de instalação, selecione uma das seguintes opções:
    • Instale o Config Sync em toda a frota (recomendado): o Config Sync é instalado em todos os clusters da frota.
    • Instale o Config Sync em clusters individuais: todos os clusters selecionados são registados automaticamente numa frota. O Config Sync é instalado em todos os clusters na frota.
  5. Se estiver a instalar o Config Sync em clusters individuais, na tabela Clusters disponíveis, selecione os clusters nos quais quer instalar o Config Sync.
  6. Clique em Instalar Config Sync. No separador Definições, após alguns minutos, deve ver Ativado na coluna Estado para os clusters na sua frota.

Implemente um pacote

Depois de registar os seus clusters numa frota e instalar o Config Sync, pode configurar o Config Sync para implementar um pacote num cluster a partir de uma fonte de verdade. Pode implementar o mesmo pacote em vários clusters ou implementar pacotes diferentes em clusters diferentes. Pode editar um pacote após a implementação, exceto algumas definições, como o nome do pacote e o tipo de sincronização. Para mais informações, consulte o artigo Faça a gestão de pacotes.

Para implementar um pacote, conclua os seguintes passos:

  1. Na Google Cloud consola, aceda ao painel de controlo do Config Sync.

    Aceda ao painel de controlo do Config Sync

  2. Clique em Implementar pacote.

  3. Na tabela Selecionar clusters para implementação de pacotes, selecione o cluster ao qual quer implementar um pacote e, de seguida, clique em Continuar.

  4. Selecione Pacote alojado no Git ou Pacote alojado no OCI como o tipo de origem e, de seguida, clique em Continuar.

  5. Na secção Detalhes do pacote, introduza um Nome do pacote, que identifica o objeto RootSync ou RepoSync.

  6. No campo Tipo de sincronização, escolha Sincronização ao nível do cluster ou Sincronização ao nível do espaço de nomes como o tipo de sincronização.

    A sincronização com âmbito de cluster cria um objeto RootSync e a sincronização com âmbito de espaço de nomes cria um objeto RepoSync. Para mais informações sobre estes objetos, consulte o artigo Arquitetura da sincronização de configuração.

  7. Na secção Origem, conclua o seguinte:

    • Para origens alojadas num repositório Git, introduza os seguintes campos:

      1. Introduza o URL do repositório Git que está a usar como fonte de informação como o URL do repositório.
      2. Opcional: atualize o campo Revisão para verificar se não está a usar o HEAD predefinido.
      3. Opcional: atualize o campo Caminho se não quiser sincronizar a partir do repositório raiz.
      4. Opcional: atualize o campo Branch se não estiver a usar a ramificação main predefinida.

    • Para origens alojadas numa imagem OCI, introduza os seguintes campos:

      1. Introduza o URL da imagem OCI que está a usar como fonte de dados fidedignos como imagem.
      2. Introduza o caminho do diretório a partir do qual quer sincronizar, relativo ao diretório raiz, como o Directory.

  8. (Opcional): expanda a secção Definições avançadas para concluir o seguinte:

    1. Selecione um Tipo de autenticação. O Config Sync precisa de acesso só de leitura à sua fonte de informações verdadeiras para ler os ficheiros de configuração na origem e aplicá-los aos seus clusters. A menos que a sua origem não exija autenticação, como um repositório público, certifique-se de que concede ao Config Sync acesso apenas de leitura ao seu repositório Git, imagem OCI ou gráfico Helm (apenas na CLI gcloud). Escolha o mesmo tipo de autenticação que configurou quando instalou o Config Sync:

      • Nenhuma: não use autenticação.
      • SSH: autentique-se através de um par de chaves SSH.
      • Cookiefile: autentique-se através de um cookiefile.
      • Token: autentique-se através de uma chave de acesso ou uma palavra-passe.
      • Google Cloud Repository: use uma conta de serviço Google para aceder a um repositório do Cloud Source Repositories. Selecione esta opção apenas se a Workload Identity Federation para o GKE não estiver ativada no seu cluster.
      • Workload Identity: use uma conta de serviço Google para aceder a um repositório do Cloud Source Repositories.

    2. Introduza um número em segundos para definir o Tempo de espera de sincronização, que determina quanto tempo o Config Sync espera entre tentativas de obtenção da fonte de verdade.

    3. Introduza um URL de proxy Git para o proxy HTTPS a usar quando comunicar com a fonte de informações fidedignas.

    4. Escolha Hierarquia para alterar o Formato de origem.

      O valor predefinido Não estruturado é recomendado na maioria dos casos, uma vez que lhe permite organizar a sua fonte de dados fidedignos da forma que quiser.

  9. Clique em Implementar pacote.

    É feito o redirecionamento para a página Packages do Config Sync. Após alguns minutos, deve ver Sincronizado na coluna Estado da sincronização para o cluster que configurou.

gcloud

Antes de continuar, certifique-se de que registou os seus clusters numa frota.

  1. Ative a funcionalidade de frota ConfigManagement:

    gcloud beta container fleet config-management enable

  2. Prepare a configuração criando um novo manifesto ou usando um manifesto existente.apply-spec.yaml A utilização de um manifesto existente permite-lhe configurar o cluster com as mesmas definições usadas por outro cluster.

    Crie um novo manifesto

    Para configurar o Config Sync com novas definições para o cluster, crie um ficheiro denominado apply-spec.yaml e copie o seguinte ficheiro YAML para o mesmo.

    Pode definir todos os campos spec.configSync opcionais de que precisa quando cria o manifesto e, posteriormente, usar comandos kubectl para a configuração. Também só pode definir o campo spec.configSync.enabled como true e omitir os campos opcionais. Posteriormente, pode usar comandos kubectl para criar objetos RootSync adicionais ou RepoSyncs que pode gerir totalmente com comandos kubectl mais tarde.

    # apply-spec.yaml

applySpecVersion: 1
spec:
  configSync:
    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
    syncRev: REVISION
    syncBranch: BRANCH
    secretType: SECRET_TYPE
    gcpServiceAccountEmail: EMAIL
    metricsGcpServiceAccountEmail: METRICS_EMAIL
    policyDir: DIRECTORY
    preventDrift: PREVENT_DRIFT

    Substitua o seguinte:

    • SOURCE_TYPE: adicione git para sincronizar a partir de um repositório Git, oci para sincronizar a partir de uma imagem OCI ou helm para sincronizar a partir de um gráfico Helm. Se não for especificado nenhum valor, o valor predefinido é git.
    • FORMAT: adicione unstructured para usar um repositório não estruturado ou adicione hierarchy para usar um repositório hierárquico. Estes valores são sensíveis a maiúsculas e minúsculas. Este campo é opcional e o valor predefinido é hierarchy. Recomendamos que adicione unstructured, porque este formato permite organizar as configurações da forma mais conveniente para si.

    • REPO: adicione o URL da fonte de confiança. 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 planeia usar o SSH como o seu secretType, introduza o URL com o protocolo SSH. Este campo é obrigatório e, se não introduzir um protocolo, o URL é tratado como um URL HTTPS.

      Os URLs de OCI usam o seguinte formato: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Por predefinição, a imagem é extraída da etiqueta latest, mas pode extrair imagens através de TAG ou DIGEST. Especifique TAG ou DIGEST no PACKAGE_NAME:

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

    • REVISION: a revisão de Git (etiqueta ou hash) ou o nome do ramo a partir do qual sincronizar. Quando usar um hash, tem de ser um hash completo e não uma forma abreviada.

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

      git

      • none: Não usar autenticação.
      • ssh: Use um par de chaves SSH.
      • cookiefile: use um cookiefile.
      • token: use um token.
      • gcpserviceaccount: use uma conta de serviço Google para aceder a um repositório do Cloud Source Repositories ou do Secure Source Manager. Se selecionar este tipo de autenticação, tem de criar uma associação de política do IAM depois de concluir a configuração do Config Sync. Para ver detalhes, consulte o separador Conta de serviço Google da secção Conceda acesso de leitura apenas ao Git para o Config Sync.
      • gcenode: use uma conta de serviço Google para aceder a um Cloud Source Repositories. Selecione esta opção apenas se a Workload Identity Federation para o GKE não estiver ativada no seu cluster.
      • githubapp: use uma app GitHub para autenticar um repositório do GitHub.

      Para mais informações sobre estes tipos de autenticação, consulte o artigo Conceder acesso só de leitura do Config Sync ao Git.

      oci

      • none: Não usar autenticação
      • gcenode: use a conta de serviço predefinida do Compute Engine para aceder a uma imagem no Artifact Registry. Selecione apenas esta opção se a Workload Identity Federation para o GKE não estiver ativada no seu cluster.
      • gcpserviceaccount: use uma conta de serviço Google para aceder a uma imagem.

      leme

      • token: use um token.
      • gcenode: use a conta de serviço predefinida do Compute Engine para aceder a uma imagem no Artifact Registry. Selecione apenas esta opção se a Workload Identity Federation para o GKE não estiver ativada no seu cluster.
      • gcpserviceaccount: use uma conta de serviço Google para aceder a uma imagem.

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

    • METRICS_EMAIL: o email da Google Cloud conta de serviço (GSA) usada para exportar métricas do Config Sync para o Cloud Monitoring. O GSA deve ter a função do IAM Monitoring Metric Writer (roles/monitoring.metricWriter). A ServiceAccount do Kubernetes default no espaço de nomes config-management-monitoring deve estar associada à GSA.

    • DIRECTORY: o caminho do diretório a sincronizar, relativo à raiz do repositório Git. Todos os subdiretórios do diretório especificado são incluídos e sincronizados com o cluster. O valor predefinido é o diretório de raiz do repositório.

    • PREVENT_DRIFT: se estiver definido como true, ativa o webhook de admissão do Config Sync para evitar desvios, rejeitando alterações em conflito que sejam enviadas para clusters em produção. A predefinição é false. A sincronização de configuração corrige sempre as variações, independentemente do valor deste campo.

    Para ver uma lista completa dos campos que pode adicionar ao campo spec, consulte campos gcloud.

    Use o manifesto existente

    Para configurar o cluster com as mesmas definições usadas por outro cluster, obtenha as definições de um cluster registado:

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

    Substitua o seguinte:

    • MEMBERSHIP_NAME: o nome de membro do cluster registado que tem as definições do Config Sync que quer usar
    • PROJECT_ID: o ID do seu projeto
    • CONFIG_YAML_PATH: o caminho para o ficheiro apply-spec.yaml que contém as definições obtidas a partir do cluster

  3. Aplique o ficheiro apply-spec.yaml. Se estiver a usar um manifesto existente, deve aplicar o ficheiro ao cluster que quer configurar com as definições que obteve no comando anterior:

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

    Substitua o seguinte:

    • MEMBERSHIP_NAME: o nome do membro da frota que escolheu quando registou o cluster. Pode encontrar o nome com gcloud container fleet memberships list.
    • CONFIG_YAML_PATH: o caminho para o ficheiro apply-spec.yaml.
    • PROJECT_ID: o ID do seu projeto.

Terraform

Para cada cluster no qual quer configurar o Config Sync, aplique um bloco de recursos google_gkehub_feature_membership que contenha um bloco configmanagement e config_sync, como no exemplo seguinte:

git

data "google_project" "default" {}

resource "google_container_cluster" "default" {
  name     = "gke-autopilot-basic"
  location = "us-central1"

  fleet {
    project = data.google_project.default.project_id
  }

  enable_autopilot = true
}

resource "google_gke_hub_feature" "configmanagement_feature" {
  name     = "configmanagement"
  location = "global"
}

resource "google_gke_hub_feature_membership" "configmanagement_feature_member" {
  location = "global"

  feature             = google_gke_hub_feature.configmanagement_feature.name
  membership          = google_container_cluster.default.fleet[0].membership_id
  membership_location = google_container_cluster.default.fleet[0].membership_location

  configmanagement {
    config_sync {
      # The field `enabled` was introduced in Terraform version 5.41.0, and
      # needs to be set to `true` explicitly to install Config Sync.
      enabled = true
      git {
        sync_repo   = "REPO"
        sync_branch = "BRANCH"
        policy_dir  = "DIRECTORY"
        secret_type = "SECRET"
      }
    }
  }
}

Substitua o seguinte:

  • REPO: o URL do repositório Git que contém os seus ficheiros de configuração.
  • BRANCH: o ramo do repositório, por exemplo, main.
  • DIRECTORY: o caminho no repositório Git que representa o nível superior do repositório que quer sincronizar.
  • SECRET: o tipo de autenticação secreta.

oci

data "google_project" "default" {}

resource "google_container_cluster" "default" {
  name     = "gke-autopilot-basic"
  location = "us-central1"

  fleet {
    project = data.google_project.default.project_id
  }

  enable_autopilot = true
}

resource "google_gke_hub_feature" "configmanagement_feature" {
  name     = "configmanagement"
  location = "global"
}

resource "google_gke_hub_feature_membership" "configmanagement_feature_member" {
  location = "global"

  feature             = google_gke_hub_feature.configmanagement_feature.name
  membership          = google_container_cluster.default.fleet[0].membership_id
  membership_location = google_container_cluster.default.fleet[0].membership_location

  configmanagement {
    config_sync {
      # The field `enabled` was introduced in Terraform version 5.41.0, and
      # needs to be set to `true` explicitly to install Config Sync.
      enabled = true
      oci {
        sync_repo   = "REPO"
        policy_dir  = "DIRECTORY"
        secret_type = "SECRET"
      }
    }
  }
}

Substitua o seguinte:

  • REPO: o URL para o repositório de imagens da OCI que contém os seus ficheiros de configuração.
  • DIRECTORY: o caminho absoluto do diretório que contém os recursos que quer sincronizar. Para usar o diretório raiz, deixe este campo em branco.
  • SECRET: o tipo de autenticação secreta.

Repita este processo para cada cluster que quer sincronizar.

Para saber mais sobre a utilização do Terraform, consulte o artigo Suporte do Terraform para o Config Sync.

Depois de terminar a configuração do repositório raiz, pode optar por configurar a sincronização a partir de vários repositórios, incluindo outros repositórios raiz e repositórios de espaço de nomes. Os repositórios de espaço de nomes são úteis se quiser um repositório que contenha configurações com âmbito de espaço de nomes sincronizadas com um espaço de nomes específico em todos os clusters.

Configure predefinições ao nível da frota

Pode ativar e configurar o Config Sync como predefinição ao nível da frota para os seus clusters. Isto significa que todos os novos clusters do GKE no Google Cloud criados na frota terão o Config Sync ativado no cluster com as definições que especificar. Pode saber mais acerca da configuração predefinida da frota em Gerir funcionalidades ao nível da frota.

Se usar apenas a Google Cloud consola, pode ativar o Config Sync por predefinição nos seus clusters e definir a versão do Config Sync para a sua frota. Se usar a CLI gcloud ou o Terraform, pode ativar o Config Sync por predefinição nos seus clusters, definir a versão do Config Sync para a sua frota e configurar a ligação ao seu repositório Git ou repositório de imagens OCI.

Para configurar as predefinições ao nível da frota para o Config Sync, conclua os seguintes passos:

gcloud

Execute o comando enable para a funcionalidade, transmitindo o apply-spec.yaml ficheiro de configuração que criou quando configurou o Config Sync num cluster individual:

gcloud beta container fleet config-management enable \
    --fleet-default-member-config=apply-spec.yaml

Pode usar este comando para atualizar as predefinições da frota em qualquer altura. Se atualizar as predefinições da frota, tem de sincronizar novamente os clusters existentes com as predefinições.

Consola

  1. Na Google Cloud consola, aceda à página Gestor de funcionalidades.

    Aceda ao Gestor de funcionalidades

  2. No painel Sincronização de configuração, clique em Configurar.

  3. Reveja as definições ao nível da frota. Todos os novos clusters que criar na frota herdam estas definições.

  4. Opcional: para alterar as definições predefinidas, clique em Personalizar definições da frota. Na caixa de diálogo apresentada, faça o seguinte:

    1. Selecione a versão do Config Sync que quer usar.
    2. Clique em Guardar alterações.

  5. Clique em Configurar.

  6. Na caixa de diálogo de confirmação Configurar definições da frota, clique em Confirmar. Se não tiver ativado anteriormente a sincronização de configuração, clicar em Confirmar também ativa a API anthosconfigmanagement.googleapis.com.

Terraform

Para ativar a sincronização de configuração numa frota, consulte o seguinte exemplo:

git

resource "google_gke_hub_feature" "default" {
  name     = "configmanagement"
  location = "global"

  fleet_default_member_config {
    configmanagement {
      config_sync {
        # The field `enabled` was introduced in Terraform version 5.41.0, and
        # needs to be set to `true` explicitly to install Config Sync.
        enabled = true
        git {
          sync_repo   = "REPO"
          sync_branch = "BRANCH"
          policy_dir  = "DIRECTORY"
          secret_type = "SECRET"
        }
      }
    }
  }
}

Substitua o seguinte:

  • REPO: o URL do repositório Git que contém os seus ficheiros de configuração.
  • BRANCH: o ramo do repositório, por exemplo, main.
  • DIRECTORY: o caminho no repositório Git que representa o nível superior do repositório que quer sincronizar.
  • SECRET: o tipo de autenticação secreta.

oci

resource "google_gke_hub_feature" "configmanagement_feature_member" {
  name     = "configmanagement"
  location = "global"

  fleet_default_member_config {
    configmanagement {
      config_sync {
        # The field `enabled` was introduced in Terraform version 5.41.0, and
        # needs to be set to `true` explicitly to install Config Sync.
        enabled = true
        oci {
          sync_repo   = "REPO"
          policy_dir  = "DIRECTORY"
          secret_type = "SECRET"
        }
      }
    }
  }
}

Substitua o seguinte:

  • REPO: o URL para o repositório de imagens da OCI que contém os seus ficheiros de configuração.
  • DIRECTORY: o caminho absoluto do diretório que contém os recursos que quer sincronizar. Para usar o diretório raiz, deixe este campo em branco.
  • SECRET: o tipo de autenticação secreta.

Para saber mais sobre a utilização do Terraform, consulte o artigo Suporte do Terraform para o Config Sync.

Para atualizar os clusters existentes de modo a usarem as predefinições do Config Sync, pode usar a consola ou a CLI gcloud para sincronizar os clusters selecionados da frota com as predefinições da frota. Google Cloud Em alternativa, pode configurar manualmente cada cluster com as mesmas definições através do Terraform seguindo as instruções para configurar o Config Sync. Se usou anteriormente o Terraform para especificar as predefinições da frota, use o mesmo bloco configmanagement e config_sync que usou para definir as predefinições para configurar os clusters escolhidos.

Para sincronizar as predefinições do Config Sync na sua frota, siga estes passos:

gcloud

  1. Sincronize uma subscrição existente com a configuração predefinida da frota:

    gcloud beta container fleet config-management apply \
    --origin=FLEET \
    --membership=MEMBERSHIP_NAME

    Substitua MEMBERSHIP_NAME pelo nome de membro da frota do cluster que quer sincronizar com a configuração predefinida da frota.

  2. Confirme se as configurações da subscrição estão sincronizadas com a predefinição da frota:

    gcloud beta container fleet config-management status

    O resultado deste comando deve ser apresentado como Yes para o estado Synced_to_Fleet_Default da subscrição que sincronizou.

consola

  1. Aceda ao Gestor de funcionalidades:

    Aceda ao Gestor de funcionalidades: Config Sync

  2. Na tabela de clusters, selecione os clusters que quer sincronizar com as definições da frota.

  3. Clique em Sincronizar com as definições da frota.

Para desativar as predefinições do Config Sync em toda a sua frota, siga estes passos:

  1. Para desativar a configuração predefinida da frota, execute o seguinte comando:

    gcloud beta container fleet config-management disable --fleet-default-member-config

  2. Confirme que a configuração predefinida da frota está desativada:

    gcloud beta container fleet config-management status

As predefinições do Config Sync são aplicadas a todos os clusters que selecionar. Embora a Google Cloud consola mostre apenas um subconjunto de definições, como a versão da sincronização de configuração, todas as definições ao nível da frota são sincronizadas com os clusters. Por exemplo, se configurar o Config Sync para sincronizar com um repositório Git através do Terraform ou da CLI gcloud, essa definição é sincronizada com os seus clusters, mas não é apresentada na consola Google Cloud .

Valide a instalação

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

Consola

Conclua os seguintes passos:

  1. Na Google Cloud consola, aceda à página Configuração na secção Funcionalidades.

    Aceda à configuração

  2. No separador Pacotes, verifique a coluna Estado da sincronização na tabela de clusters. Uma instalação bem-sucedida do Config Sync tem o estado Instalado. Uma fonte única de informações fidedignas configurada com êxito tem o estado Sincronizado.

gcloud

Execute o seguinte comando:

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

Substitua PROJECT_ID pelo ID do seu projeto.

Uma instalação bem-sucedida tem o estado SYNCED com a versão do Config Sync instalada.

Se vir um erro depois de executar o comando anterior, certifique-se de que criou o git-creds segredo. Se criou o segredo, experimente executar novamente o seguinte comando:

gcloud beta container fleet config-management apply

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

Pedidos de recursos

A secção seguinte lista os pedidos de recursos para o Config Sync.

A tabela seguinte lista os requisitos de recursos do Kubernetes para os componentes do Config Sync. Para mais informações, consulte o artigo Gerir recursos para contentores na documentação do Kubernetes.

Nem todos os componentes indicados são criados. As seguintes condições fazem com que cada componente seja agendado:

  • config-management-operator é instalado quando o Config Sync está ativado.
  • reconciler-manager é instalado quando o Config Sync está ativado.
  • admission-webhook é instalado quando a prevenção de desvio está ativada.
  • Um reconciler é instalado para cada RootSync e RepoSync.
  • otel-collector é instalado quando o Config Sync está ativado.

Para saber mais acerca destes componentes, consulte o artigo Arquitetura do Config Sync.

Os pedidos de recursos são os mesmos para todas as versões suportadas do Config Sync.

Nome da implementação Pedido de CPU (m) por réplica Pedido de memória (Mi) por réplica
config-management-operator 100 200
resource-group-controller-manager 110 300
admission-webhook1 10 100
otel-collector 200 400
reconciler-manager 20 150
reconciler (um por RootSync e RepoSync) Consulte a implementação do reconciliador para ver detalhes.

1 O webhook de admissão tem duas réplicas, pelo que, ao calcular os pedidos de recursos totais, tem de duplicar o valor se estiver a usar o webhook de admissão. O webhook de admissão está desativado por predefinição.

Implementação do reconciliador

Para cada objeto RootSync e RepoSync, o Config Sync cria uma implementação de reconciliador independente para processar a sincronização. A implementação do reconciliador consiste em vários contentores. Para saber mais acerca destes contentores, consulte o artigo Contentores do reconciliador.

Clusters padrão

Os pedidos de recursos são os mesmos para todas as versões suportadas do Config Sync.

Nome do contentor Pedido de CPU (m) Pedido de memória (Mi)
reconciler 50 200
otel-agent 10 100
hydration-controller (Opcional) 10 100
git-sync 10 16
gcenode-askpass-sidecar (Opcional) 10 20
helm-sync 75 128
oci-sync 25 32

Clusters do Autopilot

Os pedidos de recursos são os mesmos para todas as versões suportadas do Config Sync.

Nome do contentor Pedido e limite da CPU (m) Pedido e limite de memória (Mi)
reconciler 700 512
otel-agent 10 64
hydration-controller (Opcional) 200 256
git-sync 20 32
gcenode-askpass-sidecar (Opcional) 50 64
helm-sync 250 384
oci-sync 50 64

Para saber como substituir os pedidos e os limites de recursos predefinidos, consulte as substituições de recursos.

Versões do Helm e do Kustomize incluídas

O Config Sync tira partido dos executáveis do Helm e do Kustomize para renderizar as configurações nos bastidores. A tabela seguinte apresenta uma lista das versões do Config Sync que suportam a funcionalidade de renderização, juntamente com as versões do Helm e Kustomize incluídas.

Versões do Config Sync Versão do Helm Versão do Kustomize
1.22.0 v3.15.3 v5.3.0
1.21.0 v3.15.3 v5.3.0
1.20.0 v3.15.3 v5.3.0

Para obter informações sobre a renderização do Helm através do Kustomize, consulte o artigo Configure o Kubernetes com o Kustomize. Para ver informações sobre a utilização da API Helm, consulte o artigo Sincronizar gráficos Helm do Artifact Registry.

O que se segue?