Esta página apresenta a arquitetura do Config Sync, incluindo os componentes alojados 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. A aprendizagem sobre a arquitetura pode dar-lhe uma compreensão mais profunda da sincronização de configuração e pode ajudar a depurar e corrigir problemas que encontrar.
A secção seguinte mostra a arquitetura do Config Sync, incluindo os respetivos componentes e dependências, tanto no Google Cloud como no seu cluster do GKE:
O
serviço Fleet
gere os componentes do Config Sync diretamente no seu cluster, sem o
operador ConfigManagement antigo nem o objeto ConfigManagement. Tem de atualizar manualmente o Config Sync conforme necessário.
Existem vários passos para instalar o Config Sync e cada um destes passos implementa componentes adicionais no seu cluster:
A ativação da sincronização de configuração no cluster adiciona os seguintes componentes:
- A
ConfigSyncdefinição de recursos personalizados (CRD) - Um objeto
ConfigSynccom o nomeconfig-sync. - O Reconciler Manager numa implementação denominada
reconciler-manager. - O controlador ResourceGroup numa implementação denominada
resource-group-controller-manager. - O OpenTelemetry Collector num
implementação com o nome
otel-collector. - Opcional: o webhook de admissão da sincronização de configuração numa implementação denominada
admission-webhook. O webhook de admissão do Config Sync só é instalado se ativar a prevenção de desvio.
Estes recursos e objetos são criados automaticamente quando instala o Config Sync e não devem ser modificados diretamente.
- A
A criação de objetos
RootSynceRepoSyncadiciona os seguintes componentes:- Para cada objeto
RootSync, uma implementação do reconciliador denominadaroot-reconciler-ROOTSYNC_NAME. Para o objetoRootSyncdenominadoroot-sync, a implementação do reconciliador denomina-seroot-reconciler. - Para cada objeto
RepoSync, uma implementação do reconciliador denominadans-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH. Para o objetoRepoSyncdenominadorepo-sync, o reconciliador Deployment tem o nomens-reconciler.
- Para cada objeto
Implementações, pods e contentores do Config Sync
A tabela seguinte fornece mais informações sobre a implementação, os pods e os contentores do Config Sync:
| Nome da implementação | Espaço de nomes da implementação | Descrição da implementação | Número de réplicas | Expressão regular do nome do agrupamento | Número de contentores | Nomes dos contentores |
|---|---|---|---|---|---|---|
reconciler-manager |
config-management-system |
O Reconciler Manager é executado em todos os clusters com o Config Sync ativado no objeto ConfigManagement. Monitoriza os objetos RootSync e RepoSync e gere uma implementação do reconciliador para cada um. |
1 | reconciler-manager-.* |
2 | reconciler-managerotel-agent |
root-reconciler |
config-management-system |
É criada uma implementação do reconciliador raiz para cada objeto RootSync. |
1 | root-reconciler-.* |
3 - 51 |
reconcilerotel-agentgit-synchelm-syncoci-syncgcenode-askpass-sidecarhydration-controller |
ns-reconciler |
config-management-system |
É criada uma implementação do reconciliador do espaço de nomes para cada objeto RepoSync. |
1 | ns-reconciler-.* |
3 - 51 |
reconcilerotel-agentgit-synchelm-syncoci-syncgcenode-askpass-sidecarhydration-controller |
otel-collector |
config-management-monitoring |
O OpenTelemetry Collector é executado em todos os clusters com o Config Sync ativado no objeto ConfigManagement.
Recolhe métricas
dos componentes do Config Sync em execução nos espaços de nomes
config-management-system e resource-group-system
e exporta estas métricas para o Prometheus e o Cloud Monitoring. |
1 | otel-collector-.* |
1 | otel-collector |
resource-group-controller-manager |
resource-group-system |
O controlador ResourceGroup é executado em todos os clusters com o Config Sync ativado no objeto ConfigManagement. Monitoriza os objetos ResourceGroup e atualiza-os com o estado de conciliação atual de cada objeto no respetivo inventário. É criado um objeto ResourceGroup para cada objeto RootSync e RepoSync para inventariar a lista de objetos aplicados pelo reconciliador a partir da fonte de verdade. |
1 | resource-group-controller-manager-.* |
2 | managerotel-agent |
admission-webhook |
config-management-system |
O webhook de admissão da sincronização de configuração é executado em cada cluster com a
prevenção de desvio
ativada no objeto ConfigManagement. Monitoriza os pedidos da API Kubernetes e impede a modificação ou a eliminação de recursos geridos pela sincronização de configuração. O webhook de admissão do Config Sync está desativado por predefinição. |
2 | admission-webhook-.* |
1 | admission-webhook |
1 Para ver detalhes sobre quando estes contentores são criados, consulte o artigo Contentores de conciliação.
Pedidos de recursos de implementação
A tabela seguinte lista os requisitos de recursos do Kubernetes para os componentes do Config Sync. Para mais informações, consulte o artigo Gestão de recursos para pods e contentores na documentação do Kubernetes.
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 os pedidos de recursos do reconciliador para ver detalhes. | |
1 O webhook de admissão tem duas réplicas. Se usar o webhook de admissão e precisar de calcular os pedidos de recursos totais, duplique o valor. O webhook de admissão está desativado por predefinição.
Componentes principais
As secções seguintes exploram componentes importantes da sincronização de configuração com mais detalhe.
Serviço de frota e o objeto ConfigSync
Na versão 1.20.0 e posteriores do Config Sync, o serviço Hub Fleet gere diretamente os componentes do Config Sync no seu cluster:
O serviço Fleet também gere o objeto ConfigSync no seu cluster. O serviço Fleet atualiza a especificação do objeto ConfigSync com base nas suas entradas na API Google Cloud e o respetivo estado para refletir o estado dos componentes do Config Sync.
Para fazer alterações à configuração de instalação do Config Sync, tem de usar a Google Cloud API. No entanto, pode usar a API ou a API Kubernetes para monitorizar a configuração e o estado de funcionamento da instalação do Config Sync. Google Cloud
Gestor de conciliação e conciliadores
O Reconciler Manager é responsável pela criação e gestão dos reconciliadores individuais que garantem que a configuração do cluster permanece sincronizada.
O Reconciler Manager cria um reconciliador raiz para cada objeto RootSync e um reconciliador de espaço de nomes para cada objeto RepoSync. A sincronização de configuração usa este design em vez de partilhar um reconciliador monolítico único porque melhora a fiabilidade ao reduzir os pontos únicos de falha e permite que os reconciliadores individuais sejam dimensionados de forma independente.
Os reconciliadores de raiz e espaço de nomes obtêm automaticamente as configurações da sua fonte de dados fidedignos e aplicam-nas para impor o estado que quer no seu cluster.
Os diagramas seguintes mostram como o Reconciler Manager processa o controlo do ciclo de vida de cada reconciliador raiz e reconciliador de espaço de nomes:
Contentores de conciliação
Os contentores específicos implementados nos pods do reconciliador dependem das escolhas de configuração que fizer. A tabela seguinte explica o que cada um destes contentores de reconciliação faz e a condição que faz com que o Config Sync os crie:
| Nome do contentor | Descrição | Condição |
|---|---|---|
reconciler |
Trata da sincronização e da correção de desvios. | Sempre ativada. |
otel-agent |
Recebe métricas dos outros contentores de conciliação e envia-as para o OpenTelemetry Collector. | Sempre ativada. |
git-sync |
Extrai as configurações do seu repositório Git para um diretório local que o contentor do reconciliador pode ler. | Ativada quando spec.sourceType está git. |
helm-sync |
Extrai e renderiza gráficos Helm do seu repositório de gráficos para um diretório local que o contentor do reconciliador pode ler. | Ativada quando spec.sourceType está helm. |
oci-sync |
Extrai imagens OCI que contêm as suas configurações do registo de contentores para um diretório local que o contentor de reconciliação pode ler. | Ativada quando spec.sourceType está oci. |
gcenode-askpass-sidecar |
Coloca em cache as credenciais do Git do serviço de metadados do GKE para utilização pelo contentor 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 num diretório local que o contentor do reconciliador pode ler. | Ativada quando a origem inclui um ficheiro kustomize.yaml. |
Conforme mostrado na tabela anterior, normalmente, pode esperar uma contagem de contentores de três a cinco em cada pod de reconciliação. Os contentores reconciler e otel-agent
estão sempre presentes. A especificação de um tipo para a sua fonte de dados fidedignos
determina o contentor de sincronização que é adicionado. Além disso, os contentores hydration-controller
e gcenode-askpass-sidecar são criados se tiver feito as alterações de configuração mencionadas na tabela.
Pedidos de recursos 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 mais informações sobre estes contentores,
consulte o artigo Contentores de conciliação.
Os pedidos de recursos são os mesmos para todas as versões suportadas do Config Sync.
A tabela seguinte lista os pedidos de recursos para clusters padrão:
| 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 |
A tabela seguinte lista os pedidos de recursos para clusters do Autopilot:
| 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 mais informações sobre como substituir os pedidos de recursos e os limites predefinidos, consulte o artigo Substituir pedidos de recursos e limites.
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. A tabela seguinte fornece 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 obter informações sobre a utilização da API Helm, consulte o artigo Sincronize gráficos Helm a partir do Artifact Registry.
Controlador ResourceGroup e objetos ResourceGroup
Os reconciliadores de raiz e espaço de nomes criam um objeto de inventário ResourceGroup para cada objeto RootSync e RepoSync que configurar. Cada objeto ResourceGroup contém uma lista de objetos sincronizados com o cluster a partir da fonte de verdade pelo reconciliador para esse objeto RootSync ou RepoSync. O ResourceGroup
Controller monitoriza todos os objetos no objeto ResourceGroup e
atualiza o estado do objeto ResourceGroup com o estado de conciliação
atual dos objetos sincronizados. Isto permite-lhe verificar o estado do ResourceGroup
objeto
para uma vista geral do estado de sincronização, em vez de ter de consultar o estado de
cada objeto individualmente.
Os objetos ResourceGroup têm o mesmo nome e espaço de nomes que o objeto RootSync ou RepoSync correspondente. Por exemplo, para o objeto RootSync com o nome root-sync no espaço de nomes config-management-system, o objeto ResourceGroup correspondente também tem o nome root-sync no espaço de nomes config-management-system.
Não crie nem modifique objetos ResourceGroup, uma vez que isso pode interferir com o funcionamento do Config Sync.
Webhook de admissão
O Webhook de admissão do Config Sync é criado quando ativa a prevenção de desvios. A prevenção de desvio intercepta proativamente os pedidos de modificação, garantindo que estão alinhados com a fonte de verdade antes de permitir alterações.
Se não ativar a prevenção de desvio, a sincronização de configuração continua a usar um mecanismo de autocorreção para reverter o desvio de configuração. Com a autorrecuperação, o Config Sync monitoriza continuamente os objetos geridos e reverte automaticamente quaisquer alterações que se desviem do estado pretendido.
Objetos RootSync e RepoSync
Os objetos RootSync configuram o Config Sync para criar um reconciliador raiz que
monitoriza a origem de informação especificada e aplica objetos dessa origem ao
cluster. Por predefinição, o reconciliador raiz de cada objeto RootSync tem autorização cluster-admin. Com esta autorização predefinida, os reconciliadores raiz podem sincronizar recursos com âmbito de cluster e com âmbito de espaço de nomes. Se necessário, pode alterar estas autorizações
configurando os campos
spec.override.roleRefs. Os objetos RootSync são concebidos para utilização por administradores de clusters.
Os objetos RepoSync configuram o Config Sync para criar um reconciliador de espaço de nomes que monitoriza a origem especificada e aplica objetos dessa origem a um espaço de nomes específico no cluster. Os reconciliadores do espaço de nomes podem sincronizar quaisquer recursos com âmbito do espaço de nomes nesse espaço de nomes com autorizações personalizadas especificadas pelo utilizador. Os objetos RepoSync são concebidos para utilização por inquilinos do espaço de nomes.
Como o serviço Fleet gere objetos RootSync
Quando instala o Config Sync com a Google Cloud consola, a CLI gcloud, o Config Connector ou o Terraform, o Config Sync é gerido pelo serviço Fleet, com base nas suas entradas na Google Cloud API.
Quando a instalação do Config Sync é gerida pelo serviço Fleet, também pode fazer com que este faça a gestão do objeto RootSync inicial, denominado root-sync. Isto permite-lhe iniciar o GitOps no seu cluster sem ter de aplicar manualmente nada diretamente ao cluster. Se decidir que o serviço Fleet não deve gerir o objeto RootSync inicial, pode continuar a aplicar os objetos RootSync e RepoSync que quiser diretamente ao cluster.
O objeto RootSync com o nome root-sync é criado com base nas suas entradas na APIGoogle Cloud , especificamente na secção spec.configSync da API config-management apply. Uma vez que esta API expõe apenas um subconjunto dos campos RootSync, esses campos são considerados geridos no root-sync, enquanto os outros campos são considerados não geridos. Só é possível editar os campos geridos através daGoogle Cloud API. Os campos não geridos podem ser editados através do kubectl ou de qualquer outro cliente do Kubernetes.
Objetos RootSync e RepoSync adicionais
Para criar objetos RootSync ou RepoSync adicionais, pode usar a ferramenta de linha de comandos kubectl ou outro cliente do Kubernetes. Também pode usar o objeto
root-sync inicial para gerir objetos RootSync ou RepoSync adicionais com o
GitOps, adicionando os respetivos manifestos YAML à fonte de verdade a partir da qual o
root-sync está configurado para sincronizar. Não é possível usar este método para gerir a configuração do root-sync inicial, porque alguns dos respetivos campos são geridos pelo serviço de frota. Para gerir o objeto root-sync com o GitOps, use o Config Connector ou o Terraform. Para mais informações sobre a criação de objetos RootSync e RepoSync adicionais, consulte o artigo Configure a sincronização a partir de mais de uma fonte de dados fidedigna.
O que se segue?
- Recomendamos que monitorize os componentes do Config Sync ou verifique os respetivos registos. Para uma introdução, consulte o artigo Use a monitorização e os registos.
- Saiba mais sobre os pedidos de recursos para componentes do Config Sync.