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 utilisé par plusieurs équipes : backend, frontend, data, ops. Sans namespaces, toutes les ressources, Pods, Services et ConfigMaps, cohabitent dans un espace unique. Le résultat : plus personne ne sait 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 dispose de 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

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.

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

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).

Un label vous est d'ailleurs donné sans que vous ayez à le poser. Kubernetes ajoute automatiquement kubernetes.io/metadata.name à tout namespace, avec son nom pour valeur :

kubectl get namespace team-backend -o jsonpath='{.metadata.labels}'

{"kubernetes.io/metadata.name":"team-backend"}

C'est ce label que les NetworkPolicies utilisent pour désigner un namespace par son nom, sans dépendre d'un étiquetage que quelqu'un pourrait oublier ou modifier.

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.

Deux drapeaux couvrent le reste des cas, et méritent d'entrer dans vos réflexes. -n <namespace> cible un autre namespace pour une seule commande, sans toucher au contexte. -A, ou --all-namespaces, interroge tous les namespaces d'un coup et ajoute une colonne NAMESPACE à la sortie : c'est la commande à taper quand vous cherchez un Pod dont vous ignorez où il tourne.

kubectl get pods -n kube-system   # un autre namespace, ponctuellement
kubectl get pods -A               # tous les namespaces, avec la colonne NAMESPACE

La suppression n'est pas instantanée, et cela bloque

C'est le piège qui casse les pipelines. kubectl delete namespace rend la main immédiatement, mais le namespace passe d'abord en état Terminating le temps que Kubernetes supprime son contenu. Pendant cet intervalle, il existe encore, et il refuse toute création :

kubectl delete namespace lab-term
kubectl -n lab-term create configmap trop-tard --from-literal=a=b

error: failed to create configmap: configmaps "trop-tard" is forbidden:
unable to create new content in namespace lab-term because it is being terminated

Recréer le namespace lui-même échoue tout autant, avec un message qui déroute : il parle d'existence là où vous venez de demander une suppression.

Error from server (AlreadyExists): object is being deleted: namespaces "lab-term" already exists

Un enchaînement delete puis create dans un script échoue donc une fois sur deux. La parade tient en un drapeau : --wait=true est le défaut de kubectl delete, mais il est souvent désactivé dans les scripts.

kubectl delete namespace lab-term --wait=true   # rend la main quand c'est fini
kubectl create namespace lab-term

Sur un namespace contenant un Pod, la suppression a pris 10 secondes sur le cluster de la formation. Comptez davantage dès qu'il y a des volumes à démonter.

Les namespaces système ne se suppriment pas

Rassurez-vous sur un point : une faute de frappe ne peut pas emporter kube-system. L'API refuse la suppression des namespaces initiaux, y compris default.

Error from server (Forbidden): namespaces "kube-system" is forbidden:
this namespace may not be deleted

Les namespaces initiaux de Kubernetes

Quand vous tapez kubectl get ns sur un cluster fraîchement créé, vous voyez quatre namespaces créés par Kubernetes lui-même. Chacun a un rôle précis.

Vous en verrez souvent un ou deux de plus, ajoutés par votre distribution : sur un cluster kind, local-path-storage héberge le provisionneur de volumes. Ces namespaces ne sont pas standards, ne vous étonnez pas de ne pas les retrouver ailleurs.

default

Le namespace default accueille toutes les ressources qui n'en précisent aucun. C'est commode pour un test rapide, problématique en production : tout s'y mélange sans aucune organisation.

N'utilisez pas le namespace default en production. Créez des namespaces dédiés pour chaque équipe ou application. La raison est concrète : tout ce qui atterrit dans default y arrive par omission, jamais par décision. Vous ne pouvez donc ni lui appliquer un quota qui ait du sens, ni y poser un RBAC ciblé, puisque son contenu est par nature imprévisible.

kube-system

Ce namespace contient les composants de Kubernetes lui-même : kube-apiserver, kube-controller-manager, kube-scheduler, CoreDNS, kube-proxy et les plugins CNI. Tous sont critiques : le cluster ne fonctionne pas sans eux.

# 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 porte donc ce qui doit être accessible publiquement, comme le ConfigMap cluster-info lu au démarrage d'un nœud.

# 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 accélère la détection de défaillance des nœuds tout en réduisant la charge sur etcd. Vous n'avez pas à intervenir dans 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:1.29-alpine@sha256:5616878291a2eed594aee8db4dade5878cf7edcb475e59193904b198d9b830de -n team-dev
kubectl run api --image=nginx:1.29-alpine@sha256:5616878291a2eed594aee8db4dade5878cf7edcb475e59193904b198d9b830de -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 from server (NotFound): 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.

Elle s'étend aussi au sélecteur d'un Service : un Service ne peut cibler que des Pods de son propre namespace, quels que soient les libellés portés ailleurs. Le comportement est silencieux, ce qui le rend déroutant : le Service est créé, son sélecteur est accepté, et sa liste d'endpoints reste simplement vide.

kubectl -n lab-a get endpointslice -l kubernetes.io/service-name=web \
  -o jsonpath='{range .items[*]}{.endpoints}{"\n"}{end}'

null

La parade n'est pas de contourner le sélecteur mais de joindre le Service voisin par son nom DNS complet, <service>.<namespace>.svc.cluster.local.

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: ["*"]

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

Name:         team-dev
Labels:       kubernetes.io/metadata.name=team-dev
Status:       Active

Resource Quotas
  Name:            team-dev-quota
  Resource         Used  Hard
  --------         ---   ---
  pods             1     30
  requests.cpu     0     4
  requests.memory  0     8Gi

Resource Limits
 Type       Resource  Min  Max  Default Request  Default Limit
 ----       --------  ---  ---  ---------------  -------------
 Container  cpu       -    -    100m             500m
 Container  memory    -    -    128Mi            512Mi

La colonne Used est celle à surveiller : c'est la consommation réelle comparée au plafond. Une seule commande vous donne donc les deux moitiés du dispositif, le quota global du namespace et les valeurs appliquées par défaut à chaque conteneur.

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é.

Isolation des namespaces Kubernetes

Le réseau par défaut

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, et c'est la source de faux sentiment de sécurité la plus fréquente : découper en namespaces donne l'impression d'avoir cloisonné, alors que le réseau, lui, est resté plat.

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

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

kubectl api-resources --namespaced=false

La proportion surprend : sur le cluster de la formation, 37 types de ressources sont cluster-wide contre 34 namespacés. Plus de la moitié de l'API échappe donc au découpage, et aucun namespace ne vous protégera de ce qu'on y fait.

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 voisin bruyant, le « noisy neighbor » : un Pod mal configuré dégrade les performances des autres Pods du même nœud.

Les images conteneur

Le même registre d'images sert tous les namespaces. Une image malveillante poussée sur un registre partagé devient utilisable depuis n'importe quel namespace. Isoler les images demande des politiques au niveau du registre ou des admission controllers.

Pack minimum d'un namespace d'équipe

Vous savez maintenant ce qu'un namespace isole et ce qu'il n'isole pas. Reste à le rendre exploitable en production : un namespace vide ne suffit pas, il faut y déposer un ensemble cohérent de ressources.

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
```

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"

Ajouter un LimitRange pour les valeurs par défaut

Le LimitRange n'est pas un confort, c'est ce qui rend le ResourceQuota utilisable. Dès qu'un quota porte sur requests ou limits, un Pod qui ne les déclare pas est refusé à la création, et non pas créé puis laissé en attente : il n'existe jamais, et chercher un Pod Pending fait perdre du temps. Le message ne laisse pourtant aucun doute.

Error from server (Forbidden): pods "sans-requests" is forbidden:
failed quota: q: must specify limits.cpu for: sans-requests;
limits.memory for: sans-requests; requests.cpu for: sans-requests;
requests.memory for: sans-requests

Avec le LimitRange ci-dessous, le même Pod est accepté et hérite automatiquement de 100m de CPU et 128Mi de mémoire en requests.

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

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

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

Une NetworkPolicy sans CNI compatible ne bloque rien

Cette étape mérite d'être vérifiée plutôt que supposée, car son échec est totalement silencieux. Une NetworkPolicy n'est qu'une déclaration : c'est le CNI (Container Network Interface) qui l'applique, ou pas. Avec un CNI qui ne les gère pas, kubectl get networkpolicies affiche vos règles, kubectl describe les détaille, et le trafic passe quand même. Vous obtenez alors exactement la fausse sécurité que ce guide cherche à éviter, avec en prime la preuve apparente que tout est en place.

Calico, Cilium et kindnet, le CNI par défaut de kind, les appliquent. Vérifié sur le cluster de la formation : un Pod de team-dev obtenait un HTTP 200 sur un Service de team-qa, et n'obtient plus rien après un default-deny-all posé sur team-qa. Flannel seul, en revanche, ne les applique pas.

Pour savoir à quoi vous avez affaire, regardez ce qui tourne dans kube-system :

kubectl get pods -n kube-system -o custom-columns=NOM:.metadata.name,IMAGE:.spec.containers[0].image

Puis validez la règle plutôt que de la supposer, en tentant la connexion depuis un Pod du namespace censé être bloqué.

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 en terminal pour explorer et gérer les ressources. On navigue entre namespaces au clavier et on déclenche les actions directement, sans retaper de commande.

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 portant des finalizers persistent, il faut les supprimer à la main, ou patcher le namespace pour retirer ces finalizers. Cette seconde voie est risquée : elle abandonne le nettoyage que le finalizer devait faire.

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

Autre cause fréquente : un fichier YAML sans namespace dans son metadata. Déclarez-le explicitement dans le manifeste, ou passez -n au 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

Deux lectures possibles : soit ce Pod à lui seul dépasse le quota, soit le namespace a atteint sa limite globale. Ajustez le quota, ou réduisez les requests et limits de vos charges de travail.

Attention au diagnostic : selon le quota franchi, le Pod n'a pas le même sort. Un quota sur le nombre d'objets refuse la création, et vous ne trouverez aucun Pod Pending à examiner. Le message donne les trois chiffres qui comptent, le demandé, l'utilisé et le plafond.

Error from server (Forbidden): pods "p2" is forbidden: exceeded quota: q,
requested: pods=1, used: pods=1, limited: pods=1

À 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, le sélecteur d'un Service, 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
Une NetworkPolicy ne vaut que ce que le CNI en fait : vérifiez-la en tentant la connexion, ne la supposez jamais active
Le pack minimum d'équipe comprend : Namespace + ResourceQuota + LimitRange + NetworkPolicy + RBAC, et sans LimitRange le quota refuse les Pods à la création
Évitez default en production et ne touchez pas à kube-system pour vos workloads

Testez vos connaissances

Sept questions sur ce qu'un namespace sépare vraiment, ce qu'il ne sépare pas, et les namespaces système à ne pas confondre.

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

Pour aller plus loin

ResourceQuota et LimitRange : Le plafonnement des ressources consommées par chaque namespace.
Network Policies : L'isolation réseau qui manque à un namespace, cloisonné en logique seulement.
RBAC Kubernetes : Les permissions par namespace, complément indispensable du découpage.