1.10. 既知の問題

このセクションでは、OpenShift Container Platform 4.21 におけるいくつかの既知の問題について説明します。

現在、既知の問題のため、Cluster Resource Override Operator および DPU Operator の OpenShift Container Platform 4.21 バージョンは、今後の 4.21 メンテナンスリリースで提供される予定です。(OCPBUGS-74224)
oc adm release mirror コマンドを使用して OpenShift Container Platform のリリースイメージを非接続環境のレジストリーにミラーリングした場合、リリースイメージの Sigstore 署名はイメージとともにミラーリングされません。
openshift クラスターイメージポリシーがデフォルトでクラスターにデプロイされるようになったため、これは OpenShift Container Platform 4.21 で問題となっています。このポリシーにより、CRI-O はイメージをクラスターにプルする際に、Sigstore の署名を自動的に検証します。(OCPBUGS-70297)
Sigstore 署名がない場合、非接続環境で OpenShift Container Platform 4.21 にアップデートした後、今後の Cluster Version Operator の Pod が実行に失敗する可能性があります。この問題は、oc-mirror プラグイン v2 をインストールし、oc mirror コマンドを使用して OpenShift Container Platform のリリースイメージをミラーリングすることで回避できます。oc-mirror プラグイン v2 は、リリースイメージとその Sigstore 署名の両方をミラーレジストリーから非接続環境にミラーリングします。
oc-mirror プラグイン v2 を使用できない場合は、次のように oc image mirror コマンドを使用 Sigstore 署名をミラーレジストリーにミラーリングできます。
```
$ oc image mirror "quay.io/openshift-release-dev/ocp-release:${RELEASE_DIGEST}.sig" "${LOCAL_REGISTRY}/${LOCAL_RELEASE_IMAGES_REPOSITORY}:${RELEASE_DIGEST}.sig"
```
各項目の説明:
RELEASE_DIGEST
ダイジェストイメージの : 文字を - 文字に置き換えたものを指定します。たとえば、sha256:884e1ff5effeaa04467fab9725900e7f0ed1daa89a7734644f14783014cebdee は sha256-884e1ff5effeaa04467fab9725900e7f0ed1daa89a7734644f14783014cebdee.sig になります。
oc-mirror v2 プラグインの詳細は、oc-mirror プラグイン v2 を使用した非接続インストールのイメージのミラーリング を参照してください。
OpenShift Container Platform 4.21 以降、コンテナーのデフォルトの最大オープンファイル数に対するソフトリミットが引き下げられました。その結果、エンドユーザーがアプリケーションの障害を経験する可能性があります。この問題を回避するには、ulimit コマンドなどの任意の方法を使用して、コンテナーランタイム (CRI-O) の ulimit 設定を増やします。OpenShift Container Platform 4.20 から 4.21 にクラスターをアップグレードする場合、既存の最大オープンファイル数の制限は維持されることに注意してください。(OCPBUGS-62095)
現在、SR-IOV ネットワーク Virtual Function が設定されているクラスターでは、ネットワークデバイスの名前変更をするシステムサービスと、Node Tuning Operator によって管理される TuneD サービスの間で競合状態が発生する可能性があります。その結果、ノードの再起動後に TuneD プロファイルが degraded 状態となり、パフォーマンスが低下する可能性があります。回避策として、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)。
このリリースでは、ベアメタルホストの Day 2 ファームウェアアップデートと BIOS 属性再設定の一般提供が開始されていますが、Bare Metal Operator (BMO) には、一度開始されたファームウェアアップデート要求をキャンセルするネイティブなメカニズムは提供されていません。HostFirmwareComponents または HostFirmwareSettings リソースのファームウェア更新や設定変更が失敗した場合、エラーが返された場合、または処理が永久に停止した場合は、以下の手順で復旧を試みてください。
- HostFirmwareComponents および HostFirmwareSettings リソースへの変更を削除します。
- ノードを online: false に設定して再起動をトリガーします。
- 問題が解決しない場合は、Ironic Pod を削除します。
サービスの運用を中断するためのネイティブな機能は、今後のリリースで計画される可能性があります。
AWS クラスター内の gp3 ストレージボリュームの最大スループットを設定する機能に既知の問題があります。この機能は、コントロールプレーンのマシンセットでは動作しません。この問題に対する回避策はありませんが、4.21.1 で修正されました。(OCPBUGS-74478)
user-provisioned DNS を使用するプロキシーの背後にある Google Cloud 上にプライベートクラスターをインストールする場合、ブートストラップが完了しなかったこと、またはクラスターの初期化に失敗したことを示すインストールエラーが発生する可能性があります。いずれの場合も、インストールは成功し、正常なクラスターが構築されます。回避策として、デプロイするクラスターと同じ仮想プライベートクラウド (VPC) 内にある踏み台ホストにプライベートクラスターをインストールします。(OCPBUGS-54901)
現在、NUMA Resources Operator (NRO) が提供する topo-aware-scheduler は、Kubernetes の優先度ベースのプリエンプションをサポートしていません。利用可能なノード上のすべての NUMA ゾーンが低優先度の Pod によって完全に消費されると、PreemptLowerPriority ポリシーを持つ高優先度の Pod は、低優先度の Pod をプリエンプトする代わりに、無期限に Pending 状態のままになります。その結果、スケジューリングの回復において優先度ベースのプリエンプションに依存するワークロードは、topo-aware-scheduler を使用すると正しく機能しません。(OCPBUGS-77930)

1.10. 既知の問題

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links