vCluster: Virtuelle Cluster auf Shared Nodes

“Wir brauchen einen Cluster für die Tests, aber wir haben keinen.” Das ist eine häufige Aussage in wachsenden Plattform-Teams — zu viele Teams, zu viele Environments, zu wenig Budget für echte Cluster.

vCluster bietet dafür einen pragmatischen Ansatz: ein virtueller Kubernetes-Cluster, der als reguläre Pods in einem Namespace des Host-Clusters läuft.

Wie das technisch funktioniert

Ein vCluster besteht aus zwei Teilen. Die virtuelle Control Plane — ein eigener kube-apiserver mit eigenem Datastore (per Default SQLite, für größere Setups etcd oder eine externe Datenbank) — läuft als Pod im Host-Namespace. Per Default kommt dabei K3s als schlanke Distribution zum Einsatz. Daneben läuft der Syncer, und der ist das eigentlich Interessante: im vCluster gibt es keinen echten Scheduler für Nodes. Erstellt ein Tenant einen Pod, schreibt der Syncer eine umbenannte Kopie davon in den Host-Namespace, wo der Host-Scheduler sie auf echte Nodes plant. Status-Updates synct er zurück.

Die Konsequenz dieser Architektur erklärt fast alle Eigenschaften von vCluster: Alles, was nur die API betrifft — CRDs, RBAC, Namespaces, Operatoren, Webhooks — existiert ausschließlich im vCluster und ist perfekt isoliert. Ein Team kann cluster-admin in seinem vCluster sein, drei verschiedene Versionen eines Operators testen, CRDs installieren und wieder wegwerfen, ohne dass der Host-Cluster davon etwas mitbekommt. Alles, was tatsächlich läuft — die Pods — landet auf den geteilten Host-Nodes.

Wofür es sich bewährt hat

Entwicklungs- und Test-Umgebungen: jedes Team bekommt einen eigenen vCluster statt eines Namespaces. Der Unterschied ist real — im Namespace-Modell scheitern Teams regelmäßig an cluster-weiten Ressourcen: zwei Teams brauchen verschiedene Versionen derselben CRD, jemand will einen Mutating Webhook testen, ein Operator braucht ClusterRole-Rechte. Im vCluster ist das alles Tenant-Sache.

CI-Pipelines: ein leerer vCluster startet in deutlich unter einer Minute — schnell genug, um pro Integration-Test-Lauf einen frischen Cluster zu erstellen und danach wegzuwerfen. vcluster create ci-run-4711 && vcluster connect ci-run-4711 und die Pipeline hat ein sauberes kubeconfig. Keine Restbestände aus vorherigen Läufen, keine gegenseitige Beeinflussung paralleler Pipelines.

Training und Demos: Schulungen, in denen jede Person einen “eigenen” Cluster bekommt, ohne dass dreißig echte Cluster laufen und bezahlt werden.

Der Kostenvergleich gegen echte Cluster ist deutlich: jeder EKS-Cluster kostet allein für die Control Plane gut 70 USD im Monat plus dedizierte Nodes — ein vCluster kostet die paar hundert MB Memory seiner Control-Plane-Pods und nutzt vorhandene Node-Kapazität mit. Bei zwanzig Teams mit je zwei Test-Environments summiert sich das.

Zwei Eigenschaften machen den Ansatz im Alltag zusätzlich attraktiv. Erstens lassen sich vCluster pausieren: die Control-Plane-Pods werden heruntergefahren, der Datastore bleibt erhalten — Test-Environments kosten über Nacht und am Wochenende praktisch nichts und sind beim Resume in Sekunden wieder da. Zweitens ist die Kubernetes-Version des vClusters unabhängig vom Host: ein Team kann gegen eine neuere Version testen, bevor der Host-Cluster upgegradet wird — ein erstaunlich nützliches Werkzeug für Cluster-Upgrades.

Die Grenze, die man im Interview kennen muss

Was vCluster nicht ist: echte Sicherheits-Isolation. Die synchronisierten Pods laufen auf denselben Host-Nodes und demselben Kernel wie alle anderen Tenants. Ein Container-Escape landet auf dem geteilten Node — die virtuelle API-Grenze hilft dann gar nichts. Auch Netzwerk ist per Default geteilt: ohne NetworkPolicies auf dem Host können Workloads verschiedener vCluster miteinander reden. Und laute Nachbarn bleiben laute Nachbarn — ResourceQuotas und LimitRanges auf dem Host-Namespace sind weiterhin nötig, der vCluster ersetzt sie nicht.

Die saubere Einordnung für die Multi-Tenancy-Frage: vCluster löst API-Isolation (CRDs, RBAC, Operatoren, Versionen), nicht Workload-Isolation (Kernel, Netzwerk, Ressourcen). Dieser eine Satz trennt im Interview die Kandidaten, die das Tool nur vom Namen kennen, von denen, die seine Architektur verstanden haben. Für untrusted Tenants oder regulatorisch getrennte Workloads braucht es weiterhin echte Cluster-Trennung — wo welche Stufe angemessen ist, behandelt der Artikel zu Multi-Tenancy und Namespace-Isolation ausführlicher.

Self-Service: vCluster als Plattform-Produkt

Richtig interessant wird vCluster, wenn das Platform-Team es als Self-Service anbietet. Mit Crossplane lässt sich eine EphemeralCluster-API bauen: ein XRD definiert das Interface (Name, Größe, TTL), die Composition erstellt dahinter den vCluster per Helm-Release. Entwickler beantragen einen temporären Cluster als Kubernetes-Objekt, bekommen nach einer Minute ihr kubeconfig, und nach Ablauf der TTL räumt die Plattform automatisch auf. Cluster auf Abruf, ohne Ticket, ohne Cloud-Rechnung pro Experiment — wie solche Plattform-APIs gebaut werden, zeigt der Artikel zu Crossplane Compositions.