Nesta página, você vai conhecer a arquitetura do Config Sync, incluindo os componentes hospedados que são executados no Google Cloud e os componentes de código aberto que são executados no seu cluster do Google Kubernetes Engine. Aprender sobre a arquitetura pode ajudar você a entender melhor o Config Sync e a depurar e corrigir problemas encontrados.
A seção a seguir mostra a arquitetura do Config Sync, incluindo os componentes e dependências dele, tanto no Google Cloud quanto no cluster do GKE:
O
serviço da frota
gerencia os componentes do Config Sync diretamente no cluster, sem o
operador legado do ConfigManagement ou o objeto ConfigManagement. É necessário fazer upgrade manual do Config Sync conforme necessário.
Há várias etapas para instalar o Config Sync, e cada uma delas implanta componentes adicionais no cluster:
Ativar o Config Sync no cluster adiciona os seguintes componentes:
- A definição de recurso personalizado (CRD)
ConfigSync - Um objeto
ConfigSyncchamadoconfig-sync. - O Reconciler Manager em uma implantação chamada
reconciler-manager. - O controlador ResourceGroup em uma implantação chamada
resource-group-controller-manager. - O Coletor do OpenTelemetry em
uma implantação chamada
otel-collector. - Opcional: o webhook de admissão do Config Sync em uma implantação chamada
admission-webhook. O webhook de admissão do Config Sync só é instalado se você ativar a prevenção de deslocamento.
Esses recursos e objetos são criados automaticamente quando você instala o Config Sync e não devem ser modificados diretamente.
- A definição de recurso personalizado (CRD)
A criação dos objetos
RootSynceRepoSyncadiciona os seguintes componentes:- Para cada objeto
RootSync, uma implantação de reconciliação com o nomeroot-reconciler-ROOTSYNC_NAME. Para o objetoRootSyncchamadoroot-sync, a implantação do reconciliador é chamadaroot-reconciler. - Para cada objeto
RepoSync, uma implantação de reconciliação com o nomens-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH. Para o objetoRepoSyncchamadorepo-sync, a implantação do reconciliador é chamada dens-reconciler.
- Para cada objeto
Implantações, pods e contêineres do Config Sync
A tabela a seguir fornece mais informações sobre a implantação, os pods e os contêineres do Config Sync:
| Nome da implantação | Namespace da implantação | Descrição da implantação | Contagem de réplicas | Expressão regular do nome do pod | Contagem de contêineres | Nomes de contêiner |
|---|---|---|---|---|---|---|
reconciler-manager |
config-management-system |
O gerenciador de reconciliação é executado em todos os clusters com o Config Sync
ativado no objeto ConfigManagement. Ele monitora
objetos RootSync
e RepoSync e gerencia uma implantação de reconciliação
para cada um. |
1 | reconciler-manager-.* |
2 | reconciler-managerotel-agent |
root-reconciler |
config-management-system |
Uma implantação de reconciliação raiz é criada para cada objeto RootSync. |
1 | root-reconciler-.* |
3 - 51 |
reconcilerotel-agentgit-synchelm-syncoci-syncgcenode-askpass-sidecarhydration-controller |
ns-reconciler |
config-management-system |
Uma implantação de reconciliação de namespace é criada para cada objeto RepoSync. |
1 | ns-reconciler-.* |
3 - 51 |
reconcilerotel-agentgit-synchelm-syncoci-syncgcenode-askpass-sidecarhydration-controller |
otel-collector |
config-management-monitoring |
O coletor do OpenTelemetry é executado em todos os clusters com o
Config Sync ativado no objeto ConfigManagement.
Ele coleta métricas
dos componentes do Config Sync em execução nos
namespaces config-management-system e resource-group-system
e exporta essas métricas para o Prometheus e o Cloud Monitoring. |
1 | otel-collector-.* |
1 | otel-collector |
resource-group-controller-manager |
resource-group-system |
O ResourceGroup Controller é executado em todos os clusters com o Config Sync
ativado no objeto ConfigManagement. Ele monitora
objetos ResourceGroup e os atualiza com o status
de reconciliação atual de cada objeto no inventário. Um
objeto ResourceGroup é criado para cada
objeto RootSync e RepoSync para inventariar a
listagem de objetos aplicados pelo reconciliador da fonte da verdade. |
1 | resource-group-controller-manager-.* |
2 | managerotel-agent |
admission-webhook |
config-management-system |
O webhook de admissão do Config Sync é executado em cada cluster com a
prevenção contra deslocamento
ativada no objeto ConfigManagement. Ele monitora
solicitações da API Kubernetes e impede a modificação ou exclusão de
recursos gerenciados pelo Config Sync. O webhook de admissão do Config Sync é desativado por padrão. |
2 | admission-webhook-.* |
1 | admission-webhook |
1 Para saber quando esses contêineres são criados, consulte Contêineres do reconciliador
Solicitações de recursos de implantação
A tabela a seguir lista os requisitos de recursos do Kubernetes para componentes do Config Sync. Para mais informações, consulte Gerenciamento de recursos para pods e contêineres na documentação do Kubernetes.
As solicitações de recursos são as mesmas para todas as versões compatíveis do Config Sync.
| 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 Solicitações de recursos do reconciliador para mais detalhes. | |
1 O webhook de admissão tem duas réplicas. Se você usar o webhook de admissão e precisar calcular o total de solicitações de recursos, dobre o valor. O webhook de admissão é desativado por padrão.
Principais componentes
As seções a seguir exploram componentes importantes do Config Sync com mais detalhes.
Serviço de frota e o objeto ConfigSync
Na versão 1.20.0 e mais recentes do Config Sync, o serviço de frota do Hub gerencia os componentes do Config Sync diretamente no cluster:
O serviço de frota também gerencia o objeto ConfigSync no cluster. O serviço da frota atualiza a especificação do objeto ConfigSync com base nas entradas da API Google Cloud e o status para refletir o status dos componentes do Config Sync.
Para fazer mudanças na configuração de instalação do Config Sync, use a API Google Cloud . Mas é possível usar a API Google Cloud ou a API Kubernetes para monitorar a configuração e a integridade da instalação do Config Sync.
Gerenciador de reconciliação e reconciliadores
O gerenciador de reconciliação é responsável por criar e gerenciar os reconciliadores individuais que garantem que a configuração do cluster permaneça sincronizada.
O gerenciador de reconciliação cria um reconciliador raiz para cada objeto RootSync e
um reconciliador de namespace para cada objeto RepoSync. O Config Sync usa esse
design em vez de compartilhar um único reconciliador monolítico, porque ele melhora
a confiabilidade ao reduzir pontos únicos de falha e permite que reconciliadores
individuais sejam escalonados de forma independente.
Os reconciliadores de raiz e de namespace extraem automaticamente as configurações da fonte da verdade e as aplicam para aplicar o estado desejado no cluster.
Os diagramas a seguir mostram como o Reconciler Manager controla o ciclo de vida de cada reconciliador raiz e de namespace
Contêineres de reconciliador
Os contêineres específicos implantados nos pods do reconciliador dependem das escolhas de configuração feitas. A tabela a seguir explica melhor o que cada um desses contêineres de reconciliação faz e a condição que faz com que o Config Sync os crie:
| Nome do contêiner | Descrição | Condição |
|---|---|---|
reconciler |
Processa a sincronização e a correção de deslocamentos. | Sempre ativado. |
otel-agent |
Recebe métricas dos outros contêineres de reconciliação e as envia para o Coletor do OpenTelemetry. | Sempre ativado. |
git-sync |
Extrai as configurações do repositório Git para um diretório local que o contêiner de reconciliação pode ler. | Ativado quando spec.sourceType é git. |
helm-sync |
Extrai e renderiza gráficos do Helm do repositório de gráficos em um diretório local que o contêiner de reconciliação pode ler. | Ativado quando spec.sourceType é helm. |
oci-sync |
Extrai imagens OCI que contêm as configurações do registro de contêineres para um diretório local que o contêiner de reconciliação pode ler. | Ativado quando spec.sourceType é oci. |
gcenode-askpass-sidecar |
Armazena em cache as credenciais do Git do serviço de metadados do GKE para
uso pelo contêiner git-sync. |
Ativado quando spec.sourceType é git e
spec.git.auth é gcenode ou
gcpserviceaccount. |
hydration-controller |
Processa a criação de configurações do Kustomize em um diretório local que o contêiner de reconciliação pode ler. | Ativado quando a origem inclui um arquivo kustomize.yaml. |
Como mostrado na tabela anterior, normalmente é possível esperar uma contagem de contêineres de
três a cinco em cada pod de reconciliação. Os contêineres reconciler e otel-agent
estão sempre presentes. Especificar um tipo para a fonte da verdade
determina qual contêiner de sincronização é adicionado. Além disso, os contêineres hydration-controller
e gcenode-askpass-sidecar são criados se você tiver feito as
mudanças de configuração mencionadas na tabela.
Solicitações de recursos 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 mais informações sobre esses contêineres, consulte Contêineres do reconciliador.
As solicitações de recursos são as mesmas para todas as versões compatíveis do Config Sync.
A tabela a seguir lista as solicitações de recursos para clusters padrão:
| 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 |
A tabela a seguir lista as solicitações de recursos para clusters do Autopilot:
| 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 |
Para mais informações sobre como substituir os limites e as solicitações de recursos padrão, consulte Substituir solicitações e limites de recursos.
Versões Helm e Kustomize agrupadas
O Config Sync aproveita os executáveis Helm e Kustomize para renderizar as configurações. 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.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 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 Sincronizar gráficos do Helm no Artifact Registry.
Controlador e objetos do ResourceGroup
Os reconciliadores de raiz e de namespace criam um objeto de inventário ResourceGroup para
cada objeto RootSync e RepoSync que você configurar. Cada objeto ResourceGroup
contém uma lista de objetos sincronizados com o cluster da fonte de verdade pelo
reconciliador para o objeto RootSync ou RepoSync. O controlador ResourceGroup
observa todos os objetos no objeto ResourceGroup e
atualiza o status do objeto ResourceGroup com o status de reconciliação
atual dos objetos sincronizados. Isso permite verificar o status do objeto
ResourceGroup
para ter uma visão geral da sincronização, em vez de consultar o status de
cada objeto individualmente.
Os objetos ResourceGroup têm o mesmo nome e namespace do objeto
RootSync ou RepoSync correspondente. Por exemplo, para o objeto RootSync com o nome
root-sync no namespace config-management-system, o objeto
ResourceGroup correspondente também é root-sync in the
config-management-system no namespace
Não crie nem modifique objetos ResourceGroup, porque isso pode interferir na
operação do Config Sync.
Webhook de admissão
O webhook de admissão do Config Sync é criado ao ativar a prevenção de deslocamento. A prevenção de deslocamento intercepta proativamente as solicitações de modificação, garantindo que elas estejam alinhadas com a fonte de verdade antes de permitir mudanças.
Se você não ativar a prevenção de deslocamento, o Config Sync ainda vai usar um mecanismo de autocorreção para reverter o deslocamento da configuração. Com a autocorreção, o Config Sync monitora continuamente os objetos gerenciados e reverte automaticamente todas as mudanças que se desviam do estado pretendido.
Objetos RootSync e RepoSync
Os objetos RootSync configuram o Config Sync para criar um reconciliador raiz que
monitora a fonte de verdade especificada e aplica objetos dessa origem ao
cluster. Por padrão, o reconciliador raiz de cada objeto RootSync tem a permissão cluster-admin. Com
essa permissão padrão, os reconciliadores raiz podem sincronizar recursos com escopo de cluster e
de namespace. Se necessário, você pode mudar essas permissões
configurando os campos
spec.override.roleRefs. Os objetos RootSync foram criados para uso dos administradores de cluster.
Os objetos RepoSync configuram o Config Sync para criar um reconciliador de namespace
que observa a origem especificada e aplica objetos dessa origem a um
namespace específico no cluster. Os reconciliadores de namespace podem sincronizar qualquer
recurso com escopo de namespace nesse namespace com permissões personalizadas especificadas pelo usuário. Os objetos RepoSync foram criados para uso pelos locatários do namespace.
Como o serviço da frota gerencia objetos RootSync
Quando você instala o Config Sync com o console Google Cloud , a Google Cloud CLI, o Config Connector ou o Terraform, ele é gerenciado pelo serviço da frota com base nas entradas da API Google Cloud .
Quando a instalação do Config Sync é gerenciada pelo serviço da frota, você pode
gerenciar o objeto RootSync inicial, chamado
root-sync. Isso permite inicializar o GitOps no cluster sem precisar
aplicar nada manualmente. Se você decidir não usar o
serviçoda frota para gerenciar o objeto RootSync inicial, ainda poderá aplicar
qualquer objeto RootSync e RepoSync diretamente ao cluster.
O objeto RootSync chamado root-sync é criado com base nas entradas da
APIGoogle Cloud , especificamente na seção spec.configSync da
API config-management. Como essa API
expõe apenas um subconjunto dos campos
RootSync,
esses campos são considerados gerenciados no root-sync, enquanto os outros campos
são considerados não gerenciados. Os campos gerenciados só podem ser editados usando a
APIGoogle Cloud . Os campos não gerenciados
podem ser editados usando o kubectl,
ou qualquer outro cliente do Kubernetes.
Outros objetos RootSync e RepoSync
Para criar outros objetos RootSync ou RepoSync, use a ferramenta de linha de comando kubectl
ou outro cliente do Kubernetes. Também é possível usar o objeto
root-sync inicial para gerenciar outros objetos RootSync ou RepoSync com
o GitOps, adicionando os manifestos YAML à fonte da verdade que o
root-sync está configurado para sincronizar. Esse método
não pode ser usado para gerenciar a configuração do root-sync inicial, porque alguns dos
campos dele são gerenciados pelo serviço da frota. Para gerenciar o objeto root-sync com o GitOps, use o Config Connector ou o Terraform. Para mais informações sobre a criação de outros objetos RootSync e
RepoSync, consulte
Configurar a sincronização usando mais de uma fonte de verdade.
A seguir
- Talvez você queira monitorar os componentes do Config Sync ou verificar os registros deles. Para uma introdução, consulte Usar monitoramento e registros.
- Saiba mais sobre as solicitações de recursos para componentes do Config Sync.