Case Study: Multi-Tenant K8s-Plattform für 100 Teams
End-to-end System Design: Anforderungen, Architektur, Trade-offs.
Lernziele
Nach dieser Lektion kannst du ein vollständiges System-Design für eine Multi-Tenant-Kubernetes-Plattform mit 100 Teams durchspielen: Anforderungen klären, Architektur skizzieren, Trade-offs benennen und Interviewer-Einwände parieren. Du kennst ein realistisches Tenancy-Modell, weißt, wo Control Plane und Data Plane liegen, und kannst einen phasenweisen Rollout begründen. Du verstehst, warum „100 Teams” allein noch kein Design ist.
Das Szenario: Der Interviewer legt los
„Ihr seid ein Platform-Team in einem E-Commerce-Unternehmen. Hundert Stream-Teams wollen auf Kubernetes deployen. Entwickelt die Plattform — Self-Service, sichere Mandantentrennung, ein Platform-Team von zwölf Leuten. Ihr habt 45 Minuten.”
Pause. Nicht sofort zeichnen.
Phase 1: Anforderungsklärung (Minuten 0–12)
Du stellst Fragen — und der Interviewer antwortet (typische Antworten in Klammern):
„Wie viele Services und Deployments?” — ~800 Services, ~3 000 Deployments pro Woche. (CI/CD ist der heiße Pfad.)
„Regulierte Workloads?” — Kein PCI, aber personenbezogene Daten (DSGVO). Kein dedizierter On-Prem-Zwang.
„Cloud und Regionen?” — AWS, eine Region, EU-Frankfurt. Multi-Region erst ab nächstem Jahr.
„Bestehende Infrastruktur?” — Brownfield: Teams haben teils ECS, teils bare VMs. Migration über 18 Monate.
„Hauptschmerz?” — Jedes Team baut eigene CI/CD; Onboarding dauert drei Wochen; Security findet Schwachstellen erst im Audit.
„Was ist explizit out of scope?” — ML-Training-Infrastruktur, Desktop-VDI.
Du fasst zusammen: „100 Teams, ~800 Services, DSGVO aber kein PCI, AWS eu-central-1, Brownfield-Migration, MVP ist Self-Service-Deploy mit Guardrails. ML ist out of scope.”
Phase 2: NFRs und Größenordnungen (Minuten 12–18)
| NFR | Entscheidung | Begründung |
|---|---|---|
| Verfügbarkeit | Plattform-API 99,9 %; Workloads 99,95 % | Control-Plane-Ausfall darf Deployments nicht killen |
| Tenancy | Namespace pro Team, Shared Cluster pro Umgebung | 100 dedizierte Cluster = unbetreibbar mit 12 Leuten |
| Blast Radius | Management-Cluster getrennt | Plattform-Upgrade ≠ Team-Ausfall |
| Compliance | DSGVO: Logs ohne PII, EU-Region, Audit Trail | Kein PCI → kein Cluster-Split nötig |
| Kosten | Showback pro Team ab Monat 6 | FinOps-Druck ab 100 Teams |
Größenordnung: 3 000 Deploys/Woche ≈ 430/Tag ≈ 18/Stunde — GitOps-Controller und Registry müssen das tragen, aber kein Netflix-Maßstab.
Phase 3: High-Level-Architektur (Minuten 18–32)
Du zeichnest zwei Ebenen:
Management-Cluster (Control Plane):
- Developer Portal (Backstage o. ä.) — Service-Katalog, Scaffolder, Docs
- GitOps (Argo CD) — ein Application-Set pro Team-Repo oder Monorepo-Pattern
- Policy-Engine (Kyverno) — Policies zentral, Enforcement in Workload-Clustern
- Provisioning-Controller — Namespace, Quota, RBAC, NetworkPolicy-Template bei Team-Onboarding
- Observability-Stack — zentral, Teams bekommen vorgefertigte Dashboards
Workload-Cluster (Data Plane):
- Prod-Cluster — Shared, Namespace-Isolation
- Non-Prod-Cluster — Dev + Staging, lockerere Policies
- Optional später: PCI-Cluster — hier nicht nötig
Datenfluss: Entwickler → Portal/Scaffolder → Git-Repo → Argo CD → Workload-Cluster. Kein direkter kubectl-Zugriff auf Prod ohne Break-Glass (Lektion 45).
Interviewer-Einwand 1: „Ein Shared Prod-Cluster für 100 Teams — ist das nicht zu riskant?”
Deine Antwort: „Namespace-Isolation allein reicht nicht — deshalb drei Schichten: RBAC (Team sieht nur eigenen NS), ResourceQuota (kein Noisy Neighbor), NetworkPolicy Default-Deny (Lektion 22). Blast Radius eines kompromittierten Teams bleibt im Namespace. Grenze: Bei PCI oder starker Regulierung würde ich dedizierte Cluster pro Zone wählen — hier ohne PCI ist Shared vertretbar.”
Interviewer-Einwand 2: „Warum nicht ein Cluster pro Team?”
Antwort: „100 Cluster × Upgrade-Kadenz × Monitoring × etcd-Backup = Platform-Team ertrinkt. Kosten und Betriebsaufwand skaliieren linear mit Teams. Namespace-Tenancy ist der Industry-Standard bis ~150 Teams ohne harte Regulierung — danach evaluiert man Cluster-Splitting.”
Phase 4: Deep Dive und Rollout (Minuten 32–45)
Deep Dive — Team-Onboarding-Flow:
- Team beantragt Namespace im Portal (Self-Service, genehmigt automatisch wenn Quota frei).
- Scaffolder erzeugt Git-Repo mit Golden-Path-Chart, CI-Pipeline (Scan, Sign, SBOM — Lektion 44), Argo CD Application.
- Provisioning-Controller legt NS + Quota + RBAC + NetworkPolicy-Default an.
- Erster Deploy über Merge in
main— Policy prüft, Argo syncs.
Zeit: Ziel unter 2 Stunden statt 3 Wochen.
Phasen-Rollout:
| Phase | Monate | Inhalt |
|---|---|---|
| 0 — Foundation | 1–3 | Management-Cluster, Non-Prod, 5 Pilot-Teams |
| 1 — Golden Path | 4–8 | Scaffolder, Policy-Enforcement, 30 Teams |
| 2 — Prod + Migration | 9–14 | Prod-Cluster, ECS→K8s-Migration, 70 Teams |
| 3 — Scale | 15–18 | 100 Teams, Showback, härtere Policy-Enforcement |
Risiko 1: Adoption — Teams bleiben bei ECS. Gegenmaßnahme: Golden Path muss schneller sein als Altweg; Executive-Sponsor für Migration-Deadline.
Risiko 2: Noisy Neighbor. Gegenmaßnahme: Quotas, PriorityClasses, optional Node-Pools pro Team-Tier.
Praxis
Spiele den Case allein — mit Timer. Variante: Der Interviewer sagt plötzlich „Doch PCI für Payment-Team”. Welche Entscheidungen kippen? (Dedizierter Cluster, strengere NetworkPolicies, separate Registry-Zone.) Schreibe die geänderte Architektur in fünf Sätzen.
Typische Stolperfallen
100 Teams = 100 Cluster. Betriebsrealität ignorieren.
Migration vergessen. Brownfield ohne Migrationsstrategie ist kein Design.
Portal vor Pipeline. MVP ist Deploy, nicht Katalog-Feinschliff.
DSGVO als „kein Problem”. Logs, Backups, Cross-Border — mindestens ansprechen.
Interview-Vorbereitung
Elevator-Pitch für diesen Case in 30 Sekunden: „Shared Cluster mit Namespace-Tenancy, getrennte Control Plane, Golden Path für Onboarding unter 2 Stunden, GitOps + Policy-as-Code für Compliance, phasenweise Migration von ECS.”
Follow-up: „Wie viele Cluster am Ende?” — Antwort: 3 (Management, Non-Prod, Prod) — nicht 100.
Zusammenfassung
Die Multi-Tenant-Plattform für 100 Teams lebt von Namespace-Isolation mit RBAC, Quotas und NetworkPolicies in Shared Workload-Clustern, einer getrennten Control Plane und einem Golden Path, der Onboarding von Wochen auf Stunden drückt. PCI würde das Modell kippen; DSGVO erfordert EU-Region und saubere Logs. Rollout in vier Phasen mit Pilot-Teams zuerst. Im nächsten Case skaliert die Organisationsschicht: 500+ Entwickler und Enterprise-IDP.