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.
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.
Matrice des versions supportées
Le tableau suivant présente les versions Kubernetes prises en charge par la plateforme Rancher actuelle :
2.11
1.30, 1.31, 1.32
2.12
1.31, 1.32, 1.33
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
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.
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
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 :
Redémarrage des pods nœud après nœud : 10% des nœuds à la fois
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".
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 :
Pour identifier les objets obsolètes qui vont être supprimés dans la prochain version Kubernetes :
Un exemple de l'output :
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 :
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
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
La mise à jour peut prendre plusieurs minutes selon la taille du cluster.
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 :
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
Versions actuellement supportées
Les versions Kubernetes suivantes sont actuellement supportées sur cegedim.cloud :
Kubernetes 1.31
Supportée
Kubernetes 1.32
Dernière version supportée
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.
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 :
Exemples de mise à jour
Exemple 1 : Mise à jour de 1.31 vers 1.32 (versions actuellement supportées)
Chemin :
1.31 → 1.32La 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.32Si votre cluster est en 1.30 :
1.30 → 1.31 → 1.32Vous devez passer par toutes les versions intermédiaires qui ont été publiées par cegedim.cloud
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.
Last updated