Présentation de l'héritage des espaces de noms

Cette page décrit la manière dont Config Sync applique les configurations aux espaces de noms de vos clusters dans une hiérarchie, en fonction de la structure du dépôt hiérarchique. Vous pouvez également en savoir plus sur la configuration des espaces de noms et des objets à l'échelle d'un espace de noms. Pour les dépôts non structurés, Hierarchy Controller peut être utilisé pour des fonctionnalités similaires.

Fonctionnement de l'héritage des espaces de noms

L'un des aspects les plus puissants de Config Sync est la possibilité d'appliquer automatiquement des configurations à des groupes d'espaces de noms, dans tous les clusters où ces espaces de noms existent (ou devraient exister), en fonction de l'emplacement des configurations située dans un dépôt hiérarchique.

Config Sync introduit une notion d'héritage dans le répertoire namespaces/ du dépôt et de 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 le dépôt 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.

Si vous oubliez d'inclure une configuration pour un objet Namespace dans un répertoire d'espace de noms, si vous ajoutez un répertoire à un sous-répertoire d'espace de noms ou si vous incluez une configuration pour un objet Namespace dans un répertoire d'espace de noms abstrait, l'erreur KNV1003: IllegalNamespaceSubdirectoryError est renvoyée.

Les configurations dans un répertoire d'espace de noms ne s'appliquent qu'à cet espace de noms, tandis que 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).

Étant donné que l'héritage d'une configuration dans le répertoire namespaces/ est largement basé sur son emplacement dans l'arborescence de répertoires du dépôt, vous pouvez parcourir celui-ci pour savoir quelles configurations sont appliquées à un objet Namespace particulier dans un cluster donné.

Le schéma suivant montre comment les configurations sont héritées dans le répertoire namespaces/ de l'exemple de dépôt d'héritage des espaces de noms. Les rectangles bleus représentent les répertoires d'espaces de noms abstraits, tandis que les rectangles orange correspondent aux objets Namespace qui sont réellement présents dans Kubernetes.

Schéma illustrant le processus d'héritage des configurations dans l'exemple de dépôt

Par exemple, ouvrez le fichier viewers-rolebinding.yaml dans votre navigateur. Il attribue à tout utilisateur du groupe system:serviceaccounts:foo le rôle ClusterRole view dans chaque objet Namespace géré par Anthos Config Management sur tous les clusters enregistrés, car il figure dans le répertoire namespaces.

Maintenant, ouvrez le répertoire namespaces/eng/ dans votre navigateur. Le répertoire eng est un répertoire d'espace de noms abstrait, car il ne possède pas de configuration pour un objet Namespace. Il contient les configurations suivantes :

  • eng-role.yaml
  • eng-rolebinding.yaml
  • network-policy-allow-gamestore-ingress.yaml
  • quota.yaml
  • selectors.yaml

Chacun de ses trois sous-répertoires est un répertoire d'espace de noms, car il contient une configuration pour un espace de noms. Même si le nom du fichier n'est pas significatif, ce dépôt l'utilise par convention pour toutes les configurations des espaces de noms. Chacun de ces espaces de noms hérite des configurations eng-role.yaml, eng-rolebinding.yaml et network-policy-allow-gamestore-ingress.yamldans le répertoire de l'espace de noms abstrait eng. L'objet ResourceQuota défini dans quota.yaml ne s'applique qu'à l'espace de noms qui correspond à l'objet NamespaceSelector correspondant.

La page de l'espace de noms gamestore contient une configuration supplémentaire pour l'objet RoleBinding bob-rolebinding mais le dépôt de l'espace de noms analytics ne contient pas cette configuration. Il ne possède donc pas cet objet RoleBinding (sauf si quelqu'un le crée manuellement).

Noms non autorisés dans namespaces/

Les noms suivants sont réservés et ne peuvent pas être utilisés pour les objets Namespace ou les répertoires d'espaces de noms abstraits dans le répertoire namespaces/ du dépôt :

  • config-management-system

Exemples de configurations

Configuration de l'objet ResourceQuota

L'exemple ci-dessous crée un objet ResourceQuota appelé quota, qui définit une limite stricte de 1 pod, 0,1 CPU (100 millièmes de temps CPU) et 100 Mio de mémoire.

kind: ResourceQuota
apiVersion: v1
metadata:
  name: quota
spec:
  hard:
    pods: "1"
    cpu: "100m"
    memory: 100Mi

Si vous placez cette configuration dans un répertoire qui s'applique à un objet Namespace spécifique (namespaces/[NAMESPACE_NAME]), la configuration s'applique uniquement à cet objet Namespace. Si vous placez cette configuration dans un répertoire d'espace de noms abstrait (namespaces/) qui contient des objets Namespace descendants, un objet ResourceQuota distinct est appliqué à chaque objet Namespace descendant. Si vous créez un objet ResourceQuota avec une annotation NamespaceSelector, la configuration ne s'applique qu'aux objets Namespace qui correspondent à l'objet NamespaceSelector.

Exclure des espaces de noms de l'héritage

Les sélecteurs d'espace de noms peuvent être utilisés pour empêcher des espaces de noms spécifiques d'hériter d'une ressource de l'arborescence.

L'exemple suivant permet à un objet ResourceQuota correctement annoté dans le répertoire racine /namespaces d'être hérité par chaque espace de noms, à l'exception de ceux portant le libellé quota-exempt: exempt :

kind: NamespaceSelector
 apiVersion: configmanagement.gke.io/v1
 metadata:
   name: excludes-exempt-namespaces
 spec:
   selector:
     matchExpressions:
       - key: quota-exempt
         operator: NotIn
          values:
            - exempt

Pour en savoir plus sur NamesspaceSelectors dans Config Sync, consultez la section Limiter les objets Namespace affectés par une configuration.

Effets des opérations Git sur les espaces de noms

Les opérations Git qui créent ou suppriment des répertoires d'espaces de noms à partir du répertoire namespaces/ peuvent avoir des effets différents de ceux initialement prévus. Cette section décrit ces interactions.

Créer un répertoire dans namespaces/

Lorsqu'une hiérarchie namespaces/ valide fait l'objet d'un commit dans le dépôt, Config Sync crée des objets Namespace. Il crée ensuite des objets Kubernetes dans ces objets Namespace pour chaque configuration que le répertoire d'espace de noms contient ou dont il hérite.

Supprimer un répertoire de namespaces/

La suppression d'un répertoire d'espace de noms est une opération destructive. L'objet Namespace est supprimé, ainsi que tout son contenu, sur chaque cluster géré par Config Sync où il 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 dans namespaces/

Le changement de nom d'un répertoire d'espace de noms se traduit par une suppression, suivie d'une création. Il s'agit donc également d'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éplacer un répertoire dans namespaces/

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

Intégration avec Hierarchy Controller

Le concept d'héritage d'espace de noms de Hierarchy Controller est très semblable à celui compatible avec les espaces de noms abstraits, comme décrit dans la documentation de Hierarchy Controller. Cependant, ils sont compatibles avec certaines fonctionnalités supplémentaires, telles que les quotas de ressources hiérarchiques et les espaces de noms en libre-service.

Sélectionner des espaces de noms associés

Il peut arriver que vous souhaitiez appliquer des stratégies à des ensembles d'espaces de noms liés par un ancêtre commun. Hierarchy Controller est compatible avec cette fonctionnalité grâce au concept appelé libellés d'arborescence, qui sont également compatibles avec les espaces de noms abstraits, même si Hierarchy Controller n'est pas activé.

Les libellés d'arborescence sont des libellés Kubernetes qui se présentent au format suivant :

<namespace-name>.tree.hnc.x-k8s.io/depth: <depth>

Ces libellés vous permettent d'écrire des sélecteurs d'espace de noms pouvant, par exemple, être utilisés dans le cadre d'une règle de réseau pour autoriser le trafic dans une sous-arborescence des espaces de noms associés, mais interdire le trafic en dehors de cette sous-arborescence.

Nous pouvons illustrer ce concept en revenant au schéma de l'exemple de dépôt.

Schéma illustrant le processus d&#39;héritage des configurations dans l&#39;exemple de dépôt

Par exemple, l'espace de noms gamestore comporte les libellés d'arborescence suivantes :

eng.tree.hnc.x-k8s.io/depth: "1"
gamestore.tree.hnc.x-k8s.io/depth: "0"

Vous pouvez utiliser kubectl pour inspecter ces relations directement sur le cluster, sans avoir accès au dépôt Git :

# View all descendants of 'eng'
kubectl get namespaces -l 'eng.tree.hnc.x-k8s.io/depth'

# View any immediate children of 'eng'
kubectl get namespaces -l 'eng.tree.hnc.x-k8s.io/depth=1'

Hierarchy Controller propage également les libellés d'arborescence des espaces de noms abstraits dans les espaces de noms descendants. Par exemple, si vous créez un espace de noms enfant de gamestore comme suit :

kubectl hns create gamestore-v1 -n gamestore

Dans ce cas, l'espace de noms gamestore-v1 inclut tous les libellés du parent, ainsi que les siens, avec une profondeur ajustée de manière appropriée :

eng.tree.hnc.x-k8s.io/depth: 2
gamestore-v1.tree.hnc.x-k8s.io/depth: 0
gamestore.tree.hnc.x-k8s.io/depth: 1

Étape suivante