Red Hat OpenShift 4.16 : Informations utiles

Red Hat OpenShift 4.16 est maintenant disponible. Basée sur Kubernetes 1.29 et CRI-O 1.29, la solution OpenShift 4.16 se concentre sur le cœur, la sécurité, la virtualisation et les fonctionnalités pour les télécommunications et l'edge computing. Red Hat OpenShift a pour objectif d'accélérer le développement et la distribution d'applications modernes à grande échelle dans le cloud hybride grâce à une plateforme fiable, complète et cohérente.

Cycle de vie de 3 ans pour Red Hat OpenShift 4.14 et versions ultérieures

Il existe désormais un module complémentaire Extended Update Support (EUS) de 12 mois pour Red Hat OpenShift 4.14 et toutes les versions paires ultérieures. Le cycle de vie complet de ces versions EUS de Red Hat OpenShift est désormais de 3 ans, au lieu de 6 mois auparavant. Pour en savoir plus, consultez la section Politique du cycle de vie de la plateforme Red Hat OpenShift Container Platform

Placez la sécurité au début du cycle de vie des applications et faites-la évoluer avec Red Hat Advanced Cluster Security Cloud Service

Le service Red Hat Advanced Cluster Security Cloud Service passe d'une disponibilité limitée à une disponibilité générale. Red Hat Advanced Cluster Security Cloud Service est un service cloud de sécurité natif pour Kubernetes entièrement géré qui prend en charge à la fois Red Hat OpenShift et les plateformes tierces de Red Hat Kubernetes, notamment Amazon EKS, Google GKE et Microsoft AKS. Avec ce service cloud, vous pouvez adopter une approche axée sur la sécurité pour créer, déployer et assurer la maintenance des applications cloud-native à grande échelle dans le cloud hybride, quelle que soit la plateforme Kubernetes sous-jacente.

Réduire les coûts et optimiser le temps de déploiement des clusters grâce aux plans de contrôle hébergés autogérés dans AWS

Les plans de contrôle hébergés sont activés par défaut dans le moteur multicluster pour l'opérateur Kubernetes depuis la version 2.4. Depuis la version 2.6 de MCE, les plans de contrôle hébergés autogérés dans AWS sont généralement disponibles en même temps que Red Hat OpenShift 4.16.

Les plans de contrôle hébergés permettent de gérer plusieurs clusters OpenShift à grande échelle de manière plus efficace et rentable. Il centralise la gestion du plan de contrôle et permet une meilleure utilisation des ressources et une maintenance simplifiée. Les plans de contrôle hébergés vous permettent de vous concentrer sur les applications en réduisant les coûts d'infrastructure et de gestion, en optimisant le temps de déploiement des clusters et en séparant les tâches de gestion des charges de travail.

Serveurs d'authentification externes dans Red Hat OpenShift sur AWS avec plan de contrôle hébergé

Vous pouvez désormais intégrer votre propre solution OpenID Connect (OIDC) à Red Hat OpenShift Service on AWS (ROSA) avec des plans de contrôle hébergés, afin d'authentifier des utilisateurs et des groupes directement auprès du serveur d'API Kubernetes. Les clusters ROSA utilisent les jetons de sécurité AWS STS (Security Token Service) et OIDC pour permettre aux opérateurs des clusters d'accéder aux ressources AWS nécessaires. En savoir plus sur Simplifier l'accès à vos clusters ROSA à l'aide d'OIDC externe.

Sécuriser la mise en réseau des clusters OpenShift à l'aide de la politique de réseau d'administration

La prochaine génération de politiques réseau Kubernetes est désormais entièrement prise en charge dans les déploiements OpenShift avec OVN-Kubernetes pour la mise en réseau. La politique réseau d'administration (également connue sous le nom de politique réseau globale) apporte des améliorations à l'implémentation précédente de la politique réseau en amont. Les fonctions les plus demandées sont les suivantes :

• Politiques de sécurité réseau réservées aux administrateurs qui ne peuvent pas être remplacées par les administrateurs d'espaces de noms et les développeurs
• Étendue à l'échelle du cluster Par exemple, les politiques de sortie peuvent être définies une seule fois à un seul endroit et s'appliquer à l'ensemble du trafic du cluster.
• La possibilité de déléguer une politique de sécurité spécifique et vérifiée aux administrateurs d'espaces de noms et aux développeurs, afin qu'ils disposent de la flexibilité de politique réseau dont ils ont besoin pour développer des applications ;

La politique réseau d'administration permet de :

• Isoler les locataires d'un cluster avec des privilèges d'administrateur
• Créer une liste d'autorisation définitive pour le trafic qui doit toujours circuler
• Spécifier une politique immuable pour tout le trafic sortant du cluster. Par exemple, vous pouvez forcer tout le trafic à passer par une passerelle à des fins d'inspection.
• Définir une politique de trafic réseau avec une résolution précise pour les modèles de trafic très sélectifs, notamment en provenance et à destination d'espaces de noms sensibles

Réduire les accès des utilisateurs ou groupes non authentifiés

À partir de la version 4.16 d'OpenShift, une limite est instaurée aux autorisations accordées à l'utilisateursystem:anonymous et au groupesystem:unauthenticated. Seuls deux rôles sont autorisés par défaut :

• system:openshift:public-info-viewer : requis pour les workflows OIDC
• system:public-info-viewer : accès en lecture seule aux informations non sensibles sur le cluster

Cette limite ne s'applique qu'aux nouveaux clusters. Les clusters mis à niveau ne sont pas affectés.

Pour les cas d’utilisation où un accès anonyme est nécessaire, l’administrateur de cluster doit ajouter explicitement ces autorisations. Par exemple, si vous utilisez des webhooks pour BuildConfigs à partir d'un système externe (tel que GitHub) qui ne prend pas en charge l'envoi de jetons d'authentification via HTTP, vous devrez ajouter explicitement les permissionssystem:webhook. Dans de tels scénarios, nous vous recommandons vivement d'utiliser des liaisons de rôle locales plutôt que des liaisons de rôle de cluster. Un administrateur de cluster peut rajouter un ClusterRoleBinding pour l’utilisateur anonyme si nécessaire, après avoir évalué les risques et les avantages qui y sont associés.

Résolution des problèmes de mise à niveau OpenShift plus facile grâce à l'état de mise à niveau d'oc adm

Red Hat OpenShift 4.16 comprend une nouvelle commande oc adm upgrade status, disponible en version préliminaire. Cette commande affiche la progression de la mise à jour du cluster, en éliminant les bruits inutiles, et indique à l'administrateur si la mise à jour se passe bien ou s'il doit intervenir. Dans le cas d'un problème de mise à jour, la commande renvoie des informations sur ce qui se passe, accompagnées de conseils et de liens vers des ressources utiles (comme la documentation Red Hat ou des articles de la base de connaissances).

# oc adm upgrade status
An update is in progress for 55m7s: Working towards 4.16.0: 198 of 951 done (20% complete)
= Control Plane =
Assessment:      Progressing
Completion:      97%
Duration:        55m6.974951563s
Operator Status: 36 Total, 36 Available, 1 Progressing, 0 Degraded
= Worker Upgrade =
= Worker Pool =
Worker Pool:     worker
Assessment:      Progressing
Completion:      7%
Worker Status:   42 Total, 22 Available, 20 Progressing, 39 Outdated, 19 Draining, 0 Excluded, 0 Degraded
Worker Pool Node(s)
NAME                                       ASSESSMENT    PHASE      VERSION       EST    MESSAGE
build0-gstfj-ci-builds-worker-b-25ptt      Progressing   Draining   4.16.0-ec.3   +30m   
build0-gstfj-ci-longtests-worker-b-ppxvc   Progressing   Draining   4.16.0-ec.3   +30m   
build0-gstfj-ci-prowjobs-worker-b-gvthg    Progressing   Draining   4.16.0-ec.3   +30m   
build0-gstfj-ci-tests-worker-b-7hvhq       Progressing   Draining   4.16.0-ec.3   +30m   
...
Omitted additional 32 Total, 3 Completed, 22 Available, 10 Progressing, 29 Outdated, 9 Draining, 0 Excluded, and 0 Degraded nodes.
Pass along --details to see all information.
= Update Health =
SINCE   LEVEL   IMPACT   MESSAGE
55m7s   Info    None     Upgrade is proceeding well

In-place migration to Microsoft Entra Workload ID

Si vous utilisez les solutions Red Hat OpenShift autogérées sur Azure, vous pouvez maintenant migrer vers Microsoft Entra Workload ID (anciennement Azure AD Workload Identity) avec un minimum de temps d'arrêt. La prise en charge de l'ID de charge de travail Microsoft Entra a été ajoutée dans Red Hat OpenShift 4.14, qui permet aux clients de créer et de gérer des clusters Red Hat OpenShift avec des informations d'identification temporaires à privilèges limités. Vous pouvez désormais adopter l'ID de charge de travail Microsoft Entra sans avoir à recommencer avec un nouveau cluster. Reportez-vous à Configuring OpenShift with Microsoft Entra Workload ID pour plus de détails.

Optimiser les performances des clusters à l'aide des paramètres d'optimisation etcd

Vous pouvez maintenant mettre à jour etcd pour permettre à votre cluster de tolérer une latence réduite entre les membres etcd. Pour ce faire, vous définissez les paramètres de latence de l'intervalle entre les pulsations et les délais d'élection des leaders sur des valeurs qui optimisent les performances et réduisent la latence. Les valeurs possibles sont :

• "" (la valeur par défaut est vide)
• Standard
• Plus lent

Cela vous permet de tenir compte des scénarios dans lesquels vous pouvez avoir des disques plus lents mais acceptables, ou des clusters étendus qui sont couverts par les meilleures pratiques en matière de performances et d'évolutivité OpenShift.

Reportez-vous à la spécification etcd pour plus d’informations.

Optimiser la mise à l'échelle automatique des clusters en fonction des besoins des charges de travail

L’autoscaler de cluster utilise désormais les stratégies d’extension LeseastWeast, Priority et Random. Vous configurez ces extensions pour influencer la sélection d'ensembles de machines lors de la mise à l'échelle de votre cluster.

• Aléatoire : recommandé pour répartir uniformément les charges de travail sur un cluster homogène où les groupes de nœuds offrent des ressources similaires
• MoinsWeast : pour les clusters où l'efficacité et la réduction du gaspillage de ressources sont des priorités, en particulier pour les charges de travail dynamiques qui privilégient la flexibilité et la mise à l'échelle rapide.
• Priority : pour des décisions de mise à l'échelle sophistiquées basées sur des priorités définies par l'utilisateur, et convient pour des clusters complexes avec des groupes de nœuds variés.

Utiliser votre propre équilibreur de charge pour le déploiement sur site

Avec Red Hat OpenShift 4.16, vous pouvez utiliser votre propre équilibreur de charge géré par l'utilisateur en association avec un cluster sur n'importe quelle infrastructure sur site (système bare metal, VMware vSphere, Red Hat OpenStack Platform, Nutanix, etc.). Pour cette configuration, vous spécifiez loadBalancer.type:UserManaged dans le fichier install-config.yaml de votre cluster. Voir les services pour un équilibreur de charge géré par l’utilisateur pour en savoir plus sur cette fonctionnalité.

Renforcez l'observabilité de vos clusters grâce à des fonctions de surveillance et de résolution des problèmes avancées.

Red Hat OpenShift 4.16 introduit des améliorations significatives de ses capacités d'observabilité, fournissant ainsi des outils améliorés pour la surveillance, la résolution de problèmes et l'optimisation d'un cluster. Des mises à jour ont été apportées aux composants de la pile de surveillance des clusters, tels que Prometheus, Thanos et les nouvelles règles d’alerte. Un nouveau serveur de métrique simplifie la collecte des métriques, et le nouveau rôle monitoring-alertmanager-view améliore la sécurité et la collaboration. Ces fonctions sont incluses dans Cluster Observability Operator version 0.3.0, qui sert d'opérateur de point d'entrée unique pour l'installation et la gestion de l'observabilité. Cette version comprend également des améliorations pour OpenTelemetry et davantage de fonctionnalités API de journalisation de cluster.

Cluster Observability Operator : nouvelle version de Observability Signal Correlation pour la mise en corrélation des signaux d'observabilité, Incident Integration pour la hiérarchisation des alertes critiques et améliorations du traçage distribué grâce à la prise en charge de Tempo Operator pour le déploiement monolithique. Les visualisations de suivi distribué sont désormais affichées dans la console OpenShift.

Observability Signal Correlation et Incident Detection sont tous deux disponibles comme version préliminaire pour les développeurs. La surveillance de l'alimentation, disponible dans la version préliminaire, offre désormais une intégration à l'interface utilisateur de développement et améliore la précision des données.

Modernisez la gestion de votre infrastructure avec Red Hat OpenShift Virtualization

Nous avons le plaisir d'annoncer la mise à disposition générale de la solution de récupération après sinistre sur site pour les machines virtuelles qui utilisent le stockage déployé sur Red Hat OpenShift Data Foundation en association avec Red Hat Advanced Cluster Management for Kubernetes (RHACM) pour la gestion.

Nous avons ajouté un certain nombre d'améliorations aux machines virtuelles. Vous pouvez maintenant ajouter des ressources vCPU à une machine virtuelle en cours d’exécution de manière déclarative. La densité de la mémoire est améliorée grâce à la surallocation de mémoire sécurisée, et nous avons facilité la mise à l'échelle verticale des machines virtuelles grâce au plug-in de processeur.

Grâce à RHACM, vous pouvez maintenant surveiller des machines virtuelles à plusieurs clusters. À partir d’un hub RHACM, vous pouvez afficher toutes les machines virtuelles sur plusieurs clusters OpenShift. Vous pouvez collecter et créer rapidement des rapports pour toutes les machines virtuelles. Sur un hub global RHACM, vous pouvez afficher toutes les machines virtuelles sur plusieurs hubs à l’aide de la recherche de hub global.

L'écosystème continue de s'enrichir de partenaires fournisseurs de matériel, de stockage et d'infrastructure réseau, ainsi que de fournisseurs tiers de solutions de protection des données. En plus de Veeam Kasten, Trilio et Stockaware, la solution Coeshity, Commvault, Rubrique et Veritas vont prochainement évoluer.

Mise à jour basée sur une image pour les clusters OpenShift à nœud unique à l’aide de l’agent cycle de vie

Les partenaires de Red Hat dans le secteur des télécommunications commencent à utiliser des conteneurs pour les réseaux à accès radio (RAN), avec le déploiement de solutions sur un seul nœud OpenShift. Red Hat OpenShift 4.16 propose une approche de type « shift gauche » avec des mises à jour basées sur les images (IBU). IBU propose un autre moyen de mettre à jour un cluster OpenShift à nœud unique. Les utilisateurs d'OpenShift à nœud unique déplacent une grande partie du processus de mise à jour vers un environnement de pré-production afin de réduire le temps consacré à la mise à jour sur le site de production.

IBU vous permet d'effectuer des mises à jour de flux en z, des mises à jour de version mineures, ainsi que des mises à jour EUS vers EUS, où la version intermédiaire est ignorée. Cette méthode de mise à jour utilise l’agent de cycle de vie pour générer une image OCI à partir d’un cluster de départ dédié qui est installé sur le cluster OpenShift à nœud unique cible en tant que nouveau staterootostree. Un cluster de départ est un cluster OpenShift à nœud unique déployé avec la version cible d'OpenShift Container Platform, les opérateurs déployés et les configurations communes à tous les clusters cibles. Vous utilisez ensuite l’image de noyau pour mettre à jour la version de la plateforme sur n’importe quel cluster OpenShift à nœud unique qui possède la même combinaison de matériel, d’opérateurs et de configuration de cluster que le cluster de noyau.

Par ailleurs, si une mise à jour échoue ou si l'application ne revient pas à un état opérationnel, elle peut être restaurée à l'état antérieur à la mise à jour. Remarque : cela ne s'applique qu'aux clusters OpenShift à un seul nœud. Cela garantit que le service est restauré aussi rapidement que possible en cas de réussite ou d'échec d'une mise à jour. La solution IBU s'intègre parfaitement aux flux de provisionnement automatique qui utilisent Red Hat OpenShift GitOps et Red Hat Advanced Cluster Management.

Création d'appliance OpenShift autonome à grande échelle

Les partenaires qui souhaitent créer des appliances prêtes à l'emploi personnalisées avec une solution OpenShift autonome et des services supplémentaires sur leur matériel réglementaire à grande échelle peuvent désormais utiliser l'outil de création d'appliances basé sur OpenShift, disponible dans le cadre de la version préliminaire. Le créateur d'appliances basé sur OpenShift est un utilitaire basé sur le conteneur qui crée une image disque qui inclut le programme d'installation basé sur l'agent, qui est utilisé pour installer plusieurs clusters OpenShift. Pour plus d’informations, consultez le guide OpenShift-based Appliance Builder User Guide.

Mise en réseau améliorée, gestion GitOps et mises à jour EUS transparentes pour MicroShift

Pour la version Red Hat de MicroShift, la dernière version introduit trois mises à jour pour améliorer la gestion de la périphérie :

1. Associez plusieurs interfaces réseau à des pods Multus CNI pour MicroShift :Multus permet aux pods Kubernetes de s’attacher à plusieurs réseaux, ce qui est utile lorsque vous utilisez SR-IOV ou que vous avez des configurations VLAN complexes. Lorsque Multus est activé sur Microshift, vous pouvez facilement ajouter plusieurs interfaces à des pods à l'aide du pont de plug-ins CNI, macvlan ou ipvlan
2. Automatiser la gestion de l'infrastructure et des applications avec GitOps pour MicroShift : Avec GitOps pour MicroShift, vous pouvez configurer et déployer de manière cohérente une infrastructure et des applications basées sur Kubernetes dans les clusters et dans les cycles de développement. La solution GitOps avec Argo CD pour MicroShift est un module complémentaire léger et optionnel, dérivé de l'opérateur GitOps de Red Hat OpenShift. GitOps pour MicroShift utilise l'interface en ligne de commande Argo CD pour interagir avec le contrôleur GitOps qui fait office de moteur GitOps déclaratif.
3. Mises à jour EUS directes pour MicroShift :MicroShift est désormais directement mis à jour depuis la version 4.14 à la version 4.16 en un seul redémarrage (Red Hat Enterprise Linux 9.4 est requis pour la version 4.16)

Essayez Red Hat OpenShift 4.16

Lancez-vous dès aujourd'hui avec Red Hat Hybrid Cloud Console et profitez des dernières fonctions et améliorations d'OpenShift. Voici quelques ressources pour découvrir les prochaines étapes :

• What's New and What's Next in Red Hat OpenShift
• YouTube d'OpenShift
• Les blogs d'OpenShift
• OpenShift Commons
• Red Hat Developer Blogs
• Red Hat Portfolio Architecture Center

Une liste complète des mises à jour de Red Hat OpenShift 4.16 se trouve dans Notes de version de Red Hat OpenShift 4.16. Faites-nous part de vos commentaires par le biais de vos contacts Red Hat, envoyez-nous un message à l'adresse OpenShift Commons Slack ou ouvrez un dossier sur GitHub.