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

Cette page décrit comment Anthos Config Management applique les configurations aux espaces de noms de vos clusters dans une hiérarchie, en fonction de la structure du dépôt.

Fonctionnement de l'héritage des espaces de noms

L'un des principaux avantages d'Anthos Config Management réside dans le fait qu'il peut appliquer automatiquement des configurations à des groupes d'objets Namespace dans tous les clusters où ces objets existent (ou devraient exister), en fonction de l'emplacement des configurations dans le dépôt.

Anthos Config Management introduit une notion d'héritage dans le répertoire namespaces/ du dépôt et dans 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, 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. 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:audit 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/online/ dans votre navigateur. Le répertoire online est un répertoire d'espace de noms abstrait, car il ne possède pas de configuration pour un objet Namespace. Cliquez sur le répertoire shipping-app-backend. Il s'agit également d'un répertoire d'espace de noms abstrait, qui contient deux configurations (pod-creator-rolebinding.yaml et quota.yaml). Chacun de ses trois sous-répertoires est un répertoire d'espace de noms, car il contient une configuration pour un objet Namespace. Même si le nom du fichier n'est pas significatif, ce dépôt l'utilise par convention pour toutes les configurations d'objets Namespace. Chacun de ces espaces de noms hérite des configurations pod-creator-rolebinding.yaml et quota.yaml dans le répertoire de l'espace de noms abstrait shipping-app-backend.

Le répertoire d'espace de noms shipping-dev contient une configuration supplémentaire pour l'objet RoleBinding job-creators. Toutefois, les deux autres répertoires d'espaces de noms ne comportent pas cette configuration et ne disposent donc pas du rôle RoleBinding (sauf si quelqu'un le crée manuellement).

Noms non autorisés dans namespaces/

Les éléments 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

Configurations d'objets Namespace

La configuration ci-dessous crée un objet Namespace appelé audit.

apiVersion: v1
kind: Namespace
metadata:
  name: audit

Lorsque vous créez une configuration d'objet Namespace, vous pouvez également ajouter un libellé à l'objet. Cela peut être utile si vous employez également NamespaceSelector.

La configuration suivante crée un objet Namespace appelé shipping-prod s'il n'existe pas ou s'il existe déjà sans le libellé configmanagement.gke.io/managed, et l'attribue à env: prod. Cela permet également de s'assurer qu'une annotation nommée audit est définie sur true pour l'objet Namespace. Si quelqu'un modifie ou supprime manuellement cette annotation, Anthos Config Management la redéfinit rapidement sur la valeur indiquée dans la configuration.

apiVersion: v1
kind: Namespace
metadata:
  name: shipping-prod
  labels:
    env: prod
  annotations:
    audit: "true"

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.

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, Anthos Config Management 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 Anthos Config Management 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 Anthos 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.

Étape suivante