Sobre as fontes da verdade

Com o Config Sync, é possível automatizar as implantações de recursos do Kubernetes nos clusters usando uma fonte de verdade central, substituindo os comandos kubectl manuais. Nos fluxos de trabalho do GitOps, uma fonte de verdade é o repositório central em que você armazena arquivos de configuração YAML ou JSON que definem os recursos do cluster. O Config Sync monitora continuamente esse repositório e aplica automaticamente as alterações aos clusters.

É possível sincronizar arquivos de configuração de três tipos de fontes: repositórios Git, imagens da Open Container Initiative (OCI) e gráficos do Helm. Entender como o Config Sync interage com cada tipo de fonte ajuda você a escolher a melhor opção 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 atenda às suas necessidades e aproveitar os benefícios do controle de versões e da ramificação, se necessário. Como o Git é maduro e amplamente compatível, você tem uma variedade de opções de provedores e ferramentas.

Quando você configura o Config Sync com um repositório Git como a fonte de verdade, ele usa um contêiner git-sync no pod 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 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 é sincronizado 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 se há 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, é possível 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 com o 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 as dependências deles. Essa abordagem trata as configurações como artefatos, de maneira semelhante ao tratamento de imagens de contêiner. Essa abordagem oferece vantagens como imutabilidade e desempenho mais rápido em escala. Com a 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 da OCI como fonte de configuração geralmente requer 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 por humanos do que as configurações armazenadas como arquivos em um repositório Git.

Quando você configura o Config Sync com uma imagem OCI como a fonte de verdade, ele 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 é sincronizado 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 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ê quer integrar a criação de imagens OCI ao pipeline de CI/CD da sua organização. Quando as alterações 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 com controle de versão 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 empacotamento 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. É 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 criação de modelos e lançamento pode adicionar mais complexidade ao pipeline de gerenciamento de configuração.

Quando você configura o Config Sync com um gráfico do Helm como fonte de verdade, ele 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 de 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 é sincronizado 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 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 se 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: implantar 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 manualmente os comandos do Helm, você define a origem do gráfico, a versão e qualquer values personalizado 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, dos fluxos de trabalho e das preferências 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 por humanos Configurações imutáveis e com controle de versões; aproveitamento da infraestrutura de contêineres Empacotar e distribuir 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 confirmações ou mudar ramificações Implantar 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, Container Registry CLI do Helm, repositórios do Helm
Desempenho Pode ser mais lento para repositórios grandes Mais rápido, especialmente 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 finalidades distintas no mesmo cluster. Por exemplo, um cluster pode ter o seguinte:

  • Um RootSync sincronizado 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 que é sincronizado 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 que é sincronizado com 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