Visão geral do repositório hierárquico

Nesta página, descrevemos como o Config Sync lê configurações de um repositório hierárquico e aplica a configuração resultante a seus clusters automaticamente.

Se você quiser mais flexibilidade estrutural (por exemplo, criar subpastas de recursos), crie um repositório não estruturado. Os repositórios não estruturados são recomendados para a maioria dos usuários e podem ser combinados com o controlador de hierarquia para fornecer herança de namespace semelhante à oferecida por repositórios hierárquicos.

Para entender como o Config Sync usa um repositório hierárquico, é útil se você estiver familiarizado com os repositórios Git e a interface de linha de comando git.

Estrutura do repositório hierárquico

Para repositórios hierárquicos, o Config Sync aproveita a estrutura de sistema de arquivos do Git e a utiliza para determinar para quais clusters ou namespaces uma configuração é relevante.

namespaces/

O diretório namespaces/ contém configurações para namespaces e objetos com escopo de namespace. A estrutura em namespaces/ é o mecanismo que impulsiona a herança de namespace. É possível limitar quais namespaces podem herdar um config usando um NamespaceSelector.

cluster/

O diretório cluster/ contém configurações que se aplicam a clusters inteiros, em vez de namespaces. Por padrão, qualquer configuração no diretório cluster/ se aplica a todos os clusters inscritos no Config Sync. É possível limitar quais clusters um config pode afetar usando um ClusterSelector.

clusterregistry/

O diretório clusterregistry/ é opcional e contém configurações para ClusterSelectors. ClusterSelectors limitam os clusters aos quais um config se aplica. Eles são referenciados nos configs encontrados nos diretórios cluster/ e namespaces/.

system/

O diretório system/ contém configs para o operador. Consulte Como instalar o Config Sync para mais informações sobre como configurá-lo.

Exemplo de repositório hierárquico

A estrutura de diretórios a seguir demonstra como usar um repo hierárquico do Config Sync para configurar um cluster do Kubernetes compartilhado por duas equipes diferentes, team-1 e team-2.

  • Cada equipe tem o próprio namespace do Kubernetes, a conta de serviço do Kubernetes, as cotas de recursos, as políticas de rede e os RoleBindings.
  • O administrador do cluster configura uma política em namespaces/limit-range.yaml para restringir as alocações de recursos (para pods ou contêineres) nos dois namespaces.
  • O administrador do cluster também configura ClusterRoles e ClusterRoleBinidngs.

Um repositório hierárquico válido do Config Sync precisa 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, ClusterRoleBinding) e não a namespaces.

O diretório namespaces/ contém configs para os objetos de namespace e os objetos com escopo de namespace. Cada subdiretório em namespaces/ inclui os configs de um objeto de namespace e todos os objetos com escopo de namespace no namespace. O nome de um subdiretório precisa ser igual ao nome do objeto de namespace. Os objetos com escopo de namespace que precisam ser criados em cada namespace podem ser colocados diretamente em namespaces/ (por exemplo, namespaces/limit-range.yaml).

O diretório system/ contém configs para o Config Management Operator.

├── 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

A seguir