---
title: "Managed Kubernetes Platform on STACKIT"
description: "Geführte PRODYNA Journey zur Managed Kubernetes Platform auf STACKIT: Discovery, Landing Zone, Management-Cluster, Flotte, Workloads, Day-2 und Übergabe."
scfTrail:
  maintainers:
    - contributor: "prodyna"
  tags:
    ["kubernetes", "ske", "gitops", "platform", "replatform", "dm/design", "argocd", "kyverno", "multi-cluster", "day-2-betrieb"]
  steps:
    - style: "compass"
      id: "platform-discovery"
      title: "Discovery und Zielarchitektur"
      trailContext: "Beginnen Sie mit einem eintägigen Workshop, der bestehende Workloads, Infrastruktur und Compliance-Anforderungen analysiert, und überführen Sie die Ergebnisse in einen Architektur-Blueprint und eine Roadmap."
      description: "Die Roadmap unten zeigt den Zuschnitt der Umsetzung: fünf Phasen, acht bis zwölf Wochen, ein benanntes Ergebnis pro Phase."
      assetId: "de/migration/assetcontainer/prodyna/managed-kubernetes-platform.mdx#discovery-und-zielarchitektur"
      imageSrc: "contributors/prodyna/files/migration/managed-kubernetes-delivery-roadmap.svg"
      imageAlt: "Delivery-Roadmap über zwölf Wochen: Discovery und Zielarchitektur, Landing-Zone-Fundament, Management-Cluster-Fundament, Rollout der Workload-Cluster-Flotte und Übergabe, jeweils mit Ergebnis"
      imagePosition: full

    - style: "hut"
      id: "landing-zone-foundation"
      title: "Landing-Zone-Fundament"
      trailContext: "Eine Kubernetes-Plattform ist nur so tragfähig wie die Landing Zone darunter. Governance, Projekthierarchie und Hub-Networking entstehen, bevor das erste Cluster ausgerollt wird, denn das Management-Cluster wird in dieses Fundament hinein ausgerollt und nicht daneben."
      assetId: "de/migration/assetcontainer/prodyna/caf-landing-zones-implementation.mdx#was-sie-im-5-tage-hackathon-erhalten"

    - style: "stairs"
      id: "management-cluster"
      title: "Management-Cluster-Fundament"
      trailContext: "Rollen Sie das zentrale Management-Cluster in ein Landing-Zone-Projekt aus. Es wird zur Control Plane, die Add-ons, Helm-Charts und standardisierte Konfiguration über die gesamte Flotte verteilt."
      description: "Dieser Schritt macht aus einer Menge von Clustern eine Plattform. Alles, was die Flotte teilt, wird hier einmal definiert und laufend abgeglichen."
      assetId: "de/migration/assetcontainer/prodyna/managed-kubernetes-platform.mdx#management-cluster-fundament"
      imageSrc: "contributors/prodyna/files/migration/managed-kubernetes-fleet-architecture.svg"
      imageAlt: "Flottenarchitektur: ein Git-Repository speist das Management-Cluster in der Platform Landing Zone, das Add-ons, Policies, Konfiguration und Observability in die Dev-, Test- und Prod-Workload-Cluster synchronisiert"
      imagePosition: full

    - role: sub
      id: "gitops-control-plane"
      title: "GitOps-Stack auswählen"
      trailContext: "Argo CD oder Flux gleichen den gewünschten Zustand ab, und Crossplane erweitert denselben Loop auf STACKIT Ressourcen, sodass Netzwerke und Datenbanken neben den Workloads deklariert werden, die sie nutzen. Welche der beiden Engines Sie wählen, zählt deutlich weniger als die Festlegung auf eine und ein einheitliches Repository-Layout für die gesamte Flotte."

    - style: "shield"
      id: "guardrails-baseline"
      title: "Leitplanken und Compliance-Baseline"
      trailContext: "Legen Sie fest, was jedes Cluster erbt, bevor die Flotte existiert: RBAC-Baselines, Admission Control über OPA oder Kyverno, Network Policies und die Add-ons für Ingress, Secrets, Backup und Observability."
      description: "Die Leitplanken werden aus dem Management-Cluster verteilt und laufend abgeglichen. Dadurch ist die Baseline in Dev, Test und Prod identisch und bleibt es, während die Flotte wächst. Genau das macht den Betrieb nach BSI C5 und ISO 27001 zu einer Eigenschaft der Architektur statt zu einer Audit-Übung."
      imageSrc: "contributors/prodyna/files/migration/managed-kubernetes-cluster-baseline.svg"
      imageAlt: "Siebenschichtige Cluster-Baseline von souveräner STACKIT Infrastruktur und Landing Zone über SKE, Leitplanken, Plattform-Add-ons und Golden Paths bis zu den Team-Workloads, wobei die Leitplanken- und Add-on-Schichten flottenweit aus dem Management-Cluster durchgesetzt werden"
      imagePosition: full

    - style: "chairlift"
      id: "fleet-rollout"
      title: "Rollout der Workload-Cluster-Flotte"
      trailContext: "Provisionieren Sie die Workload-Cluster für Dev, Test und Prod und synchronisieren Sie Add-ons und Konfiguration aus dem Management-Cluster, damit jedes Cluster von derselben Baseline startet."
      assetId: "de/migration/assetcontainer/prodyna/managed-kubernetes-platform.mdx#rollout-der-workload-cluster-flotte"

    - role: sub
      id: "developer-self-service"
      title: "Developer-Self-Service"
      trailContext: "Ein Portal macht aus der Plattform einen Katalog: ein Team wählt ein Template und erhält ein Repository, eine Pipeline und einen Namespace mit bereits angewandter Baseline, ohne ein Ticket zu schreiben. Lohnt sich als kleiner Pilot während des Rollouts, statt es auf ein späteres Projekt zu verschieben."

    - style: "gondola"
      id: "workload-onboarding"
      title: "Die ersten Workloads aufsetzen"
      trailContext: "Eine Plattform beweist sich, wenn Workloads auf ihr laufen. Die erste Anwendung geht den kompletten Weg: in der CI gebaut und getestet, gescannt und signiert, in der Container Registry abgelegt und anschließend von derselben GitOps-Engine ins Cluster gebracht, die auch die Flotte regiert."
      description: "Der Image-Tag ist die Übergabe zwischen CI und GitOps, weshalb die Pipeline nie Cluster-Credentials braucht. Das Admission Gate weist alles Unsignierte oder nicht Konforme ab, bevor es einen Node erreicht. Die Promotion zwischen Dev, Test und Prod ändert Werte statt Manifeste, und ein Rollback ist ein zurückgenommener Commit statt eines manuellen Eingriffs. Sobald der erste Workload diesen Weg gegangen ist, erbt ihn jedes weitere Team als befestigte Straße."
      imageSrc: "contributors/prodyna/files/migration/managed-kubernetes-workload-delivery.svg"
      imageAlt: "Workload-Auslieferung in zwei Bahnen: die Build-Bahn führt vom Source-Repository über die CI-Pipeline, Scanning und Signierung in die STACKIT Container Registry; die Deliver-Bahn committet den Image-Tag ins Config-Repository, gleicht ihn per GitOps auf dem Management-Cluster ab, prüft ihn am Admission Gate und bringt ihn in Dev, Test und Prod zum Laufen"
      imagePosition: full

    - style: "chart"
      id: "day-2-operations"
      title: "Day-2-Betrieb und Fleet-Lifecycle"
      trailContext: "An Day-2 entscheidet sich, ob eine Plattform trägt. Die Daueraufgabe ist, die gesamte Flotte aktuell und nachweisbar gesund zu halten: Kubernetes-Versionen, Node-Images, Add-on-Releases, Zertifikatsrotation und das vereinbarte Reaktionsfenster für neue Policies und CVEs."
      description: "Jede dieser Änderungen wird einmal im Plattform-Repository gemacht und in Wellen ausgerollt, erst Dev, dann Test, dann Prod, wobei jede Welle davon abhängt, dass die vorherige gesund bleibt. Eine Welle, die nicht gesund hochkommt, stoppt den Rollout. Dadurch ist der Blast Radius einer schlechten Plattformänderung eine Umgebung statt der gesamten Flotte. Und der Nachweis, dass jedes Cluster auf der vereinbarten Version läuft, ist eine Abfrage gegen die Flotte statt einer handgepflegten Tabelle. Das Tuning einzelner Workloads steht bewusst nicht auf dieser Liste. Es gehört dem Applikationsteam, dem der Workload gehört."
      imageSrc: "contributors/prodyna/files/migration/managed-kubernetes-fleet-lifecycle.svg"
      imageAlt: "Day-2 in zwei Abschnitten: was die Plattform flottenweit aktuell hält, nämlich Kubernetes-Version, Node Pools und Betriebssystem, Plattform-Add-ons, Zertifikate und Secrets sowie Policies und CVEs; und wie eine solche Änderung die Flotte erreicht, im Plattform-Repository vorgeschlagen, einmal auf dem Management-Cluster angewandt und dann in abgesicherten Wellen nach Dev, Test und Prod ausgerollt"
      imagePosition: full

    - style: "summit"
      id: "handover"
      title: "Wissenstransfer und operativer Betrieb"
      trailContext: "Schließen Sie die Umsetzung mit Wissenstransfer zu Cluster-Lifecycle, Add-on-Upgrades, Skalierung und Monitoring ab, damit das interne Team den gesamten Plattform-Lifecycle verantwortet."
      assetId: "de/migration/assetcontainer/prodyna/managed-kubernetes-platform.mdx#wissenstransfer-und-operativer-betrieb"

  presentations:
    - id: "executive-overview"
      label: "Management-Überblick"
      description: "Die Plattform-Journey und ihre Ergebnisse für Entscheider, ohne Tooling-Details."
      default: true
      launch: true
      preset: "minimal"
      steps:
        - id: "platform-discovery"
          notes: "Mit der Roadmap eröffnen. Ein Workshop-Tag setzt den Rahmen: was heute läuft, was compliant sein muss und wie die Zielplattform aussieht. Acht bis zwölf Wochen, fünf Phasen, je ein benanntes Ergebnis."
        - id: "landing-zone-foundation"
          notes: "Die Landing Zone ist der regulierte Boden, auf dem die Plattform steht. Sie zu überspringen ist der häufigste Grund, warum Kubernetes-Plattformen später unregierbar werden. Fünf Tage, parallel zum Design möglich."
        - id: "management-cluster"
          notes: "Ein zentrales Cluster regiert die Flotte. Genau das macht aus einer Menge von Clustern eine Plattform: Konsistenz wird durchgesetzt, nicht dokumentiert."
        - id: "guardrails-baseline"
          notes: "Das ist das Compliance-Argument. Security wird von der Architektur vererbt, ein neues Cluster kann gar nicht unterhalb der Baseline starten. Hier lohnt eine Pause, wenn das Publikum Risiko oder Audit verantwortet."
        - id: "fleet-rollout"
          notes: "Cluster entstehen in Stunden statt Wochen, jedes mit derselben Security- und Observability-Baseline."
        - id: "workload-onboarding"
          notes: "Nicht die Plattform ist das Ziel, sondern die Workloads darauf. Das Diagramm einmal durchgehen: gebaut, signiert, registriert, dann von GitOps ausgeliefert. Für dieses Publikum zählt vor allem, dass das Security-Gate im Weg liegt und nicht daneben. Compliance ist damit kein separater Schritt, den jemand überspringen kann."
        - id: "handover"
          notes: "Die Umsetzung endet damit, dass Ihr Team die Plattform eigenständig betreibt, nicht mit einer Abhängigkeit von uns."

    - id: "delivery-deep-dive"
      label: "Technischer Deep Dive"
      description: "Vollständiger technischer Durchlauf: Plattformphasen, Leitplanken, Onboarding-Pfade und Day-2-Betrieb."
      preset: "focus"
      steps:
        - id: "platform-discovery"
          notes: "Zuerst die Phasen und ihre Dauer verankern, bevor es in eine einzelne geht. Die Landing-Zone-Phase verkürzt sich, wenn bereits ein reguliertes Fundament existiert."
        - id: "landing-zone-foundation"
          notes: "Der Umfang des fünftägigen PRODYNA Accelerator-Workshops. Darauf hinweisen, dass er parallel zum Design aus der vorherigen Phase laufen kann. Genau das hält die Gesamtumsetzung bei acht bis zwölf Wochen."
        - id: "management-cluster"
          notes: "Das Diagramm von links nach rechts durchgehen: Git hält den Zielzustand, das Management-Cluster gleicht ab, die Flotte erbt, und Drift meldet zurück."
        - id: "gitops-control-plane"
          role: sub
          notes: "Argo CD und Flux sind hier austauschbar. Crossplane ist das Stück, das STACKIT Ressourcen in denselben Abgleich-Loop holt wie die Workloads."
        - id: "guardrails-baseline"
          notes: "Den Stack von unten nach oben lesen. Die beiden geklammerten Schichten gehören dem Management-Cluster, und sie sind der Grund, warum ein neues Cluster ab Erstellung compliant ist."
        - id: "fleet-rollout"
          notes: "Die Provisionierung ist der sichtbare Teil. Synchronisation und Drift-Erkennung dahinter halten die Flotte nach Woche eins einheitlich."
        - id: "developer-self-service"
          role: sub
          notes: "Optionale Ebene. Lohnt sich als Proof of Concept während des Flotten-Rollouts statt als separates späteres Projekt."
        - id: "workload-onboarding"
          notes: "Die beiden Bahnen von links nach rechts durchgehen. Bei der Übergabe lohnt das Verweilen: die CI spricht nie mit dem Cluster, sie schreibt nur einen Tag, den GitOps aufgreift. Genau das hält Cluster-Credentials aus der Pipeline heraus, und danach fragt ein Plattform-Engineer meist als Erstes."
        - id: "day-2-operations"
          notes: "Diese Folie beantwortet die Frage, wer dreißig Cluster aktuell hält. Eine Änderung im Plattform-Repository, in abgesicherten Wellen ausgerollt. Lohnt den Kontrast zur Alternative, die das Publikum vermutlich kennt: ein Wartungswochenende pro Cluster und eine Tabelle darüber, wer auf welcher Version läuft."
        - id: "handover"
          notes: "Wissenstransfer und Handover, zwei bis drei Wochen, am Ende stehen Runbooks, die das interne Team wirklich verantwortet."
source_url: "https://framework.stackit.cloud/de/migration/trails/prodyna/managed-kubernetes-platform-on-stackit/"
source_file: "docs/de/migration/trails/prodyna/managed-kubernetes-platform-on-stackit.mdx"
---

## Steps

### 1. Discovery und Zielarchitektur

Stage: `compass`

Beginnen Sie mit einem eintägigen Workshop, der bestehende Workloads, Infrastruktur und Compliance-Anforderungen analysiert, und überführen Sie die Ergebnisse in einen Architektur-Blueprint und eine Roadmap.

Die Roadmap unten zeigt den Zuschnitt der Umsetzung: fünf Phasen, acht bis zwölf Wochen, ein benanntes Ergebnis pro Phase.

Asset: [/de/migration/assetcontainer/prodyna/managed-kubernetes-platform/#discovery-und-zielarchitektur](/de/migration/assetcontainer/prodyna/managed-kubernetes-platform/#discovery-und-zielarchitektur) — source: [/raw/de/migration/assetcontainer/prodyna/managed-kubernetes-platform.md](/raw/de/migration/assetcontainer/prodyna/managed-kubernetes-platform.md), section `#discovery-und-zielarchitektur`

### 2. Landing-Zone-Fundament

Stage: `hut`

Eine Kubernetes-Plattform ist nur so tragfähig wie die Landing Zone darunter. Governance, Projekthierarchie und Hub-Networking entstehen, bevor das erste Cluster ausgerollt wird, denn das Management-Cluster wird in dieses Fundament hinein ausgerollt und nicht daneben.

Asset: [/de/migration/assetcontainer/prodyna/caf-landing-zones-implementation/#was-sie-im-5-tage-hackathon-erhalten](/de/migration/assetcontainer/prodyna/caf-landing-zones-implementation/#was-sie-im-5-tage-hackathon-erhalten) — source: [/raw/de/migration/assetcontainer/prodyna/caf-landing-zones-implementation.md](/raw/de/migration/assetcontainer/prodyna/caf-landing-zones-implementation.md), section `#was-sie-im-5-tage-hackathon-erhalten`

### 3. Management-Cluster-Fundament

Stage: `stairs`

Rollen Sie das zentrale Management-Cluster in ein Landing-Zone-Projekt aus. Es wird zur Control Plane, die Add-ons, Helm-Charts und standardisierte Konfiguration über die gesamte Flotte verteilt.

Dieser Schritt macht aus einer Menge von Clustern eine Plattform. Alles, was die Flotte teilt, wird hier einmal definiert und laufend abgeglichen.

Asset: [/de/migration/assetcontainer/prodyna/managed-kubernetes-platform/#management-cluster-fundament](/de/migration/assetcontainer/prodyna/managed-kubernetes-platform/#management-cluster-fundament) — source: [/raw/de/migration/assetcontainer/prodyna/managed-kubernetes-platform.md](/raw/de/migration/assetcontainer/prodyna/managed-kubernetes-platform.md), section `#management-cluster-fundament`

### 4. GitOps-Stack auswählen

Argo CD oder Flux gleichen den gewünschten Zustand ab, und Crossplane erweitert denselben Loop auf STACKIT Ressourcen, sodass Netzwerke und Datenbanken neben den Workloads deklariert werden, die sie nutzen. Welche der beiden Engines Sie wählen, zählt deutlich weniger als die Festlegung auf eine und ein einheitliches Repository-Layout für die gesamte Flotte.

### 5. Leitplanken und Compliance-Baseline

Stage: `shield`

Legen Sie fest, was jedes Cluster erbt, bevor die Flotte existiert: RBAC-Baselines, Admission Control über OPA oder Kyverno, Network Policies und die Add-ons für Ingress, Secrets, Backup und Observability.

Die Leitplanken werden aus dem Management-Cluster verteilt und laufend abgeglichen. Dadurch ist die Baseline in Dev, Test und Prod identisch und bleibt es, während die Flotte wächst. Genau das macht den Betrieb nach BSI C5 und ISO 27001 zu einer Eigenschaft der Architektur statt zu einer Audit-Übung.

### 6. Rollout der Workload-Cluster-Flotte

Stage: `chairlift`

Provisionieren Sie die Workload-Cluster für Dev, Test und Prod und synchronisieren Sie Add-ons und Konfiguration aus dem Management-Cluster, damit jedes Cluster von derselben Baseline startet.

Asset: [/de/migration/assetcontainer/prodyna/managed-kubernetes-platform/#rollout-der-workload-cluster-flotte](/de/migration/assetcontainer/prodyna/managed-kubernetes-platform/#rollout-der-workload-cluster-flotte) — source: [/raw/de/migration/assetcontainer/prodyna/managed-kubernetes-platform.md](/raw/de/migration/assetcontainer/prodyna/managed-kubernetes-platform.md), section `#rollout-der-workload-cluster-flotte`

### 7. Developer-Self-Service

Ein Portal macht aus der Plattform einen Katalog: ein Team wählt ein Template und erhält ein Repository, eine Pipeline und einen Namespace mit bereits angewandter Baseline, ohne ein Ticket zu schreiben. Lohnt sich als kleiner Pilot während des Rollouts, statt es auf ein späteres Projekt zu verschieben.

### 8. Die ersten Workloads aufsetzen

Stage: `gondola`

Eine Plattform beweist sich, wenn Workloads auf ihr laufen. Die erste Anwendung geht den kompletten Weg: in der CI gebaut und getestet, gescannt und signiert, in der Container Registry abgelegt und anschließend von derselben GitOps-Engine ins Cluster gebracht, die auch die Flotte regiert.

Der Image-Tag ist die Übergabe zwischen CI und GitOps, weshalb die Pipeline nie Cluster-Credentials braucht. Das Admission Gate weist alles Unsignierte oder nicht Konforme ab, bevor es einen Node erreicht. Die Promotion zwischen Dev, Test und Prod ändert Werte statt Manifeste, und ein Rollback ist ein zurückgenommener Commit statt eines manuellen Eingriffs. Sobald der erste Workload diesen Weg gegangen ist, erbt ihn jedes weitere Team als befestigte Straße.

### 9. Day-2-Betrieb und Fleet-Lifecycle

Stage: `chart`

An Day-2 entscheidet sich, ob eine Plattform trägt. Die Daueraufgabe ist, die gesamte Flotte aktuell und nachweisbar gesund zu halten: Kubernetes-Versionen, Node-Images, Add-on-Releases, Zertifikatsrotation und das vereinbarte Reaktionsfenster für neue Policies und CVEs.

Jede dieser Änderungen wird einmal im Plattform-Repository gemacht und in Wellen ausgerollt, erst Dev, dann Test, dann Prod, wobei jede Welle davon abhängt, dass die vorherige gesund bleibt. Eine Welle, die nicht gesund hochkommt, stoppt den Rollout. Dadurch ist der Blast Radius einer schlechten Plattformänderung eine Umgebung statt der gesamten Flotte. Und der Nachweis, dass jedes Cluster auf der vereinbarten Version läuft, ist eine Abfrage gegen die Flotte statt einer handgepflegten Tabelle. Das Tuning einzelner Workloads steht bewusst nicht auf dieser Liste. Es gehört dem Applikationsteam, dem der Workload gehört.

### 10. Wissenstransfer und operativer Betrieb

Stage: `summit`

Schließen Sie die Umsetzung mit Wissenstransfer zu Cluster-Lifecycle, Add-on-Upgrades, Skalierung und Monitoring ab, damit das interne Team den gesamten Plattform-Lifecycle verantwortet.

Asset: [/de/migration/assetcontainer/prodyna/managed-kubernetes-platform/#wissenstransfer-und-operativer-betrieb](/de/migration/assetcontainer/prodyna/managed-kubernetes-platform/#wissenstransfer-und-operativer-betrieb) — source: [/raw/de/migration/assetcontainer/prodyna/managed-kubernetes-platform.md](/raw/de/migration/assetcontainer/prodyna/managed-kubernetes-platform.md), section `#wissenstransfer-und-operativer-betrieb`