# Kubernetes Namespaces: Logische Isolation & Multi-Tenancy Design

TL;DR / Management Summary Ein einzelner Kubernetes-Cluster wird oft von mehreren Teams oder Projekten gleichzeitig genutzt. Namespaces erlauben es, den Cluster in virtuelle Teilbereiche zu unterteilen. Ein Senior Admin nutzt Namespaces zur Isolation von Ressourcen, zur Durchsetzung von Quotas (Verbrauchslimits) und als Basis für das Berechtigungskonzept (RBAC). Ziel ist ein Multi-Tenant Cluster, in dem Team A niemals die Ressourcen oder Geheimnisse von Team B sehen oder stören kann.

# 1. Was ist ein Namespace?

Der virtuelle Cluster.

Ein Namespace ist ein logischer Container für Kubernetes-Objekte (Pods, Services, Deployments).

Default Namespaces:
- default: Für alles, was keinen Namespace hat.
- kube-system: Für die internen K8s-Komponenten.
- kube-public: Für Informationen, die für alle (auch unauthentifiziert) lesbar sein sollen.
Isolation: Namen (z.B. der Service db) müssen nur innerhalb eines Namespaces eindeutig sein.

# 2. Multi-Tenancy Strategien

Grenzen ziehen.

# 1. Hard Multi-Tenancy

Jedes Team bekommt einen eigenen physischen Cluster (Teuer, hoher Wartungsaufwand).

# 2. Soft Multi-Tenancy (Empfohlen)

Alle Teams teilen sich einen Cluster, sind aber via Namespaces getrennt.

Isolation: Durchsetzung via Network Policies (Artikel 774).
Quota: Begrenzung von CPU/RAM pro Namespace.

# 3. Deep Dive: Resource Quotas & Limits

Gerechtigkeit am Node.

Verhindern Sie, dass ein Team den gesamten Cluster “leersaugt”.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: marketing-quota
  namespace: marketing
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "20"

Aktion: Wenn das Team versucht, den 21. Pod zu starten, verweigert die API den Befehl.

# 4. Day-2 Operations: RBAC pro Namespace

Macht delegieren.

Nutzen Sie Roles und RoleBindings, um den Zugriff einzuschränken.

Szenario: Der Entwickler Max darf alles im Namespace dev, aber hat keine Leserechte im Namespace prod.
Vorteil: Minimierung des menschlichen Fehlerrisikos (versehentliches Löschen in der falschen Umgebung).

# 5. Troubleshooting & “War Stories”

Wenn die Wände durchlässig sind.

# Top 3 Herausforderungen

Symptom: Pod kann Dienst im anderen Namespace nicht erreichen.
- Ursache: DNS-Auflösung über Namespace-Grenzen erfordert den FQDN: <service>.<namespace>.svc.cluster.local.
- Lösung: Dokumentieren Sie die DNS-Konventionen.
Symptom: “Forbidden” Fehler beim Erstellen von Ressourcen.
- Ursache: Das Resource-Quota wurde erreicht oder der User hat keine Rechte im Namespace.
- Lösung: kubectl describe quota -n <namespace> prüfen.
Symptom: Secrets aus Namespace A sind in B sichtbar.
- Ursache: Fehlkonfiguration der Service-Accounts.

# “War Story”: Der “Vampir”-Entwickler

Ein Unternehmen betrieb einen Shared-Cluster ohne Quotas. Ein Entwickler startete ein Experiment mit maschinellem Lernen in seinem Namespace. Das Ereignis: Der ML-Job forderte 100% der verfügbaren GPU- und CPU-Ressourcen des gesamten Clusters an. Das Ergebnis: Da keine Quotas gesetzt waren, verdrängte der Test-Job die produktiven Webserver von den Nodes. Die Website war für 2 Stunden offline. Lehre: Namespaces ohne ResourceQuotas sind nur kosmetische Ordner. Wirkliche Sicherheit und Stabilität erfordern harte physikalische Grenzen.

# 6. Monitoring & Reporting

Verbrauch pro Mandant.

# Resource Usage Dashboard

Überwachen Sie in Grafana (Artikel 698):

CPU/RAM usage per Namespace.
Quota saturation %. (Planen Sie Budget-Erweiterungen, wenn ein Team dauerhaft bei 90% liegt).

# 7. Fazit & Empfehlung

Namespaces sind das Fundament für ein skalierbares Team-Modell.

Empfehlung: Erstellen Sie für jedes Projekt und jede Umgebung (Dev/Prod) einen eigenen Namespace.
Wichtig: Nutzen Sie LimitRanges, um Standard-Ressourcenwerte für alle Pods innerhalb eines Namespaces vorzugeben, damit kein Pod “nackt” (ohne Limits) gestartet wird.

# Anhang: Cheatsheet (kubectl namespace)

Aufgabe	Befehl
Namespace erstellen	`kubectl create namespace <name>`
Context wechseln	`kubectl config set-context --current --namespace=<name>`
Ressourcen listen	`kubectl get all -n <name>`
Quota prüfen	`kubectl get quota -n <name>`