Clusterward ist die Kubernetes Control Plane zwischen Ihrem Code, Ihren Kunden und Ihrem Scaleway-Projekt. Diese Seite zeigt, wie Cluster, Anwendungen, Daten, Netzwerk, Kunden und Sicherheit zusammenhängen – und warum ein Cockpit für alles weniger Arbeit macht als sechs Werkzeuge. Bring Your Own Cloud: Alles, was Clusterward anlegt, entsteht in Ihrem eigenen Scaleway-Konto.
Eine Kubernetes Control Plane im Sinne von Clusterward ist die Schicht über Ihren Clustern, die festlegt, wie Anwendungen, Datenbanken, Domains, Secrets und Kunden entstehen, und die sie danach betreibt. Sie beschreiben, was laufen soll; Clusterward legt es in Ihrem Scaleway-Projekt an, rollt es aus, sichert es und meldet, wenn etwas hakt. Die Steuerungsebene von Kubernetes selbst betreibt Scaleway.
Der Unterschied zu einer Konsole: Eine Konsole zeigt einzelne Dienste. Eine Control Plane kennt den Zusammenhang – welche Datenbank zu welchem Service gehört, welche Domain auf welchen Cluster zeigt, welcher Kunde welche Ressourcen besitzt – und handelt danach, beim Anlegen genauso wie beim Löschen.
Ein IAM-Schlüssel pro Scaleway-Projekt, geprüft vor dem Speichern.
Kapsule im privaten Netz, Nodes ohne öffentliche IP, Ingress und Zertifikate.
Aus Git, Image, Helm-Chart oder dem App-Katalog, mit Datenbank und Domain.
Per Pipeline: Datenbank, Buckets, Domain und Workload pro Kunde in einem Lauf.
Logs, Alarme, Backups, Upgrades und Rollback – im selben Cockpit.
Jeder Bereich ist für sich nützlich. Der Wert entsteht, weil alle dieselben Objekte kennen.
Kapsule-Cluster entstehen sicher ab Werk: privates Netz, Gateway, Nodes ohne öffentliche IP, API-Server nur aus Ihren Adressen. Node-Pools, Kubernetes-Version und Add-ons wie Ingress-Controller und cert-manager aktualisieren Sie aus dem Cockpit; jeder Cluster hat seine eigene Container Registry. Für Arbeitslasten mit eigenem Bedarf legen Pool Claims Node-Pools auf Abruf an.
Ein Service kommt aus einem Git-Repository mit Build im Cluster oder über GitHub Actions, aus einem fertigen Image oder als Helm-Chart. Jeder Rollout wird per Health-Check bestätigt und per Digest festgehalten, jede frühere Version lässt sich zurückholen. WordPress und Uptime Kuma kommen fertig aus dem App-Katalog.
Managed PostgreSQL und MySQL im privaten Netz mit einer Datenbank pro Service, Buckets mit eigenem Schlüssel, persistente Volumes. Backups, Snapshots und Wiederherstellung neben der laufenden Datenbank gehören dazu, ebenso der Import bestehender Datenbanken und Buckets. Die SQL-Konsole fragt sie ab – mit Editor, gespeicherten Abfragen, Diagnosen und jeder Abfrage im Audit-Log – und ändert Daten nur, wenn Sie es erlauben, nach einer Vorschau. Buckets sichert Clusterward jede Nacht mit Object Lock und testet die Wiederherstellung monatlich.
Jeder Host bekommt DNS-Record und Zertifikat, in Zonen bei Cloudflare oder Scaleway DNS automatisch, für viele Subdomains per Wildcard. Ingress läuft über nginx oder Envoy Gateway, mit Timeouts, Rate-Limits, CORS und Basic Auth pro Service und einem Controller-Wechsel ohne Ausfall.
Für SaaS-Anbieter wird jeder Kunde zu einem Pipeline-Lauf: Datenbank, Buckets, Domain und Anwendung aus einer Vorlage, in Minuten live. Ihre eigene Anwendung kann Kunden direkt bestellen. Das Offboarding sichert zuerst und baut dann in umgekehrter Reihenfolge ab.
Pflicht-2FA, Rollen mit Anwendungs-Scope, API-Tokens für CI und ein Audit-Log jeder Änderung. Secrets sind nicht auslesbar und liegen auf Wunsch im Scaleway Secret Manager. Logs aller Instanzen, Auslastung, Uptime-Checks und Alarme zeigen, was im Betrieb passiert. Die Compliance-Seite zeigt ISO-27001-Prüfungen und liefert die Berichte für Ihr Audit. Das Dashboard bündelt, was Sie gerade braucht, zeigt die letzten 24 Stunden und unter Infrastructure → Monitoring die Kapazität jedes Projekts. KI-Assistenten wie Claude, Cursor oder VS Code beantworten Fragen zum Betrieb nach Ihren Rechten und dürfen auf Wunsch deployen.
Ein Beispiel zeigt es am besten. Ein SaaS-Anbieter bekommt einen neuen Kunden. Eine Tenant-Pipeline legt in einem Lauf eine Datenbank auf der Managed-Datenbank-Instanz an, ein Bucket-Paar mit eigenem Schlüssel im Object Storage, eine Subdomain mit Record und Zertifikat über DNS & Zertifikate und rollt die Anwendung für den Kunden aus.
Die Zugangsdaten fließen dabei nicht durch E-Mails oder Tickets: Datenbank-Passwort und Bucket-Schlüssel gelangen über die Vorlage direkt in die Umgebung des Services, auf Wunsch als nicht auslesbare Secrets im Scaleway Secret Manager. Wer was angelegt hat, steht im Audit-Log.
Im Betrieb kennt Clusterward dieselben Zusammenhänge. Fällt die Seite des Kunden aus, meldet sich ein Uptime-Check, und der Link führt zu den Logs aller Instanzen unter Logs & Monitoring. Braucht der Kunde einen alten Stand, kommt die Datenbank aus einem Backup neben der laufenden zurück, beschrieben unter Backups & Wiederherstellung.
Kündigt der Kunde, läuft alles rückwärts: Datenbank-Dump und Bucket-Archiv zuerst, dann werden Anwendung, Domain, Buckets und Datenbank entfernt – genau die, die für ihn angelegt wurden, und keine anderen. Dieses Wissen um den Zusammenhang ist der Unterschied zwischen einer Control Plane und einer Sammlung von Skripten.
Auch die Infrastruktur folgt dem Bedarf: Braucht ein Kunde eigene Nodes oder ein Scanner für eine Stunde Rechenkapazität, legen Pool Claims einen passenden Node-Pool an und geben ihn wieder frei.
Wer keine eigene Anwendung mitbringt, startet mit einer Vorlage aus dem App-Katalog: WordPress oder Uptime Kuma, mit Festplatte, Snapshots und Zertifikat.
Was der Betrieb sichert und protokolliert, wird zum Nachweis: Die S3-Backups kopieren jeden Bucket nachts gesperrt und testen die Wiederherstellung, die Compliance-Seite fasst Prüfungen, Berichte und die Zugriffsprüfung für Ihr ISO-27001-Audit zusammen.
Clusterward ersetzt weder Scaleway noch Ihre Entwicklung. Es übernimmt die Arbeit dazwischen, die sonst in Skripten, Wikis und Köpfen steckt. Rechenzentren und Hardware stellt Scaleway, in Ihrem eigenen Konto – Clusterward ist Software.
| Aufgabe | Scaleway | Clusterward | Ihr Team |
|---|---|---|---|
| Rechenzentren und Hardware | Betreibt sie | – | – |
| Kubernetes-Steuerungsebene | Betreibt sie | Nutzt sie | – |
| Cluster, Netz, Registry | Stellt Dienste bereit | Legt sicher an, aktualisiert | Wählt Größe und Region |
| Deployments | – | Baut, rollt aus, prüft, rollt zurück | Schreibt den Code |
| Datenbanken, Buckets, Volumes | Betreibt die Dienste | Legt pro Service an, sichert | Entscheidet über Daten |
| DNS und Zertifikate | Load Balancer | Records, Zertifikate, Ingress | Besitzt die Domains |
| Kunden anlegen und abbauen | – | Pipeline, Backup vor dem Abbau | Legt Vorlage fest |
| Zugriff und Nachweise | IAM | 2FA, Rollen, Audit-Log | Vergibt Rollen |
| Überwachung | – | Logs, Auslastung, Uptime, Alarme | Reagiert auf Alarme |
| Rechnung für Ressourcen | Rechnet direkt mit Ihnen ab | Schlägt nichts auf | Zahlt an Scaleway |
Ihre Anwendungen sind normale Deployments, Services und Helm-Releases – lesbar mit jedem Werkzeug.
Kapsule, Managed Database, Object Storage, Secret Manager und Load Balancer in Ihrem eigenen Projekt.
Rechenzentren in Paris, Amsterdam oder Warschau, bei einem europäischen Anbieter.
Ohne Clusterward läuft alles weiter; die Konfiguration exportieren Sie als JSON-Datei.
Die Konsole verwaltet einzelne Dienste. Clusterward kennt den Zusammenhang: welche Datenbank, welcher Bucket und welche Domain zu welchem Service und Kunden gehören. Daraus entstehen Deployments mit Health-Check, Kunden-Pipelines, Backups vor dem Löschen und ein Audit-Log über alles.
Ihre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.
Frage stellenIn der Demo verbinden wir ein Scaleway-Projekt, legen einen Cluster an, rollen eine Anwendung aus und legen einen Kunden per Pipeline an.
