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

1.8. 既知の問題

  • Gateway API と Amazon Web Services (AWS)、Google Cloud、Microsoft Azure プライベートクラスターには既知の問題があります。ゲートウェイにプロビジョニングされるロードバランサーは常に外部として設定されるため、エラーや予期しない動作が発生する可能性があります。

    • AWS プライベートクラスターでは、ロードバランサーが pending 状態のままになり、Error syncing load balancer: failed to ensure load balancer: could not find any suitable subnets for creating the ELB というエラーを報告します。
    • Google Cloud および Azure プライベートクラスターでは、ロードバランサーは外部 IP アドレスを持つべきではないにもかかわらず、外部 IP アドレス付きでプロビジョニングされます。

    この問題に対して、サポートされている回避策はありません。(OCPBUGS-57440)

  • 隔離されたユーザー名前空間で Pod を実行すると、Pod コンテナー内の UID/GID がホスト上の UID/GID と一致しなくなります。ファイルシステムの所有権が正しく機能するように、Linux カーネルは ID-mapped マウントを使用します。ID マップマウントは、仮想ファイルシステム (VFS) レイヤーにおいて、コンテナーとホスト間でユーザー ID を変換するものです。

    ただし、ネットワークファイルシステム (NFS) やその他のネットワークファイルシステムまたは分散ファイルシステムなど、すべてのファイルシステムが ID-mapped マウントをサポートしているわけではありません。このようなファイルシステムは ID-mapped マウントをサポートしていないため、ユーザー名前空間内で実行されている Pod は、マウントされた NFS ボリュームにアクセスできない可能性があります。この動作は OpenShift Container Platform に固有のものではありません。これは、Kubernetes v1.33 以降のすべての Kubernetes ディストリビューションに適用されます。

    OpenShift Container Platform 4.20 にアップグレードする場合、ユーザー名前空間をオプトインするまでクラスターは影響を受けません。ユーザー名前空間を有効にした後、ID-mapped マウントをサポートしていないベンダーが提供する、NFS を基盤とした永続ボリュームを使用している Pod が、ユーザー名前空間で実行される際に、アクセスや権限の問題が発生する可能性があります。ユーザー名前空間の有効化に関する詳細は、Linux ユーザー名前空間のサポートの設定 を参照してください。

    注記

    既存の OpenShift Container Platform 4.19 クラスターは、ユーザー名前空間を明示的に有効にするまで影響を受けません。これは OpenShift Container Platform 4.19 のテクノロジープレビュー機能です。

  • Azure にクラスターをインストールするときに、compute.platform.azure.identity.type、controlplane.platform.azure.identity.type、または platform.azure.defaultMachinePlatform.identity.type フィールド値のいずれかを None に設定すると、クラスターは Azure Container Registry からイメージをプルできません。この問題は、ユーザーが割り当てたアイデンティティーを提供するか、アイデンティティーフィールドを空白のままにすることで回避できます。どちらの場合も、インストールプログラムはユーザーが割り当てたアイデンティティーを生成します。(OCPBUGS-56008)
  • コンソールの統合ソフトウェアカタログビューには既知の問題があります。Ecosystem Software Catalog を選択した場合に、ソフトウェアカタログを表示するには、既存のプロジェクト名を入力するか、新しいプロジェクトを作成する必要があります。プロジェクト選択フィールドは、クラスターへのカタログコンテンツのインストール方法には影響しません。回避策として、任意の既存のプロジェクト名を入力してソフトウェアカタログを表示します。(OCPBUGS-61870)
  • BlueField-3 NIC を使用したテスト用ワークロードを削除して再作成すると、PTP 同期が不安定になるため、クロックジャンプが発生します。これにより、テストワークロードで時刻の同期が中断されます。時刻同期は、ワークロードが安定しているときに安定します。(RHEL-93579)
  • GNR-D インターフェイスのイベントログは、同一の 3 文字の接頭辞 ("eno") によりあいまいです。その結果、状態変更時に、影響を受けるインターフェイスが明確に特定されません。この問題を回避するには、ptp-operator が使用するインターフェイスを "path" 命名規則に従うように変更してください。これにより、インターフェイス名に基づいてクロックごとのイベントが正しく特定され、状態変更によってどのクロックが影響を受けるかが明確に示されるようになります。詳細は、ネットワークインターフェイスの命名ポリシー を参照してください。(OCPBUGS-62817)
  • Telecom Time Synchronous Clock (T-TSC) 設定を使用すると、ts2phc メトリクスが "locked" ではなく "unlocked" を報告します。その結果、Precision Time Protocol (PTP) クロックの状態レポートが不正確になる可能性があります。この問題を回避するには、ts2phc メトリクスを削除します。(OCPBUGS-63158)
  • Dell XR8620 で iDRAC ファームウェアを更新すると、OS と iDRAC の再起動の干渉により、サーバーに障害が発生する可能性があります。これによりサービスが中断される可能性があります。この問題を回避するには、OpenShift を介さずに、サーバーの iDRAC ファームウェアを更新します。(OCPBUGS-60876)
  • Gateway API をサポートする istiod コンポーネントは、以前に OpenShift Service Mesh (OSSM) によって監視されているすべての名前空間に istio-ca-root-cert ConfigMap を作成しました。OSSM 3.0.1(OpenShift Container Platform 4.20 の一部) には、この動作を制限する修正が含まれており、ConfigMap は Gateway API リソースを含む名前空間にのみ作成されるようになっています。ただし、この修正では、ゲートウェイを含まない名前空間から既存の ConfigMap を自動的にクリーンアップすることはできません。その結果、アップグレード後もクラスター内に多数の不要な istio-ca-root-cert ConfigMap が残る可能性があります。これらの追加の ConfigMap は無害であり、安全に無視できます。または、ゲートウェイをホストしていない名前空間から手動で削除することもできます。(OCPBUGS-43093)
  • 2 つ以上の異なる ゲートウェイ リソースで同じホスト名が指定されている場合、システムは競合を報告しません。上流のゲートウェイ API 仕様では、各 ゲートウェイを 個別の独立したプロキシーとして扱います。これは、上流のゲートウェイ API 仕様で意図された動作です。クラスターはこの設定を妨げません。特定のゲートウェイへのトラフィックのルーティングは、ホスト名の DNS レコードで使用されるゲートウェイのサービス IP アドレスなど、外部設定によって決定されます。(NE-2180)
  • Gateway API は、ベアメタル、vSphere、Nutanix、KubeVirt、およびプラットフォームタイプが None の クラスターを含むオンプレミスプラットフォームではサポートされていません。Gateway API の実装は 、LoadBalancer タイプ のサービスを自動的に作成します。オンプレミスプラットフォームには、このサービスに外部 IP アドレスを割り当てるためのデフォルトのクラウドコントローラーマネージャーやその他のプロビジョナーがありません。その結果、ゲートウェイ リソースは承認済みとしてマークされることはなく、クラスター外部からはアクセスできない状態が続きます。(OCPBUGS-37385)
  • Kubernetes Service で appProtocol フィールドが明示的に定義されていない場合、Gateway API の実装は Service ポート名からネットワークプロトコルを推測します。たとえば、https-web という名前のポートは、HTTPS プロトコルを使用しているものとして解釈されます。ポート名がアプリケーションで実際に使用されているプロトコルと一致しない場合、この推論によって予期しないトラフィック動作や接続障害が発生する可能性があります。この問題を回避するには、サービス リソースで appProtocol フィールドを明示的に定義するか、ポート名が使用されているプロトコルと厳密に一致するようにしてください。(OSSM-7231)
  • Gateway API のリバースプロキシー実装 (Istio と Envoy に基づく) は、現状ではデフォルトの HAProxy ベースの Ingress Controller と比較してパフォーマンスが低いことが示されています。HAProxy は、長年にわたるリリースを通じて、OpenShift Container Platform 向けに徹底的に最適化されてきました。そのため、ユーザーは標準の OpenShift ルートと比較して、Gateway API を使用した場合にレイテンシーが高くなったり、スループットが低下したりする可能性があります。Gateway API の実装におけるパフォーマンス最適化は現在も進行中です。(OSSM-6842)
  • ゲートウェイ API の実装を提供する OpenShift Service Mesh (OSSM)3.x は、サポートされている移行プロセス中を除き、同じクラスター上で OSSM 2.x と共存することはできません。通常の運用において両方のバージョンを同時にインストールすることはサポートされておらず、リソースの競合が発生する可能性があります。たとえば、Ingress Operator が パフォーマンス低下を 報告する場合があります。さらに、Network Observability Operator (NID) は OSSM 2.x をサポートしなくなりました。継続的なサポートと互換性を確保するため、OSSM 3.x の使用を推奨します。ユーザーは、クラスター用に単一のサービスメッシュバージョンを選択するか、2.x から 3.x に移行する場合は公式の移行手順に従う必要があります。(OSSM-5407)
  • 現在のゲートウェイ API の実装では、サービスの自動アイドル状態への移行はサポートされていません。標準の OpenShift Routes は、使用されていないときにサービスをアイドル状態にしてリソースを節約できますが、Gateway API によって管理されるワークロードは、トラフィックの非アクティブ状態に基づいて自動的にゼロにスケールダウンしたり、アイドル状態になったりすることはありません。
  • Gateway API の実装は現在、OpenShift Container Platform の Web コンソールおよび OpenShift CLI (oc) との専用の統合が欠けています。そのため、Gateway、GatewayClass、HTTPRoute などの Gateway API リソースは、特定のコンソールダッシュボードやビューには表示されません。これらのリソースを管理するには、ユーザーは標準の oc コマンド (例: oc get gateway または oc edit httproute) を使用し、YAML マニフェストを使用して設定を適用する必要があります。
  • 現在のゲートウェイ API の実装では、ユーザーが Istio または Envoy の高度なオプションを設定するためのメカニズムは提供されていません。具体的には、アクセスログの設定や低レベルのプロキシー設定の調整といった機能は公開されていません。ユーザーは、ゲートウェイ API コントローラーが提供するデフォルト設定に頼らなければなりません。
  • 現在のゲートウェイ API の実装では、クラスターユーザー定義ネットワーク (CUDN) はサポートされていません。ゲートウェイ API リソースは、デフォルトのクラスターネットワークでのみ使用可能であり、ユーザー定義のセカンダリーネットワークに接続することはできません。
  • Gateway API 実装の HTTPRoute リソースは、現在、パススルー または 再暗号化 TLS 終端ストラテジーをサポートしていません。柔軟な終端オプションを提供する標準の OpenShift Routes とは異なり、HTTPRoute は 現在、エッジ終端 (ゲートウェイでの TLS 終端) のみをサポートしています。パススルー機能 または 再暗号化 機能を必要とするユーザーは、現在、HTTPRoute リソースを使用してこれを実現することはできません。
  • AWS にクラスターをインストールする場合、openshift-install create コマンドを実行する前に AWS 認証情報を設定しないと、インストールプログラムは失敗します。(OCPBUGS-56658)
  • 特定の AMD EPYC プロセッサーを使用するシステムでは、AMD-Vi などの一部の低レベルシステム割り込みが、その CPU マスク内に、CPU にピン留めされたワークロードと重複する CPU を含んでしまう可能性があります。この動作はハードウェアの設計によるものです。これらの特定のエラーレポート割り込みは通常は非アクティブであり、現時点で既知のパフォーマンスへの影響はありません (OCPBUGS-57787)。
  • 現在、guaranteed QoS クラスを使用し、CPU 全体を要求する Pod は、ノードの再起動または kubelet の再起動後に自動的に再起動しない可能性があります。この問題は、静的 CPU Manager ポリシーが設定され、full-pcpus-only 仕様を使用しているノードで発生する可能性があるほか、ノード上の CPU のほとんどまたはすべてがこのようなワークロードによってすでに割り当てられている場合に発生する可能性があります。回避策として、影響を受ける Pod を手動で削除して再作成します。(OCPBUGS-43280)
  • アーカイブに、接尾辞 nodes で終わるカスタム namespace ディレクトリーが含まれている場合、Performance Profile Creator ツールは must-gather アーカイブの分析に失敗します。この失敗は、ツールの検索ロジックによって、複数の一致に対して誤ってエラーが報告されるために発生します。回避策として、カスタム namespace ディレクトリーの名前を nodes 接尾辞で終わらないように変更し、ツールを再度実行します。(OCPBUGS-60218)
  • 現在、SR-IOV ネットワーク Virtual Function が設定されているクラスターでは、ネットワークデバイスの名前変更をするシステムサービスと、Node Tuning Operator によって管理される TuneD サービスの間で競合状態が発生する可能性があります。その結果、ノードの再起動後に TuneD プロファイルが degraded 状態となり、パフォーマンスが低下する可能性があります。回避策として、TuneD Pod を再起動してプロファイルの状態を復元します。(OCPBUGS-41934)
  • 現在、既知のレイテンシーの問題は 4th Gen Intel Xeon プロセッサーで実行されているシステムに影響します。(OCPBUGS-46528)
  • 仮想メディアイメージが IPv6 アドレスを介して提供される場合、SuperMicro ARS-111GL-NHR サーバーは、起動時に仮想メディアにアクセスできません。その結果、IPv6 ネットワーク設定の SuperMicro ARS-111GL-NHR サーバーモデルでは、仮想メディアを使用できなくなります。(OCPBUGS-60070)
  • Hewlett Packard Enterprise (HPE) DL110G11 サーバーおよび類似モデルのファームウェア更新は、'NetworkAdapters' リソースの実装方法に起因する、このハードウェア固有のバグのために失敗する可能性があります。更新中に利用できなくなり、更新が失敗することがあります。この問題を回避するには、サービスの中断を避けるために、Ironic の外部でベースボード管理コントローラー (BMC) ファームウェアを手動で更新します。(OCPBUGS-60708)
  • SuperMicro ARS-111GL-NHR サーバーが仮想メディアではなく既存のハードドライブから起動するため、特定の BMC ファームウェアバージョンでは、Baremetalhost オブジェクトを正しい operating system で起動しようとすると繰り返し失敗します。この問題は、更新後の BIOS とベアメタルホストファームウェアによって発生し、USB CD は動作するものの CD はサポートされなくなります。その結果、ノード検査は失敗します。影響を受ける場合は、この問題を回避するために、BootSourceOverrideTarget を CD ではなく USB CD に手動で設定し、正しい仮想メディアからノードを起動します。(OCPBUGS-61851)
  • Dell サーバーの BMC ファームウェアを更新すると、Redfish API が一時的に中断されます。これにより接続障害が発生し、Ironic が更新を失敗としてマークする可能性があります。この問題を回避するには、サービスが中断されないように、Ironic の外部で BMC ファームウェアを手動で更新します。(OCPBUGS-61871)
  • Dell R740 で BIOS と BMC ファームウェアの同時更新を試みると、BMC の更新が失敗し、サーバーの電源がオフになり、応答しなくなる可能性があります。この問題は、更新プロセスが正常に完了せず、システムが動作しない状態のままになる場合に発生します。(OCPBUGS-62009)
  • 誤ったネットワーク共有の場所や無効な認証情報を使用してサーバーを設定すると、BMC ファームウェアの更新が失敗する可能性があります。これにより、サーバーの電源がオフのままになり、回復できなくなります。(OCPBUGS-62010)
  • クロックデグレードロジックのバグにより、アップストリームクロック接続が失われた際に、すべてのクロック状態メトリクスのデグレードがトリガーされません。その結果、'ptp4l' および 'ts2phc' のクロック状態メトリクスが、'unlocked' 状態へデグレードした後も、期待どおりにデグレードしない可能性があります。これにより、時刻同期状態の報告に不整合が発生する可能性があります。この問題を回避するには、'dpll' および 'T-BC' のクロック状態メトリクスのみを信頼し、'ptp4l' および 'ts2phc' のメトリクスは無視してください。(OCPBUGS-62719)
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hatトップに戻る