vCluster Multi-Tenancy: Virtuelle Kubernetes-Cluster statt Namespace-Chaos

TL;DR

• vCluster laeuft als Pod-Set in einem Host-Namespace und stellt pro Mandant einen eigenen API-Server, Controller-Manager und etcd bereit.
• Im Vergleich zu reinen Namespaces erhalten Teams eigene CRDs, eigene RBAC-Regeln und unabhaengige Kubernetes-Versionen -- ohne den Host-Cluster zu destabilisieren.
• Der Syncer synchronisiert Pods, Services und PVCs bidirektional zwischen virtuellem und physischem Cluster.
• Provisionierung dauert unter 60 Sekunden und laesst sich per Terraform oder GitOps vollstaendig automatisieren.
• Infrastrukturkosten sinken messbar, weil mehrere Teams einen gemeinsamen Node-Pool nutzen statt eigene Cluster zu betreiben.

Das Problem: Namespaces reichen nicht

Namespaces trennen Ressourcen logisch, aber sie teilen sich den gleichen API-Server, die gleiche etcd-Instanz und die gleichen Admission-Webhooks. In der Praxis fuehrt das zu konkreten Problemen.

Ein Team installiert einen Webhook, der alle Pod-Creates abfaengt. Ein anderes Team deployt CRDs, die mit bestehenden kollidieren. Ein dritter Mandant braucht eine aeltere Kubernetes-Version fuer Zertifizierungstests. All das ist mit Namespaces allein nicht sauber loesbar.

Dedizierte Cluster pro Team loesen das Isolationsproblem, aber die Kosten explodieren. Drei Control Planes mit je drei etcd-Nodes, drei Monitoring-Stacks und drei Ingress-Controllern -- das summiert sich schnell auf fuenfstellige Monatsbetraege. Mehr zu diesem Kostenthema unter Kubernetes Hosting: Cloud vs. On-Premise Kostenvergleich.

Was vCluster technisch macht

vCluster erzeugt eine vollstaendige Kubernetes Control Plane innerhalb eines einzelnen Namespace auf dem Host-Cluster. Konkret werden folgende Komponenten als Pods gestartet:

• API-Server (k3s, k0s oder vollstaendiges k8s, konfigurierbar)
• Controller-Manager und Scheduler
• etcd (embedded oder als separater Pod)
• Syncer -- das Herzstueck, das Ressourcen zwischen virtuellem und physischem Cluster abgleicht

Wenn ein Entwickler im vCluster kubectl apply ausfuehrt, landet der Request beim virtuellen API-Server. Der Syncer erkennt die neue Ressource und erstellt das Pendant auf dem Host-Cluster. Pods laufen also physisch auf den Host-Nodes, sind aber im virtuellen Cluster sichtbar und verwaltbar.

Namespaces vs. vCluster: Vergleich

Fuer grundlegendes Namespace-Management gibt es bewehrte Patterns -- siehe Kubernetes Multi-Tenancy Patterns. Sobald Teams aber eigene CRDs, Webhooks oder K8s-Versionen brauchen, ist vCluster die sauberere Loesung.

Praxis: vCluster aufsetzen

Variante 1: vCluster CLI

Die schnellste Methode fuer einen ersten Test:

# vCluster CLI installieren (macOS/Linux)
curl -L -o vcluster "https://github.com/loft-sh/vcluster/releases/latest/download/vcluster-linux-amd64"
chmod +x vcluster && sudo mv vcluster /usr/local/bin/

# Virtuellen Cluster erstellen
vcluster create team-frontend \
  --namespace vcluster-frontend \
  --kubernetes-version v1.29.2

# Kubeconfig fuer den vCluster erhalten und testen
vcluster connect team-frontend --namespace vcluster-frontend
kubectl get nodes   # Zeigt virtuelle Nodes
kubectl get ns      # Eigener Namespace-Baum

# Zurueck zum Host-Cluster
vcluster disconnect

Nach vcluster connect zeigt kubectl get nodes virtuelle Nodes an. Diese repraesentieren die tatsaechlichen Host-Nodes, aber der vCluster-Nutzer sieht nur das, was der Syncer freigibt.

Variante 2: Helm mit Custom Values

Fuer reproduzierbare Setups per GitOps eignet sich Helm besser:

# vcluster-team-frontend.yaml
vcluster:
  image: rancher/k3s:v1.29.2-k3s1
  resources:
    requests:
      cpu: 200m
      memory: 256Mi
    limits:
      cpu: 1000m
      memory: 1Gi

syncer:
  extraArgs:
    ---tls-san=team-frontend.vcluster.internal
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 500m
      memory: 512Mi

sync:
  ingresses:
    enabled: true
  persistentvolumes:
    enabled: true
  storageclasses:
    enabled: true
  networkpolicies:
    enabled: true

isolation:
  enabled: true
  resourceQuota:
    enabled: true
    quota:
      requests.cpu: "4"
      requests.memory: 8Gi
      limits.cpu: "8"
      limits.memory: 16Gi
      pods: "50"
      services: "20"
      persistentvolumeclaims: "10"
  limitRange:
    enabled: true
    defaultRequest:
      cpu: 100m
      memory: 128Mi
    default:
      cpu: 500m
      memory: 512Mi
  networkPolicy:
    enabled: true

helm upgrade --install team-frontend vcluster \
  --repo https://charts.loft.sh \
  --namespace vcluster-frontend \
  --create-namespace \
  --values vcluster-team-frontend.yaml

Der isolation-Block ist entscheidend: Er setzt ResourceQuotas und LimitRanges im vCluster, sodass ein einzelner Mandant nicht den kompletten Host-Cluster auslastet. Die NetworkPolicy stellt sicher, dass vCluster-Pods nur mit Pods im selben vCluster kommunizieren koennen.

Variante 3: Terraform fuer Infrastructure-as-Code

Wer mehrere vCluster-Instanzen verwaltet, automatisiert am besten mit Terraform:

resource "helm_release" "vcluster" {
  for_each = toset(["team-frontend", "team-backend", "team-data", "staging"])

  name       = each.key
  repository = "https://charts.loft.sh"
  chart      = "vcluster"
  namespace  = "vcluster-${each.key}"
  create_namespace = true

  values = [
    templatefile("${path.module}/vcluster-values.yaml.tpl", {
      team_name   = each.key
      cpu_limit   = each.key == "team-data" ? "16" : "8"
      memory_limit = each.key == "team-data" ? "32Gi" : "16Gi"
      max_pods    = each.key == "staging" ? "100" : "50"
    })
  ]

  depends_on = [kubernetes_namespace.vcluster_namespaces]
}

output "vcluster_names" {
  value = [for vc in helm_release.vcluster : vc.name]
}

Mit for_each erzeugen Sie beliebig viele vCluster aus einer einzigen Konfiguration. Das Data-Team bekommt automatisch mehr Ressourcen, Staging erhaelt ein hoeheres Pod-Limit.

Architektur-Entscheidungen

Welches Backing-Distro?

vCluster unterstuetzt drei Kubernetes-Distributionen als Basis:

Fuer die Mehrheit der Anwendungsfaelle reicht k3s. Es ist schlank, schnell und deckt den Standard-API-Umfang ab. Vanilla k8s ist sinnvoll, wenn Teams CRDs oder Admission-Controller testen, die auf spezifische API-Server-Flags angewiesen sind.

Syncer: Was wird synchronisiert?

Standardmaessig synct vCluster folgende Ressourcen vom virtuellen in den physischen Cluster:

• Pods, Services, Endpoints
• ConfigMaps, Secrets (die von Pods referenziert werden)
• PersistentVolumeClaims

Optional aktivierbar sind Ingresses, NetworkPolicies, StorageClasses und PersistentVolumes. Nicht synchronisiert werden CRDs -- die bleiben im vCluster lokal, was genau der gewuenschte Isolationseffekt ist.

Storage und Networking

Pods im vCluster nutzen die Storage-Klassen und CNI-Plugins des Host-Clusters. Das bedeutet: Wenn der Host-Cluster Longhorn oder Rook-Ceph fuer persistenten Storage bereitstellt, steht das auch in jedem vCluster zur Verfuegung. Details zur Storage-Konfiguration finden sich unter Kubernetes Storage: Performante Loesungen fuer Produktionsumgebungen.

Netzwerktechnisch erhalten vCluster-Pods IPs aus dem Pod-CIDR des Host-Clusters. Services werden als ClusterIP im Host-Cluster angelegt. Die Isolation laeuft ueber NetworkPolicies, die der vCluster-Syncer automatisch erstellt, wenn isolation.networkPolicy.enabled: true gesetzt ist.

Monitoring und Betrieb

Monitoring laeuft auf zwei Ebenen:

1. Host-Cluster-Ebene: Prometheus scrapt die vCluster-Control-Plane-Pods wie normale Workloads. CPU- und Memory-Verbrauch der Syncer und API-Server werden ueberwacht.
2. vCluster-Ebene: Jeder vCluster kann seinen eigenen Prometheus-Stack betreiben, oder ein zentraler Prometheus im Host-Cluster scrapt per ServiceMonitor die Workload-Metriken innerhalb der vCluster.

Fuer ein umfassendes Observability-Setup empfiehlt sich der Blick auf OpenTelemetry auf Kubernetes.

Ein einfacher Health-Check per Bash:

#!/bin/bash
# vcluster-health.sh -- Prueft alle vCluster im Host-Cluster
for ns in $(kubectl get ns -l vcluster.loft.sh/managed-by -o jsonpath='{.items[*].metadata.name}'); do
  vc_name=$(echo "$ns" | sed 's/vcluster-//')
  status=$(kubectl get pods -n "$ns" -l app=vcluster -o jsonpath='{.items[0].status.phase}')
  api_ready=$(kubectl get pods -n "$ns" -l app=vcluster -o jsonpath='{.items[0].status.conditions[?(@.type=="Ready")].status}')
  echo "vCluster: $vc_name | Namespace: $ns | Phase: $status | API Ready: $api_ready"
done

Sicherheits-Aspekte

vCluster verbessert die Isolation gegenueber Namespaces erheblich, ist aber kein vollstaendiger Security-Boundary wie eine VM. Wichtige Massnahmen:

• Pod Security Standards auf dem Host-Cluster erzwingen (mindestens baseline, besser restricted).
• ResourceQuotas pro vCluster-Namespace setzen, damit ein Mandant nicht alle Host-Ressourcen beansprucht.
• NetworkPolicies aktivieren, damit vCluster-Pods nicht auf andere Namespaces zugreifen koennen.
• RBAC auf Host-Ebene: vCluster-Nutzer brauchen keinen Zugriff auf den Host-Cluster. Der Syncer-ServiceAccount ist der einzige, der Host-Ressourcen manipuliert.

Wer tiefer in Kubernetes-Security einsteigen will, findet unter Kubernetes Runtime Security weitere Patterns.

Typische Einsatzszenarien

Entwicklungsumgebungen: Jeder Entwickler oder jedes Feature-Team bekommt einen eigenen vCluster. Sie koennen CRDs installieren, Helm Charts testen und sogar den Cluster zerstoeren -- ohne Auswirkungen auf andere. Provisionierung per CI-Pipeline, Lebensdauer an den Feature-Branch gebunden.

Staging und Testing: QA-Teams brauchen oft eine Umgebung, die der Produktion moeglichst nahe kommt, aber unabhaengig davon laeuft. Ein vCluster mit gleicher Kubernetes-Version und gleichen CRDs wie Produktion ist in Sekunden erstellt.

Mandantenfaehige SaaS-Plattformen: Wenn Ihre Software mehrere Kunden auf gemeinsamer Infrastruktur bedient, bieten vCluster eine starke logische Trennung. Jeder Kunde erhaelt einen eigenen API-Endpunkt und eigene RBAC-Regeln.

Schulungen und Workshops: Fuer Kubernetes-Trainings erhaelt jeder Teilnehmer einen eigenen Cluster. Nach dem Workshop wird per vcluster delete aufgeraeumt. Mehr dazu unter Kubernetes Zertifizierung: Vorbereitung und Guide.

Grenzen und Fallstricke

vCluster ist kein Allheilmittel. Einige Einschraenkungen, die man kennen sollte:

• Node-Level-Isolation fehlt: Pods verschiedener vCluster laufen auf denselben physischen Nodes. Wer harte Isolation braucht (z.B. fuer regulierte Workloads), muss zusaetzlich Node-Affinity oder dedizierte Node-Pools einsetzen.
• DaemonSets: DaemonSets im vCluster werden nicht auf allen Host-Nodes ausgerollt. Sie laufen als normale Pods. Das kann bei Logging-Agents oder CNI-Plugins Probleme verursachen.
• Host-Cluster-Upgrades: Wenn der Host-Cluster aktualisiert wird, muessen die Syncer kompatibel bleiben. Major-Version-Spruenge erfordern Tests.
• Debugging: Bei Problemen muss man sowohl im vCluster als auch im Host-Cluster debuggen. kubectl logs im vCluster zeigt die virtuelle Sicht, aber der Pod laeuft physisch in einem anderen Namespace.

Fazit

vCluster schliesst die Luecke zwischen zu schwacher Namespace-Isolation und zu teuren dedizierten Clustern. Die Technik ist ausgereift, die Community aktiv, und die Integration in bestehende Toolchains (Helm, Terraform, ArgoCD) funktioniert reibungslos.

Der beste Einstieg ist ein konkreter Use Case: ein Entwicklungsteam, das heute auf Namespace-Ebene arbeitet und regelmaessig an Isolationsgrenzen stoesst. Starten Sie mit einem einzelnen vCluster, messen Sie den Unterschied in Provisionierungszeit und Flexibilitaet, und skalieren Sie dann.

Wenn Sie Unterstuetzung bei der Planung oder Umsetzung einer vCluster-basierten Multi-Tenancy-Architektur benoetigen, melden Sie sich unter /kontakt -- wir helfen bei Architektur-Review, Implementierung und Betrieb.