Begriff

Namespace (Kubernetes)

Kubernetes Architecture S1

2 Quellen 0 Lernpfade 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Ein Kubernetes Cluster ist groß und teuer (100 CPUs). Du hast 3 Teams: Team A, Team B und Team C. Du willst nicht 3 Cluster kaufen. Du nutzt Namespaces. Das ist wie WGs in einem großen Haus. Team A bekommt den Namespace team-a. Team B bekommt team-b. Wenn Team A einen Pod "webserver" nennt, und Team B auch, dann kollidieren sie nicht. team-a/webserver ist ein anderer Name als team-b/webserver. Dank Namespaces können viele Teams friedlich auf demselben Cluster arbeiten ("Multi-Tenancy").

Merksatz: Ein logischer Bereich innerhalb eines Kubernetes-Clusters zur Trennung von Ressourcen, Zugriffrechten (RBAC) und Quotas verschiedener Teams oder Projekte.

CLI: kubectl get ns (Zeigt alle). Erstellen: kubectl create ns dev. Nutzen: kubectl run nginx --image=nginx -n dev. Context wechseln (Faulheit): kubectl config set-context --current --namespace=dev. Ab jetzt landen alle Befehle automatisch in dev.

Standard-Namespaces:

default: Der Mülleimer für alles ohne Namespace.
kube-system: Hier wohnt der Cluster selbst (API Server, DNS). Finger weg!
kube-public: Für ConfigMaps, die jeder lesen darf (z. B. Cluster Info).

1. Resource Quotas & Limits

Das wichtigste Feature für Admins. Du willst verhindern, dass Team A den ganzen RAM frisst und Team B verhungert (OOMKilled). Du setzt ein ResourceQuota auf den Namespace team-a:

spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi

Wenn Team A versucht, mehr zu starten: 403 Forbidden - Exceeded quota. Das erzwingt "Fair Share".

2. Network Isolation (NetworkPolicies)

Namespaces isolieren Namen, aber nicht das Netzwerk! Standardmäßig kann Pod A in Namespace dev den Pod B in Namespace prod anpingen (und Datenbank hacken). Du musst explizit eine NetworkPolicy ("Firewall") erstellen: "Verbiete allen Traffic von dev nach prod." Erst dann ist der Namespace wirklich isoliert ("Mandantenfähig").

3. Löschen ist schwer ("Terminating")

Wenn du kubectl delete ns team-a machst, bleibt er oft ewig auf Terminating stehen. Grund: Ein Objekt im Namespace (z. B. eine CRD oder ein Finalizer auf einem PVC) blockiert das Löschen. Der Namespace Controller versucht endlos, alles zu löschen, scheitert aber. Lösung: Manuell per API den finalize Block entfernen (JSON Patch).

1. Linux Namespaces vs. Kubernetes Namespaces

Vorsicht bei Begrifflichkeiten! Ein Linux-Namespace (cgroups, PID, Mount) isoliert tief auf Betriebssystemebene (Wie Docker isoliert wird). Ein Kubernetes Namespace isoliert primär zur API-Trennungs-Zeit. Wenn du Pod A in K8s-NS 1 und Pod B in K8s-NS 2 startest, könnten sie theoretisch als Prozesse absolut fröhlich auf demselben Worker-Knoten auf dem exakt selben Linux-Kernel-Level laufen. Der Kubernetes-API-Server "lügt" dir die Isolation nur virtuell als Ordnungssystem im etcd-Key-Value Store vor.

2. DNS Resolution und der Kube-DNS

Wie reden Namespaces netzwerktechnisch? Kube-DNS (CoreDNS) vergibt für Services den FQDN (Fully Qualified Domain Name). Ist eine App im NS demo und ruft http://mysql auf, ergänzt /etc/resolv.conf im Pod im Hintergrund automatisch den Such-Suffix des eigenen NS (mysql.demo.svc.cluster.local). Will die App eine Datenbank in prod erreichen, muss sie hart http://mysql.prod.svc.cluster.local anfragen. Ohne den Namespace im Domain-Namen schlägt der DNS-Resolve fehl.

3. Cross-Namespace Secrets (Hack und Design)

Ein massives Problem der K8s-Architektur: Secrets sind streng namespace-gebunden. Wenn du ein teures SSL Wildcard Zertifikat für *.firma.com gekauft hast, kannst du es als Secret im default NS speichern. Die Ingress-Controller in team-a und team-b können dieses Secret physisch nicht lesen. Das zwingt Admins dazu, redundante Secrets durch Skripte 20x über alle Namespaces hinweg zu kopieren und synchron zu halten (Was ein Albtraum bei Secret-Rotation ist). Tools wie "Kubernetes Reflector" lösen das, in dem sie als Operator laufen und annotierte Secrets eigenmächtig durch den Cluster in alle Kind-Namespaces replizieren.

Quick-Check

Sind Nodes im Namespace?
Nein! Nodes (kubectl get nodes) sind globale Ressourcen. Ein Node gehört dem Cluster, nicht einem Team. Pods aus ns-a und ns-b können wild gemischt auf demselben Node laufen (es sei denn, man nutzt Taints/Tolerations).
DNS-Namen?
Service-Namen sind: service-name.namespace.svc.cluster.local. Wenn ich im gleichen Namespace bin, reicht service-name. Wenn ich in einen anderen will, brauche ich den FQDN.
Hierarchische Namespaces?
Gibt es nativ nicht (alles ist flach). Aber es gibt das HNC (Hierarchical Namespace Controller) Projekt, um "Parent" und "Child" Namespaces zu bauen (für Abteilungen -> Teams).