Adicionar configurações aos 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.
Quando o Config Sync gerencia esses recursos, ele mantém seus clusters registrados em
sincronia usando configs. Uma configuração é um arquivo YAML ou JSON armazenado em um repositório
Git. 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 armazenamento em um repositório Git. 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 configurações aos seus repositórios. Para saber como criar uma configuração, consulte Criar configurações. Para saber como publicar uma imagem OCI, consulte Sincronizar artefatos do OCI no Artifact Registry. Para saber como sincronizar de um repositório do Helm, consulte Sincronizar gráficos do Helm no Artifact Registry.
Selecionar como organizar suas configurações
O Config Sync usa um repositório Git para armazenamento de configurações e controle de versões. Há dois formatos diferentes para o 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 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 a estrutura hierárquica do repositório, consulte Estrutura do repositório hierárquico.
Não estruturado é o formato recomendado para a maioria dos usuários. Além disso, os repositórios de namespace, que você configura criando objetos RepoSync, precisam usar o formato de repositório não estruturado.
Recursos compatíveis para repositórios 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 de um repositório raiz | Compatível | Compatível |
Usado como formato para um repositório de namespace. | 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 ao repositório
Se você estiver criando um repositório não estruturado, poderá começar a adicionar configurações a
ele assim que ele for criado. Se você estiver criando um repositório hierárquico, use
o comando nomos init
para
inicializar o repositório 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 o repositório e adicionar configurações a ele, use o
comando nomos vet
para verificar a
estrutura do repositório e a sintaxe e a validade das configurações.
Configurar o Config Sync para ler no repositório
Depois de criar um repositório e inserir as configurações nele, é possível configurar o Config Sync para ler pelo repositório. Depois que você concluir esta etapa, o Config Sync sincronizará as configurações do seu repositório com os clusters.
Você define o local do repositório quando instala o Config Sync e pode editar a configuração do Config Sync posteriormente. Além do local do repositório, é 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.
Se você estiver usando um repositório 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 ao repositório de implantação de uma determinada equipe de produto. No entanto, quando você concede acesso a um repositório de implantação, essa pessoa também recebe o mesmo RBAC que o reconciliador em execução nesse 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
.
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.