Cycle de vie du support pour Azure Red Hat OpenShift 4

Red Hat publie des versions mineures de Red Hat OpenShift Container Platform (OCP) tous les quatre mois environ. Ces versions contiennent de nouvelles fonctionnalités et des améliorations. Les mises en production des correctifs sont plus fréquentes (généralement hebdomadaires) et peuvent inclure des correctifs pour les vulnérabilités de sécurité ou les bogues.

Azure Red Hat OpenShift s’appuie sur certaines versions d’OCP. Cet article traite des versions d’OCP prises en charge pour Azure Red Hat OpenShift et fournit des informations sur les stratégies en matière de mises à jour, de dépréciations et de support.

Versions de Red Hat OpenShift

Red Hat OpenShift Container Platform utilise la Gestion sémantique de version. Celle-ci consiste à associer un niveau de numéros différent pour chaque version. Le tableau suivant illustre les différentes parties d’un numéro de version sémantique, dans ce cas à l’aide de l’exemple de numéro 4.15.16de version.

Version majeure (x)	Version mineure (y)	Version de patch (z)
4	15	16

• Version majeure : aucune publication de version majeure n’est planifiée pour l’instant. Les versions majeures impliquent des modifications importantes du service de base, telles que l’ajout à grande échelle de nouvelles fonctionnalités et fonctions, des modifications architecturales et la suppression de fonctions existantes.
• Version mineure : publiée approximativement tous les quatre mois. Les mises à jour de versions mineures peuvent inclure des ajouts de fonctionnalités, des améliorations, des dépréciations, des suppressions, des correctifs de bogues, des renforcements de la sécurité et d’autres améliorations.
• Version de patch : généralement publiée toutes les semaines, ou selon les besoins. Les mises à jour de versions de patch peuvent inclure des correctifs de bogues, des renforcements de la sécurité et d’autres améliorations.

Vous devez essayer d’exécuter la dernière version mineure de la version majeure que vous exécutez. Par exemple, si votre cluster de production s’exécute sur la version 4.14 alors que la dernière version mineure en disponibilité générale pour la série 4 est la version 4.15, passez dès que possible à la version 4.15.

Mettre à jour les canaux

Les canaux de mise à jour constituent le mécanisme par lequel les utilisateurs indiquent la version mineure d’OpenShift Container Platform vers laquelle ils souhaitent mettre à jour leurs clusters. Les canaux de mise à niveau sont liés à une version mineure de Red Hat OpenShift Container Platform (OCP). Le numéro de version dans le canal représente la version mineure cible vers laquelle le cluster sera finalement mis à jour. Un canal de mise à jour ne recommande pas les mises à jour d’une version supérieure à celle du canal sélectionné. Par exemple, le canal de mise à jour OCP stable-4.14 n’inclut pas de mise à jour vers une version 4.15. Les canaux de mise à niveau contrôlent uniquement la sélection des publications, sans apporter aucune modification à la version actuelle du cluster. Pour plus d’informations, consultez Présentation des canaux de mise à jour et des versions.

Importante

Azure Red Hat OpenShift ne fournit une prise en charge que pour les canaux stables. Par exemple : stable-4.15.

Vous pouvez utiliser le canal stable-4.15 pour effectuer une mise à jour à partir d’une version mineure précédente d’Azure Red Hat OpenShift. Les clusters mis à jour à l’aide des canaux fast ou candidate peuvent placer votre cluster dans un état de support limité.

Stratégie de prise en charge des versions Azure Red Hat OpenShift

Disponibilité des versions d’Azure Red Hat OpenShift

Une version d’Azure Red Hat OpenShift est disponible via l’un des deux mécanismes suivants :

• lorsqu’une mise à jour vers une version plus récente est disponible pour un cluster existant ;
• lorsqu’une nouvelle version est disponible comme cible d’installation pour un nouveau cluster.

Disponibilité des mises à jour

Azure Red Hat OpenShift prend en charge les versions mineures en disponibilité générale (GA) de Red Hat OpenShift Container Platform à partir du moment où une mise à jour est disponible dans le canal stable d’OpenShift. La disponibilité des mises à jour peut être vérifiée sur la page suivante, Graphique de mise à jour de la plateforme de conteneurs Red Hat OpenShift.

Disponibilité des installations

Les versions installables peuvent être validées à l’aide du calendrier de publication d’Azure Red Hat OpenShift ou en exécutant la commande Azure CLI suivante :

az aro get-versions --location [region]

Fin de vie de la version

La date de fin de vie d’une version d’Azure Red Hat OpenShift est disponible dans le calendrier de publication d’Azure Red Hat OpenShift.

Remarque

Si vous exécutez une version Red Hat OpenShift non prise en charge, vous serez peut-être invité à effectuer une mise à jour lors de la demande de support pour le cluster. Les clusters exécutant des versions Red Hat OpenShift non prises en charge ne sont pas couverts par le contrat de niveau de service (SLA) Azure Red Hat OpenShift.

Mises à jour obligatoires

Dans des circonstances extrêmes et en fonction de l’évaluation de la criticité des vulnérabilités et des expositions courantes (CVE) dans l’environnement, vous êtes averti que vous avez 72 heures pour mettre à jour votre cluster vers la dernière version sécurisée des correctifs. Dans le cas où la mise à jour n’est pas effectuée après 72 heures, une mise à jour corrective critique peut être appliquée automatiquement aux clusters par Azure Red Hat OpenShift Site Reliability Engineers (SRE), qui sont ensuite suivis d’une notification qui vous informe de la modification. L’installation des mises à jour des patchs (z-stream) dès leur mise à disposition fait partie des bonnes pratiques.

État de support limité

Lorsqu’un cluster passe à un état de support limité, également appelé en dehors de la prise en charge, azure Red Hat OpenShift SREs ne surveille plus de manière proactive le cluster. Et le contrat SLA n’est plus applicable et les crédits demandés par rapport au contrat SLA sont refusés, mais cela ne signifie pas que vous n’avez plus de support produit.

Un cluster peut passer à un état de support limité pour de nombreuses raisons, notamment les scénarios suivants :

• Si vous ne mettez pas à jour un cluster vers une version prise en charge avant la date de fin de vie.
  • Aucune garantie de runtime ou de SLA n’existe pour les versions après leur date de fin de vie. Pour éviter cela et continuer à bénéficier d’un support complet, mettez à jour le cluster vers une version prise en charge avant la date de fin de vie. Si vous ne mettez pas à jour le cluster avant la date de fin de vie, le cluster passe à un état de support limité jusqu’à ce qu’il soit mis à jour vers une version prise en charge.
  • Les ingénieries de fiabilité de site (SRE, Site Reliability Engineering) d’Azure Red Hat OpenShift fournissent un support commercialement raisonnable pour mettre à jour une version non prise en charge vers une version prise en charge. Toutefois, si un chemin de mise à jour pris en charge n’est plus disponible, vous devrez peut-être créer un cluster et migrer vos charges de travail.
• Si vous supprimez ou remplacez les composants Azure Red Hat OpenShift natifs ou tout autre composant installé et géré par le service.
  • Si des autorisations d’administrateur ont été utilisées, Azure Red Hat OpenShift n’est pas responsable des actions de votre utilisateur autorisé, y compris celles qui affectent les services d’infrastructure, la disponibilité du service ou la perte de données. Si des actions de ce type sont détectées, le cluster peut passer à un état de support limité. Vous devez alors soit annuler l’action, soit créer un dossier de support pour explorer les étapes de correction.
  • Dans certains cas, le cluster peut revenir à un état de prise en charge complet si vous corrigez les facteurs de violation. Toutefois, dans d’autres cas, vous devrez peut-être supprimer et recréer le cluster.
  • Pour plus d’informations, consultez la stratégie de prise en charge d’Azure Red Hat OpenShift sur les exigences de configuration du cluster.

Exceptions à la politique des versions supportées

L’équipe Azure Red Hat OpenShift SRE se réserve le droit d’ajouter ou de supprimer des versions nouvelles ou existantes, ou de retarder les versions mineures à venir qui ont été identifiées pour avoir une ou plusieurs productions critiques ayant un impact sur les bogues ou les problèmes de sécurité sans préavis préalable.

Des mises en production de correctifs spécifiques peuvent être ignorées, ou le déploiement peut être accéléré en fonction de la gravité du bogue ou du problème de sécurité.

Calendrier de publication Azure Red Hat OpenShift

Consultez le guide suivant pour connaître l’historique des versions de Red Hat OpenShift Container Platform (en amont).

Version de OCP	Disponibilités générales d’OCP	Disponibilité de l’installation ARO	Fin de vie ARO
4.4	Mai 2020	Juillet 2020	Février 2021
4.5	Juillet 2020	Novembre 2020	15 juillet 2021
4,6	Octobre 2020	Février 2021	15 septembre 2021
4,7	Février 2021	15 juillet 2021	1er février 2022
4.8	Juillet 2021	15 septembre 2021	21 juin 2022
4,9	Novembre 2021	1er février 2022	2 mars 2023
4.10	mars 2022	21 juin 2022	19 août 2023
4.11	Août 2022	2 mars 2023	10 février 2024
4,12	Janvier 2023	19 août 2023	17 janv. 2025
4.13	Mai 2023	15 décembre 2023	17 novembre 2024
4.14	Octobre 2023	25 avril 2024	1er juin 2025
4.15	Février 2024	4 septembre 2024	27 août 2025
4.16	Juin 2024	10 mars 2025	2 novembre 2025
4.17	Octobre 2024	5 juin 2025	14 février 2026
4,18	Février 2025	Bientôt disponible	21 juin 2026

Passez en revue l’image suivante pour en savoir plus sur la fenêtre de prise en charge d’Azure Red Hat OpenShift.

• La fenêtre de prise en charge d’une version OCP commence par la disponibilité de la mise à niveau ARO.
• La disponibilité de la mise à niveau ARO est la date à laquelle la version OCP est disponible dans un canal stable pour une mise à jour à partir d’une version précédente.
• La disponibilité de l’installation d’ARO est la date à laquelle la version est disponible pour une nouvelle installation de cluster. Par exemple, lorsque vous créez un cluster avec le portail Azure ou Azure CLI.
• La fin de vie ARO correspond à la date à laquelle une version n’est plus prise en charge et coïncide avec la fin de vie OCP.

Pour plus d’informations sur les canaux de mise à jour stables, consultez Présentation des canaux de mise à jour et des versions.

Questions fréquentes (FAQ)

Que se passe-t-il lorsqu’un utilisateur met à jour un cluster OpenShift avec une version mineure qui n’est pas prise en charge ?

Azure Red Hat OpenShift prend en charge l’installation de versions mineures conformes aux dates du tableau précédent. Une version est prise en charge dès qu’un chemin d’accès de mise à jour vers cette version est disponible dans le canal stable. Si vous exécutez une version après la date de fin de vie, vous êtes en dehors du support et pouvez être invité à effectuer une mise à jour pour continuer à recevoir du support. La mise à jour à partir d’une ancienne version vers une version prise en charge peut s’avérer difficile, voire impossible. Nous vous recommandons de conserver votre cluster avec la dernière version d’OpenShift pour éviter d’éventuels problèmes de mise à jour.

Par exemple, si la version d’Azure Red Hat OpenShift la plus ancienne prise en charge est 4.13 et que vous possédez la version 4.12 ou une version antérieure, vous êtes hors support. Lorsque la mise à jour de la version 4.12 vers la version 4.13 ou ultérieure réussit, vous êtes de retour dans nos stratégies de support.

Le retour d’un cluster à une version antérieure, ou restauration, n’est pas pris en charge. Seule la mise à jour vers une version plus récente est possible.

Que signifie « être hors support » ou « support limité » ?

Si votre cluster ARO exécute une version OpenShift qui ne figure pas dans la liste des versions prises en charge ou utilise une configuration de cluster non prise en charge, votre cluster est en dehors de la prise en charge. Par conséquent :

• Lorsque vous ouvrez un ticket de support pour votre cluster, vous pouvez être invité à mettre à jour le cluster vers une version prise en charge avant de recevoir le support.
• Toutes les garanties de runtime ou de SLA pour les clusters qui ne disposent plus du support technique sont annulées.
• Les clusters hors support sont corrigés de manière optimale.
• Les clusters hors support ne sont pas surveillés.

Étapes suivantes

Pour plus d’informations sur le support, consultez la stratégie de prise en charge d’Azure Red Hat OpenShift 4.0.