1.8. 既知の問題

  • OpenShift Container Platform 4.1 では、匿名ユーザーは検出エンドポイントにアクセスできました。後のリリースでは、一部の検出エンドポイントは集約された API サーバーに転送されるため、このアクセスを無効にして、セキュリティーの脆弱性の可能性を減らすことができます。ただし、既存のユースケースに支障がで出ないように、認証されていないアクセスはアップグレードされたクラスターで保持されます。

    OpenShift Container Platform 4.1 から 4.13 にアップグレードされたクラスターのクラスター管理者の場合、認証されていないアクセスを無効にするか、またはこれを引き続き許可することができます。認証なしのアクセスが必要な理由が特に無い限り、無効にしてください。認証されていないアクセスを引き続き許可する場合は、それに伴ってリスクが増大することに注意してください。

    警告

    認証されていないアクセスに依存するアプリケーションがある場合、認証されていないアクセスを取り消すと HTTP 403 エラーが生じる可能性があります。

    以下のスクリプトを使用して、検出エンドポイントへの認証されていないアクセスを無効にします。

    ## Snippet to remove unauthenticated group from all the cluster role bindings
    $ for clusterrolebinding in cluster-status-binding discovery system:basic-user system:discovery system:openshift:discovery ;
    do
    ### Find the index of unauthenticated group in list of subjects
    index=$(oc get clusterrolebinding ${clusterrolebinding} -o json | jq 'select(.subjects!=null) | .subjects | map(.name=="system:unauthenticated") | index(true)');
    ### Remove the element at index from subjects array
    oc patch clusterrolebinding ${clusterrolebinding} --type=json --patch "[{'op': 'remove','path': '/subjects/$index'}]";
    done

    このスクリプトは、認証されていないサブジェクトを以下のクラスターロールバインディングから削除します。

    • cluster-status-binding
    • discovery
    • system:basic-user
    • system:discovery
    • system:openshift:discovery

    (BZ#1821771)

  • oc annotate コマンドは、等号 (=) が含まれる LDAP グループ名では機能しません。これは、コマンドがアノテーション名と値の間に等号を区切り文字として使用するためです。回避策として、oc patch または oc edit を使用してアノテーションを追加します。(BZ#1917280)
  • Git リポジトリーを追加し、GitLab および Bitbucket pipeline-as-code リポジトリーで設定すると、無効なリポジトリーリソースが作成されます。その結果、GitLab プロバイダーと Bitbucket プロバイダーの spec.git_provider.url Git プロバイダー URL が削除されます。

    回避策として、Bitbucket に必須の spec.git_provider.user フィールドを追加します。さらに、Git access token または Git access token secret を選択して、Git リポジトリーの追加を続行します。(OCPBUGS-7036)

  • 現在、VMware vSphere に OpenShift Container Platform クラスターをインストールする目的でインストールプログラムを macOS で実行する場合、x509: certificate is not standards compliant として出力される証明書コンプライアンスの問題が存在します。この問題は、コンパイラーが新しくサポートされた macOS 証明書規格を認識しないという golang コンパイラーの既知の問題に関連しています。この問題に対する回避策はありません。(OSDOCS-5694)
  • ControlPlaneMachineSet 定義に 3 つを超える障害ドメインを含めると、負荷分散アルゴリズムは既存のコントロールプレーンマシンを優先しません。既存の 3 つの障害ドメインよりもアルファベット順で優先順位が高い 4 番目の障害ドメインを定義に追加すると、4 番目の障害ドメインが既存の障害ドメインよりも優先されます。この動作により、ロールフォワード更新をコントロールプレーンマシンに適用できます。この問題は、使用中の既存障害ドメインの優先順位を、未使用の新規障害ドメインよりも高く設定することで回避できます。このアクションにより、定義に 3 つを超える障害ドメインを追加する過程で、各コントロールプレーンマシンが安定します。(OCPBUGS-11968)
  • シングルノード OpenShift インスタンスでは、ノードをドレインして実行中のすべての Pod を削除せずに再起動すると、ワークロードコンテナーのリカバリーで問題が発生する可能性があります。再起動後、すべてのデバイスプラグインの準備が整う前にワークロードが再開され、その結果、リソースが利用できなくなったり、ワークロードが間違った NUMA ノードで実行されたりします。回避策としては、再起動リカバリーの手順中にすべてのデバイスプラグインが再登録された時点でワークロード Pod を再起動します。(OCPBUGS-2180)
  • SR-IOV ネットデバイスを使用する Pod を削除するときにエラーが発生する場合があります。このエラーは、ネットワークインターフェイスの名前が変更されると、以前の名前が代替名リストに追加されるという RHEL 9 の変更によって発生します。その結果、SR-IOV 仮想機能 (VF) にアタッチされた Pod が削除されると、VF は元の名前 (例: ensf0v2) ではなく、予期しない新しい名前 (例: dev69) でプールに戻ります。これは致命的なエラーではありませんが、システムが自動修復する際に Multus および SR-IOV ログにエラーが表示される場合があります。このエラーにより、Pod の削除に追加で数秒かかる場合があります。(OCPBUGS-11281)
  • インターフェイス固有の安全な sysct を更新するデーモンセットの YAML 定義における間違った優先クラス名と構文エラーが原因で、openshift-multus namespace の cni-sysctl-allowlist config map を使用してインターフェイスの安全な sysct リストを変更できません。

    回避策: この問題に対処するには、手動で、またはデーモンセットを使用して、ノード上の /etc/cni/tuning/allowlist.conf ファイルを変更します。(OCPBUGS-11046)

  • OpenShift Container Platform 4.12 で導入された UDP GRO を有効にする新機能を使用すると、すべての veth デバイスが利用可能な CPU ごとに 1 つの RX キューを持つことになります (以前は各 veth に 1 つのキューがありました)。これらのキューは Open Virtual Network によって動的に設定され、レイテンシーチューニングとこのキューの作成の間に同期はありません。レイテンシーチューニングロジックは、veth NIC 作成イベントをモニタリングし、すべてのキューが適切に作成される前に、RPS キュー CPU マスクの設定を開始します。これは、一部の RPS キューマスクが設定されないことを意味します。すべての NIC キューが適切に設定されるわけではないため、タイミングに敏感な CPU を使用して他のコンテナー内のサービスと通信するリアルタイムアプリケーションでは、レイテンシースパイクが発生する可能性があります。カーネルネットワークスタックを使用しないアプリケーションは影響を受けません。(OCPBUGS-4194)
  • Cluster Network Operator (CNO) コントローラーが、必要以上に多くのリソースを監視します。その結果、リコンサイラーが過剰にトリガーされ、必要以上に高いレートで API 要求が発生します。毎秒約 1 件の config map アクセス要求が発生します。これにより、CNO と kube-apiserver の両方の負荷が増加します。(OCPBUGS-11565)
  • OpenShift Container Platform 4.13 の場合、Driver Toolkit (DTK) コンテナーイメージには、ドライバーコンテナーをビルドするために、ソフトウェアスタックの第 2 レイヤーとして ubi9 イメージが必要です。ubi8 イメージをソフトウェアスタックの第 2 レイヤーとして使用しようとするとエラーが発生します。(OCPBUGS-11120)
  • vSphere プラットフォーム上の一部の OpenShift Container Platform インストールで CSI ドライバーを使用する場合、vSphere CSI ドライバーの起動中に vCenter からノードに関する情報を取得できず、ドライバーは再試行しないため、vSphere CSI ドライバーが正しく起動しないことがあります。

    回避策: SSH を使用して vsphere-syncer プロセスの現在のリーダーであるノードに接続し、vsphere-syncer コンテナーを (crictl を使用して) 再起動すると、この問題が軽減されてドライバーが正常に起動します。(OCPBUGS-13385)

  • OpenShift Container Platform 4.13 の場合、OpenShift 4.13 に付属する Red Hat Enterprise Linux CoreOS (RHCOS) イメージからはベアメタルワーカーを起動できないため、ベアメタルワーカーを使用して Red Hat OpenStack Platform (RHOSP) 16.2 上にバージョン 4.13 をインストールすると失敗します。RHCOS イメージにバイトオーダーマーカーがないことが、根本的な問題となっています。この問題の修正は次の 16.2 ビルドで計画されています。(OCPBUGS-13395)
  • RHEL 9.2 の既知の問題により、Confidential VM を含む GCP クラスターでは永続ボリュームを使用できません。(OCPBUGS-7582)
  • openvswitch2.15 がインストールされている OpenShift Container Platform 4.12 クラスターで実行されている Red Hat Enterprise Linux (RHEL) ワーカーは、OpenShift Container Platform 4.13 にアップグレードすると失敗します。upgrade.yml Playbook は次のエラーメッセージで失敗します: package openvswitch2.17-2.17.0-88.el8fdp.x86_64 conflicts with openvswitch2.15 provided by openvswitch2.15-2.15.0-136.el8fdp.x86_64

    この問題を回避するには、OpenShift Container Platform 4.13 に更新する前に、手動で openvswitch2.15 パッケージを削除し、openvswitch2.17 パッケージをインストールします。次に、upgrade.yml Playbook を実行して RHEL ワーカーを更新し、更新プロセスを完了します。(OCPBUGS-11677)

  • ストレージをワークロードに接続するときに、ディスク検出が遅延します。(OCPBUGS-11149)
  • OpenShift Container Platform 4.12 から 4.13 に更新すると、Mellanox NIC は SR-IOV ネットワークノードポリシーの名前を変更します (例: ens7f0 から ens7f0np0 に変更)。この名前の変更は、RHEL 9 カーネルへの更新により発生します。その結果、インターフェイスが見つからないため仮想機能 (VF) を作成できません。SR-IOV ネットワークノードポリシーでは、この名前変更を考慮する必要があります。たとえば、ポリシーで ens7f0 が参照されている場合は、更新する前に ens7f0np0 をポリシーに追加します。

    この問題を回避するには、OpenShift Container Platform 4.13 に更新する前に、SriovNetworkNodePolicy カスタムリソース (CR) を手動で編集して ens7f0np0 を追加する必要があります。(OCPBUGS-13186) 次のコードは、互換性を確保するために両方の名前が SriovNetworkNodePolicy に追加されたポリシー更新の例を示しています。

      # ...
      deviceType: netdevice
      nicSelector:
        deviceID: “101d”
        pfNames:
          - ens7f0
          - ens7f0np0
        vendor: ‘15b3’
      nodeSelector:
        feature.node.kubernetes.io/sriov-capable: ‘true’
      numVfs: 4
     # ...
  • Pod の削除時に SR-IOV 仮想機能 (VF)の MAC アドレスをリセットすると、Intel E810 NIC で失敗する可能性があります。その結果、SR-IOV VF を持つ Pod の作成には、Intel E810 NIC カードで最大 2 分かかる場合があります。(OCPBUGS-5892)
  • クラスターのアップグレードに使用するサブスクリプションポリシーで無効なサブスクリプションチャネルを指定すると、Topology Aware Lifecycle Manager (TALM) は、TALM がポリシーを適用した直後にアップグレードが成功したことを示します。これは、Subscription リソースが AtlatestKnown 状態のままであるためです。(OCPBUGS-9239)
  • システムクラッシュの発生後、kdump は、Intel E810 NIC と ice ドライバーがインストールされている HPE Edgeline e920t および HPE ProLiant DL110 Gen10 サーバー上で vmcore クラッシュダンプファイルを生成できません。(RHELPLAN-138236)
  • GitOps ZTP では、SiteConfig CR を使用して複数のノードを含むマネージドクラスターをプロビジョニングする場合、1 つ以上のノードに SiteConfig CR で設定された diskPartition リソースがあると、ディスクパーティションが失敗します。(OCPBUGS-9272)
  • PTP 境界クロック (T-BC) が設定され、DU アプリケーションがデプロイされたクラスターでは、最大 40 秒間、vDU ホスト上の T-BC のフォロワーインターフェイスからメッセージが断続的に送信されません。ログ内のエラーレートは異なる場合があります。以下はエラーログの例です。

    出力例

    2023-01-15T19:26:33.017221334+00:00 stdout F phc2sys[359186.957]: [ptp4l.0.config] nothing to synchronize

    (RHELPLAN-145492)

  • GitOps ZTP を使用してシングルノード OpenShift クラスターをインストールし、HTTP トランスポートを使用して PTP およびベアメタルイベントを設定すると、linuxptp-daemon デーモン Pod のデプロイが断続的に失敗します。必要な PersistentVolumeClaim (PVC) リソースは作成されますが、Pod にマウントされません。次のボリュームマウントエラーが報告されます。

    出力例

    mount: /var/lib/kubelet/plugins/kubernetes.io/local-volume/mounts/local-pv-bc42d358: mount(2) system call failed: Structure needs cleaning.

    この問題を回避するには、cloud-event-proxy-store-storage-class-http-events PVC CR を削除し、PTP Operator を再デプロイします。(OCPBUGS-12358)

  • SiteConfig CR でセキュアブートが有効になっているシングルノード OpenShift マネージドクラスターの GitOps Zero Touch Provisioning (ZTP) プロビジョニング中にホストのプロビジョニングを実行すると、BareMetalHost CR に対して複数の ProvisioningError エラーが報告されます。このエラーは、セキュアブート設定が Baseboard Management Controller (BMC) に正常に適用されているが、BareMetalHost CR の適用後にホストの電源が入っていないことを示します。この問題を回避するには、以下の手順を実行します。

    1. ホストを再起動します。これにより、GitOps ZTP パイプラインは確実にセキュアブート設定を適用します。
    2. 同じ設定でクラスターの GitOps ZTP プロビジョニングを再起動します。

    (OCPBUGS-8434)

  • デュアルスタック GitOps ZTP ハブクラスターをインストールした後に、デュアルスタック仮想 IP アドレス (VIP) を有効にし、Provisioning CR で virtualMediaViaExternalNetwork フラグを有効にすると、IRONIC_EXTERNAL_URL_V6 環境変数に IPv4 アドレスが誤って割り当てられます。(OCPBUGS-4248)
  • ZT サーバーの BiosRegistry 言語が、en ではなく en-US に設定されています。これにより、マネージドクラスターホストの GitOps ZTP プロビジョニング中に問題が発生します。ZT サーバー用に生成された FirmwareSchema CR の allowable_valuesattribute_typeread_only フィールドが入力されていません。(OCPBUGS-4388)
  • OpenShift Container Platform バージョン 4.13.0 では、エージェントベースのインストーラーでクラスターをインストールしようとするとエラーが発生します。ディスクの読み取り段階の後にエラーが返され、クラスターのインストールがスタックします。このエラーは HPEsplunk Gen10 サーバーで検出されます。(OCPBUGS-13138)
  • RFC2544 のパフォーマンステストは、ネットワークを通過するパケットの Max delay 値が最小しきい値を超えることを示しています。このリグレッションは、Telco RAN DU プロファイルを実行している OpenShift Container Platform 4.13 クラスターで発生します。(OCPBUGS-13224)
  • OpenShift Container Platform 4.13 がインストールされたシングルノード OpenShift クラスターで実行されたパフォーマンステストでは、oslat の最大レイテンシーが 20 マイクロ秒を超えています。(RHELPLAN-155443)
  • OpenShift Container Platform 4.13 がインストールされたシングルノード OpenShift クラスターで実行されたパフォーマンステストでは、cyclictest の最大レイテンシーが 20 マイクロ秒を超えています。(RHELPLAN-155460)
  • DPDK の CPU ロードバランシングの無効化 で説明されている低遅延チューニングに関連付けられた cpu-load-balancing.crio.io: "disable" アノテーションは、ワークロードパーティショニングが設定されていないシステムでは機能しません。具体的には、ワークロードのパーティション設定 で説明されているように、インフラストラクチャーが cpuPartitioningModeAllNodes 値に設定していないクラスターに影響します。

    該当するクラスターの達成可能なレイテンシーに影響を与え、低レイテンシーワークロードの適切な動作を妨げる可能性があります。(OCPBUGS-13163)

  • Nutanix プラットフォーム上の OpenShift Container Platform 4.12 クラスターでは、Nutanix Cloud Control Manager (CCM) に必要な設定がない場合は、Upgradeable=False 状態が発生する可能性があります。この状態を解決するには、How to create the ConfigMaps and Secrets needed to upgrade to OpenShift 4.13 when using Nutanix as a Platform を参照してください。
  • 現在、非常に多くのファイルを含む永続ボリューム (PV) を使用すると、Pod が起動しないか、起動に過度に時間がかかる場合があります。詳細は、ナレッジベースアーティクル を参照してください。(BZ1987112)
  • コントロールプレーンノードにスケジュールされている Azure File NFS ボリュームを含む Pod を作成すると、マウントが拒否されます。(OCPBUGS-18581)

    この問題を回避するには、コントロールプレーンノードがスケジュール可能で、Pod がワーカーノードで実行できる場合は、nodeSelector または Affinity を使用してワーカーノードで Pod をスケジュールします。

  • vSphere でのエージェントベースのインストールは、ノードテイントの削除に失敗したために失敗します。これにより、インストールが保留状態のままになります。シングルノードの OpenShift クラスターは影響を受けません。この問題を回避するには、次のコマンドを実行してノードテイントを手動で削除します。

    $ oc adm taint nodes <node_name> node.cloudprovider.kubernetes.io/uninitialized:NoSchedule-

    (OCPBUGS-20049)

  • 静的 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)