1.8. 既知の問題

PDF

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 インストーラー引数として設定する必要があります。
1. インストーラーでプロビジョニングされるインフラストラクチャーの場合、インストール前に次の手順を実行して、各ノードの IP インストーラー引数としてネットワーク設定を指定します。
  1. マニフェストを作成します。
  2. 各ノードについて、アノテーションを使用して 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 のプロトコルとパスに置き換えます。
  3. ファイルを clusterconfigs/openshift ディレクトリーに保存します。
  4. クラスターを作成します。
2. 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
```
  以前のネットワーク設定の場合は、次のように置き換えます。
  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)

詳細とサポートについては、Red Hat Support チームにお問い合わせください。

(OCPBUGS-23119)

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 サービスを使用して GPS FIX 情報を読み取ります。これは、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 が有効になっており、クラスターと外部ノード間で 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)

1.8. 既知の問題

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links