Isolation: Namespace vs. Cluster vs. vCluster

Lernziele

Nach dieser Lektion kannst du die drei technischen Isolationsebenen — Namespace, vCluster und dedizierter Cluster — präzise gegeneinander abgrenzen: was jede Ebene isoliert, was sie teilt und welche Angriffs- bzw. Störflächen offen bleiben. Du verstehst, warum ein Namespace keine Sicherheitsgrenze ist, was ein vCluster technisch tut, und kannst die passende Ebene für ein gegebenes Isolationsbedürfnis wählen.

Das Problem: „Isolation” ist kein Ja/Nein, sondern ein Stapel

Lektion 19 hat entschieden, welche Tenants sich Infrastruktur teilen. Jetzt wird es konkret: Wie viel Trennung liefert die jeweilige Technik wirklich? Die Frage hat mehrere unabhängige Dimensionen, die in Diskussionen ständig vermischt werden:

• Control-Plane-Isolation: Teilen sich Tenants einen API-Server, etcd, Controller — und damit dessen Kapazität, CRDs und Versionsstand?
• Workload-Isolation: Teilen sich Container Kernel und Node-Ressourcen?
• Netzwerk-Isolation: Wer kann mit wem reden? (Vertieft in Lektion 22.)
• Operative Isolation: Trifft ein Upgrade oder ein Ausfall einen Tenant oder alle?

Jede Isolationsebene beantwortet diese Dimensionen anders — und genau diese Differenzierung trennt im Interview die präzise Antwort von der Buzzword-Antwort.

Namespaces: Verwaltungsgrenze, keine Sicherheitsgrenze

Der Namespace ist die billigste Einheit: sofort erstellt, kein Overhead. Mit RBAC (wer darf was im Namespace), ResourceQuota und LimitRange (wie viel CPU/Memory/Objekte) und NetworkPolicies (wer redet mit wem) wird daraus Namespace-as-a-Service — das Arbeitspferd des Shared-Modells.

Was der Namespace nicht isoliert, musst du auswendig können:

• Den Kernel: Alle Container auf einem Node teilen sich den Host-Kernel. Ein Container-Escape (Kernel-Exploit, Fehlkonfiguration mit privileged Pods) überschreitet jede Namespace-Grenze. Gegenmittel sind Node-Ebene-Maßnahmen: Pod Security Standards (restricted erzwingen), Sandbox-Runtimes wie gVisor/Kata für besonders misstrauische Workloads, oder Node-Pools pro Tenant via Taints und NodeSelectors.
• Die Control Plane: API-Server, etcd, Scheduler und DNS sind geteilt. Ein Tenant, der den API-Server flutet, bremst alle — API Priority and Fairness mildert das, beseitigt es nicht.
• Cluster-weite Objekte: CRDs, ClusterRoles, Webhooks, Operatoren existieren einmal pro Cluster. Zwei Teams, die verschiedene Versionen desselben Operators brauchen, sind im Namespace-Modell nicht abbildbar.

Die ehrliche Formel: Namespaces isolieren Verwaltung und Fairness, nicht Sicherheit gegen einen entschlossenen Angreifer und nicht Control-Plane-Autonomie.

Dedizierte Cluster: maximale Trennung, maximaler Aufwand

Das andere Ende des Spektrums kennt du aus Lektion 19: eigener API-Server, eigenes etcd, eigene Nodes, eigene Upgrade-Zeitlinie. Alle vier Isolations-Dimensionen sind hart getrennt — inklusive der operativen: Ein verunglücktes Upgrade trifft genau einen Tenant.

Technisch interessant ist hier vor allem, was trotzdem geteilt bleiben kann und gern übersehen wird: das Cloud-Konto (IAM-Grenzen, Service-Quotas, Netzwerk-Peering), zentrale Dienste wie Registry, Identity Provider und Observability-Backend, und die Automatisierung selbst. Wer harte Mandantentrennung für Auditoren braucht, muss die Grenze oft bis auf Account-/Subscription-Ebene ziehen — der Cluster allein ist nur ein Teil der Trennung.

vCluster: ein API-Server im Pod

Die interessante Mittelschicht: Ein virtueller Cluster (das bekannteste Tool ist vCluster von Loft Labs) startet im Namespace des Host-Clusters einen eigenen, vollwertigen Kubernetes-API-Server mit eigenem Datastore — typischerweise als StatefulSet. Tenants verbinden sich per kubeconfig mit ihrem virtuellen API-Server und sehen einen kompletten Cluster: eigene Namespaces, eigene CRDs, eigene RBAC, sogar eigene Kubernetes-Version (innerhalb der Kompatibilitätsgrenzen).

Der Mechanismus dahinter: Ein Syncer übersetzt zwischen virtuell und real. Pods, die im vCluster angelegt werden, synct er — mit umgeschriebenen Namen — in den Host-Namespace, wo der echte Scheduler sie auf echte Nodes plant. Die meisten anderen Objekte (Deployments, CRDs, ConfigMaps) bleiben rein virtuell im Datastore des vClusters und belasten den Host-API-Server gar nicht.

Damit ergibt sich ein präzises Isolationsprofil:

• Control Plane: isoliert. Eigene CRDs und Operatoren pro Tenant, eigene API-Server-Kapazität, eigene RBAC-Welt — die größte Schwäche des Namespace-Modells ist behoben. Admin-Rechte im vCluster sind möglich, ohne Host-Rechte zu vergeben.
• Workloads: geteilt. Die Pods laufen auf denselben Nodes mit demselben Kernel wie alle anderen. Für Kernel-Level-Sicherheit gewinnt ein vCluster nichts — dieselben Gegenmittel wie beim Namespace-Modell (Pod Security, Sandboxing, Node-Pools) bleiben nötig.
• Operativ: teilweise getrennt. Der Tenant kann seinen virtuellen Cluster jederzeit neu erstellen oder upgraden; ein Host-Cluster-Problem trifft aber weiterhin alle vCluster darauf.

Die Sweet Spots: Ephemere Dev-/Test-Umgebungen (ein vCluster startet in Sekunden bis Minuten und kostet nur seine Pods — perfekt für Preview-Umgebungen, Lektion 23), Teams mit eigenen Operator-/CRD-Bedürfnissen im Shared-Modell, und CI-Pipelines, die „einen frischen Cluster” brauchen, ohne einen zu provisionieren.

Die Auswahl-Logik: Bedrohung und Bedürfnis bestimmen die Ebene

Wähle die Ebene anhand der Frage, wovor du isolierst:

Isolationsbedürfnis	passende Ebene
Fairness & Ordnung zwischen vertrauenswürdigen Teams	Namespace + Quotas + RBAC + NetworkPolicies
Eigene CRDs/Operatoren, Cluster-Admin-Gefühl, schnelle Wegwerf-Umgebungen	vCluster
Schutz vor Kernel-Escapes / nicht vertrauenswürdiger Code	Sandbox-Runtime oder dedizierte Nodes — unabhängig von Namespace/vCluster
Regulatorische Mandantentrennung, eigene Upgrade-Zeitlinien, extreme Last	Dedizierter Cluster (ggf. eigenes Cloud-Konto)

Zwei Lesehinweise zur Tabelle, die in Interviews Punkte bringen: Erstens sind die Ebenen kombinierbar — ein realistisches Setup nutzt Namespaces als Default, vCluster für Sonderbedarf und dedizierte Cluster für Compliance-Tenants. Zweitens ist die Kernel-Zeile bewusst quer: Workload-Sicherheit hängt an der Runtime und den Nodes, nicht an der Control-Plane-Virtualisierung — wer „vCluster” auf die Frage nach Container-Escape antwortet, hat das Modell nicht verstanden.

Praxis: vCluster anfassen und die Grenze sehen

Auf einem lokalen kind-Cluster (vCluster-CLI installiert):

kind create cluster --name host
vcluster create team-a --namespace team-a

# Die CLI verbindet dich automatisch; prüfe die virtuelle Sicht:
kubectl get namespaces        # frische Namespace-Liste — das ist der vCluster
kubectl create deployment web --image=nginx
kubectl get pods              # Pod existiert im vCluster

# Zurück zur Host-Sicht:
vcluster disconnect
kubectl get pods -n team-a    # derselbe Pod, synct mit umgeschriebenem Namen
kubectl get deployments -n team-a   # leer! Das Deployment ist rein virtuell

Der letzte Befehl ist der Lerneffekt der Übung: Das Deployment lebt nur im Datastore des vClusters, der Pod dagegen real im Host-Namespace — du siehst die Syncer-Grenze mit eigenen Augen. Lege danach im vCluster eine CRD an und bestätige, dass sie im Host nicht existiert. Aufräumen: vcluster delete team-a — und beachte, wie schnell ein kompletter „Cluster” verschwindet.

Typische Stolperfallen

„Namespace-Isolation” als Sicherheitsversprechen verkaufen: Gegen einen Angreifer mit Container-Escape oder gegen einen privilegierten Pod hilft die Namespace-Grenze nicht. Sicherheits-Claims brauchen immer die Workload-Dimension: Pod Security Standards, Runtime, Node-Trennung.

vCluster als Sicherheits-Upgrade missverstehen: vCluster löst Control-Plane-Probleme (CRDs, RBAC-Autonomie, API-Server-Lärm), nicht Kernel-Probleme. Beides in einem Satz unterscheiden zu können ist der Litmustest.

Quotas und Policies im Shared-Modell „später” nachrüsten: Ohne ResourceQuota, LimitRange und Default-NetworkPolicies vom ersten Tag ist jeder spätere Rollout ein Breaking Change für Bestandsteams. Isolation gehört in den Namespace-Provisioning-Pfad (Lektion 16), nicht in ein Hardening-Projekt danach.

Die Node-Dimension vergessen: Auch im dedizierten Cluster können sich kritische und unkritische Workloads desselben Tenants Nodes teilen. Taints, dedizierte Node-Pools und Sandbox-Runtimes sind eine eigene Entscheidungsachse, die quer zu allen drei Ebenen liegt.

Interview-Vorbereitung

Die Standardfrage „Namespace vs. Cluster vs. vCluster — wann was?” beantwortest du über die Dimensionen: Erst klären, was isoliert werden soll (Control Plane? Kernel? Betrieb? Netzwerk?) → dann mappen (Namespace: Verwaltung/Fairness; vCluster: Control-Plane-Autonomie auf geteilten Nodes; dedizierter Cluster: alles, inkl. operativer Trennung) → Querschnitt benennen (Workload-Sicherheit hängt an Runtime und Nodes, nicht an der Ebene) → Kombination als Realität (Default Namespace, vCluster für Sonderfälle, dedicated für Compliance).

Wahrscheinliche Follow-ups:

• „Warum ist ein Namespace keine Sicherheitsgrenze?” — geteilter Kernel und geteilte Control Plane; RBAC trennt API-Zugriffe, aber Container-Escapes und privilegierte Pods umgehen die Grenze vollständig.
• „Was genau macht der vCluster-Syncer?” — Pods (und wenige nötige Objekte wie Services) aus dem virtuellen API-Server in den Host-Namespace übersetzen, damit der echte Scheduler sie platziert; der Rest bleibt virtuell.
• „Ein Team braucht eine andere Operator-Version als der Rest — was tust du?” — klassischer vCluster-Fall: eigene CRDs und Operatoren im virtuellen Cluster, ohne den Host zu berühren; Alternative dedizierter Cluster, wenn zusätzlich operative Trennung nötig ist.
• „Wie isolierst du nicht vertrauenswürdigen Code?” — Sandbox-Runtime (gVisor/Kata) oder dedizierte Nodes/Cluster; Namespace- und vCluster-Ebene sind hierfür irrelevant.

Zusammenfassung

Isolation ist ein Stapel unabhängiger Dimensionen: Namespaces trennen Verwaltung und Fairness auf geteilter Control Plane, vCluster geben jedem Tenant einen eigenen API-Server samt CRD- und RBAC-Welt auf weiterhin geteilten Nodes, dedizierte Cluster trennen auch Betrieb und Ausfall — und Workload-Sicherheit (Kernel!) ist eine Querschnittsachse, die an Runtimes und Node-Zuordnung hängt, nicht an der gewählten Ebene. Reale Plattformen kombinieren alle drei entlang der Tiers aus Lektion 19.

Isolierte Tenants brauchen als Nächstes faire Anteile: Die folgende Lektion behandelt Resource Governance — Quotas, Prioritäten und die FinOps-Seite mit Showback und Chargeback.