Clusterward zeigt, welche Kubernetes-Version möglich ist, führt das Kubernetes-Upgrade mit Bestätigung aus, skaliert Node-Pools und hält Ingress-Controller und cert-manager auf geprüften Versionen.
Cluster-Updates sind der Tag-2-Betrieb eines Kapsule-Clusters aus dem Cockpit: das Kubernetes-Upgrade auf neuere Patch-Versionen der aktuellen oder auf die nächste Minor-Version, das Anlegen, Skalieren und Entfernen von Node-Pools, das Wartungsfenster für automatische Patches sowie die Aktualisierung der Add-ons, die Clusterward installiert hat. Versionen für Add-ons stammen aus einem gepflegten Katalog mit Kompatibilitätsbereichen; was im Cluster installiert ist, liest Clusterward aus den Helm-Releases selbst.
Die Versionskarte zeigt nur Versionen, die Kapsule von hier aus erreicht.
Cluster-Name eintippen; verweigert, solange ein anderes Upgrade läuft.
Scaleway aktualisiert die Steuerungsebene, Clusterward pollt den Status.
Auf Wunsch werden die Pools mitgezogen, sonst zeigt das Cockpit „Nodes hinterher“.
Fertig oder gescheitert wird im Audit-Log vermerkt und als Benachrichtigung gemeldet.
Was sonst zwischen Scaleway-Konsole, Helm-Repositories und Changelogs verteilt ist.
Aktuelle Version, erreichbare Ziele, laufendes Upgrade mit Status. Kapsule geht einen Minor pro Schritt; die Karte bietet nur an, was geht.
Pools werden bei Scaleway gelesen und mit den Nodes des Clusters verbunden. Größe ändern, neue Pools mit anderem Node-Typ anlegen, Pools nach Eintippen des Namens entfernen.
Automatische Patch-Upgrades in einem Zeitfenster Ihrer Wahl. Minor-Upgrades bleiben eine bewusste Entscheidung.
Ingress-Controller, cert-manager und weitere Komponenten mit den Versionen, die Clusterward kennt, samt Kubernetes-Kompatibilität. Empfohlen wird nur, was einmal gelaufen ist.
Was installiert ist, liest Clusterward aus den Helm-Releases: aktuell, Update verfügbar oder inkompatibel mit der Cluster-Version. Aus der Hand entfernte Add-ons verschwinden aus der Liste.
Ein Add-on-Upgrade nutzt dieselben Werte wie die Installation und merkt sich die vorherige Version als Rollback-Ziel. Verweigert, während ein Kubernetes-Upgrade läuft.
Versionen, Upgrades, Pools und Wartungsfenster über die Scaleway-API.
Installierte Add-on-Versionen aus den Release-Secrets, nicht aus Annahmen.
kubeVersion-Bereiche jeder Chart-Version, gegen den Cluster geprüft.
Jedes Upgrade mit Person, Ziel und Ergebnis.
Die Regeln stammen von Scaleway. Clusterward macht sie im Cockpit sichtbar, statt sie als Fehler zurückzugeben.
| Regel | Konsequenz im Cockpit |
|---|---|
| Ein Minor pro Upgrade | Die Versionskarte bietet Patches und den nächsten Minor an |
| Node-Typ eines Pools ist fest | Ein anderer Typ heißt: neuen Pool anlegen, alten entfernen |
| Auto-Upgrade nur für Patches | Minor-Upgrades bleiben manuell und bestätigt |
| Verkleinern entleert Nodes | Das Cockpit weist beim Skalieren darauf hin |
| Upgrades dauern | Hintergrundüberwachung bis zu drei Stunden, dann Fehler |
Die Add-ons, die hier aktualisiert werden, installiert das Cluster-Provisioning beim Anlegen. Neue Versionen erfahren Sie über Benachrichtigungen, bevor Sie das Cockpit öffnen.
Upgrades sind eine Aktion der Berechtigungsstufe „verwalten“ im Bereich Provisioning, siehe Sicherheit und Zugriff.
Kapsule-Cluster sicher ab Werk, mit Private Network und Gateway.
Zu Cluster-ProvisioningWebhook, Slack, Teams oder E-Mail – einmal pro Ereignis.
Zu BenachrichtigungenRollen, Pflicht-2FA, Audit-Log und IP-Allowlist.
Zu Sicherheit & ZugriffIhre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.
Frage stellenWir zeigen die Versionskarte an einem echten Cluster, skalieren einen Pool und aktualisieren ein Add-on.
