OpenShift change de socle : ce que les entreprises doivent vérifier avant RHCOS 10

RRed Hat prévoit de faire de RHEL CoreOS 10 (RHCOS 10) le système par défaut des nouvelles installations OpenShift au quatrième trimestre 2026. RHCOS 9 restera disponible pour les versions récentes au moins jusqu’à mi-2027.[1] Pour les entreprises, cette transition pose une question concrète : les applications, les extensions et le matériel pourront-ils évoluer ensemble ?

Le système sous les conteneurs compte toujours

RHCOS est le système immuable des nœuds OpenShift, administré par les mécanismes de la plateforme.[1] Un nœud est une machine qui participe au fonctionnement du cluster. Même lorsque les applications sont empaquetées dans des conteneurs, elles s’exécutent donc sur un socle dont les caractéristiques restent déterminantes.

La matrice de Red Hat rappelle que les conteneurs dépendent notamment du noyau Linux de l’hôte. Elle distingue les usages ordinaires des conteneurs privilégiés, capables d’interagir plus directement avec ce système. Pour ces derniers, le support impose notamment une correspondance entre les versions majeures de l’image et de l’hôte.[2]

Le sujet dépasse ainsi la mise à jour d’une image applicative. Une application peut sembler fonctionner alors qu’un composant chargé de la surveiller, de connecter son stockage ou de gérer son réseau exige encore une adaptation. La validation doit couvrir ce service complet.

La disponibilité ne vaut pas validation de chaque environnement

À la disponibilité générale, Red Hat exigera la prise en charge de RHCOS 10 par les offres certifiées OpenShift.[1] Les équipes devront néanmoins vérifier les versions précises de leurs produits et leurs conditions de support auprès des éditeurs.

Cette distinction compte pour une organisation qui conserve une extension ancienne ou une configuration particulière. La certification d’une offre ne dispense pas de contrôler le composant effectivement installé, ses dépendances et la procédure de transition prévue par son fournisseur.

Quatre vérifications avant de planifier la transition

Les contraintes documentées ci-dessous servent de point de départ à une revue de compatibilité. Les vérifications proposées constituent une grille de préparation éditoriale.

Tester le service rendu, au-delà du démarrage des applications

RHCOS 10 est proposé en Technology Preview dans OpenShift 4.21 et 4.22.[1] Ce cadre permet de préparer les essais, sans confondre préversion et validation pour la production.

Un scénario utile consiste à reproduire une application représentative : accès utilisateur, données persistantes, supervision et sauvegarde. L’équipe vérifie ensuite la continuité des échanges, le comportement après redémarrage et la restauration des données. Un conteneur qui démarre ne suffit pas à démontrer que le service reste exploitable.

La matrice Red Hat autorise certaines combinaisons entre générations différentes pour les conteneurs non privilégiés, sous conditions. Elle ne demande donc pas de reconstruire systématiquement toutes les applications sur UBI 10.[2] À l’inverse, perdre le support d’une ancienne image est un signal à traiter même si un essai technique semble réussir.

Pour une PME, commencer par une cartographie courte et exploitable

Une PME équipée d’OpenShift peut réunir dans un inventaire les applications critiques, leurs images de base, les extensions installées et les interlocuteurs responsables. Cette cartographie aide à repérer les dépendances dont la mise à jour conditionne plusieurs services.

Le planning peut ensuite suivre les résultats des essais et la disponibilité des versions supportées. Le budget doit intégrer le temps de qualification, les adaptations éventuelles et, si nécessaire, le renouvellement de matériel. Ces postes sont à évaluer dans chaque environnement ; l’annonce ne permet pas de chiffrer un coût de migration type.

L’administrateur devient le garant des compatibilités

Cette transition mobilise directement l’Administration systèmes et réseaux. Comprendre les liens entre système hôte, conteneurs, réseau et stockage permet d’identifier les dépendances qui pourraient fragiliser une application lors du changement de socle.

Le travail consiste aussi à transformer une exigence de support en vérification concrète : retrouver une version, comparer les matrices des fournisseurs, construire un environnement de test et documenter les résultats. Cette traçabilité rend la décision de migration explicable.

La compétence prend enfin une dimension de coordination. L’administrateur échange avec les développeurs, les équipes de sécurité et les éditeurs pour organiser les changements. Sa valeur tient à sa capacité à préparer une évolution cohérente tout en préservant la continuité du service.

Une évolution à préparer par les dépendances

L’arrivée de RHCOS 10 rappelle que la portabilité des conteneurs ne supprime pas les contraintes d’infrastructure. La priorité est de savoir quels composants sont prêts, lesquels doivent évoluer et sur quelles preuves reposera la décision de basculer.

L’Actu IT à 360°, décrypter la technologie pour comprendre les métiers de demain.

Découvrir CCCLX →