# Mise à jour

Cette page couvre les procédures de mise à jour pour les **clusters Kubernetes** et la **plateforme de gestion Rancher**.

## **Calendrier de mise à jour Rancher** <a href="#k8supgrade-rancherupgradeschedule" id="k8supgrade-rancherupgradeschedule"></a>

Pour garantir que l'infrastructure **cegedim.cloud** reste à jour avec les dernières fonctionnalités, correctifs de sécurité et la prise en charge des versions Kubernetes, **Rancher** est mis à jour sur une base trimestrielle.

### Fenêtres de mise à jour planifiées

Les mises à jour de Rancher sont effectuées le **jeudi le plus proche** des dates suivantes :

* **15 janvier** (Q1)
* **15 avril** (Q2)
* **15 juillet** (Q3)
* **15 octobre** (Q4)

### À quoi s'attendre

Pendant les mises à jour de Rancher :

* **Gestion des clusters** : Vos clusters Kubernetes continuent de fonctionner sans interruption. Les charges de travail ne sont pas affectées par les mises à jour de Rancher.
* **Accès à l'interface Rancher** : L'interface de gestion Rancher peut être temporairement indisponible pendant la fenêtre de mise à jour (généralement 15-30 minutes).
* **Accès kubectl** : Si votre kubectl est configuré pour accéder à l'API Kubernetes via l'URL Rancher, vous pouvez rencontrer des problèmes de connectivité temporaires pendant la fenêtre de mise à jour, car l'API est proxy via Rancher. L'accès direct au cluster reste fonctionnel.
* **Nouvelles versions Kubernetes** : Les mises à jour de Rancher donnent accès à des versions Kubernetes plus récentes, vous permettant de mettre à jour vos clusters pour bénéficier des dernières fonctionnalités et améliorations.
* **Fonctionnalités améliorées** : Vous avez accès à de nouvelles capacités Rancher et à des améliorations des outils de gestion de clusters.

  <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>Les clients seront informés à l'avance des mises à jour Rancher planifiées. Aucune action n'est requise de votre part pour les mises à jour de la plateforme Rancher.</p></div>

  <div data-gb-custom-block data-tag="hint" data-style="success" class="hint hint-success"><p>Après chaque mise à jour de Rancher, de nouvelles versions Kubernetes peuvent devenir disponibles après validation par le fournisseur. Consultez l'interface ITCare pour voir quelles versions Kubernetes sont disponibles pour vos clusters.</p></div>

  \### Matrice des versions supportées

Le tableau suivant présente les versions Kubernetes prises en charge par la plateforme Rancher actuelle :

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

**cegedim.cloud** maintient le support des versions Kubernetes en alignement avec le calendrier de mise à jour trimestriel de Rancher :

* **Support actif** : Les versions Kubernetes sont entièrement prises en charge et reçoivent des correctifs de sécurité tels que validés et publiés via ITCare
* **Disponibilité des versions** : Les nouvelles versions Kubernetes deviennent disponibles après les mises à jour de Rancher et la validation du fournisseur
* **Responsabilité du client** : Les clients sont responsables du maintien de leurs clusters sur des versions Kubernetes prises en charge

  <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>Avant de publier toute nouvelle version Kubernetes en libre-service ITCare, une sauvegarde/restauration ponctuelle d'ETCD est soigneusement testée par l'IT pour garantir l'intégrité des données et la récupérabilité du cluster.</p></div>

  <div data-gb-custom-block data-tag="hint" data-style="warning" class="hint hint-warning"><p>Il est important de maintenir vos clusters à jour avec les versions Kubernetes prises en charge. Les clients doivent planifier des mises à jour régulières en suivant le cycle de mise à jour trimestriel de Rancher pour garantir un accès continu aux correctifs de sécurité et aux nouvelles fonctionnalités.</p></div>

  \#### Politique de gestion des clusters non conformes

  <div data-gb-custom-block data-tag="hint" data-style="warning" class="hint hint-warning"><p><strong>Important :</strong> Les clusters qui ne peuvent pas être mis à jour pour être compatibles avec les versions Rancher à venir seront soumis à la politique suivante :</p></div>
* **Identification** : Les clusters incompatibles avec la prochaine version Rancher seront identifiés par l'IT, et les clients seront informés.
* **Mois 1** : Si aucune action n'est entreprise dans un délai d'1 mois, le cluster sera temporairement détaché de la gestion Rancher. Les clients disposeront d'un accès minimum pour l'utilisation du cluster.
* **Mois 2-3** : Si aucune action n'est entreprise dans les 2 mois suivants, le cluster sera définitivement détaché pour permettre la mise à jour de Rancher. Si le client effectue des modifications pour rendre le cluster conforme, le cluster sera ré-attaché.
* **Mois 3+** : Si le client rend le cluster conforme dans les 3 mois, l'IT tentera de ré-attacher le cluster, mais ce sera au mieux sans aucune garantie.

Cette politique garantit la stabilité de la plateforme tout en laissant du temps aux clients pour résoudre les problèmes de compatibilité.## **Processus de mise à jour du PaaS**

### Requête <a href="#k8supgradeinplace-request" id="k8supgradeinplace-request"></a>

La mise à jour d'un PaaS Kubernetes peut être effectuée en libre-service sur la page de ressource du cluster Kubernetes dans [ITCare](https://itcare.cegedim.cloud)

Il est recommandé de mettre à jour vos environnements de non-production d'abord afin d'estimer le temps d'arrêt généré par l'opération et de tester vos applications utilisant la nouvelle version du moteur.

### Processus <a href="#k8supgradeinplace-process" id="k8supgradeinplace-process"></a>

La mise à jour du cluster Kubernetes suit ces étapes via un processus de **Rolling Update** :

1. Redémarrage des pods nœud après nœud : 10% des nœuds à la fois
2. Validation post-mise à jour (contrôles de santé, surveillance).

### Impacts

Certaines versions d'API peuvent être obsolètes ou même supprimées lors d'une mise à jour de Kubernetes. Il existe un risque de cassure si vous avez des ressources avec une version d'API qui a été supprimée dans la nouvelle version de Kubernetes.

Pour éviter ce problème, vous pouvez vérifier la compatibilité avec l'outil "kubent".

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

Kubent vérifie les objets obsolètes sur le cluster Kubernetes. Vous devez migrer/modifier les ressources identifiées avant de mettre à jour Kubernetes.

**Vérifier la compatibilité avant une mise à jour Kubernetes**

Pour installer kubent :

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

Pour identifier les objets obsolètes qui vont être supprimés dans la prochain version Kubernetes :

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

Un exemple de l'output :

{% code fullWidth="true" %}

```
```

{% endcode %}

Dans ce tutoriel, si votre cluster a une mise à jour planifiée vers la version Kubernetes 1.22, vous devez migrer votre ressource ingress nommée "toto" de la version API `networking.k8s.io/v1beta1` vers `networking.k8s.io/v1` avant la mise à jour.

Cette migration peut impliquer une modification de champs supplémentaires dans la ressource. Veuillez consulter la documentation officielle :

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

{% hint style="danger" %}
Kubent pourrait échouer à rapporter certaines informations, par exemple l'espace de noms de l'ingress, vous pouvez signaler le problème à l'éditeur : <https://github.com/doitintl/kube-no-trouble/issues>
{% endhint %}

**Mettre à jour le cluster Kubernetes**

En haut de la page de votre cluster, cliquez sur le bouton **Gérer**, puis sur **Mettre à jour**. Une fenêtre d'information s'affichera, cliquez sur **Submit**

{% hint style="warning" %}
La mise à jour peut prendre plusieurs minutes selon la taille du cluster.
{% endhint %}

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

\### Temps de référence

Une mise à jour de cluster Kubernetes prend généralement environ 15 minutes en moyenne. Les nœuds seront mis à jour les uns après les autres avec un maximum de 10% des nœuds du cluster en même temps.

Notez que ces temps sont des estimations et peuvent varier selon la configuration du cluster.

## **Matrice de support OS / Kubernetes** <a href="#k8supgradeinplace-os-k8ssupportmatrixmatrice" id="k8supgradeinplace-os-k8ssupportmatrixmatrice"></a>

Distributions Linux supportées par **cegedim.cloud** en fonction de la version de Kubernetes :

| Version Kubernetes | Distributions Linux supportées |
| ------------------ | ------------------------------ |
| Kubernetes 1.31    | Ubuntu 22.04, 24.04            |
| Kubernetes 1.32    | Ubuntu 22.04, 24.04            |

## **Chemins de mise à jour Kubernetes supportés** <a href="#k8supgradeinplace-supportedk8supgradepaths" id="k8supgradeinplace-supportedk8supgradepaths"></a>

### Politique de mise à jour**cegedim.cloud** ne publie pas toutes les versions mineures de Kubernetes. Par exemple, la plateforme peut supporter les versions 1.28, 1.30, 1.31 et 1.32, en omettant la version 1.29.

**Important :** Lors de la mise à jour de votre cluster, vous **devez** passer par **toutes les versions mineures** qui sont publiées par **cegedim.cloud**. Vous ne pouvez pas sauter une version disponible sur la plateforme.### Versions actuellement supportées

Les versions Kubernetes suivantes sont actuellement supportées sur **cegedim.cloud** :

| Version disponible | Statut                     |
| ------------------ | -------------------------- |
| Kubernetes 1.31    | Supportée                  |
| Kubernetes 1.32    | Dernière version supportée |

Le diagramme ci-dessous illustre les chemins de mise à jour requis entre les versions. Chaque flèche représente une étape de mise à jour obligatoire :

{% @mermaid/diagram content="graph LR
v128\[Kubernetes 1.28<br/>obsolète] --> v130\[Kubernetes 1.30<br/>obsolète]
v130 --> v131\[Kubernetes 1.31<br/>✓ supportée]
v131 --> v132\[Kubernetes 1.32<br/>✓ dernière]

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

```<div data-gb-custom-block data-tag="hint" data-style='info'>Le diagramme montre le chemin de mise à jour historique. Les versions 1.28 et 1.30 ne sont plus supportées mais sont affichées pour illustrer la séquence de mise à jour requise pour les clusters qui pourraient encore utiliser ces versions.</div>### Exemples de mise à jour

**Exemple 1 :** Mise à jour de 1.31 vers 1.32 (versions actuellement supportées)
- Chemin : `1.31 → 1.32`
- La mise à jour directe est possible car ce sont des versions supportées consécutives

**Exemple 2 :** Mise à jour depuis 1.28 ou 1.30 (versions obsolètes)
- Si votre cluster est en 1.28 : `1.28 → 1.30 → 1.31 → 1.32`
- Si votre cluster est en 1.30 : `1.30 → 1.31 → 1.32`
- Vous devez passer par toutes les versions intermédiaires qui ont été publiées par cegedim.cloud<div data-gb-custom-block data-tag="hint" data-style='warning'>**Rappel :** Le chemin de mise à jour dépend des versions disponibles sur **cegedim.cloud** à un moment donné. Consultez toujours l'interface ITCare pour voir la liste actuelle des versions disponibles avant de planifier votre mise à jour.</div>" %}
```