Capsule und vCluster bieten Kubernetes Multi-Tenancy: Wir vergleichen Namespace-Isolation mit virtuellen K8s-Clustern für Platform-Engineering-Teams 2026.

Capsule vs. vCluster: Kubernetes Multi-Tenancy im Vergleich 2026

Viele Teams, ein Cluster – das ist der Traum des effizienten Infrastruktur-Betriebs. In der Praxis stellt sich schnell die Frage: Wie isoliert man Teams voneinander, wenn sie denselben Kubernetes-Cluster teilen? Zu enge Isolation erzeugt Overhead, zu lockere Isolation verursacht Sicherheitsrisiken.

Capsule und vCluster sind zwei unterschiedliche Antworten auf das Kubernetes Multi-Tenancy-Problem. Capsule arbeitet mit dem bestehenden Cluster und fügt Namespace-basierte Mandantenfähigkeit hinzu. vCluster geht weiter: Es erstellt vollständige virtuelle Kubernetes-Cluster als Pods innerhalb des Host-Clusters.

Das Multi-Tenancy-Problem in Kubernetes

Kubernetes wurde nicht für Multi-Tenancy entworfen. Namespaces bieten eine logische Trennung, aber:

RBAC muss manuell pro Namespace konfiguriert werden
ResourceQuotas und LimitRanges müssen für jeden Namespace gesetzt werden
Cluster-weite Ressourcen (ClusterRoles, CRDs, Nodes) sind nicht per Namespace isolierbar
Teams können versehentlich auf Ressourcen anderer Teams zugreifen

Für einfache Szenarien reichen Namespace + RBAC + ResourceQuota. Für komplexere Anforderungen – unterschiedliche Kubernetes-Versionen, eigene CRDs, vollständige API-Server-Isolation – braucht man mehr.

Was ist Capsule?

Capsule ist ein Open-Source-Operator von Clastix (jetzt Teil von Capsule als CNCF-Projekt), der das Konzept des Tenant in Kubernetes einführt. Ein Tenant umfasst mehrere Namespaces, und der Tenant-Owner kann neue Namespaces selbst anlegen – ohne Cluster-Admin-Rechte.

Capsule setzt über einen Admission-Webhook durch, dass Tenants nur ihre eigenen Ressourcen sehen und verwalten können.

Capsule: Tenant-Konfiguration

# Tenant für Team Alpha
apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: team-alpha
spec:
  owners:
    - name: alice
      kind: User
  namespaceOptions:
    quota: 5          # Max. 5 Namespaces
    additionalMetadata:
      labels:
        team: alpha
  resourceQuotas:
    scope: Tenant
    items:
      - hard:
          requests.cpu: "10"
          requests.memory: 20Gi
          pods: "50"
  limitRanges:
    items:
      - limits:
          - type: Container
            default:
              cpu: "500m"
              memory: 512Mi
  ingressOptions:
    allowedClasses:
      allowed:
        - nginx
      default: nginx
    allowedHostnames:
      allowed:
        - "*.alpha.example.com"

# Als alice: Namespace anlegen (ohne Cluster-Admin!)
kubectl create ns team-alpha-production
kubectl create ns team-alpha-staging
# Capsule setzt automatisch Labels und Quotas

Capsule-Features

Self-Service Namespaces: Teams erstellen Namespaces selbst
Tenant-weite Quotas: Ressourcenbudgets über alle Namespaces eines Tenants
Network Policies: Automatische Isolation zwischen Tenants
Allowed Registries: Container-Images aus freigegebenen Registries
Ingress-Isolation: Teams dürfen nur bestimmte Domains/Ingress-Klassen nutzen
Node-Selector: Workloads bestimmter Tenants nur auf bestimmten Nodes
CRD-Mehrfachnutzung: Alle Tenants teilen sich dieselben CRDs
Capsule Proxy: kubectl-kompatibles Proxy, das Cluster-Sicht auf Tenant filtert

Was ist vCluster?

vCluster von Loft Labs erstellt vollständige virtuelle Kubernetes-Cluster innerhalb des Host-Clusters. Jeder vCluster hat seinen eigenen API-Server, etcd (oder SQLite), Controller Manager und Core-DNS – läuft aber als reguläre Pods.

Der Clou: Workloads aus dem vCluster laufen tatsächlich auf den Nodes des Host-Clusters, aber der vCluster-Tenant sieht einen vollständigen, isolierten Kubernetes-API-Server.

vCluster erstellen

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

# Virtuellen Cluster erstellen
vcluster create team-alpha --namespace vcluster-team-alpha

# In den vCluster wechseln
vcluster connect team-alpha --namespace vcluster-team-alpha -- bash

# Jetzt haben wir einen vollständigen K8s-Cluster!
kubectl get nodes         # Node des Host-Clusters (als virtueller Node angezeigt)
kubectl get namespaces    # Nur vCluster-Namespaces
kubectl apply -f my-crd.yaml  # Eigene CRDs installierbar!

vCluster-Konfiguration

# vcluster.yaml
controlPlane:
  distro:
    k3s:
      enabled: true
      version: v1.30.0
  persistence:
    volumeClaim:
      enabled: true
      size: 5Gi

sync:
  toHost:
    ingresses:
      enabled: true
  fromHost:
    nodes:
      enabled: true
      selector:
        all: true

networking:
  replicateServices:
    toHost:
      - from: ":*"
        to: "vcluster-team-alpha:*"

vCluster-Features

Vollständiger API-Server: Teams bekommen ihren eigenen Kubernetes-API-Server
Eigene CRDs: Jeder vCluster kann andere CRDs haben – keine Konflikte
Kubernetes-Versionswahl: Verschiedene K8s-Versionen pro vCluster möglich
Vollständige API-Isolation: Teams sehen nur ihren eigenen Cluster-Zustand
Multi-Tenancy ohne Capsule: Keine Admission-Webhooks auf Host-Ebene nötig
Gitpod/DevPod-Integration: vCluster als Entwicklungsumgebung

Capsule vs. vCluster: Direkter Vergleich

Kriterium	Capsule	vCluster
Isolation	Namespace-Level	Vollständige API-Server-Isolation
Overhead	Minimal (Operator + Webhook)	Mittel (API-Server, etcd, CoreDNS pro Cluster)
CRDs	Geteilt (Cluster-weit)	Unabhängig pro vCluster
Kubernetes-Version	Einheitlich	Pro vCluster wählbar
Self-Service	Namespaces	Vollständige Cluster
Kosten	Open Source	Open Source (Enterprise = kostenpflichtig)
RBAC	Tenant-RBAC via Capsule	Vollständiges K8s-RBAC pro vCluster
Networking	Shared CNI	Eigenes virtuelles Netzwerk (über Host-CNI)
Storage	Host-Storage-Classes	Host-Storage-Classes (transparent)
Reife	Produktionsreif (CNCF)	Produktionsreif (Loft Labs)
Lernkurve	Mittel (Tenant-Konzepte)	Niedrig (normaler K8s-Cluster)

Ressourcenverbrauch: Ein kritischer Unterschied

Capsule verbraucht minimal Ressourcen: ein Operator-Pod (~50 MB RAM) und ein Admission-Webhook. Alles andere teilt sich Cluster-Ressourcen.

vCluster benötigt pro virtualem Cluster einen Stack aus API-Server, Controller Manager und Storage:

# Typischer vCluster-Overhead (k3s-basiert)
k3s API-Server:   ~100-200 MB RAM
CoreDNS:          ~30 MB RAM
vCluster-Syncer:  ~50 MB RAM
Gesamt:           ~180-280 MB RAM pro vCluster

Für 10 Teams bedeutet das ~1,8-2,8 GB RAM zusätzlich nur für die vCluster-Kontrollebene. In einem größeren Cluster ist das akzeptabel; im Homelab oder auf kleinen Clustern kann es kritisch werden.

Wann Capsule die bessere Wahl ist

Capsule eignet sich, wenn:

Teams dieselben CRDs und Kubernetes-Features nutzen sollen
Ressourcen-Effizienz wichtig ist (minimaler Overhead)
Teams Namespace-Self-Service wollen, aber kein vollständiges Cluster-Admin-Recht
Bestehende Cluster-Governance (z.B. RBAC, Netzwerkrichtlinien) beibehalten werden soll
Der Fokus auf Showback/Chargeback liegt (Capsule-Quotas pro Tenant)
Teams mit denselben Kubernetes-Versionen arbeiten

Wann vCluster die bessere Wahl ist

vCluster lohnt sich, wenn:

Teams eigene CRDs installieren müssen (z.B. verschiedene Operator-Versionen)
Verschiedene Kubernetes-Versionen getestet oder genutzt werden sollen
vollständige Isolation vom Host-Cluster gewünscht ist (kein API-Server-Sharing)
Entwicklungs- und Testumgebungen schnell provisioniert werden sollen
Teams aus unterschiedlichen Projekten kommen und keinen Zugriff auf Host-Ressourcen haben sollen
Enterprise-Features wie SSO, Audit-Logs und Loft Platform genutzt werden sollen

Kombination beider Tools

Capsule und vCluster schließen sich nicht aus – viele Teams nutzen sie zusammen:

# Capsule-Tenant für das vCluster-Namespace
apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: vcluster-tenants
spec:
  owners:
    - name: platform-team
      kind: Group
  namespaceOptions:
    quota: 20
  resourceQuotas:
    items:
      - hard:
          requests.cpu: "100"
          requests.memory: 200Gi

Capsule verwaltet, welche Teams vCluster-Namespaces anlegen dürfen. Innerhalb dieser Namespaces laufen die vCluster. So kombiniert man die Tenant-Governance von Capsule mit der vollständigen Isolation von vCluster.

Fazit: Namespace-Isolation oder virtueller Cluster?

Capsule ist die effiziente Wahl für Organisationen, die mehrere Teams auf einem Cluster verwalten, ohne vollständige Isolation zu benötigen. Die schlanke Architektur, CNCF-Backing und starke Tenant-Governance machen es zur ersten Wahl für interne Plattformen mit homogenen Anforderungen.

vCluster ist die richtige Wahl, wenn Teams echte Cluster-Isolation brauchen: eigene CRDs, verschiedene Kubernetes-Versionen und vollständige API-Server-Trennung. Besonders für Entwicklungsumgebungen und CI/CD-Testcluster ist vCluster unschlagbar schnell.

Für die meisten Platform-Engineering-Teams empfiehlt sich ein Blick auf beide Tools: Capsule für Produktions-Tenancy, vCluster für Entwicklung und Test.

Capsule vs. vCluster: Kubernetes Multi-Tenancy im Vergleich 2026

Capsule vs. vCluster: Kubernetes Multi-Tenancy im Vergleich 2026

Das Multi-Tenancy-Problem in Kubernetes

Was ist Capsule?

Capsule: Tenant-Konfiguration

Capsule-Features

Was ist vCluster?

vCluster erstellen

vCluster-Konfiguration

vCluster-Features

Capsule vs. vCluster: Direkter Vergleich

Ressourcenverbrauch: Ein kritischer Unterschied

Wann Capsule die bessere Wahl ist

Wann vCluster die bessere Wahl ist

Kombination beider Tools

Fazit: Namespace-Isolation oder virtueller Cluster?

Weiterführende Artikel

Verwandte Technologien im Techradar