Configurer des espaces de noms et des objets à l'échelle d'un espace de noms

Cette rubrique explique comment utiliser Config Sync pour gérer des espaces de noms et des objets à l'échelle d'un espace de noms.

Configurer un espace de noms

La configuration d'un espace de noms fonctionne différemment pour les dépôts non structurés et hiérarchiques. Les exemples suivants mettent en évidence les différences.

Dépôt non structuré

Les configurations pour les espaces de noms et les objets à l'échelle d'un espace de noms peuvent être situées n'importe où dans le répertoire ou les sous-répertoires du dépôt.

Pour configurer un espace de noms appelé gamestore dans chaque cluster enregistré, procédez comme suit :

  1. Créez un fichier namespace-gamestore.yaml avec le contenu suivant :

    apiVersion: v1
    kind: Namespace
    metadata:
      name: gamestore
    

    Il vous suffit de créer un fichier YAML contenant la configuration de l'espace de noms.

  2. Créez un commit incluant la configuration namespace-gamestore.yaml, puis transférez le commit vers le dépôt distant :

    git add multirepo/root/namespace-gamestore.yaml
    git commit -m "Created gamestore namespace config"
    git push REMOTE_NAME BRANCH_NAME
    

    Remplacez les éléments suivants :

    • REMOTE_NAME : nom du dépôt distant.
    • BRANCH_NAME: branche vers laquelle vous souhaitez effectuer un commit.

    Cet exemple ajoute le fichier au répertoire racine, mais vous pouvez le déplacer dans n'importe quel sous-répertoire du dépôt.

Dépôt hiérarchique

Toutes les configurations des espaces de noms et des objets définis à l'échelle d'un espace de noms se trouvent dans le répertoire namespaces/ du dépôt hiérarchique et ses répertoires descendants.

Pour configurer un espace de noms appelé gamestore dans chaque cluster enregistré, procédez comme suit :

  1. Dans le clone local de votre dépôt, créez un répertoire d'espace de noms. Un répertoire d'espace de noms contient une configuration pour un objet Namespace. Le nom du répertoire d'espace de noms doit correspondre au nom de l'objet Namespace. Dans cet exemple, le répertoire est appelé namespaces/gamestore :

    mkdir namespaces/gamestore
    
  2. Dans le répertoire d'espace de noms, créez un fichier gamestore.yaml avec le contenu suivant :

    apiVersion: v1
    kind: Namespace
    metadata:
      name: gamestore
    

    Le champ metadata.name doit correspondre au nom du répertoire d'espace de noms.

  3. Créez un commit incluant la configuration gamestore.yaml, puis transférez le commit vers le dépôt distant :

    git add namespaces/gamestore/gamestore.yaml
    git commit -m "Created gamestore namespace config"
    git push REMOTE_NAME BRANCH_NAME
    

    Remplacez les éléments suivants :

    • REMOTE_NAME : nom du dépôt distant.
    • BRANCH_NAME: branche vers laquelle vous souhaitez effectuer un commit.

Après quelques instants, l'espace de noms gamestore est créé dans chaque cluster enregistré. Pour le valider, décrivez l'objet Namespace :

kubectl describe namespace gamestore

Pour supprimer la configuration et supprimer l'espace de noms gamestore des clusters enregistrés, vous pouvez créer un commit qui supprime le fichier, puis le transférer vers le dépôt distant. Ne supprimez pas la configuration si vous souhaitez configurer un espace de noms abstrait pour un dépôt hiérarchique.

Configurer un objet à l'échelle d'un espace de noms

Dans les dépôts non structurés, vous pouvez stocker des objets à l'échelle d'un espace de noms dans n'importe quel répertoire ou sous-répertoire sans avoir besoin d'une configuration d'espace de noms. Si une configuration d'espace de noms est manquante, Config Sync crée automatiquement un objet d'espace de noms implicite et applique toutes les configurations à cet espace de noms.

Ce comportement peut être modifié à l'aide du champ namespaceStrategy. Si namespaceStrategy est défini sur explicit, Config Sync ne crée pas automatiquement d'objet d'espace de noms implicite. Pour en savoir plus, consultez la section Stratégie d'espace de noms.

Dans les dépôts hiérarchiques, vous devez spécifier explicitement une configuration d'espaces de noms dans le sous-répertoire namespaces/NAMESPACE, où NAMESPACE doit correspondre au nom de l'espace de noms. Toutes les autres configurations à l'échelle d'un espace de noms doivent également être stockées dans le même sous-répertoire. Si une configuration d'espace de noms est manquante, Config Sync renvoie une erreur KNV1044, indiquant une configuration d'espace de noms manquante.

Configurer un espace de noms abstrait

Cette section ne s'applique qu'aux dépôts hiérarchiques, car les espaces de noms abstraits ne sont pas compatibles avec les dépôts non structurés.

Cet exemple élargit l'exemple de la section Configurer un espace de noms en déplaçant le répertoire d'espace de noms gamestore dans un espace de noms abstrait contenant des configurations supplémentaires héritées par l'espace de noms gamestore.

  1. Dans le clone local du dépôt, créez un répertoire d'espace de noms abstrait appelé eng :

    mkdir namespaces/eng
    

    Un répertoire d'espace de noms abstrait ne contient pas de configuration pour un objet Namespace, contrairement à ses répertoires d'espaces de noms descendants.

  2. Dans le répertoire d'espace de noms abstrait eng, créez une configuration pour un rôle appelé eng-viewer qui accorde get et list sur toutes les ressources de n'importe quel espace de noms qui hérite du rôle :

    # namespaces/eng/eng-role.yaml
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: eng-viewer
    rules:
    - apiGroups: [""]
      resources: ["*"]
      verbs: ["get", "list"]
    
  3. Créez une configuration pour un objet RoleBinding appelé eng-admin qui lie le rôle eng-viewer au groupe eng@example.com :

    # namespaces/eng/eng-rolebinding.yaml
    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: eng-admin
    subjects:
    - kind: Group
      name: eng@example.com
      apiGroup: rbac.authorization.k8s.io
    roleRef:
      kind: Role
      name: eng-viewer
      apiGroup: rbac.authorization.k8s.io
    
  4. Déplacez le répertoire d'espaces de noms gamestore du répertoire namespaces/ vers le répertoire namespaces/eng/ :

    mv namespaces/gamestore /namespaces/eng/
    
  5. Validez toutes vos modifications et transférez-les vers le dépôt distant.

Config Sync remarque la modification et applique le nouveau rôle et l'objet RoleBinding à l'espace de noms gamestore sur tous les clusters enregistrés.

Pour supprimer les configurations et supprimer l'objet Namespace gamestore des clusters enregistrés, vous pouvez créer un commit qui supprime la totalité de l'espace de noms abstrait eng, puis le transférer vers le dépôt distant.

Limiter les clusters affectés par une configuration

Généralement, Config Sync applique une configuration à chaque cluster enregistré. Cependant, si la configuration se trouve dans le sous-répertoire namespaces/ d'un dépôt hiérarchique, Config Sync crée d'abord l'espace de noms dans chaque cluster, puis applique toutes les configurations héritées à cet espace de noms. Pour limiter les clusters affectés par une configuration spécifique en fonction des libellés de chaque cluster, utilisez un objet ClusterSelector. Pour en savoir plus, consultez la page Utiliser des objets ClusterSelector.

Limiter les espaces de noms affectés par une configuration

Pour limiter les espaces de noms affectés par une configuration, utilisez un objet NamespaceSelector. NamespaceSelector est un type spécial de configuration qui utilise les objets labelSelector Kubernetes. Vous pouvez déclarer des objets NamespaceSelector en association avec des configurations pour des objets à l'échelle d'un espace de noms dans un dépôt non structuré ou dans un dépôt hiérarchique afin de limiter les espace de noms pouvant hériter de cette configuration. Les objets NamespaceSelector ressemblent aux objets ClusterSelectors, mais sont légèrement différents. Un objet NamespaceSelector limite le pool d'espaces de noms auxquels une configuration s'applique.

Pour déclarer un objet NamespaceSelector, ajoutez l'annotation metadata.namespace ou NamespaceSelector. Le fait de déclarer les deux annotations n'est pas valide. Si les ressources à l'échelle de l'espace de noms ne déclarent pas metadata.namespace ou l'annotation NamespaceSelector, Config Sync utilise l'espace de noms "par défaut" du cluster.

Objets NamespaceSelector dans les dépôts non structurés

Un dépôt non structuré n'a pas besoin de déclarer tous les espaces de noms pour les objets à l'échelle d'un espace de noms dans le dépôt. Un objet peut définir un metadata.namespace sans posséder d'objet d'espace de noms correspondant dans un dépôt non structuré. Si l'espace de noms existe déjà sur le cluster, Config Sync crée l'objet dans cet espace de noms. Si l'espace de noms n'existe pas encore sur le cluster, Config Sync le crée implicitement.

Avant de créer un dépôt non structuré avec des objets précédemment utilisés dans un dépôt hiérarchique, vérifiez que vos objets NamespaceSelectors ne s'appliquent pas aux autres ressources.

Lorsque vous supprimez des objets à l'échelle d'un espace de noms d'un dépôt non structuré, Config Sync supprime ces objets, mais ne supprime aucun espace de noms qui aurait pu être créé implicitement pour ces objets. Cela est dû au fait que Config Sync ne peut pas déterminer à quel moment il peut supprimer sans risques un espace de noms créé implicitement, et donc laisse toujours cet espace de noms dans le cluster.

Mode NamespaceSelector

Dans un dépôt non structuré, les objets qui déclarent l'annotation NamespaceSelector sont appliqués à tous les espaces de noms qui satisfont aux conditions de l'objet NamespaceSelector. Dans les versions de Config Sync antérieures à 1.17.0, l'annotation NamespaceSelector ne s'applique qu'aux espaces de noms correspondants qui sont déclarés de manière statique dans la source fiable. Dans les versions 1.17.0 et ultérieures, l'objet NamespaceSelector accepte le mode dynamique en définissant spec.mode sur dynamic. En mode dynamique, la sélection s'étend aux espaces de noms déclarés de manière statique et à ceux présents dans le cluster de manière dynamique. Les espaces de noms choisis dynamiquement existent déjà sur le cluster et ne sont donc pas gérés par Config Sync. Le mode par défaut est static.

Objets NamespaceSelector dans les dépôts hiérarchiques

Dans un dépôt hiérarchique, les objets qui déclarent l'annotation NamespaceSelector sont appliqués aux espaces de noms qui héritent d'une configuration donnée d'un espace de noms abstrait, quelle que soit la structure du répertoire namespaces/. Un objet ClusterSelector limite le groupe de clusters auquel une configuration s'applique, que la configuration cible un objet à l'échelle d'un cluster ou à l'échelle d'un espace de noms.

Emplacement de l'objet NamespaceSelector

Dans un dépôt non structuré, vous pouvez placer les objets NamespaceSelector dans n'importe quel répertoire ou sous-répertoire.

Dans un dépôt hiérarchique, vous pouvez placer les objets NamespaceSelector dans n'importe quel répertoire d'espace de noms abstrait, mais pas dans un répertoire d'espace de noms.

L'exemple d'architecture de dépôt suivant montre les emplacements valides et non valides pour les objets NamespaceSelector si vous utilisez un dépôt hiérarchique :

namespace-inheritance
...
├── namespaces
│   ├── eng
│   │   ├── gamestore
│   │   │   ├── namespace.yaml
│   │   │   └── ns_selector.yaml  # invalid
│   │   └── ns_selector.yaml  # valid
│   ├── ns_selector.yaml  # valid
│   ├── rnd
│   │   ├── incubator-1
│   │   │   ├── namespace.yaml
│   │   │   └── ns_selector.yaml  # invalid
│   │   └── ns_selector.yaml  # valid

Comme les répertoires namespaces, eng et rnd représentent des espaces de noms abstraits, vous pouvez y ajouter un sélecteur. Toutefois, du fait que les répertoires gamestore et incubator-1 représentent des espaces de noms réels, vous ne pouvez pas y inclure d'objet NamespaceSelector.

Exemples d'objets NamespaceSelector

Vous pouvez utiliser un NamespaceSelector avec des sélecteurs de libellés pour inclure ou exclure des espaces de noms. Kubernetes est compatible avec les sélecteurs basés sur l'égalité et sur des ensembles. Vous pouvez combiner les deux types de sélecteurs pour affiner davantage les espaces de noms sélectionnés.

Sélecteur de libellés basé sur l'égalité

La configuration suivante crée un objet NamespaceSelector appelé gamestore-selector. Si une autre configuration référence cet objet NamespaceSelector, elle ne peut être appliquée qu'aux objets présents dans les objets Namespace portant le libellé app: gamestore.

kind: NamespaceSelector
apiVersion: configmanagement.gke.io/v1
metadata:
  name: gamestore-selector
spec:
  selector:
    matchLabels:
      app: gamestore

Pour référencer un objet NamespaceSelector dans une configuration, définissez l'annotation configmanagement.gke.io/namespace-selector sur le nom de l'objet NamespaceSelector.

Un objet NamespaceSelector n'a aucun effet tant que vous ne le référencez pas dans une autre configuration. Si l'objet NamespaceSelector gamestore-selector se trouve dans la même hiérarchie que l'objet ResourceQuota suivant, quota, l'objet ResourceQuota n'est créé que dans les espaces de noms auxquels le libellé app: gamestore est appliqué :

kind: ResourceQuota
apiVersion: v1
metadata:
  name: quota
  annotations:
    configmanagement.gke.io/namespace-selector: gamestore-selector
spec:
  hard:
    pods: "1"
    cpu: "200m"
    memory: "200Mi"

En résumé, vous devez suivre les trois étapes suivantes pour utiliser un objet NamespaceSelector :

  1. Ajouter des libellés aux objets Namespace
  2. Créer une configuration d'objet NamespaceSelector
  3. Référencer l'objet NamespaceSelector dans une autre configuration

Sélecteur de libellés basé sur des ensembles

Vous pouvez utiliser des sélecteurs d'espace de noms pour empêcher des espaces de noms spécifiques d'hériter d'une ressource de l'arborescence à l'aide de sélecteurs de libellés basés sur des ensembles.

Dans cet exemple, lorsque la requête ResourceQuota est annotée avec le NamespaceSelector en définissant l'annotationconfigmanagement.gke.io/namespace-selector: excludes-exempt-namespaces, ResourceQuota est créé dans chaque espace de noms, à l'exception des espaces de noms auxquels un libellé quota-exempt: exempt est attribué :

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

Intégration avec les niveaux d'accès d'équipe et les espaces de noms de parc

Les espaces de noms de parc créés dans Google Cloud portent automatiquement le libellé fleet.gke.io/fleet-scope: your-scope. Tous les espaces de noms comportent également le libellé Kubernetes kubernetes.io/metadata.name: your-namespace. Vous pouvez utiliser ces libellés par défaut pour configurer le NamespaceSelector afin de sélectionner des espaces de noms de parc.

Désactiver l'héritage pour un type d'objet

Les objets Kubernetes HierarchyConfig ne sont pas compatibles avec les dépôts non structurés. L'exemple suivant ne s'applique qu'aux dépôts hiérarchiques.

Vous pouvez désactiver de manière sélective l'héritage de toute configuration en définissant le champ hierarchyMode sur none. Les ressources HierarchyConfig sont stockées dans le répertoire system/ du dépôt. Dans l'exemple ci-dessous, l'héritage est désactivé pour les objets RoleBinding.

# system/hierarchy-config.yaml
kind: HierarchyConfig
apiVersion: configmanagement.gke.io/v1
metadata:
  name: rbac
spec:
  resources:
  # Configure Role to only be allowed in leaf namespaces.
  - group: rbac.authorization.k8s.io
    kinds: [ "RoleBinding" ]
    hierarchyMode: none

Étape suivante