Adicionar configurações a uma fonte de informações

Nesta página, explicamos como adicionar e organizar configurações armazenadas em uma fonte de verdade.

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.

Quando o Config Sync gerencia esses recursos, ele mantém seus clusters registrados em sincronia usando configs. Um config é um arquivo YAML ou JSON armazenado em uma fonte de verdade. O Config Sync é compatível com repositórios Git, imagens OCI e gráficos Helm (Visualização) como fonte. As configurações contêm o mesmo tipo de detalhes de configuração que você pode aplicar 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. No entanto, alguns objetos do Kubernetes, como Secrets, contêm informações confidenciais que podem ser inadequadas para armazenar em uma fonte de verdade. Use seu bom senso ao considerar se quer gerenciar esses tipos de objetos usando o Config Sync.

Também é possível usar o Config Sync com o Config Connector para sincronizar as configurações dos recursos do Google Cloud. Para saber mais sobre como trabalhar com o Config Connector, consulte Gerenciar recursos do Google Cloud usando o Config Connector. Também é possível simplificar a instalação do Config Sync e do Config Connector configurando o Config Controller.

Esta página mostra como adicionar configs à sua fonte de verdade. Para saber como publicar uma imagem OCI, consulte Sincronizar artefatos OCI do Artifact Registry. Para saber como sincronizar a partir de um gráfico do Helm, consulte Sincronizar gráficos do Helm no Artifact Registry (Visualização).

Selecionar como organizar suas configurações

O Config Sync usa uma fonte de verdade para o armazenamento de configuração e o controle de versão. Há dois formatos diferentes para a fonte de informações, não estruturado e hierárquico.

O formato de origem não estruturada permite organizar as configurações da maneira mais conveniente. Esse formato pode ser útil principalmente se você estiver organizando ou gerando configurações usando uma ferramenta como kustomize, kpt ou helm. Para ver um exemplo de como organizar as configurações, consulte Exemplo de formato para um repositório não estruturado.

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 o formato de origem hierárquica, consulte Estrutura do repositório hierárquico.

Não estruturado é o formato recomendado para a maioria dos usuários. Além disso, ao configurar objetos RepoSync, você precisa usar o formato de origem não estruturado.

Recursos compatíveis para formatos não estruturados e hierárquicos

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

Recursos Formato não estruturado (recomendado) Formato hierárquico
Usado como formato para um objeto RootSync ou a fonte central da verdade Compatível Compatível
Usado como formato para um objeto RepoSync Compatível Sem suporte
Usado em conjunto com o controlador de hierarquia Compatível Não recomendado
ClusterSelector Compatível Compatível
NamespaceSelector Compatível Compatível
O comando nomos hydrate Compatível com a sinalização --source-format=unstructured Compatível
O comando nomos init Sem suporte Compatível
O comando nomos vet Compatível com a sinalização --source-format=unstructured Compatível
Todos os outros comandos nomos Compatível Compatível
Namespaces abstratos Sem suporte Compatível
Repo objetos Sem suporte Compatível
Objetos HierarchyConfig Sem suporte Compatível
Namespaces hierárquicos no controlador de hierarquia Compatível Sem suporte

Adicionar configurações à sua fonte de informações

Se você estiver criando um formato não estruturado, poderá começar a adicionar configurações a ele assim que ele for criado. Se você estiver criando um formato hierárquico, use o comando nomos init para inicializar a fonte da verdade ou crie a estrutura de diretórios manualmente.

Diretórios vazios não podem ser confirmados em um repositório Git. Portanto, antes de configurar o Config Sync, crie configurações e adicione-as ao seu repositório.

Depois de criar a fonte da verdade e adicionar configs a ela, use o comando nomos vet para verificar a estrutura da fonte e verificar a sintaxe e a validade das suas configurações.

Configurar o Config Sync para ler a fonte da verdade

Depois de criar uma fonte de verdade e definir as configurações nela, será possível configurar o Config Sync para ler a fonte. Depois de concluir esta etapa, o Config Sync sincroniza as configurações da sua fonte de informações com os clusters.

Você define o local da fonte da verdade ao instalar o Config Sync e pode editar a configuração do Config Sync mais tarde. Além do local da fonte da verdade, você pode especificar uma ramificação ou subdiretório para observar, se a fonte tiver outros conteúdos além das configurações.

Se você estiver usando um formato hierárquico e instalar o Config Sync manualmente com kubectl, não coloque a configuração do operador no diretório system/. Qualquer um dos outros diretórios reservados, como cluster/ ou namespaces/. Colocar a configuração em um dos diretórios reservados faz com que nomos vet falhe e registre um erro, como KNV1033: IllegalSystemResourcePlacementError, KNV1038: IllegalKindInNamespacesError ou KNV1039: IllegalKindInClusterError.

É possível conceder às pessoas acesso à fonte de verdade sobre a implantação de uma determinada equipe de produto. No entanto, quando você concede a uma pessoa acesso a uma fonte de verdade, ela também recebe o mesmo RBAC que o reconciliador em execução para essa fonte de verdade.

Para configurar a autenticação e autorização entre o Config Sync e a fonte da verdade, consulte a etapa de instalação sobre como configurar o secret git-creds.

Ignorar mutações de objeto

Se você não quiser que o Config Sync mantenha o estado do objeto no 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, é necessário ativar as APIs RootSync e RepoSync.

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