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.19.16de version.

• 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 est sur la version 4.18 et 4.19 est la dernière version mineure en disponibilité générale pour la série 4, vous devez effectuer une mise à jour vers la version 4.19 dès que vous le pouvez.

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.18 n’inclut pas de mise à jour vers une version 4.19. 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.

Vous pouvez utiliser le canal stable ou le canal eus 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]

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é.

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.

Fin de vie de la version

La fin de vie signifie qu’une version n’est plus prise en charge dans un stable canal pour les versions mineures impaires, ni dans un eus canal pour même les versions mineures. 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.

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).

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 à jour Azure Red Hat Openshift.
• La disponibilité de la mise à jour d’Azure Red Hat Openshift 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’Azure Red Hat Openshift 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.
• Azure Red Hat Openshift End of Life est la date à laquelle une version n’est plus prise en charge dans le stable canal pour les versions mineures impaires.
• Azure Red Hat OpenShift End of Life (EUS) est la date à laquelle une version n’est plus prise en charge dans le eus canal pour même les versions mineures.

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

Extension de prise en charge des mises à jour étendues, terme 1

Le module complémentaire de prise en charge des mises à jour étendues (EUS) pour la période 1 est disponible sur les versions mineures à numéros pairs à partir de la version 4.16 et est inclus dans votre abonnement Azure Red Hat OpenShift. Cela offre le principal avantage d'étendre le cycle de vie du support pour une période supplémentaire de 6 mois.

Pour appliquer EUS Term 1 à votre cluster Azure Red Hat OpenShift, vous devez modifier votre canal de support vers eus-4.y. Pour plus d’informations sur les canaux de mise à jour, consultez Présentation des canaux de mise à jour et des versions.

Pour plus d’informations sur la Période 1 de l'UES, consultez le module complémentaire de support des mises à jour étendues - Période 1.

É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.

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 est 4.16 et que vous êtes sur la version 4.15 ou antérieure, vous êtes en dehors du support. Lorsque la mise à jour de la version 4.15 à la version 4.16 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 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 n’est pas pris 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.