Rechercher
SupportConsoleDéveloppeursCommencer un essaiContact

1.6. Bug fixes

download PDF
Serveur API et authentification
  • Auparavant, l'état de l'opérateur d'authentification de cluster était défini sur progressing = false après avoir reçu une erreur workloadIsBeingUpdatedTooLong. Dans le même temps, degraded = false était conservé pendant la durée de l'erreur inertia. Par conséquent, la réduction du temps de progression et l'augmentation du temps de dégradation créaient une situation où progressing = false et degraded = false étaient définis prématurément. Cela provoquait des tests OpenShift CI incohérents car un état sain était supposé, ce qui était incorrect. Ce problème a été corrigé en supprimant le paramètre progressing = false après le retour de l'erreur workloadIsBeingUpdatedTooLong. Maintenant, parce qu'il n'y a pas d'état progressing = false, les tests OpenShift CI sont plus cohérents. (BZ#2111842)
Provisionnement du matériel Bare Metal
  • Dans les versions récentes du firmware du serveur, le temps entre les opérations du serveur a augmenté. Cela entraîne des dépassements de délais lors des installations d'infrastructures provisionnées par l'installateur, lorsque le programme d'installation d'OpenShift Container Platform attend une réponse du contrôleur de gestion de la carte mère (BMC). La nouvelle version python3-sushy augmente le nombre de tentatives côté serveur pour contacter le BMC. Cette mise à jour prend en compte le temps d'attente prolongé et évite les dépassements de délai pendant l'installation. (OCPBUGS-4097)
  • Avant cette mise à jour, le service de provisionnement d'Ironic ne prenait pas en charge les contrôleurs de gestion de cartes de base (BMC) qui utilisent des eTags faibles combinés à une validation stricte des eTags. Par conception, si le BMC fournit un eTag faible, Ironic renvoie deux eTags : l'eTag original et l'eTag original converti au format fort pour la compatibilité avec les BMC qui ne supportent pas les eTags faibles. Bien qu'Ironic puisse envoyer deux eTags, la BMC qui utilise une validation stricte des eTags rejette ces demandes en raison de la présence du second eTag. Par conséquent, sur certains serveurs plus anciens, le provisionnement bare-metal a échoué avec l'erreur suivante : HTTP 412 Precondition Failed. Dans OpenShift Container Platform 4.12 et plus, ce comportement change et Ironic ne tente plus d'envoyer deux eTags dans les cas où un eTag faible est fourni. Au lieu de cela, si une requête Redfish dépendant d'un eTag échoue avec une erreur de validation d'eTag, Ironic réessaie la requête avec des solutions de contournement connues. Cela minimise le risque d'échec du provisionnement bare-metal sur les machines avec une validation stricte de l'eTag. (OCPBUGS-3479)
  • Avant cette mise à jour, lorsqu'un système Redfish comportait un URI de paramétrage, le service de provisionnement Ironic tentait toujours d'utiliser cet URI pour apporter des modifications aux paramètres du BIOS liés au démarrage. Cependant, le provisionnement bare-metal échoue si le contrôleur de gestion de la carte de base (BMC) présente un URI de paramètres mais ne prend pas en charge la modification d'un paramètre particulier du BIOS en utilisant cet URI de paramètres. Dans OpenShift Container Platform 4.12 et plus, si un système dispose d'un Settings URI, Ironic vérifie qu'il peut modifier un paramètre particulier du BIOS en utilisant le Settings URI avant de procéder. Dans le cas contraire, Ironic met en œuvre le changement en utilisant l'URI System. Cette logique supplémentaire garantit qu'Ironic peut appliquer les changements de paramètres du BIOS liés à l'amorçage et que l'approvisionnement en métal nu peut réussir. (OCPBUGS-2052)
Constructions

  • Par défaut, Buildah imprime les étapes dans le fichier journal, y compris le contenu des variables d'environnement, qui peuvent inclure des secrets d'entrée de compilation. Bien que vous puissiez utiliser l'argument --quiet build pour supprimer l'impression de ces variables d'environnement, cet argument n'est pas disponible si vous utilisez la stratégie de compilation source-image (S2I). La version actuelle corrige ce problème. Pour supprimer l'impression des variables d'environnement, définissez la variable d'environnement BUILDAH_QUIET dans votre configuration de compilation : 

    sourceStrategy:
...
  env:
    - name: "BUILDAH_QUIET"
      value: "true"

    (BZ#2099991)

Informatique en nuage
  • Auparavant, les instances n'étaient pas configurées pour respecter l'option par défaut de l'infrastructure GCP pour les redémarrages automatiques. Par conséquent, des instances pouvaient être créées sans utiliser l'option par défaut de l'infrastructure pour les redémarrages automatiques. Cela signifiait parfois que les instances étaient terminées dans GCP mais que leurs machines associées étaient toujours listées dans l'état Running parce qu'elles n'avaient pas redémarré automatiquement. Avec cette version, le code de transmission de l'option de redémarrage automatique a été amélioré pour mieux détecter et transmettre la sélection de l'option par défaut par les utilisateurs. Les instances utilisent désormais correctement l'infrastructure par défaut et sont automatiquement redémarrées lorsque l'utilisateur demande la fonctionnalité par défaut. (OCPBUGS-4504)
  • La version v1beta1 de l'objet PodDisruptionBudget est désormais obsolète dans Kubernetes. Avec cette version, les références internes à v1beta1 sont remplacées par v1. Ce changement est interne à l'autoscaler du cluster et ne nécessite pas d'action de la part de l'utilisateur au-delà des conseils donnés dans l'article de la base de connaissances Red Hat Preparing to upgrade to OpenShift Container Platform 4.12. (OCPBUGS-1484)
  • Auparavant, le contrôleur de machines GCP rapprochait l'état des machines toutes les 10 heures. D'autres fournisseurs fixent cette valeur à 10 minutes afin que les changements qui se produisent en dehors du système Machine API soient détectés dans un court laps de temps. La période de réconciliation plus longue pour GCP pouvait causer des problèmes inattendus tels que des approbations de demandes de signature de certificat (CSR) manquantes en raison d'une adresse IP externe ajoutée mais non détectée pendant une période prolongée. Avec cette version, le contrôleur de machine GCP est mis à jour pour effectuer une réconciliation toutes les 10 minutes afin d'être cohérent avec les autres plateformes et pour que les changements externes soient détectés plus tôt. (OCPBUGS-4499)
  • Auparavant, en raison d'une mauvaise configuration du déploiement de l'opérateur d'approbation des machines en grappe, l'activation de l'ensemble de fonctionnalités TechPreviewNoUpgrade provoquait des erreurs et une dégradation sporadique de l'opérateur. Comme les clusters avec le jeu de fonctionnalités TechPreviewNoUpgrade activé utilisent deux instances de Cluster Machine Approver Operator et que les deux déploiements utilisent le même jeu de ports, il y avait un conflit qui entraînait des erreurs pour la topologie à nœud unique. Avec cette version, le déploiement de Cluster Machine Approver Operator est mis à jour pour utiliser un ensemble de ports différent pour les différents déploiements. (OCPBUGS-2621)
  • Auparavant, la fonctionnalité de mise à l'échelle à partir de zéro dans Azure reposait sur une liste de types d'instance compilée de manière statique, associant le nom du type d'instance au nombre de CPU et à la quantité de mémoire allouée au type d'instance. Cette liste est devenue obsolète au fil du temps. Avec cette version, les informations sur les tailles des types d'instance sont collectées dynamiquement à partir de l'API Azure directement pour éviter que la liste ne devienne obsolète. (OCPBUGS-2558)
  • Auparavant, les pods du gestionnaire de terminaison de l'API Machine ne démarraient pas sur les instances ponctuelles. Par conséquent, les pods qui s'exécutaient sur des instances ponctuelles entachées ne recevaient pas de signal de terminaison si l'instance était terminée. Cela pouvait entraîner une perte de données dans les applications de charge de travail. Avec cette version, le déploiement du gestionnaire de terminaison de l'API Machine est modifié pour tolérer les taints et les pods s'exécutant sur des instances ponctuelles avec des taints reçoivent maintenant des signaux de terminaison. (OCPBUGS-1274)
  • Auparavant, les messages d'erreur pour les clusters Azure n'expliquaient pas qu'il n'était pas possible de créer de nouvelles machines avec des adresses IP publiques pour une installation déconnectée qui utilise uniquement la stratégie de publication interne. Avec cette version, le message d'erreur est mis à jour pour plus de clarté. (OCPBUGS-519)
  • Auparavant, l'opérateur du gestionnaire de contrôleur cloud ne vérifiait pas le fichier de configuration cloud-config pour les clusters AWS. Par conséquent, il n'était pas possible de transmettre des paramètres supplémentaires au composant AWS cloud controller manager en utilisant le fichier de configuration. Avec cette version, le Cloud Controller Manager Operator vérifie la ressource d'infrastructure et analyse les références au fichier de configuration cloud-config afin que les utilisateurs puissent configurer des paramètres supplémentaires. (BZ#2104373)
  • Auparavant, lorsqu'Azure ajoutait de nouveaux types d'instance et activait la prise en charge de la mise en réseau accélérée sur des types d'instance qui n'en disposaient pas auparavant, la liste des instances Azure dans le contrôleur de machine devenait obsolète. Par conséquent, le contrôleur de machine ne pouvait pas créer de machines avec des types d'instance qui ne prenaient pas auparavant en charge la mise en réseau accélérée, même s'ils prenaient en charge cette fonctionnalité sur Azure. Avec cette version, les informations requises sur le type d'instance sont récupérées à partir de l'API Azure avant la création de la machine afin de les maintenir à jour pour que le contrôleur de machine puisse créer des machines avec des types d'instance nouveaux et mis à jour. Cette correction s'applique également à tous les types d'instance qui seront ajoutés à l'avenir. (BZ#2108647)
  • Auparavant, l'autoscaler de cluster ne respectait pas les étiquettes de topologie AWS, IBM Cloud et Alibaba Cloud pour les pilotes CSI lors de l'utilisation du fournisseur Cluster API. Par conséquent, les nœuds avec l'étiquette de topologie n'étaient pas traités correctement par l'autoscaler lorsqu'il tentait d'équilibrer les nœuds au cours d'un événement de mise à l'échelle. Avec cette version, les processeurs personnalisés de l'autoscaler sont mis à jour afin de respecter ce label. L'autoscaler peut désormais équilibrer des groupes de nœuds similaires portant les étiquettes AWS, IBM Cloud ou Alibaba CSI. (BZ#2001027)
  • Auparavant, les fournisseurs de cloud Power VS n'étaient pas en mesure de récupérer l'adresse IP de la machine à partir d'un serveur DHCP. La modification de l'adresse IP ne mettait pas à jour le nœud, ce qui entraînait certaines incohérences, telles que des demandes de signature de certificat en attente. Avec cette version, le fournisseur de cloud Power VS est mis à jour pour récupérer l'adresse IP de la machine à partir du serveur DHCP, de sorte que les adresses IP des nœuds sont cohérentes avec l'adresse IP de la machine. (BZ#2111474)
  • Auparavant, les machines créées dans les premières versions d'OpenShift Container Platform avec des configurations invalides ne pouvaient pas être supprimées. Avec cette version, les webhooks qui empêchent la création de machines avec des configurations invalides n'empêchent plus la suppression des machines invalides existantes. Les utilisateurs peuvent désormais supprimer ces machines de leur cluster en supprimant manuellement les finaliseurs sur ces machines. (BZ#2101736)
  • Auparavant, des baux DHCP de courte durée, causés par le fait que NetworkManager n'était pas exécuté en tant que démon ou en mode continu, entraînaient le blocage des machines lors du provisionnement initial et leur incapacité à devenir des nœuds dans le cluster. Avec cette version, des vérifications supplémentaires ont été ajoutées afin que si une machine reste bloquée dans cet état, elle soit supprimée et recréée automatiquement. Les machines affectées par cette condition de réseau peuvent devenir des nœuds après un redémarrage à partir du contrôleur Machine API. (BZ#2115090)
  • Auparavant, lors de la création d'une nouvelle ressource Machine à l'aide d'un profil de machine qui n'existe pas dans IBM Cloud, les machines restaient bloquées dans la phase Provisioning. Avec cette version, la validation est ajoutée au fournisseur IBM Cloud Machine API pour s'assurer qu'un profil de machine existe, et les machines avec un profil de machine invalide sont rejetées par l'API Machine. (BZ#2062579)
  • Auparavant, le fournisseur Machine API pour AWS ne vérifiait pas que le groupe de sécurité défini dans la spécification de la machine existait. Au lieu de renvoyer une erreur dans ce cas, il utilisait un groupe de sécurité par défaut, qui ne devrait pas être utilisé pour les machines OpenShift Container Platform, et créait avec succès une machine sans informer l'utilisateur que le groupe par défaut était utilisé. Avec cette version, l'API Machine renvoie une erreur lorsque les utilisateurs définissent des noms de groupes de sécurité incorrects ou vides dans la spécification de la machine. (BZ#2060068)
  • Auparavant, le fournisseur de l'API Machine Azure ne traitait pas les valeurs fournies par l'utilisateur pour les types d'instance comme sensibles à la casse. Cela entraînait des erreurs fausses positives lorsque les types d'instance étaient corrects mais ne correspondaient pas à la casse. Avec cette version, les types d'instance sont convertis en caractères minuscules afin que les utilisateurs obtiennent des résultats corrects sans erreurs faussement positives dues à une mauvaise correspondance des majuscules et des minuscules. (BZ#2085390)
  • Auparavant, il n'y avait pas de vérification des valeurs nulles dans les annotations d'un objet machine avant de tenter d'accéder à l'objet. Cette situation était rare, mais provoquait la panique du contrôleur de machine lors de la réconciliation de la machine. Avec cette version, les valeurs nulles sont vérifiées et le contrôleur de machine est en mesure de réconcilier les machines sans annotations. (BZ#2106733)
  • Auparavant, les mesures de l'autoscaler de cluster pour l'utilisation du CPU et de la mémoire du cluster n'atteignaient jamais, ou ne dépassaient jamais, les limites définies par la ressource ClusterAutoscaler. Par conséquent, aucune alerte n'était déclenchée lorsque l'autoscaler de cluster ne pouvait pas évoluer en raison des limitations de ressources. Avec cette version, une nouvelle métrique appelée cluster_autoscaler_skipped_scale_events_count est ajoutée à l'autoscaler de cluster pour détecter plus précisément lorsque les limites de ressources sont atteintes ou dépassées. Les alertes sont désormais déclenchées lorsque l'autoscaler de cluster n'est pas en mesure d'augmenter la taille du cluster parce qu'il a atteint les limites de ressources du cluster. (BZ#1997396)
  • Auparavant, lorsque le fournisseur de l'API Machine ne parvenait pas à récupérer l'adresse IP de la machine, il ne définissait pas le nom DNS interne et les demandes de signature de certificat de la machine n'étaient pas automatiquement approuvées. Avec cette version, le fournisseur de machines Power VS est mis à jour pour définir le nom du serveur comme nom DNS interne même s'il ne parvient pas à récupérer l'adresse IP. (BZ#2111467)
  • Auparavant, le contrôleur de machine vSphere Machine API définissait l'indicateur PowerOn lors du clonage d'une VM. Cela créait une tâche PowerOn dont le contrôleur de machine n'avait pas connaissance. Si cette tâche PowerOn échouait, les machines étaient bloquées dans la phase Provisioned mais n'étaient jamais mises sous tension. Avec cette version, la séquence de clonage est modifiée pour éviter ce problème. En outre, le contrôleur de machine tente à nouveau de mettre sous tension la VM en cas d'échec et signale correctement les échecs. (BZ#2087981, OCPBUGS-954)
  • Avec cette version, les groupes de sécurité AWS sont marqués immédiatement au lieu d'être marqués après leur création. Cela signifie que moins de demandes sont envoyées à AWS et que les privilèges d'utilisateur requis sont réduits. (BZ#2098054, OCPBUGS-3094)
  • Auparavant, un bogue dans le fournisseur de cloud hérité RHOSP entraînait un plantage si certaines opérations RHOSP étaient tentées après l'échec de l'authentification. Par exemple, l'arrêt d'un serveur entraîne le gestionnaire de contrôleur Kubernetes à récupérer des informations sur le serveur auprès de RHOSP, ce qui a déclenché ce bogue. Par conséquent, si l'authentification initiale dans le nuage a échoué ou a été configurée de manière incorrecte, l'arrêt d'un serveur a provoqué un plantage du gestionnaire de contrôleur Kubernetes. Avec cette version, le fournisseur de cloud hérité de RHOSP est mis à jour pour ne pas tenter d'appeler l'API RHOSP s'il ne s'est pas authentifié avec succès auparavant. Désormais, l'arrêt d'un serveur dont les informations d'identification ne sont pas valides n'entraîne plus le plantage du gestionnaire de contrôleur Kubernetes. (BZ#2102383)
Console du développeur
  • Auparavant, l'espace de noms openshift-config était codé en dur pour la ressource personnalisée HelmChartRepository, qui était le même espace de noms pour la ressource personnalisée ProjectHelmChartRepository. Cela empêchait les utilisateurs d'ajouter des ressources personnalisées privées ProjectHelmChartRepository dans l'espace de noms de leur choix. Par conséquent, les utilisateurs ne pouvaient pas accéder aux secrets et aux cartes de configuration dans l'espace de noms openshift-config. Cette mise à jour corrige la définition de la ressource personnalisée ProjectHelmChartRepository avec un champ namespace qui peut lire le secret et les cartes de configuration d'un espace de noms choisi par un utilisateur disposant des autorisations correctes. En outre, l'utilisateur peut ajouter des secrets et des cartes de configuration à l'espace de noms accessible, et il peut ajouter des dépôts de cartes Helm privés dans l'espace de noms utilisé pour les ressources de création. (BZ#2071792)
Registre des images
  • Auparavant, le contrôleur du déclencheur d'images n'avait pas le droit de modifier les objets. Par conséquent, les annotations de déclenchement d'images ne fonctionnaient pas sur certaines ressources. Cette mise à jour crée une liaison de rôle de cluster qui fournit au contrôleur les autorisations nécessaires pour mettre à jour les objets en fonction des annotations. (BZ#2055620)
  • Auparavant, l'opérateur du registre des images n'avait pas de condition progressing pour l'ensemble de démons node-ca et utilisait generation à partir d'un objet incorrect. Par conséquent, le jeu de démons node-ca pouvait être marqué comme degraded alors que l'opérateur était toujours en cours d'exécution. Cette mise à jour ajoute la condition progressing, qui indique que l'installation n'est pas terminée. Par conséquent, l'opérateur de registre d'images installe avec succès le jeu de démons node-ca et le programme d'installation attend qu'il soit entièrement déployé. ([BZ#2093440)
Installateur
  • Auparavant, le nombre de tags définis par l'utilisateur pris en charge était de 8, et les tags OpenShift Container Platform réservés étaient de 2 pour les ressources AWS. Avec cette version, le nombre de balises définies par l'utilisateur prises en charge est désormais de 25 et les balises OpenShift Container Platform réservées sont de 25 pour les ressources AWS. Vous pouvez désormais ajouter jusqu'à 25 balises utilisateur lors de l'installation. (CFE#592)
  • Auparavant, l'installation d'un cluster sur Amazon Web Services démarrait puis échouait lorsque l'utilisateur administratif IAM ne disposait pas de l'autorisation s3:GetBucketPolicy. Cette mise à jour ajoute cette stratégie à la liste de contrôle que le programme d'installation utilise pour s'assurer que toutes les autorisations requises sont attribuées. Par conséquent, le programme d'installation arrête désormais l'installation en affichant un avertissement indiquant que l'utilisateur administratif IAM ne dispose pas de l'autorisation s3:GetBucketPolicy. (BZ#2109388)
  • Auparavant, l'installation d'un cluster sur Microsoft Azure échouait lorsque les séries Azure DCasv5 ou DCadsv5 de VM confidentielles étaient spécifiées comme nœuds du plan de contrôle. Avec cette mise à jour, le programme d'installation arrête maintenant l'installation avec une erreur, qui indique que les VM confidentielles ne sont pas encore prises en charge. (BZ#2055247)
  • Auparavant, la collecte des journaux de démarrage n'était pas possible tant que les machines du plan de contrôle ne fonctionnaient pas. Avec cette mise à jour, la collecte des journaux de démarrage ne nécessite plus que la disponibilité de la machine de démarrage. (BZ#2105341)
  • Auparavant, si l'installation d'un cluster sur Google Cloud Platform échouait parce que le compte de service ne disposait pas d'autorisations suffisantes, le message d'erreur qui en résultait ne mentionnait pas cet élément comme cause de l'échec. Cette mise à jour améliore le message d'erreur, qui indique désormais aux utilisateurs de vérifier les autorisations attribuées au compte de service. (BZ#2103236)
  • Auparavant, lorsqu'une installation sur Google Cloud provider (GCP) échouait parce qu'une région GCP non valide était spécifiée, le message d'erreur qui en résultait ne mentionnait pas cet élément comme cause de l'échec. Cette mise à jour améliore le message d'erreur, qui indique désormais que la région n'est pas valide. (BZ#2102324)
  • Auparavant, les installations de clusters utilisant Hive pouvaient échouer si Hive utilisait une ancienne version du fichier install-config.yaml. Cette mise à jour permet au programme d'installation d'accepter les anciennes versions du fichier install-config.yaml fourni par Hive. (BZ#2098299)
  • Auparavant, le programme d'installation autorisait à tort les paramètres apiVIP et ingressVIP à utiliser la même adresse IPv6 s'ils représentaient l'adresse différemment, par exemple en la listant dans un format abrégé. Dans cette mise à jour, le programme d'installation valide correctement ces deux paramètres indépendamment de leur formatage, en exigeant des adresses IP distinctes pour chaque paramètre. (BZ#2103144)
  • Auparavant, la désinstallation d'un cluster à l'aide du programme d'installation ne supprimait pas toutes les ressources des clusters installés sur GCP si le nom du cluster comportait plus de 22 caractères. Dans cette mise à jour, la désinstallation d'un cluster à l'aide du programme d'installation localise et supprime correctement toutes les ressources des clusters GCP lorsque les noms des clusters sont longs. (BZ#2076646)
  • Auparavant, lors de l'installation d'un cluster sur Red Hat OpenStack Platform (RHOSP) avec plusieurs réseaux définis dans le paramètre machineNetwork, le programme d'installation ne créait des règles de groupe de sécurité que pour le premier réseau. Avec cette mise à jour, le programme d'installation crée des règles de groupe de sécurité pour tous les réseaux définis dans le paramètre machineNetwork afin que les utilisateurs n'aient plus à modifier manuellement les règles de groupe de sécurité après l'installation. (BZ#2095323)
  • Auparavant, les utilisateurs pouvaient définir manuellement les adresses IP virtuelles API et Ingress à des valeurs qui entraient en conflit avec le pool d'allocation du serveur DHCP lors de l'installation d'un cluster sur OpenStack. Cela pouvait amener le serveur DHCP à attribuer l'une des adresses VIP à une nouvelle machine, qui ne démarrait pas. Dans cette mise à jour, le programme d'installation valide les adresses VIP fournies par l'utilisateur pour s'assurer qu'elles n'entrent pas en conflit avec les pools DHCP. (BZ#1944365)
  • Auparavant, lors de l'installation d'un cluster sur vSphere à l'aide d'un centre de données intégré dans un dossier, le programme d'installation ne pouvait pas localiser l'objet centre de données, ce qui entraînait l'échec de l'installation. Dans cette mise à jour, le programme d'installation peut traverser le répertoire qui contient l'objet centre de données, ce qui permet à l'installation de réussir. (BZ#2097691)
  • Auparavant, lors de l'installation d'un cluster sur Azure utilisant l'architecture arm64 avec une infrastructure fournie par l'installateur, la ressource de définition d'image pour hyperVGeneration V1 avait une valeur d'architecture incorrecte de x64. Avec cette mise à jour, la ressource de définition d'image pour hyperVGeneration V1 a la valeur d'architecture correcte de Arm64. (OCPBUGS-3639)
  • Auparavant, lors de l'installation d'un cluster sur VMware vSphere, l'installation pouvait échouer si l'utilisateur spécifiait un dossier défini par l'utilisateur dans la section failureDomain du fichier install-config.yaml. Avec cette mise à jour, le programme d'installation valide correctement les dossiers définis par l'utilisateur dans la section failureDomain du fichier install-config.yaml. (OCPBUGS-3343)
  • Auparavant, lors de la destruction d'un cluster partiellement déployé après l'échec d'une installation sur VMware vSphere, certains dossiers de machines virtuelles n'étaient pas détruits. Cette erreur pouvait se produire dans les clusters configurés avec plusieurs centres de données vSphere ou plusieurs clusters vSphere. Avec cette mise à jour, toute l'infrastructure fournie par l'installateur est correctement supprimée lors de la destruction d'un cluster partiellement déployé après un échec de l'installation. (OCPBUGS-1489)
  • Auparavant, lors de l'installation d'un cluster sur VMware vSphere, l'installation échouait si l'utilisateur spécifiait le paramètre platform.vsphere.vcenters sans spécifier le paramètre platform.vsphere.failureDomains.topology.networks dans le fichier install-config.yaml. Avec cette mise à jour, le programme d'installation avertit l'utilisateur que le champ platform.vsphere.failureDomains.topology.networks est requis lorsqu'il spécifie platform.vsphere.vcenters. (OCPBUGS-1698)
  • Auparavant, lors de l'installation d'un cluster sur VMware vSphere, l'installation échouait si l'utilisateur définissait les paramètres platform.vsphere.vcenters et platform.vsphere.failureDomains mais ne définissait pas platform.vsphere.defaultMachinePlatform.zones, ou compute.platform.vsphere.zones et controlPlane.platform.vsphere.zones. Avec cette mise à jour, le programme d'installation valide que l'utilisateur a défini le paramètre zones dans les déploiements multi-régions ou multi-zones avant l'installation. (OCPBUGS-1490)
Gestionnaire de contrôleur Kubernetes
  • Auparavant, l'opérateur du gestionnaire de contrôleur Kubernetes signalait degraded sur les environnements sans la présence d'une pile de surveillance. Avec cette mise à jour, l'opérateur du gestionnaire du contrôleur Kubernetes ne vérifie pas la surveillance pour les indices de dégradation lorsque la pile de surveillance n'est pas présente. (BZ#2118286)
  • Avec cette mise à jour, les alertes de Kubernetes Controller Manager (KubeControllerManagerDown, PodDisruptionBudgetAtLimit, PodDisruptionBudgetLimit, et GarbageCollectorSyncFailed) ont des liens vers des runbooks Github. Les runbooks aident les utilisateurs à comprendre le débogage de ces alertes. (BZ#2001409)
Ordonnanceur Kubernetes
  • Auparavant, le déploiement du planificateur secondaire n'était pas supprimé après la suppression d'une ressource personnalisée du planificateur secondaire. Par conséquent, l'opérateur et l'opérande de planification secondaire n'étaient pas complètement désinstallés. Avec cette mise à jour, la référence propriétaire correcte est définie dans la ressource personnalisée du planificateur secondaire de sorte qu'elle pointe vers le déploiement du planificateur secondaire. Par conséquent, les déploiements du planificateur secondaire sont supprimés lorsque la ressource personnalisée du planificateur secondaire est supprimée. (BZ#2100923)
  • Pour la version 4.12 d'OpenShift Container Platform, le désarchiveur peut maintenant publier des événements à un groupe API parce que la version ajoute des règles supplémentaires de contrôle d'accès basé sur les rôles (RBAC) au profil du désarchiveur.(OCPBUGS-2330)
Machine Config Operator
  • Auparavant, la ressource ControllerConfig de l'opérateur de configuration de machine (MCO), qui contient des certificats importants, n'était synchronisée que si la synchronisation du démon de l'opérateur réussissait. Par conception, les nœuds non prêts pendant la synchronisation d'un démon empêchent la synchronisation de ce démon, de sorte que les nœuds non prêts empêchent indirectement la synchronisation de la ressource ControllerConfig, et donc de ces certificats. Il en résultait une dégradation éventuelle de la grappe en cas de nœuds non prêts en raison de l'impossibilité d'effectuer la rotation des certificats contenus dans la ressource ControllerConfig. Avec cette version, la synchronisation de la ressource ControllerConfig ne dépend plus de la réussite de la synchronisation du démon, de sorte que la ressource ControllerConfig continue à se synchroniser si la synchronisation du démon échoue. Cela signifie que les nœuds non prêts n'empêchent plus la ressource ControllerConfig de se synchroniser, de sorte que les certificats continuent d'être mis à jour même lorsqu'il y a des nœuds non prêts. (BZ#2034883)
Console de gestion
  • Auparavant, la page Operator details tentait d'afficher plusieurs messages d'erreur, mais le composant "message d'erreur" ne peut afficher qu'un seul message d'erreur à la fois. Par conséquent, les messages d'erreur pertinents n'étaient pas affichés. Avec cette mise à jour, la page Operator details n'affiche que le premier message d'erreur, de sorte que l'utilisateur voit une erreur pertinente. (OCPBUGS-3927)
  • Auparavant, le nom du produit pour Azure Red Hat OpenShift était incorrect dans la gestion des cas clients (CCM). Par conséquent, la console devait utiliser le même nom de produit incorrect pour remplir correctement les champs dans CCM. Une fois le nom du produit mis à jour dans CCM, la console a dû être mise à jour également. Avec cette mise à jour, le même nom de produit correct dans CCM est correctement rempli avec le nom de produit Azure correct lorsque l'on suit le lien depuis la console. (OCPBUGS-869)
  • Auparavant, lorsqu'une page de plugin entraînait une erreur, celle-ci n'était pas réinitialisée lorsque l'utilisateur s'éloignait de la page d'erreur, et l'erreur persistait lorsqu'il naviguait vers une page qui n'était pas à l'origine de l'erreur. Avec cette mise à jour, l'état de l'erreur est réinitialisé à sa valeur par défaut lorsqu'un utilisateur navigue vers une nouvelle page, et l'erreur ne persiste plus après avoir navigué vers une nouvelle page. (BZ#2117738, OCPBUGS-523)
  • Auparavant, le lien View it here dans le volet Operator details pour les opérateurs installés n'était pas correctement construit lorsque l'option All Namespaces était sélectionné. En conséquence, le lien tentait de naviguer vers la page Operator details pour une version de service de cluster (CSV) dans All Projects, ce qui est un itinéraire non valide. Avec cette mise à jour, le lien View it here pour utiliser l'espace de noms où le CSV est installé se construit maintenant correctement et le lien fonctionne comme prévu. (OCPBUGS-184)
  • Auparavant, les numéros de ligne de plus de cinq chiffres posaient un problème esthétique : le numéro de ligne recouvrait la ligne de séparation verticale entre le numéro de ligne et le contenu de la ligne, ce qui rendait la lecture plus difficile. Avec cette mise à jour, l'espace disponible pour les numéros de ligne a été augmenté pour tenir compte des numéros de ligne plus longs, et le numéro de ligne ne recouvre plus la ligne de séparation verticale. (OCPBUGS-183)
  • Auparavant, dans la perspective de l'administrateur de la console web, le lien vers Learn more about the OpenShift local update servicesDefault update server dans la fenêtre contextuelle de la page Cluster Settings produisait une erreur 404. Avec cette mise à jour, le lien fonctionne comme prévu. (BZ#2098234)
  • Auparavant, le composant MatchExpression ne prenait pas en compte les valeurs de type tableau. Par conséquent, seules des valeurs uniques pouvaient être saisies dans les formulaires utilisant ce composant. Avec cette mise à jour, le composant MatchExpression accepte les valeurs séparées par des virgules comme un tableau. (BZ#207690)
  • Auparavant, des vérifications redondantes du modèle entraînaient le rechargement des onglets, ce qui provoquait parfois un scintillement du contenu des onglets lorsqu'ils étaient rechargés. Avec cette mise à jour, la vérification redondante du modèle a été supprimée et le modèle n'est vérifié qu'une seule fois. Par conséquent, le contenu des onglets ne scintille plus et ne se réactualise plus. (BZ#2037329)
  • Auparavant, lors de la sélection du label edit à partir de la liste d'actions sur la page du nœud OpenShift Dedicated, aucune réponse n'était obtenue et une erreur de web hook était renvoyée. Ce problème a été corrigé de sorte que le message d'erreur n'est renvoyé que lorsque l'édition échoue. (BZ#2102098)
  • Auparavant, si des questions étaient en suspens, le fait de cliquer sur le lien Insights entraînait le blocage de la page. Pour contourner ce problème, vous pouvez attendre que la variable devienne initialized avant de cliquer sur le lien Insights. La page Insights s'ouvrira alors comme prévu. (BZ#2052662)
  • Auparavant, lorsque la ressource MachineConfigPool était mise en pause, l'option de remise en pause indiquait Resume rollouts. La formulation a été mise à jour et indique désormais Resume updates. (BZ#2094240)
  • Auparavant, la mauvaise méthode de calcul était utilisée pour compter les nœuds maîtres et les nœuds travailleurs. Avec cette mise à jour, les nœuds ouvriers corrects sont calculés lorsque les nœuds ont à la fois le rôle master et worker. (BZ#1951901)
  • Auparavant, des itinéraires react-router conflictuels pour ImageManifestVuln entraînaient des tentatives d'affichage d'une page de détails pour ImageManifestVuln avec un nom ~new. Le plugin de sécurité des conteneurs a été mis à jour pour supprimer les conflits d'itinéraires et s'assurer que les listes dynamiques et les extensions de pages de détails sont utilisées sur la page de détails de l'opérateur. Par conséquent, la console affiche correctement les pages de création, de liste et de détails pour ImageManifestVuln. (BZ#2080260)
  • Auparavant, un YAML incomplet non synchronisé était occasionnellement affiché aux utilisateurs. Avec cette mise à jour, le YAML synchronisé s'affiche toujours. (BZ#2084453)
  • Auparavant, lors de l'installation d'un opérateur nécessitant la création d'une ressource personnalisée (CR), le bouton Create resource pouvait ne pas installer la CR parce qu'il pointait vers l'espace de noms incorrect. Avec cette mise à jour, le bouton Create resource fonctionne comme prévu. (BZ#2094502)
  • Auparavant, la fenêtre modale Cluster update n'affichait pas correctement les erreurs. Par conséquent, la fenêtre modale Cluster update n'affichait ni n'expliquait les erreurs lorsqu'elles se produisaient. Avec cette mise à jour, la fenêtre modale Cluster update affiche correctement les erreurs. (BZ#2096350)
Contrôle
  • Avant cette mise à jour, les administrateurs de clusters ne pouvaient pas faire la distinction entre un pod qui n'était pas prêt à cause d'un problème de planification et un pod qui n'était pas prêt parce qu'il ne pouvait pas être démarré par le kubelet. Dans les deux cas, l'alerte KubePodNotReady était déclenchée. Avec cette mise à jour, l'alerte KubePodNotScheduled se déclenche désormais lorsqu'un module n'est pas prêt en raison d'un problème de programmation, et l'alerte KubePodNotReady se déclenche lorsqu'un module n'est pas prêt parce qu'il n'a pas pu être démarré par le kubelet. (OCPBUGS-4431)
  • Avant cette mise à jour, node_exporter fournissait des données sur les interfaces réseau virtuelles telles que les interfaces tun, br et ovn-k8s-mp. Avec cette mise à jour, les mesures relatives à ces interfaces virtuelles ne sont plus collectées, ce qui réduit la consommation de ressources de surveillance. (OCPBUGS-1321)
  • Avant cette mise à jour, le démarrage du pod Alertmanager pouvait être retardé en raison de la lenteur de la résolution DNS, et les pods Alertmanager ne démarraient pas. Avec cette version, la valeur du timeout a été augmentée à sept minutes, ce qui empêche le démarrage des pods. (BZ#2083226)
  • Avant cette mise à jour, si Prometheus Operator ne parvenait pas à exécuter ou à planifier les pods Prometheus, le système ne fournissait aucune raison sous-jacente à l'échec. Avec cette mise à jour, si les pods Prometheus ne sont pas exécutés ou planifiés, l'opérateur de surveillance de cluster met à jour l'état de surveillance clusterOperator en indiquant la raison de l'échec, ce qui peut être utilisé pour résoudre le problème sous-jacent. (BZ#2043518)
  • Avant cette mise à jour, si vous créiez une alerte silencieuse depuis la perspective Developer dans la console web d'OpenShift Container Platform, des étiquettes externes étaient incluses qui ne correspondaient pas à l'alerte. Par conséquent, l'alerte n'était pas réduite au silence. Avec cette mise à jour, les étiquettes externes sont désormais exclues lorsque vous créez un silence dans la perspective Developer, de sorte que les silences nouvellement créés fonctionnent comme prévu. (BZ#2084504)
  • Auparavant, si vous activiez une instance d'Alertmanager dédiée aux projets définis par l'utilisateur, une mauvaise configuration pouvait se produire dans certaines circonstances, et vous n'étiez pas informé que les paramètres de la carte de configuration d'Alertmanager pour les projets définis par l'utilisateur n'étaient pas chargés pour l'instance principale d'Alertmanager ou l'instance dédiée aux projets définis par l'utilisateur. Avec cette version, si cette erreur de configuration se produit, l'opérateur de surveillance des clusters affiche maintenant un message qui vous informe du problème et fournit les étapes de résolution. (BZ#2099939)
  • Avant cette mise à jour, si l'opérateur de surveillance de cluster (CMO) ne parvenait pas à mettre à jour Prometheus, il ne vérifiait pas si un déploiement antérieur était en cours d'exécution et signalait que la surveillance de cluster était indisponible même si l'un des pods Prometheus était toujours en cours d'exécution. Avec cette mise à jour, le CMO vérifie désormais si des pods Prometheus sont en cours d'exécution dans cette situation et signale que la surveillance du cluster est indisponible uniquement si aucun pod Prometheus n'est en cours d'exécution. (BZ#2039411)
  • Avant cette mise à jour, si vous configuriez OpsGenie comme récepteur d'alertes, un avertissement apparaissait dans le journal indiquant que api_key et api_key_file s'excluent mutuellement et que api_key est prioritaire. Cet avertissement apparaissait même si vous n'aviez pas défini api_key_file. Avec cette mise à jour, cet avertissement n'apparaît dans le journal que si vous avez défini à la fois api_key et api_key_file. (BZ#2093892)
  • Avant cette mise à jour, le Telemeter Client (TC) ne chargeait les nouveaux secrets d'extraction que lorsqu'il était redémarré manuellement. Par conséquent, si un secret d'extraction avait été modifié ou mis à jour et que le TC n'avait pas été redémarré, le TC ne parvenait pas à s'authentifier auprès du serveur. Cette mise à jour résout le problème de sorte que lorsque le secret est modifié, le déploiement est automatiquement redémarré et utilise le jeton mis à jour pour s'authentifier. (BZ#2114721)
Mise en réseau
  • Auparavant, les routeurs en état de terminaison retardaient la commande oc cp, ce qui retardait la commande oc adm must-gather jusqu'à ce que le pod soit terminé. Avec cette mise à jour, un délai d'attente pour chaque commande oc cp émise est défini pour éviter de retarder l'exécution de la commande must-gather. Par conséquent, les pods qui se terminent ne retardent plus les commandes must-gather. (BZ#2103283)
  • Auparavant, un contrôleur d'entrée ne pouvait pas être configuré avec le type de stratégie de publication de point final Private et le protocole PROXY. Avec cette mise à jour, les utilisateurs peuvent désormais configurer un contrôleur d'entrée avec le type de stratégie de publication de point final Private et le protocole PROXY. (BZ#2104481)
  • Auparavant, le paramètre routeSelector effaçait l'état de l'itinéraire du contrôleur d'entrée avant le déploiement du routeur. De ce fait, l'état de l'itinéraire se repeuplait de manière incorrecte. Pour éviter d'utiliser des données périmées, la détection de l'état de l'itinéraire a été mise à jour pour ne plus s'appuyer sur le cache d'objets Kubernetes. En outre, cette mise à jour inclut un correctif pour vérifier l'ID de génération sur le déploiement de la route pour déterminer l'état de la route. Par conséquent, l'état de la route est systématiquement effacé avec une mise à jour de routeSelector. (BZ#2101878)
  • Auparavant, un cluster mis à niveau à partir d'une version d'OpenShift Container Platform antérieure à la version 4.8 pouvait avoir des objets Route orphelins. Cela était dû au fait que les versions antérieures d'OpenShift Container Platform traduisaient les objets Ingress en objets Route sans tenir compte de l'indication IngressClass d'un objet Ingress donné. Avec cette mise à jour, une alerte est envoyée à l'administrateur du cluster concernant tous les objets Route orphelins encore présents dans le cluster après la traduction Ingress-to-Route. Cette mise à jour ajoute également une autre alerte qui notifie à l'administrateur du cluster tous les objets Ingress qui ne spécifient pas de IngressClass. (BZ#1962502)
  • Auparavant, si un site configmap dont dépend le déploiement du routeur n'était pas créé, le déploiement du routeur ne progressait pas. Avec cette mise à jour, l'opérateur de cluster signale ingress progressing=true si le déploiement du contrôleur d'entrée par défaut progresse. Cela permet aux utilisateurs de déboguer les problèmes liés au contrôleur d'entrée à l'aide de la commande oc get co. (BZ#2066560)
  • Auparavant, lorsqu'une politique réseau mal créée était ajoutée au cache d'OVN-Kubernetes, le leader d'OVN-Kubernetes entrait dans le statut crashloopbackoff. Avec cette mise à jour, le leader OVN-Kubernetes n'entre pas dans le statut crashloopbackoff en sautant la suppression des politiques nulles. (BZ#2091238)
  • Auparavant, la recréation d'un pod EgressIP avec le même espace de noms ou le même nom dans les 60 secondes suivant la suppression d'un pod plus ancien avec le même espace de noms ou le même nom entraînait la configuration du mauvais SNAT. En conséquence, les paquets pouvaient sortir avec nodeIP au lieu de EgressIP SNAT. Avec cette mise à jour, le trafic quitte le pod avec EgressIP au lieu de nodeIP. (BZ#2097243).
  • Auparavant, les anciennes listes de contrôle d'accès (ACL) avec arp produisaient des erreurs sur unexpectedly found multiple equivalent ACLs (arp v/s arp||nd) en raison d'un changement dans l'ACL de arp à arp II nd, ce qui empêchait la création correcte de stratégies de réseau. Avec cette mise à jour, les anciennes listes de contrôle d'accès (ACL) ne contenant que la correspondance arp ont été supprimées, de sorte que seules les ACL contenant la nouvelle correspondance arp II nd existent, de sorte que les stratégies de réseau peuvent être créées correctement et qu'aucune erreur ne sera observée sur ovnkube-master. REMARQUE : cette mise à jour concerne les clients qui mettent à jour leur système vers les versions 4.8.14, 4.9.32, 4.10.13 ou plus, à partir de versions antérieures. (BZ#2095852).
  • Avec cette mise à jour, CoreDNS est passé à la version 1.10.0, qui est basée sur Kubernetes 1.25. Cela permet d'aligner à la fois la version de CoreDNS et celle d'OpenShift Container Platform 4.12, qui est également basée sur Kubernetes 1.25. (OCPBUGS-1731)
  • Avec cette mise à jour, le routeur OpenShift Container Platform utilise désormais la version 1.25.2 de k8s.io/client-go, qui prend en charge Kubernetes 1.25. Ainsi, le site openshift-router et OpenShift Container Platform 4.12, qui est également basé sur Kubernetes 1.25, sont alignés l'un sur l'autre. (OCPBUGS-1730)
  • Avec cette mise à jour, Ingress Operator utilise désormais la version 1.25.2 de k8s.io/client-go, qui prend en charge Kubernetes 1.25. Cela permet d'aligner à la fois Ingress Operator et OpenShift Container Platform 4.12, qui est également basé sur Kubernetes 1.25. (OCPBUGS-1554)
  • Auparavant, l'opérateur DNS ne réconciliait pas l'espace de noms openshift-dns. Comme OpenShift Container Platform 4.12 exige que l'espace de noms openshift-dns ait des étiquettes de sécurité pour les pods, ces étiquettes manquaient à l'espace de noms lors de la mise à jour du cluster. Sans les étiquettes pod-security, les pods ne démarraient pas. Avec cette mise à jour, l'opérateur DNS réconcilie maintenant l'espace de noms openshift-dns, et les étiquettes de pod-sécurité sont maintenant présentes. Par conséquent, les pods démarrent comme prévu. (OCPBUGS-1549)
  • Auparavant, le site ingresscontroller.spec.tuniningOptions.reloadInterval ne prenait pas en charge les chiffres décimaux en tant que valeurs de paramètres valides, car l'opérateur d'entrée convertissait en interne la valeur spécifiée en millisecondes, qui n'était pas une unité de temps prise en charge. Cela empêchait la suppression d'un contrôleur d'entrée. Avec cette mise à jour, ingresscontroller.spec.tuningOptions.reloadInterval prend désormais en charge les chiffres décimaux et les utilisateurs peuvent supprimer des contrôleurs d'entrée avec des valeurs de paramètres reloadInterval qui n'étaient pas prises en charge auparavant. (OCPBUGS-236)
  • Auparavant, le Cluster DNS Operator utilisait les bibliothèques GO Kubernetes qui étaient basées sur Kubernetes 1.24 alors qu'OpenShift Container Platform 4.12 est basée sur Kubernetes 1.25. Avec cette mise à jour, l'API GO Kubernetes est v1.25.2, ce qui aligne le Cluster DNS Operator avec OpenShift Container Platform 4.12 qui utilise les API Kubernetes 1.25. (lien : OCPBUGS-1558)
  • Auparavant, la configuration de disableNetworkDiagnostics à true ne persistait pas lorsque le pod network-operator était recréé. Avec cette mise à jour, la propriété de configuration disableNetworkDiagnostics de network`operator.openshift.io/cluster` ne se réinitialise plus à sa valeur par défaut après le redémarrage de l'opérateur réseau. (OCPBUGS-392)
  • Auparavant, ovn-kubernetes ne configurait pas l'adresse MAC correcte des interfaces liées dans br-ex bridge. Par conséquent, un nœud qui utilise le bonding pour l'interface Kubernetes primaire ne parvient pas à rejoindre le cluster. Avec cette mise à jour, ovn-kubernetes configure l'adresse MAC correcte des interfaces liées dans le pont br-ex, et les nœuds qui utilisent le bonding pour l'interface Kubernetes primaire rejoignent le cluster avec succès. (BZ2096413)
  • Auparavant, lorsque l'opérateur d'entrée était configuré pour activer l'utilisation de mTLS, l'opérateur ne vérifiait pas si les CRL devaient être mises à jour jusqu'à ce qu'un autre événement l'oblige à procéder à une réconciliation. Par conséquent, les LCR utilisées pour mTLS pouvaient devenir obsolètes. Avec cette mise à jour, l'opérateur d'entrée procède désormais automatiquement à la réconciliation lorsqu'une CRL expire, et les CRL seront mises à jour à l'heure spécifiée par leur champ nextUpdate. (BZ#2117524)
Nœud
  • Auparavant, un message d'erreur concernant les liens symboliques était imprimé sous forme de données brutes au lieu d'être formaté comme une erreur, ce qui le rendait difficile à comprendre. Cette correction formate le message d'erreur correctement, afin qu'il soit facilement compréhensible. (BZ#1977660)
  • Auparavant, les seuils d'éviction difficiles des kubelets étaient différents des valeurs par défaut de Kubernetes lorsqu'un profil de performance était appliqué à un nœud. Avec cette version, les valeurs par défaut ont été mises à jour pour correspondre aux valeurs par défaut de Kubernetes. (OCPBUGS-4362).
OpenShift CLI (oc)
  • La version 4.12 d'OpenShift Container Platform corrige un problème lié à l'ouverture d'une session de débogage sur un nœud cible lorsque l'espace de noms cible n'a pas le niveau de sécurité approprié. Cela provoquait l'affichage d'un message d'erreur sur la sécurité du pod dans la CLI de oc. Si l'espace de noms existant ne contient pas les niveaux de sécurité appropriés, OpenShift Container Platform crée désormais un espace de noms temporaire lorsque vous entrez dans le mode de débogage oc sur un nœud cible.(OCPBUGS-852)
  • Auparavant, sur l'architecture macOS arm64, le binaire oc devait être signé manuellement. Par conséquent, le binaire oc ne fonctionnait pas comme prévu. Cette mise à jour implémente un binaire auto-signé pour imiter oc. Par conséquent, le binaire oc fonctionne correctement sur les architectures macOS arm64. (BZ#2059125)
  • Auparavant, must-gather essayait de collecter des ressources qui n'étaient pas présentes sur le serveur. Par conséquent, must-gather affichait des messages d'erreur. Désormais, avant de collecter des ressources, must-gather vérifie si la ressource existe. Par conséquent, must-gather n'affiche plus d'erreur lorsqu'il ne parvient pas à collecter des ressources inexistantes sur le serveur. (BZ#2095708)
  • La version 4.12 d'OpenShift Container Platform met à jour la bibliothèque oc-mirror, afin qu'elle prenne en charge les images de plates-formes multi-archives. Cela signifie que vous pouvez choisir parmi une plus grande sélection d'architectures, telles que arm64, lors de la mise en miroir d'une charge utile de plate-forme. (OCPBUGS-617)
Gestionnaire du cycle de vie des opérateurs (OLM)
  • Avant la version 4.12 d'OpenShift Container Platform, le contrôleur package-server-manager n'annulait pas les modifications apportées à une version de service de cluster (CSV) package-server, en raison d'un problème avec la fonction on-cluster. Ces changements persistants peuvent avoir un impact sur la façon dont un opérateur démarre dans un cluster. Pour OpenShift Container Platform 4.12, le contrôleur package-server-manager reconstruit toujours une CSV package-server à son état d'origine, de sorte qu'aucune modification de la CSV ne persiste après une opération de mise à niveau du cluster. La fonction on-cluster ne contrôle plus l'état d'un CSV package-server. (OCPBUGS-867)
  • Auparavant, Operator Lifecycle Manager (OLM) tentait de mettre à jour les espaces de noms pour appliquer un label, même si le label était présent dans l'espace de noms. Par conséquent, les demandes de mise à jour augmentaient la charge de travail des services API et etcd. Avec cette mise à jour, OLM compare les étiquettes existantes avec les étiquettes attendues sur un espace de noms avant d'émettre une mise à jour. Par conséquent, OLM ne tente plus d'effectuer des demandes de mise à jour inutiles sur les espaces de noms. (BZ#2105045)
  • Auparavant, Operator Lifecycle Manager (OLM) empêchait les mises à niveau mineures de clusters qui ne devraient pas être bloquées en raison d'une erreur de calcul du champ spec.DesiredVersion des ressources personnalisées ClusterVersion. Avec cette mise à jour, OLM n'empêche plus les mises à niveau de clusters qui devraient être prises en charge. (BZ#2097557)
  • Auparavant, le conciliateur mettait à jour l'annotation d'une ressource sans faire de copie de la ressource. Cela provoquait une erreur qui mettait fin au processus de rapprochement. Avec cette mise à jour, le processus de rapprochement ne s'arrête plus à cause de cette erreur. (BZ#2105045)
  • Le package-server-manifest (PSM) est un contrôleur qui s'assure que la bonne package-server Cluster Service Version (CSV) est installée sur un cluster. Auparavant, les modifications apportées à la CSV package-server n'étaient pas annulées en raison d'une erreur logique dans la fonction de réconciliation dans laquelle un objet sur le cluster pouvait influencer l'objet attendu. Les utilisateurs pouvaient modifier le fichier CSV package-server sans que les modifications soient annulées. En outre, les mises à niveau des clusters ne mettaient pas à jour le YAML pour le CSV package-server. Avec cette mise à jour, la version attendue du CSV est désormais toujours construite à partir de zéro, ce qui supprime la possibilité pour un objet sur le cluster d'influencer les valeurs attendues. Par conséquent, le PSM annule désormais toute tentative de modification du CSV package-server, et les mises à niveau de clusters déploient désormais le CSV attendu package-server. (OCPBUGS-858)
  • Auparavant, OLM mettait à niveau un opérateur en fonction de son statut CRD. Un CRD répertorie les références des composants dans un ordre défini par l'identifiant groupe/version/genre (GVK). Les opérateurs qui partagent les mêmes composants peuvent amener le GVK à modifier les listes de composants d'un opérateur, ce qui peut nécessiter davantage de ressources système pour mettre à jour en permanence l'état d'un CRD. Avec cette mise à jour, le gestionnaire du cycle de vie des opérateurs (OLM) met désormais à niveau un opérateur en fonction des références des composants de l'opérateur. Une modification de l'état de la définition des ressources personnalisées (CRD) d'un opérateur n'a pas d'incidence sur le processus de mise à niveau de l'opérateur OLM.(OCPBUGS-3795)
SDK de l'opérateur
  • Avec cette mise à jour, vous pouvez maintenant définir le contexte de sécurité pour le pod de registre en incluant le champ de configuration securityContext dans la spécification du pod. Le contexte de sécurité s'appliquera alors à tous les conteneurs du pod. Le champ securityContext définit également les privilèges du module. (BZ#2091864)
Opérateur d'intégrité des fichiers
  • Auparavant, l'opérateur d'intégrité des fichiers déployait des modèles en utilisant l'espace de noms openshift-file-integrity dans les autorisations de l'opérateur. Lorsque l'opérateur tentait de créer des objets dans l'espace de noms, il échouait en raison de problèmes d'autorisation. Avec cette version, les ressources de déploiement utilisées par OLM sont mises à jour pour utiliser l'espace de noms correct, ce qui résout les problèmes d'autorisation et permet aux utilisateurs d'installer et d'utiliser l'opérateur dans des espaces de noms autres que ceux par défaut. (BZ#2104897)
  • Auparavant, les dépendances sous-jacentes de l'opérateur d'intégrité des fichiers modifiaient la manière dont les alertes et les notifications étaient gérées, et l'opérateur n'envoyait donc pas de métriques. Avec cette version, l'opérateur s'assure que le point de terminaison des mesures est correct et accessible au démarrage. (BZ#2115821)
  • Auparavant, les alertes émises par l'opérateur d'intégrité des fichiers ne définissaient pas d'espace de noms. Il était donc difficile de comprendre d'où venait l'alerte ou quel était le composant responsable de son émission. Avec cette version, l'opérateur inclut l'espace de noms dans lequel il a été installé dans l'alerte, ce qui permet de déterminer plus facilement le composant qui a besoin d'attention. (BZ#2101393)
  • Auparavant, l'opérateur d'intégrité des fichiers ne gérait pas correctement la modification des alertes lors d'une mise à niveau. Par conséquent, les alertes n'incluaient pas l'espace de noms dans lequel l'opérateur était installé. Avec cette version, l'opérateur inclut l'espace de noms dans lequel il a été installé dans l'alerte, ce qui permet de déterminer plus facilement le composant qui nécessite une attention particulière. (BZ#2112394)
  • Auparavant, la propriété du compte de service pour l'opérateur d'intégrité des fichiers régressait en raison des mises à jour OLM sous-jacentes, et les mises à jour de 0.1.24 à 0.1.29 étaient interrompues. Avec cette mise à jour, l'opérateur passe par défaut à la version 0.1.30. (BZ#2109153)
  • Auparavant, le démon File Integrity Operator utilisait le paramètre ClusterRoles au lieu du paramètre Roles pour une modification récente des autorisations. Par conséquent, OLM ne pouvait pas mettre à jour l'opérateur. Avec cette version, le démon Opérateur utilise à nouveau le paramètre Roles et les mises à jour des anciennes versions vers la version 0.1.29 sont réussies. (BZ#2108475)
Opérateur de conformité
  • Auparavant, l'opérateur de conformité utilisait une ancienne version de l'Operator SDK, qui est une dépendance pour la construction des opérateurs. Cela provoquait des alertes sur les fonctionnalités Kubernetes obsolètes utilisées par le SDK de l'opérateur. Avec cette version, l'Opérateur de Conformité est mis à jour à la version 0.1.55, qui inclut une version mise à jour du SDK de l'Opérateur. (BZ#2098581)
  • Auparavant, l'application de la remédiation automatique pour les règles rhcos4-high-master-sysctl-kernel-yama-ptrace-scope et rhcos4-sysctl-kernel-core-pattern entraînait des échecs ultérieurs de ces règles dans les résultats de l'analyse, même si elles avaient été remédiées. Ce problème est corrigé dans cette version. (BZ#2094382)
  • Auparavant, l'opérateur de conformité codait en dur les notifications dans l'espace de noms par défaut. Par conséquent, les notifications de l'opérateur n'apparaissaient pas si l'opérateur était installé dans un autre espace de noms. Ce problème est corrigé dans cette version. (BZ#2060726)
  • Auparavant, l'opérateur de conformité ne parvenait pas à récupérer les ressources de l'API lorsqu'il analysait les configurations des machines sans les spécifications d'Ignition. Cela provoquait le blocage de la boucle de vérification api-check-pods. Avec cette version, l'Opérateur de Conformité est mis à jour pour gérer de manière élégante les pools de configuration de machines sans spécifications Ignition. (BZ#2117268)
  • Auparavant, l'opérateur de conformité maintenait les configurations de machines dans un état bloqué parce qu'il ne pouvait pas déterminer la relation entre les configurations de machines et les configurations de kubelets. Cela était dû à des hypothèses incorrectes sur les noms des configurations de machines. Avec cette version, l'opérateur de conformité est capable de déterminer si une configuration kubelet est un sous-ensemble d'une configuration machine. (BZ#2102511)
Serveur API OpenShift
  • Auparavant, l'ajout d'un membre pouvait entraîner la suppression des membres précédents d'un groupe. En conséquence, l'utilisateur perdait ses privilèges de groupe. Avec cette version, les dépendances ont été supprimées et les utilisateurs ne perdent plus leurs privilèges de groupe. (OCPBUGS-533)
Red Hat Enterprise Linux CoreOS (RHCOS)
  • Auparavant, la mise à jour vers Podman 4.0 empêchait les utilisateurs d'utiliser des images personnalisées avec des conteneurs Toolbox sur RHCOS. Ce correctif met à jour le code de la bibliothèque Toolbox pour prendre en compte le nouveau comportement de Podman, de sorte que les utilisateurs peuvent maintenant utiliser des images personnalisées avec Toolbox sur RHCOS comme prévu. (BZ#2048789)
  • Auparavant, la commande podman exec ne fonctionnait pas bien avec les conteneurs imbriqués. Les utilisateurs rencontraient ce problème lorsqu'ils accédaient à un nœud à l'aide de la commande oc debug, puis exécutaient un conteneur à l'aide de la commande toolbox. De ce fait, les utilisateurs ne pouvaient pas réutiliser les boîtes à outils sur RHCOS. Ce correctif met à jour le code de la bibliothèque de boîtes à outils pour tenir compte de ce comportement, de sorte que les utilisateurs peuvent désormais réutiliser les boîtes à outils sur RHCOS. (BZ#1915537)
  • Avec cette mise à jour, l'exécution de la commande toolbox vérifie désormais les mises à jour de l'image par défaut avant de lancer le conteneur. Cela améliore la sécurité et fournit aux utilisateurs les dernières corrections de bogues. (BZ#2049591)
  • Auparavant, la mise à jour vers Podman 4.0 empêchait les utilisateurs d'exécuter la commande toolbox sur RHCOS. Ce correctif met à jour le code de la bibliothèque de la boîte à outils pour tenir compte du nouveau comportement de Podman, de sorte que les utilisateurs peuvent désormais exécuter toolbox sur RHCOS comme prévu. (BZ#2093040)
  • Auparavant, les modules de politique SELinux personnalisés n'étaient pas correctement pris en charge par rpm-ostree, de sorte qu'ils n'étaient pas mis à jour en même temps que le reste du système lors de la mise à jour. Cela se traduisait par des défaillances dans des composants non liés. En attendant que les améliorations de l'espace utilisateur SELinux soient intégrées dans une future version d'OpenShift Container Platform, cette mise à jour fournit une solution de contournement à RHCOS qui reconstruira et rechargera la politique SELinux pendant le démarrage, si nécessaire. (OCPBUGS-595)
Évolutivité et performance
  • Le profil accordé a été modifié pour attribuer la même priorité que ksoftirqd et rcuc aux nouveaux kthreads par CPU (ktimers) ajoutés dans un récent patch du noyau Red Hat Enterprise Linux (RHEL). Pour plus d'informations, voir OCPBUGS-3475, BZ#2117780 et BZ#2122220.
  • Auparavant, les redémarrages du service tuned provoquaient une réinitialisation incorrecte de la configuration de irqbalance, ce qui conduisait à une opération IRQ servie à nouveau sur les CPU isolés, violant ainsi les garanties d'isolation. Avec cette correction, la configuration du service irqbalance est correctement préservée à travers les redémarrages du service tuned (explicites ou causés par des bogues), préservant ainsi les garanties d'isolation du CPU en ce qui concerne le service d'IRQ. (OCPBUGS-585)
  • Auparavant, lorsque le démon tuned était redémarré dans le désordre dans le cadre du cluster Node Tuning Operator, l'affinité CPU des gestionnaires d'interruption était réinitialisée et le tuning était compromis. Avec cette correction, le plugin irqbalance dans tuned est désactivé, et OpenShift Container Platform s'appuie maintenant sur la logique et l'interaction entre CRI-O et irqbalance.(BZ#2105123)
  • Auparavant, un script d'accroche à faible latence s'exécutant pour chaque nouveau périphérique veth prenait trop de temps lorsque le nœud était en charge. Les retards accumulés lors des événements de démarrage de pods provoquaient un temps de déploiement lent pour kube-apiserver et dépassaient parfois le délai de déploiement de 5 minutes. Avec cette correction, le temps de démarrage des conteneurs devrait être plus court et se situer dans le seuil des 5 minutes. (BZ#2109965).
  • Auparavant, le thread de contrôle oslat était colocalisé avec l'un des threads de test, ce qui provoquait des pics de latence dans les mesures. Avec cette correction, le programme d'exécution oslat réserve désormais une unité centrale pour le thread de contrôle, ce qui signifie que le test utilise une unité centrale de moins pour l'exécution des threads occupés. (BZ#2051443)
  • Les outils de mesure de la latence, également connus sous les noms de oslat, cyclictest et hwlatdetect, s'exécutent désormais sur des unités centrales complètement isolées, sans le processus d'aide fonctionnant en arrière-plan qui pourrait provoquer des pics de latence, ce qui permet d'obtenir des mesures de latence plus précises. (OCPBUGS-2618)
  • Auparavant, bien que la référence PolicyGenTemplate pour group-du-sno-ranGen.yaml comprenne deux entrées StorageClass, la politique générée n'en comprenait qu'une seule. Avec cette mise à jour, la politique générée inclut désormais les deux politiques. (BZ#2049306).
Stockage
  • Auparavant, les vérifications des volumes éphémères génériques échouaient. Avec cette mise à jour, les vérifications des volumes extensibles incluent désormais les volumes éphémères génériques. (BZ#2082773)
  • Auparavant, si plus d'un secret était présent pour vSphere, l'opérateur vSphere CSI choisissait un secret de manière aléatoire et provoquait parfois le redémarrage de l'opérateur. Avec cette mise à jour, un avertissement apparaît lorsqu'il y a plus d'un secret sur l'opérateur vCenter CSI. (BZ#2108473)
  • Auparavant, OpenShift Container Platform détachait un volume lorsqu'un pilote d'interface de stockage de conteneurs (CSI) n'était pas en mesure de démonter le volume d'un nœud. Détacher un volume sans le démonter n'est pas autorisé par les spécifications CSI et les pilotes pourraient entrer dans un état undocumented. Avec cette mise à jour, les pilotes CSI sont détachés avant le démontage uniquement sur les nœuds malsains, ce qui permet d'éviter l'état undocumented. (BZ#2049306)
  • Auparavant, il manquait des annotations sur la VolumeSnapshotClass de l'opérateur du pilote Manila CSI. Par conséquent, le snapshotter Manila CSI ne pouvait pas localiser les secrets et ne pouvait pas créer d'instantanés avec la VolumeSnapshotClass par défaut. Cette mise à jour corrige le problème afin que les noms de secrets et les espaces de noms soient inclus dans la classe VolumeSnapshotClass par défaut. Par conséquent, les utilisateurs peuvent désormais créer des instantanés dans le Manila CSI Driver Operator à l'aide de la classe VolumeSnapshotClass par défaut. (BZ#2057637)

  • Les utilisateurs peuvent désormais choisir d'utiliser la fonction expérimentale VHD sur Azure File. Pour ce faire, ils doivent spécifier le paramètre fstype dans une classe de stockage et l'activer avec --enable-vhd=true. Si fstype est utilisé et que la fonctionnalité n'est pas définie sur true, les volumes ne seront pas provisionnés.

    Pour ne pas utiliser la fonction VHD, supprimez le paramètre fstype de votre classe de stockage. (BZ#2080449)

  • Auparavant, si plus d'un secret était présent pour vSphere, l'opérateur vSphere CSI choisissait un secret de manière aléatoire et provoquait parfois le redémarrage de l'opérateur. Avec cette mise à jour, un avertissement apparaît lorsqu'il y a plus d'un secret sur l'opérateur vCenter CSI. (BZ#2108473)
Console web (perspective développeur)
  • Auparavant, les utilisateurs ne pouvaient pas désélectionner un secret Git dans les formulaires d'ajout et d'édition. Par conséquent, les ressources devaient être recréées. Ce correctif résout le problème en ajoutant l'option de choisir No Secret dans la liste des options de sélection des secrets. Ainsi, les utilisateurs peuvent facilement sélectionner, désélectionner ou détacher les secrets attachés. (BZ#2089221)
  • Dans OpenShift Container Platform 4.9, lorsqu'il y a peu ou pas de données dans le site Developer Perspective, la plupart des diagrammes ou graphiques de surveillance (consommation de CPU, utilisation de la mémoire et bande passante) affichent une plage de -1 à 1. Cependant, aucune de ces valeurs ne peut jamais descendre en dessous de zéro. Ce problème sera résolu dans une prochaine version. (BZ#1904106)
  • Avant cette mise à jour, les utilisateurs ne pouvaient pas faire taire les alertes dans la perspective Developer de la console web d'OpenShift Container Platform lorsqu'un service Alertmanager défini par l'utilisateur était déployé, car la console web transmettait la demande au service Alertmanager de la plateforme dans l'espace de noms openshift-monitoring. Avec cette mise à jour, lorsque vous visualisez la perspective Developer dans la console web et que vous essayez de faire taire une alerte, la demande est transmise au service Alertmanager correct. (OCPBUGS-1789)
  • Auparavant, il y avait un problème connu dans le formulaire Add Helm Chart Repositories pour étendre le catalogue des développeurs d'un projet. Les guides Quick Start indiquent que vous pouvez ajouter le CR ProjectHelmChartRepository dans l'espace de noms requis, mais ils ne mentionnent pas que pour ce faire, vous avez besoin de l'autorisation du kubeadmin. Ce problème a été résolu avec Quickstart qui mentionne les étapes correctes pour créer ProjectHelmChartRepository CR. (BZ#2057306)
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.