Kubernetes version lifecycle and upgrades

WAYSCloud keeps the Kubernetes version catalogue deliberately small and predictable. New versions are qualified before they are offered, and upgrades are performed sequentially, one minor version at a time.

Current versions

Version	Status	New clusters	Support ends	Upgrade required by
1.35	Default	Yes	28 February 2027	—
1.34	Transition	Until 15 October 2026	27 October 2026	20 October 2026
1.33 and older	Not offered	No	—	—

Kubernetes 1.35 is the default for new clusters. Kubernetes 1.34 remains available for new clusters during its published transition window.

The same lifecycle is available machine-readable through the API (GET /v1/kubernetes/versions), including status, create_allowed, create_until, support_ends_at, upgrade_required_by and the recommended upgrade target.

Qualification

A Kubernetes version is not exposed automatically when it becomes available upstream.

Before a new minor version is offered, WAYSCloud qualifies the relevant lifecycle, including:

• cluster creation
• private networking
• workloads
• load balancing
• persistent storage
• backup and restore
• upgrade path
• deletion and resource cleanup

Only versions that pass this qualification are added to the WAYSCloud catalogue — and only qualified versions are offered as upgrade targets.

Upgrade path

Minor-version upgrades are sequential. A cluster cannot skip multiple minor releases in a single upgrade. For example:

1.34 → 1.35

Upgrades are customer-initiated. Two worker strategies exist:

• Rolling (default): the control plane is upgraded first, then worker nodes are converged automatically one at a time, using surge capacity, safe draining and same-name recreation. WAYSCloud production qualification (2026-09-26) ran this path end to end with running workloads, load balancing and persistent storage remaining available.
• Manual: only the control plane is upgraded; the worker upgrade remains a separate, explicit node-pool action.

The portal and the CLI/SDK request the rolling strategy by default. A direct API call that omits the strategy field means manual, so automation should send the strategy explicitly.

Upgrades do not change your monthly price: the cluster fee and the node prices stay the same, and the temporary capacity used while worker nodes are replaced is included.

Available upgrade targets can be viewed through the WAYSCloud portal, REST API and CLI:

cloud k8s upgrade <cluster-id>        # list available upgrades
cloud k8s upgrade <cluster-id> 1.35   # start the upgrade

What happens during an upgrade

• The Kubernetes control plane is upgraded first.
• Brief Kubernetes API interruptions may occur while the control plane is being updated.
• Applications running on worker nodes are not necessarily interrupted by the control-plane upgrade itself.
• The exact duration and behaviour can vary between upgrades, so do not assume that the Kubernetes API will remain continuously available during every control-plane upgrade.

Worker nodes

The control plane and worker nodes have separate version lifecycles, and the worker state is explicit:

• The API and portal report each pool's kubelet version and the cluster's worker skew against the control plane.
• A node pool that is two or more minors behind the control plane blocks further control-plane upgrades until it is converged.
• POST /v1/kubernetes/clusters/{id}/node-pools/{pool}/upgrade converges one pool at a time: new surge capacity is created first, the old nodes are drained with PodDisruptionBudget awareness, and the pool is recreated under the same name — capacity never drops below the configured node count.
• An upgrade never reports plain "completed" while workers are behind: a rolling upgrade completes only once the kubelets have converged, and a manual upgrade reports control plane upgraded; workers on the previous version until the pools are upgraded.

Maintenance windows and scheduled upgrades

Maintenance windows and scheduled upgrades are available per cluster through the portal, the API (GET/PUT/DELETE /v1/kubernetes/clusters/{id}/maintenance-window) and the CLI.

• A window has an IANA timezone, weekdays, a local start time and a duration. Occurrence math is DST-safe: an invalid spring-forward occurrence is skipped, and an ambiguous fall-back time uses the first occurrence.
• Upgrade modes: immediate, next_maintenance_window, and scheduled — an explicit timestamp that must fall inside a valid window occurrence.
• Scheduled upgrades are queued, cancellable, and retried with bounds on failure. If the maintenance window is changed after an upgrade is scheduled, WAYSCloud never silently moves the upgrade or runs it outside the approved plan: the job is marked window_invalidated and the next step is a new customer decision.

Backups and the pre-upgrade check

Before an upgrade starts, the portal and the API run a preflight check over the cluster:

• Blockers — for example an upgrade already queued or running, a node pool still converging or not fully running, worker skew of two or more minors, an unavailable target version, a missing maintenance window, or a provider capacity issue — are returned as structured errors and the upgrade is refused until they clear.
• Advisory warnings — for example that the latest completed backup is old, or missing — are shown with the option to continue deliberately.
• Every preflight is recorded in the cluster's audit history.

The backup decision is always explicit — Backup and upgrade or Upgrade without new backup; there is no implicit default:

• Backup and upgrade starts an on-demand backup first and continues only when it has completed successfully.
• Upgrade without new backup skips a new backup for this upgrade; existing on-demand and scheduled backups are unaffected.

On-demand and scheduled backups remain separate features, described with the backup and restore capability. Backups are charged by the storage they use, so a pre-upgrade backup is billed as backup storage like any other.

Version transition and end of life

• WAYSCloud removes older Kubernetes versions from new cluster creation before they become unsuitable for new deployments, following the published dates above.
• Existing clusters are not force-upgraded by WAYSCloud.
• Staged e-mail notices are sent ahead of an upgrade_required_by date — 60, 30, 14 and 7 days, and 24 hours before — in all five customer languages. The notices are part of service updates and can be opted out of; the deadline itself remains visible in the API and portal regardless of notification settings.
• Security-critical situations are handled as explicit exceptions with direct communication; there is no forced-upgrade tooling today.

Communication

• Portal — version lifecycle, per-pool worker versions, maintenance windows, upgrade jobs and the full upgrade history at my.wayscloud.services/kubernetes.
• E-mail — staged lifecycle notices, queue/schedule confirmations and upgrade completion messages through service updates (opt-out available).
• API — lifecycle state (GET /v1/kubernetes/versions), clusters, node pools, upgrades, jobs, maintenance windows and history.
• Changelog — platform changes are announced in the WAYSCloud changelog.

Operational expectations

For platform teams planning upgrades:

• upgrades are customer-initiated and sequential, one minor version at a time
• the rolling worker strategy is the default; a strategy-less direct API call means manual
• the control plane upgrades first; brief Kubernetes API interruptions may occur
• worker convergence is automatic with rolling, and an explicit per-pool action with manual
• maintenance windows and scheduled upgrades are available, DST-safe and never silently moved
• the pre-upgrade check blocks on real blockers and warns on advisory risks
• the backup decision is explicit for every upgrade

Related documentation

• Managed Kubernetes
• Kubernetes API reference
• WAYSCloud CLI
• Python SDK