Acerca das fontes de verdade

Este documento explica os diferentes tipos de fontes de verdade a partir das quais o Config Sync pode sincronizar.

Um conceito fundamental nos fluxos de trabalho do GitOps é a fonte prioritária, um repositório central onde os seus ficheiros de configuração são armazenados. Normalmente, um ficheiro de configuração é um ficheiro YAML ou JSON que define recursos do Kubernetes. Normalmente, pode aplicar manualmente objetos Kubernetes com a ferramenta de linha de comandos kubectl, mas o Config Sync pode aplicar automaticamente esses recursos a partir de uma única fonte de verdade, como um repositório Git. Em seguida, o Config Sync monitoriza a sua fonte de dados fidedigna especificada e aplica automaticamente quaisquer alterações aos seus clusters.

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

Repositórios Git

O Git é uma tecnologia amplamente adotada para o controlo de versões e a colaboração. Com o Git, pode organizar o seu repositório da forma que se adequa às suas necessidades e obter as vantagens do controlo de versões e da ramificação, se necessário. Uma vez que o Git é uma tecnologia madura e amplamente adotada, tem várias opções de fornecedores e ferramentas.

Quando configura o Config Sync com um repositório Git como a fonte de verdade, o Config Sync usa um contentor git-sync no pod reconciliador para extrair configurações do repositório Git. Pode configurar o URL do repositório, a ramificação e a revisão (commit ou etiqueta) para ter maior controlo sobre onde obter as configurações no seu repositório Git.

Exemplo de configuração RootSync

O exemplo seguinte mostra um RootSync manifesto que é sincronizado a partir 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

Esta configuração configura o Config Sync para sincronizar manifestos a partir de um repositório Git. O Config Sync monitoriza o diretório cluster-configs no ramo main do repositório https://github.com/example/my-configs.git, verificando se existem atualizações a cada 60 segundos sem usar autenticação.

Exemplo de utilização: gestão centralizada

Imagine que é um administrador da plataforma que quer usar um repositório Git para aplicar políticas de base em todos os clusters numa frota. Neste cenário, pode armazenar os ficheiros NetworkPolicies, RoleBindings e ResourceQuotas padrão num repositório Git central denominado standard-configs. Quando um novo cluster é aprovisionado, o Config Sync é configurado para sincronizar a partir do repositório standard-configs, o que ajuda a garantir que todos os clusters cumprem as normas organizacionais desde o início.

Imagens OCI

As imagens OCI são um formato padrão para o empacotamento de aplicações e das respetivas dependências. Esta abordagem trata as suas configurações como artefactos, de forma semelhante ao tratamento de imagens de contentores. Esta abordagem oferece vantagens como a imutabilidade e um desempenho mais rápido em grande escala. Com a OCI, pode usar a infraestrutura e as ferramentas de imagens de contentores, como o Artifact Registry, para gerir as suas imagens e a Workload Identity Federation para o GKE para ajudar a simplificar a autenticação.

A utilização da OCI como origem de configuração requer normalmente um processo separado para criar os ficheiros de configuração numa imagem OCI e, em seguida, enviá-la para uma plataforma de registo como o Artifact Registry. Esta abordagem pode ser menos legível diretamente por humanos do que as configurações armazenadas como ficheiros num repositório Git.

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

Exemplo de configuração RootSync

O exemplo seguinte mostra um manifesto RootSync que é sincronizado a partir 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

Esta configuração configura o Config Sync para sincronizar a partir 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 através de uma conta de serviço do Kubernetes para autenticação.

Exemplo de utilização: integração de pipeline de CI/CD

Imagine que quer integrar a criação de imagens OCI no pipeline de CI/CD da sua organização. Quando as alterações aos ficheiros de configuração são unidas, pode configurar o pipeline para executar testes de validação (como o comando nomos vet), criar os ficheiros YAML numa imagem OCI e enviar a imagem para o Artifact Registry. Em seguida, o Config Sync deteta e aplica automaticamente a nova versão da imagem aos seus clusters, garantindo uma implementação validada e com controlo de versões de todas as alterações de configuração.

Gráficos Helm

O Helm é um gestor de pacotes popular para o Kubernetes, que usa um formato de embalagem denominado gráficos. O Config Sync pode obter, renderizar e sincronizar recursos definidos em gráficos Helm.

O Helm oferece uma forma consistente de criar pacotes e reutilizar aplicações Kubernetes. Pode usar modelos ou gráficos Helm pré-criados para configurações consistentes e reutilizáveis.

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

Quando configura o Config Sync com um gráfico Helm como a fonte de verdade, o Config Sync usa um contentor 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. Em alternativa, pode usar a sincronização de configuração com o Kustomize para renderizar gráficos do Helm. Para mais informações sobre esta abordagem, consulte o artigo Use a sincronização de configuração com o Kustomize e o Helm.

Exemplo de configuração RootSync

O exemplo seguinte mostra um manifesto RootSync que é sincronizado a partir de um gráfico 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

Esta configuração configura o Config Sync para sincronizar um gráfico Helm a partir de um repositório OCI. O Config Sync obtém 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-se com a conta de serviço my-service-account@my-project.iam.gserviceaccount.com. Implementa os recursos do gráfico no espaço de nomes my-app-namespace com o nome de lançamento de my-chart-release.

Exemplo de utilização: implementar uma aplicação de terceiros

Imagine que faz parte de uma equipa de aplicações que quer implementar o Prometheus num cluster. Pode configurar o Config Sync para extrair de um gráfico Helm pré-criado que implementa o Prometheus. Em vez de executar manualmente comandos Helm, pode definir a origem, a versão e quaisquer values personalizados no objeto RootSync ou RepoSync do Config Sync. Em seguida, o Config Sync mantém a implementação sincronizada com a versão do gráfico e as configurações especificadas.

Escolher um tipo de fonte

O melhor tipo de origem depende das ferramentas, dos fluxos de trabalho e das preferências existentes da sua equipa. Pode usar esta tabela para compreender as principais caraterísticas de cada tipo de origem e tomar uma decisão informada:

Funcionalidade Repositório Git Imagem OCI Gráfico de leme
Ideal para Gestão de configuração de fins gerais; flexibilidade; legibilidade Configurações imutáveis e com versões; tirar partido da infraestrutura de contentores Criar pacotes e distribuir aplicações complexas
Mutabilidade Mutável Imutável Mutável (as versões dos gráficos são imutáveis, mas os valores podem mudar)
Reversões Reverta commits ou altere ramos Implemente a etiqueta de imagem anterior Reverta para uma versão anterior do gráfico
Ferramentas Clientes Git padrão, pipelines de CI/CD Docker ou Podman, registos de contentores CLI do Helm, repositórios do Helm
Desempenho Pode ser mais lento para repositórios grandes Mais rápido, especialmente à escala Rápido quando obtém dados 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 o GKE (por exemplo, com o Artifact Registry) Simplificado com a federação de identidade da carga de trabalho para o GKE (por exemplo, com o Artifact Registry)

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

  • Uma RootSync sincronização a partir de um repositório Git que contém recursos e políticas ao nível do cluster base geridos pela equipa da plataforma.
  • Um RepoSync num espaço de nomes específico que está a ser sincronizado a partir de um gráfico Helm para implementar uma instância do Redis gerida por uma equipa de aplicações.
  • Outro RepoSync num espaço de nomes diferente sincronizado a partir de uma imagem OCI que contém um conjunto de configurações específicas da aplicação criadas por um processo de CI/CD separado.

O que se segue?