# Upgrade

This page covers the upgrade procedures for both **Kubernetes clusters** and the **Rancher management platform**.

## **Rancher Upgrade Schedule** <a href="#k8supgrade-rancherupgradeschedule" id="k8supgrade-rancherupgradeschedule"></a>

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.

{% hint style="info" %}
Customers will be notified in advance of scheduled Rancher upgrades. No action is required on your part for Rancher platform upgrades.
{% endhint %}

{% hint style="success" %}
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.
{% endhint %}

### Supported Version Matrix <a href="#k8supgrade-supportedversionmatrix" id="k8supgrade-supportedversionmatrix"></a>

The following table shows the Kubernetes versions supported by the current Rancher platform:

| Rancher Version | Supported Kubernetes Versions (RKE2) |
| --------------- | ------------------------------------ |
| 2.11            | 1.30, 1.31, 1.32                     |
| 2.12            | 1.31, 1.32, 1.33                     |

{% hint style="info" %}
While Rancher upgrades enable support for newer Kubernetes versions, their availability for your clusters is validated and controlled by **cegedim.cloud** through the ITCare UI. Check ITCare regularly to see which Kubernetes versions are available for upgrade.
{% endhint %}

### Kubernetes Version Lifecycle Policy <a href="#k8supgrade-versionlifecyclepolicy" id="k8supgrade-versionlifecyclepolicy"></a>

**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

{% hint style="info" %}
Before releasing any new Kubernetes version to ITCare self-service, point-in-time backup/restore of ETCD is carefully tested by IT to ensure data integrity and cluster recoverability.
{% endhint %}

{% hint style="warning" %}
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.
{% endhint %}

#### Non-Compliant Cluster Handling Policy

{% hint style="warning" %}
**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.
{% endhint %}

## **PaaS upgrade workflow** <a href="#k8supgradeinplace-k8spaasupgrade" id="k8supgradeinplace-k8spaasupgrade"></a>

### Request <a href="#k8supgradeinplace-request" id="k8supgradeinplace-request"></a>

The update of a Kubernetes PaaS can be done in self-service on the Kubernetes cluster's resource page in [ITCare](https://itcare.cegedim.cloud)

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 <a href="#k8supgradeinplace-process" id="k8supgradeinplace-process"></a>

The Kubernetes cluster upgrade follows these steps through a **Rolling Update** process :

1. Pods reboot one node after another : 10% of the nodes at a time
2. 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".

{% embed url="<https://github.com/doitintl/kube-no-trouble>" %}

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 :

```bash
sh -c "$(curl -sSL 'https://git.io/install-kubent')"
```

To identify obsolete objects that will be deleted in the next Kubernetes version :

```
kubent [--context my-cluster]
```

An output exemple :

{% code fullWidth="true" %}

```
...
__________________________________________________________________________________________
>>> Deprecated APIs removed in 1.22 <<<
------------------------------------------------------------------------------------------
KIND                       NAMESPACE      NAME                                   API_VERSION                         REPLACE_WITH (SINCE)
Ingress                    <undefined>     toto                                 networking.k8s.io/v1beta1           networking.k8s.io/v1 (1.19.0)
...
```

{% endcode %}

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 :

{% embed url="<https://kubernetes.io/docs/home/>" %}

{% hint style="danger" %}
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>
{% endhint %}

**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**

{% hint style="warning" %}
The upgrade can take several minutes depending of the size of the cluster.
{% endhint %}

{% @supademo/embed url="<https://app.supademo.com/demo/cmam706440bci2gbp5sts8p52>" demoId="cm0xxrbp40091132huaivveld" %}

### Time references <a href="#k8supgradeinplace-timereferences" id="k8supgradeinplace-timereferences"></a>

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** <a href="#k8supgradeinplace-os-k8ssupportmatrixmatrice" id="k8supgradeinplace-os-k8ssupportmatrixmatrice"></a>

Linux distributions supported by **cegedim.cloud** depending on the Kubernetes version:

| Kubernetes Version | Supported Linux Distributions |
| ------------------ | ----------------------------- |
| Kubernetes 1.31    | Ubuntu 22.04, 24.04           |
| Kubernetes 1.32    | Ubuntu 22.04, 24.04           |

## **Supported Kubernetes upgrade paths** <a href="#k8supgradeinplace-supportedk8supgradepaths" id="k8supgradeinplace-supportedk8supgradepaths"></a>

### Upgrade Policy

{% hint style="info" %}
**cegedim.cloud** does not release every Kubernetes minor version. For example, the platform may support versions 1.28, 1.30, 1.31, and 1.32, skipping version 1.29.

**Important:** When upgrading your cluster, you **must** go through **all minor versions** that are released by **cegedim.cloud**. You cannot skip any version that is available on the platform.
{% endhint %}

### Currently Supported Versions

The following Kubernetes versions are currently supported on **cegedim.cloud**:

| Available Version | Status                   |
| ----------------- | ------------------------ |
| Kubernetes 1.31   | Supported                |
| Kubernetes 1.32   | Latest supported version |

{% hint style="warning" %}
**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.
{% endhint %}

### Upgrade Path Diagram

The diagram below illustrates the required upgrade paths between versions. Each arrow represents a mandatory upgrade step:

{% @mermaid/diagram content="graph LR
v128\[Kubernetes 1.28<br/>deprecated] --> v130\[Kubernetes 1.30<br/>deprecated]
v130 --> v131\[Kubernetes 1.31<br/>✓ supported]
v131 --> v132\[Kubernetes 1.32<br/>✓ latest]

```
style v128 fill:#ffcccb,stroke:#cc0000,stroke-width:2px
style v130 fill:#ffcccb,stroke:#cc0000,stroke-width:2px
style v131 fill:#90EE90,stroke:#006400,stroke-width:2px
style v132 fill:#87CEEB,stroke:#0066cc,stroke-width:2px" %}
```

{% hint style="info" %}
The diagram shows the historical upgrade path. Versions 1.28 and 1.30 are no longer supported but are shown to illustrate the required upgrade sequence for clusters that may still be running these versions.
{% endhint %}

### Upgrade Examples

**Example 1:** Upgrading from 1.31 to 1.32 (currently supported versions)

* Path: `1.31 → 1.32`
* Direct 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.32`
* If your cluster is on 1.30: `1.30 → 1.31 → 1.32`
* You must upgrade through all intermediate versions that were released by cegedim.cloud

{% hint style="warning" %}
**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.
{% endhint %}