Sobre as fontes da verdade

Este documento explica os diferentes tipos de fontes da verdade que o Config Sync pode sincronizar.

Um conceito fundamental nos fluxos de trabalho do GitOps é a fonte da verdade, um repositório central em que os arquivos de configuração são armazenados. Um arquivo de configuração geralmente é um arquivo YAML ou JSON que define recursos do Kubernetes. Normalmente, você aplica manualmente objetos do Kubernetes com a ferramenta de linha de comando kubectl, mas o Config Sync pode aplicar automaticamente esses recursos de uma única fonte de verdade, como um repositório Git. Em seguida, o Config Sync monitora a fonte da verdade especificada e aplica automaticamente as mudanças aos clusters.

O Config Sync pode sincronizar arquivos de configuração de três tipos diferentes de fontes: repositórios Git, imagens da Open Container Initiative (OCI) e gráficos do Helm. Este documento explica cada um desses tipos de origem e como o Config Sync interage com eles. A leitura deste documento pode ajudar você a escolher a melhor opção de origem para seu fluxo de trabalho e ambiente.

Repositórios Git

O Git é uma tecnologia amplamente adotada para controle de versões e colaboração. Com o Git, é possível organizar o repositório da maneira que melhor atende às suas necessidades e aproveitar os benefícios do controle de versões e ramificação, se necessário. Como o Git é uma tecnologia madura e amplamente adotada, você tem várias opções de provedores e ferramentas.

Ao configurar o Config Sync com um repositório Git como fonte de verdade, o Config Sync usa um contêiner git-sync no pod reconciliador para extrair configs do repositório Git. É possível configurar o URL, a ramificação e a revisão (commit ou tag) do repositório para ter mais controle sobre onde extrair as configurações no repositório Git.

Exemplo de configuração do RootSync

O exemplo a seguir mostra um manifesto RootSync que sincroniza de um repositório Git:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: https://github.com/example/my-configs.git
    revision: main
    dir: cluster-configs
    auth: none # replace with your authentication method such as ssh or token
    period: 60s

Essa configuração define o Config Sync para sincronizar manifestos de um repositório Git. O Config Sync monitora o diretório cluster-configs na ramificação main do repositório https://github.com/example/my-configs.git, verificando atualizações a cada 60 segundos sem usar autenticação.

Exemplo de caso de uso: gerenciamento centralizado

Imagine que você é um administrador de plataforma que quer usar um repositório Git para aplicar políticas de referência em todos os clusters de uma frota. Nesse cenário, você pode armazenar NetworkPolicies, RoleBindings e ResourceQuotas padrão em um repositório Git central chamado standard-configs. Quando um novo cluster é provisionado, o Config Sync é configurado para sincronizar do repositório standard-configs, ajudando a garantir que todos os clusters atendam aos padrões organizacionais desde o início.

Imagens OCI

As imagens OCI são um formato padrão para empacotar aplicativos e dependências. Essa abordagem trata suas configurações como artefatos, semelhante a como você trataria imagens de contêiner. Essa abordagem oferece vantagens como imutabilidade e desempenho mais rápido em grande escala. Com o OCI, é possível usar a infraestrutura e as ferramentas de imagens de contêineres, como o Artifact Registry, para gerenciar suas imagens e a federação de identidade da carga de trabalho do GKE para simplificar a autenticação.

Usar a OCI como uma origem de configuração geralmente exige um processo separado para criar os arquivos de configuração em uma imagem da OCI e enviá-la para uma plataforma de registro como o Artifact Registry. Essa abordagem pode ser menos legível para humanos do que configurações armazenadas como arquivos em um repositório Git.

Ao configurar o Config Sync com uma imagem OCI como fonte de verdade, o Config Sync usa um contêiner oci-sync no pod reconciliador para extrair do registro a imagem OCI que contém as configurações.

Exemplo de configuração do RootSync

O exemplo a seguir mostra um manifesto RootSync que sincroniza uma imagem OCI armazenada no Artifact Registry:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: oci
  sourceFormat: unstructured
  oci:
    image: us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0
    dir: .
    auth: k8sserviceaccount

Essa configuração define o Config Sync para sincronizar com uma imagem OCI. O Config Sync extrai a imagem us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0 do Artifact Registry usando uma conta de serviço do Kubernetes para autenticação.

Exemplo de caso de uso: integração de pipeline de CI/CD

Imagine que você queira integrar a criação de imagens do OCI ao pipeline de CI/CD da sua organização. Quando as mudanças nos arquivos de configuração são mescladas, é possível configurar o pipeline para executar testes de validação (como o comando nomos vet), criar os arquivos YAML em uma imagem OCI e enviar a imagem para o Artifact Registry. O Config Sync detectaria e aplicaria automaticamente a nova versão da imagem aos clusters, garantindo um lançamento validado e versionado de todas as mudanças de configuração.

Gráficos do Helm

O Helm é um gerenciador de pacotes conhecido para o Kubernetes, que usa um formato de pacote chamado de gráficos. O Config Sync pode buscar, renderizar e sincronizar recursos definidos em gráficos do Helm.

O Helm oferece uma maneira consistente de empacotar e reutilizar aplicativos do Kubernetes. Você pode usar modelos ou gráficos Helm pré-criados para configurações consistentes e reutilizáveis.

Se você ainda não conhece o Helm, o processo de criação de modelos e lançamento pode adicionar mais complexidade ao seu pipeline de gerenciamento de configuração.

Quando você configura o Config Sync com um gráfico Helm como fonte da verdade, o Config Sync usa um contêiner helm-sync no pod reconciliador para extrair gráficos de um repositório Helm (como o Artifact Registry) ou um repositório Git e, em seguida, renderiza o gráfico para produzir manifestos do Kubernetes. Como alternativa, use o Config Sync com o Kustomize para renderizar gráficos do Helm. Para mais informações sobre essa abordagem, consulte Usar o Config Sync com o Kustomize e o Helm.

Exemplo de configuração do RootSync

O exemplo a seguir mostra um manifesto RootSync que sincroniza de um gráfico do Helm armazenado no Artifact Registry:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: helm
  helm:
    repo: oci://us-central1-docker.pkg.dev/my-project/my-helm-repo
    chart: my-chart
    version: 1.2.0
    auth: gcpserviceaccount
    gcpServiceAccountEmail: my-service-account@my-project.iam.gserviceaccount.com
    releaseName: my-chart-release
    namespace: my-app-namespace # Namespace where the chart resources will be deployed

Essa configuração define o Config Sync para sincronizar um gráfico do Helm de um repositório OCI. O Config Sync busca a versão 1.2.0 do gráfico my-chart no repositório oci://us-central1-docker.pkg.dev/my-project/my-helm-repo e faz a autenticação com a conta de serviço my-service-account@my-project.iam.gserviceaccount.com. Ele implanta os recursos do gráfico no namespace my-app-namespace com o nome de lançamento my-chart-release.

Exemplo de caso de uso: implantação de um aplicativo de terceiros

Imagine que você faz parte de uma equipe de aplicativos que quer implantar o Prometheus em um cluster. É possível configurar o Config Sync para extrair de um gráfico do Helm pré-criado que implanta o Prometheus. Em vez de executar comandos do Helm manualmente, você define a origem, a versão e qualquer values personalizado do gráfico nos objetos RootSync ou RepoSync do Config Sync. Em seguida, o Config Sync mantém a implantação sincronizada com a versão e as configurações especificadas do gráfico.

Como escolher um tipo de origem

O melhor tipo de fonte depende das ferramentas, fluxos de trabalho e preferências atuais da sua equipe. Use esta tabela para entender as principais características de cada tipo de fonte e tomar uma decisão informada:

Recurso Repositório do Git Imagem OCI Gráfico do Helm
Ideal para Gerenciamento de configuração de uso geral, flexibilidade e legibilidade para humanos Configurações imutáveis e com controle de versão que aproveitam a infraestrutura de contêineres Empacotar e distribuir aplicativos complexos
Mutabilidade Mutável Imutável Mutável (as versões de gráficos são imutáveis, mas os valores podem mudar)
Reversões Reverter commits ou mudar de ramificação Implantar a tag de imagem anterior Reverter para uma versão anterior do gráfico
Ferramentas Clientes Git padrão, pipelines de CI/CD Docker ou Podman, registros de contêineres CLI do Helm, repositórios do Helm
Desempenho Pode ser mais lento para repositórios grandes Mais rápido, principalmente em grande escala Rápido ao buscar em um repositório de gráficos
Autenticação Flexível (SSH, token), pode ser mais complexo de configurar Simplificado com a Federação de Identidade da Carga de Trabalho para GKE (por exemplo, com o Artifact Registry) Simplificado com a Federação de Identidade da Carga de Trabalho para GKE (por exemplo, com o Artifact Registry)

Também é possível usar diferentes tipos de origem para diferentes finalidades no mesmo cluster. Por exemplo, um cluster pode ter o seguinte:

  • Uma RootSync sincronização de um repositório Git que contém recursos e políticas básicos de todo o cluster gerenciados pela equipe da plataforma.
  • Um RepoSync em um namespace específico sincronizando de um gráfico Helm para implantar uma instância do Redis gerenciada por uma equipe de aplicativos.
  • Outro RepoSync em um namespace diferente sincronizando de uma imagem OCI que contém um conjunto de configurações específicas do aplicativo criadas por um processo de CI/CD separado.

A seguir