Adicione configurações a uma fonte de verdade

Esta página explica como adicionar e organizar configurações armazenadas numa fonte de dados fidedigna.

Acerca das configurações

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 armazenado 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. Use o seu julgamento ao considerar se deve gerir estes tipos de objetos através do Config Sync.

Também pode usar o Config Sync com o Config Connector para sincronizar configurações de Google Cloud recursos. Para saber mais sobre como trabalhar com o Config Connector, consulte o artigo sobre a gestão Google Cloud de recursos através do Config Connector. Também pode simplificar a instalação do Config Sync e do Config Connector configurando o Config Controller.

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 estas 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 uma ClusterRole com um nome único na sua fonte de verdade com as anotações adequadas.

Selecione como organizar as suas configurações

O Config Sync usa uma fonte de informações fidedignas para o armazenamento de configurações e o controlo de versões. Pode escolher dois formatos diferentes para a sua fonte de dados fidedignos: não estruturado e hierárquico.

O formato de origem não estruturado permite-lhe organizar as configurações da forma mais conveniente. Este formato pode ser especialmente útil se estiver a organizar ou gerar configurações através de uma ferramenta como o Kustomize, o kpt ou o Helm. Para ver um exemplo de como pode organizar as suas configurações, consulte o 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 a organizá-las. As categorias são configuração do sistema, metadados do cluster, configuração ao nível do cluster e configuração do namespace. Para mais informações sobre o formato de origem hierárquico, consulte o artigo Estrutura do repositório hierárquico.

O formato não estruturado é o formato recomendado para a maioria dos utilizadores. Além disso, quando configura objetos RepoSync, tem de usar o formato de origem não estruturado.

Funcionalidades suportadas para formatos não estruturados e hierárquicos

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

Funcionalidades Formato não estruturado (recomendado) Formato hierárquico
Usado como formato para um objeto RootSync ou a fonte central de informações fidedignas Suportado Suportado
Usado como formato para um objeto RepoSync Suportado Não suportado
ClusterSelector Suportado Suportado
NamespaceSelector Suportado Suportado
O comando nomos hydrate Suportado com a flag --source-format=unstructured Suportado
O comando nomos init Não suportado Suportado
O comando nomos vet Suportado com a flag --source-format=unstructured Suportado
Todos os outros comandos nomos Suportado Suportado
Espaços de nomes abstratos Não suportado Suportado
Repo objetos Não suportado Suportado
HierarchyConfig objetos Não suportado Suportado

Quando deve adicionar configurações à origem

Se estiver a criar um formato não estruturado, pode começar a adicionar configurações assim que o formato for criado. Se estiver a criar um formato hierárquico, use o comando nomos init para inicializar a fonte de dados fidedigna ou crie a estrutura de diretórios manualmente.

Não é possível confirmar diretórios vazios num repositório Git. Por isso, antes de configurar o Config Sync, tem de criar configurações e adicioná-las ao seu repositório.

Depois de criar a fonte de informações fidedignas e adicionar configurações à mesma, use o comando nomos vet para validar a estrutura da fonte de informações fidedignas e verificar a sintaxe e a validade das configurações.

Configure o Config Sync para ler a partir da fonte de informação fidedigna

Depois de criar uma fonte de verdade e colocar as suas configurações na mesma, pode configurar o Config Sync para ler a partir da fonte. Depois de concluir este passo, o Config Sync sincroniza as configurações da sua fonte de referência com os seus clusters.

Configura a localização da fonte de verdade quando instala o Config Sync, e pode editar a configuração do Config Sync mais tarde. Além da localização da fonte de informações verdadeiras, pode especificar uma ramificação ou um subdiretório a monitorizar, se a fonte tiver conteúdos que não sejam configurações.

Se estiver a usar um formato hierárquico e a instalar o Config Sync manualmente com kubectl, não coloque a configuração do operador no diretório system/ nem em nenhum dos outros diretórios reservados, como cluster/ ou namespaces/. A colocação da configuração num dos diretórios reservados faz com que nomos vet falhe e regista um erro, como KNV1033: IllegalSystemResourcePlacementError, KNV1038: IllegalKindInNamespacesError, ou KNV1039: IllegalKindInClusterError.

Pode conceder às pessoas acesso à fonte de verdade de implementação de uma determinada equipa de produto. No entanto, quando concede a uma pessoa acesso a uma fonte de verdade de implementação, essa pessoa também recebe o mesmo RBAC que o reconciliador em execução para essa fonte de verdade.

Para configurar a autenticação e a autorização entre o Config Sync e a fonte de dados fidedigna, consulte o passo de instalação sobre a configuração do git-credssegredo.

Ignore object mutations

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

Para usar a anotação, tem de ativar as APIs RootSync e RepoSync.

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.

O que se segue?