Zum Hauptinhalt springen Zur Navigation springen Zur Fußzeile springen

Einen laufenden Kubernetes-Cluster forken oder verschieben

Ihr Cluster zieht als ganzes um: Nodes, Konfiguration, Daten. Auf eine andere Maschine oder in ein anderes Rechenzentrum. Die Umschaltung dauert Sekunden, nicht ein Wochenende.

DAS PROBLEM

Ihr Cluster sitzt fest, wo Sie ihn aufgebaut haben

Kubernetes hat Ihre Apps portabel gemacht. Der Cluster selbst ist es nicht. Die Daten liegen in einem einzigen Rechenzentrum. Ihn zu verschieben bedeutet ein Neuaufbau-Projekt: neue Nodes, neuer Speicher, Wiederherstellung aus dem Backup, alles neu testen. Deshalb ziehen die meisten Teams nie um. Und ihr Anbieter weiß das.

27% der Cloud-Ausgaben werden jedes Jahr verschwendet 1 Flexera 2024 State of the Cloud Report
17% durchschnittlicher Betrag, um den Unternehmen ihr Cloud-Budget überschreiten 2 Flexera 2025 State of the Cloud Report
$0.09/GB an Gebühren für den Datenexport, bewusst so gestaltet, dass ein Wechsel teuer wird 3 AWS/Azure/GCP Pricing 2024
46s
Kompletter 2-Node-Cluster-Fork
16s
Migrations-Umschaltung, gemessen
1-5s
Namespace-Fork
SO FUNKTIONIERT ES

Der gesamte Cluster ist ein Satz Dateien

1

Cluster-Images plus Volumes

Jeder Node läuft von einer Image-Datei. Jedes Volume ist ein Ceph-RBD-Image. Zusammen ergeben sie den gesamten Cluster: Apps, Konfiguration und Daten.

2

Fork an Ort und Stelle

Ein einziger Befehl klont jedes Image, copy-on-write. Ein 2-Node-Cluster forkte in unserem Labor in 46 Sekunden. Der Ursprung läuft währenddessen weiter.

3

Migrieren mit kurzer Umschaltung

Rediacc kopiert vorab, während der Cluster läuft. Dann stoppt es, sendet das finale Delta und startet auf der neuen Maschine neu. Gemessene Umschaltung: 16 Sekunden.

prod (Datacenter A) Running
Nodes 2 (k3s + Ceph)
Namespaces 8 apps
Volumes Ceph RBD
State Keeps running
Fork
46s
prod-staging (Datacenter B) Running
Nodes 2 (k3s + Ceph)
Namespaces 8 apps
Volumes Ceph RBD clones
State Own identity, new IPs
UNTER DER HAUBE

Warum ein Cluster wie eine Datei umziehen kann

Jeder Node läuft von einer Image-Datei auf btrfs. Jedes Volume ist ein Ceph-RBD-Image. Einen Cluster zu kopieren heißt, diese Images copy-on-write zu klonen. Kein Export, keine Konvertierung, kein Wiederherstellungsschritt. Deshalb dauert ein Fork Sekunden, nicht Monate.

WARUM ES WICHTIG IST

Behalten Sie Ihr Kubernetes. Gewinnen Sie Mobilität.

Behalten Sie Ihr Kubernetes

Rediacc betreibt k3s für Sie oder verbindet sich mit einem Cluster, den Sie bereits haben. Volumes laufen über ceph-csi RBD. Ihre Manifeste bleiben Ihre eigenen.

Echte Rechenzentrums-Mobilität

Provisionieren Sie auf Ihren eigenen KVM-Hosts oder in Clouds wie Linode mit privaten VLANs. Node-Pools halten speicherintensive Ceph-Nodes getrennt von rechenintensiven Kubernetes-Nodes.

Eine Denkweise für alles

Eine Kubernetes-App ist ein Namespace. Forken Sie ihn wie jedes Repository: 1 bis 5 Sekunden, Daten inklusive. Dieselben Befehle, die Sie schon für Docker-Repositories nutzen.

Wenig Zeit?

Kein Deep-Dive nötig. Die Fünf-Minuten-Version eignet sich für die nächste Teambesprechung.

Kurzfassung herunterladen (PDF)
DIE LÜCKE

Niemand sonst verschiebt einen laufenden Cluster samt seinen Daten

Backup-Tools stoppen und stellen wieder her. Cluster API klont die Struktur ohne die Daten. RBD-Mirroring kopiert Volumes, nicht den Cluster. Rediacc verschiebt alles davon.

Geben Sie Ihrem Cluster einen Fluchtweg

Forken Sie ihn, testen Sie den Umzug, dann migrieren Sie wirklich. Starten Sie Ihre 14-tägige kostenlose Testphase.

Kostenlos starten
$ rdc cluster fork prod --tag staging