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, é possível aplicar objetos do Kubernetes manualmente com a ferramenta de linha de comando kubectl, mas o Config Sync pode aplicar esses recursos automaticamente de uma única fonte da verdade, como um repositório Git. Em seguida, o Config Sync monitora a fonte da verdade especificada e aplica automaticamente todas 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 mais adequada às suas necessidades e aproveitar os benefícios do controle de versões e do 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 a fonte da verdade, o Config Sync usa um contêiner git-sync no pod do reconciliador para extrair configurações do repositório Git. É possível configurar o URL, a ramificação e a revisão (commit ou tag) do repositório para ter maior controle sobre onde extrair as configurações no repositório Git.

Exemplo de configuração 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 configura 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 autenticação.

Exemplo de caso de uso: gerenciamento centralizado

Imagine que você seja um administrador de plataforma que quer usar um repositório Git para aplicar políticas de linha de base 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 as configurações como artefatos, de maneira semelhante a como você trataria imagens de contêiner. Essa abordagem oferece vantagens como imutabilidade e desempenho mais rápido em escala. Com o OCI, é possível usar a infraestrutura e as ferramentas de imagem de contêiner, como o Artifact Registry, para gerenciar as imagens e a Federação de Identidade da Carga de Trabalho para GKE para simplificar a autenticação.

O uso do OCI como uma fonte de configuração geralmente exige um processo separado para criar os arquivos de configuração em uma imagem OCI e, em seguida, enviá-la para uma plataforma de registro, como o Artifact Registry. Essa abordagem pode ser menos legível diretamente do que as configurações armazenadas como arquivos em um repositório Git.

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

Exemplo de configuração RootSync

O exemplo a seguir mostra um manifesto RootSync que sincroniza de 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 configura o Config Sync para sincronizar de 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ê quer integrar a criação de imagens 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. Em seguida, o Config Sync detecta e aplica automaticamente a nova versão da imagem aos clusters, garantindo uma implantação validada e versionada de todas as mudanças de configuração.

Gráficos do Helm

O Helm é um gerenciador de pacotes popular para o Kubernetes, que usa um formato de empacotamento chamado 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. É possível usar modelos ou gráficos do Helm pré-criados para configurações consistentes e reutilizáveis.

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

Ao configurar o Config Sync com um gráfico do Helm como a fonte da verdade, o Config Sync usa um contêiner helm-sync no pod do reconciliador para extrair gráficos de um repositório do Helm (como o Artifact Registry) ou um repositório Git e, em seguida, renderiza o gráfico para produzir manifestos do Kubernetes. Como alternativa, é possível usar 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 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.s3ns.iam.gserviceaccount.com
    releaseName: my-chart-release
    namespace: my-app-namespace # Namespace where the chart resources will be deployed

Essa configuração configura 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 do repositório oci://us-central1-docker.pkg.dev/my-project/my-helm-repo e autentica com a conta de serviço my-service-account@my-project.s3ns.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ê faça 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, defina a origem, a versão e todos os values personalizados do gráfico no objeto 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 do gráfico especificadas.

Como escolher um tipo de origem

O melhor tipo de origem 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 origem 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; legibilidade humana Configurações imutáveis e versionadas; aproveitamento da infraestrutura de contêiner Empacotamento e distribuição de aplicativos complexos
Mutabilidade Mutável Imutável Mutável (as versões do gráfico são imutáveis, mas os valores podem mudar)
Reversões Reverter commits ou mudar ramificações 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êiner CLI do Helm, repositórios do Helm
Desempenho Pode ser mais lento para repositórios grandes Mais rápido, especialmente em escala Rápido ao buscar de 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 fins diferentes no mesmo cluster. Por exemplo, um cluster pode ter o seguinte:

  • Um RootSync sincronizando de um repositório Git que contém recursos e políticas básicos de cluster gerenciados pela equipe da plataforma.
  • Um RepoSync em um namespace específico sincronizando de um gráfico do 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