Utiliser un dépôt hiérarchique

Cette page décrit comment Config Sync lit les configurations à partir d'une source de référence hiérarchique et applique automatiquement la configuration obtenue à vos clusters.

Si vous souhaitez plus de flexibilité structurelle (par exemple, vous souhaitez créer des sous-dossiers de ressources), vous pouvez créer une source d'informations non structurée. Des sources de référence non structurées sont recommandées pour la plupart des cas d'utilisation. Si vous utilisez déjà une source de vérité hiérarchique, vous pouvez la convertir en source de vérité non structurée.

Pour comprendre comment Config Sync utilise un dépôt hiérarchique, il est utile de connaître 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 déterminer les clusters ou les espaces de noms auxquels une configuration est pertinente.

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 ClusterSelectors. 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 de référence 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 stratégie 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 ClusterRoles et les ClusterRoleBindings.

Une source 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 l'opérateur 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

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

Avec une source de référence hiérarchique, vous pouvez utiliser le concept d'héritage d'espace de noms pour appliquer automatiquement des configurations aux 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 de référence hiérarchique, 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'espaces de noms abstraits disposent du type de configuration et de structure approprié, l'erreur KNV1003: IllegalnamespaceSubdirectoryError signale un problème.

Les configurations d'un répertoire d'espace de noms ne s'appliquent qu'à cet espace de noms. Toutefois, les configurations d'un répertoire d'espace de noms abstrait sont appliquées à tous les répertoires d'espaces de noms 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 de référence

Lorsque vous apportez une modification à votre source de référence qui crée ou supprime des répertoires d'espaces de noms dans le 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 est validée dans la source de référence, 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 hérite.
  • Suppression d'un répertoire: la suppression d'un répertoire d'espace de noms est une opération destructive. L'espace de noms et son contenu sont supprimés sur chaque cluster géré par Config Sync où il existe. Si vous supprimez un répertoire d'espace de noms abstrait contenant des répertoires d'espaces de noms descendants, tous ces espaces de noms 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 opération de suppression, suivie d'une création. Cette opération est considérée comme une opération destructive. Renommer un répertoire d'espace de noms abstrait n'a aucun effet visible de l'extérieur.

  • Déplacer un répertoire: déplacer un espace de noms ou un répertoire d'espace de noms abstrait dans namespaces/ n'entraîne pas la suppression de l'espace de noms ni des objets qu'il contient, sauf si l'espace de noms commence à hériter ou cesse d'hériter d'une configuration d'un répertoire d'espace de noms abstrait en raison d'une modification de sa hiérarchie.

Étapes suivantes