Usar um 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. Se você já está usando um repositório hierárquico, converta-o em um repositório não estruturado.
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.
Exemplo de repositório hierárquico
A estrutura de diretórios a seguir demonstra como usar um repositório 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.yamlpara 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 raiz hierárquico 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 as
configurações 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 configurações para o Config Sync 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