2.5. Le Red Hat OpenShift Service sur AWS met à jour le cycle de vie

Le Red Hat fournit un cycle de vie des produits publié pour Red Hat OpenShift Service sur AWS afin que les clients et les partenaires puissent planifier, déployer et soutenir efficacement leurs applications en cours d’exécution sur la plateforme. Le Red Hat publie ce cycle de vie pour offrir autant de transparence que possible et pourrait faire des exceptions à ces politiques lorsque des conflits surgissent.

Le Red Hat OpenShift Service sur AWS est une instance gérée de Red Hat OpenShift et maintient un calendrier de sortie indépendant. De plus amples détails sur l’offre gérée peuvent être trouvés dans le service Red Hat OpenShift sur la définition de service AWS. La disponibilité des avis de sécurité et des avis de correction de bogues pour une version spécifique dépend de la politique de cycle de vie de Red Hat OpenShift Container Platform et est soumise au service Red Hat OpenShift sur le calendrier de maintenance AWS.

Les principales versions de Red Hat OpenShift Service sur AWS, par exemple la version 4, sont prises en charge pendant un an après la sortie d’une version majeure ultérieure ou la retraite du produit.

À partir de la version mineure de 4.8 OpenShift Container Platform, Red Hat prend en charge toutes les versions mineures pendant au moins 16 mois après la disponibilité générale de la version mineure donnée. Les versions de patch ne sont pas affectées par la période de support.

Les clients sont informés 60, 30 et 15 jours avant la fin de la période d’assistance. Les clusters doivent être mis à niveau vers la dernière version de patch de la version mineure la plus ancienne prise en charge avant la fin de la période de support, ou le cluster entrera un statut « Support limité ».

Au cours de la période pendant laquelle une version mineure est prise en charge, Red Hat prend en charge toutes les versions de patch OpenShift Container Platform sauf indication contraire.

En raison de la sécurité et de la stabilité de la plate-forme, une version de correctif peut être dépréciée, ce qui empêcherait les installations de cette version et déclencherait des mises à niveau obligatoires de cette version.

Lorsqu’un cluster passe à un statut de support limité, Red Hat ne surveille plus de manière proactive le cluster, le SLA n’est plus applicable et les crédits demandés contre l’ALS sont refusés. Cela ne signifie pas que vous n’avez plus de support produit. Dans certains cas, le cluster peut revenir à un statut entièrement pris en charge si vous corrigez les facteurs de violation. Cependant, dans d’autres cas, vous devrez peut-être supprimer et recréer le cluster.

Il est possible qu’un cluster passe à un statut de support limité pour de nombreuses raisons, y compris les scénarios suivants:

Lorsque vous avez des questions sur une action spécifique qui pourrait faire passer un cluster à un statut de support limité ou avoir besoin d’une assistance supplémentaire, ouvrez un ticket de support.

Le Red Hat 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 comme ayant un ou plusieurs problèmes de production critiques ayant un impact sur les bogues ou les problèmes de sécurité sans préavis.

Alors que Red Hat recommande l’installation de la dernière version de support, Red Hat OpenShift Service sur AWS prend en charge l’installation de toute version prise en charge comme couvert par la politique précédente.

Lorsqu’un CVE critique ou important, ou un autre bug identifié par Red Hat, a un impact significatif sur la sécurité ou la stabilité du cluster, le client doit passer à la prochaine version du correctif pris en charge dans les deux jours ouvrables.

Dans des circonstances extrêmes et sur la base de l’évaluation par Red Hat de la criticité CVE pour l’environnement, Red Hat informera les clients qu’ils disposent de deux jours ouvrables pour planifier ou mettre à jour manuellement leur cluster vers la dernière version sécurisée du patch. Dans le cas où une mise à jour n’est pas effectuée après deux jours ouvrables, Red Hat mettra automatiquement à jour le cluster vers la dernière version de correctif sécurisé afin d’atténuer les failles de sécurité potentielles ou l’instabilité. À sa propre discrétion, Red Hat peut retarder temporairement une mise à jour automatisée si un client le demande par le biais d’un dossier d’assistance.