Cycle de vie du support pour Azure Red Hat OpenShift 4

Red Hat publie des versions mineures de Red Hat OpenShift Container Platform (OCP) environ tous les quatre mois. Ces versions contiennent de nouvelles fonctionnalités et des améliorations. Les mises à jour sont plus fréquentes (généralement hebdomadaires) et peuvent inclure des correctifs pour des failles de sécurité ou des 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 donne des informations sur les mises à jour, les dépréciations et la stratégie 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 4.15.16.

• Version majeure : aucune mise en production 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 caractéristiques et fonctions, des modifications architecturales et la suppression de fonctions existantes.
• Version mineure : mise en production 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 du correctif : généralement publiée toutes les semaines, ou selon les besoins. Les mises à jour de versions correctives peuvent inclure des correctifs de bogues, des renforcements de la sécurité et d’autres améliorations.

Vous devez chercher à exécuter la dernière version mineure de la version principale que vous possédez. Par exemple, si votre cluster de production tourne 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.

Canaux de mise à jour

Les canaux de mise à jour sont 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 à jour sont liés à une version mineure de Red Hat OpenShift Container Platform. 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 à jour contrôlent uniquement la sélection des versions et ne modifient pas la version actuelle du cluster. Pour plus d’informations, consultez Présentation des canaux de mise à jour et des versions.

Il est possible d’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 de la version d’Azure Red Hat OpenShift

Disponibilité de la version 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

Mettre à jour la disponibilité

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 OpenShift. La disponibilité des mises à jour peut être vérifiée sur la page suivante, Red Hat OpenShift Container Platform Update Graph.

Disponibilité de l'installation

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.

Mises à jour obligatoires

Dans des circonstances extrêmes et sur la base de l'évaluation de la criticité du CVE pour l'environnement, une mise à jour de correctif critique peut être appliquée aux clusters automatiquement par Azure Red Hat OpenShift Site Reliability Engineers (SRE) qui sera ensuite suivie d'une notification vous informant du changement. La meilleure pratique consiste à installer les mises à jour des correctifs (z-stream) dès qu'elles sont disponibles.

Statut de la prise en charge limitée

Lorsqu'un cluster passe à un statut de support limité (ou également appelé hors support), les SRE d’Azure Red Hat OpenShift ne surveillent plus le cluster de manière proactive. En outre, le contrat SLA n’est plus applicable et les crédits demandés par rapport au contrat SLA sont refusés, bien qu’il 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.

  • Il n'y a pas de garantie de durée d'exécution ou du SLA pour les versions après leur date de fin de vie. Pour éviter cela et continuer à bénéficier d'une assistance complète, 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 statut de support limité jusqu'à ce qu'il soit mis à jour vers une version supportée.
  • Les SRE Azure Red Hat OpenShift fournissent une assistance 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 nouveau cluster et migrer vos charges de travail.

• Si vous supprimez ou remplacez tout composant Azure Red Hat OpenShift natif 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 de vos actions ou de celles de vos utilisateurs autorisés, y compris celles qui affectent les services d'infrastructure, la disponibilité des services ou la perte de données. Si de telles actions sont détectées, le cluster peut passer à un statut de support limité. Vous devez alors soit annuler l'action, soit créer un cas de support pour explorer les étapes de remédiation.
  • Dans certains cas, le cluster peut revenir à un état de support complet si vous remédiez aux facteurs de violation. Toutefois, dans d'autres cas, vous devrez peut-être supprimer et recréer le cluster.
  • Pour plus d’informations sur les exigences de configuration du cluster, consultez la stratégie de prise en charge d’Azure Red Hat OpenShift.

Exceptions de la stratégie de version prise en charge

L’équipe SRE Azure Red Hat OpenShift se réserve le droit d’ajouter ou de supprimer de nouvelles versions, de supprimer des versions existantes ou de retarder la publication de versions mineures s’il a été identifié qu’elles présentent un ou plusieurs problèmes de sécurité ou bogues critiques ayant un impact sur la production, et ce, sans préavis.

Il est possible d’ignorer certaines versions correctives ou d’accélérer le déploiement 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).

Forum aux questions

Que se passe-t-il quand un utilisateur met à jour un cluster OpenShift avec une version mineure non 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 utilisez une version au-delà de la date de fin de vie ci-dessus, vous êtes hors support et il peut vous être demandé d’effectuer une mise à jour pour continuer à profiter 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 de 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. Une fois la mise à jour de la version 4.12. à la version 4.13 ou à une version ultérieure réussie, vous bénéficierez à nouveau de 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 d’OpenShift qui ne figure pas dans la liste des versions prises en charge ou qui utilise une configuration de cluster non prise en charge, votre cluster est « hors support ». 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 du 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 seront corrigés de manière optimale.
• Les clusters hors support ne sont pas analysés.