Appearance

Kubernetes version lifecycle and upgrades ​

WAYSCloud keeps the Kubernetes version catalogue deliberately small and predictable.

New Kubernetes versions are qualified before they are made available to customers, and upgrades are performed sequentially, one minor version at a time.

Current versions ​

VersionStatusNew clusters
1.35DefaultYes
1.34TransitionUntil 15 October 2026
1.33 and olderNot offeredNo

Kubernetes 1.35 is the default version for new clusters.

Kubernetes 1.34 remains available for new clusters until 15 October 2026 as a transition release.

Older versions are not offered for new clusters.

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.

Upgrade path ​

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

text
1.34 → 1.35

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

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

Upgrades are currently customer-initiated and begin when requested.

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.
  • WAYSCloud production qualification has included a live upgrade from Kubernetes 1.34 to 1.35 with running workloads, load balancing and persistent storage remaining available throughout the upgrade.

The exact duration and behaviour can vary between upgrades, so customers should 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.

With the current manual upgrade strategy, upgrading the control plane does not automatically upgrade the kubelet version on worker nodes. For example, after a qualified 1.34 → 1.35 control-plane upgrade, worker nodes may remain on Kubernetes 1.34 until their node pools are upgraded or replaced.

WAYSCloud is extending the worker upgrade workflow to provide clearer node-version visibility and managed worker convergence. Customers should not assume that a control-plane upgrade immediately places every worker node on the same minor version.

Backups before upgrades ​

WAYSCloud does not automatically create a backup before a Kubernetes upgrade.

If you want a fresh recovery point before upgrading, create an on-demand backup first:

bash
cloud k8s backup <cluster-id>

Verify available backups with:

bash
cloud k8s backups <cluster-id>

Maintenance windows ​

Customer-defined maintenance windows and scheduled Kubernetes minor upgrades are not currently available. Today, upgrades are explicitly initiated by the customer and begin when requested.

WAYSCloud is working on maintenance-window support so platform teams can schedule future upgrades against their own operational windows. Until that functionality is available, customers should initiate upgrades at a time appropriate for their own workloads and operational requirements.

Version transition and end of life ​

  • WAYSCloud removes older Kubernetes versions from new cluster creation before they become unsuitable for new deployments.
  • Existing clusters are not currently force-upgraded by WAYSCloud.
  • Transition dates are published so customers can plan upgrades ahead of time; existing clusters continue to run and can normally still be upgraded.
  • WAYSCloud is extending the lifecycle system with machine-readable version state and customer notifications for future transition and upgrade deadlines.

Operational expectations ​

For platform teams planning upgrades:

  • upgrades are customer-initiated
  • minor upgrades are sequential
  • the control plane upgrades first
  • worker nodes may remain on the previous kubelet version until explicitly converged
  • brief Kubernetes API interruptions may occur
  • no automatic backup is taken before an upgrade
  • maintenance windows are not yet available
  • available upgrade targets are exposed through the portal, API and CLI