Versions¶

Version v1.30 to v1.31¶

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.

Version v1.29 to v1.30¶

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.

Version v1.28 to v1.29¶

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.

Version v1.27 to v1.28¶

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.

Version 1.26 and below¶

The upgrade path for clusters of version v1.27 and prior is build a new cluster and migrate your workloads.

For more information see Rebuilding vs in-place upgrade.

Finding Available Versions¶

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                                                                            |
+--------------------------------------+-----------------------------------+---------------------------------------------------------------------------------+
| 456a5390-67c3-4a89-b1e8-ba8dbf529506 | kubernetes-v1.26.14-prod-20240218 | environment:prod,build_id:20240218,pipeline_id:40826,created_at:20240218T183133 |
| b922a741-099a-4987-bc32-d5f3e3a4beed | kubernetes-v1.27.11-prod-20240218 | environment:prod,build_id:20240218,pipeline_id:40827,created_at:20240218T183254 |
| dafe4576-8de0-4024-a12a-1bc5197b474f | kubernetes-v1.28.9-20240416       | None                                                                            |
+--------------------------------------+-----------------------------------+---------------------------------------------------------------------------------+

Upgrading Kubernetes Versions¶

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.