Namespaces Kubernetes : organiser et isoler logiquement vos ressources

Un namespace Kubernetes organise votre cluster en espaces logiques distincts. Il permet de séparer les ressources par équipe, projet ou environnement, d’éviter les conflits de noms, et de cibler facilement des politiques (quotas, permissions). Pour une vraie séparation d’équipe en production, vous irez plus loin avec RBAC, ResourceQuota et NetworkPolicy — mais commençons par comprendre ce qu’est un namespace et comment l’utiliser au quotidien.

Ce que vous allez apprendre

À la fin de ce guide, vous saurez :

• Comprendre le rôle d’un namespace : organiser un cluster, séparer équipes et environnements
• Créer et gérer des namespaces : commandes impératives, manifestes déclaratifs, changement de contexte
• Identifier les namespaces système : default, kube-system, kube-public, kube-node-lease
• Connaître les limites : ce qu’un namespace isole vraiment et ce qu’il n’isole pas
• Sécuriser un namespace d’équipe avec le pack minimum : quotas, limites, NetworkPolicy, RBAC

À quoi sert un namespace Kubernetes ?

Avant de créer votre premier namespace, comprenons pourquoi cette ressource existe et quels problèmes elle résout.

Organiser un cluster partagé

Imaginez un cluster Kubernetes utilisé par plusieurs équipes : backend, frontend, data, ops. Sans namespaces, toutes les ressources (pods, services, configmaps) cohabitent dans un espace unique. Le résultat ? Un chaos où il devient difficile de savoir qui a déployé quoi.

Un namespace crée un répertoire logique pour regrouper les ressources liées. C’est comme avoir des dossiers sur un disque dur : chaque équipe travaille dans son espace sans polluer celui des autres.

Éviter les conflits de noms

Deux équipes veulent créer un service nommé api. Sans namespaces, c’est impossible — le nom est unique dans le cluster. Avec des namespaces séparés (team-backend et team-frontend), chaque équipe peut avoir son propre service api sans conflit.

# Deux services "api" coexistent dans des namespaces différents
kubectl get service api -n team-backend
kubectl get service api -n team-frontend

Séparer les environnements

Les namespaces permettent de faire cohabiter plusieurs environnements sur le même cluster :

Namespace	Usage
dev	Développement, tests rapides
staging	Pré-production, tests d’intégration
prod	Production

Glissez pour voir

Cette séparation facilite l’application de politiques différenciées : quotas généreux en dev, stricts en prod ; accès large en dev, restreint en prod.

Appliquer des politiques ciblées

Un namespace sert de périmètre pour les politiques :

• RBAC : donner à une équipe les droits complets sur son namespace, sans accès aux autres
• ResourceQuota : limiter la consommation CPU/mémoire par namespace
• LimitRange : définir des valeurs par défaut pour les conteneurs
• NetworkPolicy : contrôler le trafic réseau entrant et sortant

Sans namespace, vous ne pourriez pas cibler ces politiques — elles s’appliqueraient à tout le cluster.

Quand créer un namespace ?

Créez un namespace dès que vous avez besoin de séparer logiquement des ressources : nouvelle équipe, nouveau projet, nouvel environnement. Un cluster bien organisé compte généralement entre 5 et 50 namespaces selon sa taille.

Créer et gérer un namespace

Passons à la pratique. Kubernetes offre deux approches pour créer un namespace, chacune adaptée à des cas d’usage différents.

Création impérative

L’approche impérative utilise des commandes kubectl directes. Elle convient pour les tests rapides et l’exploration.

# Créer un namespace
kubectl create namespace mon-namespace

# Lister tous les namespaces
kubectl get namespaces

# Voir les détails (quotas, labels, annotations)
kubectl describe namespace mon-namespace

# Supprimer un namespace (supprime TOUTES ses ressources !)
kubectl delete namespace mon-namespace

Suppression destructive

La suppression d’un namespace entraîne la suppression de toutes les ressources qu’il contient : pods, services, configmaps, secrets, PVCs… Cette action est irréversible. Vérifiez toujours le contenu avant de supprimer.

Création déclarative

L’approche déclarative utilise des fichiers YAML versionnés. C’est la méthode recommandée pour la production et les workflows GitOps.

apiVersion: v1
kind: Namespace
metadata:
  name: team-backend
  labels:
    team: backend
    environment: production
    cost-center: "12345"
  annotations:
    owner: "equipe-backend@example.com"
    description: "Namespace pour les services backend de production"

Appliquez ce fichier avec :

kubectl apply -f namespace.yaml

Les labels sont particulièrement utiles pour les NetworkPolicies (sélection par namespace) et pour l’organisation (filtrage, reporting de coûts).

Configurer le namespace par défaut

Pour éviter d’ajouter -n mon-namespace à chaque commande, configurez le namespace par défaut de votre contexte kubectl :

# Définir le namespace par défaut
kubectl config set-context --current --namespace=team-backend

# Vérifier le namespace actuel
kubectl config view --minify | grep namespace:

Tous vos kubectl get pods, kubectl get services, etc. s’exécuteront désormais dans team-backend sans avoir à le spécifier.

Les namespaces initiaux de Kubernetes

Quand vous tapez kubectl get ns sur un cluster fraîchement créé, vous voyez quatre namespaces. Chacun a un rôle spécifique qu’il est important de comprendre.

default

Le namespace default est l’espace par défaut pour toutes les ressources qui ne spécifient pas de namespace. C’est pratique pour les tests rapides, mais problématique en production car toutes les ressources s’y mélangent sans organisation.

Bonne pratique production

N’utilisez pas le namespace default en production. Créez des namespaces dédiés pour chaque équipe ou application. Le namespace default rend difficile l’application de quotas et de politiques RBAC ciblées.

kube-system

Ce namespace contient les composants essentiels de Kubernetes lui-même : kube-apiserver, kube-controller-manager, kube-scheduler, CoreDNS, kube-proxy, et les plugins CNI. Ces composants sont critiques pour le fonctionnement du cluster.

# Voir les composants système
kubectl get pods -n kube-system

Ne déployez jamais vos applications dans kube-system. Une erreur de configuration ou une surconsommation de ressources pourrait impacter les composants critiques et déstabiliser tout le cluster. De plus, certaines mises à jour de cluster peuvent réinitialiser ce namespace.

kube-public

Ce namespace est lisible par tous les utilisateurs, même non authentifiés. Il est principalement utilisé pour les ressources qui doivent être accessibles publiquement, comme le ConfigMap cluster-info utilisé lors du bootstrap.

# Le ConfigMap cluster-info est accessible sans authentification
kubectl get configmap cluster-info -n kube-public -o yaml

En pratique, ce namespace est peu utilisé. Il existe principalement pour des cas d’usage spécifiques liés au bootstrapping du cluster.

kube-node-lease

Introduit dans Kubernetes 1.14, ce namespace contient des objets Lease pour chaque nœud. Ces Leases permettent au kubelet d’envoyer des heartbeats (signaux de vie) sans surcharger l’API Server avec des mises à jour fréquentes de l’objet Node.

# Voir les leases des nœuds
kubectl get lease -n kube-node-lease

Ce mécanisme optimise la détection de défaillance des nœuds tout en réduisant la charge sur etcd. Vous n’avez généralement pas besoin d’interagir avec ce namespace.

Ce qu’un namespace isole réellement

Maintenant que vous savez créer et utiliser des namespaces, voyons précisément ce qu’ils isolent. Un namespace crée une frontière logique avec des effets concrets sur plusieurs aspects de vos ressources.

Isolation des noms de ressources

Le premier rôle d’un namespace est de créer un scope pour les noms. Deux ressources peuvent porter le même nom si elles sont dans des namespaces différents.

# Créer deux namespaces
kubectl create namespace team-dev
kubectl create namespace team-qa

# Créer un pod "api" dans chaque namespace
kubectl run api --image=nginx -n team-dev
kubectl run api --image=nginx -n team-qa

# Vérifier : les deux pods coexistent sans conflit
kubectl get pods api -n team-dev
kubectl get pods api -n team-qa

Les deux pods api existent simultanément, chacun dans son propre espace.

Isolation des ressources sensibles

Les ConfigMaps et les Secrets sont scopés par namespace. Un pod dans team-dev ne peut pas monter un Secret créé dans team-qa. Cette isolation protège les données sensibles entre équipes.

# Un secret créé dans team-dev...
kubectl create secret generic db-password \
  --from-literal=password=secret123 -n team-dev

# ...n'est pas visible depuis team-qa
kubectl get secret db-password -n team-qa
# Error: secrets "db-password" not found

Cette isolation s’étend aux ServiceAccounts. Chaque namespace possède automatiquement un ServiceAccount default, et les pods d’un namespace utilisent les ServiceAccounts de ce namespace uniquement.

Portée des politiques RBAC

Les Role et RoleBinding s’appliquent à un namespace spécifique. Vous pouvez donner à une équipe les droits complets sur son namespace sans lui accorder l’accès aux autres namespaces.

# Un Role qui donne tous les droits... mais seulement dans team-dev
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: full-access
  namespace: team-dev
rules:
- apiGroups: ["", "apps", "batch"]
  resources: ["*"]
  verbs: ["*"]

ClusterRole vs Role

Un Role s’applique à un seul namespace. Pour des permissions qui s’étendent à tout le cluster, utilisez un ClusterRole combiné à un ClusterRoleBinding. Mais pour l’isolation multi-tenant, privilégiez les Roles namespace-scoped.

Portée des quotas et limites

Les ResourceQuota et LimitRange sont des ressources namespacées. Ils permettent de limiter la consommation de ressources par namespace, évitant qu’une équipe ne monopolise le cluster.

# Voir les quotas et limites appliqués à un namespace
kubectl describe namespace team-dev

Cette commande affiche les quotas configurés et leur utilisation actuelle.

Ce qu’un namespace N’isole PAS

Comprendre les limites de l’isolation par namespace est crucial pour éviter de faux sentiments de sécurité. Le diagramme ci-dessous illustre la frontière entre ce qui est isolé et ce qui est partagé.

Le réseau par défaut

Point critique

Par défaut, tous les pods de tous les namespaces peuvent communiquer entre eux. Un pod dans team-dev peut atteindre un pod dans team-qa ou même dans kube-system. Le namespace seul n’apporte aucune isolation réseau.

Pour tester cette communication inter-namespace :

# Depuis un pod dans team-dev, on peut joindre un service dans team-qa
kubectl exec -it mon-pod -n team-dev -- curl http://mon-service.team-qa.svc.cluster.local

La résolution DNS fonctionne car Kubernetes utilise le format <service>.<namespace>.svc.cluster.local pour tous les Services. Sans NetworkPolicy explicite, le trafic passe sans restriction.

Les ressources cluster-wide

Certaines ressources Kubernetes ne sont pas scopées par namespace. Ces ressources cluster-wide sont partagées par tous :

Ressource	Description	Impact sur l’isolation
Nodes	Nœuds du cluster	Tous les pods partagent les mêmes nœuds
PersistentVolumes	Stockage persistant	Un PV peut être réclamé depuis n’importe quel namespace
StorageClasses	Classes de stockage	Partagées globalement
ClusterRole	Rôles RBAC cluster-wide	Permissions globales
Namespaces	Eux-mêmes	Visibles par tous
IngressClass	Classes d’Ingress	Partagées globalement
PriorityClasses	Priorités de scheduling	Affectent le scheduling global

Glissez pour voir

Pour lister toutes les ressources non-namespacées de votre cluster :

kubectl api-resources --namespaced=false

Les ressources physiques du nœud

Les pods de différents namespaces qui s’exécutent sur le même nœud partagent ses ressources physiques :

• CPU et mémoire : Sans quotas, un pod peut consommer toutes les ressources du nœud
• Espace disque : Les volumes ephemeral et les logs partagent le même disque
• Bande passante réseau : Pas d’isolation réseau au niveau nœud par défaut

Cette cohabitation crée le problème du “noisy neighbor” (voisin bruyant) : un pod mal configuré peut dégrader les performances des autres pods sur le même nœud.

Les images conteneur

Le même registry d’images est utilisé par tous les namespaces. Si un développeur push une image malveillante sur un registry partagé, elle peut être utilisée par n’importe quel namespace. L’isolation des images nécessite des politiques au niveau du registry ou des admission controllers.

Pack minimum d’un namespace d’équipe

Maintenant que vous connaissez ce qu’un namespace isole et ses limites, voici comment le rendre vraiment exploitable en production. Créer un namespace vide ne suffit pas — vous devez déployer un ensemble cohérent de ressources.

1. Créer le namespace avec des labels appropriés

   Les labels permettent d’identifier le namespace et sont utilisés par les NetworkPolicies.

   apiVersion: v1
   kind: Namespace
   metadata:
     name: team-backend
     labels:
       team: backend
       environment: production

2. Ajouter un ResourceQuota pour limiter la consommation globale

   Le ResourceQuota protège le cluster contre la surconsommation par une équipe.

   apiVersion: v1
   kind: ResourceQuota
   metadata:
     name: team-backend-quota
     namespace: team-backend
   spec:
     hard:
       requests.cpu: "4"
       requests.memory: 8Gi
       limits.cpu: "8"
       limits.memory: 16Gi
       pods: "30"
       services: "10"
       configmaps: "30"
       secrets: "30"
       persistentvolumeclaims: "10"

3. Ajouter un LimitRange pour les valeurs par défaut

   Sans LimitRange, les pods sans requests/limits définis ne seront pas schedulés si un ResourceQuota est en place. Le LimitRange définit des valeurs par défaut automatiques.

   apiVersion: v1
   kind: LimitRange
   metadata:
     name: team-backend-limits
     namespace: team-backend
   spec:
     limits:
     - default:
         cpu: "500m"
         memory: "512Mi"
       defaultRequest:
         cpu: "100m"
         memory: "128Mi"
       max:
         cpu: "2"
         memory: "4Gi"
       min:
         cpu: "50m"
         memory: "64Mi"
       type: Container

4. Isoler le réseau avec des NetworkPolicies

   Par défaut, bloquez tout le trafic, puis autorisez sélectivement.

   # Politique par défaut : tout bloquer
   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: default-deny-all
     namespace: team-backend
   spec:
     podSelector: {}
     policyTypes:
     - Ingress
     - Egress
   ---
   # Autoriser le trafic interne au namespace + DNS
   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: allow-internal
     namespace: team-backend
   spec:
     podSelector: {}
     policyTypes:
     - Ingress
     - Egress
     ingress:
     - from:
       - namespaceSelector:
           matchLabels:
             kubernetes.io/metadata.name: team-backend
     egress:
     - to:
       - namespaceSelector:
           matchLabels:
             kubernetes.io/metadata.name: team-backend
     - to:  # Autoriser les requêtes DNS
       - namespaceSelector:
           matchLabels:
             kubernetes.io/metadata.name: kube-system
       ports:
       - protocol: UDP
         port: 53

5. Configurer le RBAC pour l’équipe

   Créez un Role avec les permissions nécessaires et liez-le au groupe de l’équipe.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: team-backend-developer
     namespace: team-backend
   rules:
   - apiGroups: ["", "apps", "batch"]
     resources: ["pods", "deployments", "services", "configmaps", "secrets"]
     verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
   - apiGroups: [""]
     resources: ["pods/log", "pods/exec"]
     verbs: ["get", "create"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: team-backend-developers
     namespace: team-backend
   subjects:
   - kind: Group
     name: team-backend-devs  # Groupe dans votre IdP
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: Role
     name: team-backend-developer
     apiGroup: rbac.authorization.k8s.io

NetworkPolicy et CNI

Les NetworkPolicies ne fonctionnent que si votre CNI (Container Network Interface) les supporte. Calico, Cilium, et Weave les supportent. Flannel basique ne les supporte pas. Avec K3s (utilisé par K3d), le CNI par défaut supporte les NetworkPolicies.

Vérifier le pack appliqué

Après avoir appliqué toutes ces ressources, vérifiez leur présence :

# Le namespace avec ses quotas et limites
kubectl describe namespace team-backend

# Les NetworkPolicies
kubectl get networkpolicies -n team-backend

# Le RBAC
kubectl get roles,rolebindings -n team-backend

Un kubectl describe namespace team-backend affiche à la fois les Resource Quotas et les LimitRanges, vous permettant de valider la configuration en une commande.

Outils pour naviguer entre namespaces

Travailler avec plusieurs namespaces implique de nombreux changements de contexte. Plusieurs outils simplifient cette navigation.

kubens

L’outil kubens permet de changer de namespace en une commande, sans manipuler la configuration kubectl.

# Lister les namespaces disponibles
kubens

# Changer de namespace
kubens team-backend

# Revenir au namespace précédent
kubens -

kubens colore le namespace actuel, facilitant le repérage visuel. Il fait partie du projet kubectx qui fournit aussi kubectx pour changer de cluster.

k9s

k9s offre une interface terminal complète pour explorer et gérer les ressources Kubernetes. Il permet de naviguer entre namespaces avec les raccourcis clavier et d’exécuter des actions directement.

Pour filtrer par namespace dans k9s, tapez :ns pour lister les namespaces, puis Entrée pour sélectionner. Le namespace actif s’affiche dans le header.

Dépannage des namespaces

Certains problèmes courants avec les namespaces ont des solutions bien documentées.

Namespace bloqué en état Terminating

Lorsqu’un namespace reste en état Terminating indéfiniment, c’est généralement dû à des finalizers qui ne peuvent pas être traités. Identifiez la cause :

# Voir ce qui bloque
kubectl get namespace mon-namespace -o json | jq '.status'

# Rechercher les ressources avec des finalizers
kubectl api-resources --verbs=list --namespaced -o name | \
  xargs -n 1 kubectl get --show-kind --ignore-not-found -n mon-namespace

Si des ressources avec des finalizers persistent, vous devrez peut-être les supprimer manuellement ou patcher le namespace pour retirer les finalizers (opération risquée, à faire avec précaution).

Ressources créées dans le mauvais namespace

Si vos ressources apparaissent systématiquement dans default alors que vous pensiez les créer ailleurs :

# Vérifier le namespace par défaut de votre contexte
kubectl config view --minify | grep namespace:

# Si vide, le namespace par défaut est "default"
# Corrigez avec :
kubectl config set-context --current --namespace=team-backend

Une autre cause fréquente : les fichiers YAML qui ne spécifient pas de namespace dans leur metadata. Ajoutez explicitement le namespace dans le manifeste ou utilisez -n lors du kubectl apply.

Conflit de quota dépassé

Si vos pods restent en état Pending avec un événement mentionnant des quotas :

# Voir l'utilisation actuelle vs les limites
kubectl describe resourcequota -n team-backend

Soit vous demandez plus de ressources que le quota autorise pour un pod unique, soit le namespace a atteint sa limite globale. Ajustez le quota ou réduisez les requests/limits de vos workloads.

Testez vos Connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

90% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

Un namespace Kubernetes est un outil d’organisation avant d’être un outil d’isolation :

• Utilisez-le pour : organiser vos ressources, séparer équipes et environnements, éviter les conflits de noms, cibler des politiques
• Le namespace isole : les noms de ressources, les Secrets/ConfigMaps, le périmètre RBAC, et permet d’appliquer des quotas
• Le namespace N’isole PAS : le réseau (sans NetworkPolicy), les ressources cluster-wide (Nodes, PV, StorageClass), les ressources physiques du nœud
• Le pack minimum d’équipe comprend : Namespace + ResourceQuota + LimitRange + NetworkPolicy + RBAC
• Évitez default en production et ne touchez pas à kube-system pour vos workloads

Prochaines étapes

RBAC Kubernetes Configurez finement les permissions avec Role, ClusterRole, et leurs bindings.

ResourceQuota en détail Maîtrisez les quotas pour contrôler la consommation des ressources par namespace.

NetworkPolicy Isolez le réseau entre namespaces avec des règles de trafic précises.

×

📖 Voir la documentation →