Introduction aux Namespaces pour l'isolation logique (utiliser autre chose que `default`)

Le défi de l'organisation dans un cluster partagé

Imaginez un unique cluster Kubernetes utilisé par plusieurs équipes, pour différents projets ou pour héberger plusieurs environnements (développement, pré-production, production). Sans mécanisme de séparation, la situation peut rapidement devenir chaotique. Comment s'assurer qu'une équipe ne supprime pas accidentellement les ressources d'une autre ? Comment éviter les conflits si deux projets veulent déployer un service nommé 'database' ? Comment répartir équitablement les ressources du cluster ?

C'est ici qu'interviennent les Namespaces. Considérez-les comme des sous-clusters virtuels au sein de votre cluster physique Kubernetes. Ils fournissent un moyen de diviser les ressources du cluster entre plusieurs utilisateurs ou groupes d'utilisateurs. Chaque namespace agit comme une portée (scope) isolée pour les objets qu'il contient.

Par défaut, Kubernetes fournit un namespace nommé `default`. Lorsque vous débutez et créez des ressources sans spécifier de namespace, elles atterrissent automatiquement dans `default`. Si cela est pratique pour des tests rapides, s'appuyer uniquement sur ce namespace pour toutes vos applications est une mauvaise pratique. Cela conduit à un manque de clarté, augmente le risque de conflits de noms et rend difficile la gestion des permissions et des ressources à mesure que l'utilisation du cluster augmente. La règle d'or est donc d'utiliser des namespaces dédiés pour organiser vos charges de travail.

Comprendre le fonctionnement et la portée des Namespaces

La fonction principale d'un namespace est de fournir une portée pour les noms des ressources. Cela signifie qu'un nom de ressource (comme un Pod, un Service, un Deployment) doit être unique *au sein* d'un namespace donné, mais le même nom peut être réutilisé dans un autre namespace. Par exemple, vous pouvez avoir un `Deployment` nommé `mon-app` dans le namespace `projet-alpha` et un autre `Deployment` également nommé `mon-app` dans le namespace `projet-beta` sans aucun conflit.

Il est crucial de comprendre que toutes les ressources Kubernetes ne sont pas liées à un namespace. Certaines ressources sont globales au cluster. C'est le cas des Noeuds (Nodes), des PersistentVolumes (PVs), des StorageClasses, des ClusterRoles, des ClusterRoleBindings, et des Namespaces eux-mêmes. D'autres, comme les Pods, Services, Deployments, ReplicaSets, ConfigMaps, Secrets, Roles, RoleBindings, NetworkPolicies, ResourceQuotas, LimitRanges, sont associées à un namespace spécifique. Vous pouvez vérifier si un type de ressource est lié à un namespace avec la commande :

kubectl api-resources --namespaced=true # Ressources liées à un namespace
kubectl api-resources --namespaced=false # Ressources globales au cluster

Concernant l'isolation réseau, il est important de noter que par défaut, les Pods peuvent communiquer entre eux, même s'ils se trouvent dans des namespaces différents. Les namespaces fournissent une isolation logique et de nommage, mais pas une isolation réseau stricte par défaut. Pour contrôler le trafic entre les Pods (y compris entre différents namespaces), vous devez utiliser des objets `NetworkPolicy`, qui sont eux-mêmes des ressources liées à un namespace.

Création et utilisation pratique des Namespaces

Créer un nouveau namespace est une opération simple. Vous pouvez le faire directement via la ligne de commande `kubectl` :

kubectl create namespace mon-projet-dev

Alternativement, et conformément à l'approche déclarative, vous pouvez définir un namespace dans un fichier YAML et l'appliquer :

# namespace-dev.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: mon-projet-dev
  labels:
    usage: development # Vous pouvez aussi ajouter des labels aux namespaces

Appliquez ensuite ce fichier :

kubectl apply -f namespace-dev.yaml

Pour créer une ressource dans un namespace spécifique, vous avez deux options. Soit vous utilisez l'option `-n` (ou `--namespace`) avec `kubectl` :

kubectl apply -f mon-deployment.yaml -n mon-projet-dev

# mon-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mon-app-deployment
  namespace: mon-projet-dev # Spécification directe du namespace
spec:
  replicas: 2
  selector:
    matchLabels:
      app: mon-app
  template:
    metadata:
      labels:
        app: mon-app
    spec:
      containers:
      - name: mon-app-container
        image: nginx

Pour interagir avec les ressources d'un namespace donné, utilisez l'option `-n` :

kubectl get pods -n mon-projet-dev
kubectl logs mon-pod-xyz -n mon-projet-dev

kubectl get pods --all-namespaces

kubectl config set-context --current --namespace=mon-projet-dev

Bénéfices concrets et bonnes pratiques d'utilisation

L'avantage le plus évident de l'utilisation des namespaces est l'organisation. Regrouper les ressources par projet, équipe, application ou environnement (dev, staging, prod) rend le cluster beaucoup plus facile à comprendre et à gérer. Cela évite la confusion et le désordre qui peuvent régner dans un namespace `default` surchargé.

Les namespaces sont la base du contrôle d'accès basé sur les rôles (RBAC - Role-Based Access Control) dans Kubernetes. Les objets `Role` (qui définissent des permissions sur les ressources) et `RoleBinding` (qui lient ces permissions à des utilisateurs ou groupes) sont spécifiques à un namespace. Cela vous permet d'accorder des droits précis à différentes équipes sur leurs propres namespaces, sans leur donner accès aux ressources des autres ou aux ressources globales du cluster. C'est essentiel pour la sécurité et la mise en oeuvre de scénarios multi-locataires (multi-tenancy) de base.

Un autre bénéfice majeur est la capacité à gérer la consommation des ressources par namespace grâce aux objets ResourceQuota et LimitRange. Un `ResourceQuota` permet de définir des limites sur la quantité totale de ressources (CPU, mémoire, nombre de Pods, de Services, etc.) qu'un namespace peut consommer. Un `LimitRange` permet de définir des contraintes par défaut (requêtes/limites minimales/maximales) pour les conteneurs créés dans le namespace. Cela empêche une application ou une équipe de monopoliser les ressources du cluster.

En résumé, les bonnes pratiques consistent à : créer systématiquement des namespaces dédiés pour chaque projet, application ou environnement logique distinct ; éviter d'utiliser le namespace `default` pour vos applications ; utiliser RBAC et ResourceQuotas pour sécuriser et contrôler l'utilisation des ressources par namespace ; et bien sûr, ne pas déployer d'applications utilisateur dans les namespaces système comme `kube-system`.

Les Namespaces système et points clés à retenir

Outre le namespace `default`, Kubernetes crée automatiquement quelques autres namespaces pour son propre fonctionnement. Il est important de les connaître et de ne généralement pas y toucher : `kube-system` contient les composants essentiels du plan de contrôle Kubernetes (API Server, etcd, scheduler, controller manager, kube-proxy, CoreDNS, etc.). `kube-public` est un namespace lisible par tous les utilisateurs (même non authentifiés) et est parfois utilisé pour exposer des informations publiques sur le cluster. `kube-node-lease` est utilisé en interne pour les mécanismes de bail (lease) des noeuds, permettant de détecter leur état.

Le point essentiel à retenir est que les Namespaces constituent un outil fondamental pour la partition logique et l'organisation au sein d'un cluster Kubernetes. Ils fournissent une portée pour les noms, une base pour le contrôle d'accès et la gestion des quotas de ressources.

Adopter une stratégie claire d'utilisation des namespaces dès le début de vos déploiements Kubernetes vous évitera bien des maux de tête par la suite. C'est une pratique indispensable pour maintenir un cluster ordonné, sécurisé et gérable, surtout dans des environnements partagés ou complexes.