Upgrade
This page covers the upgrade procedures for both Kubernetes clusters and the Rancher management platform.
Rancher Upgrade Schedule
To ensure that the cegedim.cloud infrastructure remains up-to-date with the latest features, security patches, and Kubernetes version support, Rancher is upgraded on a quarterly basis.
Scheduled Upgrade Windows
Rancher upgrades are performed on the Thursday closest to the following dates:
January 15th (Q1)
April 15th (Q2)
July 15th (Q3)
October 15th (Q4)
What to Expect
During Rancher upgrades:
Cluster Management: Your Kubernetes clusters continue to run without interruption. Workloads are not affected by Rancher upgrades.
Rancher UI Access: The Rancher management interface may be temporarily unavailable during the upgrade window (typically 15-30 minutes).
kubectl Access: If your kubectl is configured to access the Kubernetes API through Rancher URL, you may experience temporary connectivity issues during the upgrade window, as the API is proxied through Rancher. Direct cluster access remains functional.
New Kubernetes Versions: Rancher upgrades provide access to more recent Kubernetes versions, enabling you to upgrade your clusters to benefit from the latest features and improvements.
Enhanced Features: You gain access to new Rancher capabilities and improvements in cluster management tools.
After each Rancher upgrade, newer Kubernetes versions may become available after validation by the provider. Check the ITCare UI to see which Kubernetes versions are available for your clusters.
Supported Version Matrix
The following table shows the Kubernetes versions supported by the current Rancher platform:
2.11
1.30, 1.31, 1.32
2.12
1.31, 1.32, 1.33
Kubernetes Version Lifecycle Policy
cegedim.cloud maintains Kubernetes version support in alignment with Rancher's quarterly upgrade schedule:
Active Support: Kubernetes versions are fully supported and receive security patches as validated and released through ITCare
Version Availability: New Kubernetes versions become available after Rancher upgrades and provider validation
Customer Responsibility: Customers are responsible for maintaining their clusters on supported Kubernetes versions
It is important to keep your clusters updated with supported Kubernetes versions. Customers should plan regular upgrades following the quarterly Rancher upgrade cycle to ensure continued access to security patches and new features.
Non-Compliant Cluster Handling Policy
Important: Clusters that cannot be upgraded to be compatible with incoming Rancher versions will be subject to the following policy:
Identification: Clusters incompatible with the upcoming Rancher version will be identified by IT, and customers will be informed.
Month 1: If no action is taken within 1 month, the cluster will be temporarily detached from Rancher management. Customers will be provided with minimum access for cluster usage.
Month 2-3: If no action is taken within the next 2 months, the cluster will be permanently detached to allow Rancher upgrade. If the customer makes changes to achieve cluster compliance, the cluster will be re-attached.
Month 3+: If the customer makes the cluster compliant within 3 months, IT will attempt to re-attach the cluster, but this is best effort without any guarantee.
This policy ensures platform stability while allowing time for customers to address compatibility issues.
PaaS upgrade workflow
Request
The update of a Kubernetes PaaS can be done in self-service on the Kubernetes cluster's resource page in ITCare
It is recommended that you upgrade your non-production environments first in order to estimate the downtime generated by the operation and to test your applications using the new engine version.
Process
The Kubernetes cluster upgrade follows these steps through a Rolling Update process :
Pods reboot one node after another : 10% of the nodes at a time
Post-upgrade validation (health checks, monitoring).
Impacts
Some API versions can be obsolete or even deleted during a Kubernetes upgrade. There is a risk of breakage if you have resources with an API version that has been removed in the new version of Kubernetes.
To avoid this issue, you can check compatibility with the tool "kubent".
Kubent checks obsolete objects on the Kubernetes cluster. You need to migrate/change the identified resources before upgrading Kubernetes.
Check compatibility before a Kubernetes upgrade
To install kubent :
To identify obsolete objects that will be deleted in the next Kubernetes version :
An output exemple :
In this tutorial, if your cluster has an upgrade planned to the Kubernetes version 1.22, you need to migrate the ingress resource named "toto" of the API version networking.k8s.io/v1beta1 to networking.k8s.io/v1 before the upgrade.
This migration can imply a change of more fields in the resource. Please check the official documentation :
Kubent could fail to report some information, for instance the ingress namespace, you can report this issue to the publisher : https://github.com/doitintl/kube-no-trouble/issues
Upgrade the Kubernetes cluster
On the top of your cluster's page, click on the Manage button, then Update. An information popup will be displayed, click on Sumit
The upgrade can take several minutes depending of the size of the cluster.
Time references
A Kubernetes cluster upgrade typically takes around 15 minutes on average. Nodes will be upgraded one after another with no more than 10% of the cluster's node at the same time
Note that these times are estimates and can vary depending on the cluster configuration
OS / Kubernetes support matrix
Linux distributions supported by cegedim.cloud depending on the Kubernetes version:
Kubernetes 1.31
Ubuntu 22.04, 24.04
Kubernetes 1.32
Ubuntu 22.04, 24.04
Supported Kubernetes upgrade paths
Upgrade Policy
Currently Supported Versions
The following Kubernetes versions are currently supported on cegedim.cloud:
Kubernetes 1.31
Supported
Kubernetes 1.32
Latest supported version
Note: Kubernetes versions 1.28 and 1.30 are no longer supported. If your cluster is running these versions, please upgrade to a supported version as soon as possible.
Upgrade Path Diagram
The diagram below illustrates the required upgrade paths between versions. Each arrow represents a mandatory upgrade step:
Upgrade Examples
Example 1: Upgrading from 1.31 to 1.32 (currently supported versions)
Path:
1.31 → 1.32Direct upgrade is possible as these are consecutive supported versions
Example 2: Upgrading from 1.28 or 1.30 (deprecated versions)
If your cluster is on 1.28:
1.28 → 1.30 → 1.31 → 1.32If your cluster is on 1.30:
1.30 → 1.31 → 1.32You must upgrade through all intermediate versions that were released by cegedim.cloud
Remember: The upgrade path depends on which versions are available on cegedim.cloud at any given time. Always check ITCare UI to see the current list of available versions before planning your upgrade.
Last updated