Kubernetes Namespaces: Multi-Tenancy richtig umsetzen

TL;DR

• Namespaces sind logische Trennungseinheiten in Kubernetes -- sie isolieren Ressourcen, Berechtigungen und Netzwerk-Traffic voneinander.
• Die fuenf gaengigen Patterns sind: nach Umgebung, nach Team, nach Applikation, nach Kunde (fuer SaaS) und als Hybrid-Ansatz.
• ResourceQuotas und LimitRanges verhindern, dass ein Namespace den gesamten Cluster auffrisst ("Noisy Neighbor"-Problem).
• NetworkPolicies sind Pflicht in Produktion -- ohne sie kann jeder Pod mit jedem anderen Pod im Cluster kommunizieren.
• Ein GitOps-Ansatz fuer Namespace-Konfigurationen macht Aenderungen nachvollziehbar und reproduzierbar.

Was Namespaces sind und was sie nicht sind

Namespaces erzeugen eine logische Trennung innerhalb eines Clusters. Ressourcen wie Pods, Services, ConfigMaps und Secrets leben innerhalb eines Namespaces und sind per Default nur dort sichtbar.

Was Namespaces nicht bieten: echte Sicherheits-Isolation auf Kernel-Ebene. Ein Container in Namespace A und ein Container in Namespace B teilen sich denselben Kernel. Wer harte Isolation braucht (z.B. zwischen verschiedenen Kunden mit unterschiedlichen Compliance-Anforderungen), sollte entweder separate Cluster oder vCluster einsetzen.

Trotzdem sind Namespaces das wichtigste Organisationswerkzeug in Kubernetes. Richtig eingesetzt, reduzieren sie operativen Overhead, erhoehen die Sicherheit und machen Kostenverteilung transparent.

Die fuenf Namespace-Patterns

Pattern 1: Trennung nach Umgebung

Das einfachste und am haeufigsten eingesetzte Pattern. Jede Umgebung bekommt einen eigenen Namespace:

dev
staging
production

Wann sinnvoll: Kleine Teams (bis 10 Entwickler), wenige Applikationen, einfache Organisationsstruktur.

Nachteil: Skaliert schlecht. Wenn 5 Teams jeweils 3 Services betreiben, liegen alle 15 Prod-Services in einem Namespace. RBAC wird unuebersichtlich.

Pattern 2: Trennung nach Team

Jedes Team erhaelt seinen eigenen Namespace:

team-platform
team-backend
team-data
team-frontend

Wann sinnvoll: Wenn Teams autonom arbeiten und eigene Release-Zyklen haben. Typisch bei Platform-Engineering-Setups.

Nachteil: Umgebungstrennung (dev vs. prod) fehlt. Entweder braucht man Sub-Namespaces oder separate Cluster fuer Produktion.

Pattern 3: Trennung nach Applikation

Jede Applikation oder jeder Microservice bekommt einen eigenen Namespace:

app-checkout
app-inventory
app-payment
app-user-service

Wann sinnvoll: Microservice-Architekturen mit klaren Ownership-Grenzen. Ermoeglicht feingranulare ResourceQuotas pro Service.

Nachteil: Die Namespace-Anzahl kann schnell dreistellig werden. Tooling (Monitoring, Dashboards) muss damit umgehen koennen.

Pattern 4: Trennung nach Kunde (SaaS)

Fuer SaaS-Anbieter, die Workloads pro Kunde isolieren:

tenant-acme-corp
tenant-globex-inc
tenant-initech

Wann sinnvoll: Wenn Kunden regulatorische Anforderungen an Datenisolation stellen (z.B. DSGVO, Finanzbranche).

Nachteil: Hoher Management-Overhead. Automatisierung ueber Operatoren oder Hierarchical Namespaces ist Pflicht.

Pattern 5: Hybrid (Empfehlung)

Die Kombination aus Umgebung und Team/Applikation:

prod-team-backend
prod-team-data
staging-team-backend
dev-team-backend
shared-infra

Wann sinnvoll: Die meisten Szenarien ab mittlerer Komplexitaet. Bietet sowohl Umgebungstrennung als auch Team-Autonomie.

Namespace-Erstellung mit Labels und Annotations

Ein Namespace ist schnell erstellt. Der Unterschied zwischen einem funktionierenden und einem wartbaren Setup liegt in den Labels und Annotations:

apiVersion: v1
kind: Namespace
metadata:
  name: prod-team-backend
  labels:
    environment: production
    team: backend
    cost-center: "CC-4200"
    managed-by: gitops
  annotations:
    contact: backend-team@example.com
    description: "Produktions-Workloads des Backend-Teams"

Die Labels environment und team sind nicht optional -- sie werden fuer NetworkPolicies, ResourceQuotas und Monitoring-Dashboards benoetigt. Das Label cost-center ermoeglicht spaeter eine Kostenzuordnung ueber Tools wie Kubecost.

ResourceQuotas: Cluster-Ressourcen fair verteilen

Ohne Quotas kann ein einzelnes Deployment den gesamten Cluster blockieren. ResourceQuotas setzen harte Grenzen pro Namespace:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: prod-backend-quota
  namespace: prod-team-backend
spec:
  hard:
    requests.cpu: "8"
    requests.memory: "16Gi"
    limits.cpu: "16"
    limits.memory: "32Gi"
    pods: "40"
    services: "10"
    persistentvolumeclaims: "8"
    requests.storage: "100Gi"

Dazu gehoert eine LimitRange, die Default-Werte fuer Pods setzt, die keine eigenen Limits definieren:

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: prod-team-backend
spec:
  limits:
  - default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "100m"
      memory: "128Mi"
    max:
      cpu: "4"
      memory: "8Gi"
    min:
      cpu: "50m"
      memory: "64Mi"
    type: Container

Ein haeufiger Fehler: Die Quota wird zu eng gesetzt und Deployments koennen keine neuen Pods mehr starten. Starten Sie mit grosszuegigen Werten und ziehen Sie nach 2-4 Wochen basierend auf den tatsaechlichen Metriken nach.

Mehr zum Thema Kapazitaetsplanung finden Sie unter Kubernetes Capacity Planning.

RBAC: Wer darf was in welchem Namespace

RBAC ist der Mechanismus, um Zugriff pro Namespace zu steuern. Das Konzept: Roles definieren Berechtigungen, RoleBindings weisen sie Benutzern oder ServiceAccounts zu.

Hier ein typisches Setup fuer ein Entwickler-Team, das in seinem Namespace deployen darf, aber keine Cluster-Ressourcen aendern kann:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
  namespace: dev-team-backend
rules:
- apiGroups: ["", "apps", "batch"]
  resources: ["pods", "deployments", "services", "configmaps", "secrets", "jobs", "cronjobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["pods/log", "pods/exec"]
  verbs: ["get", "create"]
- apiGroups: [""]
  resources: ["events"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: backend-developers
  namespace: dev-team-backend
subjects:
- kind: Group
  name: "backend-team"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

Fuer den Produktions-Namespace wuerde dieselbe Gruppe eine eingeschraenkte Rolle bekommen -- z.B. nur get, list, watch ohne create oder delete. Deployments in Produktion sollten ausschliesslich ueber die CI/CD-Pipeline laufen.

Eine Rollenmatrix hilft, den Ueberblick zu behalten:

Details zur RBAC-Konfiguration in Enterprise-Setups finden Sie unter Kubernetes RBAC Enterprise.

NetworkPolicies: Namespace-Isolation auf Netzwerk-Ebene

Default-Verhalten in Kubernetes: Jeder Pod kann mit jedem anderen Pod kommunizieren, egal in welchem Namespace. Das ist fuer Produktion nicht akzeptabel.

Eine Deny-All-Policy als Baseline pro Namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: prod-team-backend
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Danach oeffnen Sie gezielt die benoetigten Pfade. Beispiel: Ingress nur vom Ingress-Controller und vom Monitoring-Namespace erlauben:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-and-monitoring
  namespace: prod-team-backend
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: ingress-controller
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: monitoring
    ports:
    - port: 9090
      protocol: TCP

Wichtig: NetworkPolicies sind additiv. Mehrere Policies in einem Namespace werden per UNION kombiniert -- es gibt kein "Override". Planen Sie die Policy-Hierarchie entsprechend.

Vertiefung zum Thema Netzwerksicherheit finden Sie unter Kubernetes Network Policies Advanced.

Namespace-Lifecycle mit GitOps automatisieren

Namespaces, Quotas, RBAC und NetworkPolicies per kubectl apply zu verwalten, funktioniert fuer 3 Namespaces. Bei 30+ wird es fehleranfaellig. Ein GitOps-Ansatz mit ArgoCD oder Flux loest das:

Verzeichnisstruktur im Git-Repository:

namespaces/
  prod-team-backend/
    namespace.yaml
    resource-quota.yaml
    limit-range.yaml
    rbac.yaml
    network-policies.yaml
  prod-team-data/
    namespace.yaml
    resource-quota.yaml
    ...
  shared-infra/
    namespace.yaml
    ...

ArgoCD Application:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: namespace-config
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://git.example.com/infra/namespace-config.git
    targetRevision: main
    path: namespaces
  destination:
    server: https://kubernetes.default.svc
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Jede Aenderung an der Namespace-Konfiguration geht durch ein Pull Request Review. Kein Ad-hoc-kubectl-apply mehr, keine undokumentierten Aenderungen.

Monitoring pro Namespace

Kubernetes Metrics Server liefert Ressourcen-Nutzung pro Namespace. Mit Prometheus und Grafana laesst sich das zu aussagekraeftigen Dashboards ausbauen:

Nuetzliche PromQL-Queries:

# CPU-Verbrauch pro Namespace
sum(rate(container_cpu_usage_seconds_total{namespace="prod-team-backend"}[5m]))

# Memory-Verbrauch vs. Quota
sum(container_memory_working_set_bytes{namespace="prod-team-backend"})
/
kube_resourcequota{namespace="prod-team-backend", resource="limits.memory", type="hard"}

# Pod-Anzahl vs. Limit
count(kube_pod_info{namespace="prod-team-backend"})
/
kube_resourcequota{namespace="prod-team-backend", resource="pods", type="hard"}

Alerts sollten feuern, wenn ein Namespace ueber 80% seiner Quota erreicht. Dann bleibt genug Spielraum, um entweder die Quota zu erhoehen oder Ressourcen zu optimieren, bevor Deployments fehlschlagen.

Details zum Monitoring-Setup finden Sie unter Kubernetes Monitoring und Observability.

Haeufige Fehler und wie man sie vermeidet

Fehler 1: Zu viele Namespaces. 50+ Namespaces mit jeweils einem Pod sind ein Zeichen von Ueberstrukturierung. Der Verwaltungsaufwand (RBAC, Quotas, Policies pro Namespace) steht in keinem Verhaeltnis zum Nutzen. Konsolidieren Sie, wo die Isolation nicht zwingend noetig ist.

Fehler 2: Keine Default LimitRange. Ohne LimitRange koennen Pods ohne Limits gestartet werden. Ein einzelner Pod ohne Memory-Limit kann einen gesamten Node zum OOM-Kill treiben. Setzen Sie immer eine LimitRange, auch wenn die Defaults grosszuegig sind.

Fehler 3: NetworkPolicies vergessen. In vielen Clustern sind NetworkPolicies nur in Produktion konfiguriert. Das Problem: Fehler in der Policy-Konfiguration fallen erst beim Rollout auf Prod auf. Testen Sie Policies in Staging unter realistischen Bedingungen.

Fehler 4: Namespace-Benennung ohne Konvention. Ohne Konvention entstehen Namen wie backend, backend-prod, prod-backend, team-a-prod. Einigen Sie sich frueh auf ein Schema (z.B. {env}-{team} oder {env}-{app}) und setzen Sie es per Admission Controller durch.

Fehler 5: Cross-Namespace-Abhaengigkeiten nicht dokumentiert. Wenn der Service in Namespace A den Service in Namespace B ueber service-b.namespace-b.svc.cluster.local aufruft, muss das dokumentiert und in den NetworkPolicies abgebildet sein. Sonst bricht nach einer Policy-Aenderung ueberraschend die Kommunikation ab.

Zusammenfassung

Namespaces sind einfach zu erstellen, aber anspruchsvoll, wenn man sie richtig einsetzt. Die Kombination aus durchdachter Namespace-Strategie, RBAC, ResourceQuotas, LimitRanges und NetworkPolicies bildet das Fundament fuer sichere Multi-Tenancy in Kubernetes.

Starten Sie mit dem Hybrid-Pattern (Umgebung + Team), setzen Sie von Anfang an Quotas und Deny-All-NetworkPolicies, und verwalten Sie alles ueber GitOps. Das spart langfristig erheblich mehr Zeit als es initial kostet.

Wenn Sie Hilfe bei der Planung oder Umsetzung Ihrer Namespace-Strategie benoetigen, melden Sie sich bei uns unter /kontakt. Wir beraten von der ersten Architektur-Skizze bis zur produktionsreifen Konfiguration.