Der Wechsel zu Scaleway scheitert selten an Kubernetes, sondern an allem drumherum: Netzwerk, Datenbanken, Buckets, DNS, Zertifikate. Clusterward baut die neue Umgebung sicher auf, holt Daten aus AWS, Azure oder Google Cloud herüber und zieht Ihre Hosts einzeln um – die alte Umgebung läuft weiter, bis alles grün ist.
Ein Wechsel zu Scaleway mit Clusterward heißt: Die Zielumgebung entsteht in Ihrem eigenen Scaleway-Projekt – Kapsule-Cluster im Private Network, Nodes ohne öffentliche IP, Managed Database nur privat erreichbar, eigene Container Registry. Danach ziehen Sie Anwendung für Anwendung um: Image oder Git-Repository anbinden, Daten importieren, Host umstellen. Clusterward verwaltet nur die neue Seite; EKS, AKS oder GKE bleiben unangetastet, bis Sie sie selbst abschalten.
Clusterward legt Cluster, Private Network, Gateway und Registry in Ihrem Scaleway-Projekt an.
Git-Repository, fertiges Image oder Helm-Chart anbinden und neben der alten Umgebung ausrollen.
Datenbank und Buckets importieren, während die Apps am Ziel pausieren.
Host auf Scaleway zeigen lassen, Zertifikat kommt automatisch. Nächste Anwendung.
Die Teile, die bei einem Cloud-Wechsel sonst Wochen kosten, sind im Cockpit ein Formular.
Der neue Cluster startet im Private Network, Nodes ohne öffentliche IP, API-Server nur aus Ihren Adressbereichen. Kein Nachhärten nach dem Umzug.
Schema und Daten aus RDS, Azure Database oder Cloud SQL in eine Managed Database. Der Import läuft im Cluster, die betroffenen Apps pausieren und starten danach wieder.
Objekte aus einem S3-kompatiblen Bucket in einen Scaleway-Bucket kopieren, mit Fortschrittsanzeige. Kopieren und überschreiben, nie löschen – ein zweiter Lauf ist gefahrlos.
Jeder Cluster bekommt eine private Registry im eigenen Projekt. Gebaut wird im Cluster oder mit GitHub Actions, ausgerollt wird aus Ihrer Registry.
Umgebungsvariablen und Secrets pro Service, auf Wunsch in Scaleway Secret Manager. Secrets, die dort schon liegen, übernehmen Sie statt sie neu anzulegen.
Jeder Host bekommt Ingress und Zertifikat. Liegt die Zone bei Cloudflare, setzt Clusterward den Record selbst – einen bestehenden übernimmt es und stellt ihn um, statt einen zweiten anzulegen; sonst stellen Sie einen Record um.
Die meisten Bausteine haben bei Scaleway ein direktes Gegenstück, das Clusterward verwaltet.
| Heute | Bei Scaleway | Mit Clusterward |
|---|---|---|
| EKS, AKS, GKE | Kapsule | Anlegen, Node-Pools, Upgrades |
| RDS, Azure Database, Cloud SQL | Managed Database | Instanz, Datenbanken, Import |
| S3, S3-kompatible Buckets | Object Storage | Buckets, Schlüssel, Kopie |
| ECR, ACR, Artifact Registry | Container Registry | Namespace pro Cluster |
| Secrets Manager, Key Vault | Secret Manager | Secrets pro Service |
| Route 53, Azure DNS, Cloud DNS | Cloudflare (empfohlen) | Records und Zertifikate |
Wie die Zielumgebung entsteht und welche Rechte der Scaleway-Schlüssel braucht, steht unter Cluster-Provisioning. Den Datenbank-Import und seine Voraussetzungen beschreiben die Managed Datenbanken.
Warum Daten in EU-Rechenzentren eines europäischen Anbieters liegen sollten, erklärt Digitale Souveränität. Kommen Sie von einer Kubernetes-Plattform statt direkt vom Hyperscaler, lesen Sie Migration von Qovery.
Den Weg Dienst für Dienst mit allen Stolperfallen beschreibt der Beitrag Von AWS zu Scaleway: Was aus RDS, S3 und Route 53 wird.
Kapsule-Cluster sicher ab Werk, mit Private Network und Gateway.
Zu Cluster-ProvisioningPostgres und MySQL privat angebunden, eine Datenbank pro Service.
Zu Managed DatenbankenCluster, Datenbanken und Buckets in EU-Rechenzentren.
Zu Digitale SouveränitätIhre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.
Frage stellenWir legen einen Cluster an, importieren eine Beispieldatenbank und ziehen einen Host um – und schätzen mit Ihnen, wie lange Ihr Wechsel dauert.
