Instalar o Config Sync
Com o Config Sync, é possível gerenciar os recursos do Kubernetes com arquivos de configuração armazenados em uma fonte de verdade. O Config Sync é compatível com repositórios Git, imagens OCI e gráficos do Helm como uma fonte de verdade. Nesta página, mostramos como ativar e configurar o Config Sync para que ele seja sincronizado com seu repositório raiz. O Config Sync está disponível com a edição Google Kubernetes Engine (GKE) Enterprise.
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 seu ambiente, verifique se você atende aos requisitos do cluster e conceda os papéis de usuário certos.
Preparar o ambiente local
Prepare o ambiente local concluindo as tarefas a seguir:
- Crie ou verifique se você tem acesso a uma fonte de informações. Esse é o lugar em que você adiciona as configurações que o Config Sync sincroniza. Para saber mais sobre como definir as configurações e a fonte de informações, consulte um destes guias:
- Instale e inicialize a Google Cloud CLI, que fornece os
comandos
gcloud
enomos
. Se você usa o Cloud Shell, a Google Cloud CLI já vem pré-instalada. Se você já instalou a Google Cloud CLI, instale a versão mais recente executandogcloud components update
.
Requisitos de cluster
Crie ou tenha acesso a um cluster que atenda aos seguintes requisitos:
- O cluster está em uma plataforma e versão compatíveis da edição Google Kubernetes Engine (GKE) Enterprise.
Se você usar clusters do Autopilot, ele vai ajustar os requisitos de recursos do contêiner para atender às seguintes regras:
- Os limites de recursos são definidos como solicitações de recursos.
- A vCPU de pods está disponível em incrementos de 0,25 vCPU (arredondadas para cima).
- O valor mínimo é 250 miliCPU (mCPU)..
- A proporção de memória (em GiB) para vCPU precisa estar no intervalo de 1 a 6,5 vCPU.
Devido a essas regras, para clusters do Autopilot, o Config Sync:
- ajusta os limites de substituição de recursos especificados pelo usuário para corresponder às solicitações.
- aplica as substituições apenas quando existe uma ou mais solicitações de recursos superiores à saída ajustada correspondente declarada na anotação ou existe uma ou mais solicitações de recursos inferiores à entrada correspondente declarada na anotação.
(Opcional) O cluster terá a Identidade da carga de trabalho ativada se você usar clusters do GKE. A Identidade da carga de trabalho é a maneira indicada para acessar os serviços do Google Cloud em aplicativos executados no GKE. Esse método fornece propriedades de segurança e gerenciamento aprimorados. Os clusters do Autopilot têm a identidade da carga de trabalho ativada por padrão.
Conceda as permissões de gravação de métrica corretas para que o Config Sync possa enviar métricas para o Cloud Monitoring. Isso é obrigatório se você quiser usar upgrades automáticos.
Se você quiser fazer upgrade automático da versão do Config Sync, verifique se o cluster do GKE está inscrito em um canal de lançamento. Um cluster que não usa canais de lançamento do GKE é tratado como um cluster que usa o canal de lançamento Stable.
Se você quiser usar um cluster particular do GKE, configure o Cloud NAT para permitir a saída de nós particulares do GKE. Para detalhes, 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 uma conta de serviço do Google ao conceder acesso ao Config Sync à sua fonte de informações, inclua o escopo somente leitura nos escopos de acesso dos nós no cluster do Cloud Source Repositories.
É possível adicionar o escopo somente leitura incluindo
cloud-source-repos-ro
na lista--scopes
especificada no momento da criação do cluster ou usando o escopocloud-platform
no momento da criação do cluster. Exemplo:gcloud container clusters create CLUSTER_NAME --scopes=cloud-platform
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 incluicloud-source-repos-ro
.Se você tiver requisitos rígidos de firewall da VPC que bloqueiam qualquer tráfego desnecessário, será necessário Criar regras de firewall para permitir o tráfego a seguir em clusters públicos do GKE:
TCP: permite a entrada e a saída nas portas 53 e 443
UDP: permitir a saída na porta 53
Se você não incluir essas regras, o Config Sync não será sincronizado corretamente, com
nomos status
informando o seguinte erro:Error: KNV2004: unable to sync repo Error in the git-sync container
Pule essas etapas se estiver usando um cluster particular do GKE.
Execute o Config Sync em um pool de nós
amd64
. As imagens de contêiner do componente de back-end do Config Sync são criadas, distribuídas e testadas apenas para a arquitetura de máquinaamd64
. Se um componente do Config Sync estiver programado em um nó do ARM, ele apresentará o erroexec format
e falhará.Se você tiver nós Arm no cluster, adicione um ou mais nós amd64 ao cluster e, se não estiver usando um cluster do GKE, adicione um taint aos nós arm64 para evitar a programação de pods nos nós arm64 sem uma tolerância específica. Os nós do grupo do GKE já têm um taint padrão, então você não precisa adicionar um.
Preparar o cluster
Depois de criar um cluster adequado, siga estas etapas:
Se você planeja usar a Google Cloud CLI para configurar o Config Sync ou usar clusters fora do Google Cloud, verifique se os clusters do GKE ou clusters fora do Google Cloud estão registradas em uma frota agora. Se você planeja usar o console do Google Cloud, é possível registrar clusters do GKE ao configurar o Config Sync.
Instalar o Config Sync
Nas seções a seguir, você concede ao Config Sync acesso a uma destas fontes de verdade:
Depois de conceder o acesso, é possível configurar o Config Sync.
Permitir acesso ao Git
O Config Sync precisa de acesso somente leitura ao seu repositório Git para ler os configs confirmados no repositório e aplicá-los aos clusters.
Se o repositório não exigir autenticação para acesso somente leitura, será possível
continuar a configurar o Config Sync e
usar none
como o tipo de autenticação. Por exemplo, se for possível navegar no
repositório usando uma interface da Web sem fazer login ou usar git
clone
para criar um clone do repositório localmente sem fornecer credenciais
ou usar credenciais salvas, não será necessário fazer a autenticação. Nesse caso,
você não precisa criar um secret.
No entanto, a maioria dos usuários precisa criar credenciais porque o acesso de leitura ao repositório é
restrito. Se as credenciais forem necessárias, elas serão armazenadas no secret git-creds
em cada cluster registrado (a menos que você esteja usando uma conta de serviço do Google). O secret precisa ser nomeado como git-creds
porque esse é um valor fixo.
O Config Sync é compatível com os seguintes mecanismos de autenticação:
- Par de chaves SSH (
ssh
) - Cookiefile (
cookiefile
) - Token (
token
) - Conta de serviço do Google (
gcpserviceaccount
) - Conta de serviço padrão do Compute Engine (
gcenode
)
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.
Para usar um repositório no Cloud Source Repositories como seu repositório do Config Sync, conclua as etapas a seguir para recuperar o URL do Cloud Source Repositories:
Liste todos os repositórios:
gcloud source repos list
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.
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:
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.
Configure seu repositório para reconhecer a chave pública recém-criada. Consulte a documentação do seu provedor de hospedagem Git. Instruções para alguns provedores de hospedagem Git conhecidos estão incluídas por conveniência:
- Cloud Source Repositories
- Bitbucket
- GitHub Recomendamos que você crie chaves de implantação separadas para fornecer acesso somente leitura a um único repositório do GitHub.
- GitLab
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
).(Recomendado) Para configurar a verificação de hosts conhecidos usando a autenticação SSH, adicione a chave de hosts conhecida ao campo
data.known_hosts
no secretgit_creds
. Para desativar a verificação deknown_hosts
, remova o campoknown_hosts
do secret. Para adicionar a chave de hosts conhecida, execute:kubectl edit secret git-creds \ --namespace=config-management-system
Em seguida, em
data
, adicione a entrada de hosts conhecida:known_hosts: KNOWN_HOSTS_KEY
Exclua a chave privada do disco local ou a proteja.
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. Para ver um 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:
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.
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.
Crie um token usando o GitHub, o GitLab ou o Bitbucket.
- GitHub: crie um PAT.
Conceda ao token o escopo
repo
para que ele possa ler os repositórios particulares. Como você vincula um PAT a uma conta do GitHub, também recomendamos criar um usuário de máquina e vincular seu PAT a ele. - GitLab: crie um PAT ou crie um token de implantação
- Bitbucket: crie uma senha de app.
- GitHub: crie um PAT.
Conceda ao token o escopo
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 usarTOKEN
: o token que você criou na etapa anterior
Se você precisar usar um proxy HTTPS, adicione-o ao secret junto de
username
etoken
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 usarTOKEN
: o token que você criou na etapa anteriorHTTPS_PROXY_URL
: o URL do proxy HTTPS que você usa ao se comunicar com o repositório Git.
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 e o cluster usar a Identidade da carga de trabalho do GKE ou a Identidade da carga de trabalho da frota, será possível conceder ao Config Sync acesso a um repositório no mesmo projeto que o cluster gerenciado usando uma conta de serviço do Google.
Crie uma conta de serviço se você ainda não tiver uma.
Conceda o papel do IAM de Leitor do Cloud Source Repositories (
roles/source.reader
) à conta de serviço do Google. Para mais informações sobre os papéis e permissões do Cloud Source Repositories, consulte Conceder permissões para visualizar repositórios.Conceda permissão a todo o projeto se as mesmas permissões se aplicarem a todos os repositórios no projeto.
gcloud projects add-iam-policy-binding PROJECT_ID \ --role=roles/source.reader \ --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
Conceda permissão específica do repositório quando quiser que as contas de serviço tenham diferentes níveis de acesso para cada repositório no projeto.
gcloud source repos set-iam-policy REPOSITORY POLICY_FILE --project=PROJECT_ID
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
comosecretType
e adicione o e-mail da conta de serviço agcpServiceAccountEmail
.Depois configurar o Config Sync, 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.
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 Identidade da carga de trabalho. Com o conceito de semelhança da frota, se você adicionar a política do IAM à sua conta de serviço do Kubernetes em um cluster, a conta de serviço do Kubernetes do mesmo namespace em outros clusters da mesma frota também receberá a mesma política do IAM.
Essa vinculação permite que a conta de serviço do Kubernetes do Config Sync atue como a conta de serviço do Google:
gcloud iam service-accounts add-iam-policy-binding \ GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/iam.workloadIdentityUser \ --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \ --project=PROJECT_ID
Substitua:
PROJECT_ID
: ID do projeto da organização.FLEET_HOST_PROJECT_ID
: se você estiver usando a Identidade da carga de trabalho do GKE, será igual aPROJECT_ID
. Se você estiver usando a identidade da carga de trabalho da frota, esse será o ID do projeto da frota em que o cluster está registrado.GSA_NAME
: a conta de Serviço do Google personalizada que você quer usar para se conectar ao Artifact Registry. Essa conta de serviço precisa ter o papel do IAM "Leitor do Artifact Registry" (roles/artifactregistry.reader
).KSA_NAME
: a conta de serviço do Kubernetes do reconciliador.- Para repositórios raiz, se o nome
RootSync
forroot-sync
, useroot-reconciler
. Caso contrário, useroot-reconciler-ROOT_SYNC_NAME
. Se você instalar o Config Sync usando o console do Google Cloud ou a Google Cloud CLI, o Config Sync criará automaticamente um objeto RootSync chamadoroot-sync
.
- Para repositórios raiz, se o nome
REPOSITORY
: o nome do repositório.POLICY_FILE
: o arquivo JSON ou YAML com a política do Identity and Access Management.
Conta de serviço padrão do Compute Engine
Se o repositório estiver no Cloud Source Repositories e o cluster for do GKE no Google Cloud com a Identidade da carga de trabalho desativada, será possível usar gcenode
como o tipo de autenticação.
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
.
Selecionar o Google Cloud Repository ou gcenode
permite que você use a
conta de serviço padrão do Compute Engine. Conceda o
papel do IAM de Leitor do Cloud Source Repositories (roles/source.reader
)
à conta de serviço padrão do Compute Engine. Para mais informações sobre os papéis e permissões do Cloud Source Repositories, consulte Conceder permissões para visualizar repositórios.
gcloud projects add-iam-policy-binding PROJECT_ID \
--role=roles/source.reader \
--member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"
Substitua PROJECT_ID
pelo ID do projeto da organização e PROJECT_NUMBER
pelo número do projeto da organização.
Conceder acesso somente leitura do Config Sync ao OCI
O Config Sync precisa de acesso somente leitura à imagem OCI armazenada no Artifact Registry para ler as configurações incluídas na imagem e aplicá-las aos clusters.
Se o repositório não exigir autenticação para acesso somente leitura, será possível
continuar a
configurar o Config Sync
e usar none
como o tipo de autenticação. Por exemplo, se a imagem for pública
e puder ser acessada por qualquer pessoa na Internet, você não precisará fazer a autenticação.
No entanto, a maioria dos usuários precisa criar credenciais para acessar imagens restritas. O Config Sync é compatível com os seguintes mecanismos de autenticação:
- Conta de serviço do Kubernetes (
k8sserviceaccount
) - Conta de serviço do Google (
gcpserviceaccount
) Conta de serviço padrão do Compute Engine (
gcenode
)
Conta de serviço do Kubernetes
Se você armazenar sua imagem OCI no Artifact Registry e seu cluster usar a
Identidade da carga de trabalho do GKE
ou a Identidade da carga de trabalho da frota,
será possível usar k8sserviceaccount
como seu tipo de autenticação na versão 1.17.2
e mais recentes. Essa opção é recomendada em vez de gcpserviceaccount
devido ao
processo de configuração simplificado.
Conceda o papel do IAM de Leitor do Artifact Registry (
roles/artifactregistry.reader
) à conta de serviço do Kubernetes com o pool de Identidade da carga de trabalho. Para mais informações sobre os papéis e permissões do Artifact Registry, consulte Configurar papéis e permissões do Artifact Registry.Conceda permissão a todo o projeto se as mesmas permissões se aplicarem a todos os repositórios no projeto.
gcloud projects add-iam-policy-binding PROJECT_ID \ --role=roles/artifactregistry.reader \ --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
Conceda permissão específica do repositório quando quiser que as contas de serviço tenham diferentes níveis de acesso para cada repositório no projeto.
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \ --location=LOCATION \ --role=roles/artifactregistry.reader \ --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \ --project=PROJECT_ID
Substitua:
PROJECT_ID
: ID do projeto da organização.FLEET_HOST_PROJECT_ID
: se você estiver usando a Identidade da carga de trabalho do GKE, será igual aPROJECT_ID
. Se você estiver usando a identidade da carga de trabalho da frota, esse será o ID do projeto da frota em que o cluster está registrado.KSA_NAME
: a conta de serviço do Kubernetes do reconciliador.- Para repositórios raiz, se o nome
RootSync
forroot-sync
, useroot-reconciler
. Caso contrário, useroot-reconciler-ROOT_SYNC_NAME
. Se você instalar o Config Sync usando o console do Google Cloud ou a Google Cloud CLI, o Config Sync criará automaticamente um objeto RootSync chamadoroot-sync
.
- Para repositórios raiz, se o nome
REPOSITORY
: o ID do repositório.LOCATION
: o local regional ou multirregional do repositório.
Conta de serviço do Google.
Se você armazenar sua imagem OCI no Artifact Registry e seu cluster usar a
Identidade da carga de trabalho do GKE
ou a Identidade da carga de trabalho da frota,
será possível usar gcpserviceaccount
como o tipo de autenticação. A partir da
versão 1.17.2, é recomendável usar k8sserviceaccount
. Essa
opção elimina as etapas extras da criação de uma conta de serviço do Google e a
vinculação de política do IAM associada.
Crie uma conta de serviço se você ainda não tiver uma.
Conceda o papel do IAM de leitor do Artifact Registry (
roles/artifactregistry.reader
) à conta de serviço do Google. Para mais informações sobre os papéis e permissões do Artifact Registry, consulte Configurar papéis e permissões do Artifact Registry.Conceda permissão a todo o projeto se as mesmas permissões se aplicarem a todos os repositórios no projeto.
gcloud projects add-iam-policy-binding PROJECT_ID \ --role=roles/artifactregistry.reader \ --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
Conceda permissão específica do repositório quando quiser que as contas de serviço tenham diferentes níveis de acesso para cada repositório no projeto.
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \ --location=LOCATION \ --role=roles/artifactregistry.reader \ --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \ --project=PROJECT_ID
Crie uma vinculação de política do IAM entre a conta de serviço do Kubernetes e a conta de serviço do Google executando o seguinte comando:
gcloud iam service-accounts add-iam-policy-binding GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/iam.workloadIdentityUser \ --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \ --project=PROJECT_ID
Substitua:
PROJECT_ID
: ID do projeto da organização.FLEET_HOST_PROJECT_ID
: se você estiver usando a Identidade da carga de trabalho do GKE, será igual aPROJECT_ID
. Se você estiver usando a identidade da carga de trabalho da frota, esse será o ID do projeto da frota em que o cluster está registrado.GSA_NAME
: a conta de Serviço do Google personalizada que você quer usar para se conectar ao Artifact Registry. Essa conta de serviço precisa ter o papel do IAM "Leitor do Artifact Registry" (roles/artifactregistry.reader
).KSA_NAME
: a conta de serviço do Kubernetes do reconciliador.- Para repositórios raiz, se o nome
RootSync
forroot-sync
, useroot-reconciler
. Caso contrário, useroot-reconciler-ROOT_SYNC_NAME
. Se você instalar o Config Sync usando o console do Google Cloud ou a Google Cloud CLI, o Config Sync criará automaticamente um objeto RootSync chamadoroot-sync
.
- Para repositórios raiz, se o nome
REPOSITORY
: o ID do repositório.LOCATION
: o local regional ou multirregional do repositório.
Conta de serviço padrão do Compute Engine
Se você armazenar o gráfico Helm no Artifact Registry e seu cluster for do GKE no Google Cloud
com a Identidade da carga de trabalho desativada, será possível usar gcenode
como
tipo de autenticação.
O Config Sync usa a conta de serviço padrão do Compute Engine.
Conceda ao leitor de conta de serviço padrão do Compute Engine
o acesso ao Artifact Registry.
Conceda à conta de serviço do Compute Engine permissão de leitura para o Artifact Registry executando o seguinte comando:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \ --role=roles/artifactregistry.reader
Substitua
PROJECT_ID
pelo ID do projeto da organização ePROJECT_NUMBER
pelo número do projeto da organização.
Conceder acesso somente leitura do Config Sync ao Helm
O Config Sync precisa de acesso somente leitura ao seu repositório do Helm para ler os gráficos do Helm no repositório e instalá-los nos clusters.
Se o repositório não exigir autenticação para acesso somente leitura, será possível
continuar a configurar o Config Sync e
usar none
como o tipo de autenticação. Por exemplo, se o repositório do Helm for público e puder ser acessado por qualquer pessoa na Internet, não será necessário autenticar.
No entanto, a maioria dos usuários precisa criar credenciais para acessar repositórios particulares do Helm. O Config Sync é compatível com os seguintes mecanismos de autenticação:
- Token (
token
) - Conta de serviço do Kubernetes (
k8sserviceaccount
) - Conta de serviço do Google (
gcpserviceaccount
) - Conta de serviço padrão do Compute Engine (
gcenode
)
Token
Crie um Secret com um nome de usuário e uma senha do repositório Helm:
kubectl create secret generic SECRET_NAME \
--namespace=config-management-system \
--from-literal=username=USERNAME \
--from-literal=password=PASSWORD
Substitua:
SECRET_NAME
: o nome que você quer dar ao controlador.USERNAME
: o nome de usuário do repositório do Helm.PASSWORD
: a senha do repositório do Helm.
Quando você configurar o ConfigManagement Operator,
você usará o nome do secret escolhido para spec.helm.secretRef.name
.
Conta de serviço do Kubernetes
Se você armazenar o gráfico Helm no Artifact Registry e seu cluster usar a
Identidade da carga de trabalho do GKE
ou a Identidade da carga de trabalho da frota,
será possível utilizar k8sserviceaccount
como tipo de autenticação na versão 1.17.2
e mais recentes. Essa opção é recomendada em vez de gcpserviceaccount
devido ao
processo de configuração simplificado.
Conceda o papel do IAM de Leitor do Artifact Registry (
roles/artifactregistry.reader
) à conta de serviço do Kubernetes com o pool de Identidade da carga de trabalho. Para mais informações sobre os papéis e permissões do Artifact Registry, consulte Configurar papéis e permissões do Artifact Registry.Conceda permissão a todo o projeto se as mesmas permissões se aplicarem a todos os repositórios no projeto.
gcloud projects add-iam-policy-binding PROJECT_ID \ --role=roles/artifactregistry.reader \ --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
Conceda permissão específica do repositório quando quiser que as contas de serviço tenham diferentes níveis de acesso para cada repositório no projeto.
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \ --location=LOCATION \ --role=roles/artifactregistry.reader \ --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \ --project=PROJECT_ID
Substitua:
PROJECT_ID
: ID do projeto da organização.FLEET_HOST_PROJECT_ID
: se você estiver usando a Identidade da carga de trabalho do GKE, será igual aPROJECT_ID
. Se você estiver usando a identidade da carga de trabalho da frota, esse será o ID do projeto da frota em que o cluster está registrado.KSA_NAME
: a conta de serviço do Kubernetes do reconciliador.- Para repositórios raiz, se o nome
RootSync
forroot-sync
, useroot-reconciler
. Caso contrário, useroot-reconciler-ROOT_SYNC_NAME
.
- Para repositórios raiz, se o nome
REPOSITORY
: o ID do repositório.LOCATION
: o local regional ou multirregional do repositório.
Conta de serviço do Google.
Se você armazenar o gráfico do Helm no Artifact Registry e o cluster usar
Identidade da carga de trabalho do GKE
ouIdentidade da carga de trabalho da frota ,gcpserviceaccount
como seu tipo de autenticação. A partir da
versão 1.17.2, é recomendável usar k8sserviceaccount
. Essa
opção elimina as etapas extras da criação de uma conta de serviço do Google e a
vinculação de política do IAM associada.
Crie uma conta de serviço se você ainda não tiver uma.
Conceda o papel do IAM de leitor do Artifact Registry (
roles/artifactregistry.reader
) à conta de serviço do Google. Para mais informações sobre os papéis e permissões do Artifact Registry, consulte Configurar papéis e permissões do Artifact Registry.Conceda permissão a todo o projeto se as mesmas permissões se aplicarem a todos os repositórios no projeto.
gcloud projects add-iam-policy-binding PROJECT_ID \ --role=roles/artifactregistry.reader \ --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
Conceda permissão específica do repositório quando quiser que as contas de serviço tenham diferentes níveis de acesso para cada repositório no projeto.
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \ --location=LOCATION \ --role=roles/artifactregistry.reader \ --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \ --project=PROJECT_ID
Crie uma vinculação de política do IAM entre a conta de serviço do Kubernetes e a conta de serviço do Google executando o seguinte comando:
gcloud iam service-accounts add-iam-policy-binding GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/iam.workloadIdentityUser \ --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" --project=PROJECT_ID
Substitua:
PROJECT_ID
: ID do projeto da organização.FLEET_HOST_PROJECT_ID
: se você estiver usando a Identidade da carga de trabalho do GKE, será igual aPROJECT_ID
. Se você estiver usando a identidade da carga de trabalho da frota, esse será o ID do projeto da frota em que o cluster está registrado.GSA_NAME
: a conta de Serviço do Google personalizada que você quer usar para se conectar ao Artifact Registry. Essa conta de serviço precisa ter o papel do IAM "Leitor do Artifact Registry" (roles/artifactregistry.reader
).KSA_NAME
: a conta de serviço do Kubernetes do reconciliador.- Para repositórios raiz, se o nome
RootSync
forroot-sync
, useroot-reconciler
. Caso contrário, useroot-reconciler-ROOT_SYNC_NAME
.
- Para repositórios raiz, se o nome
REPOSITORY
: o ID do repositório.LOCATION
: o local regional ou multirregional do repositório.
Conta de serviço padrão do Compute Engine
Se você armazenar o gráfico Helm no Artifact Registry e seu cluster for do GKE no Google Cloud
com a Identidade da carga de trabalho desativada, será possível usar gcenode
como
tipo de autenticação.
O Config Sync usa a conta de serviço padrão do Compute Engine.
Conceda ao leitor de conta de serviço padrão do Compute Engine
o acesso ao Artifact Registry. Talvez seja necessário conceder acesso ao escopo
storage-ro
para conceder permissão somente leitura
para extrair imagens.
Conceda à conta de serviço do Compute Engine a permissão de leitura para o Artifact Registry:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \ --role=roles/artifactregistry.reader
Substitua
PROJECT_ID
pelo ID do projeto da organização ePROJECT_NUMBER
pelo número do projeto da organização.
Configurar o Config Sync
Nesta seção, você definirá as configurações do seu repositório raiz. Se você estiver sincronizando com um repositório Git, use o console do Google Cloud para orientar você no processo de instalação e automatizar algumas etapas.
Quando você instala o Config Sync usando o console do Google Cloud ou a
Google Cloud CLI, o Config Sync cria automaticamente um objeto RootSync chamado
root-sync
. É possível usar comandos kubectl
para modificar root-sync
e adicionar
outras configurações do Config Sync. Para saber mais, consulte
Configurar o Config Sync com comandos kubectl
.
Console
Instalar o Config Sync
Para instalar o Config Sync, todos os clusters precisam estar registrados em uma frota. Quando você instala o Config Sync no console do Google Cloud, a seleção de clusters individuais registra automaticamente esses clusters na sua frota.
- No console do Google Cloud, acesse a página Configuração na seção Recursos.
- Clique em add Instalar o Config Sync.
- Selecione Upgrades automáticos (Visualizar) para ativar o Config Sync para fazer upgrade das versões automaticamente ou selecione Upgrades manuais para gerenciar a versão do Config Sync por conta própria. Para mais informações sobre como os upgrades automáticos funcionam, consulte Fazer upgrade do Config Sync.
- Em Opções de instalação, selecione uma das seguintes opções:
- Instalar o Config Sync em toda a frota (recomendado): o Config Sync será instalado em todos os clusters na frota.
- Instale o Config Sync em clusters individuais: todos os clusters selecionados serão registrados automaticamente em uma frota. O Config Sync será instalado em todos os clusters na frota.
- Se você estiver instalando o Config Sync em clusters individuais, na tabela Clusters disponíveis, selecione os clusters em que você quer instalar o Config Sync.
- Clique em Instalar Config Sync. Na guia Configurações, após alguns minutos, será exibido Ativado na coluna Status dos clusters na sua frota.
Implantar um pacote
Depois de registrar os clusters em uma frota e instalar o Config Sync, é possível configurá-lo para implantar um pacote em um cluster usando uma fonte de verdade. É possível implantar o mesmo pacote em vários clusters ou implantar pacotes diferentes em clusters distintos. É possível editar um pacote após a implantação, exceto algumas configurações, como nome do pacote e tipo de sincronização. Para mais informações, consulte Gerenciar pacotes.
Para implantar um pacote, siga estas etapas:
No console do Google Cloud, acesse o painel do Config Sync.
Clique em Implantar pacote.
Na tabela Selecionar clusters para implantação do pacote, selecione o cluster em que você quer implantar um pacote e clique em Continuar.
Selecione Pacote hospedado no Git ou Pacote hospedado na OCI como tipo de origem e clique em Continuar.
Na seção Package details, insira um Package name, que identifica o objeto RootSync ou RepoSync.
No campo Tipo de sincronização, escolha Sincronização com escopo de cluster ou Sincronização com escopo de namespace como o tipo.
A sincronização com escopo de cluster cria um objeto RootSync e a sincronização com escopo de namespace cria um objeto RepoSync. Para mais informações sobre esses objetos, consulte Arquitetura do Config Sync.
Na seção Origem, faça o seguinte:
Para fontes hospedadas em um repositório Git, insira os seguintes campos:
- Digite o URL do repositório Git que você está usando como fonte de verdade como o URL do repositório.
- Opcional: atualize o campo Revisão para verificar se você não está usando
o
HEAD
padrão. - Opcional: atualize o campo Path se você não quiser sincronizar a partir do repositório raiz.
- Opcional: atualize o campo Ramificação se você não estiver usando a ramificação
main
padrão.
Para fontes hospedadas em uma imagem OCI, insira os seguintes campos:
- Insira o URL da imagem OCI que você está usando como fonte de verdade como a Imagem.
- Insira o caminho do diretório de onde sincronizar, relativo ao diretório raiz, como o Diretório.
(Opcional): expanda a seção Configurações avançadas para concluir o seguinte:
Selecione um Tipo de autenticação. O Config Sync precisa de acesso somente leitura à sua fonte de verdade para ler os arquivos de configuração na origem e aplicá-los aos clusters. A menos que sua origem não exija autenticação, como um repositório público, conceda ao Config Sync acesso somente leitura ao repositório Git, imagem OCI ou gráfico Helm (somente CLI gcloud). Escolha o mesmo tipo de autenticação que você configurou quando instalou o Config Sync:
- Nenhum: não usar autenticação.
- SSH: faça a autenticação usando um par de chaves SSH.
- Cookiefile: faça a autenticação usando um
cookiefile
. - Token: faça a autenticação usando um token de acesso ou uma senha.
- 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.
Insira um número em segundos para definir o Tempo de espera da sincronização, que determina quanto tempo o Config Sync espera entre as tentativas de extração da fonte de verdade.
Insira um URL de proxy Git para o proxy HTTPS a ser usado ao se comunicar com a fonte da verdade.
Escolha Hierarquia para mudar o Formato de origem.
O valor padrão Não estruturado é recomendado na maioria dos casos, porque permite organizar a fonte de verdade como você quiser.
Clique em Implantar pacote.
Você será redirecionado para a página Pacotes do Config Sync. Após alguns minutos, a mensagem Sincronizado vai aparecer na coluna Status da sincronização do cluster configurado.
gcloud
Antes de continuar, registre seus clusters em uma fleet.
Ative o recurso de frota
ConfigManagement
:gcloud beta container fleet config-management enable
Prepare a configuração criando um novo manifesto
apply-spec.yaml
ou usando um existente. Se você escolher a última opção, é possível configurar um cluster com as mesmas configurações usadas por outro.Criar novo manifesto
Para definir o Config Sync com novas configurações para o cluster, crie um arquivo chamado
apply-spec.yaml
e copie o arquivo YAML a seguir nele.É possível definir todos os campos
spec.configSync
opcionais que são necessários ao criar o manifesto e depois usar comandoskubectl
para a configuração. Também é possível definir apenas o campospec.configSync.enabled
comotrue
e omitir os campos opcionais. Posteriormente, é possível usar comandoskubectl
para criar outros objetos RootSync ou RepoSyncs que poderão ser gerenciados totalmente mais tarde por meio de comandoskubectl
.# apply-spec.yaml applySpecVersion: 1 spec: # upgrades: UPGRADE_SETTING configSync: # Set to true to install and enable Config Sync enabled: true # If you don't have a source of truth yet, omit the # following fields. You can configure them later. sourceType: SOURCE_TYPE sourceFormat: FORMAT syncRepo: REPO syncRev: REVISION syncBranch: BRANCH secretType: SECRET_TYPE gcpServiceAccountEmail: EMAIL metricsGcpServiceAccountEmail: METRICS_EMAIL policyDir: DIRECTORY preventDrift: PREVENT_DRIFT
Substitua:
(Visualização)
UPGRADE_SETTING
: remova a marca de comentário do campo e defina comoauto
para configurar o Config Sync para fazer upgrade automaticamente. Defina comomanual
para fazer upgrade manual do Config Sync por conta própria. O valor padrão émanual
. Essa sinalização é compatível apenas com clusters do GKE no Google Cloud. Para usar esse campo, talvez seja necessário atualizar a CLI gcloud executandogcloud components update
.SOURCE_TYPE
: adicionegit
para sincronizar de um repositório Git,oci
para sincronizar de uma imagem OCI ouhelm
para sincronizar de um gráfico do Helm. Se nenhum valor for especificado, o padrão serágit
.FORMAT
: adicioneunstructured
para usar um repositório não estruturado ouhierarchy
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ê adicioneunstructured
como esse formato para organizar suas configurações da melhor maneira para você.REPO
: adiciona o URL da fonte da verdade. Os URLs dos repositórios Git e Helm usam o protocolo HTTPS ou SSH. Por exemplo,https://github.com/GoogleCloudPlatform/anthos-config-management-samples
. Se você planeja usar o SSH como osecretType
, digite o URL com o protocolo SSH. Esse campo é obrigatório e, caso você não insira um protocolo, o URL será tratado como HTTPS.Os URLs da OCI usam o seguinte formato:
LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME
. Por padrão, a imagem é extraída da taglatest
, mas é possível extrair imagens porTAG
ouDIGEST
. EspecifiqueTAG
ouDIGEST
noPACKAGE_NAME
:- Para extrair por
TAG
:LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
- Para extrair por
DIGEST
:LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
- Para extrair por
REVISION
: a revisão Git (tag ou hash) da qual sincronizar. Esse campo é opcional, e o valor padrão éHEAD
. A partir da versão 1.17.0 do Config Sync, também é possível especificar um nome de ramificação no camposyncRev
. Ao usar um hash na versão 1.17.0 ou mais recente, ele precisa ser um hash completo, e não uma forma abreviada.BRANCH
: a ramificação do repositório com que sincronizar. Este campo é opcional e o padrão émaster
. A partir da versão 1.17.0 do Config Sync, é recomendável usar o camposyncRev
para especificar um nome de ramificação para simplificar. Se os campossyncRev
esyncBranch
forem especificados,syncRev
terá precedência sobresyncBranch
.SECRET_TYPE
: uma das seguintes opçõessecretTypes
:git
none
: não usa autenticação.ssh
: usa um par de chaves SSH.cookiefile
: Use umcookiefile
.token
: usar um token.gcpserviceaccount
: use uma conta de serviço do Google para acessar um Cloud Source Repositories. Se você selecionar esse tipo de autenticação, precisará criar uma vinculação de política do IAM depois de concluir a configuração do Config Sync. Para mais detalhes, consulte a guia "Conta de serviço do Google" da seção Conceder acesso somente de leitura do Config Sync ao Git.gcenode
: use uma conta de serviço do Google para acessar um Cloud Source Repositories. Selecione esta opção somente se a identidade da carga de trabalho não estiver ativada em seu cluster.
Para mais informações sobre esses tipos de autenticação, consulte Como conceder acesso somente leitura do Config Sync ao Git.
oci
none
: nenhuma autenticação é usadagcenode
: use a conta de serviço padrão do Compute Engine para acessar uma imagem no Artifact Registry. Selecione esta opção somente se a identidade da carga de trabalho não estiver ativada em seu cluster.gcpserviceaccount
: use uma conta de serviço do Google para acessar uma imagem.
helm
token
: usar um token.gcenode
: use a conta de serviço padrão do Compute Engine para acessar uma imagem no Artifact Registry. Selecione esta opção somente se a identidade da carga de trabalho não estiver ativada em seu cluster.gcpserviceaccount
: use uma conta de serviço do Google para acessar uma imagem.
EMAIL
: se você adicionougcpserviceaccount
comosecretType
, adicione o endereço de e-mail da sua conta de serviço do Google. Por exemplo,acm@PROJECT_ID.iam.gserviceaccount.com
.METRICS_EMAIL
: o e-mail da conta de serviço do Google Cloud (GSA) usada para exportar as métricas do Config Sync para o Cloud Monitoring. A GSA precisa ter o papel do IAM de Gravador de métricas do Monitoring (roles/monitoring.metricWriter
). A conta de serviço do Kubernetesdefault
no namespaceconfig-management-monitoring
precisa ser vinculada ao GSA.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 comotrue
, ativa o webhook de admissão do Config Sync para evitar desvios, rejeitando alterações conflitantes de envio para clusters ativos. A configuração padrão éfalse
. O Config Sync sempre corrige desvios, independentemente do valor desse campo.
Para uma lista completa de campos que podem ser adicionados ao campo
spec
, consulte gcloud.Usar manifesto existente
Para definir o cluster com as mesmas configurações usadas por outro cluster, recupere as configurações de um cluster registrado:
gcloud alpha container fleet config-management fetch-for-apply \ --membership=MEMBERSHIP_NAME \ --project=PROJECT_ID \ > CONFIG_YAML_PATH
Substitua:
MEMBERSHIP_NAME
: o nome da assinatura do cluster registrado que tem as configurações do Config Sync que você quer usarPROJECT_ID
: ID do projetoCONFIG_YAML_PATH
: o caminho para o arquivoapply-spec.yaml
que contém as configurações buscadas no cluster
Aplique o arquivo
apply-spec.yaml
. Se você estiver usando um manifesto atual, aplique o arquivo ao cluster que você quer definir com as configurações buscadas no comando anterior:gcloud beta container fleet config-management apply \ --membership=MEMBERSHIP_NAME \ --config=CONFIG_YAML_PATH \ --project=PROJECT_ID
Substitua:
MEMBERSHIP_NAME
: o nome da associação da frota que você escolheu quando registrou o cluster. O nome pode ser encontrado comgcloud container fleet memberships list
.CONFIG_YAML_PATH
: o caminho para o arquivoapply-spec.yaml
.PROJECT_ID
: o ID do projeto.
Terraform
Para cada cluster em que você quer configurar o Config Sync,
aplique um bloco de recursos google_gkehub_feature_membership
que contenha
um bloco configmanagement
e config_sync
:
git
resource "google_container_cluster" "cluster" {
name = EXISTING_CLUSTER_NAME
location = "EXISTING_CLUSTER_LOCATION"
}
resource "google_gke_hub_membership" "membership" {
membership_id = "MEMBERSHIP_ID"
endpoint {
gke_cluster {
resource_link = "//container.googleapis.com/${google_container_cluster.cluster.id}"
}
}
resource "google_gke_hub_feature" "feature" {
name = "configmanagement"
location = "global"
}
}
resource "google_gke_hub_feature_membership" "feature_member" {
location = "global"
feature = google_gke_hub_feature.feature.name
membership = google_gke_hub_membership.membership.membership_id
configmanagement {
version = "VERSION"
config_sync {
git {
sync_repo = "REPO"
sync_branch = "BRANCH"
policy_dir = "DIRECTORY"
secret_type = "SECRET"
}
}
}
}
Substitua:
EXISTING_CLUSTER_NAME
: o nome do cluster atual.EXISTING_CLUSTER_LOCATION
: o local do cluster atual.MEMBERSHIP_ID
: o ID de vinculação de assinatura.VERSION
: (opcional) o número da versão do Config Sync. Precisa ser definido para a versão 1.17.0 ou mais recente. Se deixado em branco, o padrão será a versão mais recente.REPO
: o URL para o repositório que contém os arquivos de configuração.BRANCH
: a ramificação do repositório, por exemplo,main
.DIRECTORY
: o caminho no repositório Git que representa o nível superior do repositório que você quer sincronizar.SECRET
: o tipo de autenticação do secret.
OCI
resource "google_container_cluster" "cluster" {
name = EXISTING_CLUSTER_NAME
location = "EXISTING_CLUSTER_LOCATION"
}
resource "google_gke_hub_membership" "membership" {
membership_id = "MEMBERSHIP_ID"
endpoint {
gke_cluster {
resource_link = "//container.googleapis.com/${google_container_cluster.cluster.id}"
}
}
resource "google_gke_hub_feature" "feature" {
name = "configmanagement"
location = "global"
}
}
resource "google_gke_hub_feature_membership" "feature_member" {
location = "global"
feature = google_gke_hub_feature.feature.name
membership = google_gke_hub_membership.membership.membership_id
configmanagement {
version = "VERSION"
config_sync {
oci {
sync_repo = "REPO"
policy_dir = "DIRECTORY"
secret_type = "SECRET"
}
}
}
}
Substitua:
EXISTING_CLUSTER_NAME
: o nome do cluster atual.EXISTING_CLUSTER_LOCATION
: o local do cluster atual.MEMBERSHIP_ID
: o ID de vinculação de assinatura.VERSION
: (opcional) o número da versão do Config Sync. Se deixado em branco, o padrão será a versão mais recente.REPO
: o URL do repositório de imagens OCI que contém os arquivos de configuração.DIRECTORY
: o caminho absoluto do diretório que contém os recursos que você quer sincronizar. Deixe em branco para usar o diretório raiz.SECRET
: o tipo de autenticação do secret.
Repita esse processo para cada cluster que quiser sincronizar.
Depois de configurar o repositório raiz, é possível optar por configurar a sincronização de vários repositórios, incluindo outros repositórios raiz e repositórios de namespace. Os repositórios de namespace são úteis caso você queira um repositório que contenha configurações com escopo de namespace sincronizadas com um namespace específico nos clusters.
Configurar padrões no nível da frota
Se você tiver ativado o Google Kubernetes Engine (GKE) Enterprise, poderá ativar e configurar o Config Sync como um padrão no nível da frota para seus clusters. Isso significa que cada novo cluster do GKE no Google Cloud criado na frota terá o Config Sync ativado no cluster com as configurações especificadas. Saiba mais sobre a configuração padrão da frota em Gerenciar recursos no nível da frota.
Se você usa apenas o console do Google Cloud, é possível ativar o Config Sync por padrão nos clusters e definir a versão dele para sua frota. Se você usa o Terraform, é possível ativar o Config Sync por padrão nos clusters, definir a versão do Config Sync para sua frota e configurar a conexão com seu repositório Git ou o repositório de imagens OCI.
Para configurar os padrões da frota para o Config Sync, siga estas etapas:
Console
No console do Google Cloud, acesse a página Gerenciador de recursos.
No painel Config Sync, clique em Configurar.
Revisar as configurações da frota Todos os novos clusters criados na frota herdam essas configurações.
Opcional: para mudar as configurações padrão, clique em Personalizar configurações da frota. Na caixa de diálogo exibida, execute as ações a seguir:
Selecione Upgrades automáticos (Pré-lançamento) para que as versões do Config Sync sejam atualizadas automaticamente ou selecione Upgrades manuais para gerenciar a versão do Config Sync por conta própria. Para mais informações sobre como os upgrades automáticos funcionam, consulte Fazer upgrade do Config Sync.
Se você selecionou Upgrades manuais, na lista Versão, escolha a versão do Config Sync que você quer usar.
Clique em Salvar.
Clique em Configurar.
Na caixa de diálogo Definir configurações da frota, clique em Confirmar. Se você não tiver ativado o Config Sync anteriormente, clicar em Confirmar também ativará a API
anthosconfigmanagement.googleapis.com
.
Terraform
Crie um diretório para os arquivos de configuração padrão da frota do Terraform. Nesse diretório, adicione um arquivo
main.tf
com o seguinte recurso que define as configurações do Config Sync:git
terraform { required_providers { google = { source = "hashicorp/google" version = ">=5.16.0" } } } provider "google" { project = "PROJECT_ID" } resource "google_gke_hub_feature" "feature" { name = "configmanagement" location = "global" provider = google fleet_default_member_config { configmanagement { version = "VERSION" config_sync { source_format = "unstructured" git { sync_repo = "REPO" sync_branch = "BRANCH" policy_dir = "DIRECTORY" secret_type = "SECRET" } } } } }
Substitua:
PROJECT_ID
: o ID do projeto host da frota.VERSION
: (opcional) o número da versão do Config Sync. Se deixado em branco, o padrão será a versão mais recente.REPO
: o URL para o repositório que contém os arquivos de configuração.BRANCH
: a ramificação do repositório, por exemplo,main
.DIRECTORY
: o caminho no repositório Git que representa o nível superior do repositório que você quer sincronizar.SECRET
: o tipo de autenticação do secret.
Para uma lista completa de configurações compatíveis com o bloco
git
do Config Sync, consulte a documentação de referência do Terraform para recursos de hub do GKE.OCI
terraform { required_providers { google = { source = "hashicorp/google" version = ">=5.16.0" } } } provider "google" { project = "PROJECT_ID" } resource "google_gke_hub_feature" "feature" { name = "configmanagement" location = "global" provider = google fleet_default_member_config { configmanagement { version = "VERSION" config_sync { source_format = "unstructured" oci { sync_repo = "REPO" policy_dir = "DIRECTORY" secret_type = "SECRET" } } } } }
Substitua:
PROJECT_ID
: o ID do projeto host da frota.VERSION
: o número da versão do Config Sync. Precisa ser definido para a versão 1.17.0 ou mais recente. Se deixado em branco, o padrão será a versão mais recente.REPO
: o URL para o repositório de imagens OCI que contém arquivos de configuração.DIRECTORY
: o caminho absoluto do diretório que contém os recursos que você quer sincronizar. Deixe em branco para usar o diretório raiz.SECRET
: o tipo de autenticação do secret.
Para uma lista completa de configurações compatíveis com o bloco
oci
do Config Sync, consulte a documentação de referência do Terraform para recursos de hub do GKE.Inicialize o Terraform no diretório que você criou:
terraform init
Verifique se as alterações propostas com o Terraform correspondem ao plano esperado:
terraform plan
Crie as configurações padrão de membros da frota:
terraform apply
Se você tiver clusters que gostaria de atualizar para usar as configurações
padrão do Config Sync, use o console do Google Cloud para sincronizar clusters selecionados
da frota com os padrões da frota. Como alternativa, é possível configurar manualmente cada
cluster com as mesmas configurações usando o Terraform ou a CLI gcloud
seguindo as instruções para
configurar o Config Sync. Se você já usou o Terraform
para especificar os padrões da frota, use os mesmos blocos configmanagement
e
config_sync
usados para definir os padrões e configurar os
clusters escolhidos.
Para sincronizar as configurações padrão do Config Sync em toda a frota, siga estas etapas:
Acesse o Gerenciador de recursos:
Na tabela de clusters, selecione os clusters que você quer sincronizar com as configurações da frota.
Clique em Sincronizar com as configurações da frota.
As configurações padrão do Config Sync serão aplicadas a todos os clusters selecionados. Embora o console do Google Cloud mostre apenas um subconjunto de configurações, como a versão do Config Sync, todas as configurações da frota são sincronizadas com os clusters. Por exemplo, se você configurar o Config Sync para sincronizar com um repositório Git usando o Terraform, essa configuração será sincronizada com seus clusters, mas não será exibida no console do Google Cloud.
Verifique 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:
- No console do Google Cloud, acesse a página Configuração na seção Recursos.
- Na guia Pacotes, verifique a coluna Status da sincronização na tabela de clusters. Uma instalação bem-sucedida do Config Sync tem o status Instalado. Uma fonte de verdade configurada tem o status Sincronizado.
gcloud
Execute este comando:
gcloud beta container fleet config-management status \
--project=PROJECT_ID
Substitua PROJECT_ID
pelo ID do projeto.
Uma instalação bem-sucedida tem um status de SYNCED
. A partir da
versão 1.18.0 do Config Sync, a saída também mostra qual versão do Config Sync
está instalada e a configuração de upgrade do Config Sync.
Se você encontrar um erro depois
de executar o comando anterior, verifique se criou o secret
git-creds
. Se você criou o Secret, tente executar novamente o comando a seguir:
gcloud beta container fleet config-management apply
Também é possível usar o
comando nomos status
para
verificar se o Config Sync foi instalado com sucesso. Uma instalação válida
sem problemas tem o status PENDING
ou SYNCED
. Uma instalação inválida ou incompleta tem o status de
NOT INSTALLED
ou NOT CONFIGURED
. A saída
também inclui todos os erros informados.
Permissões e controles de acesso baseados em função (RBAC)
O Policy Controller, o Config Sync e o Config Controller incluem cargas de trabalho altamente privilegiadas. A tabela a seguir lista as permissões para essas cargas de trabalho:
Componente | Namespace | Conta de serviço | Permissões | Descrição |
---|---|---|---|---|
Operador ConfigManagement | config-management-system |
config-management-operator |
Administrador de clusters | O ConfigManagement Operator instala os outros componentes nesta tabela. Alguns desses componentes exigem permissões de administrador do cluster, portanto, o ConfigManagement Operator também as exige. |
Config Sync | config-management-system |
Consulte as permissões necessárias do Config Sync. |
Solicitações de recursos
A seção a seguir lista as solicitações de recursos do Config Sync.
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.
Nem todos os componentes listados foram criados. As condições a seguir fazem com que cada componente seja programado:
- O
config-management-operator
será instalado quando o Config Sync estiver ativado. - O
reconciler-manager
será instalado quando o Config Sync estiver ativado. - O
admission-webhook
é instalado quando a prevenção contra desvio está ativada. - Um
reconciler
é instalado para cada RootSync e RepoSync. - O
otel-collector
será instalado quando o Config Sync estiver ativado.
Para saber mais sobre esses componentes, consulte Arquitetura do Config Sync.
1.18
Nome da implantação | Solicitação de CPU (m) por réplica | Solicitação 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 implantação do reconciliador para ver mais detalhes. |
1 O webhook de admissão tem duas réplicas. Portanto, ao calcular o total de solicitações de recursos, você precisa dobrar o valor se estiver usando o webhook de admissão. O webhook de admissão é desativado por padrão.
1.17
Nome da implantação | Solicitação de CPU (m) por réplica | Solicitação 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 implantação do reconciliador para ver mais detalhes. |
1 O webhook de admissão tem duas réplicas. Portanto, ao calcular o total de solicitações de recursos, você precisa dobrar o valor se estiver usando o webhook de admissão. O webhook de admissão é desativado por padrão.
1.16
Nome da implantação | Solicitação de CPU (m) por réplica | Solicitação 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 implantação do reconciliador para ver mais detalhes. |
1 O webhook de admissão tem duas réplicas. Portanto, ao calcular o total de solicitações de recursos, você precisa dobrar o valor se estiver usando o webhook de admissão. O webhook de admissão é desativado por padrão.
Implantação do reconciliador
Para cada objeto RootSync
e RepoSync
, o Config Sync cria uma
implantação de reconciliador independente para processar a sincronização. A implantação do reconciliador
consiste em vários contêineres. Para saber mais sobre esses contêineres, consulte
Reconciliação de contêineres.
No Config Sync versão 1.17.0 e mais recentes, as solicitações de recursos padrão para reconciliadores são diferentes para clusters Standard e Autopilot. Todos os outros tipos de cluster usam os padrões padrão.
Clusters padrão
1.18
Nome do contêiner | Solicitação de CPU (m) | Solicitação 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 |
1.17
Nome do contêiner | Solicitação de CPU (m) | Solicitação 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 |
1.16
Nome do contêiner | Solicitação de CPU (m) | Solicitação de memória (Mi) |
---|---|---|
reconciler |
50 | 200 |
otel-agent |
10 | 100 |
hydration-controller (opcional) |
10 | 100 |
git-sync |
10 | 200 |
gcenode-askpass-sidecar (opcional) |
10 | 20 |
helm-sync |
50 | 256 |
oci-sync |
10 | 200 |
Clusters do Autopilot
1.18
Nome do contêiner | Solicitação e limite de CPU (m) | Solicitação 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 |
1.17
Nome do contêiner | Solicitação e limite de CPU (m) | Solicitação 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 |
150 | 256 |
oci-sync |
50 | 64 |
1.16
Nas versões do Config Sync anteriores à 1.17.0, as solicitações de recursos são as mesmas para Standard e Autopilot.
Para saber como modificar as solicitações e os limites padrão de recursos, consulte Modificações de recursos.
Versões Helm e Kustomize agrupadas
O Config Sync aproveita os executáveis Helm e Kustomize para renderizar as configurações em segundo plano. A tabela a seguir fornece uma lista de versões do Config Sync compatíveis com o recurso de renderização, junto com as versões agrupadas do Helm e do Kustomize.
Versões do Config Sync | Versão do Helm | Versão do Kustomize |
---|---|---|
1.18.0 | v3.14.3 | v5.3.0 |
1.17.1 e 1.17.3 | v3.13.3 | v5.3.0 |
1.16.3 e 1.17.0 | v3.13.1 | v5.1.1 |
1.16.1 e 1.16.2 | v3.12.3 | v5.1.1 |
1.16.0 | v3.12.2 | v5.1.1 |
1.15.3 | v3.12.2 | v5.1.0 |
1.15.1 a 1.15.2 | v3.11.3 | v5.0.3 |
1.15.0 | v3.11.3 | v5.0.1 |
1.11.0 a 1.14.3 | v3.6.3 | v4.5.2 |
Para mais informações sobre como renderizar o Helm por meio do Kustomize, consulte Configurar o Kubernetes com o Kustomize. Para informações sobre como usar a API Helm, consulte Como sincronizar gráficos do Helm a partir do Artifact Registry.
A seguir
- Saiba como fazer upgrade do Config Sync.
- Saiba mais sobre os comandos
gcloud
para configurar o Config Sync. - Descubra como configurar a sincronização a partir de repositórios de namespace.
- Use o comando
nomos
- Leia a Introdução à solução de problemas do Config Sync.
- Saiba como desinstalar o Config Sync.
- Consulte as permissões padrão do Config Sync.