IBM Cloud Docs
Informations sur la version de Red Hat OpenShift on IBM Cloud

Informations sur la version de Red Hat OpenShift on IBM Cloud

Revoyez les informations relatives aux versions d'Red Hat OpenShift prises en charge pour les clusters Red Hat® OpenShift® on IBM Cloud®.

Affichez des informations sur les modifications de version correspondant à des mises à jour de version principale, de version secondaire ou de correctif qui sont disponibles pour vos clusters Red Hat® OpenShift® on IBM Cloud®. Les modifications comprennent des mises à jour pour les composants d'Red Hat OpenShift, de Kubernetes et d'IBM Cloud Provider.

Sauf indication contraire dans les journaux de modification, la version du fournisseur IBM Cloud active les API et les fonctions Red Hat OpenShift qui sont en version bêta. Les fonctions alpha de Red Hat OpenShift, qui sont sujettes à modification, sont désactivées.

Consultez les bulletins de sécurité concernant le statut d'IBM Cloud afin de découvrir les vulnérabilités en matière de sécurité qui affectent Red Hat OpenShift on IBM Cloud. Vous pouvez filtrer les résultats pour afficher uniquement les bulletins de sécurité de Kubernetes Service pertinents pour Red Hat OpenShift on IBM Cloud. Les entrées de journal des modifications qui traitent d'autres vulnérabilités de sécurité mais qui ne font pas également référence à un bulletin de sécurité IBM sont destinées à des vulnérabilités qui ne sont pas connues pour affecter Red Hat OpenShift on IBM Cloud lors d'une utilisation normale. Si vous exécutez des conteneurs privilégiés, vous exécutez des commandes sur les noeuds worker ou vous exécutez un code non sécurisé, vous vous exposez à des risques.

Les mises à jour des correctifs de maître sont appliquées automatiquement. Les mises à jour des correctifs de noeud worker peuvent être appliquées en rechargeant ou en mettant à jour les noeuds worker. Pour plus d'informations sur les versions principales, mineures et de correctifs et sur les actions de préparation entre les versions mineures, voir les versions Red Hat OpenShift.

Pour plus de détails sur les versions des projets Red Hat OpenShift et Kubernetes, consultez les notes de mise à jour de Red Hat OpenShift.

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.

Red Hat Enterprise Linux CoreOS (RHCOS) sont disponibles uniquement pour les clusters de VPC créés à partir de la version 4.15. Les clusters mis à niveau de 4.14 vers 4.15 ne peuvent pas utiliser les noeuds worker RHCOS.

Clusters VPC avec CoreOS activé

Dernière 4.18 ( Kubernetes 1.31 )

Défaut 4.17 ( Kubernetes 1.30 )

4.16 (Kubernetes 1.29)

4.15 (Kubernetes 1.28)

Clusters VPC et Classic

Dernière 4.18 ( Kubernetes 1.31 )

Défaut 4.17 ( Kubernetes 1.30 )

4.16 (Kubernetes 1.29)

4.15 (Kubernetes 1.28)

4.14 (Kubernetes 1.27)

Clusters dans des emplacements Satellite avec CoreOS activé

Dernière 4.18 ( Kubernetes 1.31 )

Défaut 4.17 ( Kubernetes 1.30 )

4.16 (Kubernetes 1.29)

4.15 (Kubernetes 1.28)

4.14 (Kubernetes 1.27)

Clusters dans des emplacements Satellite sans CoreOS activé

Dernière 4.18 ( Kubernetes 1.31 )

Défaut 4.17 ( Kubernetes 1.30 )

4.16 (Kubernetes 1.29)

4.15 (Kubernetes 1.28)

4.14 (Kubernetes 1.27)

Indique les dates provisoires et susceptibles d'être modifiées.

Versions non prises en charge :
Pour plus d'informations sur les versions non prises en charge, voir l'archive.

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 à renforcer la version communautaire en vue de la publication d'une version supportée par Red Hat OpenShift on IBM Cloud.

  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. Les mises à jour des correctifs de sécurité peuvent ne pas être fournies. Pendant la période de dépréciation, la version est toujours prise en charge et votre cluster est toujours fonctionnel, mais peut nécessiter une mise à jour vers une version prise en charge pour corriger des 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.

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

Archiver

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.

Versions de Red Hat OpenShift on IBM Cloud non prises en charge:
Historique des versions archivées