Clusterward shows which Kubernetes versions are available, runs the Kubernetes upgrade after confirmation, scales node pools and keeps ingress controllers and cert-manager on tested versions.
Cluster updates are the day-2 operations of a Kapsule cluster, run from the cockpit: upgrading Kubernetes to newer patch versions of the current minor or to the next minor version, creating, scaling and removing node pools, the maintenance window for automatic patches, and updating the add-ons Clusterward installed. Add-on versions come from a curated catalog with compatibility ranges; Clusterward reads what is installed in the cluster from the Helm releases themselves.
The version card shows only versions Kapsule can reach from here.
Type the cluster name; refused while another upgrade is running.
Scaleway updates the control plane; Clusterward polls the status.
If you want, the pools are brought along; otherwise the cockpit shows “nodes behind”.
Success or failure is recorded in the audit log and reported as a notification.
What is otherwise scattered across the Scaleway console, Helm repositories and changelogs.
Current version, reachable targets, running upgrade with status. Kapsule moves one minor per step; the card only offers what is possible.
Pools are read from Scaleway and linked to the cluster’s nodes. Change the size, create new pools with a different node type, remove pools after typing the name.
Automatic patch upgrades in a time window of your choice. Minor upgrades remain a deliberate decision.
Ingress controllers, cert-manager and other components in the versions Clusterward knows, including Kubernetes compatibility. Only what has run at least once is recommended.
Clusterward reads what is installed from the Helm releases: up to date, update available, or incompatible with the cluster version. Add-ons removed by hand disappear from the list.
An add-on upgrade uses the same values as the installation and remembers the previous version as a rollback target. Refused while a Kubernetes upgrade is running.
Versions, upgrades, pools and maintenance windows via the Scaleway API.
Installed add-on versions from the release secrets, not from assumptions.
kubeVersion ranges of every chart version, checked against the cluster.
Every upgrade with person, target and result.
The rules come from Scaleway. Clusterward makes them visible in the cockpit instead of returning them as errors.
| Rule | Consequence in the cockpit |
|---|---|
| One minor per upgrade | The version card offers patches and the next minor |
| A pool’s node type is fixed | A different type means: create a new pool, remove the old one |
| Auto-upgrade only for patches | Minor upgrades remain manual and confirmed |
| Scaling down drains nodes | The cockpit points this out when scaling |
| Upgrades take time | Background monitoring for up to three hours, then an error |
The add-ons updated here are installed by Cluster provisioning when the cluster is created. You learn about new versions via Notifications before you even open the cockpit.
Upgrades are an action of the “manage” permission level in the Provisioning area; see Security & access.
Kapsule clusters secure by default, with Private Network and gateway.
Go to Cluster provisioningWebhook, Slack, Teams or email – once per event.
Go to NotificationsRoles, mandatory 2FA, audit log and IP allowlist.
Go to Security & accessCan’t find your question? Write to us – we usually reply on the same business day.
Ask a questionWe show the version card on a real cluster, scale a pool and update an add-on.
