> For the complete documentation index, see [llms.txt](https://academy.cegedim.cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://academy.cegedim.cloud/francais/calcul/conteneurs-k8s/k8s-didacticiels/k8s-mise-a-jour.md). # 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** 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. {% hint style="info" %} 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. {% endhint %} {% hint style="success" %} 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. {% endhint %} ### 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 | {% hint style="info" %} Bien que les mises à jour de Rancher permettent la prise en charge de nouvelles versions Kubernetes, leur disponibilité pour vos clusters est validée et contrôlée par **cegedim.cloud** via l'interface ITCare. Consultez ITCare régulièrement pour voir quelles versions Kubernetes sont disponibles pour la mise à jour. {% endhint %} ### Politique de cycle de vie des versions Kubernetes **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 {% hint style="info" %} 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. {% endhint %} {% hint style="warning" %} 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. {% endhint %} #### Politique de gestion des clusters non conformes **Important :** Les clusters qui ne peuvent pas être mis à jour pour être compatibles avec les versions Rancher à venir seront soumis à la politique suivante : * **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 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 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). ```mermaid graph TD start["Kubernetes 1.28"] --> upgrade["Mise à niveau des nœuds du cluster
(pas plus de 10% des nœuds du cluster)"] upgrade --> validation["Validation post mise à niveau"] validation --> done["Kubernetes 1.32"] upgrade -.->|Pris en charge par cegedim.cloud| validation style start fill:#e8e8e8,stroke:#000,stroke-width:2px,color:#000 style upgrade fill:#c8e6c9,stroke:#2ca02c,stroke-width:2px,color:#000 style validation fill:#ffe0b2,stroke:#e8820c,stroke-width:2px,color:#000 style done fill:#e8e8e8,stroke:#000,stroke-width:2px,color:#000 ``` ### 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="" %} 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 : ``` ... __________________________________________________________________________________________ >>> Deprecated APIs removed in 1.22 <<< ------------------------------------------------------------------------------------------ KIND NAMESPACE NAME API_VERSION REPLACE_WITH (SINCE) Ingress toto networking.k8s.io/v1beta1 networking.k8s.io/v1 (1.19.0) ... ``` 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="" %} {% 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 : {% 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="" 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** 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 ### Politique de mise à jour {% hint style="info" %} **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. {% endhint %} ### 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 | {% hint style="warning" %} **Note :** Les versions Kubernetes 1.28 et 1.30 ne sont plus supportées. Si votre cluster utilise ces versions, veuillez effectuer la mise à jour vers une version supportée dès que possible. {% endhint %} ### Diagramme des chemins de mise à jour 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 graph LR v128["Kubernetes 1.28
deprecated"] --> v130["Kubernetes 1.30
deprecated"] v130 --> v131["Kubernetes 1.31
✓ supported"] v131 --> v132["Kubernetes 1.32
✓ latest"] style v128 fill:#ffcccb,stroke:#cc0000,stroke-width:2px,color:#000 style v130 fill:#ffcccb,stroke:#cc0000,stroke-width:2px,color:#000 style v131 fill:#90EE90,stroke:#006400,stroke-width:2px,color:#000 style v132 fill:#87CEEB,stroke:#0066cc,stroke-width:2px,color:#000 ``` {% hint 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. {% endhint %} ### 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 {% hint 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. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://academy.cegedim.cloud/francais/calcul/conteneurs-k8s/k8s-didacticiels/k8s-mise-a-jour.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.