1.3. Nouvelles fonctionnalités et améliorations

Les nœuds Red Hat Enterprise Linux CoreOS (RHCOS) installés à partir d'une image de démarrage OpenShift Container Platform 4.12 utilisent désormais une console par défaut spécifique à la plateforme. Les consoles par défaut sur les plateformes cloud correspondent aux consoles système spécifiques attendues par ce fournisseur de cloud. Les images VMware et OpenStack utilisent désormais une console graphique principale et une console série secondaire. Les autres installations bare metal n'utilisent plus que la console graphique par défaut et n'activent pas de console série. Les installations réalisées à l'aide de coreos-installer peuvent remplacer les valeurs par défaut existantes et activer la console série.

Les nœuds existants ne sont pas concernés. Les nouveaux nœuds des clusters existants ne sont pas susceptibles d'être affectés car ils sont généralement installés à partir de l'image de démarrage utilisée à l'origine pour l'installation du cluster.

Pour plus d'informations sur l'activation de la console série, voir la documentation suivante :

OpenShift Container Platform prend désormais en charge la configuration des nœuds Red Hat Enterprise Linux CoreOS (RHCOS) pour IBM Secure Execution sur IBM zSystems et LinuxONE (architecture s390x) en tant que fonctionnalité Technology Preview. IBM Secure Execution est une amélioration matérielle qui protège les limites de la mémoire pour les invités KVM. IBM Secure Execution fournit le plus haut niveau d'isolation et de sécurité pour les charges de travail en cluster, et vous pouvez l'activer en utilisant une image de démarrage QCOW2 prête pour IBM Secure Execution.

Pour utiliser IBM Secure Execution, vous devez disposer de clés hôte pour votre (vos) machine(s) hôte(s) et les spécifier dans votre fichier de configuration Ignition. IBM Secure Execution chiffre automatiquement vos volumes de démarrage à l'aide du chiffrement LUKS.

Pour plus d'informations, voir Installation de RHCOS à l'aide d'IBM Secure Execution.

RHCOS utilise désormais les paquets Red Hat Enterprise Linux (RHEL) 8.6 dans OpenShift Container Platform 4.12. Cela vous permet de bénéficier des derniers correctifs, fonctionnalités et améliorations, ainsi que des dernières mises à jour de la prise en charge matérielle et des pilotes. OpenShift Container Platform 4.10 est une version Extended Update Support (EUS) qui continuera à utiliser les paquets RHEL 8.4 EUS pendant toute la durée de son cycle de vie.

Assisted Installer SaaS sur console.redhat.com prend en charge l'installation d'OpenShift Container Platform sur la plateforme Nutanix avec l'intégration Machine API en utilisant soit l'interface utilisateur Assisted Installer, soit l'API REST. L'intégration permet aux utilisateurs de Nutanix Prism de gérer leur infrastructure à partir d'une interface unique, et permet l'auto-scaling. Il y a quelques étapes d'installation supplémentaires pour permettre l'intégration de Nutanix avec Assisted Installer SaaS. Voir la documentation Assisted Installer pour plus de détails.

À partir d'OpenShift Container Platform 4.12, vous pouvez spécifier soit Network Load Balancer (NLB) soit Classic comme type d'équilibreur de charge persistant dans AWS lors de l'installation. Par la suite, si un contrôleur d'entrée est supprimé, le type d'équilibreur de charge persiste avec le lbType configuré lors de l'installation.

Pour plus d'informations, voir Installation d'un cluster sur AWS avec personnalisation du réseau.

Avec cette mise à jour, vous pouvez installer OpenShift Container Platform sur un VPC existant avec une infrastructure fournie par l'installateur, en étendant les nœuds de travail aux sous-réseaux des zones locales. Le programme d'installation fournira des nœuds de travail à la périphérie du réseau AWS qui sont spécifiquement désignés pour les applications utilisateur en utilisant les taches NoSchedule. Les applications déployées dans les zones locales offrent une faible latence aux utilisateurs finaux.

Pour plus d'informations, voir Installation d'un cluster à l'aide des zones locales AWS.

OpenShift Container Platform est désormais disponible sur le GCP Marketplace. L'installation d'OpenShift Container Platform avec une image GCP Marketplace vous permet de créer des déploiements de clusters autogérés qui sont facturés sur la base d'un paiement à l'utilisation (à l'heure, par cœur) via GCP, tout en continuant à être pris en charge directement par Red Hat.

Pour plus d'informations sur l'installation à l'aide d'une infrastructure fournie par l'installateur, voir Utilisation d'une image GCP Marketplace. Pour plus d'informations sur l'installation à l'aide d'une infrastructure fournie par l'utilisateur, voir Création de machines de travail supplémentaires dans GCP.

Le programme d'installation recueille désormais les journaux de la console série des hôtes bootstrap et control plane sur GCP et Azure. Ces données sont ajoutées au paquet de logs bootstrap standard.

Pour plus d'informations, voir Résolution des problèmes d'installation.

IBM Cloud VPC est désormais disponible dans OpenShift Container Platform 4.12.

Pour plus d'informations sur l'installation d'un cluster, voir Préparation de l'installation sur IBM Cloud VPC.

OpenShift Container Platform 4.12 utilise Kubernetes 1.25, qui a supprimé plusieurs API obsolètes.

Un administrateur de cluster doit fournir un accusé de réception manuel avant que le cluster puisse être mis à niveau d'OpenShift Container Platform 4.11 à 4.12. Cela permet d'éviter les problèmes après la mise à niveau vers OpenShift Container Platform 4.12, lorsque les API qui ont été supprimées sont encore utilisées par des charges de travail, des outils ou d'autres composants fonctionnant sur le cluster ou interagissant avec lui. Les administrateurs doivent évaluer leur cluster pour déterminer si des API utilisées seront supprimées et migrer les composants concernés pour qu'ils utilisent la nouvelle version appropriée de l'API. Une fois cette opération effectuée, l'administrateur peut fournir l'accusé de réception de l'administrateur.

Tous les clusters OpenShift Container Platform 4.11 nécessitent cette reconnaissance de l'administrateur avant de pouvoir être mis à niveau vers OpenShift Container Platform 4.12.

Pour plus d'informations, voir Préparation de la mise à jour vers OpenShift Container Platform 4.12.

À partir d'OpenShift Container Platform 4.12, vous pouvez activer un ensemble de fonctionnalités dans le cadre du processus d'installation. Un ensemble de fonctionnalités est une collection de fonctionnalités d'OpenShift Container Platform qui ne sont pas activées par défaut.

Pour plus d'informations sur l'activation d'un ensemble de fonctionnalités lors de l'installation, voir Activation des fonctionnalités d'OpenShift Container Platform à l'aide des portes de fonctionnalités.

OpenShift Container Platform 4.12 est désormais pris en charge sur les infrastructures Azure provisionnées par l'installateur et basées sur l'architecture ARM. Les processeurs AWS Graviton 3 sont désormais disponibles pour les déploiements de clusters et sont également pris en charge par OpenShift Container Platform 4.11. Pour plus d'informations sur la disponibilité des instances et la documentation d'installation, voir Méthodes d'installation prises en charge pour différentes plateformes

L'utilisation du plugin CLI oc-mirror pour mettre en miroir des images d'opérateurs de catalogue basées sur des fichiers au format OCI au lieu du format Docker v2 est désormais disponible en tant qu'aperçu technologique.

Pour plus d'informations, voir Mise en miroir d'images d'opérateurs de catalogues basés sur des fichiers au format OCI.

Dans OpenShift Container Platform 4.12, vous pouvez installer un cluster sur GCP dans un VPC partagé en tant qu'aperçu technologique. Dans cette méthode d'installation, le cluster est configuré pour utiliser un VPC d'un projet GCP différent. Un VPC partagé permet à une organisation de connecter les ressources de plusieurs projets à un réseau VPC commun. Vous pouvez communiquer au sein de l'organisation de manière sécurisée et efficace en utilisant les adresses IP internes de ce réseau.

Pour plus d'informations, voir Installer un cluster sur GCP dans un VPC partagé.

Avec cette mise à jour, dans les installations bare-metal sans réseau de provisionnement, le service Ironic API est accessible via un serveur proxy. Ce serveur proxy fournit une adresse IP cohérente pour le service Ironic API. Si le pod Metal3 qui contient metal3-ironic est déplacé vers un autre pod, l'adresse proxy cohérente assure une communication constante avec le service Ironic API.

Dans OpenShift Container Platform 4.12, vous pouvez installer un cluster sur GCP en utilisant une machine virtuelle à laquelle est attaché un compte de service. Cela vous permet d'effectuer une installation sans avoir besoin d'utiliser un fichier JSON de compte de service.

Pour plus d'informations, voir Création d'un compte de service GCP.

Dans OpenShift Container Platform 4.12, le paramètre propagateUserTags est un drapeau qui indique aux opérateurs en cluster d'inclure les balises utilisateur spécifiées dans les balises des ressources AWS que les opérateurs créent.

Pour plus d'informations, voir Paramètres de configuration optionnels.

Dans les versions antérieures d'OpenShift Container Platform, les images de conteneurs Ironic utilisaient Red Hat Enterprise Linux (RHEL) 8 comme image de base. À partir de la version 4.12 d'OpenShift Container Platform, les images de conteneurs Ironic utilisent RHEL 9 comme image de base. L'image de base RHEL 9 ajoute la prise en charge de CentOS Stream 9, Python 3.8 et Python 3.9 dans les composants Ironic.

Pour plus d'informations sur le service de provisionnement Ironic, voir Déployer des clusters provisionnés par l'installateur sur du métal nu.

Dans OpenShift Container Platform 4.12, les clusters qui s'exécutent sur Red Hat OpenStack Platform (RHOSP) passent du fournisseur de cloud OpenStack hérité au Cloud Controller Manager (CCM) externe. Ce changement fait suite à l'évolution de Kubernetes, qui est passé de fournisseurs de clouds traditionnels à des fournisseurs de clouds externes mis en œuvre à l'aide du gestionnaire de contrôleur de clouds.

Pour plus d'informations, voir OpenStack Cloud Controller Manager.

Dans OpenShift Container Platform 4.12, les déploiements de clusters vers les clouds Red Hat OpenStack Platform (RHOSP) qui ont une architecture de nœuds de calcul distribués (DCN) ont été validés. Une architecture de référence pour ces déploiements est à venir.

Pour un bref aperçu de ce type de déploiement, consultez l'article de blog Déployer votre cluster à la périphérie avec OpenStack.

OpenShift Container Platform 4.12 est maintenant supporté sur la plateforme AWS Outposts en tant que Technology Preview. Avec AWS Outposts, vous pouvez déployer des nœuds de travailleurs en périphérie, tout en utilisant AWS Regions pour les nœuds du plan de contrôle. Pour plus d'informations, voir Installer un cluster sur AWS avec des travailleurs distants sur AWS Outposts.

L'installation basée sur l'agent prend en charge deux modes de saisie :

Avec le mode préféré, vous pouvez configurer le fichier install-config.yaml et spécifier les paramètres spécifiques à l'agent dans le fichier agent-config.yaml. Pour plus d'informations, voir À propos de l'installateur OpenShift Container Platform basé sur l'agent.

L'installateur OpenShift Container Platform basé sur un agent prend en charge les clusters OpenShift Container Platform en mode conforme aux normes fédérales de traitement de l'information (FIPS). Vous devez définir la valeur du champ fips sur True dans le fichier install-config.yaml. Pour plus d'informations, voir À propos de la conformité FIPS.

Vous pouvez effectuer une installation basée sur l'agent dans un environnement déconnecté. Pour créer une image utilisée dans un environnement déconnecté, la section imageContentSources du fichier install-config.yaml doit contenir les informations sur le miroir ou le fichier registries.conf si vous utilisez des manifestes ZTP. Les paramètres de configuration à utiliser dans ces fichiers sont fournis par la commande oc adm release mirror ou oc mirror. Pour plus d'informations, voir Comprendre la mise en miroir d'une installation déconnectée.

Vous pouvez créer l'image ISO de l'agent avec les configurations d'adresses IP suivantes :

Pour plus d'informations, voir Clusters de piles IP simples et doubles.

Vous pouvez installer le moteur multicluster pour Kubernetes Operator et déployer un hub cluster avec l'installateur OpenShift Container Platform basé sur l'agent. Pour plus d'informations, voir Préparation d'un cluster installé à l'aide d'un agent pour le moteur multicluster de Kubernetes Operator.

L'installateur de la plateforme OpenShift Container basé sur un agent effectue des validations sur :

Pour plus d'informations, voir les validations d'installation.

Avec l'installateur OpenShift Container Platform basé sur l'agent, vous pouvez configurer des adresses IP statiques pour IPv4, IPv6, ou dual-stack (à la fois IPv4 et IPv6) pour tous les hôtes avant de créer l'image ISO de l'agent. Vous pouvez ajouter les adresses statiques à la section hosts du fichier agent-config.yaml ou au fichier NMStateConfig.yaml si vous utilisez les manifestes ZTP. Notez que la configuration des adresses doit suivre les règles de syntaxe pour NMState comme décrit dans les exemples d'état de NMState.

Pour plus d'informations, voir À propos de la mise en réseau.

Avec l'installateur OpenShift Container Platform basé sur un agent, vous pouvez définir vos configurations d'installation, générer une ISO pour tous les nœuds, puis effectuer une installation sans surveillance en démarrant les systèmes cibles avec l'ISO générée. Pour plus d'informations, voir Installation d'un cluster OpenShift Container Platform avec l'installateur OpenShift Container Platform basé sur un agent.

Vous pouvez configurer le nom d'hôte, la configuration du réseau au format NMState, les indices du périphérique racine et le rôle dans une installation basée sur un agent.

Pour plus d'informations, voir À propos des conseils sur le périphérique racine.

Avec l'installateur OpenShift Container Platform basé sur un agent, vous pouvez déployer dans des environnements où vous comptez sur DHCP pour configurer le réseau pour tous les nœuds, à condition que vous connaissiez l'IP qu'au moins l'un des systèmes recevra. Cette IP est nécessaire pour que tous les nœuds l'utilisent comme point de rencontre. Pour plus d'informations, voir DHCP.

Pour installer un pilote CSI sur un cluster fonctionnant sous vSphere, les conditions suivantes doivent être remplies :

Les composants dont les versions sont antérieures à celles mentionnées ci-dessus sont toujours pris en charge, mais sont obsolètes. Ces versions sont toujours entièrement prises en charge, mais la version 4.12 d'OpenShift Container Platform nécessite la version 15 ou ultérieure du matériel virtuel vSphere. Pour plus d'informations, voir Fonctionnalités obsolètes et supprimées.

Le non-respect des exigences ci-dessus empêche la mise à niveau d'OpenShift Container Platform vers OpenShift Container Platform 4.13 ou une version ultérieure.

Les nouvelles capacités suivantes ont été ajoutées :

Un nouvel ensemble prédéfini de capacités de cluster, v4.12, a été ajouté. Il comprend toutes les fonctionnalités de v4.11, ainsi que les nouvelles fonctionnalités ajoutées dans la version actuelle.

Pour plus d'informations, voir le lien : Activation des capacités des clusters.

OpenShift Container Platform 4.12 avec des machines de calcul multi-architecture prend désormais en charge les images listées dans le manifeste sur les flux d'images. Pour plus d'informations sur les images de la liste de manifeste, voir Configuration des machines de calcul multi-architecture sur un cluster OpenShift Container Platform.

Sur un cluster avec des machines de calcul multi-architectures, vous pouvez désormais remplacer l'affinité de nœud dans l'objet Subscription de l'opérateur pour planifier des pods sur des nœuds avec des architectures prises en charge par l'opérateur. Pour plus d'informations, voir Utilisation de l'affinité de nœud pour contrôler l'emplacement d'installation d'un opérateur.

Cette version comporte plusieurs mises à jour de la perspective Administrator de la console web.

Cette version comporte plusieurs mises à jour de la perspective Developer de la console web. Vous pouvez effectuer les actions suivantes :

L'utilisation de Krew pour installer et gérer des plugins pour l'OpenShift CLI (oc) est maintenant disponible en tant que Technology Preview.

Pour plus d'informations, voir Gérer les plugins CLI avec Krew.

L'opérateur de profils de sécurité (SPO) est désormais disponible pour OpenShift Container Platform 4.12 et les versions ultérieures.

Le SPO permet de définir des profils informatiques sécurisés(seccomp) et des profils SELinux en tant que ressources personnalisées, en synchronisant les profils avec chaque nœud d'un espace de noms donné.

Pour plus d'informations, voir Profils de sécurité - Présentation de l'opérateur.

Assisted Installer prend en charge l'installation d'OpenShift Container Platform 4.12 et des versions ultérieures avec un réseau à double pile pour l'API VIP et l'Ingress VIP sur le métal nu uniquement. Cette prise en charge introduit deux nouveaux paramètres de configuration : api_vips et ingress_vips, qui peuvent prendre une liste d'adresses IP. Les anciens paramètres, api_vip et ingress_vip, doivent également être définis dans OpenShift Container Platform 4.12 ; cependant, comme ils ne prennent qu'une seule adresse IP, vous devez définir l'adresse IPv4 lors de la configuration de la mise en réseau à double pile pour l'API VIP et l'Ingress VIP à l'aide des anciens paramètres de configuration api_vip et ingress_vip.

L'adresse VIP API et l'adresse VIP Ingress doivent appartenir à la famille d'adresses IP primaire lors de l'utilisation d'un réseau à double pile. Actuellement, Red Hat ne prend pas en charge les VIP à double pile ou la mise en réseau à double pile avec IPv6 comme famille d'adresses IP primaire. Cependant, Red Hat prend en charge la mise en réseau à double pile avec IPv4 comme famille d'adresses IP primaire. Par conséquent, vous devez placer les entrées IPv4 avant les entrées IPv6. Pour plus d'informations, consultez la documentation d'Assisted Installer.

Red Hat OpenShift Networking est un écosystème de fonctionnalités, de plugins et de capacités de mise en réseau avancées qui étendent la mise en réseau de Kubernetes au-delà du plugin CNI de Kubernetes avec les fonctionnalités avancées liées à la mise en réseau dont votre cluster a besoin pour gérer son trafic réseau pour un ou plusieurs clusters hybrides. Cet écosystème de capacités de mise en réseau intègre l'entrée, la sortie, l'équilibrage de charge, le débit haute performance, la sécurité et la gestion du trafic inter- et intra-cluster et fournit un outil d'observabilité basé sur les rôles pour réduire ses complexités naturelles.

Pour plus d'informations, voir À propos de la mise en réseau.

Lors de l'installation d'un nouveau cluster, le plugin réseau OVN-Kubernetes est le plugin réseau par défaut. Pour toutes les versions antérieures d'OpenShift Container Platform, OpenShift SDN reste le plugin réseau par défaut.

Le plugin réseau OVN-Kubernetes comprend un plus large éventail de fonctionnalités qu'OpenShift SDN, notamment :

OpenShift Container Platform 4.12 présente également d'énormes améliorations en termes d'échelle, de performances et de stabilité par rapport aux versions précédentes.

Si vous utilisez le plugin réseau OpenShift SDN, notez que :

Pour plus d'informations sur OVN-Kubernetes, y compris une matrice de comparaison des fonctionnalités avec OpenShift SDN, voir À propos du plugin réseau OVN-Kubernetes.

Pour plus d'informations sur la migration vers OVN-Kubernetes depuis OpenShift SDN, voir Migrations depuis le plugin réseau OpenShift SDN.

Cette mise à jour introduit un nouvel opérateur de pare-feu sans état pour les nœuds d'entrée. Vous pouvez désormais configurer des règles de pare-feu au niveau du nœud. Pour plus d'informations, voir Opérateur de pare-feu de nœud d'entrée.

Les métriques suivantes sont désormais disponibles pour le plugin réseau OVN-Kubernetes :

La métrique suivante a été supprimée :

À partir d'OpenShift Container Platform 4.12, la possibilité de configurer plusieurs centres de données vCenter et plusieurs clusters vCenter dans une seule installation vCenter en utilisant l'infrastructure fournie par l'installateur est maintenant disponible en tant que fonctionnalité de l'aperçu technologique. En utilisant les balises vCenter, vous pouvez utiliser cette fonctionnalité pour associer les centres de données vCenter et les clusters de calcul avec des régions et des zones openshift. Ces associations définissent des domaines de défaillance pour permettre aux charges de travail des applications d'être associées à des emplacements et à des domaines de défaillance spécifiques.

À partir d'OpenShift Container Platform 4.12, vous pouvez configurer les paramètres de mise en réseau tels que les serveurs DNS ou les domaines de recherche, les VLAN, les ponts et le collage d'interface à l'aide de l'opérateur Kubernetes NMState sur votre instance VMware vSphere.

Pour plus d'informations, voir À propos de l'opérateur NMState de Kubernetes.

À partir d'OpenShift Container Platform 4.12, vous pouvez configurer les paramètres de mise en réseau tels que les serveurs DNS ou les domaines de recherche, les VLAN, les ponts et le collage d'interface à l'aide de l'opérateur Kubernetes NMState sur votre instance OpenStack.

Pour plus d'informations, voir À propos de l'opérateur NMState de Kubernetes.

Dans OpenShift Container Platform 4.12, l'Opérateur DNS Externe modifie le format des enregistrements TXT wildcard ExternalDNS sur AzureDNS. L'Opérateur DNS externe remplace l'astérisque par any dans les enregistrements TXT wildcard ExternalDNS. Vous devez éviter que les enregistrements Wildcard A et CNAME de ExternalDNS aient any comme sous-domaine le plus à gauche car cela pourrait causer un conflit.

La version amont de ExternalDNS pour OpenShift Container Platform 4.12 est v0.13.1.

Dans OpenShift Container Platform 4.12, le Cluster Ingress Operator exporte une nouvelle métrique nommée route_metrics_controller_routes_per_shard. L'étiquette shard_name de la métrique spécifie le nom des tessons. Cette métrique indique le nombre total d'itinéraires admis par chaque shard.

Les mesures suivantes sont envoyées par télémétrie.

Dans OpenShift Container Platform 4.12, le contrôleur AWS Load Balancer implémente désormais la spécification Kubernetes Ingress pour les correspondances multiples. Si plusieurs chemins au sein d'un Ingress correspondent à une demande, le chemin le plus long est prioritaire. Si deux chemins correspondent encore, les chemins avec un type de chemin exact sont prioritaires sur un type de chemin préfixe.

L'opérateur de l'équilibreur de charge AWS définit la porte de fonctionnalité EnableIPTargetType sur false. Le contrôleur de l'équilibreur de charge AWS désactive la prise en charge des services et des ressources d'entrée pour target-type ip .

La version amont de aws-load-balancer-controller pour OpenShift Container Platform 4.12 est v2.4.4.

Vous pouvez maintenant utiliser l'opérateur Custom Metrics Autoscaler d'OpenShift Container Platform pour mettre à l'échelle dynamiquement le contrôleur d'ingestion par défaut en fonction des métriques de votre cluster déployé, telles que le nombre de nœuds de travail disponibles. Le Custom Metrics Autoscaler est disponible en tant que fonctionnalité Technology Preview.

Pour plus d'informations, voir Autoscaling an Ingress Controller (Mise à l'échelle automatique d'un contrôleur d'entrée).

Dans OpenShift Container Platform 4.12, la valeur par défaut du paramètre maxConnections est désormais 50000. Auparavant, à partir d'OpenShift Container Platform 4.11, la valeur par défaut du paramètre maxConnections était 20000.

Pour plus d'informations, voir les paramètres de configuration du contrôleur d'entrée.

Vous pouvez maintenant configurer un contrôleur d'entrée pour arrêter la gestion automatique du DNS et démarrer la gestion manuelle du DNS. Définissez le paramètre dnsManagementPolicy pour spécifier la gestion automatique ou manuelle du DNS.

Pour plus d'informations, voir Configuration d'un contrôleur d'entrée pour gérer manuellement le DNS.

OpenShift Container Platform 4.12 ajoute la prise en charge des périphériques SR-IOV suivants :

Pour plus d'informations, voir Dispositifs pris en charge.

OpenShift Container Platform 4.12 ajoute la prise en charge OvS Hardware Offload pour les périphériques suivants :

Pour plus d'informations, voir Dispositifs pris en charge.

OpenShift Container Platform 4.12 ajoute la prise en charge de la configuration de la politique multiréseau pour les périphériques SR-IOV.

Vous pouvez désormais configurer le multiréseau pour les réseaux supplémentaires SR-IOV. La configuration des réseaux supplémentaires SR-IOV est une fonctionnalité de l'aperçu technologique et n'est prise en charge qu'avec les cartes d'interface réseau (NIC) du noyau.

Pour plus d'informations, voir Configuration de la politique multi-réseaux.

Vous pouvez mettre à jour le contrôleur d'entrée pour passer d'un équilibreur de charge classique AWS (CLB) à un équilibreur de charge réseau AWS (NLB) sans supprimer le contrôleur d'entrée.

Pour plus d'informations, voir Configuration du trafic d'entrée des clusters sur AWS.

Les pods créés avec le plugin CNI SR-IOV (Single Root I/O Virtualization), auxquels le plugin CNI de gestion des adresses IP a attribué des IP, envoient désormais par défaut sur le réseau des annonces de voisinage non sollicitées IPv6 et/ou un protocole de résolution d'adresse gratuit IPv4. Cette amélioration notifie aux hôtes l'adresse MAC du nouveau pod pour une IP particulière afin de rafraîchir les caches ARP/NDP avec les informations correctes.

Pour plus d'informations, voir Dispositifs pris en charge.

Vous pouvez maintenant configurer la durée de vie (TTL) des requêtes DNS réussies et non réussies mises en cache par CoreDNS.

Pour plus d'informations, voir Optimisation du cache CoreDNS.

Auparavant, le sous-réseau utilisé en interne par OVN-Kubernetes était 100.64.0.0/16 pour IPv4 et fd98::/48 pour IPv6 et ne pouvait pas être modifié. Pour prendre en charge les cas où ces sous-réseaux se chevauchent avec des sous-réseaux existants dans votre infrastructure, vous pouvez désormais modifier ces sous-réseaux internes pour éviter tout chevauchement.

Pour plus d'informations, voir l'objet de configuration Cluster Network Operator

RHOSP, associé à OpenShift Container Platform, prend désormais en charge l'attachement et le détachement automatiques des adresses IP Egress. Le trafic provenant d'un ou plusieurs pods dans un nombre quelconque d'espaces de noms dispose d'une adresse IP source cohérente pour les services extérieurs au cluster. Cette prise en charge s'applique à OpenShift SDN et OVN-Kubernetes en tant que fournisseurs de réseau par défaut.

Si vous prévoyez de migrer du plugin réseau OpenShift SDN vers le plugin réseau OVN-Kubernetes, vos configurations pour les capacités suivantes sont automatiquement converties pour fonctionner avec OVN-Kubernetes :

Pour plus d'informations sur le fonctionnement de la migration vers OVN-Kubernetes, voir Migrations à partir du fournisseur de réseau de cluster SDN OpenShift.

Pour le plugin réseau OVN-Kubernetes, les pare-feu de sortie prennent en charge la journalisation des audits à l'aide du même mécanisme que la journalisation des audits de stratégie réseau. Pour plus d'informations, voir Journalisation des règles de pare-feu de sortie et de stratégie réseau.

Avec cette mise à jour, en mode BGP, vous pouvez utiliser le sélecteur de nœuds pour annoncer le service MetalLB à partir d'un sous-ensemble de nœuds, en utilisant un pool spécifique d'adresses IP. Cette fonctionnalité a été introduite en tant qu'aperçu technologique dans OpenShift Container Platform 4.11 et est maintenant disponible dans OpenShift Container Platform 4.12 pour le mode BGP uniquement. Le mode L2 reste une fonctionnalité d'aperçu technologique.

Pour plus d'informations, voir Publicité d'un pool d'adresses IP à partir d'un sous-ensemble de nœuds.

Cette mise à jour fournit des spécifications de déploiement supplémentaires pour MetalLB. Lorsque vous utilisez une ressource personnalisée pour déployer MetalLB, vous pouvez utiliser ces spécifications de déploiement supplémentaires pour gérer le déploiement et l'exécution des pods MetalLB speaker et controller dans votre cluster. Par exemple, vous pouvez utiliser les spécifications de déploiement MetalLB pour gérer l'endroit où les pods MetalLB sont déployés, définir des limites de CPU pour les pods MetalLB et attribuer des classes d'exécution aux pods MetalLB.

Pour plus d'informations sur les spécifications de déploiement pour MetalLB, voir Spécifications de déploiement pour MetalLB.

Auparavant, le service nodeip-configuration sur un hôte du cluster sélectionnait l'adresse IP de l'interface utilisée par la route par défaut. Si plusieurs routes étaient présentes, le service sélectionnait la route ayant la valeur métrique la plus faible. Par conséquent, le trafic réseau pouvait être distribué à partir de l'interface incorrecte.

Avec OpenShift Container Platform 4.12, une nouvelle interface a été ajoutée au service nodeip-configuration, qui permet aux utilisateurs de créer un fichier d'indices. Ce fichier contient une variable, NODEIP_HINT, qui remplace la logique de sélection IP par défaut et sélectionne une adresse IP de nœud spécifique à partir de la variable de sous-réseau NODEIP_HINT. L'utilisation de la variable NODEIP_HINT permet aux utilisateurs de spécifier l'adresse IP utilisée, ce qui garantit que le trafic réseau est distribué à partir de l'interface correcte.

Pour plus d'informations, voir Facultatif : Remplacer la logique de sélection de l'IP du nœud par défaut.

Dans OpenShift Container Platform 4.12, CoreDNS utilise la version 1.10.0, qui inclut les changements suivants :

Avec cette mise à jour, un administrateur de cluster peut configurer l'intervalle de rechargement pour forcer HAProxy à recharger sa configuration moins fréquemment en réponse aux mises à jour des routes et des points d'extrémité. L'intervalle minimum de rechargement de HAProxy par défaut est de 5 secondes.

Pour plus d'informations, voir Configuration de l'intervalle de recharge de HAProxy.

En tant qu'administrateur, vous pouvez maintenant installer le Network Observability Operator pour observer le trafic réseau du cluster OpenShift Container Platform dans la console. Vous pouvez visualiser et surveiller les données du trafic réseau dans différentes représentations graphiques. Le Network Observability Operator utilise la technologie eBPF pour créer les flux réseau. Les flux réseau sont enrichis avec les informations d'OpenShift Container Platform et stockés dans Loki. Vous pouvez utiliser les informations sur le trafic réseau pour un dépannage et une analyse détaillés.

Pour plus d'informations, voir Observabilité du réseau.

IPv6 pour les interfaces réseau secondaires est désormais pris en charge dans les clusters fonctionnant sous RHOSP.

Pour plus d'informations, voir Activation de la connectivité IPv6 aux pods sur RHOSP.

Suite au passage à un fournisseur externe de cloud OpenStack, UDP est désormais pris en charge pour les services LoadBalancer pour les clusters qui fonctionnent sur cette plateforme.

Si vous avez configuré et déployé votre cluster de services d'hébergement, vous pouvez maintenant déployer l'opérateur SR-IOV pour un cluster hébergé. Pour plus d'informations, voir Déploiement de l'opérateur SR-IOV pour les plans de contrôle hébergés.

Avec cette mise à jour, dans les clusters d'infrastructure fournis par l'installateur, les paramètres de configuration ingressVIP et apiVIP du fichier install-config.yaml sont obsolètes. Utilisez plutôt les paramètres de configuration ingressVIPs et apiVIPs. Ces paramètres prennent en charge la mise en réseau à double pile pour les applications sur métal nu qui nécessitent un accès IPv4 et IPv6 au cluster en utilisant les services Ingress VIP et API VIP. Les paramètres de configuration ingressVIPs et apiVIPs utilisent un format de liste pour spécifier une adresse IPv4, une adresse IPv6 ou les deux formats d'adresse IP. L'ordre de la liste indique l'adresse VIP primaire et secondaire pour chaque service. L'adresse IP primaire doit provenir du réseau IPv4 en cas d'utilisation d'un réseau à double pile.

Avec cette mise à jour, vous pouvez faire passer le périphérique réseau BlueField-2 du mode unité de traitement des données (DPU) au mode contrôleur d'interface réseau (NIC).

Pour plus d'informations, voir Passer Bluefield-2 de DPU à NIC.

OpenShift Container Platform est capable de provisionner des volumes persistants (PV) en utilisant le pilote CSI (Container Storage Interface) pour Google Compute Platform (GCP) Filestore. L'opérateur du pilote CSI de GCP Filestore qui gère ce pilote est en avant-première technologique.

Pour plus d'informations, voir GCP Filestore CSI Driver Operator.

À partir d'OpenShift Container Platform 4.8, la migration automatique pour les plugins de volume in-tree vers leurs pilotes équivalents Container Storage Interface (CSI) est devenue disponible en tant que fonctionnalité d'aperçu technologique. La prise en charge de l'Elastic Block Storage (EBS) d'Amazon Web Services (AWS) a été fournie dans cette fonctionnalité dans OpenShift Container Platform 4.8, et OpenShift Container Platform 4.12 prend désormais en charge la migration automatique pour AWS EBS en tant que disponibilité générale. La migration CSI pour AWS EBS est désormais activée par défaut et ne nécessite aucune action de la part d'un administrateur.

Cette fonction traduit automatiquement les objets de l'arborescence en leurs représentations CSI correspondantes et devrait être totalement transparente pour les utilisateurs. Les objets traduits ne sont pas stockés sur le disque et les données des utilisateurs ne sont pas migrées.

Bien que le référencement de la classe de stockage au plugin de stockage dans l'arborescence continue de fonctionner, il est recommandé de remplacer la classe de stockage par défaut par la classe de stockage CSI.

Pour plus d'informations, voir Migration automatique CSI.

À partir d'OpenShift Container Platform 4.8, la migration automatique pour les plugins de volume in-tree vers leurs pilotes équivalents Container Storage Interface (CSI) est devenue disponible en tant que fonctionnalité d'aperçu technologique. La prise en charge de Google Compute Engine Persistent Disk (GCP PD) a été fournie dans cette fonctionnalité dans OpenShift Container Platform 4.9, et OpenShift Container Platform 4.12 prend désormais en charge la migration automatique pour GCP PD en tant que fonctionnalité généralement disponible. La migration CSI pour GCP PD est désormais activée par défaut et ne nécessite aucune action de la part d'un administrateur.

Cette fonction traduit automatiquement les objets de l'arborescence en leurs représentations CSI correspondantes et devrait être totalement transparente pour les utilisateurs. Les objets traduits ne sont pas stockés sur le disque et les données des utilisateurs ne sont pas migrées.

Bien que le référencement de la classe de stockage au plugin de stockage dans l'arborescence continue de fonctionner, il est recommandé de remplacer la classe de stockage par défaut par la classe de stockage CSI.

Pour plus d'informations, voir Migration automatique CSI.

Cette nouvelle fonctionnalité expose la capacité de stockage actuellement disponible à l'aide d'objets CSIStorageCapacity, et améliore la planification des pods qui utilisent des volumes CSI (Container Storage Interface) avec une liaison tardive. Actuellement, le seul type de stockage d'OpenShift Container Platform qui supporte cette fonctionnalité est OpenShift Data Foundation.

OpenShift Container Platform offre la possibilité de déployer OpenShift Container Platform for vSphere sur différentes zones et régions, ce qui vous permet de déployer sur plusieurs clusters de calcul, contribuant ainsi à éviter un point de défaillance unique.

Pour plus d'informations, voir topologie vSphere CSI.

La fonctionnalité de gestion des ressources de stockage éphémère local est désormais disponible. Grâce à cette fonctionnalité, vous pouvez gérer le stockage éphémère local en spécifiant des demandes et des limites.

Pour plus d'informations, voir Gestion du stockage éphémère.

Les populateurs de volumes utilisent datasource pour permettre la création de volumes pré-remplis.

La population de volume est actuellement activée et prise en charge en tant que fonctionnalité d'aperçu technologique. Cependant, OpenShift Container Platform n'est pas livré avec des populateurs de volume.

Pour plus d'informations, voir Populateurs de volume.

Pour OpenShift Container Platform 4.12, VMWare vSphere Container Storage Interface (CSI) Driver Operator nécessite l'installation des composants minimums suivants :

If a third-party CSI driver is present in the cluster, OpenShift Container Platform does not overwrite it. The presence of a third-party CSI driver prevents OpenShift Container Platform from upgrading to OpenShift Container Platform 4.13 or later.

Pour plus d'informations, voir VMware vSphere CSI Driver Operator requirements.

À partir d'OpenShift Container Platform 4.12, Operator Lifecycle Manager (OLM) introduit le type platform Operator en tant que fonctionnalité d'aperçu technologique. Le mécanisme Operator de la plateforme s'appuie sur les ressources du composant RukPak, également introduit dans OpenShift Container Platform 4.12, pour sourcer et gérer le contenu.

Un opérateur de plateforme est un opérateur basé sur OLM qui peut être installé pendant ou après les opérations du jour 0 d'un cluster OpenShift Container Platform et qui participe au cycle de vie du cluster. En tant qu'administrateur de cluster, vous pouvez utiliser les opérateurs de plateforme pour personnaliser davantage votre installation OpenShift Container Platform afin de répondre à vos exigences et à vos cas d'utilisation.

Pour plus d'informations sur les opérateurs de plate-forme, voir Gestion des opérateurs de plate-forme. Pour plus d'informations sur RukPak et ses ressources, voir Operator Framework packaging format.

Par défaut, lorsque vous installez un Operator, OpenShift Container Platform installe aléatoirement le pod Operator sur l'un de vos worker nodes.

Dans OpenShift Container Platform 4.12, vous pouvez contrôler l'endroit où un pod Operator est installé en ajoutant des contraintes d'affinité à l'objet Subscription de l'Operator.

Pour plus d'informations, voir Contrôle de l'emplacement d'installation d'un opérateur.

Dans OpenShift Container Platform 4.12, la synchronisation de l'admission à la sécurité des pods est activée par défaut si un opérateur est installé dans des espaces de noms créés par l'utilisateur qui ont un préfixe openshift-. La synchronisation est activée après la création d'une version de service de cluster (CSV) dans l'espace de noms. L'étiquette synchronisée hérite des autorisations des comptes de service dans l'espace de noms.

Pour plus d'informations, voir Synchronisation des contraintes de contexte de sécurité avec les normes de sécurité des pods.

Vous pouvez configurer le contexte de sécurité d'un pod de catalogue en utilisant l'indicateur --security-context-config dans les sous-commandes run bundle et bundle-upgrade. Cet indicateur permet aux profils seccomp de se conformer à l'admission de sécurité du pod. L'indicateur accepte les valeurs restricted et legacy. Si vous ne spécifiez pas de valeur, le profil seccomp prend par défaut la valeur restricted. Si votre module de catalogue ne peut pas fonctionner avec des autorisations restreintes, définissez l'indicateur sur legacy, comme indiqué dans l'exemple suivant :

$ operator-sdk run bundle \
  --security-context-config=legacy

Vous pouvez désormais vérifier les manifestes de bundle pour les API obsolètes supprimées de Kubernetes 1.25 en utilisant la suite de tests Operator Framework avec la sous-commande bundle validate.

Par exemple :

$ operator-sdk bundle validate .<bundle_dir_or_image> \
  --select-optional suite=operatorframework \
  --optional-values=k8s-version=1.25

Si votre opérateur demande l'autorisation d'utiliser l'une des API supprimées de Kubernetes 1.25, la commande affiche un message d'avertissement.

Si l'une des versions d'API supprimées de Kubernetes 1.25 est incluse dans la version du service de cluster (CSV) de votre opérateur, la commande affiche un message d'erreur.

Voir Beta APIs removed from Kubernetes 1.25 and the Operator SDK CLI reference pour plus d'informations.

OpenShift Container Platform 4.12 introduit des ensembles de machines de plan de contrôle. Les ensembles de machines du plan de contrôle fournissent des capacités de gestion pour les machines du plan de contrôle qui sont similaires à ce que les ensembles de machines de calcul fournissent pour les machines de calcul. Pour plus d'informations, voir Gestion des machines du plan de contrôle.

OpenShift Container Platform prend désormais en charge la définition de la verbosité du niveau de journal du cluster autoscaler en définissant le paramètre logVerbosity dans la ressource personnalisée ClusterAutoscaler. Pour plus d'informations, voir la définition de la ressourceClusterAutoscaler .

OpenShift Container Platform prend désormais en charge l'activation des diagnostics de démarrage sur les machines Azure créées par votre jeu de machines. Pour plus d'informations, voir "Activation des diagnostics de démarrage Azure" pour les machines de calcul ou les machines de plan de contrôle.

La superposition d'images de Red Hat Enterprise Linux CoreOS (RHCOS) vous permet d'ajouter de nouvelles images au-dessus de l'image RHCOS de base. Cette stratification ne modifie pas l'image RHCOS de base. Au lieu de cela, elle crée un site custom layered image qui inclut toutes les fonctionnalités de RHCOS et ajoute des fonctionnalités supplémentaires à des nœuds spécifiques du cluster.

Actuellement, la stratification d'images RHCOS vous permet de travailler avec Customer Experience and Engagement (CEE) pour obtenir et appliquer des paquets Hotfix sur votre image RHCOS, sur la base de la politique Hotfix de Red Hat. Il est prévu, dans les prochaines versions, que vous puissiez utiliser la stratification d'images RHCOS pour incorporer des logiciels tiers tels que Libreswan ou numactl.

Pour plus d'informations, voir RHCOS image layering.

OpenShift Container Platform prend désormais en charge la mise à jour de la sécurité par défaut spécifique à l'interface sysctls.

Vous pouvez ajouter ou supprimer sysctls de la liste prédéfinie. Lorsque vous ajoutez des sysctls, ils peuvent être définis sur tous les nœuds. La mise à jour de la liste sysctls spécifique à l'interface est une fonctionnalité de l'aperçu technologique uniquement.

Pour plus d'informations, voir Mise à jour de la liste des sysctls sûrs spécifiques à l'interface.

La définition d'un fuseau horaire pour la planification d'une tâche cron est désormais proposée en tant qu'aperçu technologique. Si aucun fuseau horaire n'est spécifié, le gestionnaire de contrôleur Kubernetes interprète la programmation en fonction de son fuseau horaire local.

Pour plus d'informations, voir Création de tâches cron.

La prise en charge par OpenShift Container Platform de Linux Control Group version 2 (cgroup v2) a été promue au rang d'aperçu technologique. cgroup v2 est la prochaine version des groupes de contrôle du noyau. cgroups v2 offre de multiples améliorations, notamment une hiérarchie unifiée, une délégation de sous-arbres plus sûre, de nouvelles fonctionnalités telles que Pressure Stall Information, ainsi qu'une gestion des ressources et une isolation améliorées. Pour plus d'informations, voir Enabling Linux Control Group version 2 (cgroup v2).

OpenShift Container Platform prend désormais en charge le runtime de conteneur crun dans l'aperçu technologique. Vous pouvez basculer entre le moteur d'exécution de conteneur crun et le moteur d'exécution de conteneur par défaut en utilisant une ressource personnalisée (CR) ContainerRuntimeConfig. Pour plus d'informations, voir À propos du moteur de conteneurs et de l'exécution des conteneurs.

OpenShift Container Platform prend désormais en charge la clôture du plan de contrôle par l'opérateur de remédiation des nœuds autonomes. En cas de défaillance d'un nœud, vous pouvez suivre des stratégies de remédiation à la fois sur les nœuds de travail et les nœuds du plan de contrôle. Pour plus d'informations, voir Control Plane Fencing.

OpenShift Container Platform prend désormais en charge la clôture du plan de contrôle sur l'opérateur de vérification de la santé des nœuds. En cas de défaillance d'un nœud, vous pouvez suivre des stratégies de remédiation sur les nœuds de travail et les nœuds du plan de contrôle. Pour plus d'informations, voir Control Plane Fencing.

L'opérateur de bilan de santé des nœuds inclut désormais un plugin de console web pour gérer les bilans de santé des nœuds. Pour plus d'informations, voir Création d'un bilan de santé d'un nœud.

Pour installer ou mettre à jour la dernière version du Node Health Check Operator, utilisez le canal d'abonnement stable. Pour plus d'informations, voir Installation de l'opérateur de contrôle de santé des nœuds à l'aide de l'interface CLI.

Cette version comprend les mises à jour de version suivantes pour les composants et dépendances de la pile de surveillance :

Vous pouvez désormais utiliser les contraintes de répartition de la topologie des pods pour contrôler la répartition des pods Prometheus, Thanos Ruler et Alertmanager sur une topologie de réseau lorsque les pods OpenShift Container Platform sont déployés dans plusieurs zones de disponibilité.

Vous pouvez désormais configurer un moniteur de service kubelet facultatif pour Prometheus Adapter (PA) qui améliore la cohérence des données entre plusieurs requêtes de mise à l'échelle automatique. L'activation de ce moniteur de service élimine la possibilité que deux requêtes envoyées en même temps à PA produisent des résultats différents parce que les requêtes PromQL sous-jacentes exécutées par PA peuvent se trouver sur des serveurs Prometheus différents.

Avec cette version, si vous configurez un secret Alertmanager pour contenir des clés supplémentaires et si la configuration Alertmanager fait référence à ces clés en tant que fichiers (tels que des modèles, des certificats TLS ou des jetons), vos paramètres de configuration doivent pointer vers ces clés en utilisant un chemin d'accès absolu plutôt qu'un chemin d'accès relatif. Ces clés sont disponibles dans le répertoire /etc/alertmanager/config. Dans les versions précédentes d'OpenShift Container Platform, vous pouviez utiliser des chemins relatifs dans votre configuration pour pointer vers ces clés car le fichier de configuration de l'Alertmanager était situé dans le même répertoire que les clés.

Au niveau du cluster, un service systemd définit par défaut un masque RPS (Receive Packet Steering) pour les interfaces réseau virtuelles. Le masque RPS achemine les demandes d'interruption des interfaces réseau virtuelles en fonction de la liste des unités centrales réservées définie dans le profil de performances. Au niveau du conteneur, un script hook CRI-O définit également un masque RPS pour tous les périphériques réseau virtuels.

Avec cette mise à jour, si vous définissez spec.workloadHints.realTime dans le profil de performance sur False, le système désactive également le service systemd et le script hook CRI-O qui définissent le masque RPS. Le système désactive ces fonctions RPS parce que RPS est typiquement pertinent pour les cas d'utilisation nécessitant des charges de travail à faible latence et en temps réel uniquement.

Pour conserver les fonctions RPS même lorsque vous définissez spec.workloadHints.realTime sur False, consultez la section RPS Settings de la solution Performance addons operator advanced configuration de la base de connaissances de Red Hat.

Pour plus d'informations sur la configuration des indices de charge de travail, voir Comprendre les indices de charge de travail.

Le profil tuned définit désormais la valeur fs.aio-max-nr sysctl par défaut, ce qui améliore les performances des E/S asynchrones pour les profils de nœuds par défaut.

Le réglage de la faible latence a été mis à jour pour utiliser les dernières fonctionnalités et options du noyau. Le correctif pour 2117780 a introduit un nouveau thread par CPU kthread, ktimers. Ce thread doit être épinglé aux cœurs de l'unité centrale appropriés. Avec cette mise à jour, il n'y a pas de changement fonctionnel ; l'isolation de la charge de travail est la même. Pour plus d'informations, voir 2102450.

Dans OpenShift Container Platform 4.12, en activant les C-states et les P-states contrôlés par le système d'exploitation, vous pouvez utiliser différentes configurations d'économie d'énergie pour les charges de travail critiques et non critiques. Vous pouvez appliquer les configurations via le nouvel indice de charge de travail perPodPowerManagement et les annotations CRI-O cpu-c-states.crio.io et cpu-freq-governor.crio.io. Pour plus d'informations sur cette fonctionnalité, voir Configurations d'économie d'énergie.

Dans OpenShift Container Platform 4.11, une fonctionnalité permettant d'ajouter manuellement des nœuds de travail aux clusters OpenShift à nœud unique a été introduite. Cette fonctionnalité est désormais également disponible dans GitOps ZTP.

Pour plus d'informations, voir Ajouter des nœuds de travail à des clusters OpenShift à nœud unique avec GitOps ZTP.

Dans OpenShift Container Platform 4.12, vous pouvez utiliser l'outil factory-precaching-cli pour pré-cacher les images OpenShift Container Platform et Operator sur un serveur à l'usine, puis vous pouvez inclure le serveur pré-caché sur le site pour le déploiement. Pour plus d'informations sur l'outil factory-precaching-cli, voir Pre-caching images for single-node OpenShift deployments.

Dans OpenShift Container Platform 4.12, vous pouvez utiliser l'outil factory-precaching-cli dans le flux de travail GitOps ZTP. Pour plus d'informations, voir Pre-caching images for single-node OpenShift deployments.

Vous pouvez désormais configurer le réglage au niveau du système d'exploitation pour les nœuds d'un cluster hébergé à l'aide de l'opérateur de réglage des nœuds. Pour configurer l'optimisation des nœuds, vous pouvez créer des cartes de configuration dans le cluster de gestion qui contiennent des objets Tuned, et référencer ces cartes de configuration dans vos pools de nœuds. La configuration de l'optimisation définie dans les objets Tuned est appliquée aux nœuds du pool de nœuds. Pour plus d'informations, voir Configuration de l'optimisation des nœuds dans un cluster hébergé.

L'opérateur de gestion des modules du noyau (KMM) remplace l'opérateur de ressources spéciales (SRO). KMM comprend les fonctionnalités suivantes pour les environnements connectés uniquement :

Pour les déploiements en étoile dans un environnement qui peut accéder à l'internet, vous pouvez utiliser l'opérateur de gestion des modules du noyau (KMM) déployé dans le cluster de l'étoile pour gérer le déploiement des modules du noyau requis vers un ou plusieurs clusters gérés.

Topology Aware Lifecycle Manager (TALM) fournit désormais des informations d'état et des messages plus détaillés, ainsi que des conditions redéfinies. Vous pouvez utiliser le champ ClusterLabelSelector pour une plus grande flexibilité dans la sélection des clusters à mettre à jour. Vous pouvez utiliser des paramètres de délai pour déterminer ce qui se passe si une mise à jour échoue pour un cluster, par exemple, ignorer le cluster défaillant et continuer à mettre à niveau d'autres clusters, ou arrêter la remédiation de la politique pour tous les clusters. Pour plus d'informations, voir Topology Aware Lifecycle Manager pour les mises à jour de clusters.

L'encapsulation est le processus de déplacement de tous les points de montage spécifiques à Kubernetes vers un espace de noms alternatif afin de réduire la visibilité et l'impact sur les performances d'un grand nombre de points de montage dans l'espace de noms par défaut. Auparavant, l'encapsulation de l'espace de noms de montage a été déployée de manière transparente dans OpenShift Container Platform, spécifiquement pour les unités distribuées (DU) installées à l'aide de GitOps ZTP. Dans OpenShift Container Platform v4.12, cette fonctionnalité est désormais disponible en tant qu'option configurable.

Un système d'exploitation hôte standard utilise systemd pour analyser en permanence tous les espaces de noms de montage : à la fois les montages Linux standard et les nombreux montages que Kubernetes utilise pour fonctionner. L'implémentation actuelle de Kubelet et de CRI-O utilise l'espace de noms de premier niveau pour tous les points de montage des conteneurs et de Kubelet. L'encapsulation de ces points de montage spécifiques aux conteneurs dans un espace de noms privé réduit la charge de travail de systemd et améliore les performances de l'unité centrale. L'encapsulation peut également améliorer la sécurité, en stockant les points de montage spécifiques à Kubernetes dans un emplacement à l'abri de l'inspection par des utilisateurs non privilégiés.

Pour plus d'informations, voir Optimiser l'utilisation de l'unité centrale avec l'encapsulation de l'espace de noms de montage.

Vous pouvez configurer l'ensemble de CPU de partitionnement de la charge de travail dans les clusters OpenShift à nœud unique que vous déployez avec GitOps ZTP. Pour ce faire, vous spécifiez les ressources CPU de gestion de cluster avec le champ cpuset de la ressource personnalisée (CR) SiteConfig et le champ reserved de la CR de groupe PolicyGenTemplate. La valeur que vous définissez pour cpuset doit correspondre à la valeur définie dans le champ cluster PerformanceProfile CR .spec.cpu.reserved pour le partitionnement de la charge de travail.

Pour plus d'informations, voir Partitionnement de la charge de travail.

Les fonctions de modèle de hub sont maintenant disponibles pour une utilisation avec GitOps ZTP en utilisant Red Hat Advanced Cluster Management (RHACM) et Topology Aware Lifecycle Manager (TALM). Les modèles de cluster côté hub réduisent le besoin de créer des politiques séparées pour de nombreux clusters avec des configurations similaires mais avec des valeurs différentes. Pour plus d'informations, voir Utilisation de modèles de concentrateur dans les CR PolicyGenTemplate.

Le RHACM utilise les CR SiteConfig pour générer les CR d'installation de cluster géré du jour 1 pour ArgoCD. Chaque application ArgoCD peut gérer un maximum de 300 CR SiteConfig. Pour plus d'informations, voir Configuration du cluster hub avec ArgoCD.

Dans GitOps ZTP v4.11 , une valeur par défaut de délai d'évaluation de la conformité aux politiques est disponible pour une utilisation dans PolicyGenTemplate custom resources (CRs). Cette valeur indique la durée pendant laquelle la CR ConfigurationPolicy concernée peut se trouver dans un état de conformité ou de non-conformité aux politiques avant que RHACM ne réévalue les politiques de cluster appliquées.

En option, vous pouvez désormais remplacer les intervalles d'évaluation par défaut pour toutes les politiques dans les CR PolicyGenTemplate.

Pour plus d'informations, voir Configuration des délais d'évaluation de la conformité des politiques pour les CR PolicyGenTemplate.

L'installateur assisté prend actuellement en charge les plateformes OpenShift Container Platform suivantes :

OpenShift à nœud unique ne prend pas en charge VSphere.

Cette version prend en charge l'utilisation de registres non authentifiés lors de la configuration du cluster hub. Les registres qui ne nécessitent pas d'authentification sont répertoriés sous spec.unauthenticatedRegistries dans la ressource AgentServiceConfig. Tout registre figurant sur cette liste n'est pas tenu d'avoir une entrée dans le secret d'extraction utilisé pour l'installation du cluster de rayons. assisted-service valide le secret d'extraction en s'assurant qu'il contient les informations d'authentification pour chaque registre d'image utilisé pour l'installation.

Pour plus d'informations, voir Configurer le cluster hub pour utiliser des registres non authentifiés.

Pour les installations déconnectées utilisant GitOps ZTP, si vous déployez OpenShift Container Platform version 4.11 ou antérieure sur un cluster spoke avec converged flow activé, vous devez mettre en miroir l'image de l'agent Ironic par défaut dans le référentiel d'images local. Les images par défaut de l'agent Ironic sont les suivantes :

Pour plus d'informations sur la mise en miroir des images, voir Mise en miroir du référentiel d'images OpenShift Container Platform.

OpenShift Container Platform prend désormais en charge la spécification d'arguments de noyau pour l'ISO de découverte dans les déploiements GitOps ZTP. Dans les déploiements GitOps ZTP manuels et automatisés, l'ISO de découverte fait partie du processus d'installation d'OpenShift Container Platform sur les hôtes bare-metal gérés. Vous pouvez maintenant éditer la ressource InfraEnv pour spécifier les arguments du noyau pour l'ISO de découverte. Ceci est utile pour les installations de clusters avec des exigences environnementales spécifiques. Par exemple, vous pouvez définir l'argument de noyau rd.net.timeout.carrier pour aider à configurer le cluster pour un réseau statique.

Pour plus d'informations sur la manière de spécifier les arguments du noyau, voir Configuration des arguments du noyau pour l'ISO de découverte à l'aide de GitOps ZTP et Configuration des arguments du noyau pour l'ISO de découverte pour les installations manuelles à l'aide de GitOps ZTP.

Avec cette mise à jour, vous pouvez créer des clusters à architecture mixte d'OpenShift Container Platform, également connus sous le nom de clusters hétérogènes, qui comprennent des hôtes avec des architectures de CPU AMD64 et AArch64. Vous pouvez déployer un cluster hétérogène à partir d'un cluster hub géré par Red Hat Advanced Cluster Management (RHACM). Pour créer un cluster hétérogène, ajoutez un nœud de travail AArch64 à un cluster AMD64 déployé.

Pour ajouter un nœud de travail AArch64 à un cluster AMD64 déployé, vous pouvez spécifier l'architecture AArch64, l'image de version multi-architecture et le système d'exploitation requis pour le nœud à l'aide d'une ressource personnalisée (CR) InfraEnv. Vous pouvez ensuite intégrer le nœud de travailleur AArch64 au cluster AMD64 à l'aide de l'API Assisted Installer et de la CR InfraEnv.

Dans OpenShift Container Platform 4.12, les recommandations actives d'Insights sont désormais présentées à l'utilisateur sous forme d'alertes. Vous pouvez visualiser et configurer ces alertes avec Alertmanager.

Dans OpenShift Container Platform 4.12, l'opérateur Insights collecte désormais les métriques suivantes :

Vous pouvez désormais spécifier des identifiants d'application dans les fichiers clouds.yaml des clusters qui s'exécutent sur Red Hat OpenStack Platform (RHOSP). Les informations d'identification de l'application sont une alternative à l'intégration des détails du compte d'utilisateur dans les fichiers de configuration. À titre d'exemple, voir la section suivante d'un fichier clouds.yaml qui inclut des détails de compte d'utilisateur :

clouds:
    openstack:
        auth:
            auth_url: https://127.0.0.1:13000
            password: thepassword
            project_domain_name: Default
            project_name: theprojectname
            user_domain_name: Default
            username: theusername
        region_name: regionOne

Comparez cette section à une autre qui utilise les informations d'identification de l'application :

clouds:
    openstack:
        auth:
            auth_url: https://127.0.0.1:13000
            application_credential_id: '5dc185489adc4b0f854532e1af81ffe0'
            application_credential_secret: 'PDCTKans2bPBbaEqBLiT_IajG8e5J_nJB4kvQHjaAy6ufhod0Zl0NkNoBzjn_bWSYzk587ieIGSlT11c4pVehA'
        auth_type: "v3applicationcredential"
        region_name: regionOne

Pour utiliser les identifiants d'application avec votre cluster en tant qu'administrateur RHOSP, créez les identifiants. Utilisez-les ensuite dans un fichier clouds.yaml lors de l'installation d'un cluster. Vous pouvez également créer le fichier clouds.yaml et le faire pivoter dans un cluster existant.

La version par défaut de l'API hypershift.openshift.io, qui est l'API pour les plans de contrôle hébergés sur OpenShift Container Platform, est maintenant v1beta1. Actuellement, pour un cluster existant, le passage de la version alpha à la version bêta n'est pas pris en charge.

Avec chaque version majeure, mineure ou corrective d'OpenShift Container Platform, l'HyperShift Operator est publié. L'interface de ligne de commande (CLI) HyperShift est publiée dans le cadre de chaque version de l'opérateur HyperShift.

Les ressources des API HostedCluster et NodePool sont disponibles dans la version bêta de l'API et suivent une politique similaire à celle d'OpenShift Container Platform et de Kubernetes.

Si vous utilisez des plans de contrôle hébergés sur OpenShift Container Platform, vous pouvez sauvegarder et restaurer etcd en prenant un instantané d'etcd et en le téléchargeant vers un emplacement où vous pourrez le récupérer plus tard, tel qu'un seau S3. Plus tard, si nécessaire, vous pouvez restaurer l'instantané. Pour plus d'informations, voir Sauvegarde et restauration d'etcd sur un cluster hébergé.

Si vous avez besoin d'une reprise après sinistre pour un cluster hébergé, vous pouvez récupérer le cluster hébergé dans la même région au sein d'AWS. Pour plus d'informations, voir Reprise après sinistre d'un cluster hébergé dans une région AWS.