Kubernetes community releases currently happen approximately three times per year.
These are called minor version releases (the y in v1.y.0),
and contain new features and bug fixes.
Patch version releases (the z in v1.31.z) are released more frequently,
and include minor bug fixes, OS updates, and patches for critical security vulnerabilities.
Catalyst Cloud Kubernetes Service supports each minor version for at least 6 months before it transitions to unsupported, giving users enough time to upgrade their clusters. See the table below for currently supported versions and the expected date they become unsupported.
This table documents Catalyst Cloud Kubernetes Service minor versions, and their supported status. It does not show patch versions, as all patch versions for a supported minor version are supported.
Version |
Current Status |
Initial Release Date |
Unsupported Date |
|---|---|---|---|
|
Unsupported |
2024-04-18 |
2024-12-20 |
|
Unsupported |
2024-05-27 |
2025-03-19 |
|
Supported |
2024-08-26 |
Expected 2025-06-28 |
|
Supported |
2024-12-20 |
Expected 2025-10-28 |
|
Supported |
2025-02-05 |
Expected 2026-02-28 |
Kubernetes release changelog for v1.32 since v1.31.
In addition to the Kubernetes changes, we have:
Upgraded minor versions of Calico CNI, CoreDNS, Cinder CSI and Cloud Provider Openstack.
Upgraded patch version of k8s-keystone-auth.
Upgraded base OS Flatcar to latest stable release.
Note that skipping minor versions when upgrading a cluster is unsupported and should not be attempted. For example, before upgrading to v1.32.x, you must be running at least v1.31.x.
Kubernetes release changelog for v1.31 since v1.30.
In addition to the Kubernetes changes, we have:
Upgraded minor versions of Calico CNI, CoreDNS, Cinder CSI and Cloud Provider Openstack.
Upgraded patch version of etcd.
Upgrades base OS flatcar to latest stable release.
Note that skipping minor versions when upgrading a cluster is unsupported and should not be attempted. For example, before upgrading to v1.31.x, you must be running at least v1.30.x.
Kubernetes release changelog for v1.30 since v1.29.
In addition to the Kubernetes changes, we have:
Upgraded minor version of Calico CNI.
Upgraded minor version of Cinder CSI and Cloud Provider Openstack.
Upgrades base OS flatcar to latest stable release.
Note that skipping minor versions when upgrading a cluster is unsupported and should not be attempted. For example, before upgrading to v1.30.x, you must have upgraded to v1.29.x.
This is the first minor version upgrade of CCKS that supports upgrade of existing clusters.
Kubernetes release changelog for v1.29 since v1.28.
In addition to the Kubernetes changes, we have:
Extended Role-Based Access Control to deny access to namespaces created by CCKS in addition to kube-system. These include openstack-system, tigera-operator, calico-apiserver and calico-system. This affects users with roles k8s_viewer and k8s_developer.
Upgraded patch version of Calico CNI.
Upgraded minor version of Cinder CSI and Cloud Provider Openstack.
Note: There is an outstanding issue during this upgrade where the cluster control plane may become unavailable for a short duration.
To read more about performing a cluster upgrade, refer to Upgrading a cluster.
The upgrade path for clusters of version v1.27 and prior is to build a new cluster and migrate your workloads. For more information see Rebuilding vs in-place upgrade.
There are several changes to be aware of when deploying your workloads onto a newly built v1.28 cluster that are different to the older v1.27 and below clusters.
Kubernetes release changelog for v1.28 since v1.27.
In addition to the Kubernetes changes, CCKS has had a significant change in the driver used to create clusters and several aspects have been revised.
The major differences are:
The operating system for control plane and worker nodes is replaced with Flatcar Container OS (was Fedora Core OS).
CCKS now runs several operations from within a management cluster. This is largely not visible to end users, but includes cluster operations such as:
Auto-scaling pods (if configured) run within the management cluster.
Auto-healing events (if configured) are monitored and actions taken from within the management cluster.
Reconciliation loops within the management cluster keep resources in the desired state. This means temporary failures are re-tried so cluster operations succeed more often, and some cluster resources are re-created if they are inadvertently deleted.
Heat Stacks are no longer created in the customer project (in fact, they aren’t created anywhere)
Customer SSH Keypairs are no longer placed on all nodes.
CCKS no longer offers Prometheus and Grafana stack as a managed deployment. You can gain the same features by installing the kube-prometheus-stack helm charts, and gain customisation options.
The Octavia Ingress Controller is no longer installed as a managed deployment.
CCKS supports Kubernetes Service objects with type: Loadbalancer.
This creates a single Octavia Loadbalancer for that service.
For ingress solutions that loadbalance to multiple services within your cluster you can install
Ingress-NGINX, Traefik Ingress, Octavia Ingress controller or another controller.
As with all upgrades you are advised to test this in a non-production environment, and ensure all workloads and operations remain functional for your use-case.
Kubernetes versions follow Semantic Versioning terminology.
Versions are expressed as x.y.z, where x is the major version, y is the minor version
and z is the patch version.
Version Part |
Example |
Description |
|---|---|---|
Major |
|
Versions that may make incompatible API changes |
Minor |
|
Versions that adds functionality in a backwards compatible manner |
Patch |
|
Versions that makes backwards compatible bug fixes |
Catalyst Cloud Kubernetes Service uses Cluster Templates to manage each Kubernetes version, and the matrix of addons that make up our a managed Kubernetes cluster.
Users are able to see the Kubernetes version from the Cluster Template name. For example:
kubernetes-v1.31.4-20241220
Here, the Kubernetes version is v1.31.4 (Major version 1, Minor version 31 and Patch version 4).
The template creation date is 20th December 2024.
The Cluster Template name contains the specific Kubernetes semantic version,
and a date in YYYYMMDD format which represents the release date of the template on Catalyst Cloud.
A Cluster Template with the same Kubernetes version and a later release date should always be preferred over an older release date. This is to allow for bug fixes or Operating System upgrades within the same Kubernetes patch version.
For more information, see Kubernetes Releases.
Catalyst Cloud Kubernetes Service supports at least 3 minor versions.
When there is a new minor version released by the Kubernetes project, Catalyst Cloud Kubernetes Service will work get it certified (passing the CNCF conformance test) and Cluster Templates will be created.
When a new minor version is released, we will update the section Supported Kubernetes Versions with the new version and the expected date it will become unsupported. There are times we will extend this date, and the table will be updated.
An unsupported version means when users ask for support, you will be asked to upgrade your cluster to a supported version first.
Catalyst Cloud Kubernetes Service create new Cluster Templates when a new Kubernetes patch version is released, or an Operating System updated is available on our cloud. When a new Cluster Template is created, any existing Cluster Templates for the same minor version will be hidden.
For example, when we release patch version v1.31.2, the Cluster Template for
the previous patch version, v1.31.1 will be marked as hidden.
Note
Hiding a patch Cluster Template does not mean it is out of support.
It simply means we are motivating customers to always create new clusters
using the latest Cluster Template for that supported minor version.
Users should aim to run the latest patch for each minor version to get the latest security and bug fixes.
Note
Catalyst Cloud reserves the right to add/remove a new/existing Cluster Template, if there is a critical issue identified in the version, without further notice.
You can find the set of Cluster Templates which are currently available on Catalyst Cloud Kubernetes Service in the web interface as well as on the command line.
$ openstack coe cluster template list
+--------------------------------------+------------------------------+------+
| uuid | name | tags |
+--------------------------------------+------------------------------+------+
| 59b4440d-05f1-4088-971c-60d5bd11690c | kubernetes-v1.30.7-20241121 | None |
| ee9d62ac-bbf1-4b88-9e2a-d5e083e73708 | kubernetes-v1.31.4-20241220 | None |
| 5613be85-5f5f-45ca-9f60-cad5c2850224 | kubernetes-v1.32.1-20250121 | None |
+--------------------------------------+------------------------------+------+
When upgrading a cluster to a new version, skipping minor versions is unsupported.
For example, if the current cluster version is v1.29.x, then you cannot upgrade directly to a v1.31.x. You have to upgrade to v1.30.x first, and then perform another upgrade to v1.31.x.
This is in line with the Kubernetes Version Skew policy, and also takes into account the additional components that Catalyst Cloud Kubernetes Service is formed with.
Warning
Catalyst Cloud reserves the right to force a patch version upgrade if
there is an urgent critical security vulnerability
(CVE rated as HIGH or CRITICAL), and the customer cannot be contacted.