Red Hat Summit1.8. 既知の問題
-
以前は、Google Cloud サービスアカウントのポリシーを設定しようとすると、API によって
400: Bad Request検証エラーが報告されていました。サービスアカウントを作成すると、アカウントがアクティブになるまでに最大 60 秒かかることがあり、これにより検証エラーが発生します。このエラーが発生した場合は、少なくとも 60 秒間続く真の指数バックオフを持つサービスアカウントを作成してください。(OCPBUGS-48187) -
最小限の権限を使用し、
install-config.yamlファイルで `controlPlane.platform.gcp.serviceAccount` を指定せずに、Google Cloud の共有仮想プライベートネットワーク (VPC) にクラスターをインストールすると、インストールが成功する場合があります。Kubernetes (K8s) のファイアウォールルールが共有 VPC に作成されますが、ホストプロジェクトに権限がないため、クラスターを破棄しても K8s のこれらのファイアウォールルールは削除されません。(OCPBUGS-38689) -
oc-mirror プラグイン v2 は現在、ミラーリングエラーが発生した場合でも、"success" を意味する終了ステータス
0を返します。そのため、自動化されたワークフローでは終了ステータスに依存できません。この問題が解決されるまで、oc-mirrorによって生成されたmirroring_errors_XXX_XXX.txtファイルでエラーを手動で確認してください。(OCPBUGS-49880) -
Red Hat Enterprise Linux CoreOS (RHCOS) イメージに含まれる DNF パッケージマネージャーは、実行時に使用できません。これは DNF が、Red Hat サブスクリプションに登録されたクラスター内の有資格ノードにアクセスするために追加のパッケージに依存しているためです。回避策として、代わりに
rpm-ostreeコマンドを使用します。(OCPBUGS-35247) - OpenShift Container Platform バージョン 4.18 には、インストール中に Nutanix クラスターの障害ドメインに複数のサブネットを設定できないという既知の問題があります。この問題に対する回避策はありません。(OCPBUGS-49885)
コントロールプレーンマシンセットを使用して既存の Nutanix クラスターに複数のサブネットを設定する場合、次の既知の問題が存在します。
-
subnetsスタンザ内の既存のサブネットの上にサブネットを追加すると、コントロールプレーンノードがDeleting状態のままになります。回避策として、subnetsスタンザ内の既存のサブネット配下にのみサブネットを追加します。 - サブネットを追加した後、更新されたコントロールプレーンマシンが Nutanix コンソールに表示されても、OpenShift Container Platform クラスターにアクセスできないことがあります。この問題に対する回避策はありません。
これらの問題は、サブネットが障害ドメインまたはプロバイダー仕様で指定されているかどうかに関係なく、サブネットを設定するためにコントロールプレーンマシンセットを使用するクラスターで発生します。(OCPBUGS-50904)
-
-
cgroupv1Linux コントロールグループ (cgroup) を使用する RHEL 8 ワーカーノードには既知の問題があります。影響を受けるノードに表示されるエラーメッセージの例として、UDN are not supported on the node ip-10-0-51-120.us-east-2.compute.internal as it uses cgroup v1があります。回避策として、ユーザーはワーカーノードをcgroupv1からcgroupv2に移行する必要があります。(OCPBUGS-49933) -
現在の 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) -
Google Cloud Platform (GCP) 上で実行されているクラスターのレイヤー 2 ネットワークトポロジーには既知の問題があります。現時点では、
UserDefinedNetwork(UDN) リソースによって作成されたレイヤー 2 ネットワークで使用されている Egress IP アドレスは、間違った送信元 IP アドレスを使用しています。その結果、GCP のレイヤー 2 で UDN はサポートされません。現在、この問題の修正方法はありません。(OCPBUGS-48301) - ユーザー定義ネットワーク (UDN) には、OVN-Kubernetes が管理していない 1000 以上のルーティングテーブル ID を削除するという既知の問題があります。その結果、OVN-Kubernetes の外部で作成された Virtual Routing and Forwarding (VRF) インスタンスはすべて削除されます。この問題は、テーブル ID が 1000 以上のユーザー定義 VRF を作成したユーザーに影響します。これらは OpenShift Container Platform 用に予約されているため、回避策としてユーザーは VRF を 1000 未満のテーブル ID に変更する必要があります。(OCPBUGS-50855)
OpenShift Container Platform 4.18 の一部としてインストールした OpenShift CLI (
oc) を使用して OpenShift Container Platform 4.17 サーバーにログインしようとすると、ターミナルに次の警告メッセージが表示されます。Warning: unknown field "metadata" You don't have any projects. You can try to create a new project, by running oc new-project <projectname>Warning: unknown field "metadata" You don't have any projects. You can try to create a new project, by running oc new-project <projectname>Copy to Clipboard Copied! Toggle word wrap Toggle overflow この警告メッセージは既知の問題ですが、OpenShift Container Platform の機能上の問題を示すものではありません。警告メッセージを無視しても問題はなく、OpenShift Container Platform も引き続き意図したとおり使用できます。(OCPBUGS-44833)
OpenShift Container Platform 4.18 には、
ovnkube-nodeデーモンセットが削除されるとクラスターのマスカレードサブネットが169.254.169.0/29に設定されるという既知の問題があります。マスカレードサブネットが169.254.169.0/29に設定されている場合、UserDefinedNetworkカスタムリソース (CR) を作成できません。注記-
Day 2 で
network.operatorCR を変更することでマスカレードサブネットが設定された場合、169.254.169.0/29には戻されません。 -
クラスターが OpenShift Container Platform 4.16 からアップグレードされている場合、下位互換性のためにマスカレードサブネットは
169.254.169.0/29のままになります。ユーザー定義ネットワーク機能を使用するには、マスカレードサブネットを、より多くの IP を持つサブネット (169.254.0.0/17など) に変更する必要があります。
この既知の問題は、次のいずれかのアクションを実行した後に発生します。
Expand アクション 結果 ovnkube-nodeDaemonSetオブジェクトを再起動したマスカレードサブネットが、
UserDefinedNetworkCR をサポートしない169.254.169.0/29に設定されます。ovnkube-nodeDaemonSetオブジェクトを削除したマスカレードサブネットが、
UserDefinedNetworkCR をサポートしない169.254.169.0/29に設定されます。さらに、ovnkube-nodePod がクラッシュし、CrashLoopBackOff状態のままになります。一時的な回避策として、次のコマンドを実行して
UserDefinedNetworkCR を削除し、すべてのovnkube-nodePod を再起動できます。oc delete pod -l app=ovnkube-node -n openshift-ovn-kubernetes
$ oc delete pod -l app=ovnkube-node -n openshift-ovn-kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow ovnkube-nodePod が自動的に再起動し、クラスターが再び安定します。次にマスカレードサブネットを、IPv4 の場合は169.254.0.0/17などのように、より大きな IP アドレスに設定できます。その結果、NetworkAttachmentDefinitionまたはUserDefinedNetworkCR を作成できます。重要ovnkube-nodePod を削除するときに、ovnkube-nodeDaemonSetオブジェクトを削除しないでください。そうすることで、マスカレードサブネットが169.254.169.0/29に設定されます。詳細は、Day 2 オペレーションとして OVN-Kubernetes マスカレードサブネットを設定する を参照してください。
-
Day 2 で
-
クラスターにノードを追加または削除すると、ノードのステータスをめぐる所有権の競合が発生する可能性があります。これにより、新しいノードが表示されるまでに長時間かかる可能性があります。回避策として、
openshift-kube-apiserver-operatornamespace でkube-apiserver-operatorPod を再起動して、プロセスを迅速化することができます。(OCPBUGS-50587) - RHOSP 上で実行されるデュアルスタックネットワーククラスターの場合、Floating IP (FIP) にアタッチされた仮想 IP (VIP) がマスターノード間で移動するときに、新しいマスターが別のコンピュートノードにあると、仮想 IP と FIP 間の関連付けが機能しなくなる可能性があります。この問題は、OVN が共有 Neutron ポート上の IPv4 アドレスと IPv6 アドレスの両方が同じノードに属していると想定するために発生します。(OCPBUGS-50599)
- ブート操作中に追加の Extensible Firmware Interface (EFI) エントリーを自動的に作成するシステムでは、PCR 1 および PCR 7 保護によるディスク暗号化が失敗します。この追加のエントリーによって EFI 変数が変更されるため、PCR 1 によるサーバー構成証明が阻止されます。(OCPBUGS-54593)
-
OpenShift Container Platform クラスターでクラウドネイティブネットワーク関数 (CNF) のレイテンシーテストを実行すると、テストのレイテンシーしきい値 (たとえば、
cyclictestテストの場合は 20 マイクロ秒) を超える結果が返されることがあります。その結果、テストは失敗します。(OCPBUGS-42328) -
グランドマスタークロック (T-GM) が
Locked状態に遷移するタイミングが早すぎる場合に発生する既知の問題があります。これは、Digital Phase-Locked Loop (DPLL) がLocked-HO-Acquired状態への移行を完了する前、Global Navigation Satellite Systems (GNSS) のタイムソースが復元された後に発生します。(OCPBUGS-49826)
Kubernetes の問題により、CPU マネージャーは、ノードに許可された最後の Pod から利用可能な CPU リソースのプールに CPU リソースを戻すことができません。これらのリソースは、後続の Pod がノードに許可された場合は、割り当てることができます。ただし、この Pod が最後の Pod になり、CPU マネージャーはこの Pod のリソースを使用可能なプールに戻すことができなくなります。
この問題は、CPU マネージャーが利用可能なプールに CPU を解放することに依存する CPU 負荷分散機能に影響します。その結果、保証されていない Pod は、少ない CPU 数で実行される可能性があります。回避策として、影響を受けるノードで
ベストエフォートの Quality of Service (QOS)を持つ Pod をスケジュールします。この Pod は最後に許可された Pod となり、これによりリソースが使用可能なプールに正しく解放されます。(OCPBUGS-46428)- Pod が、DHCP アドレス割り当てに他の CNI プラグインと組み合わせて CNI プラグインを使用すると、Pod のネットワークインターフェイスが予期せず削除される可能性があります。その結果、Pod の DHCP リースの有効期限が切れると、新しいリースの再作成時に DHCP プロキシーがループに入り、ノードが応答しなくなります。現在、回避策はありません。(OCPBUGS-45272)
- PXE ブートを使用して オンプレミスクラスターにワーカーノードを追加する と、ホストがディスクから適切に再起動できず、インストールが完了しないことがあります。回避策として、障害が発生したホストをディスクから手動で再起動する必要があります。(OCPBUGS-45116)
- GCP PD CSI ドライバーは、RWX モードのハイパーディスクバランスボリュームをサポートしていません。GCP PD CSI ドライバーを使用して RWX モードでハイパーディスクバランスボリュームをプロビジョニングしようとすると、エラーが発生し、目的のアクセスモードでボリュームがマウントされません。(OCPBUGS-44769)
- 現在、c3-standard-2、c3-standard-4、n4-standard-2、n4-standard-4 ノードが含まれる GCP PD クラスターは、アタッチ可能なディスクの最大数 (16 であるはず) を誤って超過する可能性があります。この問題により、ボリュームを Pod に正常に作成またはアタッチできない可能性があります。(OCPBUGS-39258)
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}