OpenStack ist keine gescheiterte Plattform. Es ist eine Plattform, deren Betriebskosten in knappen Fachkräften bezahlt werden. Diese Seite beschreibt, wann dieser Tausch nicht mehr aufgeht, was der Wechsel auf eine Kubernetes-native Steuerebene Dienst für Dienst bedeutet — und welche Teile wirklich schwierig sind.
Passt zu: Ænix Public Cloud Platform, wenn die OpenStack-Cloud an externe Kunden verkauft wird (Hoster, MSPs, Telcos, nationale Betreiber); Ænix Private Cloud Platform, wenn sie interne Verbraucher unter DORA-, NIS2- oder sektorspezifischen Auflagen bedient.
Wann Sie nicht migrieren sollten
Das gehört an den Anfang, weil die meisten Texte zu OpenStack es auslassen.
Bleiben Sie auf OpenStack, wenn Sie ein funktionierendes Betriebsteam haben, das den Release-Zyklus kennt, Sie auf einem gepflegten Release stehen, Ihr Upgrade-Pfad geübt statt theoretisch ist und Sie genug von der Dienstepalette nutzen — Ironic für Bare Metal, Octavia, Manila, Designate, Barbican —, dass ein Ersatz den Neubau mehrerer dieser Dienste bedeuten würde. OpenStack kann Dinge, die Kubernetes-native Plattformen nicht können: Multi-Hypervisor-Compute, ausgereiftes Bare-Metal-Provisioning und eine API-Oberfläche, die ein Jahrzehnt an Werkzeugen bereits spricht.
Der Grund für eine Migration ist betrieblich, nicht technisch-überlegen. Er wird stark, wenn:
- Upgrades hängen. Die Umgebung liegt zwei oder mehr Releases zurück, das Upgrade ist ein Projekt statt eines Wartungsfensters, und jedes Aufschieben verschlimmert das nächste.
- Das Team ein Bus-Faktor-Problem ist. Ein oder zwei Personen tragen die gesamte Steuerebene. OpenStack-Kompetenz wird vom Markt nicht in dem Tempo nachgeliefert, in dem sie abfließt.
- Der genutzte Dienstumfang schmal ist. In der Praxis laufen viele Clouds auf Keystone, Nova, Glance, Cinder, Neutron und Horizon — und sonst nichts. Diesen Umfang ersetzt eine Kubernetes-Steuerebene ohne Verlust.
- Container bereits die Mehrheit der Last stellen. Sie betreiben Kubernetes auf OpenStack-VMs, bezahlen zwei Steuerebenen und debuggen über beide hinweg.
- Sich die Distributionsökonomie geändert hat. Das herstellergestützte OpenStack-Abonnement wurde zu einem Preis verlängert, der nicht mehr zum Wert des Supports passt.
Trifft nichts davon zu, lautet die ehrliche Empfehlung: bleiben und stattdessen in die Upgrade-Pipeline investieren.
Zuordnung Dienst für Dienst
Hier entscheidet sich der Umfang. Jedes OpenStack-Projekt hat ein Ziel, kein Ziel oder einen Neuentwurf.
| OpenStack | Ziel in Cozystack | Charakter der Migration |
|---|---|---|
| Keystone (Identität, Domains, Projekte) | Tenant-CRD plus Kubernetes-RBAC, OIDC gegen Ihren bestehenden IdP | Neumodellierung. Projektbäume bilden sich nicht eins zu eins ab; die Mandantenhierarchie wird im Assessment entworfen. |
| Nova (Compute) | KubeVirt-VMs im selben Cluster wie Container | Mechanisch. Beide Seiten sind libvirt/KVM. |
| Glance (Images) | CDI-DataVolumes mit Object Storage als Quelle | Mechanisch. QCOW2 und raw kommen mit. |
| Cinder (Block) | LINSTOR/DRBD, oder das bestehende Ceph-Cluster über den Ceph-CSI-Treiber weiter nutzen | Mechanisch, wenn Ceph bleibt; Datenumzug bei Konsolidierung auf LINSTOR. |
| Neutron (Netzwerk) | Cilium (eBPF) mit L2-Announcements oder BGP; MetalLB, wo bereits Standard | Neuentwurf. Der schwierige Teil — siehe unten. |
| Swift / Ceph RGW (Object) | S3-kompatibler Object Storage auf der Plattform, oder RGW behalten | Meist behalten. Object-Endpunkte sind langlebig und kundensichtbar. |
| Octavia (Load Balancing) | Kubernetes-Services vom Typ LoadBalancer plus Ingress-Schicht | Neuentwurf. Die Semantik pro Mandant unterscheidet sich. |
| Ironic (Bare Metal) | Keine direkte Entsprechung | Lücke. Wenn Ironic tragend ist, behalten Sie es — oder diesen Teil von OpenStack. |
| Magnum (Kubernetes as a Service) | Mandanten-Kubernetes-Cluster mit gehosteten Steuerebenen | Vereinfachung. Genau darauf ist die Plattform gebaut. |
| Trove (DBaaS) | Managed-Datenbank-Anwendungen im Mandantenkatalog | Ersatz, keine Migration. Daten ziehen per Dump oder Replikat um. |
| Heat (Orchestrierung) | Helm plus GitOps-Reconciliation | Neubau. Heat-Templates lassen sich nicht konvertieren. |
| Horizon (Dashboard) | Cozystack-Mandanten-Dashboard | Ersatz. Schulen statt portieren. |
| Ceilometer / Gnocchi | Prometheus-kompatibler Metrik-Stack mit Langzeitspeicher | Ersatz. Abrechnungsanbindungen müssen umgehängt werden. |
Zwei Zeilen verdienen Nachdruck, weil dort Migrationen aus dem Ruder laufen.
Neutron ist der Neuentwurf. Mandantennetze, Router, Floating IPs, Security Groups und Provider-VLANs sind ein Adressierungs- und Policy-Modell, nicht bloß Verkabelung. Cilium erreicht dieselben Ergebnisse über andere Primitive: Network Policy statt Security Groups, LB-IPAM mit BGP oder L2-Announcements statt Floating IPs und L3-Agent. Kundensichtbare Adressen müssen den Umzug überleben oder nach einem Plan umnummeriert werden, dem Ihre Kunden zugestimmt haben. Planen Sie hier echte Entwurfszeit ein; das Überspringen ist der häufigste Grund für eine steckengebliebene OpenStack-Migration.
Heat und Horizon kommen nicht mit. Alles, was ein Mandant gegen die OpenStack-API automatisiert hat — Terraform-Provider, Heat-Stacks, interne Skripte —, wird gegen die Kubernetes-API neu geschrieben. Für eine interne Cloud sind das Schulungskosten. Für eine öffentliche Cloud mit API-nutzenden Kunden ist es eine Produktentscheidung mit Abkündigungsfrist, und die gehört an Tag eins in den Plan, nicht in Monat neun.
Ablauf der Migration
- Architektur-Review (2-4 Wochen). Vollständige Dienstinventur — welche OpenStack-Projekte tatsächlich genutzt werden, welche mandantensichtbare APIs haben, hinter welchen Integrationen hängen. Entwurf des Mandantenmodells. Adressplan. Ergebnis ist eine schriftliche Zielarchitektur und eine Kohortenfolge — und der Punkt, an dem ein Nein noch günstig ist.
- Parallel-Deployment. Cozystack wird neben der laufenden OpenStack-Cloud aufgebaut, nicht darauf. Beide Steuerebenen bestehen für die Dauer nebeneinander; es gibt keinen Moment, in dem die gesamte Umgebung an einem einzigen Cutover hängt.
- Kohorten-Migration. Workloads ziehen in definierten Gruppen um — typischerweise nach Mandant, bei einer internen Cloud nach Anwendungsschicht. Jede Kohorte wird im Parallel-Run validiert, bevor ihre OpenStack-Seite freigegeben wird. Compute zuerst, Storage folgt dem Compute, das Netzwerk wird pro Kohorte gegen den abgestimmten Adressplan umgeschaltet.
- Decommission. OpenStack-Knoten werden geleert und in den neuen Cluster überführt, sobald Kohorten abgeschlossen sind. Die Umgebung braucht damit nicht über die gesamte Laufzeit doppelte Hardware, sondern nur Reserve für die jeweils größte laufende Kohorte.
Typische Dauer: 4 bis 12 Monate für mittelgroße Umgebungen; 12 bis 18 Monate, wenn Neutron eine komplexe Provider-Netz-Topologie trägt oder Mandanten die OpenStack-API direkt nutzen.
Was sauber umzieht und was nicht
Zieht sauber um. VM-Disks — beide Seiten sind KVM, ein QCOW2- oder raw-Image importiert ohne Änderung am Gastsystem in ein KubeVirt-DataVolume. Linux-Gäste booten in der Regel beim ersten Versuch. Ceph, wenn Sie es behalten. Object-Storage-Endpunkte. Alles bereits Containerisierte.
Braucht Entwurfsarbeit. Die Mandantenhierarchie, falls Sie Keystone-Domains und verschachtelte Projekte genutzt haben. Load-Balancer-Semantik. Quota- und Rate-Limit-Modelle. Alles, was einen Floating-IP-Pool voraussetzt.
Muss neu gebaut werden. Heat-Stacks. Horizon-Anpassungen. Abrechnungs- und Metering-Anbindungen, die Ceilometer lesen und auf die neue Metrikquelle umgehängt werden müssen — bei einem Service-Provider ist das nach dem Netzwerk der längste Einzelposten, und weil er den Umsatz betrifft, wird er früh eingeplant statt spät.
Zieht womöglich gar nicht um. Ironic-verwaltetes Bare Metal. Windows-Gäste brauchen dieselbe VirtIO-Treiberbehandlung wie bei jeder Virtualisierungsmigration. Als Hersteller-VM ausgelieferte Appliances brauchen die Freigabe ihres Herstellers für den neuen Hypervisor, bevor Sie mit ihnen planen.
Den Plattformvergleich hinter diesen Entscheidungen finden Sie unter OpenStack-Alternative. Die Kostenseite modellieren Sie mit dem ROI- und TCO-Rechner.
Wie Ænix arbeitet
- Platform Readiness Assessment (Festpreis, vorab vereinbart) — Dienstinventur, Zielarchitektur, Mandanten- und Adressentwurf, Kohortenplan, Risikoregister. Siehe Platform Readiness Assessment.
- Pilot-Kohorte — die erste Mandantengruppe migriert mit Ænix-Ingenieuren im Team; daraus entstehen die Runbooks für den Rest.
- Rollende Migration — Kohorte für Kohorte, im Parallel-Run validiert, mit OpenStack-Hardware, die in den Zielcluster nachwandert.
- Betrieb — entweder betreibt Ihr Team die Plattform mit Cozystack Enterprise Support im Rücken, oder Ænix betreibt sie.
Ænix ist das Team hinter Cozystack (CNCF-Projekt, Apache 2.0).