Kubernetes Namespaces — Multi-Tenancy in der Praxis

Ein Kubernetes-Cluster, fünf Teams, drei Kunden. Wie stellt man Isolierung, faire Ressourcenverteilung sicher und verhindert, dass ein Team alle Ressourcen der anderen verbraucht? Namespaces mit Resource Quotas.

Namespace pro Tenant¶

Jedes Team/jeder Kunde erhält seinen eigenen Namespace: team-alpha, client-bank, client-insurance. In Kombination mit RBAC ist dies der grundlegende Baustein für Multi-Tenancy.

Resource Quotas¶

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-alpha-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 16Gi
    limits.cpu: "16"
    limits.memory: 32Gi
    pods: "50"
    services: "20"

Team Alpha hat garantierte 8 CPU und 16 GB RAM. Sie können bis zu 16 CPU und 32 GB bursten, aber nicht mehr. Maximal 50 Pods.

LimitRange — Standardwerte für Pods¶

LimitRange setzt Standard-Requests und -Limits für Pods, die keine angeben. Schutz gegen „Pod ohne Limits, der den gesamten Node verbraucht.”

Network Policies pro Namespace¶

Default Deny in jedem Namespace + explizites Allow. Namespace team-alpha kann nicht mit client-bank kommunizieren. Isolierung auf Netzwerkebene.

Zugriffsbeschränkungen¶

• RBAC: Admin im Namespace, Read-Only im Cluster
• Resource Quotas: faire Verteilung von Compute-Ressourcen
• Network Policies: Netzwerkisolierung
• Pod Security Policies: Sicherheitseinschränkungen

Soft Multi-Tenancy ist erreichbar¶

Namespaces mit RBAC, Quotas und Network Policies bieten ausreichende Isolierung für Teams innerhalb einer Organisation. Für Hard Multi-Tenancy (nicht vertrauenswürdige Tenants) sollten separate Cluster in Betracht gezogen werden.