Informations sur la version de Red Hat OpenShift on IBM Cloud

Versions Red Hat OpenShift disponibles

Red Hat OpenShift on IBM Cloud prend en charge les versions suivantes d'Red Hat OpenShift. Notez que différentes versions de Red Hat OpenShift peuvent prendre en charge des versions RHEL différentes.

Tous les clusters VPC créés à partir de la version 4.18 ou ultérieure peuvent utiliser des nœuds de travail RHCOS. Les clusters créés dans les versions 4.15, 4.16, ou ne 4.17 peuvent utiliser les nœuds de travail RHCOS que s'ils ont été initialement créés avec des nœuds de travail RHCOS ou s'ils ont été mis à niveau vers au moins la version 4.18.

• † Indique les dates provisoires et susceptibles d'être modifiées.
• * Indique les systèmes d'exploitation qui sont obsolètes.

Cycle de vie des éditions

Chaque version d' Red Hat OpenShift on IBM Cloud prise en charge passe par un cycle de vie comportant les étapes suivantes : test, développement, édition générale, prise en charge, dépréciation puis, progressivement, fin de prise en charge. Passez en revue les descriptions de chaque phase du cycle de vie d'une version.

L'estimation des jours et les versions sont fournies pour une compréhension générale. La disponibilité effective et les dates de publication sont susceptibles de changer et dépendent de divers facteurs, tels que les mises à jour de la communauté, les correctifs de sécurité et les changements de technologie qui interviennent d'une version à l'autre.

1. Edition de la communauté: La communauté publie la nouvelle version. IBM Les ingénieurs commencent à tester et à stabiliser la version « Community » en vue de la sortie d'une version « Red Hat OpenShift on IBM Cloud » bénéficiant d'un support technique.

2. Cycle de vie des versions prises en charge:

   Edition de développement

   L'édition est en cours de développement et peut être disponible en tant que version bêta pour sélectionner des clients. IBM fournit une prise en charge optimale de l'édition.

   Disponibilité générale

   L'édition est disponible en version GA (GA). IBM fournit une prise en charge complète de l'édition. IBM fournit une date cible provisoire pour que l'édition ne soit pas prise en charge. L'édition devient la version par défaut utilisée lors de la création du cluster une fois qu'il existe des restrictions minimales et un taux d'adoption raisonnable pour l'édition.

   Maintenance

   L'édition est entrée dans le support de maintenance tel que défini par le support Red Hat. IBM fournit une prise en charge de la maintenance pour OpenShift basée sur la règle Red Hat. Sinon, IBM fournit une prise en charge complète.

   prise en charge étendue

   L'édition est entrée dans la prise en charge étendue telle que définie par Red Hat. IBM fournit une prise en charge étendue pour OpenShift basée sur la règle Red Hat. Sinon, IBM fournit une prise en charge complète.

3. Version obsolète: la version est obsolète. IBM fournit une date cible non prise en charge mise à jour pour l'édition. Un compte à rebours non pris en charge jusqu'à cette date est fourni au moins 45 jours avant que l'édition ne devienne non prise en charge. IBM fournit une prise en charge minimale pour l'édition en conformité avec la prise en charge de Red Hat. Cette phase de prise en charge est généralement la phase finale avant que l'édition ne soit pas prise en charge et remplace les phases de maintenance et de prise en charge étendue en cas de chevauchement. Il se peut que les mises à jour de sécurité ne soient pas fournies. Pendant la période de dépréciation, la version reste prise en charge et votre cluster continue de fonctionner, mais il peut être nécessaire de passer à une version prise en charge afin de corriger les failles de sécurité. Par exemple, en ajoutant ou en rechargeant des noeuds worker.

4. Version non prise en charge: la version n'est pas prise en charge. IBM fournit uniquement la prise en charge de la mise à niveau vers une édition prise en charge. La version n'est pas prise en charge. Les clusters qui ne sont pas pris en charge ne reçoivent pas des mises à jour de sécurité et des correctifs et ne bénéficient pas du service de support IBM Cloud. Bien que votre cluster et vos applications puissent continuer à s'exécuter pendant un certain temps, vous ne pouvez plus créer, recharger ou effectuer d'autres actions correctives sur le maître ou les noeuds worker du cluster lorsqu'un problème se produit. Vous pouvez toujours supprimer le cluster ou les noeuds worker ou mettre à jour le cluster vers la version suivante. Examinez les impacts potentiels et mettez à jour le cluster immédiatement pour continuer à recevoir des mises à jour de sécurité importantes et bénéficier du service de support. Si le maître cluster exécute deux versions ou plus derrière la version prise en charge la plus ancienne, vous ne pouvez plus appliquer de mises à jour et vous devez supprimer le cluster et en créer une nouvelle.

   Les clusters exécutant une version non prise en charge finiront par échouer car les certificats de cluster expirent. Les défaillances peuvent inclure, sans s'y limiter, un plan de contrôle de cluster indisponible, des nœuds de travail d' NotReady, ou un Ingress non sain.

5. Archivé: la version n'est pas prise en charge sans chemin de mise à niveau. IBM ne fournit aucune prise en charge. IBM se réserve le droit d'arrêter les plans de contrôle de ces clusters.

IBM fournit des groupes de correctifs de noeud worker toutes les deux semaines. IBM l'objectif de la Commission est de remédier aux vulnérabilités légitimes détectées dans un délai approprié aux risques qu'elles représentent. Pour garantir la qualité et la stabilité de l'édition, les groupes de correctifs peuvent être retardés.

Pour Red Hat OpenShift, les groupes de correctifs sont appliqués à la dernière édition mineure et au dernier correctif pour le système d'exploitation ciblé.

• Pour RHEL8, c'est-à-dire 8.9.

Pour sécuriser vos noeuds, vous devez installer des groupes de correctifs de noeud worker dès que possible. Vous pouvez vous abonner à des notifications pour être alerté lorsqu'une nouvelle mise à jour est disponible.

Archivage

Les clusters qui ne sont pas pris en charge ne reçoivent pas des mises à jour de sécurité et des correctifs et ne bénéficient pas du service de support IBM Cloud. Bien que votre cluster et vos applications puissent continuer à s'exécuter pendant un certain temps, vous ne pouvez plus créer, recharger ou effectuer d'autres actions correctives sur le maître ou les noeuds worker du cluster lorsqu'un problème se produit. Vous pouvez toujours supprimer le cluster ou les noeuds worker ou mettre à jour le cluster vers la version suivante. Examinez les impacts potentiels et mettez à jour le cluster immédiatement pour continuer à recevoir des mises à jour de sécurité importantes et bénéficier du service de support. Si votre maître cluster est inférieur d'au moins deux versions à la version prise en charge la plus ancienne, vous devez créer un nouveau cluster et déployer vos applications sur le nouveau cluster.