Utiliser un dépôt hiérarchique

Cette page décrit comment Config Sync lit les fichiers de configuration configs à partir d'une source fiable hiérarchique et applique 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 une source fiable non structurée. Les sources fiables non structurées sont recommandées pour la plupart des cas d'utilisation. Si vous utilisez déjà une source fiable hiérarchique, vous pouvez la convertir en source fiable non structurée.

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

Structure du répertoire

Pour les sources hiérarchiques, Config Sync exploite les structures de type système de fichiers et utilise le répertoire pour 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.

Exemple de source fiable hiérarchique

La structure de répertoires suivante montre comment utiliser une source fiable 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 ClusterRoleBinding.

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

Utiliser l'héritage des espaces de noms et les espaces de noms d'extrait

Avec une source hiérarchique fiable, vous pouvez utiliser le concept d'héritage des espaces de noms pour appliquer automatiquement des configurations à des groupes d'espaces de noms dans tous les clusters où ces espaces de noms existent (ou devraient exister).

L'héritage des espaces de noms s'applique au répertoire namespaces/ du dépôt hiérarchique et à tous ses sous-répertoires. Les configurations des autres répertoires du dépôt, tels que cluster/, ne sont pas soumises au processus d'héritage.

Dans une source hiérarchique fiable, le répertoire namespaces/ peut contenir deux types de sous-répertoires différents :

  • Un répertoire d'espace de noms qui contient une configuration pour un objet Namespace. Le nom du fichier contenant la configuration n'est pas important, mais la configuration doit contenir kind: Namespace. Un répertoire d'espace de noms peut également inclure des configurations pour d'autres genres d'objets Kubernetes. Il ne peut pas contenir de sous-répertoires. Une configuration d'objet Namespace représente un objet Namespace réel d'un cluster.

  • Un répertoire d'espace de noms abstrait qui contient des répertoires d'espaces de noms. Il peut également inclure des configurations pour d'autres objets Kubernetes. En revanche, il ne peut pas contenir directement de configuration pour un objet Namespace. Un objet d'un cluster Kubernetes n'est pas représenté par un répertoire d'espace de noms abstrait, mais par les répertoires d'espaces de noms descendants de ce dernier.

Pour vous assurer que vos sources d'espaces de noms et d'espace de noms abstraits disposent du type de configuration et de structure appropriés, l'erreur KNV1003: IllegalNamespaceSubdirectoryError est signalée en cas de problème.

Les configurations dans un répertoire d'espace de noms ne s'appliquent qu'à cet espace de noms. Pourtant les configurations dans un répertoire d'espace de noms abstrait s'appliquent à tous les répertoires descendants de cet espace de noms abstrait (ou aux espaces de noms descendants qui correspondent à l'objet NamespaceSelector d'une configuration, le cas échéant).

L'héritage d'une configuration dans le répertoire namespaces/ est largement basé sur son emplacement dans l'arborescence de répertoires de la source fiable. Pour comprendre quelles configurations sont appliquées à un espace de noms particulier dans un cluster donné, vous pouvez parcourir l'exemple de dépôt d'héritage des espaces de noms.

Espaces de noms restreints

config-management-system est un espace de noms restreint. Vous ne pouvez pas l'utiliser comme répertoire d'espace de noms abstrait. Vous pouvez définir un espace de noms config-management-system, mais le seul type de ressource autorisé pour l'espace de noms config-management-system est RootSync.

Apporter des modifications à votre source fiable

Lorsque vous apportez une modification dans votre source fiable qui crée ou supprime des répertoires d'espaces de noms à partir du répertoire namespaces/, vous pouvez obtenir des résultats inattendus en fonction de l'action :

  • Créer un répertoire : lorsqu'une hiérarchie namespaces/ valide fait l'objet d'un commit dans la source fiable, Config Sync crée des espaces de noms, puis crée des objets Kubernetes dans ces espaces de noms pour chaque configuration que le répertoire d'espace de noms contient ou dont il hérite.
  • Supprimer un répertoire : la suppression d'un répertoire d'espace de noms est une opération destructive. L'espace de noms ainsi que son contenu sont supprimés sur chaque cluster géré par Config Sync où l'espace de noms est présent. Si vous supprimez un répertoire d'espace de noms abstrait contenant des répertoires d'espaces de noms descendants, tous ces objets Namespace et leur contenu sont supprimés de chaque cluster géré par Config Sync.

  • Renommer un répertoire : le changement de nom d'un répertoire d'espace de noms est une suppression, suivie d'une création. Cette opération est considérée comme une opération destructive. Le changement de nom d'un répertoire d'espace de noms abstrait n'a aucun effet visible de l'extérieur.

  • Déplacement d'un répertoire : Le déplacement d'un espace de noms ou d'un répertoire d'espace de noms abstrait dans namespaces/ n'a pas pour effet de supprimer l'espace de noms ni les objets qu'il contient, sauf si l'espace de noms commence à hériter d'une configuration à partir d'un répertoire d'espace de noms abstrait ou cesse d'en hériter, à la suite d'une modification de sa hiérarchie.

Étapes suivantes