Annonce de la nouvelle prise en charge étendue des mises à jour pour OpenShift 4.14 et les versions ultérieures 

Red Hat annonce l'ajout d'une option EUS de 12 mois pour OpenShift 4.14 et les versions ultérieures paires de Red Hat OpenShift dans la série 4.x. Le cycle de vie complet de ces versions EUS est alors de trois (3) ans.

Pour donner le coup d'envoi du Red Hat Summit ici à Denver avec OpenShift Commons Gathering, nous allons vous entendre, vous, nos clients qui utilisent au quotidien Red Hat OpenShift. Au cours des dernières années, les clients d'OpenShift ont appliqué ses technologies à des cas d'utilisation de marchés spécialisés qui exigeaient des cycles de vie plus longs.Que ce soit pour des raisons de conformité ou pour la raison qu'OpenShift héberge des services essentiels que les gouvernements et les entreprises traitent différemment, nos clients cherchent chez Red Hat des moyens de prolonger la durée de vie de nos composants Open Source.Chaque année, nous étudions les cycles de vie en fonction de plusieurs critères.Cette année, nous avons trouvé la bonne combinaison de conditions pour être en mesure d'aider nos clients qui se trouvent dans ces situations.

Pour répondre à la complexité des besoins de notre clientèle, nous avons enrichi nos offres de prise en charge prolongée des mises à jour (EUS) pour Red Hat OpenShift et vous avez ainsi la possibilité de prolonger considérablement la prise en charge du cycle de vie des déploiements OpenShift.

Elle s'étendra au-delà de la période EUS de 6 mois qui a été introduite lors du lancement d'OpenShift 4.12. Cette nouvelle période EUS de 12 mois sera disponible sous la forme d'un module complémentaire et portera le cycle de vie d'OpenShift à 3 ans au total.

Avec le trimestre EUS supplémentaire, OpenShift 4.14 sera pris en charge jusqu'au 31 octobre 2026 :

La prochaine version Extended Update Support sera la prochaine version d'OpenShift 4.16. L'impact sur le cycle de vie des versions EUS est également visualisé ci-dessous :

Quel niveau d'assistance est inclus ?

Le trimestre EUS supplémentaire inclut les rétroportages de mises à jour de sécurité ayant un impact Critique ou Important, ainsi que de correctifs de bogues de priorité urgente. Le langage formel sera publié sur la pageRed Hat OpenShift Container Platform Lifecycle Policy qui reste la source de vérité pour les informations actuelles sur le cycle de vie d'OpenShift.

Le contrat de niveau de service (SLA) relatif à l'assistance proposé pendant la phase EUS supplémentaire sera hérité de l'offre de base achetée (Premium ou Standard).

Quels sont les composants inclus ?

Le trimestre EUS supplémentaire s'applique à tous les opérateurs alignés sur la plateforme inclus dans OpenShift Kubernetes Engine. Les autres opérateurs ne sont pas automatiquement inclus et continuent de gérer leurs propres cycles de vie.

Un client qui exécute la souscription OpenShift Platform Plus ou OpenShift Container Platform dans le cadre d'une souscription de base peut toujours acheter la souscription Extended Update Support (EUS) équivalente pour cette offre, mais il ne reçoit que la souscription EUS supplémentaire pour les composants pour lesquels elle est disponible.

Nous prévoyons de proposer ce nouveau trimestre EUS à d'autres opérateurs Red Hat à l'avenir. Vérifiez toujours la page du cycle de vie de l’opérateur en couches approprié afin de déterminer les informations les plus récentes sur le cycle de vie.

Quelles sont les conséquences sur les mises à niveau ?

OpenShift 4.14 prend en charge un décalage de version N-2 entre les services du plan de contrôle et les nœuds de travail, où N est la version mineure d’OpenShift pertinente. Par exemple, un plan de contrôle qui est passé à OpenShift 4.14 peut interagir avec les nœuds de calcul des versions 4.13 et/ou 4.12 dans le cadre d'une séquence de mise à niveau.

Pour les nœuds de plan de contrôle eux-mêmes, les mises à niveau restent séquentielles. En revanche, pour les nœuds de calcul, il est possible de suspendre les pools de calcul pour ignorer chaque version sur deux et le redémarrage associé. Cette possibilité, associée à la prise en charge du décalage de version, permet d'atténuer l'impact supplémentaire de la mise à niveau des charges de travail en cours d'exécution.

Exemple de flux de mise à niveau pour le plan de contrôle et les nœuds de calcul de la version 4.14 vers une version 4.18 future.

En attendant des tests supplémentaires, cette capacité sera étendue dans les prochaines versions en accord avec l'extension du décalage de version Kubernetes en amont, qui prend en charge la politique de décalage de version N-3.

Plus la période entre la version source et la version de destination augmente, plus le nombre de mises à niveau séquentielles requises pour passer à la dernière version EUS augmente. À mesure que le nombre de mises à niveau séquentielles requises augmente, la complexité de la mise à niveau le fait également, le niveau de perturbation des charges de travail et le temps nécessaire à sa réalisation. Ainsi, si la capacité le permet, il peut être préférable de passer par un processus de mise à niveau bleu/vert en faisant évoluer un nouveau cluster, en déplaçant les charges de travail et en désactivant l'ancien cluster.

Chaque cluster est différent et disposera donc de son propre chemin de mise à niveau. Nous vous recommandons de choisir un plan de mise à niveau en même temps que vous choisissez d'utiliser les trimestres EUS OpenShift pour un cluster.

Comment en savoir plus ?

Red Hat a rejoint le groupe de travail LTS (Long Term Support) au sein de l'écosystème Kubernetes pour contribuer à faire avancer les idées sur la manière de prolonger la durée de vie de Kubernetes et des technologies associées.Nous invitons tous les utilisateurs intéressés par ces sujets à rejoindre cette communauté.

Pour en savoir plus, regardez le prochain événement virtuel « What's New in OpenShift 4.16 » Suivez-nous sur YouTube ou Twitch pour connaître la date de diffusion.

Si vous n'utilisez pas encore OpenShift et que nous avons suscité votre intérêt, effectuez un essai.