Kubernetes-Multi-Tenancy wird fast immer als eine einzige Achse gezeichnet: Namespace → vCluster → eigener Cluster. Links billig und schwach, rechts teuer und solide, such dir einen Punkt nach deinem Risikoappetit.
Die Achse ist bequem und falsch. vCluster besetzt darauf seit Kurzem zwei verschiedene Stellen, und der Preis eigener Cluster wächst nicht mit ihrer Anzahl. Die Entscheidung zerfällt in drei Fragen, und deren Reihenfolge liegt fest.
Frage eins: wer ist der Tenant
Ein Namespace ist keine Sicherheitsgrenze. Er ist keine virtuelle Maschine, der Kernel ist geteilt, und ein privilegierter Container läuft auf den Host hinaus, egal wie viele RBAC-Rollen darum herumhängen. Daher die erste Wasserscheide: Schützt man sich vor dem versehentlichen Fehler des Nachbarn oder vor dem Nachbarn selbst?
Für eigene Teams mit gegenseitigem Vertrauen erledigt ein Namespace die Aufgabe, sofern er vollständig zusammengebaut ist: RBAC ohne Wildcard-Verben, NetworkPolicy default-deny (Kubernetes erlaubt zwischen Namespaces standardmäßig sämtlichen Verkehr — das ist ein Loch, keine Einstellung), ResourceQuota zusammen mit LimitRange. Genau zusammen: Quota ohne LimitRange heißt, der erste Pod ohne Requests frisst sie komplett auf. Die schwächste Schicht bestimmt die Festigkeit der ganzen Konstruktion, deshalb ist „NetworkPolicy machen wir später“ gleichbedeutend mit „machen wir nicht“.
An derselben Stelle liegt die einzige Änderung seit Jahren, die die Vertrauensgrenze wirklich verschiebt. In Kubernetes 1.36 haben User Namespaces den Status stable erreicht: hostUsers: false mappt root im Container auf eine unprivilegierte uid des Hosts, und ein Ausbruch aus dem Container bedeutet nicht mehr root auf der Node. Der Weg des Gates: alpha in 1.28, beta ab 1.30, beta standardmäßig aktiv ab 1.33, stable ab 1.36. Im Kopf behalten sollte man, dass es eine Pod-Option ist und keine Cluster-Eigenschaft: GA heißt „man kann sich darauf verlassen“, nicht „wird bereits auf eure Workloads angewendet“.
Frage zwei: braucht der Tenant Cluster-scoped Zugriff
Braucht ein Team eigene CRDs, eigene Namespaces oder Cluster-Admin im eigenen Perimeter, passt ein Namespace bei keiner RBAC-Konfiguration. Das ist keine Vertrauensfrage, sondern eine Frage des API-Geltungsbereichs. Hier beginnt vCluster: Der Tenant bekommt einen eigenen API-Server, die Workloads werden in den Host-Cluster synchronisiert.
Im vergangenen Jahr hat dieses Bild aufgehört, vollständig zu sein. vCluster hat Private Nodes bekommen — eigene Worker-Nodes des Tenant-Clusters, die in einer anderen VPC, bei einem anderen Anbieter oder auf Bare Metal stehen können und per VPN an die Control Plane angebunden werden. Isolation betrifft nicht mehr nur die Control Plane, und genau jene Achse „schwächer bis stärker“ ist auseinandergegangen: vCluster ohne Private Nodes und vCluster mit ihnen sind zwei verschiedene Antworten.
Danach beginnt das, was man vor dem Piloten durchrechnen sollte und nicht danach. Die Fähigkeiten sind auf Tiers verteilt, und die Grenzen verlaufen nicht dort, wo man sie erwartet:
- OSS (Apache 2.0) — eigene Control Planes, Ressourcen-Synchronisation, verschiedene Backing Stores. Keine Lizenz nötig, keine Verbindung zu einer externen Platform nötig.
- Free — kostenlos und ohne Kreditkarte, aber erfordert eine Verbindung zur vCluster Platform zur Lizenzvalidierung. Dazu gehören embedded etcd, Private Nodes, Custom Resource Syncing, Sync Patches und der HostPath Mapper.
- Enterprise (Dev / Prod / Scale) — Sleep Mode, externe Datenbanken, SSO, Audit-Logs, FIPS und Air-gapped-Auslieferung.
Die Folge ist scharf: Eine abgeschottete Umgebung bekommt nur den OSS-Tier, also ohne Private Nodes. Eine Organisation, die vCluster wegen dedizierter Nodes gewählt hat und nicht zur Validierung nach Hause telefonieren darf, entdeckt das während der Einführung. Ein altes Detail gehört ebenfalls korrigiert: Seit Version 0.20 ist die Standarddistribution der virtuellen Control Plane vanilla k8s statt k3s, und die Unterstützung für EKS als Distribution wurde damals entfernt.
Frage drei: was ein Fehler kostet
Das Standardargument gegen einen Cluster pro Team ist die Vervielfachung der Fixgebühr. Bei EKS sind das $0,10 pro Stunde und Cluster, rund $73 im Monat, und dreißig Cluster ergeben etwa $2.200 im Monat allein für Control Planes, vor jeder einzelnen Workload.
Die Vervielfachung ist nicht der teure Teil. Endet der Standard-Support einer Version, wechselt ein Cluster automatisch in den Extended Support zu $0,60 pro Stunde — das Sechsfache. Eine Flotte einzelner Cluster wird nicht proportional zur Zahl der Teams teuer, sondern proportional zur Zahl der Teams, die mit Upgrades nicht hinterherkommen. Das dreht die vertraute Rechnung um: Das Modell „ein Cluster pro Tenant“ kostet nicht $73 × N, sondern $73 × N plus eine Strafe auf organisatorische Disziplin, an der es einer wachsenden Flotte gewöhnlich fehlt. Dieses Geld auf die Tenants zu verteilen, ist die Aufgabe von Showback — OpenCost und Kubecost rechnen über Namespace-Labels, deshalb werden Labels beim Anlegen des Namespace gesetzt und nicht nachträglich.
Die Entscheidungstabelle
| Situation | Modell | Was man in Kauf nimmt |
|---|---|---|
| Eigene Teams, Vertrauen vorhanden, kein Cluster-scoped Bedarf | Namespace + RBAC + default-deny + Quota/LimitRange | Namespace ist keine Sicherheitsgrenze; Festigkeit nach der schwächsten Schicht |
| Eigene CRDs und Cluster-Admin nötig, Umgebung nicht abgeschottet | vCluster OSS | Workloads laufen im Host-Cluster; isoliert ist die Control Plane, nicht die Worker |
| Dedizierte Nodes pro Tenant nötig | vCluster + Private Nodes | Free-Tier und dauerhafte Platform-Verbindung zur Lizenzvalidierung |
| Abgeschottete Umgebung, air-gapped | vCluster OSS oder eigene Cluster | Private Nodes und Air-gapped-Auslieferung fehlen im OSS |
| Nicht vertrauenswürdiger Code, PCI-DSS, HIPAA | Eigene Cluster | $73/Monat pro Control Plane, im Extended Support $0,60/Stunde |
Die Zeile zum nicht vertrauenswürdigen Code lässt eine mildere Lesart zu: gVisor oder Kata über RuntimeClass geben Isolation auf Pod-Ebene innerhalb eines gemeinsamen Clusters, zum Preis der Performance. Das ersetzt keinen eigenen Cluster dort, wo ein Regulator Trennung verlangt, taugt aber als Zwischenlösung, wenn die Anforderung aus gesundem Menschenverstand kommt und nicht von einem Auditor.
Was man 2026 nicht mehr aufgreift
Der Hierarchical Namespace Controller mit seinem kubectl hns taucht in jeder zweiten Multi-Tenancy-Sammlung auf. Das Repository ist in die Organisation kubernetes-retired umgezogen und archiviert, der letzte Commit datiert auf April 2025, ein Nachfolger wurde nicht benannt. Darauf jetzt eine Namespace-Hierarchie zu bauen heißt, eine Migration einzuplanen.
Das Szenario „Tenant als Objekt, Quotas und Policies über eine Menge von Namespaces“ deckt Capsule ab — ein CNCF-Projekt, lebendig (v0.14.3 erschien am 31. August 2026), API-Gruppe capsule.clastix.io/v1beta2, dazu die neu hinzugekommenen globalen Quotas über mehrere Tenants hinweg. Das ist weder eine Migration von HNC noch ein Ersatz Feature für Feature: ein anderes Modell, in dem das Wurzelobjekt ein Tenant ist und kein Baum von Namespaces.
Zwei Ebenen, die regelmäßig verwechselt werden, gehören getrennt. Argo CDs AppProject schränkt ein, wer was wohin deployt, und das ist eine Delivery Boundary. Es ersetzt weder ResourceQuota noch NetworkPolicy noch Pod Security Admission im Namespace des Tenants. Ein konfiguriertes AppProject über einem leeren Namespace-Perimeter erzeugt das Gefühl von Isolation ohne Isolation. Policy auf Admission-Ebene ist eine eigene Schicht, und den Netzwerk-Perimeter baut man bequemer auf Cilium mit DNS-basiertem Egress und L7-Regeln.
Eine Reihenfolge, keine Skala
Die drei Fragen kommen in fester Reihenfolge. Wer der Tenant ist, entscheidet, ob ein Namespace überhaupt taugt. Ob er Cluster-scoped Zugriff braucht, entscheidet, ob eine virtuelle Control Plane nötig ist. Und erst danach wird der Preis gerechnet, denn er hängt von den ersten beiden Antworten ab und davon, wie schnell die Organisation Upgrades ausrollt.
Die Antworten auf die ersten beiden Fragen sind heute schon bekannt, sie müssen nicht erforscht werden. Die dritte verändert sich mit der Zeit — und sie verändert sich zum Schlechteren genau bei denen, die eigene Cluster gewählt haben, um über Isolation nicht nachdenken zu müssen.