infra / kubernetes

Namespaces

Leçon 91 exercice

Explication

Ce que vous allez apprendre

Expliquer pourquoi les Namespaces existent pour cloisonner logiquement plusieurs équipes, projets ou environnements dans un même cluster
Distinguer ce qu'un Namespace isole réellement (les noms) de ce qu'il n'isole PAS par défaut (le réseau, les ressources machine)
Appliquer un ResourceQuota pour plafonner la consommation CPU/mémoire/Pods d'un namespace entier
Utiliser un LimitRange pour fixer des valeurs par défaut ou des bornes au niveau d'un Pod individuel
Relier le Namespace aux NetworkPolicy (leçon 19) pour obtenir une vraie isolation réseau quand c'est nécessaire

Dans quel contexte ?

Deux équipes (paiement et notifications) partagent le même cluster de production. L'équipe paiement crée un Deployment nommé "api" dans son namespace payment, et l'équipe notifications fait exactement la même chose dans son namespace notifications, sans aucun conflit malgré le nom identique. Mais un audit de sécurité révèle ensuite que les Pods du namespace notifications, censé être moins sensible, peuvent communiquer librement en réseau avec les Pods du namespace payment : le Namespace, à lui seul, ne bloque jamais le trafic réseau entre namespaces, contrairement à une intuition répandue.

Le problème d'un cluster partagé

D'abord, un constat : un même cluster Kubernetes héberge souvent plusieurs équipes, plusieurs projets, ou plusieurs environnements (dev, staging, prod).

Ce qui se passerait sans organisation

Sans organisation, tous ces objets se retrouveraient mélangés dans un espace unique : deux équipes pourraient créer un Deployment nommé "api" et entrer en conflit.

La solution : des dossiers séparés

Le Namespace résout ce problème en créant des espaces de noms logiques et cloisonnés à l'intérieur d'un même cluster physique. C'est un peu comme des dossiers séparés sur un même disque dur : les fichiers ne se marchent pas dessus tant qu'ils sont dans des dossiers différents.

Ce qu'un Namespace isole	Ce qu'un Namespace n'isole PAS par défaut
Les noms d'objets (deux "api" dans deux namespaces différents)	Le trafic réseau entre Pods de namespaces différents
Le résultat de `kubectl get` sans `-A` (filtre par défaut)	Les ressources CPU/mémoire du cluster physique

Une limite importante à connaître

Il faut bien comprendre les limites du Namespace : par défaut, il isole les NOMS et sert de filtre pour les commandes, mais il n'isole PAS le réseau. Deux Pods de deux namespaces différents peuvent se parler librement, sauf restriction explicite.

Piège fréquent

Un Namespace ne fournit AUCUNE isolation réseau par défaut : deux Pods dans des namespaces différents peuvent se joindre librement, comme s'ils étaient dans le même espace. Pour une vraie isolation réseau, il faut explicitement des NetworkPolicy (leçon 19) — ne supposez jamais qu'un découpage en namespaces suffit pour la sécurité réseau.

Pour une vraie isolation, il faudra un autre outil

Pour une vraie isolation réseau, il faudra des NetworkPolicy, vues plus loin dans le cours. Le Namespace n'isole pas non plus les ressources machine par lui-même.

Contrôler la consommation par équipe

C'est précisément le rôle de ResourceQuota, qui plafonne la somme totale de CPU, mémoire et nombre de Pods dans tout un namespace.

Astuce

ResourceQuota plafonne la consommation totale d'un namespace (par exemple 10 CPU et 20 Gi de mémoire au total), tandis que LimitRange fixe des bornes ou des valeurs par défaut par Pod individuel à l'intérieur de ce namespace. Les deux se combinent souvent pour éviter qu'une seule équipe monopolise les ressources du cluster.

Un deuxième outil pour les cas individuels

LimitRange complète ce mécanisme en imposant des valeurs par défaut ou des bornes à chaque conteneur individuellement, si le développeur a oublié de les préciser. Ensemble, ils évitent qu'une équipe ne monopolise toutes les ressources du cluster partagé.

Une subtilité DNS à retenir

Enfin, la résolution de nom courte d'un Service (juste nom-du-service) ne fonctionne que depuis le même namespace. Pour joindre un service situé dans un autre namespace, il faut son nom complet qualifié, comme api-service.staging.svc.cluster.local.

Maintenant que le cluster est bien organisé, la leçon suivante s'attaque à l'exposition HTTP des applications vers l'extérieur, avec l'Ingress.

Commandes & code

Namespaces

Un Namespace isole logiquement des groupes de ressources (équipes, environnements) au sein d'un même cluster.

# namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: staging
  labels:
    environment: staging

kubectl apply -f namespace.yaml
kubectl get namespaces
kubectl get pods -n staging
kubectl get pods --all-namespaces

# Changer le namespace par défaut du contexte courant (évite "-n" à chaque commande)
kubectl config set-context --current --namespace=staging
kubectl config view --minify | grep namespace

# ResourceQuota : plafonne la consommation totale d'un namespace
apiVersion: v1
kind: ResourceQuota
metadata:
  name: staging-quota
  namespace: staging
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "30"
---
# LimitRange : impose des defaults/limites PAR conteneur si non précisé
apiVersion: v1
kind: LimitRange
metadata:
  name: staging-limits
  namespace: staging
spec:
  limits:
    - default:
        cpu: "500m"
        memory: "256Mi"
      defaultRequest:
        cpu: "100m"
        memory: "128Mi"
      type: Container

# La résolution DNS courte "api-service" ne fonctionne QUE dans le même namespace
# Depuis un autre namespace, il faut le nom qualifié :
# api-service.staging.svc.cluster.local

Résumé

Les Namespaces isolent logiquement (pas de sandbox réseau/kernel par défaut, voir NetworkPolicy).
ResourceQuota plafonne la consommation globale, LimitRange fixe des defaults par conteneur.
kubectl config set-context --current --namespace=X évite de répéter -n X partout.
Certains objets sont "cluster-scoped" (Node, PV, ClusterRole) : jamais dans un Namespace.

Exercices pratiques

1 disponible

Mission : corriger une fausse impression d'isolation

Objectif : Organiser un cluster partagé avec des Namespaces et des quotas, tout en évitant l'illusion d'une isolation réseau qu'ils ne fournissent pas.

Contexte

Deux équipes, paiement et notifications, partagent le même cluster de production dans les namespaces payment et notifications. Un audit de sécurité vient de révéler que les Pods de notifications, censés être moins sensibles, peuvent communiquer librement avec les Pods de payment. Le lead technique pensait, à tort, que la séparation en namespaces suffisait à garantir cette isolation.

Résoudre l’exercice →