1.11.5.3. 修正された問題


  • 今回のアップデート以前は、OpenShift Container Platform の Web コンソールで namespace スコープの ProjectHelmChartRepository オブジェクトを作成すると、認証局 (CA) 証明書と Transport Layer Security (TLS) クライアント設定のドロップダウンメニューには openshift-config namespace のリソースのみが表示されていました。今回のリリースにより、ProjectHelmChartRepository オブジェクトでは、選択したプロジェクト namespace 内の CA および TLS リソースがフォーム上にリスト表示されるようになりました。一方、クラスタースコープの HelmChartRepository オブジェクトについては、引き続き openshift-config namespace が使用されます。(OCPBUGS-76328)
  • 今回のアップデート以前は、バウンダリークロック (T-BC) がホールドオーバー状態に移行すると、event.sync.sync-status.synchronization-state-change (/sync/sync-status/sync-state) イベントが HOLDOVER の代わりに FREERUN を誤って報告することがありました。これらの報告は、ノード全体の同期状態の計算に問題があったために発生した可能性があります。今回のリリースでは、ptp4l の状態は無視されます。その結果、event.sync.sync-status.synchronization-state-change (/sync/sync-status/sync-state) イベントは正しく HOLDOVER を報告します。(OCPBUGS-86530)
  • 今回のアップデート以前は、アービターの設定ではデフォルトのコンテナーランタイムとして runc が使用されていました。今回のリリースでは、アービターの設定がマスターノードと同期するように更新され、デフォルトのコンテナーランタイムとして crun が使用されるようになりました。(OCPBUGS-87019)
  • 今回のアップデート以前は、複数のリクエストが同時にプロジェクト認可データにアクセスした場合、openshift-apiserver が失敗する可能性がありました。この問題は、多数の namespace やロールベースアクセス制御 (RBAC) ルールが存在するクラスターで、より高頻度に発生していました。その結果、openshift-apiserver Pod が予期せず終了コード 2 で再起動し、プロジェクトおよび namespace 操作用の API の利用が一時的に中断されました。今回のリリースにより、プロジェクトの認可キャッシュは同時アクセスを安全に処理できるようになりました。これにより、プロジェクトの認可照会が並行して実行された場合でも openshift-apiserver namespace で障害が発生しなくなり、クラスターの規模に関わらずプロジェクトのリスト取得処理の応答性が維持されます。(OCPBUGS-87022)
  • 今回のアップデート以前は、Cluster Dashboard Overview ページに移動し、Status カードの Insights ウィンドウをクリックすると、基盤となる UI コンポーネントがテキストを正しく表示していませんでした。その結果、4 つの重大度レベル (重大、重要、中程度、低) を示すアイコンは表示されたものの、実際の課題数や Insights Advisor へのリンクが表示されていませんでした。今回のリリースでは、Insights の重大度メッセージ内のリンクコンポーネントが更新され、テキストとリンクが正しく表示されるようになります。これにより、Insights ウィンドウの各重要度レベルに、アイコン、正しい問題数、および Insights アドバイザーへのクリック可能なリンクが正しくレンダリングされるようになりました。(OCPBUGS-87096)
  • 今回のアップデート以前は、cloud-event-proxy (CEP) サイドカーの再起動後、linuxptp-daemon は同じイベントソケット上で、リプレイされた出力とライブ ptp4l 出力を同時に送信することができました。リプレイされた古い FAULTY ポートロールイベントにより、クロック状態が強制的に HOLDOVER へ移行してしまう可能性があります。ポートロールの更新は離散的な状態変更イベントの発生時にしか行われないため、その後にライブでオフセット値が更新されても LOCKED 状態へ復帰できませんでした。リプレイされた RECEIVER から FAULTY への遷移は、ソケット上のアクティブな RECEIVER のロールを上書きし、実際のポート状態の変更が発生するまで継続する可能性があります。この問題は、T-BC およびデュアルフォロワー設定に影響し、可能性は低いものの OpenShift CLI (oc) 設定にも影響します。その結果、ptp4l が完全にロックされている場合でも、クロック状態メトリクスと SyncStateChange クラウドイベントが FREERUN または HOLDOVER でスタックしたままになり、ポートロールが FAULTY でスタックしたままになる可能性があります。今回のリリースでは、ライブゲートによって、リプレイが完了するまでプロセス接続からイベントソケットへの書き込みがブロックされるようになりました。これにより、すべてのライブデータが到着する前に、履歴状態が確実にすべて処理されます。これにより、古いリプレイデータがライブ出力と競合できなくなり、クロック状態とポートロールのメトリクスは、CEP 再起動後の現在の同期ステータスを正しく反映します。(OCPBUGS-87839)
  • 今回のアップデート以前は、OpenShift Container Platform は、高解像度カーネルタイマーと cyclictest (タイマーベースのベンチマークツール) が余分なレイテンシーの影響を受けないように、タイマー移行を無効にしていました。しかし、新規に CPU ピン留めされた guaranteed ワークロードコンテナーに対して、すでに割り当てられている CPU から起動済みタイマー (TCP タイムアウトや keep-alive など) を移行させるには、タイマーの移行が必要でした。その結果、タイマー移行が無効になった際、残りのタイマーがレイテンシーに敏感なワークロードを中断し続けました。今回のリリースでは、タイマーの移行機能が復活し、設定が可能になりました。これは、PerformanceProfile パラメーターが主にレイテンシーに敏感なワークロードで使用されるためです。これにより、新しく作成された Pod が、それらのワークロードに割り当てられた CPU 上でスタックしているタイマーによって中断されることはありません。クラスター上でレイテンシーに敏感なポーリングアプリケーションを実行したくない場合は、ナレッジベースの 5532341 に記載されている高度な設定手順を使用して、kernel.timer_migration=0 sysctl を設定できます。(OCPBUGS-87891)
  • 今回のアップデート以前は、新しいノードをブートストラップする際に、クラスター設定で必要かどうかに関わらず、拡張機能イメージがプルされていました。その結果、ノードのブートストラップ時間が長くなりました。今回のリリースにより、拡張機能イメージは設定で必要な場合にのみプルされるようになりました。(OCPBUGS-88120)
  • 今回のアップデート以前は、親 PVC が削除された状態でも VolumeSnapshot を機能させるには、"Restore as new PVC" 操作を完了するよう促されていました。CLI ですでにサポートされていたこの操作が、コンソールの挙動にも反映されました。今回のリリースでは、VolumeSnapshot の復元モーダルが、ストレージクラス、アクセスモード、およびサイズに関するスナップショットアノテーションにフォールバックするようになり、元の PVC の存在を必須とする必要がなくなりました。(OCPBUGS-88304)
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る