Kubernetes namespaces
| Fiche express | |
|---|---|
| Type | Partitionnement logique d'un cluster |
| Namespaces par défaut | default · kube-system · kube-public · kube-node-lease
|
| Portée | Objets namespacés (Pods, Services, Deployments...) vs objets cluster-wide (Nodes, PersistentVolumes...) |
| Voir aussi | Kubernetes · Kubernetes services · Kubectl |
Un namespace Kubernetes fournit un espace de noms logique à l'intérieur d'un même cluster physique : plusieurs équipes, applications ou environnements (dev/staging/prod) peuvent cohabiter sans collision de noms d'objets, chacun dans son propre namespace. Ce n'est pas une isolation réseau ou sécurité forte en soi (elle s'obtient en combinant namespaces et NetworkPolicies ou RBAC) — c'est avant tout un mécanisme d'organisation et de portée.
Tous les objets ne sont pas namespacés : les Pods, Services, Deployments le sont, mais les Nodes, PersistentVolumes ou les objets de type Namespace eux-mêmes sont de portée cluster.
Usage
# lister les namespaces existants
kubectl get namespaces
# créer un nouveau namespace
kubectl create namespace mon-namespace
# lister les objets d'un namespace particulier (ex. les composants système)
kubectl get pods -n kube-system
Sans précision de -n/--namespace, kubectl opère sur le namespace par défaut du contexte courant (généralement default) ; voir Kubectl pour la gestion des contextes.
Le namespace d'un objet influe aussi sur sa résolution DNS interne au cluster : un Service n'est directement joignable par son nom court que depuis son propre namespace, et nécessite son nom pleinement qualifié (service.namespace.svc.cluster.local) depuis un autre — voir Réseau Kubernetes — Modèle et primitives pour le détail du fonctionnement de CoreDNS.