Chapitre 1. Des mises à niveau de cluster dédiées à OpenShift


Il est possible de planifier des stratégies de mise à niveau automatiques ou manuelles pour mettre à jour la version de vos clusters dédiés OpenShift. Les clusters dédiés à OpenShift peuvent être effectués via Red Hat OpenShift Cluster Manager ou OpenShift Cluster Manager CLI.

Les ingénieurs de fiabilité du site Red Hat (SRE) surveillent les progrès de la mise à niveau et corrigent les problèmes rencontrés.

Lorsque des mises à niveau sont disponibles pour votre cluster OpenShift Dedicated, vous pouvez passer à la dernière version via Red Hat OpenShift Cluster Manager ou OpenShift Cluster Manager CLI. Il est possible de définir vos stratégies de mise à niveau sur les clusters existants ou lors de la création de clusters, et les mises à niveau peuvent être programmées pour se produire automatiquement ou manuellement.

Important

Avant de mettre à niveau un OpenShift Dedicated on Google Cloud Platform (GCP) activé par la Fédération d’identité de travail (WIF), vous devez mettre à jour la configuration wif-config. En savoir plus, voir « Mises à niveau des clusters avec Workload Identity Federation (WIF) ».

Les ingénieurs de fiabilité du site Red Hat (SRE) fourniront une liste organisée des versions disponibles pour vos clusters dédiés OpenShift. Chaque cluster vous permettra d’examiner la liste complète des versions disponibles, ainsi que les notes de publication correspondantes. Le gestionnaire de cluster OpenShift permettra l’installation de clusters aux dernières versions prises en charge, et les mises à niveau peuvent être annulées à tout moment.

Il est également possible de fixer un délai de grâce pour la durée du respect des charges de travail protégées par PodDisruptionBudget lors des mises à niveau. Après ce délai de grâce, toute charge de travail protégée par PodDisruptionBudget qui n’a pas été vidé avec succès d’un nœud sera supprimée de force.

Note

L’ensemble des objets Kubernetes et PV de chaque cluster dédié OpenShift sont sauvegardés dans le cadre du service dédié OpenShift. Les sauvegardes de données d’application et d’application ne font pas partie du service dédié OpenShift. Assurez-vous d’avoir une politique de sauvegarde en place pour vos applications et vos données d’application avant la planification des mises à niveau.

Note

Lorsque vous suivez une stratégie de mise à niveau planifiée, il peut y avoir un délai d’une heure ou plus avant le début du processus de mise à niveau, même s’il s’agit d’une mise à niveau immédiate. De plus, la durée de la mise à jour peut varier en fonction de votre configuration de charge de travail.

1.1.1. Des mises à jour récurrentes

Les mises à niveau peuvent être programmées automatiquement un jour et une heure spécifiés par le propriétaire ou l’administrateur du cluster. Les mises à niveau se produisent sur une base hebdomadaire, sauf si une mise à niveau n’est pas disponible pour cette semaine.

Lorsque vous sélectionnez des mises à jour récurrentes pour votre cluster, vous devez fournir la reconnaissance d’un administrateur. Le gestionnaire de cluster OpenShift ne démarre pas les mises à jour programmées du flux y pour les versions mineures sans recevoir la reconnaissance d’un administrateur.

Note

Les stratégies de mise à niveau récurrentes sont facultatives et si elles ne sont pas définies, les stratégies de mise à niveau par défaut par défaut à l’individu.

1.1.2. Des mises à niveau individuelles

Lorsque vous optez pour des mises à jour individuelles, vous êtes responsable de la mise à jour de votre cluster. Lorsque vous sélectionnez une version de mise à jour qui nécessite l’approbation, vous devez fournir la reconnaissance d’un administrateur.

Lorsque votre version de cluster devient obsolète, elle passera à un statut de support limité. Consultez OpenShift pour plus d’informations sur les politiques de cycle de vie OpenShift.

1.1.3. Les notifications de mise à niveau

Depuis la console OpenShift Cluster Manager, vous pouvez visualiser l’historique de votre cluster à partir de l’onglet Aperçu. Les états de mise à niveau peuvent être visualisés dans le journal de service sous la rubrique historique du cluster.

Chaque changement d’état déclenche également une notification par e-mail au propriétaire du cluster et aux utilisateurs abonnés. Les notifications par e-mail vous seront communiquées pour les événements suivants:

  • La mise à niveau est prévue.
  • La mise à jour a commencé.
  • La mise à niveau est terminée.
  • La mise à jour a été annulée.
Note

En cas de mises à niveau récurrentes, vous recevrez également des notifications par e-mail avant que la mise à jour ne se produise en fonction de la cadence suivante:

  • 2 semaines de préavis
  • 1 semaine de préavis
  • 1 jour de préavis

Avant de mettre à niveau un cluster OpenShift dédié sur Google Cloud Platform (GCP) avec le type d’authentification WIF vers une version plus récente du flux y, vous devez également mettre à jour la configuration WIF vers cette version. Le défaut de le faire avant de tenter de mettre à niveau la version du cluster entraînera une erreur. Consultez la section Ressources supplémentaires pour plus d’informations sur la mise à jour d’une configuration WIF.

Note

Le chemin de mise à jour vers une toute nouvelle version d’OpenShift Dedicated n’est disponible dans le canal stable que 45 à 90 jours après l’AG initiale d’une nouvelle version y-stream.

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat