Ein Kubernetes Namespace ist ein logisch abgetrennter Bereich innerhalb eines Clusters. Innerhalb eines Namespace müssen Namen eindeutig sein, über Namespaces hinweg nicht, und an den Namespace hängen Zugriffsrechte, Ressourcenquoten und Netzwerkregeln. Namespaces sind damit das Werkzeug, mit dem du einen Cluster zwischen Anwendungen und Teams aufteilst, ohne für jede Anwendung einen eigenen Cluster zu betreiben.
Was ein Namespace nicht ist: eine Sicherheitsgrenze aus sich heraus. Ohne RBAC, Network Policies und Quoten ist ein Namespace nur ein Ordner mit Namen. Genau diese drei Bausteine machen aus dem Ordner einen abgesicherten Bereich, und darum geht es in diesem Beitrag.
Ich betreibe Kubernetes-Cluster in Produktion und habe das Kubernetes-Praxisbuch bei Rheinwerk geschrieben (2024). Die Namespace-Regeln hier sind die, die ich in meinen eigenen Clustern anwende, inklusive der Fehlerbilder, die mir im eigenen Betrieb und in Kundenprojekten begegnet sind. Alle meine Beiträge zum Thema findest du auf der Seite Kubernetes.
Was ein Kubernetes Namespace trennt und was nicht
Stell dir den Cluster als großes Lager vor. Der Namespace ist eine abgetrennte Regalzone: Jedes Team hat seine eigene, mit eigenem Schlüssel, eigenem Platzkontingent und eigenen Regeln. Trotzdem stehen alle Zonen in derselben Halle, auf demselben Boden, mit denselben Staplerwegen. Übertragen auf Kubernetes: Die Pods verschiedener Namespaces laufen auf denselben Nodes, teilen sich denselben Kernel und dasselbe Cluster-Netzwerk.
Drei Dinge leistet ein Namespace von Haus aus. Er scopet Namen, sodass zwei Teams beide ein Deployment api betreiben können, ohne sich zu stören. Er ist die Einheit, an der du Rechte vergibst, denn eine Role und ein RoleBinding gelten immer für genau einen Namespace. Und er ist die Einheit, an der Kubernetes Ressourcen zählt und begrenzt, über ResourceQuota und LimitRange.
Was er nicht leistet: Ein Namespace isoliert weder Netzwerk noch Rechenleistung. Ein Pod im Namespace shop erreicht standardmäßig jeden Pod im Namespace billing, und ein Pod ohne Limits kann die Node für alle anderen Namespaces leerfressen. Beides musst du explizit unterbinden, dazu weiter unten mehr.
Wichtig ist auch, dass nicht jedes Objekt in einem Namespace lebt. Pods, Deployments, Services, ConfigMaps, Secrets, Ingresses und PersistentVolumeClaims sind namespaced. Nodes, PersistentVolumes, StorageClasses, ClusterRoles und die Namespaces selbst sind clusterweit. Welche Ressource wohin gehört, zeigt dir kubectl direkt an:
kubectl api-resources --namespaced=true
kubectl api-resources --namespaced=false
Diese Unterscheidung erklärt eine Stolperfalle, die Einsteigern regelmäßig begegnet: Ein PersistentVolume gehört keinem Namespace, erst der PersistentVolumeClaim bindet es an einen. Wer also Volumes „im Namespace" sucht, sucht am falschen Ort.
Die vier Namespaces, die jeder Cluster mitbringt
Ein frisch installierter Cluster startet mit vier Namespaces, die du nicht anlegen musst und nicht löschen solltest.
| Namespace |
Zweck |
Solltest du nutzen? |
default |
Landeplatz für alles ohne Namespace-Angabe |
nur für schnelle Tests |
kube-system |
Komponenten, die Kubernetes selbst betreibt (DNS, Proxy, Controller) |
nein, nur lesen |
kube-public |
für alle Clients lesbar, hält Cluster-Informationen wie die Cluster-Info-ConfigMap |
nein |
kube-node-lease |
Lease-Objekte, über die das Kubelet seine Heartbeats sendet |
nein |
Der Präfix kube- ist für Systemnamespaces reserviert, deine eigenen Namespaces beginnen also nie damit. Und der default-Namespace ist die Falle Nummer eins: Jeder Befehl ohne -n landet dort. In geteilten Clustern liegen dort nach ein paar Monaten Test-Deployments von fünf Leuten, von denen niemand mehr weiß, wer sie gestartet hat. Bei mir bleibt default in Produktionsclustern leer; wer das absichern will, kann es mit einer Admission-Regel, etwa einem Gatekeeper-Constraint, erzwingen.
Namespaces schneiden: nach Anwendung, Team oder Umgebung?
Die häufigste Frage in meinen Projekten lautet nicht „Was ist ein Namespace", sondern „Wie viele brauchen wir und wonach schneiden wir sie". Es gibt drei gängige Muster, und alle drei sind je nach Situation richtig.
| Muster |
Beispiel |
Passt, wenn |
Schwäche |
| pro Anwendung oder Komponente |
shop, shop-search, billing |
mehrere Anwendungen teilen sich einen Cluster |
viele kleine Namespaces bei Microservices |
| pro Team |
team-payments, team-frontend |
Teams betreiben ihre Dienste selbst |
Rechte und Quoten werden grob |
| pro Umgebung |
dev, staging, prod |
ein kleiner Cluster für alles |
Produktion teilt sich Nodes mit Experimenten |
Meine Faustregel für den Schnitt kommt aus dem Buch und hat sich seitdem nicht geändert. Ich stelle drei Fragen: Gehören die Anwendungen zu einer größeren, zusammenhängenden Komponente? Brauchen sie sich gegenseitig, um zu funktionieren? Werden sie gemeinsam ausgerollt und gemeinsam zurückgerollt? Dreimal ja bedeutet ein gemeinsamer Namespace. Ein Nein reicht, um sie zu trennen.
In meinen Clustern sieht das so aus: Jede fachliche Anwendung bekommt einen eigenen Namespace, Plattformwerkzeuge wie ArgoCD, cert-manager, Prometheus und Falco ebenfalls je einen. Umgebungen trenne ich dagegen nicht per Namespace, sondern per Cluster. Ein Staging-Cluster, der Produktion nachbildet, ist mir wichtiger als ein Staging-Namespace, der sich Nodes, Ingress-Controller und Kernel mit Produktion teilt. Für einen Ein-Personen-Cluster oder ein reines Testsystem ist das übertrieben; da reichen dev und prod als Namespaces völlig.
Was ich nicht mehr mache: Namespaces für leicht unterschiedliche Varianten derselben Anwendung, etwa shop-v1 und shop-v2. Dafür sind Labels da. Namespaces sind für Dinge gedacht, die getrennte Rechte, getrennte Quoten oder getrennte Netzwerkregeln brauchen. Alles andere ist ein Label-Fall.
Namespace anlegen und mit kubectl bedienen
Ein Namespace ist ein einfaches Objekt, und wie alles in Kubernetes solltest du ihn als YAML in Git ablegen, nicht per kubectl create namespace von Hand. Der Grund: Der Namespace ist der Ort, an dem später Quoten, Rollen und Netzwerkregeln hängen, und die willst du zusammen mit ihm versionieren. Bei mir legt ArgoCD Namespaces an, das Manifest liegt neben Quota und RoleBinding im selben Ordner.
apiVersion: v1
kind: Namespace
metadata:
name: shop
labels:
team: commerce
environment: production
Die Labels am Namespace sind mehr als Deko. Network Policies und Admission-Regeln wählen Namespaces über Labels aus, und Kubernetes setzt automatisch das Label kubernetes.io/metadata.name mit dem Namen des Namespace, damit du auch ohne eigene Labels einen bestimmten Namespace selektieren kannst.
Im Alltag arbeitest du mit drei Optionen. Mit -n shop sprichst du einen Namespace an, mit -A siehst du eine Ressource über alle Namespaces hinweg, und mit kubectl config set-context --current --namespace=shop machst du einen Namespace zum Standard für alle folgenden Befehle:
kubectl get pods -n shop
kubectl get pods -A
kubectl config set-context --current --namespace=shop
Das Umschalten über set-context wird schnell lästig, wenn du täglich zwischen mehreren Namespaces und Clustern wechselst; kubens und kubectx nehmen dir das ab. Die übrigen Befehle für den Alltag stehen gesammelt in kubectl Befehle: die wichtigsten im Alltag.
Ein Punkt, der oft übersehen wird, ist DNS. Ein Service api im Namespace shop ist innerhalb von shop schlicht als api erreichbar. Aus einem anderen Namespace heraus brauchst du den langen Namen api.shop.svc.cluster.local oder mindestens api.shop. Wenn also eine Anwendung nach dem Umzug in einen eigenen Namespace ihre Datenbank nicht mehr findet, ist das fast immer der Grund.
Ressourcen pro Namespace begrenzen: ResourceQuota und LimitRange
Ein geteilter Cluster ohne Quoten funktioniert genau so lange, bis jemand ein Deployment mit zwanzig Replicas ohne Limits ausrollt. Kubernetes bringt dafür zwei Objekte mit, die beide pro Namespace wirken. Die ResourceQuota deckelt die Summe, die ein Namespace insgesamt anfordern darf. Die LimitRange setzt Grenzen und Standardwerte für einzelne Container.
apiVersion: v1
kind: ResourceQuota
metadata:
name: shop-quota
namespace: shop
spec:
hard:
requests.cpu: "4"
requests.memory: 8Gi
limits.cpu: "8"
limits.memory: 16Gi
pods: "50"
persistentvolumeclaims: "10"
---
apiVersion: v1
kind: LimitRange
metadata:
name: shop-defaults
namespace: shop
spec:
limits:
- type: Container
defaultRequest:
cpu: 100m
memory: 128Mi
default:
cpu: 500m
memory: 512Mi
max:
cpu: "2"
memory: 4Gi
Die Quota sagt: Alle Pods in shop zusammen dürfen höchstens 4 CPU und 8 GiB anfordern, höchstens 8 CPU und 16 GiB als Limit setzen, und es dürfen nicht mehr als 50 Pods und 10 Volume-Claims existieren. Die LimitRange sorgt dafür, dass ein Container ohne eigene Angaben mit 100 Millicores und 128 MiB Request startet und bei 500 Millicores und 512 MiB gedeckelt wird; mehr als 2 CPU oder 4 GiB darf niemand für einen einzelnen Container verlangen.
Beide gehören zusammen, und genau an dieser Stelle geht es in der Praxis am häufigsten schief. Sobald eine ResourceQuota requests.cpu oder requests.memory begrenzt, lehnt der API-Server jeden Pod ab, der diese Werte nicht setzt. Ohne LimitRange scheitert dann jedes Helm-Chart, das keine Requests mitbringt, und die Fehlermeldung must specify requests.cpu steht nur im Event des ReplicaSets, nicht beim Deployment. Dass die LimitRange die fehlenden Werte auffüllt, bevor die Quota prüft, ist kein Zufall, sondern die Reihenfolge im Admission-Durchlauf: Kubernetes lässt zuerst die verändernden Plugins arbeiten und prüft erst danach mit den validierenden, zu denen die ResourceQuota gehört (Admission-Controller-Referenz). Beide zusammen ergeben einen Namespace, der andere nicht verhungern lässt. Welche Werte für Requests und Limits sinnvoll sind, steht in Kubernetes Requests und Limits erklärt.
Mit kubectl describe quota -n shop siehst du jederzeit, wie viel vom Kontingent belegt ist. Das ist auch ein gutes Frühwarnsystem: Ein Namespace, der dauerhaft bei 90 Prozent seiner Quota liegt, braucht entweder mehr Kontingent oder eine Aufräumaktion.
Isolation zwischen Namespaces: Rechte und Netzwerk
Der Begriff Namespace-Isolation führt in die Irre, wenn du ihn wörtlich nimmst. Ein Namespace isoliert erst, wenn du ihm zwei Dinge beigibst: Rechte und Netzwerkregeln.
Rechte laufen über RBAC. Eine Role beschreibt, was in einem Namespace erlaubt ist, ein RoleBinding gibt diese Rolle einem User, einer Gruppe oder einem ServiceAccount. Ein Entwicklungsteam bekommt so edit in seinem Namespace und sonst nichts, und ein ServiceAccount einer Anwendung darf nur die Secrets lesen, die es braucht. ClusterRoleBindings vergibst du dagegen nur an Administratoren und Plattformkomponenten, denn die gelten über alle Namespaces hinweg. Wie Rollen, Verben und Bindings zusammenspielen, steht in Kubernetes RBAC: Rollen und Rechte.
Netzwerk läuft über NetworkPolicies. Standardmäßig darf jeder Pod mit jedem reden, Namespace hin oder her. Mein Muster für jeden Anwendungs-Namespace ist eine Default-Deny-Policy für eingehenden Verkehr plus gezielte Freigaben: vom Ingress-Controller zum Frontend, vom Frontend zur API, von der API zur Datenbank. Der Namespace-Selektor in einer NetworkPolicy nutzt genau die Labels, die du oben am Namespace gesetzt hast. Die Details mit Beispielen stehen in Kubernetes Network Policy erklärt.
Was auch mit beidem nicht isoliert ist: der Kernel. Pods aus verschiedenen Namespaces laufen auf denselben Nodes, und wer aus einem Container ausbricht, steht auf der Node und nicht im Namespace. Wenn zwei Mandanten sich gegenseitig wirklich nicht vertrauen dürfen, sind getrennte Node-Pools mit Taints oder gleich getrennte Cluster die ehrliche Antwort. Für Teams innerhalb eines Unternehmens reicht in meiner Erfahrung die Kombination aus RBAC, NetworkPolicy, Quota und Pod-Security-Regeln fast immer aus.
Häufige Fragen
Wie viele Namespaces sollte ein Cluster haben?
So viele, wie es Einheiten mit eigenen Rechten, Quoten oder Netzwerkregeln gibt, und nicht mehr. Für einen Cluster mit drei Anwendungen und vier Plattformwerkzeugen sind sieben Namespaces normal. Hunderte Namespaces sind technisch kein Problem, aber jeder braucht Quota, RoleBinding und Network Policy, sonst ist er nur ein Name. Wer dafür kein Template in Git hat, sollte lieber weniger Namespaces anlegen.
Kann ein Service über Namespaces hinweg erreicht werden?
Ja, über den vollen DNS-Namen service.namespace.svc.cluster.local, oft reicht service.namespace. Ob die Verbindung dann auch zustande kommt, entscheiden die NetworkPolicies im Ziel-Namespace. Ohne Policies geht alles, mit Default-Deny nur, was du freigegeben hast.
Was passiert, wenn ich einen Namespace lösche?
Kubernetes löscht alles darin: Pods, Deployments, Services, Secrets, PersistentVolumeClaims. Der Namespace steht dabei eine Weile im Status Terminating, bis alle Finalizer abgearbeitet sind. Hängt er dort fest, blockiert meist eine Custom Resource, deren Controller nicht mehr läuft. Bevor du einen Namespace löschst, prüfe die Volumes: Bei Delete als Reclaim Policy sind die Daten danach weg.
Sind Kubernetes Namespaces ein Sicherheitsmerkmal?
Nur zusammen mit RBAC, NetworkPolicies und Pod-Security-Regeln. Der Namespace allein trennt Namen, sonst nichts. Als Mandantentrennung für Kunden, die sich nicht vertrauen, reicht das Konzept nicht aus, dafür brauchst du getrennte Nodes oder Cluster.
Kann ein Pod zu mehreren Namespaces gehören?
Nein. Jedes namespaced Objekt gehört zu genau einem Namespace, und der lässt sich nach dem Anlegen nicht ändern. Willst du ein Deployment in einen anderen Namespace verschieben, legst du es dort neu an und löscht es im alten.
Wie du weitermachst
Wenn du einen bestehenden Cluster hast, fang mit einer Bestandsaufnahme an: kubectl get all -n default zeigt dir, was dort nicht hingehört. Dann leg für jede Anwendung einen Namespace mit Quota und LimitRange in Git an, gib den Teams ihre Rechte über RoleBindings und setz eine Default-Deny-Policy. In dieser Reihenfolge: erst Struktur, dann Rechte, dann Netzwerk.
Die drei Bausteine haben eigene Beiträge: Kubernetes RBAC: Rollen und Rechte für die Zugriffsseite, Kubernetes Requests und Limits erklärt für die Werte in Quota und LimitRange und Kubernetes Network Policy erklärt für die Netzwerkseite.
Ausführlich mit allen Beispielen steht das in Kapitel 2 meines Kubernetes-Praxisbuchs bei Rheinwerk, die Rechte in Kapitel 7 und die Ressourcensteuerung in Kapitel 8.
