Arquitetura do Config Sync

Nesta página, apresentaremos a arquitetura do Config Sync. Aprender sobre os componentes criados pelo Config Sync pode ajudar você a entender melhor o serviço e a depurar e corrigir os problemas encontrados.

O diagrama a seguir mostra a arquitetura do Config Sync e os recursos relacionados em um cluster da edição Enterprise do Google Kubernetes Engine (GKE):

O diagrama mostra a relação entre os objetos e recursos do Config Sync

Neste diagrama, o usuário cria uma fonte de verdade e instala o Config Sync usando o Gerenciador de recursos.

Há várias etapas para instalar o Config Sync, e cada uma delas implanta componentes adicionais no cluster:

  1. Ativar o Config Sync no cluster adiciona os seguintes componentes:

    • O ConfigManagement Operator em uma implantação chamada config-management-operator.
    • A definição de recurso personalizado (CRD) ConfigManagement e o objeto chamado config-management.
    • 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.

    A maioria desses recursos e objetos é criada automaticamente ao instalar o Config Sync. Não é necessário modificá-los.

  2. A criação dos objetos RootSync e RepoSync adiciona os seguintes componentes:

    • Para cada RootSync, uma implantação de reconciliação com o nome root-reconciler-ROOTSYNC_NAME.
    • Para cada RepoSync, uma implantação de reconciliação com o nome ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH.

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
config-management-operator config-management-system O ConfigManagement Operator é executado em todos os clusters com o Config Sync instalado. Ele monitora o objeto ConfigManagement e gerencia componentes do Config Sync, como o gerenciador de reconciliação e o coletor do OpenTelemetry. 1 config-management-operator-.* 1
  • manager
    		•
    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-manager
  • otel-agent
    		•
    root-reconciler config-management-system Uma implantação de reconciliação raiz é criada para cada objeto RootSync. 1 root-reconciler-.* 3 - 51
  • reconciler
  • otel-agent
  • git-sync
  • helm-sync
  • oci-sync
  • gcenode-askpass-sidecar
  • hydration-controller
    		•
    ns-reconciler config-management-system Uma implantação de reconciliação de namespace é criada para cada objeto RepoSync. 1 ns-reconciler-.* 3 - 51
  • reconciler
  • otel-agent
  • git-sync
  • helm-sync
  • oci-sync
  • gcenode-askpass-sidecar
  • hydration-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
  • reconciler-manager
  • otel-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.

    Principais componentes

    As seções a seguir exploram componentes importantes do Config Sync com mais detalhes.

    Operador e objeto do ConfigManagement

    O ConfigManagement Operator observa o objeto ConfigManagement, cria e gerencia outros componentes necessários para que o Config Sync funcione:

    Atuação do operador

    Como o ConfigManagement Operator instala alguns componentes que exigem permissões cluster-admin, ele também exige permissões cluster-admin.

    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:

    Diagrama que mostra como o gerenciador de reconciliação controla o reconciliador raiz Diagrama que mostra como o gerenciador de reconciliação controla o reconciliador 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.

    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 do Google Cloud, a CLI do Google Cloud, 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 API Google 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 API Google 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 saber mais sobre a criação de outros objetos RootSync e RepoSync, consulte Configurar a sincronização usando mais de uma fonte de verdade.

    A seguir