Como usar configs em repositórios Git

O Config Sync foi projetado para operadores de cluster que gerenciam muitos clusters. É possível garantir que os clusters atendam aos padrões de negócios e conformidade permitindo que o Config Sync gerencie namespaces, papéis, RoleBindings, ResourceQuotas e outros objetos importantes do Kubernetes na sua frota.

O Config Sync mantém seus clusters registrados sincronizados usando configs. Um config é um arquivo YAML ou JSON armazenado no repositório Git e contém os mesmos tipos de detalhes de configuração que podem ser aplicados manualmente a um cluster usando o comando kubectl apply. É possível criar um config para qualquer objeto do Kubernetes que possa existir em um cluster. Neste tópico, abordamos as seguintes tarefas:

  • Como organizar configs em um diretório.
  • Como inicializar um repositório do Git para armazenar os configs.
  • Como configurar o Config Sync para ler as configurações.

Como armazenar configurações em repositórios

O Config Sync usa um repositório do Git para armazenamento de configuração e controle de versão, agindo com base nesse conteúdo. No Config Sync, esse repositório é chamado de repo. Há dois formatos diferentes para um repositório: não estruturado e hierárquico.

  • O formato de origem não estruturado permite organizar as configurações no seu repositório da maneira mais conveniente. Esse formato pode ser útil principalmente se você estiver organizando e/ou gerando configurações usando uma ferramenta como kustomize, kpt ou helm.
  • O formato de origem hierárquico ou estruturado separa as configurações em categorias distintas para ajudar você a organizá-las. As categorias são configurações do sistema, metadados de cluster, configuração no nível do cluster e configuração de namespace. Para mais informações sobre a estrutura hierárquica do repositório, consulte Estrutura do repositório hierárquico.

A tabela a seguir destaca as diferenças entre os formatos hierárquicos e não estruturados:

Recursos Formato de repositório hierárquico Formato de repositório não estruturado
Seletores de namespace Compatível Compatível
Seletores de cluster Compatível Compatível
Namespaces abstratos Compatível Incompatível
Repo objetos Compatível Incompatível
Objetos HierarchyConfig Compatível Incompatível
Namespaces hierárquicos no controlador de hierarquia Incompatível Compatível
Usado como formato para um repositório de namespace. Incompatível Compatível
Usado como formato de um repositório raiz Compatível Compatível
Usado em conjunto com o controlador de hierarquia Não recomendado Compatível
O comando nomos init Compatível Incompatível
O comando nomos hydrate Compatível Incompatível
O comando nomos vet Compatível Compatível com a sinalização --source-format=unstructured
Todos os outros comandos nomos Compatível Compatível

Exemplo de um layout de configuração não estruturado

O exemplo a seguir demonstra uma maneira de organizar seus configs, incluindo recursos do Google Cloud.

É possível colocar as configurações brutas em um diretório raw-configs, usar um script ou um pipeline automatizado para renderizar as configurações brutas e armazenar a saída no diretório manifests. No final, você configura o Config Sync para sincronizar com o diretório manifests.

├── manifests
│   ├── access-control
│   │   ├── ...
│   ├── change-control
│   │   ├── ...
│   ├── git-ops
│   │   └── ...
│   ├── logging-monitoring
│   │   └── ...
│   ├── networking
│   │   └── ...
│   ├── project-factory
│   │   └── ...
│   └── resource-hierarchy
│   │   └── ...
├── raw-configs
│   ├── access-control
│   │   └── ...
│   ├── change-control
│   │   └── ...
│   ├── git-ops
│   │   └── ...
│   ├── logging-monitoring
│   │   └── ...
│   ├── networking
│   │   └── ...
│   ├── project-factory
│   │   └── ...
│   └── resource-hierarchy
│   │   └── ...
└── scripts
    └── render.sh

Como inicializar um repositório Git

A maneira como você inicia um repo depende da estrutura dele.

  • Para o formato não estruturado, é possível inicializar um repositório Git vazio e começar a adicionar configs no repo.
  • Para o formato hierárquico, inicialize um repositório usando o comando nomos init ou crie a estrutura de diretórios manualmente.

Como configurar o Config Sync para ler o repositório

Você configura o local do repo ao instalar o Config Sync e pode editar a configuração dele posteriormente no arquivo de configuração do Operador. Além do local do repo, é possível especificar uma ramificação do Git e um subdiretório para serem observados caso o repositório do Git tenha outros conteúdos além de configs.

Depois de atualizar o arquivo de configuração, use o comando kubectl apply para aplicá-lo ao cluster. O Config Sync não gerencia a configuração do próprio Operador.

É possível conceder às pessoas acesso ao repositório de implantação de uma determinada equipe de produto. No entanto, lembre-se de que, ao conceder acesso a um repositório de implantação para uma pessoa, ela também recebe o mesmo RBAC que o reconciliador em execução desse repositório.

Para configurar a autenticação e autorização entre o Config Sync e o repositório, consulte a etapa de instalação sobre Como configurar o secret git-creds.

Como ignorar mutações de objetos

Se você não quiser que o Config Sync mantenha o estado do objeto e o cluster após ele existir, adicione a anotação client.lifecycle.config.k8s.io/mutation: ignore ao objeto em que o Config Sync deve ignorar as mutações. Para usar a anotação, ative o modo de vários repositórios e use uma versão 1.7.0 ou posterior.

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

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

Não é possível modificar manualmente essa anotação em objetos gerenciados no cluster.

A seguir