サポートコンソール開発者トライアルの開始お問い合わせ

1.8.18. ノード

  • このアップデート以前は、上流の Pod のインプレースサイズ変更スケジューラーに焦点を当てたテストでは、最初の Pod が利用可能なすべての CPU リソースを消費した場合、2 番目のテスト Pod が 保留 フェーズにとどまることが想定されていましたが、スケジューラーが誤って 2 番目の Pod の 実行 フェーズへの移行を許可していました。その結果、テストは Pod 'testpod2' はフェーズ Pending であるべきでしたが、フェーズ Running になりましたというエラーで一貫して失敗しました。今回のリリースにより、スケジューラーはインプレースサイズ変更操作中にリソース制約を正しく適用するようになりました。その結果、テストは確実に合格し、Pod は利用可能なノードリソースに応じてスケジュールされます。(OCPBUGS-63132)
  • このアップデート以前は、config-operator が 再起動したり、一時的な API サーバー接続の問題が発生した場合、config-drift-monitor は リカバリー中に各 Tuned リソースに対して ConfigDriftMonitorStopped および RemoveSigtermProtection イベントを繰り返し発行していました。その結果、シリアルテクニカルプレビュージョブにおいて、病理学的イベントのテストが失敗し、これらのイベントが 20 回以上発生したと報告された。今回のリリースでは、config-drift-monitor が 再起動および復旧シナリオにおけるイベントノイズを低減します。その結果、シリアルテクニカルプレビュージョブでは、病理学的イベントのテストが確実に合格します。(OCPBUGS-63307)
  • 今回のアップデート以前は、InPlacePodVerticalScaling フィーチャーゲートが有効になっている状態で、kubelet が Pod のサイズ変更操作中にリソース容量を計算する際に、使用 CPU 値を実際の値ではなく、非常に大きな値として誤って計算していました。その結果、ノードに十分な CPU 容量が利用可能であっても、Pod のサイズ変更要求が OutOfcpu エラーで失敗しました。今回のリリースにより、kubelet はサイズ変更操作中に使用される CPU 使用率を正しく計算するようになりました。その結果、ノードに十分な CPU リソースがある場合、インプレース Pod の垂直スケーリング要求は成功します。(OCPBUGS-64847)
  • このアップデート以前は、Hosted Control Plane を含むすべてのトポロジーで AutoSizingReserved オプションがデフォルトで有効になっていたため、この機能はノードサイズに基づいてシステム予約メモリーを動的に増加させていました。そのため、Hosted Control Plane ワーカーノードで使用される m5.large や m5.xlarge などの小型インスタンスタイプでは、割り当て可能なメモリーが大幅に減少していました。その結果、監視、DNS、ネットワーク、レジストリーなどのプラットフォーム Pod は、割り当て可能なメモリーが不足しているため、Hosted Control Plane ワーカーノードにスケジュールできず、クラスター Operator のパフォーマンスが低下し、e2e テストが失敗しました。今回のリリースでは、Hosted Control Plane ワーカーノード (ControlPlaneTopology=External) の AutoSizingReserved オプションが無効になっています。その結果、Hosted Control Plane のエンドツーエンドテストは合格し、Hosted Control Plane ワーカーノードには、すべてのプラットフォーム Pod が正常にスケジュールされるのに十分な割り当て可能なメモリーが確保されました。(OCPBUGS-79502)
  • このアップデート以前は、非常に大規模な非均一メモリーアクセス (NUMA) トポロジーを持つシステム (たとえば、34 個の NUMA ノードを持つ NVIDIA GB200 システム) で PCI デバイスを要求する Pod をスケジューリングする場合、ヒント生成における組み合わせ爆発のため、kubelet トポロジー Manager はトポロジーヒントの計算を完了できませんでした。その結果、GPU、InfiniBand、または Non-Volatile Memory Express (NVMe) デバイスを要求する Pod は Pending 状態にとどまり、hostDevices を使用する KubeVirt VirtualMachineInstances は Running 状態に移行しませんでした。今回のリリースでは、TopologyManager のヒント生成アルゴリズムが最適化され、NUMA ノードが多数存在するシステムでも、限られた時間内にヒントを計算できるようになりました。その結果、PCI ホストデバイスを要求する Pod や仮想マシンは、GB200 クラスのハードウェアなどの大規模な NUMA システム上で正常に起動します。(OCPBUGS-83502)
  • 今回のアップデート以前は、OpenShift Container Platform はデフォルトのベースオペレーティングシステムとして RHEL 10 に切り替わっていましたが、runc OCI ランタイムバイナリーは RHCOS 10 イメージに含まれていませんでした。その結果、OCI ランタイムとして runc を 使用するように設定されたすべての CI ジョブは、ブートストラップ中に失敗しました。これは、CRI-O が $PATH 内に runc 実行ファイルを見つけることができず、コンテナーランタイムの初期化が妨げられたためです。今回のリリースでは、runc ベースのジョブ用の CI インフラストラクチャーが更新され、runc バイナリーが RHCOS 10 環境で利用可能になることが保証されます。その結果、runc ベースの CI ジョブは正常にブートストラップされ、実行時エラーなく完了します。(OCPBUGS-89267)
  • このアップデート以前は、コンテナーネイティブ仮想化 (CNV) 用の kubelet LimitedSwap Drop-in Configuration テストケース (TC6) が、oc debug node を介した kubelet の再起動中に失敗し、ワーカーノードが劣化し、システム設定アーティファクト (system_compressible および reserved-cpu-test の 残骸) が残っていました。その結果、障害発生時間が長いテスト スイートにおける後続のテストは完了までに著しく多くの時間を要し、テストスイート全体がタイムアウトした。今回のリリースでは、テストによってノード設定が適切にクリーンアップされ、ノードの性能を低下させることなく kubelet が正常に再起動されることが保証されます。その結果、長時間実行される負荷の高い テストスイートは、タイムアウトエラーを起こすことなく、想定された時間内に完了します。(OCPBUGS-90507)
  • このアップデート以前は、CRIOCredentialProviderConfig カスタムリソース定義 (CRD) は、最初に導入された時点でストレージバージョンとして v1 を 即座に設定していました。その結果、この CRD を含むバージョンにアップグレードしたクラスターは、ストレージバージョンの変更が段階的ではなかったため、以前のバージョンに安全にロールバックすることができませんでした。今回のリリースでは、CRD はロールバックが可能なバージョン管理パターンに従い、導入後すぐにストレージバージョンを変更することはありません。その結果、クラスター管理者は CRD ストレージのバージョン互換性の問題に遭遇することなく、安全にアップグレードをロールバックできます。(OCPBUGS-94869)
  • 今回のアップデート以前は、動的リソース割り当て (DRA) 拡張リソースのアップストリーム Kubernetes テストでは、DRA ドライバーとサンプルデバイスプラグインが別々のノードにデプロイされていましたが、ドライバーの設定がデバイスプラグインと連携する際に、テストインフラストラクチャーに不安定な動作が見られました。その結果、シリアルテストスイートでは約 53% の確率でテストが失敗し、登録済みリソースのエンドポイントがキャッシュに見つかりません: example.com/resource などのエラーが発生しました。今回のリリースでは、一般的なシリアルレーンでのテストはスキップされ、ドライバーの設定がより確実な専用レーンで DRA をテストするという上流のアプローチに合わせられています。その結果、この不安定な DRA テストインフラストラクチャーに起因するシリアルテストスイートの頻繁な障害は解消された。(OCPBUGS-99058)
  • このアップデート以前は、CPU パーティショニング適合性テストはすべての openshift-* 名前空間を列挙し、それらに workload.openshift.io/allowed:management アノテーションがあることを前提としていましたが、並列 SecurityPenetration テストで oc debug node/ コマンドによって作成された一時的な openshift-debug-* 名前空間を除外していませんでした。その結果、セキュリティー侵入 テストと CPU パーティショニングテストを同時に実行した場合、デバッグネームスペースに管理アノテーションがなかったため、CPU パーティショニングテストが失敗しました。今回のリリースでは、テストにおいて openshift-debug-* 名前空間がアノテーションチェックから除外されます。その結果、セキュリティー 侵入テストが並行して実行されている場合でも、CPU パーティショニングテストは確実に合格します。(OCPBUGS-100392)
  • このアップデート以前は、同じノード上で約 100 個の Pod を同時に作成し、各 Pod が同じ OCI イメージをイメージボリュームとしてマウントする場合、CRI-O はコンテナー/ストレージ層を介したマウント操作ごとに書き込みロックを取得していました。その結果、イメージレイヤーがすでにノード上に存在していたにもかかわらず、すべてのマウント操作が単一のロックの背後で直列化され、EmptyDir ボリュームを使用した場合と比較して Pod の起動時間が約 80% 増加しました。今回のリリースでは、CRI-O はイメージボリュームのマウントパスを最適化し、すでに存在するイメージレイヤーをマウントする際に発生する不要なロック競合を回避します。その結果、ノード上の複数の Pod に同じイメージをマウントしても、Pod の起動パフォーマンスが著しく低下することはなくなった。(OCPBUGS-108950)
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

Legal Notice

Theme

© 2026 Red Hatトップに戻る