Changelog: was in Clusterward neu ist

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.

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.

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.

„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.

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).

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.