1.8. 既知の問題
-
libreswanの動作のリグレッションにより、IPsec が有効になっている一部のノードが、同じクラスター内の他のノード上の Pod との通信を失う原因となりました。この問題を解決するには、クラスターの IPsec を無効にすることを検討してください。(OCPBUGS-43715)
-
oc annotateコマンドは、等号 (=) が含まれる LDAP グループ名では機能しません。これは、コマンドがアノテーション名と値の間に等号を区切り文字として使用するためです。回避策として、oc patchまたはoc editを使用してアノテーションを追加します。(BZ#1917280) - Run Once Duration Override Operator (RODOO) は、Hypershift Operator によって管理されるクラスターにはインストールできません。(OCPBUGS-17533)
- シークレットまたはトップシークレットリージョンの AWS への OpenShift Container Platform 4.16 のインストールは、これらのリージョンの Network Load Balancers (NLBs) とセキュリティーグループの問題により失敗します。(OCPBUGS-33311)
-
OpenShift Container Platform クラスターで Cloud-native Network Functions (CNF) レイテンシーテストを実行すると、
oslatテストで 20 マイクロ秒を超える結果が返されることがあります。これにより、oslatテストが失敗します。(RHEL-9279) -
Local Zones を使用して Amazon Web Services (AWS) にクラスターをインストールする場合、エッジノードが
us-east-1-iah-2aリージョンにデプロイされていると、デプロイに失敗します。(OCPBUGS-35538) -
ACM バージョン 2.10.3 以前を使用して、Infrastructure Operator、Central Infrastructure Management、または ZTP 方式で OpenShift Container Platform 4.16 をインストールすることはできません。これは、動的にリンクされたインストーラーバイナリー
openshift-baremetal-installの変更によるもので、OpenShift Container Platform 4.16 では、これを正常に実行するには Red Hat Enterprise Linux (RHEL) 9 ホストが必要です。この問題を回避するために、ACM の今後のバージョンでは静的にリンクされたバイナリーを使用する予定です。(ACM-12405) - AWS にクラスターをインストールする場合、ロードバランサーの DNS の Time-To-Live (TTL) 値が非常に高いと、インストールがタイムアウトすることがあります。(OCPBUGS-35898)
-
br-exブリッジデバイスを保持するボンディングネットワークインターフェイスの場合、ノードネットワーク設定でmode=6 balance-albボンディングモードを設定しないでください。このボンドモードは OpenShift Container Platform ではサポートされていないため、Open vSwitch (OVS) ブリッジデバイスがネットワーク環境から切断される可能性があります。(OCPBUGS-34430)
-
プロキシーを使用すると、installer-provisioned クラスターをベアメタルにデプロイする操作が失敗します。リグレッションバグのため、ブートストラップ仮想マシンのサービスはプロキシー経由で IP アドレス
0.0.0.0にアクセスできません。回避策として、noProxyリストに0.0.0.0を追加します。詳細は、プロキシーの設定 を参照してください。(OCPBUGS-35818) -
複数の CIDR ブロックを含む VPC 内の Amazon Web Services (AWS) にクラスターをインストールする場合、マシンネットワークが
install-config.yamlファイルでデフォルト以外の CIDR ブロックを使用するように設定されていると、インストールは失敗します。(OCPBUGS-35054) - マルチパスが設定された IBM Power® 上の仮想 SCSI ストレージを備えた単一の VIOS ホストに、インストール後のアクティビティーとして OpenShift Container Platform 4.16 クラスターがインストールまたは設定されると、マルチパスが有効になっている CoreOS ノードが起動に失敗します。ノードに使用できるパスは 1 つだけなので、これは想定内の動作です。(OCPBUGS-32290)
- cgroupv2 で CPU 負荷分散を使用する場合、排他的 CPU にアクセスできる別の Pod がすでに存在すると、Pod の起動に失敗する可能性があります。これは、Pod が削除され、それを置き換えるために別の Pod がすぐに作成された場合に発生する可能性があります。回避策として、新しい Pod を作成する前に、古い Pod が完全に終了していることを確認してください。(OCPBUGS-34812)
-
512 エミュレーションディスクを使用するシステムで LUKS 暗号化を有効にすると、プロビジョニングが失敗し、システムは initramfs で緊急シェルを起動します。これは、パーティションを拡張するときに
sfdiskのアライメントバグが原因で発生します。回避策として、代わりに Ignition を使用してサイズ変更を実行できます。(OCPBUGS-35410) - OpenShift Container Platform バージョン 4.16 の切断されたインストールは、IBM Power® Virtual Server 上で失敗します。(OCPBUGS-36250)
OpenShift Container Platform の Hosted Control Plane で Ingress 機能 を無効にすると、Console Operator は次のエラーメッセージを返します。
RouteHealthAvailable: failed to GET route.
このエラーを回避するには、OpenShift Container Platform マネージドクラスターで
Ingress機能を無効にしないでください。(OCPBUGS-33788)-
クラスター上で IPsec が有効になっている場合、north-south IPsec 接続をホストしているノード上で、
ipsec.servicesystemd ユニットを再起動するか、ovn-ipsec-hostPod を再起動すると、IPsec 接続が失われます。(RHEL-26878)
-
現在の PTP グランドマスタークロック (T-GM) 実装には、バックアップ NMEA センテンスジェネレーターなしで GNSS から供給される単一の National Marine Electronics Association (NMEA) センテンスジェネレーターがあります。NMEA センテンスが e810 NIC に到達する前に失われた場合、T-GM はネットワーク同期チェーン内のデバイスを同期できず、PTP Operator はエラーを報告します。修正案は、NMEA 文字列が失われたときに
FREERUNイベントを報告することです。この制限が解決されるまで、T-GM は PTP クロックの holdover 状態をサポートしません。(OCPBUGS-19838)
- ワーカーノードの Topology Manager ポリシーが変更されると、NUMA 対応のセカンダリー Pod スケジューラーはこの変更を考慮しないため、誤ったスケジューリング決定や予期しないトポロジーアフィニティーエラーが発生する可能性があります。回避策として、NUMA 対応スケジューラー Pod を削除して、NUMA 対応スケジューラーを再起動します。(OCPBUGS-34583)
- NUMA Resources Operator をデプロイする予定の場合は、OpenShift Container Platform バージョン 4.17.7 または 4.17.8 を使用しないでください。(OCPBUGS-44644)
Kubernetes の問題により、CPU マネージャーは、ノードに許可された最後の Pod から利用可能な CPU リソースのプールに CPU リソースを戻すことができません。これらのリソースは、後続の Pod がノードに許可された場合は、割り当てることができます。ただし、この Pod が最後の Pod になり、CPU マネージャーはこの Pod のリソースを使用可能なプールに戻すことができなくなります。
この問題は、CPU マネージャーが利用可能なプールに CPU を解放することに依存する CPU 負荷分散機能に影響します。その結果、保証されていない Pod は、少ない CPU 数で実行される可能性があります。回避策として、影響を受けるノード上で
best-effortCPU マネージャーポリシーを使用して、Pod をスケジュールします。この Pod は最後に許可された Pod となり、これによりリソースが使用可能なプールに正しく解放されます。(OCPBUGS-17792)-
SriovNetworkNodePolicyリソースを適用した後、SR-IOV Network Operator の Webhook の調整中に CA 証明書が置き換えられる可能性があります。その結果、SR-IOV ネットワークノードポリシーを適用するときに、unknown authorityエラーが表示される場合があります。回避策として、失敗したポリシーを再度適用してみてください。(OCPBUGS-32139) -
vfio-pciドライバータイプを持つ Virtual Function のSriovNetworkNodePolicyリソースを削除すると、SR-IOV Network Operator はポリシーを調整できなくなります。その結果、sriov-device-pluginPod は継続的な再起動ループに入ります。回避策として、物理機能に影響する残りのポリシーをすべて削除してから、再作成します。(OCPBUGS-34934) - クローン作成の進行中にコントローラー Pod が終了した場合、Microsoft Azure ファイルクローンの永続ボリューム要求 (PVC) は保留状態のままになります。この問題を解決するには、影響を受けるクローン PVC をすべて削除してから、PVC を再作成します。(OCPBUGS-35977)
- Microsoft Azure では、azcopy (コピージョブを実行する基盤ツール) でログプルーニングが利用できないため、最終的にはコントローラー Pod のルートデバイスがいっぱいになる可能性があり、手動でクリーンアップする必要があります。(OCPBUGS-35980)
openshift-network-operatornamespace のConfigMapオブジェクトのmtuパラメーターが見つからない場合、制限付きライブマイグレーションメソッドは停止します。ほとんどの場合、
ConfigMapオブジェクトのmtuフィールドは、インストール中にmtu-proberジョブによって作成されます。ただし、クラスターが OpenShift Container Platform 4.4.4 などの以前のリリースからアップグレードされた場合、ConfigMapオブジェクトが存在しない可能性があります。一時的な回避策として、制限付きライブマイグレーションプロセスを開始する前に、
ConfigMapオブジェクトを手動で作成することができます。以下に例を示します。apiVersion: v1 kind: ConfigMap metadata: name: mtu namespace: openshift-network-operator data: mtu: "1500" 1- 1
mtu値は、ノードインターフェイスの MTU と一致する必要があります。
- ホストされたクラスターでは、API からの自己署名証明書を置き換えることはできません。(OCPSTRAT-1516)
-
高解像度タイマーに依存してスレッドをウェイクアップする低遅延アプリケーションでは、想定よりも長いウェイクアップ遅延が発生する可能性があります。予想されるウェイクアップレイテンシーは 20μs 未満ですが、
cyclictestツールを長時間実行すると、この時間を超えるレイテンシーが発生することがあります。テストの結果、99.99999% 以上のサンプルで、ウェイクアップ遅延が 20μs 未満であることが示されました。(OCPBUGS-34022)
