1.10. 既知の問題


このセクションでは、OpenShift Container Platform 4.22 に関する既知の問題点をいくつか紹介します。

  • 現在、NUMA Resources Operator (NRO) が提供する topo-aware-scheduler は、Kubernetes の優先度ベースのプリエンプションをサポートしていません。利用可能なノード上のすべての NUMA ゾーンが低優先度の Pod によって完全に消費されると、PreemptLowerPriority ポリシーを持つ高優先度の Pod は、低優先度の Pod をプリエンプトする代わりに、無期限に Pending 状態のままになります。その結果、スケジューリングの回復において優先度ベースのプリエンプションに依存するワークロードは、topo-aware-scheduler を使用すると正しく機能しません。(OCPBUGS-77930)
  • 現在、SR-IOV ネットワーク Virtual Function が設定されているクラスターでは、ネットワークデバイスの名前変更をするシステムサービスと、Node Tuning Operator によって管理される TuneD サービスの間で競合状態が発生する可能性があります。その結果、ノードの再起動後に TuneD プロファイルが劣化し、パフォーマンスの低下につながる可能性があります。回避策として、TuneD Pod を再起動してプロファイルの状態を復元します。(OCPBUGS-41934)
  • 現在、guaranteed QoS クラスを使用し、CPU 全体を要求する Pod は、ノードの再起動または kubelet の再起動後に自動的に再起動しない可能性があります。この問題は、静的 CPU Manager ポリシーが設定され、full-pcpus-only 仕様を使用しているノードで発生する可能性があるほか、ノード上の CPU のほとんどまたはすべてがこのようなワークロードによってすでに割り当てられている場合に発生する可能性があります。回避策として、影響を受ける Pod を手動で削除して再作成します。(OCPBUGS-43280)
  • 特定の AMD EPYC プロセッサーを使用するシステムでは、AMD-Vi などの一部の低レベルシステム割り込みにおいて、CPU マスク内の CPU が CPU 固定ワークロードと重複する場合があります。この動作はハードウェア設計に起因するものです。これらの特定のエラー報告割り込みは通常は非アクティブであり、現時点ではパフォーマンスへの影響は確認されていません。(OCPBUGS-57787)
  • 現在、非 RT カーネルで openshift-node-performance PerformanceProfile を適用すると、タイマー移行 (kernel.timer_migration) は有効になりません。その結果、TCP タイムアウトやキープアライブタイマーなどのカーネルタイマーが、レイテンシーに敏感なワークロードに割り当てられた CPU 上で停止したままになり、これらのワークロードに不要な中断を引き起こす可能性があります。回避策として、TuneD カスタムリソースを使用して kernel.timer_migration=1 sysctl パラメーターを設定することで、タイマー移行を有効にします。TuneD の設定に関する詳細は、パフォーマンスアドオンオペレーターの詳細設定を 参照してください。(OCPBUGS-86541)
  • OpenShift Container Platform は、スナップショットが存在するデータストアにアクセスできないトポロジードメインでのボリュームスナップショットの復元をサポートしていません。スナップショットを、そのスナップショットを含むリージョンとゾーンに復元する永続ボリューム要求 (PVC) を使用する Pod は、手動でスケジュールする必要があります。すべてのリージョンとゾーンで共有データストアを使用することで、この要件を満たすことができます。(OCPBUGS-84702)
  • Azure プライベート、パブリック Azure OpenShift Container Platform、プライベート Azure OpenShift Container Platform などの一部の Microsoft Azure 設定では、仮想マシンネットワークインターフェイスコントローラー (NIC) のプライマリー IP アドレスのバックエンドアドレスプールに接続されたアウトバウンドルールを介してアウトバウンド接続が実現されます。今回のアップデート以前は、OutBoundRule パラメーターが指定されていない場合、Egress IP アドレスがパブリックロードバランサーのバックエンドアドレスプールに追加されていました。OutBoundRule パラメーターの有無に関わらず、Azure 上でホストされている OpenShift Container Platform クラスターのパブリックロードバランサーバックエンドプールに、Egress IP アドレスは追加されなくなりました。その結果、Azure OpenShift Container Platform クラスター内のインフラストラクチャーサブネットを除き、Egress IP アドレスは送信接続を一切持ちません。(OCPBUGS-57447)
  • PTP プロファイルを切り替える際、以前に適用されていたプロファイルのメトリクスが正しくクリーンアップされない場合があります。この問題は、ネットワークインターフェイス (NIC) を変更する際に最も顕著に現れます。この問題を回避するには、Pod を再起動してメトリクスをクリーンアップしてください。(OCPBUGS-66413)
  • 現在、-p 0 設定では BGP (Border Gateway Protocol) デーモンがポート 179 でリッスンできず、マネージドルーティングモードのフルメッシュ iBGP (Interior Gateway Protocol) トポロジーが失敗します。この問題を解決するには、デフォルトネットワークでマネージドルーティングを無効にしてください。(OCPBUGS-84702)
  • オーバーレイ管理ルーティングモードを使用しないクラスターユーザー定義ネットワーク (CUDN) には、既知の問題があります。この設定では、outboundSNAT パラメーターを使用すると SYN パケットがドロップされるため、Pod とリモートノードの IP アドレスとの接続に問題が発生します。この問題は、ExternalTrafficPolicyCluster に設定されている NodePort サービスにアクセスする際の NodePort サービス、ホストネットワークの Pod、およびノード間トラフィックに影響します。現時点では回避策はありません。(OCPBUGS-79682)
  • ovn-kubernetes-control-plane サービスアカウント (SA) が、マネージドルーティングモードを有効にするために openshift-ovn-kubernetes 名前空間で必要な RouteAdvertisement CR を作成できないという既知の問題が存在します。そのため、この設定ではオーバーレイなしモードは機能しません。現時点では回避策はありません。(OCPBUGS-83406)
  • 今回のリリースでは、トランスポートモードを NoOverlay に設定した CUDN(クラスターユーザー定義ネットワーク) を作成する際に問題が発生する場合、カスタムリソース定義 (CRD) に必要な NoOverlay 設定フィールドが欠落していることが原因となっている可能性があります。この欠落によりネットワーク障害が発生し、CRD に NoOverlay フィールドが欠落しているため、東西方向のトラフィック経路に影響が出ます。この問題を解決するには、デフォルトのトランスポートモードを使用してください。(OCPBUGS-86761)
  • OpenShift Container Platform クラスター上でクラウドネイティブネットワーク機能 (CNF) のレイテンシーテストを実行すると、テスト結果がレイテンシーのしきい値を超える場合があります。たとえば、cyclictest テストでは 20 マイクロ秒を超える場合があります。これは、クラスターが低遅延ワークロード向けに正しく設定されている場合でも、断続的なテスト失敗を引き起こす可能性があります。回避策として、遅延スパイクの頻度と大きさを軽減するために、停止した バックエンドを sched_debug に戻してください。(OCPBUGS-86339)
  • Telecom Grandmaster (T-GM) PTP 設定における競合状態により、システム起動時に 37 秒のオフセットが発生する可能性があります。これは、ts2phc が GNSS 信号からハードウェアクロック (PHC) を同期する前に、phc2sys が システムクロックを同期してしまうために発生します。37 秒のずれは、現在の UTC と TAI のうるう秒の差に相当します。この問題は、PHC が GNSS 信号から適切に同期されると自動的に解決します。(OCPBUGS-85586)
  • cloud-event-proxy サイドカーが再起動した後、linuxptp-daemon からの古いリプレイデータが、イベントソケット上のライブデータと競合する可能性があります。これにより、ptp4l が 完全に LOCKED 状態に回復した後でも、openshift_ptp_clock_state メトリクスと集約 /master SyncStateChange クラウドイベントが FREERUN または HOLDOVER のままになることがあります。回避策として、linuxptp-daemon Pod を再起動してください。(OCPBUGS-85092)
  • Telecom Boundary Clock (T-BC) がホールドオーバー状態に入ると、event.sync.sync-status.synchronization-state-change イベントで HOLDOVER の代わりに FREERUN が報告される場合があります。これは、ノード全体の同期状態の計算における問題が原因です。回避策として、正しく計算される event.sync.ptp-status.ptp-state-change および event.sync.sync-status.os-clock-sync-state-change イベントから最悪の状態を使用してください。時計がホールドオーバー状態から抜け出すと、イベントは同期状態に戻ります。(OCPBUGS-86530)
  • BlueField-3 NIC を使用したテスト用ワークロードを削除して再作成すると、PTP 同期が不安定になるため、クロックジャンプが発生します。これにより、テストワークロードで時刻の同期が中断されます。時刻同期は、ワークロードが安定しているときに安定します。(RHEL-93579)
  • 現在、cert-manager がインストールされているクラスターでは、Extended Update Support (EUS) から EUS イメージベースのアップグレードはサポートされていません。(OCPBUGS-86967)
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

Legal Notice

Theme

© 2026 Red Hat
トップに戻る