Changelog: was in Clusterward neu ist

Mit dem dritten Schalter „Also let it change configuration“ ändert ein Assistent Ressourcen, Skalierung, Image-Tag, Backup- und Snapshot-Pläne, Builds und Tenant-Eingaben und legt Anwendungen, Umgebungen, Services, Datenbanken, Katalog-Apps und Onboardings an. Nichts wird von selbst ausgerollt.

Datenbank-Backup oder Snapshot jetzt, Bucket-Backup und Restore-Test, Konfigurationsprüfung, DNS-Zone abgleichen, Wildcard-Zertifikat ausstellen, Import abbrechen, Verbindungen testen – jeweils nach Rückfrage.

Clusterward spricht das Model Context Protocol: Claude Code, Claude Desktop, Cursor oder VS Code beantworten, warum ein Deploy scheiterte, was heiß läuft oder welche Seiten nicht antworten. Einschalten unter System → Sicherheit, dazu ein API-Token mit „Usable by AI assistants“ – der Assistent liest nur, was das Token darf.

In Claude im Browser, in der Desktop-App oder auf dem Handy einen eigenen Connector hinzufügen, im Cockpit anmelden und zulassen. Der Assistent handelt als Sie, höchstens mit Ihren Rechten; „Connected assistants“ im Kontomenü trennt ihn sofort.

Mit „Also let it act“ und dem Recht „operate“ startet ein Assistent Deploys und Neustarts, holt frühere Versionen, bricht Builds ab, wiederholt Pipeline-Läufe und legt Uptime-Checks an – über dieselben Prüfungen wie das Cockpit und nach Rückfrage. Löschen geht nie.

Cluster-Details, Umgebungen und Isolation, Pods und warum einer abstürzte, Volumes, DNS, Zertifikate, Buckets, Pipelines, Compliance – nie Schlüssel, Passwörter oder Chart-Werte. Und sie sagen, warum sie etwas nicht dürfen.

Vom fehlgeschlagenen Deploy bis zum Backup-Check; der Assistent liest jeden Hilfe-Artikel, nennt bei einer Ablehnung den passenden und verlinkt die Seite im Cockpit, um die es geht.

Aufrufe über 24 Stunden, 7 oder 30 Tage, Fehler und ihre Ursachen, Antwortzeiten pro Werkzeug, wer gefragt hat und welche Werkzeuge niemand nutzt.

Zwei neue Ansichten: „Services“ zeigt CPU, Speicher und Neustarts jedes deployten Services der letzten 24 Stunden, die nächsten am Limit zuerst; „Uptime“ jeden Check mit 24-Stunden-Balken, Verfügbarkeit und Antwortzeit – und die Services, die noch niemand überwacht.

Die Übersicht beginnt mit einem Satz zum Stand und einer Liste mit allem, was Sie braucht – fehlgeschlagene Deployments, ausgefallene Seiten, gescheiterte Backups, ablaufende Zertifikate, die Zugriffsprüfung, wartende Restarts und Commits. Dazu ein Streifen mit den letzten 24 Stunden und Kacheln mit der Uptime jeder App.

Eine Karte pro Scaleway-Projekt mit Clustern, Nodes, Datenbank-Instanzen und Load Balancern, live gelesen – auch für alle, die Infrastruktur nicht ändern dürfen.

„Needs you“, „Running now“ und die letzten 24 Stunden nennen Services als Anwendung / Umgebung / Service – gleichnamige Services verschiedener Tenants sind wieder unterscheidbar.

Ein Schalter pro Workspace erlaubt INSERT, UPDATE, DELETE und Strukturänderungen. Jede Änderung läuft zuerst als Vorschau, die zurückgerollt wird und sagt, wie viele Zeilen sie ändern würde; „Apply changes“ führt genau diese Anweisung aus. DROP, TRUNCATE und Änderungen an allen Zeilen fragen nach dem Datenbanknamen.

S3-Seite → Backups: Jeder Bucket wird jede Nacht in einen gesperrten Backup-Bucket im Projekt und in der Region Ihrer Wahl kopiert. Jede Nacht ist ein Wiederherstellungspunkt, standardmäßig 30 Tage; der Backup-Schlüssel kann nichts löschen, und ein fehlendes Backup wird gemeldet.

„Backup history…“ → eine Nacht: in einen neuen privaten Bucket zurückspielen, der laufende bleibt unberührt, auf Wunsch nur ein Ordner – oder eine einzelne Datei suchen und herunterladen.

Jeder gesicherte Bucket wird einmal im Monat mit einer Stichprobe getestet, „Test restore“ startet einen sofort. „Download evidence…“ lädt jedes Backup, jede Wiederherstellung und jeden Test eines Zeitraums als CSV.

Der Import hält die Workloads des Charts für die Kopie an und startet sie danach wieder. Sie bestätigen im Dialog, dass sonst nichts in die Datenbank schreibt – vorher das Chart abzubauen ist nicht mehr nötig.

Lässt die Quelldatenbank nur bekannte Adressen zu, braucht sie die ausgehende Adresse des Clusters. Der Dialog zeigt sie mit Kopierknopf.

Jeder Bucket eines Bucket-Schritts hat das Kästchen „Back up nightly“, standardmäßig an.

Objekte über 2 GiB werden nicht mehr übersprungen: Backups, Wiederherstellungen und der Import aus anderen S3-Buckets kopieren sie in Teilen, mit Fortschritt pro Teil.

Ein neuer Menüpunkt „Compliance“: Live-Prüfungen zu Zugriff, Backup, Protokollierung, Netzwerk und Änderungen, jede mit ihrer Annex-A-Kontrolle und einem Link zur Behebung, dazu sechs Berichte als CSV.

Eine Zugriffsprüfung durchgehen und unterschreiben, im eigenen Zyklus mit Erinnerung. „Download compliance pack“ legt alle Berichte eines Zeitraums mit README und Prüfsummen in ein ZIP.

„Show passwords“ braucht das Recht „operate“ für Datenbanken, und jedes Anzeigen steht im Audit-Log.

Neben der Nummer (A.8.5, A.8.13 …) zeigen Compliance-Seite und Compliance-Paket den Namen der Kontrolle aus Annex A – so finden Sie sie in Ihrer Erklärung zur Anwendbarkeit.

Keine andere Subdomain kann das Sitzungs-Cookie setzen oder ersetzen; nach dem Update meldet sich jeder einmal neu an.

Ziele, die auf private, interne oder Metadaten-Adressen zeigen, werden beim Speichern und vor jedem Aufruf abgelehnt; Webhook-Adressen liegen verschlüsselt.

Passwort- oder 2FA-Reset, Einladungen und Änderungen an einem Nutzer brauchen mindestens dessen Rechte.

Die Download-Knöpfe auf der Compliance-Seite und im Backup-Nachweis zeigen wieder ihre Beschriftung.

„Who else may call in“ im Isolationsdialog erlaubt einer Umgebung auf demselben Cluster, die Services einer isolierten Umgebung über Cluster-DNS aufzurufen; die Regeln auf beiden Seiten pflegt Clusterward.

„Add record…“ legt einen A- oder CNAME-Record in einer registrierten Zone bei Cloudflare oder Scaleway DNS an; Clusterward verwaltet ihn danach. Die übrigen A-Records der Zone stehen darunter.

Die Port-Karte zeigt, wo ein Service im Cluster antwortet, mit Kopierknopf – für Aufrufe aus einer anderen Umgebung ohne Domain.

Die Seite nennt vor „Issue“, was fehlt – etwa Admin-Zugang oder den Scaleway-DNS-Webhook –, mit Link zur Behebung, und verfolgt das Zertifikat danach, bis es bereit ist.

Unter „Verify zone“ steht, ob die Zone verifiziert ist oder warum nicht, und wann zuletzt geprüft wurde.

Auf Clustern mit Envoy Gateway las ein Service mit einer Domain ohne eigenes Zertifikat (TLS-Modus „No TLS“ hinter Cloudflare) nach jedem Deployment „differs“. Die Prüfung liest jetzt jede Route, die den Service bedient.

„Runs on“ legt einen Build auf einen beliebigen Node, einen Node-Pool oder einen Pool Claim. Ein Claim mit Taint wird so zum reinen Build-Pool, und jeder Build hält ihn am Leben.

„Touch (keep alive)“ funktioniert jetzt auch bei einem freigegebenen Claim: Er lebt mit denselben Einstellungen wieder auf, und Clusterward legt seinen Node-Pool neu an.

Ein ephemerer Claim nach Ablauf seiner Leerlaufzeit bekam seinen Node-Pool mitunter von selbst wieder. Er bleibt jetzt ohne Pool, bis sein Verbraucher sich meldet.

Die Tenant-Liste zeigt, auf welcher Chart-Version oder wie viele Commits hinter dem Branch jeder Tenant läuft. „Update to the newest version…“ bringt genau diesen einen Tenant auf den neuesten Stand – zum Ausprobieren, bevor die übrigen folgen.

Jede Zeile der Tenant-Liste zeigt die Gesundheit der Services und die letzten 24 Stunden der Uptime-Checks als Balken. Die Kacheln oben filtern die Liste, Retry und das Menü mit Open site, Edit inputs, Cancel und Offboard liegen in der Zeile.

Workload- und Umgebungs-Schritte legen nach dem ersten gesunden Rollout Uptime-Checks an – ein neuer Kunde ist vom ersten Moment an überwacht.

Jeder Tenant bekommt eine eigene Umgebung, deshalb reicht ein fester Name wie „web“; eine Variable im Namen lehnt der Designer jetzt mit dieser Begründung ab.

Ein Domain-Schritt übernimmt die Klasse des Schritts, der seinen Host bedient; gewählt wird sie aus einer Liste.

Die Host-Quelle eines Domain-Schritts bietet Scaleway DNS neben Cloudflare an.

Ist Object Storage verbunden, nennt der Einrichtungsleitfaden als nächsten Schritt die Bucket-Backups.

Ein Log-Viewer führt alle Instanzen eines Services nach Zeit zusammen, mit Suche, „Errors only“, Download und dem vorherigen Lauf eines abgestürzten Containers.

CPU, Speicher und Instanzen über 24 Stunden, 7 oder 30 Tage; Uptime-Checks prüfen Ihre Domains von außen und melden Ausfälle.

CPU und Speicher auf einer Achse von 0 bis 100 % des Limits, auch für Services aus Helm-Charts. Zeiträume von 15 Minuten bis 30 Tage und eine große Ansicht mit aktuellem, durchschnittlichem und höchstem Wert.

Benachrichtigungen, Einladungen und Passwort-E-Mails zeigen die Domain des sendenden Betreibers im Absender, im Betreff und in der Fußzeile, dazu seine Firmenangaben mit Impressum und Datenschutz.

Hervorhebung und Vervollständigung von Tabellen und Spalten, nur die Markierung ausführen, Abfragen formatieren, Tabellen, Spalten und Indizes im Schema-Browser und mehrere Abfragen in Tabs.

Lange Werte öffnen, eine Zeile als Datensatz lesen, sortieren, Spalten ausblenden und verbreitern, weitere Zeilen nachladen und als CSV, CSV für Excel oder JSON herunterladen.

Abfragen für sich oder das Team speichern, :name-Parameter sicher binden, frühere Abfragen aus dem Verlauf öffnen und Links teilen, die eine Abfrage öffnen, ohne sie auszuführen.

Fertige Prüfungen wie größte Tabellen, ungenutzte Indizes oder Sperren, eine laufende Abfrage abbrechen und der Plan als Baum mit dem teuersten Schritt – bei PostgreSQL mit echten Zeiten. Die Runner jedes Clusters sind mit ihrem Verbrauch zu sehen.

Unter Operations → SQL-Konsole eine Anweisung gegen eine PostgreSQL- oder MySQL-Datenbank ausführen: mit eigenem Lese-Login, in einer Nur-Lese-Transaktion, standardmäßig bis 60 Sekunden und 1.000 Zeilen. Jede Abfrage steht im Audit-Log, die Konsole hat eine eigene Berechtigung.

Automatische Snapshots, Backups einzelner Datenbanken mit Download und Wiederherstellung in eine neue Datenbank neben der laufenden.

Ein Volume aus einem Snapshot zurückholen, mit Sicherheits-Snapshot vorher; auch die Festplatten, die ein Helm-Chart mitbringt, bekommen Snapshots.

Deploy und Neustart aus GitHub Actions oder jedem Skript, mit eigener Rolle, Anwendungsbereich und Ablaufdatum.

Neue Nutzer setzen ihr Passwort über einen Einladungslink selbst, Wiederherstellungscodes ersetzen ein verlorenes Handy, Angriffe auf die Anmeldung werden gesperrt.

Jede Änderung durchsuchbar im Cockpit; die ganze Konfiguration als JSON-Datei, ohne Passwörter und Schlüssel.

Jede Umgebung zeigt, ob sie isoliert ist: Dann kommen nur der Ingress-Controller und die eigenen Pods hinein, und der Metadaten-Dienst der Nodes ist nicht erreichbar. Isolieren geht mit einem Klick, neue Umgebungen und Pipeline-Umgebungen gleich nach dem ersten Rollout; System → Sicherheit listet alle Umgebungen. Angeboten wird das nur, wo alle Voraussetzungen erfüllt sind.

Einmal am Tag löscht Clusterward Einträge, die älter als zwölf Monate sind – auch den Abfrageverlauf der SQL-Konsole. Wer Nachweise länger braucht, exportiert seine Daten unter System → Security.

Eine isolierte Umgebung lässt sich wieder öffnen. Kommt ein Ingress-Controller hinzu oder fällt einer weg, passen sich die Richtlinien aller isolierten Umgebungen des Clusters selbst an.

Schlüssel und Tokens eintragen, destruktive Aktionen und Helm-Charts schreiben brauchen jetzt die Stufe „verwalten“. Rollen, Bereiche und API-Tokens vergibt jeder nur im Rahmen der eigenen Rechte, und der Anwendungsbereich gilt auch für Kunden-Läufe, Backups und Bucket-Schlüssel.

Secrets sind nach dem Speichern nicht mehr auslesbar und liegen auf Wunsch im Secret Manager Ihres Projekts, in Ordnern pro App, Umgebung und Service.

Eine neue Version im Secret Manager wird erkannt und auf Wunsch per Neustart ausgerollt; pro Cluster wählbar über den External Secrets Operator.

Ein Secret-Store kann einen nur lesenden Schlüssel bekommen, mit dem External Secrets die Werte in Ihre Namespaces liefert. Die Store-Seite zeigt, wo er noch fehlt.

Zonen in Scaleway Domains & DNS lassen sich mit einem IAM-Schlüssel registrieren. Clusterward legt Records an, gleicht sie ab, übernimmt fremde und zieht sie beim Controller-Wechsel um – wie bei Cloudflare. Wildcard-Zertifikate entstehen über den Scaleway-DNS-Webhook aus der Setup-Karte des Clusters.

„Klasse wechseln…“ zeigt vor dem Start für jeden Host, wer den DNS-Record umzieht und was mit dem Zertifikat passiert. Clusterward zieht eigene und übernommene Records selbst um, erkennt den Umzug auch hinter dem Cloudflare-Proxy und lässt einen laufenden Wechsel abbrechen.

Registrierte Zonen werden stündlich mit Cloudflare abgeglichen. Bestehende Records lassen sich übernehmen: Clusterward ändert sie dann wie eigene, löscht sie aber nie. Die Domains-Karte liest jeden Host live.

Envoy Gateway als zweiter Ingress-Controller; ein Wechsel der Ingress-Klasse läuft mit beiden Load Balancern parallel, bis DNS umgezogen ist.

Timeouts, Retries, Rate-Limits, Upload-Größe, CORS, Sticky Sessions und Basic Auth je Service.

Leitet ein Host hinter dem Cloudflare-Proxy weiter, schreibt Clusterward bei jedem Deploy eine Redirect-Regel in die Zone: ein 301 auf https, tiefere Seiten behalten ihren Pfad. Ziele dürfen jetzt einen Pfad tragen, etwa example.com/de. Das Zonen-Token braucht dafür das Recht „Dynamic URL Redirects: Edit“.

Hat ein Chart den Schalter ingress.mode, läuft der Wechsel zwischen nginx und Envoy auch für Helm-Services als Cutover.

Ein von Clusterward ausgestelltes Wildcard-Zertifikat für *.example.com gilt auch für example.com.

Auf einem von Clusterward angelegten Cluster beschreiben Sie, welche Nodes ein Zweck braucht – ein Scanner, ein Batch-Lauf, ein Mandant. Clusterward legt einen passenden Node-Pool an, skaliert ihn, setzt Label und Taint und gibt ephemere Claims im Leerlauf selbst frei.

Die eigene Adresse mit einem Klick für die Kubernetes-API freigeben – ohne Scaleway-Konsole.

Die Cluster-Identität liest und schreibt Secrets nur in den Namespaces Ihrer Umgebungen, die mit Pod Security „baseline“ laufen; eine Richtlinie im Cluster hält das fest. Builds pushen mit einem Schlüssel, der nur die Registry darf, und Admin-Zugriff auf einen Cluster gilt eine Stunde. Bestehende Cluster stellen Sie auf der Cluster-Seite um (Kubernetes 1.30 oder neuer).

Ein Umgebungsschritt im Pipeline-Designer hat einen Abschnitt „Volumes“: Name, Pfad, Größe, Speicherklasse und Snapshots je Festplatte, angelegt mit dem Service jedes Mandanten.

Die Tenant-Seite zeigt die Eingaben, mit denen ein Kunde angelegt wurde. „Edit inputs…“ ändert sie – mit einer Vorschau jeder Zeile, die sich ändert; später hinzugekommene Eingaben erscheinen als neu.

KEY=secret:Wert im Env-Template eines Umgebungs-Bausteins wird zum nur schreibbaren Secret des Kunden-Services, auf Wunsch gleich im Scaleway Secret Manager. Workload-Bausteine legen Chart-Secrets vor dem ersten Rollout an, und Env-Vorlagen erzeugen Secrets pro Service, ohne selbst Werte zu speichern.

Der Domain-Baustein einer Pipeline kann eine Ingress-Klasse angeben, damit der Record auf den richtigen Load Balancer zeigt.

Tarif und die Zahl der genutzten und enthaltenen Cluster auf einen Blick, auch über den Listen. Am Limit sind neue Cluster mit Begründung gesperrt; laufende Cluster und Anwendungen hält ein Limit nie an.

Bei offener Zahlung oder nach Vertragsende ist das Cockpit nur lesbar, ein Hinweis sagt warum. Ihre Anwendungen laufen weiter, Anmelden und Datenexport bleiben möglich.