Reference Architecture: Kubernetes-basierte IDP
Schichtenmodell, Komponenten und Integrationspunkte einer produktionsreifen K8s-IDP.
Lernziele
Nach dieser Lektion kannst du die Referenzarchitektur einer Kubernetes-basierten IDP als Schichtenmodell zeichnen und erklären: von der Cloud-Foundation über Cluster, Delivery und Plattform-Services bis zur Developer-Experience-Schicht. Du kannst den Weg eines Deployments durch alle Schichten nachvollziehen und das Konzept der Platform API — Entwickler deklarieren Absicht, Controller setzen um — im Interview an einem Beispiel erläutern.
Wozu eine Referenzarchitektur?
Wenn du im Interview eine IDP skizzieren sollst, brauchst du eine mentale Landkarte, auf der jede Komponente einen festen Platz hat — sonst entsteht das berüchtigte Logo-Diagramm: fünfzehn CNCF-Tools, wild verbunden, ohne erkennbare Ordnung. Eine Referenzarchitektur ist genau diese Landkarte: kein verbindlicher Bauplan, sondern ein Schichtenmodell, in dem du jedes Tool und jede Anforderung verorten kannst. Sie beantwortet die zwei Fragen, an denen Logo-Diagramme scheitern: Was hängt wovon ab? und Was sieht der Entwickler — und was bleibt ihm erspart?
Das Schichtenmodell: fünf Ebenen, eine Richtung
┌────────────────────────────────────────────────────────────┐
│ L4 Developer Experience │
│ Portal · Service Catalog · Scaffolding · CLI · Docs │
├────────────────────────────────────────────────────────────┤
│ L3 Platform Services │
│ Platform-APIs (CRDs) · CI-Strecke · Observability · │
│ Secrets-Service │
├────────────────────────────────────────────────────────────┤
│ L2 Delivery & Governance │
│ GitOps-Controller · Policy Engine · Image Registry │
├────────────────────────────────────────────────────────────┤
│ L1 Cluster Foundation │
│ Kubernetes · Ingress · CNI · CSI · Autoscaling · DNS │
├────────────────────────────────────────────────────────────┤
│ L0 Cloud Foundation / Landing Zone │
│ Accounts · Netzwerk · IAM · Audit-Logging · Baseline │
└────────────────────────────────────────────────────────────┘Die Schichten bauen strikt aufeinander auf, und jede hat einen klaren Auftrag:
L0 — Cloud Foundation: Account-Struktur, Netzwerk-Topologie, Identity und Audit-Logging des Cloud-Providers. Diese Schicht existiert vor jedem Cluster und gehört oft einem eigenen Cloud-Foundation-Team — Lektion 9 widmet sich ihr komplett.
L1 — Cluster Foundation: Kubernetes plus alles, was ein Cluster braucht, um überhaupt Workloads tragen zu können — Netzwerk-Plugin (CNI), Storage-Anbindung (CSI), Ingress, Cluster-Autoscaling, DNS. Für Entwickler unsichtbar, für den Betrieb der größte Aufwandsposten.
L2 — Delivery & Governance: Hier entsteht der kontrollierte Weg in den Cluster. Ein GitOps-Controller (ArgoCD oder Flux) synchronisiert den in Git deklarierten Zustand in die Cluster; eine Policy-Engine (etwa Kyverno oder OPA Gatekeeper) erzwingt Regeln bei der Admission — keine Images aus fremden Registries, Pflicht-Labels, keine privilegierten Container. Diese Schicht ist der Grund, warum niemand mit kubectl apply in Produktion arbeitet.
L3 — Platform Services: Die Capabilities, die die Plattform ihren Kunden anbietet — als Services, nicht als Anleitungen: die CI-Strecke, Observability (Metriken, Logs, Traces mit Mandanten-Trennung), Secrets-Versorgung und vor allem die Platform-APIs, zu denen gleich mehr.
L4 — Developer Experience: Die einzige Schicht, die Entwickler aktiv sehen. Portal mit Service Catalog, Scaffolding-Templates (der Einstieg in den Golden Path aus Lektion 5), CLI und Dokumentation. Wichtig fürs Verständnis: L4 ist eine Fassade — das Portal tut selbst fast nichts, es macht die Schichten darunter zugänglich.
Die Platform API: Absicht deklarieren statt Ressourcen bauen
Das architektonische Herzstück einer reifen K8s-IDP ist die eigene API-Schicht über Kubernetes. Statt dass ein Team Deployment, Service, Ingress, NetworkPolicy und ServiceMonitor einzeln pflegt, deklariert es seine Absicht in einer eigenen, schlanken Ressource — und ein Controller der Plattform expandiert sie in die Dutzend Kubernetes-Objekte, inklusive aller Hausstandards:
apiVersion: platform.example.com/v1alpha1
kind: Environment
metadata:
name: checkout-staging
spec:
team: checkout
tier: staging
capabilities:
- ingress
- observability
- postgres
quotas:
cpu: "8"
memory: 16GiDer Mechanismus dahinter ist das Kubernetes-Operator-Pattern: Custom Resource Definitions (CRDs) definieren die neue API, ein Controller reconciled sie kontinuierlich gegen die Realität. Die Vorteile sind handfest: Die Schnittstelle zum Entwickler ist klein und stabil, während die Plattform darunter umbauen kann (anderes Ingress, neuer Observability-Stack), ohne dass Teams etwas ändern müssen. Und die Standards sind nicht dokumentiert, sondern generiert — sie können gar nicht vergessen werden.
Der ehrliche Trade-off: Eine eigene API ist Software mit allem Drum und Dran — Versionierung, Migrationspfade, Bugs, Dokumentation. Wer sie zu früh oder zu breit baut, hat ein zweites Produkt am Hals, bevor das erste trägt. Viele Plattformen starten deshalb mit parametrisierten Templates (Helm-Charts, Kustomize-Bases) und führen CRDs erst ein, wenn die Abstraktion sich stabilisiert hat.
Der Weg eines Deployments durch die Schichten
Die Architektur versteht man am besten entlang eines konkreten Flusses. Eine Entwicklerin im Checkout-Team pusht einen Commit:
- L3: Die CI-Strecke baut das Image, führt Tests und Security-Scans aus und pusht das Image in die Registry. Anschließend aktualisiert sie — per Pull Request oder automatisiertem Commit — den Image-Tag im Konfigurations-Repo des Teams.
- L2: Der GitOps-Controller bemerkt die Änderung in Git und will den neuen Zustand in den Ziel-Cluster synchronisieren. Bei der Admission prüft die Policy-Engine jede Ressource gegen die Hausregeln — verstößt etwas, wird der Sync abgelehnt und der Fehler landet sichtbar beim Team, nicht heimlich in Produktion.
- L1: Kubernetes rollt die neuen Pods aus; Ingress und DNS leiten Traffic, der Autoscaler reagiert auf Last.
- L4: Im Portal sieht das Team den Deployment-Status, die generierten Dashboards zeigen die neuen Pods — ohne dass jemand sie angelegt hat.
Bemerkenswert ist, was in diesem Fluss fehlt: kein Ticket, kein manueller kubectl-Zugriff, kein Mensch aus dem Plattform-Team. Genau das ist der Self-Service aus Lektion 1, architektonisch eingelöst. Und Git ist dabei die einzige Schreibschnittstelle in die Cluster — was Audit (jede Änderung ist ein Commit) und Rollback (Revert) als Nebeneffekt mitliefert.
Praxis: die Architektur selbst zeichnen und befüllen
Nimm ein leeres Blatt oder ein Diagramm-Tool:
- Zeichne die fünf Schichten aus dem Gedächtnis und beschrifte jede mit ihrem Auftrag in einem Satz — nicht mit Tool-Namen.
- Befülle dann jede Schicht mit konkreten Tool-Entscheidungen für dieses Szenario: 40 Teams, AWS, keine regulierten Workloads. Pro Tool ein Halbsatz Begründung.
- Zeichne den Deployment-Fluss von oben als nummerierte Pfeile durch dein Diagramm — vom Commit bis zum laufenden Pod.
- Härtetest: Beantworte anhand deines Diagramms drei Fragen schriftlich: Was fällt aus, wenn der GitOps-Controller down ist (und was läuft weiter)? An welcher Stelle wird ein nicht-konformes Manifest gestoppt? Welche Schicht müsstest du anfassen, um von Prometheus auf einen anderen Metrik-Stack zu wechseln — und wer merkt davon etwas?
Wenn du die drei Fragen flüssig beantworten kannst, sitzt das Modell.
Typische Stolperfallen
Das Logo-Diagramm. Fünfzehn Tools ohne Schichtenordnung zeigen Tool-Kenntnis, aber kein Architekturverständnis. Erst Schichten und Verantwortungen, dann Tools als austauschbare Besetzung der Rollen.
Das Portal mit der Plattform verwechseln. Backstage zu installieren erzeugt eine leere Fassade — der Wert entsteht in L2 und L3. Ein Portal ohne funktionierende Delivery- und Service-Schicht ist ein Katalog ohne Ware.
Die Platform API zu früh bauen. Eigene CRDs für drei Pilot-Teams sind Over-Engineering; die Abstraktion sollte aus beobachteten, stabilen Mustern entstehen, nicht aus Antizipation.
Den degradierten Modus nicht kennen. Wer nicht sagen kann, was bei Ausfall von GitOps-Controller oder Portal weiterläuft (nämlich: alle Workloads), hat die Entkopplung der Schichten nicht verstanden — eine beliebte Interview-Falle.
Interview-Vorbereitung
Auf „Skizziere eine Kubernetes-basierte IDP” antwortest du am stärksten mit dem Schichtenmodell: L0 bis L4 nennen und je einen Auftrag geben → den Deployment-Fluss einmal durchlaufen (Commit → CI → Git → GitOps + Policy → Cluster → Portal) → die Platform API als Reife-Merkmal erwähnen, inklusive ihres Trade-offs.
Rechne mit diesen Follow-ups:
- „Warum GitOps statt direktem Deployment aus der CI?” — Git als einzige Schreibschnittstelle: auditierbar, rollback-fähig per Revert, und der Cluster-Zugriff der CI entfällt als Angriffsfläche.
- „Was passiert, wenn euer Portal ausfällt?” — Nichts Kritisches: L4 ist Fassade; Deployments laufen über Git weiter, nur Komfortfunktionen fehlen.
- „Wann würdest du eigene CRDs einführen?” — Wenn sich wiederholende Muster über viele Teams stabilisiert haben und die Template-Lösung an Grenzen stößt; vorher Templates statt eigener API.
- „Wo werden eure Policies durchgesetzt?” — Bei der Admission in L2 (Policy-Engine), zusätzlich früher in der CI als schnelles Feedback — Defense in Depth, aber die Admission ist die verbindliche Instanz.
Zusammenfassung
Die Referenzarchitektur einer K8s-IDP ist ein Schichtenmodell: L0 Cloud Foundation, L1 Cluster Foundation, L2 Delivery & Governance (GitOps + Policy als kontrollierter Weg in die Cluster), L3 Platform Services (CI, Observability, Secrets, Platform-APIs) und L4 Developer Experience als Fassade. Entwickler deklarieren Absicht — idealerweise gegen eine schlanke Platform API — und Controller setzen sie standardkonform um; Git ist die einzige Schreibschnittstelle, Tickets kommen im Fluss nicht vor.
Die unterste Schicht haben wir bisher als gegeben behandelt. Die nächste Lektion holt das nach: Landing Zones und Cloud Foundation — das Fundament unter dem Fundament.