Assistant d’installation, kubernetes 1.20 et autres nouveautés d’OpenShift 4.7
Kubernetes 1.20 et CRI-o 1.20
Sa technologie est basée sur les versions 1.20 de Kubernetes et le moteur de conteneurs CRI-O 1.20, qui remplace complètement le peu qui restait de Docker. OpenShift 4.7 a poursuivi son chemin de nouvelles fonctionnalités dont nous parlerons plus tard, mais si nous pouvons dire quelque chose de pertinent sur cette version, c’est qu’elle est plus stable, beaucoup plus stable. De nombreuses modifications ont été apportées à l’ensemble de la pile logicielle afin d’améliorer la disponibilité, la résilience et la robustesse de la plateforme dans son ensemble. Des contrôles plus nombreux et plus efficaces ont été mis en place, un nouveau système de diagnostic pour l’installateur a été mis en place et les codes d’erreur ont été enrichis. Il comprend également des améliorations du panneau de contrôle pour faciliter la surveillance des pipelines, des opérateurs (connectés ou déconnectés) des systèmes de stockage et des réseaux de communication. 
Un installateur pour les serveurs bare-metal ?
Oui, enfin. Cette version est livrée avec l’assistant d’installation (aperçu technologique). Une avancée pour simplifier le déploiement de l’ensemble des paquets, dépendances, services et configurations nécessaires pour installer OpenShift sur nos propres serveurs.
Mais n’a-t-il pas toujours été installé dans le nuage avec un installateur automatique ?
Oui et non. L’installateur du nuage est génial, tout fonctionne comme par magie MAIS il y a de plus en plus de charges de travail comme l’IA, le HPC, le DL, le Telco/5G, le ML, qu’il est impossible de déployer dans le nuage en raison des coûts (vous devez télécharger et envoyer de très nombreux Go) et des performances. Nous avons déjà vu comment configurer OpenShift pour les environnements AI/DL sur les serveurs IBM Power Systems. L’une des principales objections à de tels déploiements était la complexité de l’installation manuelle de l’environnement. L’installateur le simplifiera beaucoup.
Conteneurs Windows
Cela peut paraître étrange, mais les clients de Microsoft sont des millions dans le monde. Si un système comme celui-ci veut réussir, il doit les soutenir. C’est pourquoi Red Hat OpenShift 4.7 continue d’étendre la prise en charge de Windows Containers, une fonctionnalité annoncée dès la fin de 2020. Outre la prise en charge de Windows Containers sur AWS et Azure, OpenShift inclura désormais la prise en charge de vSphere (disponible au début du mois d’avril prochain 2021) à l’aide de l’Installer Provided Infrastructure (IPI) pour VMWare. Les clients de Red Hat peuvent désormais migrer leurs conteneurs Windows de leurs systèmes virtualisés VMWare vers leur cluster Red Hat OpenShift de manière simple et, surtout, entièrement prise en charge et sécurisée.
Support IPSec dans OVN
Dans les environnements de nuages hybrides, l’un des grands défis est de savoir comment connecter nos nœuds et clusters distants les uns aux autres ou à nos centres de données locaux. Avec la prise en charge du réseau virtuel d’OpenShift pour le protocole IPSec, cela est grandement facilité.
Mise à l’échelle automatique des pods
La dernière fonctionnalité que nous voulions mettre en avant est l’uto-scaling horizontal des pods (HPA). Il permet, en mesurant l’utilisation de la mémoire et par le biais d’un contrôleur de réplication, d’augmenter le nombre de pods ou de modifier leurs caractéristiques automatiquement.
Si vous voulez essayer Red Hat OpenShift 4.7, il y a plusieurs façons de le faire, des tutoriels d’apprentissage en ligne aux démos sur votre ordinateur portable, en passant par la façon de le faire dans le cloud public ou dans votre propre centre de données.
Vous pouvez consulter le reste des nouvelles sur https://www.openshift.com/blog/red-hat-openshift-4.7-is-now-available, configurer votre environnement de démonstration chez vous et commencer à vous former dès maintenant avec nos cours pratiques.