Containerisierung ist keine Modernisierung
Ein Legacy-Workload kann weiterhin von einem einzelnen Server, lokalen Dateien, einem festen Hostnamen, einer statischen IP, manueller Installation, In-Memory-Sessions, einem gemeinsamen beschreibbaren Verzeichnis, einem nicht unterstützten Betriebssystem oder einer hardwaregebundenen Lizenz abhängen. Das Verpacken in einen Container beseitigt nichts davon.
Modernisierung erfordert unter Umständen zusätzlich, die Konfiguration zu externalisieren, Dateien in persistenten Speicher oder Objektspeicher zu verschieben, maschinenspezifische Abhängigkeiten zu entfernen, aussagekräftige Health-Checks zu ergänzen, Graceful Shutdown zu unterstützen und die Lebenszyklen von Anwendung und Datenbank zu trennen.
Ein containerisierter Monolith kann trotzdem ein Monolith bleiben. Das ist nicht automatisch ein Fehlschlag — ein gut betriebener Monolith in Kubernetes kann einen schlecht betriebenen Monolithen auf einem unverwalteten Server schlagen. Die Verbesserung muss ehrlich gemessen werden.
Warum migrieren — und warum nicht
Ein solides Kubernetes-Programm lehnt ungeeignete Migrationen ab — Erfolg bemisst sich nicht am Prozentsatz verschobener Anwendungen.
Sechs Platzierungsoptionen
Den Controller wählen — und Windows-Anwendungen
Ein Deployment ist im Allgemeinen angemessen, wenn jedes Replikat Traffic bedienen kann und der Zustand extern liegt — Web-Frontends, zustandslose APIs, Worker zur Dokumentenverarbeitung. Ein StatefulSet eignet sich für tatsächlich zustandsbehaftete Legacy-Kandidaten, die stabile Identität oder geordnetes Scaling benötigen; nutzen Sie es nicht nur, weil eine App Dateien schreibt.
Kubernetes unterstützt Windows-Worker-Nodes neben Linux-Nodes. Die Control Plane bleibt Linux-basiert, während Workloads je nach Bedarf auf Windows- oder Linux-Nodes geplant werden können. Die aktuelle Dokumentation listet Windows Server 2022 und 2025 als unterstützte Node-Betriebssysteme.
Zustand, Dateisystem und Konfiguration migrieren
Ein Container-Dateisystem ist kein dauerhafter Datenspeicherort — wird ein Pod ersetzt, können beschreibbare Daten in der Container-Layer verschwinden. Klassifizieren Sie jeden Pfad als schreibgeschützten Inhalt, temporäre Daten, Cache, Log, Konfiguration oder persistente Geschäftsdaten, und ordnen Sie ihn dann bewusst zu:
Testen Sie das tatsächliche Verhalten eines gemeinsam genutzten Legacy-Verzeichnisses, bevor Sie es auf neuem Storage voraussetzen — Datei-Locking, Groß-/Kleinschreibung, symbolische Links, atomares Umbenennen und maximale Pfadlänge können sich alle unterscheiden.
Health-Checks, Graceful Shutdown und Session-Zustand
Eine Startup-Probe schützt eine langsam initialisierende Legacy-App davor, von gewöhnlichen Liveness-Checks beendet zu werden, bevor sie bereit ist. Eine Readiness-Probe sollte bestätigen, dass die App sicher Traffic empfangen kann — vermeiden Sie es, sie von jedem optionalen externen Dienst abhängig zu machen, sonst entfernt ein kleiner Ausfall jedes Replikat aus dem Dienst. Eine Liveness-Probe sollte Zustände erkennen, die einen Neustart erfordern, nicht einen Ausfall einer entfernten Datenbank, der eine Neustartschleife über alle Replikate hinweg auslösen könnte.
Beim Herunterfahren sollte die Anwendung aufhören, neue Arbeit anzunehmen, laufende Arbeit abschließen oder einen Checkpoint setzen, Verbindungen schließen und innerhalb des Termination-Zeitfensters beenden — testen Sie das tatsächliche Beenden, statt es einfach anzunehmen.
Session-Zustand
Eine Webanwendung, die Sessions im Arbeitsspeicher hält, kann über Replikate hinweg fehlschlagen. Optionen sind Session Affinity als Übergangslösung, Redis- oder datenbankgestützte Sessions oder zustandslose Tokens — Affinity kann den Übergang unterstützen, sollte eine Resilienzanforderung aber nicht dauerhaft verdecken.
Migration von Datenbank und geplanten Aufgaben
Die Trennung von Anwendungs- und Datenbankmigration verringert das Risiko — eine praktische erste Phase containerisiert oft die Anwendung, während die etablierte Datenbank beibehalten wird, und adressiert die Datenbankmodernisierung in einer späteren Phase.
Erfassen Sie Scheduler-Jobs des Betriebssystems, Scheduler-Jobs der Datenbank und anwendungsinterne Zeitpläne, und ordnen Sie jeden einem CronJob, Job, Queue-Worker oder einer externen Workflow-Plattform zu — und verhindern Sie doppelte Ausführung während des Cutovers.
Nutzen Sie wo möglich das Expand-and-Contract-Muster für Datenbankmigrationen: rückwärtskompatibles Schema hinzufügen, die kompatible Anwendung ausrollen, Daten migrieren und veraltetes Schema erst später entfernen. Kombinieren Sie keine unumkehrbare Datenbankmigration mit einem ungetesteten Anwendungs-Rollout.
Migrationsansätze
Planung von Cutover und Rollback
Ein Cutover-Plan sollte den Change-Freeze, das finale Backup, die Datensynchronisierung, Validierung, die Stufen der Traffic-Umschaltung, Monitoring und — entscheidend — einen Rollback-Auslöser und eine Frist definieren.
Häufige Fehler bei der Legacy-Kubernetes-Migration
Das reproduziert möglicherweise nur den alten Server, ohne die Architektur zu verbessern. Klassifizieren und trennen Sie Dateien bewusst.
Die Anwendung kann bei Neustart, Upgrade, Scaling oder Wiederherstellung fehlschlagen. Testen Sie Lifecycle-Ereignisse.
Nutzer können Sessions verlieren oder inkonsistentes Verhalten erleben. Beheben oder verwalten Sie den Session-Zustand zuerst explizit.
Ein Datenbankausfall kann jede Anwendungsinstanz wiederholt neu starten. Entwerfen Sie Probes sorgfältig.
Das kombiniert mehrere risikoreiche Änderungen. Trennen Sie sie, wo praktikabel.
Jede Umgebungsänderung erfordert einen Rebuild und kann Secrets offenlegen. Externalisieren Sie die Konfiguration.
Reports, Cleanup- oder Integrationsjobs können nach der Migration unbemerkt stoppen. Erfassen Sie Zeitpläne auf Host-Ebene.
Reale Workloads können Probleme aufdecken, die Tests übersehen haben. Behalten Sie den Rollback, bis die Abnahmekriterien erfüllt sind.
Checkliste zur Legacy-Anwendungsmigration
0 / 24Häufig gestellte Fragen
Ja. Viele ältere Anwendungen können nach der Containerisierung laufen, aber die Eignung hängt von Betriebssystem-Support, Zustand, Netzwerk, Konfiguration, Lizenzierung und Wiederherstellungsanforderungen ab.
Nein. Containerisierung verpackt die Anwendung. Modernisierung erfordert oft zusätzlich externalisierten Zustand, automatisiertes Deployment, Health-Checks, Sicherheitsänderungen und ein betriebliches Neudesign.
Er kann, wenn Kubernetes Deployment oder Betrieb verbessert. Die Anwendung muss nicht in Microservices aufgeteilt werden, nur um Kubernetes zu nutzen.
Nutzen Sie ein Deployment, wenn Instanzen austauschbar sind. Nutzen Sie ein StatefulSet, wenn stabile Identität, geordneter Betrieb oder replikaspezifischer persistenter Speicher erforderlich sind.
Ja. Kubernetes unterstützt Windows-Worker-Nodes, abhängig von unterstützten Windows-Server-Versionen, Netzwerk, Container-Runtime und Anwendungskompatibilität.
Nein. Windows-Worker können einem Cluster beitreten, aber die Kubernetes Control Plane läuft auf Linux.
Die aktuelle Kubernetes-Dokumentation gibt an, dass Kubernetes Windows-Container mit Hyper-V-Isolation nicht unterstützt.
Beschreibbare Daten in der Container-Layer sind kein verlässlicher persistenter Speicherort. Nutzen Sie für benötigte Daten ein PersistentVolume, Objektspeicher, eine Datenbank oder einen anderen freigegebenen externen Speicher.
Ja. Kubernetes kann Packaging und Deployment trotzdem verbessern, aber ein einzelnes Replikat bietet keine Hochverfügbarkeit für die Anwendung.
Nicht zwangsläufig. Die Datenbank auf ihrer bestehenden Plattform zu belassen oder zu einem Managed Service zu verschieben, kann das Migrationsrisiko verringern.
Belassen Sie sie auf einer VM, wenn sie von nicht unterstützten Betriebssystemen, Hardware, interaktiver Desktop-Nutzung, Hersteller-Zertifizierung oder maschinenspezifischem Verhalten abhängt, das Kubernetes nicht verbessert.
Es gibt keine universelle Methode. Phasenweises Replatforming, Blue-Green-Migration und parallele Validierung verringern oft das Risiko, aber die Wahl hängt von der Zustandssynchronisierung und geschäftlichen Rahmenbedingungen ab.
Bewusst modernisieren
Kubernetes kann Images, Konfiguration, Deployment, Monitoring, Sicherheitskontrollen, Backup und Wiederherstellung für eine Legacy-Anwendung standardisieren. Es kann keine architektonischen Einschränkungen beseitigen, die in der Anwendung selbst bestehen bleiben.
Erfassen Sie den Workload, finden Sie jeden Zustandsort, dokumentieren Sie Betriebssystem- und Lizenzierungsabhängigkeiten, und entscheiden Sie, ob Sie rehosten, replatformen, refactoren, beibehalten, ersetzen oder abschalten. Bauen Sie einen Proof of Concept rund um die schwierigsten Ausfall- und Wiederherstellungsszenarien, und migrieren Sie erst, wenn Kubernetes eine messbare Verbesserung schafft — nicht, um einen alten Server als Pod zu verkleiden.