Red Hat SummitLa mise à niveau
La mise à niveau d’OpenShift dédié
Résumé
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.
1.1. Comprendre les mises à niveau de cluster dédiées à OpenShift
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.
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.
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.
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.
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.
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
1.1.4. Les mises à niveau de cluster avec Workload Identity Federation (WIF)
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.
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.
1.2. La planification des mises à jour récurrentes pour votre cluster
Il est possible d’utiliser OpenShift Cluster Manager pour planifier des mises à niveau automatiques et récurrentes pour les versions de patch z-stream pour votre cluster dédié OpenShift. En fonction des changements en amont, il peut y avoir des moments où aucune mise à jour n’est publiée. Donc, aucune mise à niveau n’a lieu pour cette semaine.
Procédure
- Dans OpenShift Cluster Manager, sélectionnez votre cluster dans la liste des clusters.
- Cliquez sur l’onglet Paramètres de mise à niveau pour accéder à l’opérateur de mise à niveau.
- Afin de programmer des mises à jour récurrentes, sélectionnez Récurrence des mises à jour.
Fournissez la reconnaissance d’un administrateur et cliquez sur Approuver et continuer. 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.
ImportantAvant 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) ».
- Indiquez le jour de la semaine et l’heure à laquelle vous souhaitez que votre cluster soit mis à niveau.
- Cliquez sur Save.
- Facultatif: Définir un délai de grâce pour l’évacuation du nœud en sélectionnant un temps déterminé dans la liste déroulante. Le délai de grâce d’une heure est fixé par défaut.
- Afin d’éditer une stratégie de mise à niveau récurrente existante, modifiez la journée préférée ou l’heure de début à partir de l’onglet Paramètres de mise à niveau. Cliquez sur Save.
- Afin d’annuler une stratégie de mise à niveau récurrente, passez la méthode de mise à niveau à un individu à partir de l’onglet Paramètres de mise à niveau. Cliquez sur Save.
Dans l’onglet Paramètres de mise à niveau, la zone d’état de mise à niveau indique qu’une mise à niveau est programmée. La date et l’heure de la prochaine mise à jour prévue sont listées.
1.3. La planification des mises à niveau individuelles pour votre cluster
Il est possible d’utiliser OpenShift Cluster Manager pour mettre à niveau manuellement votre cluster OpenShift Dedicated une fois.
Procédure
- Dans OpenShift Cluster Manager, sélectionnez votre cluster dans la liste des clusters.
- Cliquez sur l’onglet Paramètres de mise à niveau pour accéder à l’opérateur de mise à niveau. Dans l’onglet Aperçu, vous pouvez également mettre à jour votre cluster en cliquant sur Mettre à jour à côté de la version du cluster sous la rubrique Détails.
- Afin de programmer une mise à jour individuelle, sélectionnez Mises à jour individuelles.
- Cliquez sur Mettre à jour dans la zone État de mise à jour.
- Choisissez la version vers laquelle vous souhaitez mettre à niveau votre cluster. Les mises à niveau de cluster recommandées apparaissent dans l’interface utilisateur. Cliquez sur Voir les notes de publication pour en savoir plus sur chaque version de mise à jour disponible.
Lorsque vous sélectionnez une version de mise à jour qui nécessite l’approbation, fournissez la reconnaissance d’un administrateur et cliquez sur Approuver et continuer.
ImportantAvant 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) ».
- Cliquez sur Next.
Afin de planifier votre mise à niveau:
- Cliquez sur Mise à niveau maintenant pour mettre à niveau dans l’heure suivante.
- Cliquez sur Planifier une heure différente et spécifiez la date et l’heure que vous souhaitez que le cluster soit mis à niveau.
- Cliquez sur Next.
- Examinez la politique de mise à niveau et cliquez sur Confirmer la mise à niveau.
- La confirmation apparaît lorsque la mise à niveau du cluster a été programmée. Cliquez sur Close.
- Facultatif: Définir un délai de grâce pour l’évacuation du nœud en sélectionnant un temps déterminé dans la liste déroulante. Le délai de grâce d’une heure est fixé par défaut.
À partir de l’onglet Aperçu, à côté de la version du cluster, l’interface utilisateur indique que la mise à jour a été programmée. Cliquez sur Afficher les détails pour afficher les détails de la mise à jour. Dans le cas où vous devez annuler la mise à niveau prévue, vous pouvez cliquer sur Annuler cette mise à niveau à partir du pop-up Afficher les détails.
Les mêmes détails de mise à niveau sont disponibles dans l’onglet Paramètres de mise à niveau sous la zone État de mise à niveau. Dans le cas où vous devez annuler la mise à niveau prévue, vous pouvez cliquer sur Annuler cette mise à niveau à partir de la zone d’état de mise à niveau.
Dans le cas où un CVE ou un autre problème critique à OpenShift Dedicated est trouvé, tous les clusters sont mis à niveau dans les 48 heures suivant la sortie du correctif. Lorsque le correctif est disponible, vous êtes informé que le cluster sera automatiquement mis à niveau au plus tard avant la fermeture de la fenêtre de 48 heures. Il est également possible de mettre à niveau manuellement à tout moment avant le début de la mise à niveau récurrente.
Legal Notice
Copyright © 2025 Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}