Présentation du dépôt hiérarchique

Cette page décrit comment Config Sync lit les fichiers de configuration configs à partir d'un dépôt hiérarchique afin d'appliquer automatiquement la configuration obtenue à vos clusters.

Si vous souhaitez plus de flexibilité structurelle (par exemple, pour créer des sous-dossiers de ressources), vous pouvez créer un dépôt non structuré. Les dépôts non structurés sont recommandés pour la plupart des utilisateurs et peuvent être combinés avec Hierarchy Controller pour fournir un héritage d'espace de noms semblable à celui proposé par les dépôts hiérarchiques.

Pour comprendre comment Config Sync utilise un dépôt hiérarchique, il est utile que vous maîtrisez les dépôts Git et l'interface de ligne de commande git.

Structure de dépôt hiérarchique

Pour les dépôts hiérarchiques, Config Sync exploite la structure de Git (semblable à un système de fichiers) afin d'identifier les clusters ou espaces de noms auxquels une configuration est adaptée.

namespaces/

Le répertoire namespaces/ contient les configurations associées aux espaces de noms et aux objets à l'échelle d'un espace de noms. La structure de namespaces/ est le mécanisme qui gère le processus d'héritage des espaces de noms. Vous pouvez limiter les espaces de noms pouvant hériter d'une configuration à l'aide d'un objet NamespaceSelector.

cluster/

Le répertoire cluster/ contient des configurations qui s'appliquent à des clusters entiers plutôt qu'à des espaces de noms. Par défaut, toute configuration du répertoire cluster/ s'applique à chaque cluster inscrit dans Config Sync. Vous pouvez limiter les clusters susceptibles d'être affectés par une configuration en utilisant un objet ClusterSelector.

clusterregistry/

Le répertoire clusterregistry/ est facultatif et contient les configurations associées aux objets ClusterSelector. Ces objets limitent les clusters auxquels une configuration s'applique et sont référencés dans les configurations trouvées dans les répertoires cluster/ et namespaces/.

system/

Le répertoire system/ contient des configurations pour l'opérateur. Pour plus d'informations sur la configuration de Config Sync, consultez la section Installer Config Sync.

Exemple de dépôt hiérarchique

La structure de répertoires suivante montre comment utiliser un dépôt hiérarchique Config Sync pour configurer un cluster Kubernetes partagé par deux équipes différentes, team-1 et team-2.

  • Chaque équipe dispose de son propre espace de noms Kubernetes, d'un compte de service Kubernetes, de quotas de ressources, de règles de réseau et de liaisons de rôles.
  • L'administrateur du cluster configure une règle dans namespaces/limit-range.yaml pour limiter les allocations de ressources (aux pods ou aux conteneurs) dans les deux espaces de noms.
  • L'administrateur du cluster configure également les objets ClusterRole et ClusterRoleBinidngs.

Un dépôt hiérarchique Config Sync valide doit inclure trois sous-répertoires : cluster/, namespaces/ et system/.

Le répertoire cluster/ contient les configurations qui s'appliquent à des clusters entiers (tels que ClusterRole et ClusterRoleBinding) plutôt qu'à des espaces de noms.

Le répertoire namespaces/ contient les configurations associées aux objets d'espace de noms ainsi qu'aux objets à l'échelle d'un espace de noms. Chaque sous-répertoire situé sous namespaces/ inclut les configurations d'un objet d'espace de noms ainsi tous les objets à l'échelle d'un espace de noms situés sous l'espace de noms. Le nom d'un sous-répertoire doit être identique à celui de l'objet d'espace de noms. Les objets à l'échelle d'un espace de noms qui doivent être créés dans chaque espace de noms peuvent être placés directement sous namespaces/ (par exemple, namespaces/limit-range.yaml).

Le répertoire system/ contient des configurations pour 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

Étape suivante