1.8. 既知の問題

--cloud-provider=external オプションが cloud-provider-vsphere に設定されているクラウドコントローラーマネージャー(CCM)の場合、複数のサブネットを持つネットワーク環境で動作するクラスターに対する既知の問題が存在します。

クラスターを OpenShift Container Platform 4.12 から OpenShift Container Platform 4.13 にアップグレードすると、CM は誤ったノード IP アドレスを選択し、この操作により namespace/openshift-cloud-controller-manager/pods/vsphere-cloud-controller-manager ログにエラーメッセージが生成されます。このエラーメッセージは、クラスターのノード IP アドレスと vsphere-cloud-controller-manager Pod IP アドレスと不一致を示しています。

既知の問題はクラスターのアップグレード操作に影響しない可能性がありますが、クラスターがネットワーク要件に使用する nodeNetworking.external.networkSubnetCidr パラメーターと nodeNetworking.internal.networkSubnetCidr パラメーターの両方に、正しい IP アドレスを設定できます。

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

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

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

## 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

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

(BZ#1821771)

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)

インターフェイス固有の安全な sysct を更新するデーモンセットの YAML 定義における間違った優先クラス名と構文エラーが原因で、openshift-multus namespace の cni-sysctl-allowlist config map を使用してインターフェイスの安全な sysct リストを変更できません。

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

vSphere プラットフォーム上の一部の OpenShift Container Platform インストールで CSI ドライバーを使用する場合、vSphere CSI ドライバーの起動中に vCenter からノードに関する情報を取得できず、ドライバーは再試行しないため、vSphere CSI ドライバーが正しく起動しないことがあります。

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

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)

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
 # ...

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 の適用後にホストの電源が入っていないことを示します。この問題を回避するには、以下の手順を実行します。

(OCPBUGS-8434)

DPDK の CPU ロードバランシングの無効化 で説明されている低遅延チューニングに関連付けられた cpu-load-balancing.crio.io: "disable" アノテーションは、ワークロードパーティショニングが設定されていないシステムでは機能しません。具体的には、ワークロードのパーティション設定 で説明されているように、インフラストラクチャーが cpuPartitioningMode を AllNodes 値に設定していないクラスターに影響します。

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

コントロールプレーンノードにスケジュールされている 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 インストーラー引数として設定する必要があります。