1.8. 既知の問題
-
oc annotate
コマンドは、等号 (=
) が含まれる LDAP グループ名では機能しません。これは、コマンドがアノテーション名と値の間に等号を区切り文字として使用するためです。回避策として、oc patch
またはoc edit
を使用してアノテーションを追加します。(BZ#1917280) - 静的 IP アドレス (テクノロジープレビュー) を使用して VMware vSphere にクラスターをインストールする場合、インストールプログラムがコントロールプレーンマシンセット (CPMS) に誤った設定を適用する可能性があります。これにより、静的 IP アドレスが定義されていないコントロールプレーンマシンが再作成される可能性があります。(OCPBUGS-28236)
- Azure クラスターをインストールする場合、標準の Ebdsv5 または Ebsv5 ファミリーマシンタイプインスタンスの指定はサポートされていません。この制限は、Azure terraform プロバイダーがこれらのマシンタイプをサポートしていないために発生します。(OCPBUGS-18690)
-
FIPS を有効にしてクラスターを実行している場合、RHEL 9 システムで OpenShift CLI (
oc
) を実行すると、FIPS mode is enabled, but the required OpenSSL backend is unavailable
というエラーが発生する場合があります。回避策として、OpenShift Container Platform クラスターで提供されるoc
バイナリーを使用します。(OCPBUGS-23386) -
Red Hat OpenStack Platform (RHOSP) 環境で IPv6 ネットワークが実行されている 4.15 では、
endpointPublishingStrategy.type=LoadBalancerService
YAML 属性で設定されたIngressController
オブジェクトが正しく機能しません。(BZ#2263550、BZ#2263552) -
Red Hat OpenStack Platform (RHOSP) 環境で IPv6 ネットワークが実行されている 4.15 では、IPv6
ovn-octavia
ロードバランサーで作成されたヘルスモニターが正しく機能しません。(OCPBUGS-29603) - Red Hat OpenStack Platform (RHOSP) 環境で IPv6 ネットワーキングが実行されている 4.15 では、IPv6 ロードバランサーをクラスターの内部として誤ってマークする問題のため、IPv6 ロードバランサーを複数のサービスと共有することはできません。(OCPBUGS-29605)
静的 IP アドレス指定と Tang 暗号化を使用して OpenShift Container Platform クラスターをインストールする場合、ノードはネットワーク設定なしで起動します。この状況により、ノードは Tang サーバーにアクセスできなくなり、インストールが失敗します。この状況に対処するには、各ノードのネットワーク設定を
ip
インストーラー引数として設定する必要があります。インストーラーでプロビジョニングされるインフラストラクチャーの場合、インストール前に次の手順を実行して、各ノードの
IP
インストーラー引数としてネットワーク設定を指定します。- マニフェストを作成します。
各ノードについて、アノテーションを使用して
BareMetalHost
カスタムリソースを変更し、ネットワーク設定を含めます。以下に例を示します。$ cd ~/clusterconfigs/openshift $ vim openshift-worker-0.yaml
apiVersion: metal3.io/v1alpha1 kind: BareMetalHost metadata: annotations: bmac.agent-install.openshift.io/installer-args: '["--append-karg", "ip=<static_ip>::<gateway>:<netmask>:<hostname_1>:<interface>:none", "--save-partindex", "1", "-n"]' 1 2 3 4 5 inspect.metal3.io: disabled bmac.agent-install.openshift.io/hostname: <fqdn> 6 bmac.agent-install.openshift.io/role: <role> 7 generation: 1 name: openshift-worker-0 namespace: mynamespace spec: automatedCleaningMode: disabled bmc: address: idrac-virtualmedia://<bmc_ip>/redfish/v1/Systems/System.Embedded.1 8 credentialsName: bmc-secret-openshift-worker-0 disableCertificateVerification: true bootMACAddress: 94:6D:AE:AB:EE:E8 bootMode: "UEFI" rootDeviceHints: deviceName: /dev/sda
ip
設定については、次のように置き換えます。- 1
<static_ip>
は、ノードの静的 IP アドレスに置き換えます (例:192.168.1.100
)- 2
<gateway>
は、ネットワークのゲートウェイの IP アドレスに置き換えます (例:192.168.1.1
)- 3
<netmask>
は、ネットワークマスクに置き換えます (例:255.255.255.0
)- 4
<hostname_1>
は、ノードのホスト名に置き換えます (例:node1.example.com
)- 5
<interface>
は、ネットワークインターフェイスの名前に置き換えます (例:eth0
)- 6
<fqdn>
は、ノードの完全修飾ドメイン名に置き換えます。- 7
<role>
は、ノードのロールを反映するworker
またはmaster
に置き換えます。- 8
<bmc_ip>
は、必要に応じて BMC IP アドレス、BMC のプロトコルとパスに置き換えます。
-
ファイルを
clusterconfigs/openshift
ディレクトリーに保存します。 - クラスターを作成します。
Assisted Installer を使用してインストールする場合は、インストール前に API を使用して各ノードのインストーラー引数を変更し、ネットワーク設定を
IP
インストーラー引数として追加します。以下に例を示します。$ curl https://api.openshift.com/api/assisted-install/v2/infra-envs/${infra_env_id}/hosts/${host_id}/installer-args \ -X PATCH \ -H "Authorization: Bearer ${API_TOKEN}" \ -H "Content-Type: application/json" \ -d ' { "args": [ "--append-karg", "ip=<static_ip>::<gateway>:<netmask>:<hostname_1>:<interface>:none", 1 2 3 4 5 "--save-partindex", "1", "-n" ] } ' | jq
以前のネットワーク設定の場合は、次のように置き換えます。
詳細とサポートについては、Red Hat Support チームにお問い合わせください。
OpenShift Container Platform 4.15 では、すべてのノードが、デフォルトの RHEL 9 設定に合わせた内部リソース管理に Linux コントロールグループバージョン 2 (cgroup v2) を使用します。ただし、クラスターにパフォーマンスプロファイルを適用する場合、パフォーマンスプロファイルに関連付けられた低遅延チューニング機能は、cgroup v2 をサポートしません。
その結果、パフォーマンスプロファイルを適用すると、クラスター内のすべてのノードが再起動され、cgroup v1 設定に戻ります。この再起動には、パフォーマンスプロファイルの対象になっていないコントロールプレーンノードとワーカーノードが含まれます。
クラスター内のすべてのノードを cgroups v2 設定に戻すには、
Node
リソースを編集する必要があります。詳細は、Linux cgroup v2 の設定 を参照してください。最後のパフォーマンスプロファイルを削除しても、クラスターを cgroups v2 設定に戻すことはできません。(OCPBUGS-16976)-
現時点で、SR-IOV ネットワークデバイスを使用する Pod を削除するとエラーが発生する可能性があります。このエラーは、ネットワークインターフェイスの名前が変更されると、以前の名前が代替名リストに追加されるという RHEL 9 の変更によって発生します。その結果、SR-IOV Virtual Function (VF) にアタッチされた Pod が削除されると、VF は元の名前 (
ensf0v2
など) ではなく、予期しない新しい名前 (dev69
など) でプールに戻ります。このエラーは重大なエラーではありませんが、システムが自動修復する際に、Multus および SR-IOV ログにエラーが表示される場合があります。このエラーにより、Pod の削除に数秒かかる場合があります。(OCPBUGS-11281、OCPBUGS-18822、RHEL-5988) -
OpenShift Container Platform クラスターで Cloud-native Network Functions (CNF) レイテンシーテストを実行すると、
oslat
テストで 20 マイクロ秒を超える結果が返されることがあります。これにより、oslat
テストが失敗します。(RHEL-9279) -
リアルタイムカーネルで
preempt-rt
パッチを使用し、ネットワーク割り込みの SMP アフィニティーを更新すると、対応する割り込み要求 (IRQ) スレッドは更新をすぐには受け取りません。代わりに、次の割り込みを受信したときに更新が有効になり、その後スレッドが正しいコアに移行されます。(RHEL-9148) グランドマスタークロック (T-GM) として設定されている Intel Westport Channel e810 NIC の Global Navigation Satellite System (GNSS) モジュールは、GPS
FIX
状態と、GNSS モジュールと GNSS コンステレーション衛生間の GNSS オフセットを報告できます。現在の T-GM 実装では、GNSS オフセットおよび GPS
FIX
値を読み取るために、ubxtool
CLI を使用してublox
モジュールをプローブすることはしません。代わりに、gpsd
サービスを使用して GPSFIX
情報を読み取ります。これは、ubxtool
CLI の現在の実装では応答を受信するのに 2 秒かかり、呼び出しごとに CPU 使用率が 3 倍に増加するためです。(OCPBUGS-17422)-
現在のグランドマスタークロック (T-GM) 実装には、バックアップ NMEA センテンスジェネレーターなしで、GNSS から提供される単一の NMEA センテンスジェネレーターがあります。NMEA センテンスが e810 NIC に向かう途中で失われた場合、T-GM はネットワーク同期チェーン内のデバイスを同期できず、PTP Operator はエラーを報告します。修正案は、NMEA 文字列が失われたときに
FREERUN
イベントを報告することです。(OCPBUGS-19838) - 現在、Kubernetes Operator (MCE) のマルチクラスターエンジンがインストールされている場合、Web コンソールの一部のページの YAML タブが一部のブラウザーで予期せず停止します。次のメッセージが表示されます: "Oh no!Something went wrong." (OCPBUGS-29812)
- クラスターで IPsec が有効になっている場合は、OpenShift Container Platform 4.15 にアップグレードする前に無効にする必要があります。IPsec を無効にせずに 4.15 に更新すると、Pod 間通信が中断または失われる可能性があるという既知の問題があります。IPsec を無効にする方法については、IPsec 暗号化の設定 を参照してください。(OCPBUGS-43323)
- クラスターで IPsec が有効になっており、クラスターと外部ノード間で IPsec 暗号化が設定されている場合、外部ノードで IPsec 接続を停止すると、外部ノードへの接続が失われます。接続の OpenShift Container Platform 側で IPsec トンネルのシャットダウンが認識されないため、このように接続できなくなります。(RHEL-24802)
- クラスターで IPsec が有効になっており、クラスターが OpenShift Container Platform クラスターの Hosted Control Plane である場合、Pod 間のトラフィックの IPsec トンネルを考慮した MTU 調整は自動的には行われません。(OCPBUGS-28757)
-
クラスター上で IPsec が有効になっている場合、作成した外部ホストへの既存の IPsec トンネルを変更することはできません。既存の NMState Operator
NodeNetworkConfigurationPolicy
オブジェクトを変更して既存の IPsec 設定を調整し、外部ホストへのトラフィックを暗号化しても、OpenShift Container Platform では認識されません。(RHEL-22720) -
クラスター上で IPsec が有効になっている場合、north-south IPsec 接続をホストしているノード上で、
ipsec.service
systemd ユニットを再起動するか、ovn-ipsec-host
Pod を再起動すると、IPsec 接続が失われます。(RHEL-26878) -
現在、Operator カタログのミラーリングに関して既知の問題があります。
oc-mirror
は、imagesetconfig
カタログフィルタリング仕様に従ってカタログを再構築し、内部キャッシュを再生成します。この操作では、カタログに含まれるopm
バイナリーを使用する必要があります。OpenShift Container Platform 4.15 では、Operator カタログにopm
RHEL 9 バイナリーが含まれており、これにより RHEL 8 システムでミラーリングプロセスが失敗します。(OCPBUGS-31536)
現在、OpenShift Container Platform 4.15 でリリースされた
opm
CLI ツールのバージョンが RHEL 8 をサポートしないという既知の問題があります。回避策として、RHEL 8 ユーザーは OpenShift ミラーサイト に移動し、OpenShift Container Platform 4.14 でリリースされた tarball の最新バージョンをダウンロードできます。
-
このリリースには、
kubeadmin
としてクラスターにログインしたときに Web ターミナルを作成できないという既知の問題があります。ターミナルには、Error Loading OpenShift command line terminal: User is not a owner of the requested workspace.
というメッセージが表示されます。この問題は、今後の OpenShift Container Platform リリースで修正される予定です。(WTO-262)
-
現在、Tuned リソースの
profile
フィールドで、名前にスラッシュが含まれる設定 (ボンディングデバイスなど) のsysctl
値を定義すると、機能しない可能性があります。sysctl
オプション名にスラッシュが含まれる値は、/proc
ファイルシステムに正しくマップされません。回避策として、必要な値を使用して設定ファイルを/etc/sysctl.d
ノードディレクトリーに配置するMachineConfig
リソースを作成します。(RHEL-3707) Kubernetes の問題により、CPU マネージャーは、ノードに許可された最後の Pod から利用可能な CPU リソースのプールに CPU リソースを戻すことができません。これらのリソースは、後続の Pod がノードに許可された場合は、割り当てることができます。ただし、これが最後の Pod となり、やはり CPU マネージャーはこの Pod のリソースを使用可能なプールに戻すことができなくなります。
この問題は、CPU 負荷分散機能に影響を与えます。これは、これらの機能が CPU マネージャーが使用可能なプールに CPU を解放することに依存するためです。その結果、保証されていない Pod は、少ない CPU 数で実行される可能性があります。回避策として、影響を受けるノード上で
best-effort
CPU マネージャーポリシーを使用して、Pod をスケジュールします。この Pod は最後に許可された Pod となり、これによりリソースが使用可能なプールに正しく解放されます。(OCPBUGS-17792)-
ノードの再起動が発生すると、すべての Pod がランダムな順序で再起動されます。このシナリオでは、
tuned
Pod がワークロード Pod の後に開始された可能性があります。これは、ワークロード Pod が部分的なチューニングから開始されることを意味します。これは、パフォーマンスに影響を与えたり、ワークロードの失敗を引き起こしたりする可能性があります。(OCPBUGS-26400) -
パフォーマンスプロファイルが追加のマニフェストフォルダーに存在し、プライマリープールまたはワーカープールをターゲットにしている場合、OpenShift Container Platform のインストールが失敗することがあります。これは、デフォルトのプライマリーおよびワーカー
MachineConfigPool
が作成される前に、パフォーマンスプロファイルを処理する内部インストール順序によって発生します。この問題は、追加のマニフェストフォルダーにストックプライマリーまたはワーカーMachineConfigPools
のコピーを含めることで回避できます。(OCPBUGS-27948) (OCPBUGS-18640) - OpenShift Container Platform の Hosted Control Plane では、HyperShift Operator は Operator の初期化中にリリースメタデータを 1 回しか抽出しません。管理クラスターに変更を加えたり、ホストされたクラスターを作成したりしても、HyperShift Operator はリリースメタデータを更新しません。回避策として、Pod のデプロイメントを削除して HyperShift Operator を再起動します。(OCPBUGS-29110)
-
OpenShift Container Platform の Hosted Control Plane では、非接続環境で
ImageDigestMirrorSet
オブジェクトとImageContentSourcePolicy
オブジェクトのカスタムリソース定義 (CRD) を同時に作成すると、HyperShift Operator がImageContentSourcePolicy
CRD を無視して、ImageDigestMirrorSet
CRD のみのオブジェクトを作成します。回避策として、ImageDigestMirrorSet
CRD にImageContentSourcePolicies
オブジェクト設定をコピーします。(OCPBUGS-29466) -
OpenShift Container Platform の Hosted Control Plane では、非接続環境でホストされたクラスターを作成するときに、
HostedCluster
リソースでhypershift.openshift.io/control-plane-operator-image
アノテーションを明示的に設定しないと、ホストされたクラスターのデプロイメントがエラーで失敗します。(OCPBUGS-29494)