Organize os ficheiros de configuração numa fonte de informação

Esta página explica como organizar as configurações numa fonte de verdade.

À medida que a sua organização cresce, é provável que precise de gerir configurações numa frota de clusters e suportar várias equipas que trabalham nos mesmos repositórios. Uma parte fundamental de uma estratégia GitOps bem-sucedida é garantir que as configurações são aplicadas aos clusters corretos e que as equipas podem trabalhar sem interferir umas com as outras.

Acerca dos ficheiros de configuração

O Config Sync foi concebido para operadores de clusters que gerem muitos clusters. Pode garantir que os seus clusters cumprem as normas empresariais e de conformidade permitindo que o Config Sync faça a gestão de espaços de nomes, funções, associações de funções, quotas de recursos e outros objetos importantes do Kubernetes na sua frota.

Quando o Config Sync gere estes recursos, mantém os clusters inscritos sincronizados através de configurações. Uma configuração é um ficheiro YAML ou JSON numa fonte de verdade. O Config Sync suporta repositórios Git, imagens OCI e gráficos Helm como fonte de informações fidedignas. As configurações contêm o mesmo tipo de detalhes de configuração que pode aplicar manualmente a um cluster através do comando kubectl apply. Pode criar uma configuração para qualquer objeto do Kubernetes que possa existir num cluster. No entanto, alguns objetos do Kubernetes, como os segredos, contêm informações confidenciais que podem ser inadequadas para armazenar numa fonte de verdade. Pondere cuidadosamente se deve gerir estes tipos de objetos através do Config Sync.

Requisitos e limitações

  • Alguns recursos do Kubernetes contêm campos imutáveis, como seletores de pods num objeto de implementação. Não pode alterar nenhum campo imutável numa configuração alterando o valor na fonte de dados fidedigna. Se tentar fazer essa alteração, ocorre um KNV2009 erro. Se precisar de alterar um campo imutável, elimine o objeto da sua fonte de verdade, aguarde que o Config Sync elimine o objeto do cluster e, em seguida, recrie o objeto na sua fonte de verdade com as atualizações.

  • Se usar submódulos Git, tem de conceder acesso de sincronização de configuração a todos os repositórios, incluindo quaisquer submódulos.

  • Não pode usar a sincronização de configuração para gerir diretamente as ClusterRoles do Kubernetes incorporadas. O GKE inclui algumas funções orientadas para o utilizador, como cluster-admin, admin, edit e view. Não pode gerir diretamente estes ClusterRoles com o Config Sync. Caso contrário, o Config Sync entra em conflito com o GKE. Para adicionar autorizações aos ClusterRoles incorporados, use a agregação de funções para os modificar indiretamente. Para modificar as funções, crie um ClusterRole com um nome único na sua fonte de verdade com as anotações adequadas.

Organize a sua fonte de informação

Pode configurar o Config Sync para sincronizar a partir de um repositório completo ou de pastas ou ramificações específicas. Devido a esta flexibilidade, organize os ficheiros de configuração com base nas necessidades da sua equipa ou organização.

Recomendamos que, quando configurar a sincronização de configuração, defina sourceFormat como unstructured. O tipo de origem estruturado (hierárquico) requer uma estrutura de pastas muito específica para sincronizar corretamente as suas configurações e adiciona complexidade desnecessária na maioria dos casos.

A maioria da documentação do Config Sync, incluindo esta página, usa o formato não estruturado por predefinição, mas pode encontrar informações sobre o formato hierárquico, se necessário, em Use um repositório hierárquico.

Quando usa uma origem não estruturada, tem a flexibilidade de organizar as suas configurações de acordo com o fluxo de trabalho da sua equipa. Esta secção apresenta alguns padrões comuns para estruturar o seu repositório.

Esquema baseado no ambiente

Uma abordagem comum é organizar o repositório por ambiente.

├── cluster-essentials/
│   ├── crds/
│   └── namespace.yaml
├── environments/
│   ├── dev/
│   │   ├── backend/
│   │   └── frontend/
│   ├── staging/
│   │   ├── backend/
│   │   └── frontend/
│   └── prod/
│       ├── backend/
│       └── frontend/
└── system/
    └── monitoring/

Neste exemplo, a fonte de verdade está organizada da seguinte forma:

  • cluster-essentials/: contém a configuração que se aplica a todos os clusters, independentemente do ambiente. Isto pode incluir recursos como definições de recursos personalizados (CRDs) e espaços de nomes essenciais.
  • environments/: o diretório principal de todas as configurações específicas do ambiente.
  • system/: contém configurações para serviços ao nível do sistema, como a monitorização.

Esta abordagem é simples de compreender e navegar, e oferece um caminho de promoção claro para as alterações de um ambiente para outro.

Quando configura o Config Sync neste cenário, cria vários objetos em cada cluster.RootSync Por exemplo, um cluster de desenvolvimento tem RootSync objetos a sincronizar a partir de cluster-essentials/, system/ e environments/dev/.

Esquema baseado em clusters

Se o seu foco for gerir um conjunto de clusters individuais com configurações distintas, um esquema baseado em clusters pode ser mais adequado.

├── clusters/
│   ├── cluster-a/
│   │   ├── apps/
│   │   └── networking/
│   ├── cluster-b/
│   │   ├── apps/
│   │   └── networking/
│   └── cluster-c/
│       ├── apps/
│       └── networking/
└── shared/
    ├── roles/
    └── policies/

Neste exemplo, a fonte de verdade está organizada da seguinte forma:

  • clusters/: contém um diretório para cada cluster que está a gerir.
  • shared/: contém configurações comuns a todos os clusters, como funções RBAC e políticas de segurança.

Esta abordagem é eficaz para gerir muitos clusters se todos tiverem configurações únicas, uma vez que oferece uma propriedade clara e isolamento das configurações. Esta abordagem pode ser mais complexa de gerir se tiver muitas configurações de clusters partilhadas.

Quando configura a sincronização de configuração neste cenário, pode usar um RepoSync para configurar cada cluster de modo a sincronizar a partir de shared e do diretório específico do cluster.

Esquema baseado em equipas

Para organizações onde diferentes equipas gerem diferentes aplicações ou serviços, um esquema baseado em equipas pode ser eficaz. Esta abordagem alinha a estrutura da fonte de dados fidedignos com a estrutura organizacional.

├── teams/
│   ├── team-alpha/
│   │   ├── app-one/
│   │   └── app-two/
│   ├── team-beta/
│   │   ├── service-a/
│   │   └── service-b/
│   └── team-gamma/
│       ├── data-pipeline/
│       └── dashboard/
└── platform/
    ├── cluster-roles/
    └── storage-classes/

Neste exemplo, a fonte de confiança está organizada da seguinte forma:

  • teams/: organiza a configuração por equipa, com cada equipa a gerir as suas próprias configurações de aplicações e serviços.
  • platform/: contém configurações ao nível do cluster que uma equipa de plataforma central gere e que todas as equipas usam.

Esta abordagem permite que as equipas geram as suas próprias configurações e ciclos de lançamento e reduz a probabilidade de as alterações de uma equipa afetarem acidentalmente outra equipa. No entanto, esta abordagem requer uma gestão cuidadosa das dependências entre as equipas de apps e as equipas de plataformas.

Quando configura a sincronização de configuração para este cenário, cada equipa usa um objeto RootSync para sincronizar configurações. Por exemplo, team-alpha sincroniza a partir de teams/team-alpha/.

Validar ficheiros de configuração

Depois de criar, organizar e adicionar ficheiros de configuração a uma fonte de confiança, use o comando nomos vet --source-format=unstructured para verificar a sintaxe e a validade das suas configurações. Isto ajuda a evitar erros durante ou após uma sincronização.

Ignore object mutations

Se não quiser que o Config Sync mantenha o estado do objeto no cluster depois de existir, adicione a anotação client.lifecycle.config.k8s.io/mutation: ignore ao objeto no qual quer que o Config Sync ignore as mutações.

O exemplo seguinte mostra como adicionar a anotação a um objeto:

metadata:
  annotations:
    client.lifecycle.config.k8s.io/mutation: ignore

Não pode modificar manualmente esta anotação em objetos geridos no cluster.

Converta um repositório hierárquico num repositório não estruturado

Se usar um repositório hierárquico e quiser convertê-lo num repositório não estruturado, execute o seguinte comando:

nomos hydrate PATH

Substitua PATH pelo caminho para o seu diretório.

Este comando cria um diretório compiled/ no diretório de trabalho atual. Nesse diretório, é criado um subdiretório para cada cluster inscrito. Estas subdiretorias contêm as configurações totalmente resolvidas e podem ser usadas num repositório não estruturado.

Para mais detalhes, consulte os comandos nomos.

Se preferir converter o repositório manualmente, siga as seguintes instruções:

  1. Remova as configurações Repo no diretório system/ do seu repositório Git. O recurso Repo não é necessário para um repositório não estruturado.

  2. O diretório de espaço de nomes abstrato não é suportado num repositório não estruturado. Por conseguinte, declare o espaço de nomes de todos os recursos originalmente incluídos no diretório namespaces/ e nos respetivos subdiretórios.

  3. A herança do espaço de nomes não é suportada no repositório não estruturado. Por conseguinte, declare todos os recursos que são originalmente herdados nos espaços de nomes descendentes (os que estão originalmente no diretório namespaces/).

O que se segue?