Viele Cluster oder viele Namespaces? Die Kubernetes-Architekturfrage, die niemand endgültig beantworten kann
Viele Cluster oder Namespace-basierte Isolation? Eine praxisnahe Analyse der Kubernetes-Architekturentscheidung mit Kostenvergleich und Empfehlungen für DACH-Unternehmen.
Viele Cluster oder viele Namespaces? Die Kubernetes-Architekturfrage, die niemand endgültig beantworten kann
Die eine Architekturentscheidung in Kubernetes, über die sich Platform-Teams am meisten den Kopf zerbrechen: Fahre ich lieber viele kleine Cluster mit wenigen Namespaces — oder wenige große Cluster, in denen sich dutzende Teams per Namespace tummeln? Spoiler: Die Antwort ist weder noch. Bzw. beides. Aber der Reihe nach.
Alle drei großen Cloud-Provider und die CNCF empfehlen als Default: weniger Cluster, dafür Namespace-basierte Isolation für vertrauenswürdige Tenants. Separate Cluster nur dort, wo Compliance-Grenzen oder die Trennung von Prod und Non-Prod es wirklich verlangen. Und dann gibt es seit 2024/2025 noch den dritten Weg — virtuelle Cluster via vCluster —, der die Lücke zwischen den beiden Extremen rapide schließt. Über 40 Millionen virtuelle Cluster laufen bereits produktiv bei Unternehmen wie Adobe, NVIDIA und CoreWeave.
Für DACH-Unternehmen, die sich mit DSGVO, BaFin-Anforderungen und ISO 27001 rumschlagen, sieht das praktische Pattern 2025 so aus: Cluster pro Umgebung (Dev/Staging/Prod), Namespaces pro Team innerhalb jedes Clusters, und virtuelle Cluster für Developer-Self-Service.
Die Cluster-Grenze ist die einzige echte Sicherheitsgrenze
Kubernetes ist im Kern ein Single-Tenant-Orchestrator. Das sagt nicht nur die Community — AWS formuliert es in seinem EKS Best Practices Guide ziemlich direkt: Der Cluster ist das einzige Konstrukt, das eine starke Sicherheitsgrenze bietet. Ein Namespace ist im Vergleich dazu eher ein logisches Ordnungsprinzip: Namensräume, ein Anknüpfungspunkt für RBAC, Network Policies und Resource Quotas — aber keine Sicherheitsbarriere. Rapid7 vergleicht Namespaces treffend mit Absperrband am Tatort: Du weißt, dass es da ist, aber drüber steigen ist trivial.
Die Angriffsfläche eines geteilten Clusters ist beträchtlich. Per Default können alle Pods mit allen anderen Pods kommunizieren — egal in welchem Namespace. Jeder Pod kann CoreDNS nach sämtlichen Services im Cluster fragen. Pods aus verschiedenen Namespaces teilen sich Nodes, und ein Container-Escape gibt dir Zugriff auf alles, was auf dem Node läuft. Aktuelle CVEs unterstreichen das Risiko: Die Leaky-Vessels-Schwachstellen (Januar 2024, CVE-2024-21626) ermöglichten vollständige Container-Escapes über geleakte File-Deskriptoren in runC. Die NVIDIAScape-Lücke (CVE-2025-23266, CVSS 9.0) betraf 37% der Cloud-Umgebungen mit GPU-Workloads — ein Drei-Zeilen-Exploit mit LD_PRELOAD.
Für Hard Multi-Tenancy — also wenn du nicht vertrauenswürdige oder potenziell feindliche Tenants hostest — bleibt Cluster-Level-Isolation der einzige vertretbare Ansatz. Microsofts AKS-Doku ist da ziemlich unverblümt: Für echte Sicherheit bei feindlichen Multi-Tenant-Workloads solltest du nur einem Hypervisor vertrauen.
Aber für Soft Multi-Tenancy unter vertrauenswürdigen internen Teams? Da reicht Namespace-Isolation kombiniert mit Defense-in-Depth (RBAC, Network Policies, Pod Security Admission im “restricted”-Profil, Resource Quotas und sandboxed Runtimes wie gVisor) — bei dramatisch niedrigeren Kosten.
Die Kostenrechnung spricht eine deutliche Sprache
Hier wird’s richtig interessant. Jeder Managed-Kubernetes-Cluster hat eine Control-Plane-Gebühr: EKS kostet $0,10/Stunde (~73$/Monat), AKS Standard genauso, GKE ebenfalls — wobei GKE eine Free-Credit von $74,40/Monat für einen zonalen Cluster mitbringt. AKS hat als einziger Anbieter einen wirklich kostenlosen Tier für Entwicklung (kein SLA, max. 10 Nodes empfohlen).
Diese Gebühren skalieren linear. Bei 50 Clustern liegen allein die Control-Plane-Kosten bei rund $43.000/Jahr auf EKS oder AKS Standard. Mengenrabatte? Gibt’s nicht. Und das sind nur die Cluster-Fees — jeder Cluster braucht eigene System-Komponenten: CoreDNS, kube-proxy DaemonSets, CNI-Pods, Monitoring-Agents, Ingress Controller, cert-manager. Das frisst ca. 0,4 vCPU und 0,8 GiB RAM pro Node, bevor auch nur ein Application-Pod läuft.
Ein realistischer Gesamtvergleich zeigt einen ungefähr 10-fachen Overhead-Unterschied: 50 Cluster mit duplizierten System-Pods, Monitoring und operativer Komplexität kosten circa $250.000/Jahr an Overhead — versus $25.000/Jahr für 5 Cluster mit dem gleichen Gesamt-Workload.
Bin-Packing-Effizienz verstärkt den Effekt. Weniger, größere Cluster geben dem Scheduler einen größeren Pool heterogener Workloads zum dichten Packen. Cast AIs Kubernetes-Report 2025 zeigt: 99,94% aller Cluster sind over-provisioned, mit durchschnittlich nur 10% CPU- und 23% Memory-Auslastung. LiveRamp berichtet von 60–70% Infrastrukturkostenreduktion nach der Migration von dedizierten Per-Team-Clustern zu geteilten Multi-Tenant-GKE-Clustern mit Capsule.
Und dann kommen noch die Tool-Lizenzen obendrauf. Datadog berechnet $15–$23/Host/Monat für Infrastructure Monitoring — jede zusätzliche System-Node eines weiteren Clusters erhöht den Host-Count. Red Hat OpenShift wird pro Core-Pair lizenziert (~€2.000–€5.000/Jahr pro 4 vCPUs). Tools, die per Cluster abrechnen, multiplizieren die Kosten direkt mit der Cluster-Anzahl.
Skalierungslimits: Echt, aber selten das Bottleneck
Die offiziellen Kubernetes SIG-Scalability-Schwellenwerte definieren den Rahmen: 5.000 Nodes, 10.000 Namespaces, 150.000 Pods und 300.000 Container pro Cluster. Das sind keine harten Limits, sondern SLO-Grenzen — darüber hinaus überschreiten API-Call-Latenzen 1 Sekunde beim 99. Perzentil und Pod-Startzeiten können über 5 Sekunden klettern.
etcd ist typischerweise der erste Flaschenhals. Die Community empfiehlt eine maximale Datenbankgröße von 8 GiB (Default-Quota: 2 GiB). Wenn etcd vollläuft, schaltet es auf Read-Only und friert die gesamte Control Plane ein. Regelmäßiges Compaction und Defragmentierung sind Pflicht. Google löst das bei GKE elegant, indem sie etcd teilweise durch Spanner ersetzen — damit sind Cluster jenseits der 15.000 Nodes möglich.
In der Praxis ist die Churn-Rate wichtiger als die reine Objekt-Anzahl. Ein 5.000-Node-Cluster mit stabilen Pods belastet die Control Plane weniger als ein 1.000-Node-Cluster, der 10.000 kurzlebige Jobs pro Minute erstellt. OpenAI hat Kubernetes auf 7.500 Nodes skaliert — unter anderem für das Training von GPT-3, CLIP und DALL·E. Der Trick: etcd und API-Server auf dedizierten Nodes außerhalb des Clusters, plus Monitoring der HTTP 429/5xx-Raten als zentrale Health-Signale.
Für die meisten DACH-Unternehmen liegt das praktische Namespace-Limit weit unter den theoretischen 10.000. Performance, RBAC-Komplexität und operative Handhabbarkeit machen typischerweise ein paar hundert Namespaces zur Obergrenze, bevor man über weitere Cluster oder virtuelle Cluster nachdenkt.
Operative Komplexität: Der versteckte Kostenmultiplikator
5 Cluster managen? Kein Problem für ein kleines Platform-Team von 2–3 Engineers. 50 Cluster? Configuration Drift wird zum ernsthaften Risiko und dediziertes Fleet-Management-Tooling wird Pflicht. 100+ Cluster? Das schaffen nur Organisationen mit durchgängiger GitOps-Automatisierung — Deutsche Telekom managed ungefähr 200 Kubernetes-Cluster mit nur 10 Vollzeit-Engineers via Flux CD und plant die Skalierung auf tausende mit lediglich 1–2 zusätzlichen Engineers.
Die Tooling-Landschaft für Multi-Cluster-Management ist mittlerweile ziemlich ausgereift:
Rancher Prime 3.0 (GA April 2024, SUSE) liefert zentralisierte Authentifizierung, RBAC, Audit-Logging und Fleet-Management über beliebige CNCF-zertifizierte Distributionen. Auf der KubeCon NA 2025 kamen native vCluster-Integration und ein KI-gestützter Operations-Assistent dazu. Rancher ist Leader in Gartners Magic Quadrant für Container Management.
ArgoCD (CNCF Graduated) dominiert GitOps-basiertes Multi-Cluster-Deployment. Das Hub-and-Spoke-Modell — eine zentrale ArgoCD-Instanz, die mehrere Cluster verwaltet — ist die beliebteste Architektur. ApplicationSets mit Cluster-Generatoren deployen automatisch auf alle registrierten Cluster. Expedia managed über 30.000 Applikationen per ArgoCD über Cluster hinweg.
Crossplane (CNCF Graduated) erweitert Kubernetes zur universellen Infrastructure Control Plane — deklaratives Provisioning von Clustern und Cloud-Ressourcen über Provider hinweg via CRDs.
Cluster API (CAPI) bietet deklaratives Cluster-Lifecycle-Management — der Standard für programmatisches Provisionieren und Upgraden von Fleet-Clustern.
Beim Thema Observability divergieren die beiden Strategien massiv. Ein einzelner Cluster mit vielen Namespaces ist dramatisch einfacher: eine Prometheus-Instanz, ein Logging-Stack, natürliches Service-Discovery. Multi-Cluster-Observability erfordert Thanos oder Grafana Mimir für Metrik-Aggregation, Per-Cluster-Log-Collectors, die an zentrales Loki oder Elasticsearch shippen, und sorgfältige Trace-Korrelation über Cluster-Grenzen hinweg. Service-Mesh (Istio Multi-Cluster oder Linkerd) bringt Cross-Cluster-mTLS und Traffic-Management — aber mit erheblicher Konfigurationskomplexität. Policy Engines (OPA Gatekeeper, Kyverno) müssen per GitOps in jedem Cluster deployt werden, während ein einzelner Cluster nur ein Policy-Deployment braucht.
Virtuelle Cluster: Der pragmatische Mittelweg
Der spannendste Trend im Kubernetes-Multi-Tenancy-Bereich 2024/2025 ist der Aufstieg von virtuellen Clustern. vCluster von Loft Labs (CNCF Sandbox) erstellt voll funktionsfähige Kubernetes-Cluster — mit eigenem API-Server, Controller Manager und Datastore —, die innerhalb eines Namespaces eines Host-Clusters laufen. Tenants bekommen ihre eigene kubeconfig mit vollem cluster-admin: Sie können CRDs installieren, Helm Charts deployen, Namespaces erstellen und Cluster-scoped Resources verwalten, ohne andere Tenants zu beeinflussen.
vCluster bietet vier progressive Isolationsstufen: Shared Nodes (maximale Dichte, Pods laufen als normale Host-Pods), Dedicated Nodes (gelabelte Node-Pools pro virtuellem Cluster), Private Nodes (volle CNI/CSI-Isolation mit externen Nodes) und Standalone (kein Host-Cluster nötig). Dieses abgestufte Modell erlaubt es, die Isolationsstärke an die tatsächlichen Anforderungen anzupassen, statt zwischen den Extremen “nur Namespace” und “eigener physischer Cluster” zu wählen.
Die Produktionsadoption ist beeindruckend. Atlan konsolidierte von 100 Kubernetes-Clustern auf einen einzigen Host-Cluster mit vCluster. Aussie Broadband erreichte 99% schnelleres Environment-Provisioning und $180.000 jährliche Einsparungen. Expedia testete 300 virtuelle Cluster auf der KubeCon India 2024. Rancher Prime integriert vCluster mittlerweile nativ.
Neben vCluster gibt es Capsule (CNCF Incubating, von Clastix) als leichtgewichtigere Alternative: Ein Tenant-CRD gruppiert Namespaces mit automatischer Policy-Vererbung und einem Proxy, der API-Responses filtert, sodass Tenants nur ihre eigenen Ressourcen sehen. TomTom nutzt Capsule mit ArgoCD für Multi-Tenant-Produktionscluster. Kamaji (ebenfalls von Clastix) bietet hosted Control Planes als Pods — genutzt von OVHCloud und Rackspace für Kubernetes-as-a-Service.
Entscheidungsframework für DACH-Unternehmen
Die Cluster-vs.-Namespace-Entscheidung sollte sich an fünf Faktoren orientieren, grob nach Priorität:
1. Compliance-Anforderungen
PCI-DSS, HIPAA und BaFins BAIT/VAIT-Vorgaben verlangen oft separate Cluster für Produktions-Cardholder-Data-Environments, geschützte Gesundheitsinformationen oder kritische Finanz-Workloads. Nicht weil Kubernetes es technisch erfordert, sondern weil Auditoren klare physische Grenzen erwarten. DSGVO treibt eher regionales Cluster-Deployment (nur EU-Rechenzentren) als Per-Tenant-Cluster-Entscheidungen. Ein Berliner Fintech berichtete von 60% Compliance-Risikoreduktion durch den Einsatz von ausschließlich EU-basiertem Managed Kubernetes.
2. Vertrauenslevel zwischen Tenants
Vertrauenswürdige interne Teams können sich Cluster mit Namespace-Isolation problemlos teilen. Externe Kunden oder nicht vertrauenswürdiger Code brauchen Cluster-Level- oder zumindest Virtual-Cluster-Level-Separation. Azure ist hier am deutlichsten: Minimiere die Anzahl physischer AKS-Cluster für interne Nutzung, nutze physisch isolierte Cluster für feindliches Multi-Tenancy.
3. Team-Autonomie-Bedarf
Teams, die vollen cluster-admin-Zugriff brauchen, eigene CRD-Versionen oder unabhängige Kubernetes-Version-Upgrades wollen, brauchen entweder dedizierte Cluster oder virtuelle Cluster. Namespace-only-Tenants können keine Operators installieren, keine CRDs verwalten und keine clusterweiten Settings kontrollieren.
4. Kostenrahmen
Der 10-fache Overhead-Unterschied zwischen Many-Cluster- und Few-Cluster-Strategien ist substanziell. Organisationen, die Kosteneffizienz priorisieren, sollten aggressiv konsolidieren und virtuelle Cluster oder Capsule für Tenant-Grenzen innerhalb geteilter Infrastruktur nutzen.
5. Operative Kapazität
Mehr Cluster erfordern größere Platform-Teams und ausgereiftere Automatisierung. Organisationen ohne mature GitOps-Pipelines und Fleet-Management-Tooling sollten die Cluster-Anzahl minimieren.
Das empfohlene Pattern für 2025
Für die meisten DACH-Unternehmen hat sich ein hybrides Modell durchgesetzt, das Elemente beider Strategien kombiniert:
Separate physische Cluster für Umgebungsgrenzen (Development, Staging, Production) und regionale Datensouveränität (EU-West, EU-Central). Innerhalb jedes Clusters Namespace-per-Team-Isolation mit RBAC, Default-Deny Network Policies, Pod Security Admission im “restricted”-Profil und Resource Quotas. Virtuelle Cluster für Developer-Self-Service, CI/CD-Ephemeral-Environments und Situationen, in denen Teams cluster-admin-Capabilities brauchen. GitOps (ArgoCD oder Flux) für konsistentes Multi-Cluster-Deployment, mit Policy-as-Code (Kyverno oder OPA Gatekeeper), identisch über die gesamte Fleet enforced.
Die Community behandelt Cluster als Cattle
Der breitere Kubernetes-Community-Trend geht Richtung mehr Cluster, managed als disposable Infrastruktur, ermöglicht durch Platform Engineering und GitOps-Automatisierung. Organisationen betreiben heute durchschnittlich 20+ Cluster, und 80% haben Platform-Engineering-Praktiken adoptiert. Cruise baute einen Kubernetes-Operator, der Cluster per einzelnem API-Call provisioniert und zerstört — Erstellungszeit runter von einer Woche auf Minuten. Confluent betreibt zehntausende Cluster für seinen Managed-Kafka-Service.
Dieser “Clusters as Cattle”-Ansatz widerspricht nicht der Kosteneffizienz weniger Cluster — er reflektiert unterschiedliche Use Cases. SaaS-Provider wie Confluent brauchen Per-Customer-Isolation im großen Stil. Enterprise-interne Platform-Teams wie bei American Airlines fahren weniger, größere geteilte Cluster (American Airlines reduzierte die Kosten pro genutztem Core um 40% trotz 300% Plattformwachstum).
Spotify zeigt den Hybrid-Ansatz exemplarisch: Multi-Cluster für regionale Redundanz (1.600+ Produktionsservices auf GKE über Regionen verteilt), Namespace-per-Service innerhalb jedes Clusters, abstrahiert durch Backstage als internes Developer-Portal. Im DACH-Raum promotet Kubermatic (Hamburg) das Clusters-as-Cattle-Modell aktiv und ZITADEL (Schweiz) plädiert für kleine, domänenspezifische Cluster via GitOps.
Fazit
Die Debatte “viele Cluster vs. viele Namespaces” hat sich von einer Entweder-oder-Frage zu einem Spektrum entwickelt. Drei zentrale Erkenntnisse aus aktueller Produktionserfahrung:
Kosten und operative Einfachheit favorisieren klar die Konsolidierung. Der 10-fache Overhead-Unterschied ist real und potenziert sich mit Lizenzkosten, Monitoring und Engineering-Zeit.
Compliance ist der Haupttreiber für Cluster-Separation — nicht technische Vorliebe. Trenne nur dort, wo Regulatoren oder Sicherheitsanforderungen es verlangen.
Virtuelle Cluster haben die Gleichung fundamental verändert. Sie liefern Cluster-Level-Autonomie für Tenants (CRDs, cluster-admin, unabhängige Versionen) zu Namespace-Level-Kosten und machen das traditionelle Entweder-oder zunehmend obsolet.
Für DACH-Unternehmen, die 2025 Kubernetes-Plattformen bauen, heißt die Winning-Strategie: Pragmatische Hybridisierung. Physische Cluster für harte Grenzen (Umgebung, Region, Compliance). Namespaces für Team-Isolation innerhalb dieser Cluster. Und virtuelle Cluster, um Developern die Autonomie zu geben, die sie brauchen — ohne den Overhead, vor dem das IT-Management (zurecht) Angst hat.