1.8. 既知の問題

OpenShift Container Platform 4.19 では、ネットワーク暗号化に IPsec を使用するクラスターで、Pod 間の接続が断続的に失われる可能性があります。これにより、特定のノード上の一部の Pod が他のノード上のサービスに到達できなくなり、接続タイムアウトが発生します。内部テストでは、120 ノード以下のクラスターではこの問題を再現できませんでした。この問題に対する回避策はありません。(OCPBUGS-55453)
メキシコ中部リージョン (mx-central-1) の AWS にインストールされている OpenShift Container Platform クラスターは、破棄できません。(OCPBUGS-56020)
Azure にクラスターをインストールするときに、compute.platform.azure.identity.type、controlplane.platform.azure.identity.type、または platform.azure.defaultMachinePlatform.identity.type フィールド値のいずれかを None に設定すると、クラスターは Azure Container Registry からイメージをプルできません。この問題は、ユーザーが割り当てたアイデンティティーを提供するか、アイデンティティーフィールドを空白のままにすることで回避できます。どちらの場合も、インストールプログラムはユーザーが割り当てたアイデンティティーを生成します。(OCPBUGS-56008)
以前は、kubelet は、定期的に Pod の状態をチェックし、通常のプローブ期間外で Readiness プローブを実行する syncPod メソッドで実行されたプローブを考慮していませんでした。このリリースにより、kubelet が readinessProbe 期間を誤って計算するバグが修正されました。ただし、Pod 作成者は、Readiness プローブが設定された Pod の Readiness レイテンシーが増加する可能性があることに気付く場合があります。この動作は、設定されたプローブに対してより正確です。詳細は、(OCPBUGS-50522) を参照してください。
グランドマスタークロック (T-GM) が Locked 状態に遷移するタイミングが早すぎる場合に発生する既知の問題があります。これは、Digital Phase-Locked Loop (DPLL) が Locked-HO-Acquired 状態への移行を完了する前、Global Navigation Satellite Systems (GNSS) のタイムソースが復元された後に発生します。(OCPBUGS-49826)
AWS にクラスターをインストールするときに、openshift-install create コマンドを実行する前に AWS 認証情報を設定しないと、インストールプログラムは失敗します。(OCPBUGS-56658)
must-gather ツールは、OpenShift Container Platform 4.14 からアップグレードされたクラスターの IPsec 情報を収集しません。この問題は、networks.operator.openshift.io cluster CR の ipsecConfig 設定に空のコンストラクト {} があるために発生します。空のコンストラクトは、OpenShift Container Platform のアップグレードされたバージョンに渡されます。この問題を回避するには、Cluster Network Operator (CNO) CR で次の ipsecConfig 設定を使用して、以下のコマンドを実行します。
```
oc patch networks.operator.openshift.io cluster --type=merge -p \
  '{
```
```
$ oc patch networks.operator.openshift.io cluster --type=merge -p \
  '{
  "spec":{
    "defaultNetwork":{
      "ovnKubernetesConfig":{
        "ipsecConfig":{
          "mode":"Full"
        }}}}}'
```
Copy to Clipboard Toggle word wrap
コマンドを実行すると、CNO は検査可能な must-gather ログを収集します。
(OCPBUGS-52367)
Gateway API と Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure プライベートクラスターには既知の問題があります。ゲートウェイにプロビジョニングされるロードバランサーは常に外部として設定されるため、エラーや予期しない動作が発生する可能性があります。
- AWS プライベートクラスターでは、ロードバランサーが pending 状態のままになり、Error syncing load balancer: failed to ensure load balancer: could not find any suitable subnets for creating the ELB というエラーを報告します。
- GCP および Azure プライベートクラスターでは、ロードバランサーは外部 IP アドレスを持つべきではないにもかかわらず、外部 IP アドレスを使用してプロビジョニングされます。
この問題に対して、サポートされている回避策はありません。(OCPBUGS-57440)

クラッシュが発生した場合、mlx5_core NIC ドライバーによってメモリー不足の問題が発生し、kdump は vmcore ファイルを /var/crash に保存しません。vmcore ファイルを保存するには、crashkernel 設定を使用して、kdump カーネル用に 1024 MB のメモリーを予約します。(OCPBUGS-54520、RHEL-90663)
第 4 世代 Intel Xeon プロセッサーには、既知のレイテンシーの問題があります。(OCPBUGS-42495)

現在、guaranteed QoS クラスを使用し、CPU 全体を要求する Pod は、ノードの再起動または kubelet の再起動後に自動的に再起動しない可能性があります。この問題は、静的 CPU Manager ポリシーが設定され、full-pcpus-only 仕様を使用しているノードで発生する可能性があるほか、ノード上の CPU のほとんどまたはすべてがこのようなワークロードによってすでに割り当てられている場合に発生する可能性があります。回避策として、影響を受ける Pod を手動で削除して再作成します。(OCPBUGS-43280)
現在、特定の AArch64 マシンで irqbalance サービスを実行すると、バッファーオーバーフローの問題によりサービスがクラッシュする可能性があります。その結果、レイテンシーの影響を受けやすいワークロードは、CPU 間で適切に分散されていない未管理の割り込みの影響を受け、パフォーマンスの低下を招く可能性があります。現在、この問題に対する回避策はありません。(RHEL-89986)
現在、SR-IOV ネットワーク Virtual Function が設定されているクラスターでは、ネットワークデバイスの名前変更をするシステムサービスと、Node Tuning Operator によって管理される TuneD サービスの間で競合状態が発生する可能性があります。その結果、ノードの再起動後に TuneD プロファイルが degraded 状態となり、パフォーマンスが低下する可能性があります。回避策として、TuneD Pod を再起動してプロファイルの状態を復元します。(OCPBUGS-41934)

RHEL-83435 により、VMware vSAN ファイルからエクスポートされる NFS ボリュームは、OpenShift Container Platform 4.19 を実行しているクラスターではマウントできません。この問題を回避するには、VMware ESXi および vSAN が 8.0 P05 以降の最新のパッチバージョンで実行されていることを確認してください。(OCPBUGS-55978)

トップに戻る

1.8. 既知の問題

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links