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

1.10. 既知の問題

OpenShift Container Platform 5.0 の既知の問題は、ノード、Pod、およびネットワークデバイスに影響を与える可能性があります。各問題の影響と回避策について検討します。

  • OpenShift Container Platform クラスター上で Cloud-native Network Functions (CNF) のレイテンシーテストを実行すると、cyclictest による測定で 20 マイクロ秒を超えるなど、テスト結果が許容しきい値を超過する場合があります。クラスターが低レイテンシーワークロード向けに正しく設定されている場合でも、これにより、テストが断続的に失敗する可能性があります。回避策として、レイテンシースパイクの頻度と大きさを軽減するために、stalld バックエンドを sched_debug に戻します。(OCPBUGS-86339)
  • BlueField-3 NIC を使用したテスト用ワークロードを削除して再作成すると、PTP 同期が不安定になるため、クロックジャンプが発生します。これにより、テストワークロードで時刻の同期が中断されます。時刻同期は、ワークロードが安定しているときに安定します。(RHEL-145136)
  • Red Hat Enterprise Linux (RHEL) 10 ストリームを使用する場合、これは 5.0 の新規インストールではデフォルトですが、4.22 からのアップグレードではデフォルトではありません。この場合、4KB 未満のメッセージのスループットは、RHEL 9 と比較して約 30-50% 低下します。リグレッションは、たとえば 64 バイトや 1KB といった小さなメッセージサイズで最も顕著に現れ、4KB 以上のメッセージサイズでは減少します。OCPBUGS-105469

  • 厳格な CPU 予約と、分離された CPU または 予約済み CPU を含むパフォーマンスプロファイルを適用すると、ワーカーノードがロックアップします。

    厳密な CPU 予約と 分離型 および 予約型 CPU を設定するパフォーマンスプロファイルを適用すると、ワーカーノードがロックアップして NotReady 状態になります。この問題は、ノードの再起動後に CPU マネージャーの状態ファイルが使用可能な CPU と一致しないために発生します。

    この問題を回避するには、CPU マネージャーの状態ファイルをクリアし、kubelet サービスを再起動してください。

    1. 影響を受けるノードでデバッグセッションを開始します。 

      $ oc debug node/<node_name>

    2. ルートディレクトリーを /host に変更します。 

      # chroot /host

    3. CPU マネージャーの状態ファイルを削除します。 

      # rm /var/lib/kubelet/cpu_manager_state

    4. kubelet サービスを再起動します。 

      # systemctl restart kubelet

      OCPBUGS-105469

  • 現在、Intel 710 ネットワークインターフェイスカード (NIC) 上で Single Root I/O Virtualization (SR-IOV)Virtual Function (VF) を使用する Pod では、削除時に遅延が発生する可能性があります。netdev ロックに関わるカーネルのリグレッションにより、VF の元の MAC アドレスを復元する際にデッドロックが発生します。その結果、Container Network Interface (CNI) のタイムアウトにより、影響を受ける Pod の削除に最大 90 秒かかる場合があります。OCPBUGS-105469
  • 現在、保証された サービス品質 (QoS) クラスを使用し、CPU 全体を要求する Pod は、ノードの再起動または kubelet の再起動後に自動的に再起動しない可能性があります。この問題は、静的な CPU マネージャーポリシーと full-pcpus-only 仕様を持つノードで発生する可能性があります。これは、ノード上のほとんど、あるいはすべての CPU がすでにそのようなワークロードによって割り当てられている場合に発生します。その結果、影響を受けた Pod は保留状態または失敗状態のままとなります。この問題を回避するには、影響を受ける Pod を手動で削除して再作成してください。OCPBUGS-105469

  • NUMA Resources Operator は、非均一メモリーアクセス (NUMA) に対応したスケジューリングのために、セカンダリースケジューラーを導入します。このスケジューラーでプリエンプションを有効にすると、古いノードリソーストポロジー (NRT) キャッシュによって余分な Pod 退避が発生する可能性があります。

    排他的リソースを要求する Pod が終了すると、スケジューラーはその Pod をノード上で実行中の Pod のリストから削除します。トポロジー更新器は非同期で実行されるため、終了を記録するのに数秒かかる場合があります。アップデーターが NRT キャッシュを更新するまで、スケジューラーは終了した Pod のリソースを予約済みとして扱い、この古いアカウンティング情報を次のスケジューリング決定に使用します。

    NUMA 対応スケジューラーは、Pod を配置できない場合にこの古いアカウンティングを使用し、優先度の低い Pod を削除することで十分なリソースが解放されるかどうかを確認します。優先度の低い Pod が実行されている場合、終了した Pod がすでにリソースを解放していても、スケジューラーはそれらの Pod を強制終了することができます。これらの退避は、トポロジー更新器が解放されたリソースで NRT キャッシュを更新するまで継続できます。

    この問題を回避するには、クラスター上で実行される Pod に対して、デプロイメント、ReplicaSet、DaemonSet などのコントローラーを使用してください。コントローラーは、追い出された Pod を再作成します。スケジューラーは、再作成された Pod を配置しない可能性があります。なぜなら、配置はスケジューリングキューにおける Pod の位置に依存するからです。

    OCPBUGS-105469

  • ノードリソーストポロジー (NRT) プラグインが古い NRT 情報のために拒否した Pod は、スケジューラーが NRT キャッシュを更新した後も保留状態のままになることがあります。

    Pod がスケジューリング不可キューにある間、スケジューラーは、リソースの可用性または割り当て可能なリソースを変更するノードイベントが発生した場合、またはスケジューリング不可タイムアウトが経過した場合にのみ、Pod の再試行を行います。デフォルトのタイムアウト時間は 60 分です。NRT プラグインが古い NRT 情報のために Pod を拒否した場合、NRT キャッシュを更新しても、これらのイベントは発生しません。Pod は、これらのイベントのいずれかが発生するまで、スケジュール不可能なキューに留まります。

    この問題を回避するには、スケジューラーが NRT キャッシュを更新した後、保留中の Pod を削除して再作成してください。ターゲットノード上で、保証された サービス品質 (QoS) クラスを使用し、少量のリソースを要求する Pod をスケジュールすることもできます。

    OCPBUGS-105469

  • NUMA 対応スケジューラーは優先度の高い Pod に対してプリエンプションを試みますが、ノードリソーストポロジー (NRT) キャッシュの更新によって、スケジューラーが優先度の低い Pod を追い出すのを止めることはできません。

    これらの試行中に、NRT キャッシュが更新され、優先度の高い Pod に十分な空きリソースがあることが示される可能性があります。その Pod のために、これ以上リソースを解放する必要はありません。キャッシュの更新は、プリエンプションの流れやスケジューリングサイクルを停止させません。その結果、スケジューラーは優先度の低い Pod を強制終了することができます。プリエンプション開始前にキャッシュが更新され、十分な空きリソースが示された場合、スケジューラーは追加のプリエンプション試行を行いません。

    この問題を回避するには、クラスター上で実行される Pod に対して、デプロイメント、ReplicaSet、DaemonSet などのコントローラーを使用してください。コントローラーは、追い出された Pod を再作成します。スケジューラーは、再作成された Pod を配置しない可能性があります。なぜなら、配置はスケジューリングキューにおける Pod の位置に依存するからです。

    OCPBUGS-105469

  • 現在、Single Root I/O Virtualization (SR-IOV)Virtual Function (VF) をボンドデバイスのポートとして使用することはできません。影響を受ける VF は、Intel i40e (710 シリーズ) または ice (E810 シリーズ) ネットワークインターフェイスカード (NIC) 上で動作します。カーネルのリグレッションにより、ボンディングに 2 つ目の VF を追加すると、set_mac_address 操作が失敗します。操作は、set_mac_address の呼び出し時にエラー -11 を返します (リソースが一時的に利用できません)。その結果、ボンディングデバイスはアクティブにならず、影響を受ける VF をボンディングに追加することはできません。この問題を回避するには、影響を受けるノード上で、i40e または ice VF をポートとして使用するボンディングデバイスを設定しないでください。(RHEL-145136)
  • 現在、ListenerSet カスタムリソース定義 (CRD) はクラスターにインストールされていますが、OpenShift Container Platform Gateway API の実装は ListenerSet リソースをサポートしていません。その結果、OpenShift Container Platform が管理する Gateway を対象とする ListenerSet は 調整されず、定義されたリスナーは Gateway にプログラムされず、トラフィックをルーティングしません。ListenerSet は、UnsupportedByController という理由で Accepted=False の ステータス状態を報告し、ListenerSetOnManagedGateway アラートが発生します。回避策として、ListenerSet を使用する代わりに、Gateway リソース上でリスナーを直接定義してください。OCPBUGS-105469
  • 現在、Red Hat Enterprise Linux CoreOS (RHCOS) バージョン 10 の VMware vSphere installer-provisioned infrastructure ノードで 、serial-getty@ttyS0 の 再起動ループが発生しています。この状態は、シリアルポートが存在しないために発生します。再起動ループにより、マウントテーブルが 継続的に変更され、それがすべてのノードで確認できます。長期間稼働するクラスターでは、これにより ノードエクスポーターの メモリー枯渇や制御プレーンの性能低下につながる可能性があります。OCPBUGS-105469
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

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

Legal Notice

Theme

© 2026 Red Hatトップに戻る