On-Prem Kubernetes nach AKS: Schnitt oder bleiben

Constantin, Kubernetes-Betrieb bei Pexon Consulting | 12 Min. Lesezeit | 29.09.2026

TL;DR: On-Prem Kubernetes nach AKS in fünf Sätzen

Die Entscheidung, einen On-Prem- oder Rancher-ähnlichen Cluster nach Azure Kubernetes Service zu heben, ist eine Plattform-Entscheidung, kein Rehost-Ticket. Pexon Consulting (80 Mitarbeitende, Deutschland, Microsoft Partner) trennt Bleiben, Plattform-Schnitt und ehrliches EKS/GKE. Dieser Artikel hilft bei der Entscheidung, nicht bei der Umsetzung. Lift-and-Shift ohne Identitäten und Storage ist der falsche erste Schritt.

Das Problem: Die Anfrage heißt Umzug, die Lage ist ein laufender Cluster

Niemand startet auf der grünen Wiese. Es läuft ein Cluster, oft On-Prem, oft Rancher-ähnlich. Jemand hat „wir stellen auf AKS um“ in ein Protokoll geschrieben. Der Portal-Wizard sieht freundlich aus. Stateful Platten, drei Ingress-Eingänge und Policy-Drift sehen das anders.

On-Prem Kubernetes nach AKS ist deshalb zuerst eine Entscheidungsfrage. Den Ablauf des Projekts beschreibt unsere Seite zur Kubernetes-Migration. Der Weg von VMs zu Containern ist eine andere Reise, hier geht es um einen bestehenden Cluster.

Pexon Consulting klärt zuerst, ob der Ist-Cluster tragfähig ist.

Wann bleiben Sie auf dem bestehenden Cluster, statt nach AKS zu heben?

Die kurze Antwort: wenn der Cluster die Last trägt und der Schmerz eine Folie ist, kein Betrieb.

Bleiben, wenn Upgrades laufen, Identitäten klar sind, Stateful einen Besitzer hat und niemand eine Microsoft-Pflicht mitbringt. Heben, wenn das Haus schon Entra, Azure Landing Zone und die restliche IT auf Azure gezogen hat und der On-Prem-Control-Plane der letzte Sonderling ist.

Unsere Empfehlung: nicht heben, weil eine Ausschreibung „Cloud first“ sagt. Heben, weil der Schnitt die Identitäten und das Netz vereinfacht. Ein ruhiger On-Prem-Cluster, den das Team kann, ist kein Makel.

Wann ist Lift-and-Shift nach AKS der falsche erste Schritt?

Wenn Sie Pods kopieren und Policies, Ingress und Storage „danach“ machen.

Lift-and-Shift gewinnt Zeit auf der Folie und verliert sie im zweiten Monat. AKS hat andere Defaults für CNI, Identity, Disk, Load Balancer. Manifeste 1:1 sind verwandt, nicht identisch. Das haben wir am Cilium-Pfad schon gesehen: gleiche Sprache, andere Helm-Werte.

Die offizielle Dokumentation: Microsoft Learn zu AKS.

Wir raten davon ab, den ersten Schritt „alle Namespaces rüber“ zu nennen. Der erste Schritt ist die Gabel: bleiben, schneiden, oder ehrlich eine andere Cloud.

Was muss ein Plattform-Schnitt klären, das ein Rehost nicht klärt – Identitäten, Ingress, Storage, Policies?

Vier Schnitte, ohne Tool-Portraits.

1. Identitäten: Workload Identity gegen Datei-Secrets, Entra gegen selbstgebaute Nutzer.
2. Ingress: öffentliche, authentisierte, interne Zone. Ein Default-Gateway ist die Finding.
3. Storage: Longhorn oder local-path gegen Azure Disk und Backup-Klasse. Stateful entscheidet oft über den ganzen Umzug.
4. Policies: Kyverno gegen Azure Policy, NetworkPolicy gegen den AKS-Datapath.

Wer diese vier nicht aufschreibt, hat ein Rehost-Ticket. Wer sie aufschreibt, hat einen Plattform-Schnitt. Unser Vergleich AKS vs. EKS vs. GKE behandelt die Wahl zwischen den Hyperscalern.

Wie ein solcher Ablauf aussieht, zeigt die Case Study zur Azure-Kubernetes-Migration.

Wann ist EKS oder GKE die ehrlichere Antwort als AKS?

Wenn die Cloud schon feststeht und es nicht Azure ist.

Microsoft-Nähe, Entra, restliche Workloads in Azure: AKS. AWS-Kern, bestehende IAM-Welten: EKS. GCP-Datenplattform als Mitte: GKE. Einen dritten Hyperscaler „dazu“, nur weil Kubernetes portabel klingt, zahlen Sie doppelt.

Die Details zu den drei Anbietern stehen im Vergleich AKS vs. EKS vs. GKE.

Welche Nachweise brauchen Sie vor dem Cutover, die kein Portal-Wizard liefert?

Restore-Fähigkeit der Daten, nicht nur der Deployments. Policy-Drift zwischen alt und neu. Wer nach dem Cutover den Control Plane wirklich trägt: AKS-Plattform-SLA endet an einer Grenze, Worker und Day-2 bleiben.

AKS unterstützt nur drei Kubernetes-Versionen gleichzeitig, jede zwölf Monate ab Verfügbarkeit. Wer ohne Architektur hebt, wiederholt diese Arbeit jedes Jahr. Das ist ein Grund für den sauberen Schnitt.

Decision-Raster: bleiben, schneiden, andere Cloud

On-Prem Kubernetes nach AKS braucht ein Raster, das ein Wizard nicht liefert. Wir nutzen fünf Fragen, schriftlich, bevor jemand Namespaces kopiert:

1. Trägt das Team den Ist-Cluster noch zwölf Monate, ohne Heldentum?
2. Liegt der Rest der IT schon in Azure, inklusive Identitäten?
3. Ist Stateful so gebaut, dass Azure Disk plus Backup-Klasse ehrlich ist, oder bleibt eine Cloud-DB die kürzere Antwort?
4. Sind Ingress-Zonen benannt, oder gibt es einen Default-Eingang für alles?
5. Wer trägt nach dem Cutover Worker und Day-2? Nicht die Folie, der Name.

Drei Ja auf 2, 3, 4 und ein Nein auf 1: Schnitt ernsthaft. Drei Ja auf 1 und Nein auf 2: bleiben, Review statt Umzug. Cloud ist AWS oder GCP: EKS oder GKE.

Identitäten zuerst, weil sie den Rest binden. Workload Identity gegen Datei-Secrets ist kein Geschmack. Es entscheidet, ob der Schnitt die Secret-Landschaft halbiert oder verdoppelt. Wer Secrets 1:1 mitnimmt, hat gehoben und nichts vereinfacht.

Ingress-Zonen als zweites, weil AKS den Eingang anders legt als ein On-Prem-Default. Ein öffentlicher Eingang, ein interner, oft ein authentisierter: drei Policies, drei Zertifikatswege. Ein Application Gateway für alles verschiebt die Finding nur.

Storage als drittes, weil Stateful den Cutover-Termin diktiert. Ein Rehost der Disk ohne Backup-Klasse ist ein Termin, kein Nachweis. Cloud-DB daneben ist oft der ehrlichere Satz, kein Verrat am Cluster.

Policies als viertes. Azure Policy und Kyverno können parallel existieren. Parallel ohne Schichtkarte erzeugen doppelte Verbote. Ein Satz im Protokoll, welcher Schnitt welches Manifest stoppt.

Cutover ohne Freeze der Daten ist Heldentum. Ein Fenster, ein Owner, ein Rollback, der mehr ist als „DNS zurück“. Der Wizard kennt das Fenster nicht.

Namensräume 1:1 zu kopieren, inklusive toter Test-Namespaces, verdoppelt Müll. Inventar vorher. Was nicht weh tut, wenn es fehlt, bleibt erstmal weg.

Privater API-Zugang und Bastion verdienen eine eigene Betrachtung. Nur so viel: Ein öffentlicher API-Server, weil es erstmal schnell gehen soll, ist kein Schnitt, sondern ein Befund, den Sie mitnehmen. Das Raster aus bleiben, schneiden, andere Cloud hängt schriftlich im Protokoll, bevor der erste Namespace kopiert wird.

# Entscheidungsraster
bleiben     = Team trägt, kein Azure-Zwang
schneiden   = Entra + Zonen + Storage ehrlich
andere Cloud = AWS/GCP-Kern schon da

Häufig gestellte Fragen

Was kostet der Schnitt nach AKS?

Das hängt vom Umfang ab und wird als Projekt kalkuliert. Den Einstieg bildet ein Cluster-Check für den bestehenden Cluster.

Ist „wir stellen auf AKS um“ dasselbe wie eine Kubernetes-Migration?

Nein. Eine Migration kann auch VMs oder andere Projekte betreffen. Hier geht es nur um die Entscheidung, einen bestehenden On-Prem-Cluster nach AKS zu heben.

On-Prem Kubernetes nach AKS oder bleiben: was ist der Default 2026?

Kein Default. Microsoft-Haus: Schnitt ernsthaft prüfen. Ruhiger On-Prem-Cluster: bleiben und reviewen ist oft ehrlicher.

Müssen wir Rancher ablösen, um nach AKS zu gehen?

Rancher ist eine Klasse bestehender Plattform, nicht der Feind. Ablösen ist eine Folge, nicht der erste Satz.

Reicht Lift-and-Shift für den ersten Pilot?

Für einen leeren Namespace ja. Für Stateful und Policy nein. Den Pilot nicht mit dem Cutover verwechseln.

Nächster Schritt

Verwandte Themen