Modern verpackt

von Martin Loschwitz

Klassische Virtualisierung gerät gegenüber dem Verpacken von Anwendungen in Container immer stärker ins Hintertreffen. Denn nur die wenigsten Workloads benötigen heute noch eine komplett virtualisierte Umgebung. Admins stehen also vor der Herausforderung, virtualisierte Workloads in Richtung Kubernetes oder OpenShift zu bewegen. Diese Migration geht allerdings mit einem neuen IT-Betriebsmodell einher und erfordert daher eine detaillierte Planung.

IT-Infrastrukturen funktionieren heute kaum noch ohne Virtualisierung – Plattformen wie VMware vSphere, KVM oder Hyper-V haben über Jahre hinweg den Standard gesetzt. Anwendungen laufen in virtuellen Maschinen, sauber voneinander getrennt, jeweils mit eigenem Betriebssystem, eigenem Kernel und klar abgegrenzten Ressourcen. Dieses Modell hat sich bewährt, denn es ist stabil, gut verstanden und bietet eine hohe Isolation zwischen Workloads. Die Anzahl der wirksamen Angriffe, die zum Ausbruch aus einer per Hypervisor abgesicherten Instanz geführt haben, ist gering.

Gleichzeitig stößt klassische Virtualisierung zunehmend an ihre Grenzen. Der Grund liegt weniger in der Technik selbst als in den Anforderungen moderner Anwendungen. Microservices, Continuous Deployment, horizontale Skalierung und kurze Release-Zyklen passen nur bedingt zu einem Modell, das stark auf langlebige, vergleichsweise statische Instanzen setzt. Zudem haben (para)virtualisierte Instanzen einen erheblichen Nachteil: Da sie stets vollständige Computer simulieren, beansprucht dieser Prozess erhebliche Ressourcen. Das mag bei kleinen Setups kaum ins Gewicht fallen, doch fünf bis zehn Prozent Overhead über eine Flotte von etlichen Servern hinweg bedeuten hohe Investitionen ohne echten technischen Gegenwert.

Nicht zuletzt steigen die Kosten für Virtualisierung kontinuierlich. Wer VMware in der Infrastruktur nutzt, sieht sich seit einiger Zeit den Preisänderungen von Broadcom ausgesetzt und sucht nach Alternativen. Doch statt beispielsweise nach Proxmox zu migrieren, verbinden viele Unternehmen die Ablösung der Virtualisierung mit einer umfassenden Überarbeitung ihrer IT und prüfen den Einsatz von Containern.

Architekturunterschiede zwischen VM und Container

Salopp spricht mancher von "Con- tainer-Virtualisierung". Ganz zutreffend ist der Begriff einerseits nicht, denn eine klassische Virtualisierung involviert immer einen Hypervisor – dieser fehlt jedoch in Containern. Ganz falsch ist die Bezeichnung andererseits auch nicht, da bei Containern durchaus Komponenten virtualisiert sind, etwa das Dateisystem oder die Ansicht der Systemprozesse. Der zentrale Unterschied zwischen VMs und Containern liegt im Umgang mit dem Betriebssystem. Während jede VM ein vollständiges OS mitbringt, teilen sich Container den Kernel des Hosts mit diesem. IT-Verantwortliche kapseln lediglich Anwendung, Laufzeitumgebung und Abhängigkeiten über Control Groups (Cgroups) und Namespaces vom Rest des Systems ab.

Das hat unmittelbare Auswirkungen auf den Ressourcenbedarf. Container starten in Sekundenbruchteilen, benötigen deutlich weniger RAM und verursachen weniger Overhead bei CPU und Storage. Nur das Container-Abbild belegt hier Ressourcen doppelt. In der Regel sind diese Images jedoch viel kleiner als die virtuellen Laufwerke virtueller Instanzen, da ein eigener Kernel fehlt. Wo Admins auf einem Host vielleicht zehn oder zwanzig VMs sinnvoll betreiben können, lassen sich so oft Hunderte Container realisieren. Dieser Unterschied ist nicht nur quantitativ, sondern auch qualitativ relevant. Anwendungen lassen sich feiner granulieren. Statt eine große monolithische VM zu betreiben, zerlegt die IT eine Anwendung in mehrere Container, die jeweils einen klar definierten Zweck erfüllen.

Container-Orchestrierung im Vergleich zum Einzelbetrieb

Der zweite große Unterschied zwischen VMs und Containern betrifft den Betrieb. Virtuelle Maschinen verwalten IT-Profis typischerweise einzeln – selbst dann, wenn sie Teil eines Clusters sind. Zwar existieren mit Produkten wie vCenter oder OpenStack Managementebenen, doch die Steuerung bleibt vergleichsweise grobgranular. Container hingegen sind ohne Orchestrierung praktisch nicht sinnvoll nutzbar. Genau hier kommt Kubernetes zum Einsatz. Das Werkzeug kümmert sich nicht nur darum, Container zu starten, sondern übernimmt auch Überwachung, Neustarts, Skalierung und Vernetzung.

Ein Beispiel: Fällt eine VM aus, muss ein Administrator eingreifen oder ein externes HA-System reagieren. In Kubernetes ist das Verhalten deklarativ beschrieben. Der IT-Verantwortliche definiert, dass eine Anwendung in drei Instanzen laufen soll – und Kubernetes sorgt selbstständig dafür, dass die Infrastruktur diesen Zustand einhält. Das verschiebt die Verantwortung weg vom manuellen Betrieb einzelner Systeme hin zur Beschreibung eines gewünschten Zustands, den die Plattform kontinuierlich durchsetzt.

Mit dieser Verschiebung ändern sich auch die Anforderungen an die zugrunde liegende Infrastruktur. Während klassische Virtualisierung auf stabile Hosts und klar definierte Netzwerke setzt, verlangt Kubernetes Flexibilität. Workloads bewegen sich dynamisch im Cluster, IP-Adressen ändern sich und Services werden über Abstraktionen angesprochen statt über feste Hosts. Netzwerk, Storage und Security müssen sich diesem Modell anpassen.

Planung der Zielarchitektur

Der Umstieg von VMs auf Container ist selten ein abrupter Wechsel. Viel häufiger handelt es sich um eine schrittweise Evolution. Bestehende Anwendungen bleiben zunächst unverändert, während IT-Verantwortliche neue Workloads bereits containerisieren. Parallel entsteht eine Umgebung, die beide Welten verbindet. Damit steht eine strategische Frage im Raum: Wie lässt sich eine bestehende Virtualisierungsumgebung so weiterentwickeln oder umbauen, dass sie den Anforderungen moderner Container-Plattformen gerecht wird? Welche Schritte sind notwendig, um Workloads kontrolliert und ohne Risiko zu migrieren?

Die Antwort darauf ist komplexer, als es auf den ersten Blick scheint. Der Wechsel betrifft nicht nur die Laufzeitumgebung, sondern die gesamte Architektur – vom Netzwerk über Storage bis hin zu den Betriebsprozessen. Admins stehen vor mehreren Umstellungen: Sie müssen Anwendungen in Container verpacken, parallel eine Orchestrierungsumgebung aufbauen, beide Welten verheiraten und passende Konzepte für Betrieb und Wartung entwickeln. Bei guter Vorbereitung ist diese Aufgabe jedoch zu meistern.

Bevor Sie den ersten Container bauen oder einen Kubernetes-Cluster installieren, entscheidet die Planungsphase über den Erfolg. Der Wechsel hin zu einer Container-basierten Infrastruktur ist kein rein technischer Austausch von Werkzeugen. Grundlegende Annahmen darüber, wie Anwendungen kommunizieren und welche Anforderungen sie an ihre Umgebung stellen, ändern sich.

Der erste Schritt besteht darin, die bestehende Landschaft genau zu analysieren. In vielen Virtualisierungsumgebungen sind über Jahre Anwendungen gewachsen, die fest mit ihrer Umgebung verwoben sind. Sie laufen in virtuellen Maschinen, die oft gleichzeitig Applikationsserver, Datenbank und Dateisystem beherbergen. Konfigurationen liegen lokal auf dem System, Pfade sind fest verdrahtet und es existieren implizite Abhängigkeiten ohne Dokumentation. Solche Konstrukte lassen sich nicht ohne Vorarbeit in Container verpacken.

Die Erfahrung zeigt: Wer versucht, bestehende VMs eins zu eins in Container zu überführen, wird die Vorteile von Kubernetes kaum nutzen. Stattdessen ist es notwendig, Anwendungen in ihre Bestandteile zu zerlegen. IT-Profis müssen prüfen, welche Komponenten sich sinnvoll containerisieren lassen und welche zunächst in ihrer bestehenden Form weiterlaufen.

Trennung von Stateful- und Stateless-Workloads

Eine Kernfrage bei der Migration ist die nach Stateful- und Stateless-Workloads. Während klassische Virtualisierung davon ausgeht, dass eine Instanz dauerhaft existiert und ihren Zustand lokal hält, folgt Kubernetes einem anderen Prinzip. Container sind grundsätzlich austauschbar; ihr Zustand wird außerhalb des Containers verwaltet. Diese Trennung ist essenziell, da sie der Plattform erlaubt, Workloads beliebig zu verschieben, neu zu starten oder zu skalieren. Anwendungen mit starken lokalen Zustandsbindungen müssen Sie daher anpassen oder isoliert betrachten.

Besonders deutlich wird dieser Unterschied bei Datenbanken und Dateisystemen. In einer VM liegen Daten oft lokal auf einem virtuellen Datenträger. Kubernetes hingegen stellt Speicher über abstrahierte Schnittstellen bereit. Anwendungen fordern Speicher an, ohne den physischen Ort zu kennen. Das erfordert eine Storage-Infrastruktur, die dynamisch arbeitet, sich in die Plattform integriert und gleichzeitig Persistenz garantiert. Wer bestehende SAN- oder NAS-Konzepte unverändert übernimmt, wird feststellen, dass diese nicht zu den Anforderungen einer Container-Plattform passen.

Ähnlich verhält es sich mit dem Netzwerk: In klassischen Umgebungen planen IT-Verantwortliche Netze, segmentieren diese und weisen sie statisch zu. Virtuelle Maschinen erhalten feste IP-Adressen. Kubernetes hingegen löst diese Strukturen weitgehend auf. Pods erhalten dynamische IP-Adressen, die von außen oft nicht direkt ansprechbar sind. Das API-Objekt "Service" abstrahiert die Erreichbarkeit von Anwendungen; die tatsächliche Platzierung eines Workloads bleibt für den Nutzer unsichtbar. Anwendungen müssen daher über logische Namen kommunizieren. Wer Software betreibt, die fest verdrahtete IP-Adressen erwartet, muss diese zwingend anpassen.

Auswahl der passenden Distribution

Ein oft unterschätzter Punkt ist die Wahl der Zielplattform. Kubernetes ist kein fertiges Produkt, sondern ein Baukasten. Die konkrete Ausprägung – ob als schlanke Installation mit "kubeadm", als umfassende Plattform wie Open-Shift oder als gemanagtes Produkt in der Cloud – beeinflusst den späteren Betrieb erheblich. Während eine minimalistische Installation maximale Flexibilität bietet, verlangt sie Eigenleistung bei Monitoring, Logging, Security und Lifecycle-Management. Eine integrierte Plattform nimmt Ihnen viele dieser Aufgaben ab, gibt dafür aber gewisse Rahmenbedingungen vor.

Die Entscheidung für eine konkrete Kubernetes-Distribution ist nicht nur eine technische, sondern auch eine organisatorische Frage. Sie hängt davon ab, welche Kompetenzen im Team vorhanden sind, wie stark Sie sich auf externe Unterstützung verlassen möchten und welche Anforderungen an Support sowie Stabilität bestehen. Wer hier vorschnell entscheidet, läuft Gefahr, später mit einer Infrastruktur zu arbeiten, die entweder zu komplex oder zu eingeschränkt ist.

Schließlich darf das Betriebsmodell selbst nicht außer Acht bleiben. Der Umstieg auf Kubernetes verändert die Art und Weise, wie Admins Systeme betreiben. Statt einzelne Instanzen zu pflegen, beschreibt der Betreiber einen gewünschten Zustand, den die Plattform kontinuierlich herstellt. Änderungen erfolgen nicht mehr durch direkte Eingriffe auf den Systemen, sondern durch Anpassung von Konfigurationsdefinitionen. Dieser Ansatz verlangt ein Umdenken, das weit über die Technik hinausgeht: Prozesse, Verantwortlichkeiten und die Zusammenarbeit zwischen Entwicklung und Betrieb müssen sich anpassen. Nach entsprechender Recherche muss ein Unternehmen eine Entscheidung zur K8s-Distribution treffen.

Aufbau der Zielinfrastruktur

Nach der Entscheidung für eine Plattform beginnt der Aufbau der Zielumgebung. Dieser startet meist mit der Hardware – selbst wenn Kubernetes zunächst auf bestehenden Virtualisierungsplattformen laufen soll. Zwar ist es grundsätzlich möglich, Kubernetes auf VMware oder KVM zu betreiben, doch auch hier gelten andere Anforderungen als bei klassischen Workloads.

Nodes sollten möglichst homogen sein, ausreichend CPU- und RAM-Reserven bieten und vor allem über performanten lokalen Storage verfügen, wenn Software-defined Storage zum Einsatz kommt. Wer Ceph per Rook oder vergleichbare Produkte plant, muss diese Anforderungen von Beginn an berücksichtigen, da sich Storage später nur mit erheblichem Aufwand nachrüsten lässt.

Auf dieser Grundlage folgt die Installation der eigentlichen Kubernetes-Plattform. Ob dies über eine Distribution wie OpenShift, Rancher oder eine eigene Zusammenstellung geschieht, ist technisch zweitrangig. Entscheidend ist, dass Sie die Infrastruktur vollständig und konsistent aufbauen. Dazu gehören neben der Control Plane auch die Worker-Nodes, ein funktionierendes Zertifikatsmanagement sowie eine saubere Integration von Authentifizierung und Zugriffskontrolle. Gerade dieser Punkt wird in frühen Test- installationen oft vernachlässigt, was sich spätestens im produktiven Betrieb rächt.

Parallel dazu erfolgt die Einbindung des Speichers. Kubernetes bringt von Haus aus kein eigenes Storage-Produkt mit, sondern verlässt sich auf externe Systeme, die Sie über das API "Container Storage Interface" anbinden. In der Praxis bedeutet das, dass IT-Profis entweder ein bestehendes Storage-System integrieren oder eine neue In- frastruktur bereitstellen, die sich dynamisch in Kubernetes einfügt. Typische Kandidaten sind hier das Ceph-basierte Rook, Cloudstorage (vor allem für Blob-Speicher per S3) oder CSI-Treiber für bestehende SAN- oder NAS-Systeme.

Beim Bau einer Kubernetes-Plattform ist das Netzwerk wie zuvor beschrieben zu beachten. Hier ist jedoch weniger Vorarbeit möglich. Cilium, der aktuelle Standard für SDN in Kubernetes, lässt sich mittels weniger Befehle ausrollen. Wichtig ist lediglich, dass Sie vorab ein Netzwerk vorsehen, aus dem sich später Service-IP-Adressen für die Kommunikation mit der Außenwelt nutzen lassen – eine Art Vermittlernetz zwischen den Welten.

Sind Compute, Storage und Netzwerk eingerichtet, folgt die Integration weiterer Basisdienste. Monitoring, Logging und gegebenenfalls ein zentrales Identity-Management gehören in produktiven Umgebungen von Anfang an dazu. Auch wenn diese Komponenten für die Migration eines einzelnen Workloads zunächst nicht notwendig erscheinen, sind sie essenziell für den späteren Betrieb. Ohne sie fehlt die nötige Transparenz, um Probleme zu erkennen und zu beheben.

Am Ende dieser Phase steht eine funktionsfähige Plattform: Kubernetes ist installiert, Storage lässt sich dynamisch bereitstellen, das Netzwerk arbeitet stabil und grundlegende Betriebswerkzeuge sind vorhanden. Erst auf dieser Basis ist es sinnvoll, mit der eigentlichen Migration von Anwendungen zu beginnen.

Workload-Migration am Beispiel MariaDB

Abhängig von Art und Wesen der umzuziehenden Anwendungen kann die Migration leicht oder komplex ausfallen. In der Praxis ist dieser Schritt weniger ein einmaliger Umzug als vielmehr ein kontrollierter Übergang von einem Betriebsmodell in ein anderes. Besonders deutlich wird das bei zustandsbehafteten Anwendungen wie Datenbanken. Während sich Stateless-Services oft einfach neu ausrollen lassen, erfordern Datenbanken eine saubere Datenmigration und ein exakt geplantes Umschalten. Die Herausforderungen beginnen bereits vor dem eigentlichen Umzug: Admins müssen klären, ob die Zielanwendung bereits in Container-Form zur Verfügung steht.

Bei Standardanwendungen ist dies meist der Fall. Werkzeuge wie MariaDB oder PostgreSQL stellen deren Entwickler ebenso als standardisierte Container bereit wie typische Userspace-Anwendungen wie Nginx, Tomcat oder Python-Laufzeit- umgebungen. Bei Eigenentwicklungen steht vor dem Betrieb zunächst das Erstellen der Container. Das Verpacken von Anwendungen ist in den vergangenen Jahren einfacher geworden.

Der Arbeitsablauf unterscheidet sich zwischen den Laufzeitumgebungen Docker und Podman nur im Detail: Bei Ersterem erstellen Sie ein "Dockerfile", bei Letzterem ein "Containerfile". Die Syntax beider Formate ist beinahe deckungsgleich. IT-Profis sollten hier auf die Unterstützung der Entwicklung zurückgreifen und fertige Container anfordern, wie es früher bei RPM- oder Deb-Paketen üblich war. Der Bau von Containern lässt sich heute gut in CI/CD-Systeme integrieren. Wichtig ist ergänzend eine lokale Container-Registry wie etwa Harbor, Quay oder Nexus, aus der Kubernetes die Abbilder abruft.

An dieser Stelle ist eine Warnung angebracht: Von vielen Anwendungen existieren im Netz Container mit Zusatzfunktionen, die jedoch nicht die offiziellen Abbilder sind. Wir raten dringend davon ab, beliebige Abbilder von Docker Hub oder aus Drittanbieterquellen zu verwenden. Diese stellen in Bezug auf Security eine Black Box dar. Es kommt vor, dass solche Images neben der eigentlichen Anwendung auch Schadsoftware wie Bitcoin-Miner enthalten.

Als mittelkomplexes Beispiel dient eine MariaDB-Instanz, die bislang in einer VM läuft. Von MariaDB existiert ein offizielles Container-Abbild, das wir direkt nutzen können. Ziel ist es, diese Datenbank künftig als Pod in Kubernetes inklusive persistentem Speicher zu betreiben.

Zunächst müssen Sie die bestehende In-stanz in einen konsistenten Zustand bringen, indem Sie Schreibzugriffe stoppen oder minimieren und anschließend ein vollständiges Backup erstellen. Der klassische Weg führt dabei über einen Dump:

Alternativ bietet sich bei größeren Installationen ein physisches Backup an, doch für den Einstieg genügt meist ein simpler Dump. Entscheidend ist, dass Sie die Daten zu einem definierten Zeitpunkt konsistent sichern. Ändern sich die Daten während des Vorgangs, ist der Dump in sich inkonsistent.

Kubernetes für MariaDB vorbereiten

Parallel dazu bereiten Sie die Zielumgebung in Kubernetes vor. Das umfasst einen PersistentVolumeClaim (PVC), der den Speicher für die Datenbank bereitstellt:

Dieser Claim sorgt dafür, dass Kubernetes dynamisch ein Volume bereitstellt, das der Pod später nutzt. Ob dieses Volume auf Ceph, einem SAN oder lokalem Storage basiert, bleibt für die Anwendung transparent. Darauf aufbauend folgt das Deployment der MariaDB-Instanz mittels der Ressourcendefinition im Listing.

In einer Air-Gapped-Umgebung ist die Referenz auf das Container-Abbild ("image") so anzupassen, dass sie auf die lokale Registry verweist. Mit dieser Definition läuft die Datenbank zunächst leer, ist aber vollständig in die Kubernetes-Infrastruktur integriert.

Migration der Datenbestände

Im nächsten Schritt erfolgt die eigentliche Datenübernahme. Dafür existieren mehrere Wege und der einfachste besteht darin, den zuvor erstellten Dump in den neuen Pod zu importieren. Dazu kopieren Sie die Datei in den Container oder stellen sie über ein Volume bereit. Ein typischer Ablauf sieht wie folgt aus:

Alternativ lässt sich der Import direkt ausführen, ohne die Datei dauerhaft im Container zu speichern. Wichtig ist in jedem Fall, dass die Zielinstanz während des Imports stabil läuft und keine konkurrierenden Schreibzugriffe stattfinden. Bei größeren Datenmengen oder produktiven Umgebungen empfiehlt sich ein abgestufter Ansatz: Sie spielen zunächst einen initialen Dump ein und nutzen anschließend eine kurze Downtime, um die letzten Änderungen zu synchronisieren. Dieses Vorgehen minimiert die Unterbrechung für die Anwender.

Umzug der Anwendungskomponenten

Sobald die Datenbank im Cluster läuft und die Daten vollständig vorhanden sind, folgt die Umschaltung der Anwendung. In klassischen Umgebungen bedeutet das oft, dass die Applikation eine neue Zieladresse für die Datenbank erhält. Kubernetes abstrahiert diesen Schritt in der Regel über das Objekt "Service":

Die Anwendung greift dann nicht mehr direkt auf eine feste IP-Adresse oder einen Host zu, sondern auf den Service-Namen "mariadb". Kubernetes sorgt intern dafür, dass die Anfrage beim richtigen Pod landet. Das geschieht über das in Kubernetes integrierte "coredns".

Oft ist es sinnvoll, die Anwendung zunächst parallel zur alten Datenbank laufen zu lassen und den Zugriff gezielt umzuschalten. Das kann über Konfigurationsänderungen, Feature Flags oder DNS-Einträge erfolgen. Erst wenn sichergestellt ist, dass die neue Instanz stabil arbeitet, nehmen Sie die alte VM endgültig außer Betrieb. Zu beachten ist dabei, dass in diesem Fall eine Nachmigration der Daten stattfinden muss, die sich zwischenzeitlich geändert haben.

Welcher Aufwand notwendig ist, um die zugreifende Anwendung zu portieren, hängt vom Einzelfall ab. Liegt ein fertiges Container-Abbild vor, genügt es, dieses in eine Pod-Definition analog zu jener von MariaDB zu verpacken, die Konfiguration für den Datenbankzugang anzupassen und die Anwendung ebenfalls per Service erreichbar zu machen. Soll die Anwendung von außerhalb der Kubernetes-Plattform erreichbar sein, müssen Sie zusätzlich einen Gateway-API-Controller ausrollen und diesen durch einen Loadbalancer ergänzen. Der letzte Schritt besteht darin, Kubernetes aus dem beschriebenen Transfer-Netz IP-Adressen zuzuweisen, die es für die Anbindung der App nach außen nutzen darf.

Betriebliche Besonderheiten

Die Migration zeigt exemplarisch, wie sich der Betrieb in Kubernetes von klassischer Virtualisierung unterscheidet. Die Datenbank läuft nicht mehr auf einem festen Host, sondern als Pod, den wir bei Bedarf neu starten oder verschieben können. Persistenz entsteht nicht durch den Server selbst, sondern durch das angebundene Storage.

Auch das Deployment erfolgt nicht mehr manuell, sondern deklarativ. Änderungen an der Konfiguration werden über YAML-Dateien beschrieben und von Kubernetes umgesetzt. Das erfordert ein Umdenken, bietet aber langfristig Vorteile bei Reproduzierbarkeit und Automatisierung. Gerade bei zustandsbehafteten Anwendungen lohnt es sich, diesen Schritt bewusst zu planen und nicht als bloßes "Lift-and-Shift" zu betrachten. Wer Datenbanken unverändert in Container verpackt, verschenkt Potenzial. Wer hingegen die Plattformmechanismen konsequent nutzt, schafft eine Infrastruktur, die sich flexibler betreiben lässt als klassische Umgebungen.

Netzwerk und Zugang validieren

Ist der Umzug des Workloads abgeschlossen, beginnt die Phase, in der sich der Erfolg im Alltag entscheidet. Eine Anwendung gilt nicht schon als sauber migriert, weil sie in Kubernetes läuft. Entscheidend ist, dass Anfragen die neue Instanz zuverlässig erreichen und alte Pfade stillgelegt oder umgebogen sind.

In klassischen Umgebungen greifen Nutzer häufig direkt über feste Hostnamen oder IP-Adressen auf Dienste zu. In Kubernetes steht vor dem Pod in der Regel ein Service, oft zusätzlich ein Ingress oder ein externer Loadbalancer. Entsprechend müssen IT-Verantwortliche sicherstellen, dass die Netzwerkpfade korrekt auf das neue Ziel zeigen. Das geschieht über den Loadbalancer und die Service-IP-Adresse.

Auch DNS spielt eine zentrale Rolle: Wurde die virtualisierte Anwendung bislang unter einem festen Namen angesprochen, sollte dieser erhalten bleiben, damit Nutzer vom Umzug nichts bemerken. Praktisch bedeutet das: Vor der Umschaltung ist der TTL-Wert des DNS-Eintrags zu reduzieren, damit sich die Änderung später schneller verbreitet.

Erst nach Wirksamwerden der Änderung greifen alle Clients sicher auf die neue Instanz zu. Der eigentliche Wechsel sollte in einem definierten Wartungsfenster oder anhand eines kontrollierten Rollout-Plans stattfinden. Nach der Umschaltung dürfen Sie die alte virtuelle Instanz nicht einfach vergessen. Sie ist entweder sauber stillzulegen oder so zu isolieren, dass keine produktiven Zugriffe mehr auf ihr landen. Bleibt sie parallel aktiv, entsteht die Gefahr eines Split-Brain-Zustands, in dem Anfragen verteilt auf der alten und neuen Instanz landen. Gerade bei Datenbanken ist das problematisch.

Ebenso wichtig ist die Anpassung des Monitorings. Prüfpunkte, Alarmierungen und Logging-Pfade müssen Sie auf die neue Kubernetes-basierte Anwendung umstellen. Das gilt auch für Backups, Security-Scans und die Kapazitätsüberwachung. Erst wenn diese Begleitmechanismen migriert sind, ist das Projekt betrieblich abgeschlossen.

Fazit

Der Weg von klassischer Virtualisierung hin zu einer Containerbasierten Infrastruktur mit Kubernetes ist kein einfacher Umzug, sondern eine grundlegende Veränderung des Betriebsmodells. Während VMs Anwendungen in klar abgegrenzten Einheiten kapseln, setzt Kubernetes auf Dynamik, Austauschbarkeit und deklarative Steuerung. Genau darin liegt der größte Gewinn.

Eine Migration lässt sich nicht mit einem simplen "Lift-and-Shift" erledigen. Wer Workloads unverändert in Container verpackt, nutzt die Vorteile der Plattform nicht aus. Erst durch die Anpassung an das Kubernetes-Modell – die Trennung von Anwendung und Infrastruktur sowie die Nutzung von Services und automatisiertem Storage – entfaltet sich das volle Potenzial.

Dies erfordert sorgfältige Planung: Die Analyse der Bestandslandschaft, der Aufbau einer tragfähigen Zielplattform und eine saubere Datenmigration sind zwingende Voraussetzungen. Besonders bei zustandsbehafteten Anwendungen entscheidet die Qualität der Vorbereitung über den Erfolg. Ist der Übergang jedoch gelungen, ermöglicht Kubernetes eine flexiblere Skalierung und konsistentere Betriebsprozesse. Unterm Strich zeigt sich: Der Umstieg lohnt sich für Organisationen, die bereit sind, ihr Betriebsmodell anzupassen. Kubernetes ist kein besserer Hypervisor, sondern ein anderer Ansatz, Infrastruktur umzusetzen.

Workloads aus VMs in Container migrieren