---
title: "Managed Kubernetes Platform on STACKIT"
description: "Guided PRODYNA journey to a managed Kubernetes platform on STACKIT: discovery, landing zone, management cluster, fleet, workloads, day-2, and handover."
scfTrail:
  maintainers:
    - contributor: "prodyna"
  tags:
    ["kubernetes", "ske", "gitops", "platform", "replatform", "dm/design", "argocd", "kyverno", "multi-cluster", "day-2-operations"]
  steps:
    - style: "compass"
      id: "platform-discovery"
      title: "Discovery and Target Architecture"
      trailContext: "Start with a one-day workshop that assesses current workloads, infrastructure, and compliance requirements, then agree the cloud strategy fit and the target architecture decisions within the same week."
      description: "The roadmap below is the shape of the engagement: five phases, eight to twelve weeks, one named deliverable per phase."
      assetId: "migration/assetcontainer/prodyna/managed-kubernetes-platform.mdx#discovery-and-target-architecture"
      imageSrc: "contributors/prodyna/files/migration/managed-kubernetes-delivery-roadmap.svg"
      imageAlt: "Delivery roadmap across twelve weeks: discovery and target architecture, landing zone foundation, management cluster foundation, workload cluster fleet rollout, and handover, each with its deliverable"
      imagePosition: full

    - style: "hut"
      id: "landing-zone-foundation"
      title: "Landing Zone Foundation"
      trailContext: "A Kubernetes platform is only as sound as the landing zone underneath it. Governance, project hierarchy, and hub networking are established before any cluster is deployed, because the management cluster is deployed into that foundation rather than beside it."
      assetId: "migration/assetcontainer/prodyna/caf-landing-zones-implementation.mdx#what-you-get-in-the-5-day-workshop"

    - style: "stairs"
      id: "management-cluster"
      title: "Management Cluster Foundation"
      trailContext: "Deploy the central management cluster into a landing zone project. It becomes the control plane that distributes add-ons, Helm charts, and standardized configuration across the whole fleet."
      description: "This is the step that turns a set of clusters into a platform. Everything the fleet shares is defined once here and reconciled continuously."
      assetId: "migration/assetcontainer/prodyna/managed-kubernetes-platform.mdx#management-cluster-foundation"
      imageSrc: "contributors/prodyna/files/migration/managed-kubernetes-fleet-architecture.svg"
      imageAlt: "Fleet architecture: a Git repository feeds a management cluster in the platform landing zone, which synchronizes add-ons, policy, configuration, and observability into the Dev, Test, and Prod workload clusters"
      imagePosition: full

    - role: sub
      id: "gitops-control-plane"
      title: "Choose the GitOps stack"
      trailContext: "Argo CD or Flux reconciles the desired state, and Crossplane extends the same loop to STACKIT resources so networks and databases are declared next to the workloads that use them. Which of the two engines you pick matters far less than committing to one and giving the whole fleet a single repository layout."

    - style: "shield"
      id: "guardrails-baseline"
      title: "Guardrails and Compliance Baseline"
      trailContext: "Define what every cluster inherits before the fleet exists: RBAC baselines, admission control through OPA or Kyverno, network policies, and the add-ons that carry ingress, secrets, backup, and observability."
      description: "Guardrails are distributed from the management cluster and reconciled continuously, so the baseline is identical in Dev, Test, and Prod and stays identical as the fleet grows. This is what makes BSI C5 and ISO 27001 operation an architectural property rather than an audit exercise."
      imageSrc: "contributors/prodyna/files/migration/managed-kubernetes-cluster-baseline.svg"
      imageAlt: "Seven-layer cluster baseline from sovereign STACKIT infrastructure and the landing zone up through SKE, guardrails, platform add-ons, and golden paths to team workloads, with the guardrail and add-on layers enforced fleet-wide from the management cluster"
      imagePosition: full

    - style: "chairlift"
      id: "fleet-rollout"
      title: "Workload Cluster Fleet Rollout"
      trailContext: "Provision the Dev, Test, and Prod workload clusters and synchronize add-ons and configuration from the management cluster so every cluster starts from the same baseline."
      assetId: "migration/assetcontainer/prodyna/managed-kubernetes-platform.mdx#workload-cluster-fleet-rollout"

    - role: sub
      id: "developer-self-service"
      title: "Developer Self-Service"
      trailContext: "A portal turns the platform into a catalog: a team picks a template and receives a repository, a pipeline, and a namespace with the baseline already applied, without filing a ticket. Worth proving with a small pilot during the rollout rather than deferring it to a later project."

    - style: "gondola"
      id: "workload-onboarding"
      title: "Land the First Workloads"
      trailContext: "A platform proves itself when workloads run on it. The first application walks the whole path end to end: built and tested in CI, scanned and signed, stored in the container registry, then delivered into the cluster by the same GitOps engine that governs the fleet."
      description: "The image tag is the handoff between CI and GitOps, which is why the pipeline never needs cluster credentials. The admission gate rejects anything unsigned or non-compliant before it reaches a node, promotion between Dev, Test, and Prod changes values rather than manifests, and a rollback is a reverted commit rather than a manual intervention. Once the first workload has walked this path, every team after it inherits the same route as a paved road."
      imageSrc: "contributors/prodyna/files/migration/managed-kubernetes-workload-delivery.svg"
      imageAlt: "Workload delivery in two lanes: the build lane runs from the source repository through the CI pipeline, scanning and signing, into the STACKIT Container Registry; the delivery lane commits the image tag to the config repository, reconciles it with GitOps on the management cluster, checks it at the admission gate, and runs it in Dev, Test, and Prod"
      imagePosition: full

    - style: "chart"
      id: "day-2-operations"
      title: "Day-2 Operations and Fleet Lifecycle"
      trailContext: "Day-2 is where a platform is won or lost. The standing job is keeping the whole fleet current and provably healthy: Kubernetes versions, node images, add-on releases, certificate rotation, and the response window for new policies and CVEs."
      description: "Each of those changes is made once in the platform repository and rolled out in waves, Dev first, then Test, then Prod, with every wave gated on the previous one staying healthy. A wave that does not come up healthy stops the rollout, so the blast radius of a bad platform change is one environment rather than the whole fleet, and proving that every cluster runs the agreed version is a query against the fleet rather than a spreadsheet someone maintains by hand. Tuning an individual workload is deliberately not on this list. That belongs to the application team that owns the workload."
      imageSrc: "contributors/prodyna/files/migration/managed-kubernetes-fleet-lifecycle.svg"
      imageAlt: "Day-2 in two sections: what the platform keeps current across the fleet, namely Kubernetes version, node pools and OS, platform add-ons, certificates and secrets, and policies and CVEs; and how such a change reaches the fleet, proposed in the platform repository, applied once on the management cluster, then rolled out in gated waves to Dev, Test, and Prod"
      imagePosition: full

    - style: "summit"
      id: "handover"
      title: "Handover and Operational Enablement"
      trailContext: "Close the engagement with knowledge transfer on cluster lifecycle, add-on upgrades, scaling, and monitoring so the internal team owns the full platform lifecycle."
      assetId: "migration/assetcontainer/prodyna/managed-kubernetes-platform.mdx#handover-and-operational-enablement"

  presentations:
    - id: "executive-overview"
      label: "Executive overview"
      description: "The platform journey and its outcomes for decision-makers, without the tooling detail."
      default: true
      launch: true
      preset: "minimal"
      steps:
        - id: "platform-discovery"
          notes: "Open with the roadmap. One workshop day sets the frame: what runs today, what must be compliant, and what the target platform looks like. Eight to twelve weeks, five phases, a named deliverable each."
        - id: "landing-zone-foundation"
          notes: "The landing zone is the governed ground the platform stands on. Skipping it is the most common reason Kubernetes platforms become ungovernable later. Five days, and it can run in parallel with design."
        - id: "management-cluster"
          notes: "One central cluster governs the fleet. That is what turns a set of clusters into a platform: consistency is enforced, not documented."
        - id: "guardrails-baseline"
          notes: "This is the compliance argument. Security is inherited by construction, so a new cluster cannot start below the baseline. Worth pausing here if the audience owns risk or audit."
        - id: "fleet-rollout"
          notes: "Clusters arrive in hours rather than weeks, each with the same security and observability baseline."
        - id: "workload-onboarding"
          notes: "The platform is not the goal, the workloads on it are. Walk the diagram once: built, signed, registered, then delivered by GitOps. The point for this audience is that the security gate sits inside the path rather than beside it, so compliance is not a separate step someone can skip."
        - id: "handover"
          notes: "The engagement ends with your team operating the platform independently, not with a dependency on us."

    - id: "delivery-deep-dive"
      label: "Delivery deep dive"
      description: "Full technical walkthrough: platform phases, guardrails, workload onboarding paths, and day-2 operations."
      preset: "focus"
      steps:
        - id: "platform-discovery"
          notes: "Anchor the phases and their durations before going into any single one. Note that the landing zone phase shortens when a governed foundation already exists."
        - id: "landing-zone-foundation"
          notes: "The scope of the five-day PRODYNA accelerator workshop. Point out that it can run in parallel with the design work from the previous phase, which is what keeps the overall engagement at eight to twelve weeks."
        - id: "management-cluster"
          notes: "Walk the diagram left to right: Git holds desired state, the management cluster reconciles it, the fleet inherits it, and drift reports back."
        - id: "gitops-control-plane"
          role: sub
          notes: "Argo CD and Flux are interchangeable here. Crossplane is the piece that pulls STACKIT resources into the same reconcile loop as the workloads."
        - id: "guardrails-baseline"
          notes: "Read the stack bottom-up. The two bracketed layers are the ones the management cluster owns, and they are the reason a new cluster is compliant on creation."
        - id: "fleet-rollout"
          notes: "Provisioning is the visible part; the synchronization and drift detection behind it are what keep the fleet uniform after week one."
        - id: "developer-self-service"
          role: sub
          notes: "Optional layer. Worth a proof of concept during fleet rollout rather than a separate later project."
        - id: "workload-onboarding"
          notes: "Walk the two lanes left to right. The handoff worth dwelling on is the image tag: CI never talks to the cluster, it only writes a tag that GitOps picks up. That is what keeps cluster credentials out of the pipeline, and it is usually the question a platform engineer asks first."
        - id: "day-2-operations"
          notes: "The question this slide answers is who keeps thirty clusters current. One change in the platform repository, rolled out in gated waves. Worth contrasting with the alternative the audience probably knows, which is a maintenance weekend per cluster and a spreadsheet tracking who is on which version."
        - id: "handover"
          notes: "Knowledge transfer and handover, two to three weeks, ending in runbooks the internal team actually owns."
source_url: "https://framework.stackit.cloud/migration/trails/prodyna/managed-kubernetes-platform-on-stackit/"
source_file: "docs/migration/trails/prodyna/managed-kubernetes-platform-on-stackit.mdx"
---

## Steps

### 1. Discovery and Target Architecture

Stage: `compass`

Start with a one-day workshop that assesses current workloads, infrastructure, and compliance requirements, then agree the cloud strategy fit and the target architecture decisions within the same week.

The roadmap below is the shape of the engagement: five phases, eight to twelve weeks, one named deliverable per phase.

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

### 2. Landing Zone Foundation

Stage: `hut`

A Kubernetes platform is only as sound as the landing zone underneath it. Governance, project hierarchy, and hub networking are established before any cluster is deployed, because the management cluster is deployed into that foundation rather than beside it.

Asset: [/migration/assetcontainer/prodyna/caf-landing-zones-implementation/#what-you-get-in-the-5-day-workshop](/migration/assetcontainer/prodyna/caf-landing-zones-implementation/#what-you-get-in-the-5-day-workshop) — source: [/raw/migration/assetcontainer/prodyna/caf-landing-zones-implementation.md](/raw/migration/assetcontainer/prodyna/caf-landing-zones-implementation.md), section `#what-you-get-in-the-5-day-workshop`

### 3. Management Cluster Foundation

Stage: `stairs`

Deploy the central management cluster into a landing zone project. It becomes the control plane that distributes add-ons, Helm charts, and standardized configuration across the whole fleet.

This is the step that turns a set of clusters into a platform. Everything the fleet shares is defined once here and reconciled continuously.

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

### 4. Choose the GitOps stack

Argo CD or Flux reconciles the desired state, and Crossplane extends the same loop to STACKIT resources so networks and databases are declared next to the workloads that use them. Which of the two engines you pick matters far less than committing to one and giving the whole fleet a single repository layout.

### 5. Guardrails and Compliance Baseline

Stage: `shield`

Define what every cluster inherits before the fleet exists: RBAC baselines, admission control through OPA or Kyverno, network policies, and the add-ons that carry ingress, secrets, backup, and observability.

Guardrails are distributed from the management cluster and reconciled continuously, so the baseline is identical in Dev, Test, and Prod and stays identical as the fleet grows. This is what makes BSI C5 and ISO 27001 operation an architectural property rather than an audit exercise.

### 6. Workload Cluster Fleet Rollout

Stage: `chairlift`

Provision the Dev, Test, and Prod workload clusters and synchronize add-ons and configuration from the management cluster so every cluster starts from the same baseline.

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

### 7. Developer Self-Service

A portal turns the platform into a catalog: a team picks a template and receives a repository, a pipeline, and a namespace with the baseline already applied, without filing a ticket. Worth proving with a small pilot during the rollout rather than deferring it to a later project.

### 8. Land the First Workloads

Stage: `gondola`

A platform proves itself when workloads run on it. The first application walks the whole path end to end: built and tested in CI, scanned and signed, stored in the container registry, then delivered into the cluster by the same GitOps engine that governs the fleet.

The image tag is the handoff between CI and GitOps, which is why the pipeline never needs cluster credentials. The admission gate rejects anything unsigned or non-compliant before it reaches a node, promotion between Dev, Test, and Prod changes values rather than manifests, and a rollback is a reverted commit rather than a manual intervention. Once the first workload has walked this path, every team after it inherits the same route as a paved road.

### 9. Day-2 Operations and Fleet Lifecycle

Stage: `chart`

Day-2 is where a platform is won or lost. The standing job is keeping the whole fleet current and provably healthy: Kubernetes versions, node images, add-on releases, certificate rotation, and the response window for new policies and CVEs.

Each of those changes is made once in the platform repository and rolled out in waves, Dev first, then Test, then Prod, with every wave gated on the previous one staying healthy. A wave that does not come up healthy stops the rollout, so the blast radius of a bad platform change is one environment rather than the whole fleet, and proving that every cluster runs the agreed version is a query against the fleet rather than a spreadsheet someone maintains by hand. Tuning an individual workload is deliberately not on this list. That belongs to the application team that owns the workload.

### 10. Handover and Operational Enablement

Stage: `summit`

Close the engagement with knowledge transfer on cluster lifecycle, add-on upgrades, scaling, and monitoring so the internal team owns the full platform lifecycle.

Asset: [/migration/assetcontainer/prodyna/managed-kubernetes-platform/#handover-and-operational-enablement](/migration/assetcontainer/prodyna/managed-kubernetes-platform/#handover-and-operational-enablement) — source: [/raw/migration/assetcontainer/prodyna/managed-kubernetes-platform.md](/raw/migration/assetcontainer/prodyna/managed-kubernetes-platform.md), section `#handover-and-operational-enablement`