Kubernetes Multi-Tenancy: Modelle, Isolationsebenen und Best Practices

TL;DR

• Kubernetes Multi-Tenancy bedeutet, mehrere Teams, Projekte oder Kunden auf einem gemeinsamen Cluster zu betreiben statt auf je einem dedizierten Cluster – und nichts an der Isolation passiert automatisch.
• Vier Kernebenen tragen das Ganze: Namespaces, RBAC, Network Policies und Resource Quotas (inklusive LimitRanges), plus Pod Security Standards zum Schutz auf Workload-Ebene. Fehlt eine davon, wirkt sich ein Tenant, der eigentlich isoliert bleiben sollte, auf alle anderen aus.
• Es gibt drei Isolationsmodelle: Soft (Namespace-basiert, am günstigsten, nur logische Isolation), Hard (virtuelle Cluster wie vCluster oder Capsule) und physisch (dedizierte Node Pools oder Cluster, stärkste Isolation, höchste Kosten). Die meisten Unternehmen kombinieren alle drei, statt sich auf ein einziges Modell festzulegen.
• Die meisten Ausfälle gehen auf Drift zurück, nicht auf ein schlechtes Initial-Setup: Teams konfigurieren Quotas und RBAC einmal korrekt – und fassen sie danach nie wieder an, während sich die Workloads verändern.

Setzen Sie zehn Teams auf einen Kubernetes-Cluster, und standardmäßig hindert nichts Team A daran, die Secrets von Team B zu lesen, dessen CPU zu verbrauchen oder eine Control Plane lahmzulegen, auf die auch Team B angewiesen ist. Kubernetes Multi-Tenancy schließt diese Lücke über vier konfigurierbare Ebenen: Namespaces, RBAC, Network Policies und Resource Quotas.

Mit Multi-Tenancy müssen Unternehmen nicht länger für Dutzende ungenutzte Control Planes zahlen und können Infrastruktur über Teams, Projekte oder Kunden ("Tenants") hinweg teilen. Das funktioniert aber nur, wenn jede dieser Ebenen tatsächlich konfiguriert wird – und konfiguriert bleibt. Kubernetes ist ab Werk nicht mandantenfähig. Namespaces ziehen eine logische Grenze, keine Sicherheitsgrenze. Fehlt eine Ebene, wirkt sich ein Tenant, der eigentlich isoliert bleiben sollte, auf alle anderen im Cluster aus – ob als Sicherheitsproblem oder schlicht, weil ein Workload einem anderen die CPU wegfrisst.

Warum Teams sich überhaupt einen Cluster teilen

Drei Gründe tauchen in fast jedem Fall auf: Kosten, operativer Aufwand und Entwicklungsgeschwindigkeit.

Zehn Cluster bedeuten zehn Control Planes, zehn überprovisionierte Node Pools und zehn Load Balancer, die den Großteil des Tages im Leerlauf sind. Die Konsolidierung auf zwei oder drei gemeinsame Cluster reduziert diesen Overhead unmittelbar. Auch der operative Aufwand sinkt: ein Cluster zum Patchen, ein Ort, an dem die etcd-Gesundheit überwacht wird, ein Satz konsistent zu haltender Policies – statt derselben Arbeit auf jedem einzelnen Cluster, den Sie betreiben.

Entwicklungsgeschwindigkeit ist genauso wichtig, fällt aber weniger auf. Teams, die darauf warten, dass ein Plattform-Team einen neuen Cluster provisioniert, warten Tage. Teams, die einen Namespace auf einem bestehenden Multi-Tenant-Cluster anfordern, bekommen ihn in Minuten – per Self-Service, mit bereits hinterlegten Quotas und Network Policies. Plattform-Teams nennen das "Namespace-as-a-Service", und oft ist genau das der Grund, warum sie Multi-Tenancy überhaupt aufbauen.

Die drei Multi-Tenancy-Modelle

Nicht jeder Tenant braucht dieselbe Isolation. Das gewählte Modell wägt den Blast Radius gegen die Kosten und die operative Komplexität ab, die Sie zu tragen bereit sind.

Die meisten Unternehmen legen sich nicht auf ein einziges Modell fest. Sie betreiben Soft Multi-Tenancy für vertrauenswürdige interne Teams und reservieren Hard- oder physische Isolation für die Handvoll Tenants (ein externer Kunde, ein GPU-lastiges ML-Team, ein regulierter Workload), die sie tatsächlich brauchen. Wer "Multi-Tenancy" als einfachen Ein/Aus-Schalter behandelt, über- oder unterdimensioniert viele dieser Projekte von Anfang an.

Die Isolationsebenen, die Soft Multi-Tenancy tragen

Die meisten Teams starten standardmäßig mit Soft Multi-Tenancy. Vier Ebenen bilden sie – und jede einzelne muss konfiguriert werden; keine ist ab Werk aktiv.

Namespaces liefern die Grenze, an der alles andere ansetzt: den Ort, an dem RBAC, Quotas und Network Policies greifen. Für sich genommen isolieren sie Namen, kein Verhalten. Ein Pod in Namespace A kann weiterhin mit einem Pod in Namespace B kommunizieren, und ein Workload ohne Ressourcenlimits kann weiterhin einen Node auslasten, den auch die Pods von Namespace B nutzen.

RBAC entscheidet, wer worauf zugreifen darf. Starten Sie mit Deny-by-Default, vergeben Sie nur die Rollen, die das Team eines Tenants tatsächlich braucht, und binden Sie Berechtigungen an Gruppen statt an einzelne Nutzer, damit Zugriffe nicht veralten, wenn Personen Teams wechseln oder verlassen. RBAC-Wildwuchs pro Tenant (Dutzende fast identischer Roles und RoleBindings, die auseinanderdriften) gehört zu den Hauptgründen, warum Multi-Tenant-Cluster mit der Zeit immer schwerer zu auditieren sind.

NetworkPolicy verhindert, dass Tenants sich gegenseitig über das Netzwerk erreichen – etwas, das RBAC und Namespaces allein nicht leisten:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: team-a

Die meisten Teams starten mit einer Default-Deny-Policy pro Namespace und ergänzen dann explizite Allow-Regeln für alles, was tatsächlich Namespace-übergreifend kommunizieren muss. Ohne sie kann standardmäßig jeder Pod im Cluster jeden anderen Pod erreichen. Namespaces erzwingen von sich aus keine Netzwerkgrenzen.

ResourceQuotas und LimitRanges verhindern, dass ein Tenant dem Rest des Clusters CPU, Arbeitsspeicher oder Objektkontingente entzieht. Eine ResourceQuota deckelt, was ein Namespace insgesamt verbrauchen darf; eine LimitRange setzt darin sinnvolle Defaults und Maxima pro Container. Multi-Tenancy und das Noisy-Neighbor-Problem treffen genau hier aufeinander: Eine Quota schützt den Cluster nur dann, wenn die dahinterliegenden Requests und Limits korrekt und nah an der realen Nutzung gesetzt sind. Zu locker gesetzte Quotas stoppen keine Noisy Neighbors; zu eng gesetzte Quotas verleiten Teams dazu, zu viel anzufordern – und verspielen genau die Konsolidierungsersparnis, die Multi-Tenancy versprochen hat.

Pod Security Standards runden das Ganze auf Workload-Ebene ab: Sie beschränken privilegierte Container, Host-Networking und Root-Zugriff pro Namespace, damit ein Angreifer, der einen Pod eines Tenants kompromittiert, nicht auf den Node oder den Rest des Clusters eskalieren kann.