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.
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.
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 kommt 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 nur lesend ab, mit jeder Abfrage im Audit-Log.
Jeder Host bekommt DNS-Record und Zertifikat, bei Cloudflare 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.
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.
Clusterward ersetzt weder Scaleway noch Ihre Entwicklung. Es übernimmt die Arbeit dazwischen, die sonst in Skripten, Wikis und Köpfen steckt.
| Aufgabe | Scaleway | Clusterward | Ihr Team |
|---|---|---|---|
| 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 |
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.
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.
