Tenancy-Modelle: Shared, Dedicated, Hybrid

Lernziele

Nach dieser Lektion kannst du die drei Tenancy-Grundmodelle — Shared, Dedicated und Hybrid — mit ihren Kosten-, Isolations- und Betriebskonsequenzen erklären. Du kennst die Entscheidungskriterien (Blast Radius, Compliance, Noisy Neighbors, Betriebsaufwand pro Cluster) und kannst für ein konkretes Organisationsszenario ein Tenancy-Modell vorschlagen und verteidigen.

Das Problem: 50 Teams, eine Infrastruktur — wer wohnt wo?

Deine Plattform soll 50 Teams tragen. Die erste Architekturfrage ist banal formuliert und folgenschwer: Teilen sich alle dieselben Cluster, oder bekommt jedes Team eigene? Die Antwort bestimmt Kostenstruktur, Sicherheitsgrenzen, Upgrade-Strategie und die Größe deines Platform-Teams für Jahre — und sie ist später nur mit erheblichem Migrationsaufwand korrigierbar.

Ein Tenant ist dabei die Einheit, der du Ressourcen, Rechte und Verantwortung zuordnest — meist ein Team, manchmal ein Produkt oder eine Geschäftseinheit. Wichtig: Die Tenant-Definition ist eine organisatorische Entscheidung, keine technische. Wer Tenant = Team setzt, obwohl Budget und Compliance entlang von Produkten laufen, baut sich Reporting- und Governance-Schmerzen ein, die keine Technik mehr heilt.

Shared: alle in denselben Clustern

Im Shared-Modell teilen sich alle Tenants wenige große Cluster; die Trennung passiert innerhalb des Clusters über Namespaces, RBAC, Quotas und Network Policies (die technischen Mittel im Detail in Lektion 20).

Die Stärken sind ökonomisch und operativ: Bin-Packing — viele Workloads auf gemeinsamen Nodes nutzen die bezahlte Kapazität deutlich besser aus als viele halb leere Einzelcluster. Das Platform-Team betreibt eine Handvoll Cluster statt fünfzig: ein Upgrade-Zyklus, ein Monitoring-Stack, ein Satz Addons. Neue Tenants sind in Minuten onboarded (Namespace plus Quota plus RBAC statt Cluster-Provisionierung).

Die Schwächen sind die Kehrseite derselben Medaille:

• Blast Radius: Ein Cluster-weiter Ausfall — kaputtes Upgrade, überlasteter API-Server, fehlerhafter Admission Webhook — trifft alle Tenants gleichzeitig.
• Noisy Neighbors: Ein Team, das den API-Server mit Requests flutet oder Nodes mit Workloads ohne Limits sättigt, degradiert die Erfahrung aller anderen. Quotas dämpfen das, eliminieren es aber nicht — manche Ressourcen (API-Server, DNS, Ingress) bleiben geteilt.
• Harte Isolationsgrenzen fehlen: Namespaces sind eine Verwaltungs-, keine Sicherheitsgrenze. Cluster-weite Ressourcen (CRDs, Operatoren, Node-Zugriff) lassen sich nicht pro Namespace besitzen — Teams, die eigene Operatoren brauchen, passen schlecht ins Shared-Modell.

Dedicated: jeder Tenant sein eigener Cluster

Im Dedicated-Modell bekommt jeder Tenant (oder jede kleine Tenant-Gruppe) eigene Cluster. Isolation ist maximal: eigener API-Server, eigene Nodes, eigenes Versagen. Compliance-Anforderungen wie strikte Datentrennung oder regulatorische Mandanten-Trennung sind trivial nachweisbar — „eigener Cluster” überzeugt jeden Auditor schneller als ein Geflecht aus Policies. Teams mit Sonderanforderungen (eigene Kubernetes-Version, exotische Addons, GPU-Nodes) blockieren niemanden.

Der Preis ist erheblich und wächst linear mit der Tenant-Zahl: 50 Cluster heißt 50-mal Upgrades, 50-mal Addon-Rollouts, 50-mal Zertifikats- und Secret-Rotation. Ohne radikale Automatisierung — Fleet-Management per GitOps (Lektion 25) und Cluster-Lifecycle als Code (Lektion 26) — kollabiert das Modell unter seinem Betriebsaufwand. Dazu kommt die Ressourcenverschwendung: Jeder Cluster trägt fixe Grundlast (Control Plane, Monitoring-Agents, Ingress, Mesh), und kleine Tenants lasten ihre Nodes selten aus. Als Faustgröße: Der System-Overhead, der bei drei großen Clustern verschwindend ist, kann bei fünfzig kleinen ein zweistelliger Prozentsatz der Gesamtkapazität sein.

Hybrid: das Modell, das reale Plattformen wählen

In der Praxis landen die meisten Organisationen bei einem Hybrid-Modell, weil Tenants nicht gleich sind. Ein bewährtes Muster ist die Tier-Einteilung:

• Tier Standard (shared): Der Default für die Mehrheit. Namespace-as-a-Service in großen Shared-Clustern, voller Golden Path, niedrigste Kosten. Hierauf optimierst du die Plattform.
• Tier Isolated (dedicated): Für Tenants mit hartem Bedarf — regulierte Workloads (z. B. Zahlungsdaten), extreme Lastprofile, Sonder-Infrastruktur. Eigene Cluster, aber aus derselben Fleet-Automatisierung wie alle anderen, damit kein Schatten-Betriebsmodell entsteht.
• Umgebungs-Split als Querschnitt: Unabhängig vom Tier trennen fast alle Plattformen Produktions- von Nicht-Produktions-Clustern — schon damit ein Experiment in Dev niemals den Prod-API-Server beeinträchtigt.

Entscheidend ist, das Hybrid-Modell als Policy mit Kriterien zu führen, nicht als Verhandlungssache: Wer bekommt einen dedizierten Cluster? Eine schriftliche Liste (Compliance-Anforderung X, nachgewiesenes Lastprofil Y, Sonder-Infrastruktur Z) plus ein Preisschild — dedizierte Cluster erscheinen im Showback des Teams (Lektion 21) — verhindert, dass „dedicated” zum Statussymbol wird, das jeder will und niemand bezahlt.

Eine Zwischenebene, die das Spektrum erweitert, sind virtuelle Cluster (vCluster): eigene API-Server pro Tenant auf geteilter Node-Infrastruktur — mehr Isolation als Namespaces, weniger Kosten als echte Cluster. Die Einordnung folgt in Lektion 20.

Die Entscheidungsmatrix fürs Interview

Wenn du im Interview ein Tenancy-Modell empfehlen sollst, frage zuerst nach vier Dingen:

1. Compliance-Grenzen: Gibt es regulatorische Trennungspflichten? Sie entscheiden einzelne Tenants sofort Richtung dedicated.
2. Tenant-Profil: Viele kleine, ähnliche Teams → shared lohnt maximal. Wenige große, heterogene → dedicated tut weniger weh.
3. Plattform-Reife: Fleet-Automatisierung vorhanden? Ohne sie ist jedes Dedicated-Versprechen ein zukünftiges Betriebsproblem.
4. Kostendruck vs. Verfügbarkeitsanforderung: Wie teuer ist ein Vier-Stunden-Ausfall aller Teams gleichzeitig? Die Antwort kalibriert, wie viel Blast-Radius-Reduktion die Organisation bezahlen sollte.

Die Empfehlung für den Normalfall „50 Teams, übliche Mischung”: Shared als Default mit zwei bis drei Clustern pro Umgebung (damit selbst der Shared-Pool nicht ein einzelner Blast Radius ist), Dedicated als kriterienbasierte Ausnahme, alles aus einer Fleet-Pipeline.

Praxis: ein Tenancy-Konzept schreiben

Nimm folgendes Szenario und entwirf das Tenancy-Modell als Ein-Seiten-Dokument: Versicherungskonzern, 40 Entwicklungsteams. Drei Teams verarbeiten Gesundheitsdaten (strenge Trennungsauflagen), ein Team betreibt ein ML-Training mit GPU-Bedarf und stark schwankender Last, die übrigen 36 bauen Standard-Webservices und Batch-Jobs.

Dein Dokument muss beantworten:

1. Tenant-Definition: Was ist ein Tenant, und warum (Budget-, Ownership-, Compliance-Schnitt)?
2. Zuordnung: Welche Teams landen in welchem Tier — mit Begründung pro Ausnahme.
3. Cluster-Topologie: Wie viele Cluster pro Tier und Umgebung? Skizziere die Zählung (z. B. Shared: je 2 für Prod und Non-Prod; Isolated: je Tenant Prod + Non-Prod).
4. Aufnahme-Kriterien: Die schriftliche Liste, wann ein Team Tier Isolated beanspruchen kann — und was es kostet.
5. Migrationspfad: Was passiert, wenn ein Standard-Team später Compliance-Anforderungen bekommt?

Formuliere das als ADR (Lektion 12): Kontext, Optionen, Entscheidung, Konsequenzen. Genau dieses Artefakt ist auch eine starke Antwort-Struktur im System-Design-Interview.

Typische Stolperfallen

Tenancy-Entscheidung implizit treffen: Wer „erstmal einen Cluster” startet und Teams hineinwachsen lässt, hat irgendwann ein Shared-Modell ohne Quotas, ohne Network Policies und ohne Exit-Pfad — und die Migration zu echter Tenancy läuft dann unter Produktionslast.

Dedicated als Konfliktvermeidung: Jedem unzufriedenen Team einen eigenen Cluster zu geben fühlt sich nach Service an, ist aber ein Betriebsschulden-Generator. Ohne Kriterienkatalog und Kostentransparenz wächst die Fleet schneller als die Automatisierung.

Shared-Modell ohne Lastschutz: Namespaces ohne ResourceQuotas, LimitRanges und API-Priority-Überlegungen sind eine Einladung an den ersten Noisy Neighbor. Das Shared-Modell ist nur so gut wie seine Durchsetzungsmechanismen — die kommen in Lektion 20 und 21.

Tenant ≠ Organisationsrealität: Wenn Kostenstellen entlang Produkten laufen, die Plattform aber Teams als Tenants führt, wird jede Chargeback-Diskussion zur Übersetzungsübung. Tenant-Schnitt zuerst mit Finance und Org-Struktur abgleichen.

Interview-Vorbereitung

Die Standardfrage „Shared oder Dedicated Cluster?” beantwortest du nie binär, sondern als Kriterien-Entscheidung: Trade-off benennen (Isolation und Blast Radius gegen Kosten und Betriebsaufwand pro Cluster) → Kriterien (Compliance, Tenant-Heterogenität, Fleet-Automatisierungsgrad, Ausfallkosten) → Empfehlung (Hybrid: Shared als Default, Dedicated als kriterienbasierte, bepreiste Ausnahme) → Absicherung (auch den Shared-Pool auf mehrere Cluster verteilen, alles aus einer Automatisierung).

Wahrscheinliche Follow-ups:

• „Warum nicht einfach jedem Team einen Cluster — Cloud macht das doch leicht?” — Provisionieren ja, Betreiben nein: Upgrades, Addons, Security-Patches und Monitoring skalieren linear mit; dazu Grundlast-Overhead und schlechtes Bin-Packing.
• „Was ist die größte Schwäche des Shared-Modells?” — geteilte Cluster-weite Ressourcen: API-Server-Kapazität, CRD-/Operator-Konflikte und der gemeinsame Blast Radius bei Upgrades.
• „Wie verhinderst du, dass jedes Team einen dedizierten Cluster fordert?” — schriftliche Aufnahme-Kriterien plus Kostenzuordnung; dedicated ist eine bezahlte Ausnahme, kein Statussymbol.
• „Wie migrierst du ein Team von shared nach dedicated?” — GitOps macht’s handhabbar: gleiche Manifeste auf neues Ziel synchronisieren, Daten separat migrieren, Traffic umschwenken; der Aufwand liegt in Stateful-Diensten und Netzwerk-Abhängigkeiten, nicht in den Deployments.

Zusammenfassung

Tenancy-Modelle balancieren Isolation gegen Ökonomie: Shared maximiert Auslastung und minimiert Betriebsaufwand, teilt aber Blast Radius und Cluster-weite Ressourcen; Dedicated kauft harte Grenzen mit linear wachsendem Betriebsaufwand; real gewinnen Hybrid-Modelle mit Shared als Default und Dedicated als kriterienbasierter, kostentransparenter Ausnahme — getragen von einer gemeinsamen Fleet-Automatisierung. Die Tenant-Definition selbst ist eine organisatorische Entscheidung und gehört vor jede technische.

Damit ist geklärt, wer wo wohnt. Die nächste Lektion liefert die technische Tiefe dazu: was Namespaces, dedizierte Cluster und vCluster an Isolation tatsächlich leisten — und wo die Grenzen jeder Ebene liegen.