Use um repositório hierárquico

Esta página descreve como o Config Sync lê as configurações de uma fonte de verdade hierárquica e aplica automaticamente a configuração resultante aos seus clusters.

Recomendamos que use uma fonte de dados não estruturada em vez de hierárquica, porque oferece as mesmas capacidades essenciais, mas dá-lhe mais flexibilidade na organização dos seus recursos. Se já usa uma fonte de informações fidedignas hierárquica, pode convertê-la numa fonte de informações fidedignas não estruturada.

Para compreender como o Config Sync usa um repositório hierárquico, é útil conhecer os repositórios Git e a interface de linha de comandos git.

Pode ver um exemplo de como organizar e configurar uma origem de confiança hierárquica no repositório de exemplos do Config Sync.

Estrutura do diretório

Para origens hierárquicas, o Config Sync tira partido de estruturas semelhantes a sistemas de ficheiros e usa o diretório para determinar a que clusters ou espaços de nomes uma configuração é relevante.

namespaces/

O diretório namespaces/ contém configurações para espaços de nomes e objetos com âmbito de espaço de nomes. A estrutura dentro de namespaces/ é o mecanismo que impulsiona a herança do espaço de nomes. Pode limitar os espaços de nomes que podem herdar uma configuração através de um NamespaceSelector.

cluster/

O diretório cluster/ contém configurações que se aplicam a clusters inteiros, em vez de a espaços de nomes. Por predefinição, qualquer configuração no diretório cluster/ aplica-se a todos os clusters inscritos na sincronização de configuração. Pode limitar os clusters que uma configuração pode afetar usando um ClusterSelector.

clusterregistry/

O diretório clusterregistry/ é opcional e contém configurações para ClusterSelectors. Os ClusterSelectors limitam os clusters aos quais uma configuração se aplica e são referenciados nas configurações encontradas nos diretórios cluster/ e namespaces/.

system/

O diretório system/ contém configurações para o operador.

Exemplo de fonte hierárquica de verdade

A seguinte estrutura de diretórios demonstra como usar uma origem hierárquica de verdade do Config Sync para configurar um cluster do Kubernetes partilhado por duas equipas diferentes, team-1 e team-2.

  • Cada equipa tem o seu próprio espaço de nomes do Kubernetes, conta de serviço do Kubernetes, quotas de recursos, políticas de rede e rolebindings.
  • O administrador do cluster configura uma política no namespaces/limit-range.yaml para restringir as atribuições de recursos (a pods ou contentores) em ambos os espaços de nomes.
  • O administrador do cluster também configura ClusterRoles e ClusterRoleBindings.

Uma origem hierárquica do Config Sync válida tem de incluir três subdiretórios: cluster/, namespaces/ e system/.

O diretório cluster/ contém configurações que se aplicam a clusters inteiros (como ClusterRole e ClusterRoleBinding), em vez de a espaços de nomes.

O diretório namespaces/ contém configurações para os objetos do espaço de nomes e os objetos com âmbito do espaço de nomes. Cada subdiretório em namespaces/ inclui as configurações de um objeto de espaço de nomes e todos os objetos com âmbito de espaço de nomes no espaço de nomes. O nome de um subdiretório deve ser igual ao nome do objeto de espaço de nomes. Os objetos com âmbito de espaço de nomes que precisam de ser criados em cada espaço de nomes podem ser colocados diretamente em namespaces/ (por exemplo, namespaces/limit-range.yaml).

O diretório system/ contém configurações para o operador ConfigManagement.

├── cluster
│   ├── clusterrolebinding-namespace-reader.yaml
│   ├── clusterrole-namespace-reader.yaml
│   ├── clusterrole-secret-admin.yaml
│   └── clusterrole-secret-reader.yaml
├── namespaces
│   ├── limit-range.yaml
│   ├── team-1
│   │   ├── namespace.yaml
│   │   ├── network-policy-default-deny-egress.yaml
│   │   ├── resource-quota-pvc.yaml
│   │   ├── rolebinding-secret-reader.yaml
│   │   └── sa.yaml
│   └── team-2
│       ├── namespace.yaml
│       ├── network-policy-default-deny-all.yaml
│       ├── resource-quota-pvc.yaml
│       ├── rolebinding-secret-admin.yaml
│       └── sa.yaml
├── README.md
└── system
    └── repo.yaml

Use a herança de espaços de nomes e os espaços de nomes abstratos

Com uma origem de confiança hierárquica, pode usar o conceito de herança do espaço de nomes para aplicar automaticamente configurações a grupos de espaços de nomes em todos os clusters onde esses espaços de nomes existem (ou devem existir).

A herança do espaço de nomes aplica-se ao namespaces/ diretório do repositório hierárquico e a todos os respetivos subdiretórios. As configurações noutros diretórios no repositório, como cluster/, não estão sujeitas a herança.

Numa origem de dados fidedigna hierárquica, o diretório namespaces/ pode conter dois tipos diferentes de subdiretórios:

  • Um diretório do espaço de nomes contém uma configuração para um espaço de nomes. O nome do ficheiro que contém a configuração não é importante, mas a configuração tem de ter kind: Namespace. Um diretório de espaço de nomes também pode conter configurações para outros tipos de objetos do Kubernetes. Um diretório de espaço de nomes não pode conter subdiretórios. Uma configuração do espaço de nomes representa um espaço de nomes real num cluster.

  • Um diretório de espaço de nomes abstrato contém diretórios de espaço de nomes. Também pode conter configurações para outros objetos do Kubernetes, mas não pode conter diretamente uma configuração para um espaço de nomes. Um diretório de espaço de nomes abstrato não representa um objeto num cluster do Kubernetes, mas os respetivos diretórios de espaço de nomes descendentes sim.

Para ajudar a garantir que as origens do espaço de nomes e do espaço de nomes abstrato têm o tipo correto de configurações e estrutura, o erro KNV1003: IllegalNamespaceSubdirectoryError é comunicado quando existe um problema.

As configurações num diretório de espaço de nomes aplicam-se apenas a esse espaço de nomes. No entanto, as configurações num diretório de espaço de nomes abstrato são aplicadas a todos os diretórios de espaço de nomes descendentes desse espaço de nomes abstrato (ou aos espaços de nomes descendentes que correspondam a um NamespaceSelector de uma configuração, se existir).

A herança de uma configuração no diretório namespaces/ baseia-se em grande parte na respetiva localização na árvore de diretórios na fonte de dados fidedignos. Para compreender que configurações estão a ser aplicadas a um determinado espaço de nomes num determinado cluster, pode procurar o repositório de exemplo de herança de espaço de nomes.

Espaços de nomes restritos

config-management-system é um espaço de nomes restrito. Não pode usá-lo como um diretório de espaço de nomes abstrato. Pode definir um espaço de nomes config-management-system, mas o único tipo de recurso permitido para o espaço de nomes config-management-system é RootSync.

Fazer alterações na sua fonte de informação fidedigna

Quando faz uma alteração na sua fonte de dados fidedigna que cria ou elimina diretórios de espaços de nomes a partir do diretório namespaces/, pode obter resultados inesperados consoante a ação:

  • Criar um diretório: quando uma hierarquia namespaces/ válida é confirmada na fonte de verdade, o Config Sync cria espaços de nomes e, em seguida, cria objetos Kubernetes nesses espaços de nomes para cada configuração que o diretório do espaço de nomes contém ou herda.
  • Eliminar um diretório: eliminar um diretório de espaço de nomes é uma operação destrutiva. O espaço de nomes e o respetivo conteúdo são eliminados em todos os clusters geridos pela sincronização de configuração onde o espaço de nomes existe. Se eliminar um diretório de espaço de nomes abstrato que contenha diretórios de espaço de nomes descendentes, todos esses espaços de nomes e respetivos conteúdos são eliminados de todos os clusters geridos pela sincronização de configuração.

  • Mudar o nome de um diretório: mudar o nome de um diretório de espaço de nomes é uma eliminação, seguida de uma criação, e é considerada uma operação destrutiva. A mudança do nome de um diretório de espaço de nomes abstrato não tem um efeito visível externamente.

  • Mover um diretório: mover um espaço de nomes ou um diretório de espaço de nomes abstrato em namespaces/ não elimina o espaço de nomes nem os objetos no mesmo, exceto quando o espaço de nomes começa ou deixa de herdar uma configuração de um diretório de espaço de nomes abstrato, devido a uma alteração na respetiva hierarquia.

O que se segue?