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)
-
現在、
guaranteedQoS クラスを使用し、CPU 全体を要求する Pod は、ノードの再起動または kubelet の再起動後に自動的に再起動しない可能性があります。この問題は、静的 CPU Manager ポリシーが設定され、full-pcpus-only仕様を使用しているノードで発生する可能性があるほか、ノード上の CPU のほとんどまたはすべてがこのようなワークロードによってすでに割り当てられている場合に発生する可能性があります。回避策として、影響を受ける Pod を手動で削除して再作成します。(OCPBUGS-43280) -
特定の AMD EPYC プロセッサーを使用するシステムでは、
AMD-Viなどの一部の低レベルシステム割り込みにおいて、CPU マスク内の CPU が CPU 固定ワークロードと重複する場合があります。この動作はハードウェア設計に起因するものです。これらの特定のエラー報告割り込みは通常は非アクティブであり、現時点ではパフォーマンスへの影響は確認されていません。(OCPBUGS-57787) -
現在、非 RT カーネルで
openshift-node-performancePerformanceProfile を適用すると、タイマー移行 (kernel.timer_migration) は有効になりません。その結果、TCP タイムアウトやキープアライブタイマーなどのカーネルタイマーが、レイテンシーに敏感なワークロードに割り当てられた CPU 上で停止したままになり、これらのワークロードに不要な中断を引き起こす可能性があります。回避策として、TuneD カスタムリソースを使用してkernel.timer_migration=1sysctlパラメーターを設定することで、タイマー移行を有効にします。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 アドレスとの接続に問題が発生します。この問題は、ExternalTrafficPolicyがClusterに設定されているNodePortサービスにアクセスする際のNodePortサービス、ホストネットワークの Pod、およびノード間トラフィックに影響します。現時点では回避策はありません。(OCPBUGS-79682) -
ovn-kubernetes-control-planeサービスアカウント (SA) が、マネージドルーティングモードを有効にするためにopenshift-ovn-kubernetes名前空間で必要なRouteAdvertisementCR を作成できないという既知の問題が存在します。そのため、この設定ではオーバーレイなしモードは機能しません。現時点では回避策はありません。(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メトリクスと集約/masterSyncStateChange クラウドイベントが FREERUN または HOLDOVER のままになることがあります。回避策として、linuxptp-daemonPod を再起動してください。(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)