Arquitetura do Config Sync

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

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

Diagrama que mostra a relação entre objetos e recursos do Config Sync

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

Há várias etapas para instalar o Config Sync, e cada uma delas implanta outros componentes 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, na sigla em inglês) ConfigManagement e o objeto chamado config-management.
    • O gerenciador de reconciliação 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 e não é necessário modificá-los.

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

    • Para cada RootSync, uma implantação de reconciliador chamada root-reconciler-ROOTSYNC_NAME.
    • Para cada RepoSync, uma implantação de reconciliador chamada 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 de 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 observa o objeto ConfigManagement e gerencia componentes do Config Sync, como o Reconciler Manager e o Coletor do OpenTelemetry. 1 config-management-operator-.* 1
  • manager
    		•
    reconciler-manager config-management-system O Reconciler Manager é executado em todos os clusters com o Config Sync ativado no objeto ConfigManagement. Ele observa objetos RootSync e RepoSync e gerencia uma implantação do reconciliador para cada um. 1 reconciler-manager-.* 2
  • reconciler-manager
  • otel-agent
    		•
    root-reconciler config-management-system Uma implantação do reconciliador raiz é criada para cada objeto RootSync. 1 root-reconciler-.* 3 a 51
  • reconciler
  • otel-agent
  • git-sync
  • helm-sync
  • oci-sync
  • gcenode-askpass-sidecar
  • hydration-controller
    		•
    ns-reconciler config-management-system Uma implantação do reconciliador de namespace é criada para cada objeto RepoSync. 1 ns-reconciler-.* 3 a 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 as exporta 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. Ele observa 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 lista de objetos aplicados pelo reconciliador usando a 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 de desvio ativada no objeto ConfigManagement. Ele monitora as 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 detalhes sobre quando esses contêineres são criados, consulte Reconciliação de contêineres.

    Principais componentes

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

    Operador e objeto ConfigManagement

    O ConfigManagement Operator observa o objeto ConfigManagement e 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, o ConfigManagement Operator também requer permissões cluster-admin.

    Reconciliador e reconciliadores

    O Reconciler Manager é responsável por criar e gerenciar os reconciliadores individuais que garantem que a configuração do cluster permaneça sincronizada.

    O Reconciler Manager 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 melhora a confiabilidade ao reduzir pontos únicos de falha e permite que reconciliadores individuais sejam escalonados de maneira independente.

    Os reconciliadores raiz e de namespace buscam automaticamente configurações da fonte da verdade e as aplicam para aplicar o estado que você quer no cluster.

    Os diagramas a seguir mostram como o Reconciler Manager lida com o controle do ciclo de vida de cada reconciliador raiz e reconciliador de namespace:

    Diagrama que mostra como o gerenciador de reconciliação controla o reconciliador raiz Diagrama que mostra como o reconciliador controla o reconciliador de namespace

    Contêineres do reconciliação

    Os contêineres específicos implantados nos pods reconciliadores dependem das escolhas de configuração feitas por você. A tabela a seguir explica mais sobre o que cada um desses contêineres reconciliadores faz e a condição que faz com que o Config Sync os crie:

    Nome do contêiner Descrição Condição
    reconciler Lida com a sincronização e a correção de desvios. Sempre ativado.
    otel-agent Recebe métricas dos outros contêineres reconciliadores e as envia ao Coletor do OpenTelemetry. Sempre ativado.
    git-sync Extrai as configurações do seu repositório Git para um diretório local que o contêiner do reconciliador possa ler. Ativado quando spec.sourceType for git.
    helm-sync Extrai e renderiza gráficos do Helm do seu repositório de gráficos para um diretório local que o contêiner do reconciliador possa ler. Ativado quando spec.sourceType for helm.
    oci-sync Extrai imagens OCI que contêm suas configurações do Container Registry para um diretório local que o contêiner do reconciliador possa ler. Ativado quando spec.sourceType for oci.
    gcenode-askpass-sidecar Armazena em cache as credenciais Git do serviço de metadados do GKE para uso pelo contêiner git-sync. Ativada quando spec.sourceType é git e spec.git.auth é gcenode ou gcpserviceaccount.
    hydration-controller Processa a criação de configurações do Kustomize para um diretório local que o contêiner de reconciliação pode ler. Ativado quando a origem inclui um arquivo kustomize.yaml.

    Conforme mostrado na tabela anterior, normalmente há uma contagem de três a cinco contêineres em cada pod do reconciliador. Os contêineres reconciler e otel-agent estão sempre presentes. A especificação de um tipo para sua fonte de verdade define qual contêiner de sincronização será adicionado. Além disso, os contêineres hydration-controller e gcenode-askpass-sidecar serão criados se você fizer as mudanças de configuração mencionadas na tabela.

    Objetos ResourceGroup Controller e ResourceGroup

    Os reconciliadores raiz e de namespace criam um objeto de inventário ResourceGroup para cada objeto RootSync e RepoSync configurado. 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. Em seguida, o controlador ResourceGroup monitora 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 que você verifique o status do objeto ResourceGroup para ter uma visão geral do status de sincronização, em vez de ter que consultar o status de cada objeto individual.

    Os objetos ResourceGroup têm o mesmo nome e namespace que os objetos RootSync ou RepoSync correspondentes. Por exemplo, para o objeto RootSync com o nome root-sync no namespace config-management-system, o objeto ResourceGroup correspondente também é chamado de root-sync no namespace config-management-system.

    Não crie ou 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 quando você ativa a prevenção de desvio. A prevenção contra desvios intercepta proativamente as solicitações de modificação, garantindo que elas estejam alinhadas à fonte de verdade antes de permitir mudanças.

    Se você não ativar a prevenção de desvio, o Config Sync ainda vai usar um mecanismo de autocorreção para reverter o desvio de configuração. Com a autocorreção, o Config Sync monitora objetos gerenciados continuamente e reverte automaticamente todas as mudanças que desviam do estado pretendido.

    Objetos RootSync e RepoSync

    Os objetos RootSync configuram o Config Sync para criar um reconciliador raiz que observa a fonte de verdade especificada e aplica objetos dela 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, é possível alterar essas permissões configurando os campos spec.override.roleRefs. Os objetos RootSync são projetados 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 são projetados para uso por locatários de namespace.

    Como o serviço Fleet gerencia objetos RootSync

    Quando você instala o Config Sync com o console do Google Cloud, a Google Cloud CLI, o Config Connector ou o Terraform, o Config Sync é gerenciado pelo serviço Fleet, com base nas entradas da API Google Cloud.

    Quando a instalação do Config Sync é gerenciada pelo serviço Fleet, também é possível fazer com que ele gerencie seu objeto RootSync inicial, chamado root-sync. Isso permite inicializar o GitOps no cluster sem precisar aplicar manualmente nada ao cluster diretamente. Se você decidir não que o serviço da frota gerencie seu objeto RootSync inicial, ainda será possível aplicar quaisquer objetos RootSync e RepoSync que você quiser diretamente ao cluster.

    O objeto RootSync chamado root-sync é criado com base nas suas entradas para a API do Google Cloud, especificamente a seção spec.configSync da API de aplicação de gerenciamento de configuração. Como essa API expõe apenas um subconjunto dos campos RootSync, eles são considerados gerenciados no root-sync, enquanto os outros 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 kubectl ou qualquer outro cliente do Kubernetes. Para ver um exemplo que mostra como exportar o YAML root-sync, editá-lo localmente e aplicá-lo novamente, consulte Criar e editar um arquivo de configuração RootSync.

    Para instalações manuais, você gerencia o Config Sync com a ferramenta de linha de comando 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 GitOps, adicionando os manifestos YAML deles à fonte de verdade da qual o root-sync está configurado para sincronizar. Este método não pode ser usado para gerenciar a configuração da root-sync inicial, porque alguns dos campos são gerenciados pelo serviço da frota. Para gerenciar o objeto root-sync com GitOps, use o Config Connector ou o Terraform. Para saber mais sobre como criar mais objetos RootSync e RepoSync, consulte Configurar a sincronização de mais de uma fonte de verdade.

    A seguir