1.8. 既知の問題

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

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

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

for clusterrolebinding in cluster-status-binding discovery system:basic-user system:discovery system:openshift:discovery ;

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

ユーザーによってプロビジョニングされるインフラストラクチャーで vSphere 上の仮想マシンの電源をオンにすると、ノードのスケールアッププロセスは予想通りに機能しない可能性があります。ハイパーバイザー設定の既知の問題により、ハイパーバイザー内にマシンが作成されますが、電源がオンになりません。マシンセットをスケールアップした後にノードが Provisioning 状態のままである場合、vSphere インスタンス自体で仮想マシンのステータスを調査できます。VMware コマンド govc tasks および govc events を使用して、仮想マシンのステータスを判別します。以下のようなエラーメッセージがあるかどうかを確認します。

[Invalid memory setting: memory reservation (sched.mem.min) should be equal to memsize(8192). ]

[Invalid memory setting: memory reservation (sched.mem.min) should be equal to memsize(8192). ]

この VMware KBase の記事 にある手順に従って、問題の解決を試行できます。詳細は、Red Hat ナレッジベースのソリューションの [UPI vSphere] Node scale-up doesn't work as expected を参照してください。(BZ#1918383)

x86_64 アーキテクチャーを使用する VMware でクラスターを実行し、platform: none フィールドが install-config.yaml ファイルに設定されていると、OpenShift Container Platform クラスターバージョン 4.7 の新規インストール、またはクラスターバージョン 4.6 からバージョン 4.7 へのアップグレードに失敗する可能性があります。この失敗は、クラスターが仮想ハードウェアバージョン 14 以上で設定された仮想マシン (VM) を使用する場合に発生します。回避策として、仮想ハードウェアのバージョン 13 を使用するように仮想マシンを設定できます。

VMware Cloud (VMC) にデプロイされるクラスターでは、仮想ハードウェアバージョン 14 以上の問題は発生しません。(BZ#1941714)

Pod をすぐに起動および停止すると、Pod が Terminating 状態のままになる可能性があります。回避策として、以下のコマンドを実行して停止状態の Pod を削除する必要があります。

oc delete --force -n <project_name> <pod_name>

$ oc delete --force -n <project_name> <pod_name>

この問題は OpenShift Container Platform の今後のリリースで修正されます。(BZ#1929463)

Performance Addon Operator を 4.6 から 4.7 にアップグレードすると、エラーを出して失敗します。

"Warning  TooManyOperatorGroups  11m   operator-lifecycle-manager  csv created in namespace with multiple operatorgroups, can't pick one automatically"

"Warning  TooManyOperatorGroups  11m   operator-lifecycle-manager  csv created in namespace with multiple operatorgroups, can't pick one automatically"

アップグレードする前に、以前に特定の namespace にインストールされている場合の Performance Addon Operator のアップグレード に説明されている手順に従います。

(BZ#1913826)

サポートされる NIC で SR-IOV の変更を有効にするには、再起動が必要になる場合があります。現時点で SR-IOV は準備状態になると再起動を実行します。この再起動が Machine Config ポリシーの変更と同時に起こると、ノードは不確定 (undermined) の状態になる可能性があります。Machine Config Operator は、更新されたポリシーが適用されていなくても適用されたと仮定します。

この問題を回避するには、MCO および SR-IOV の変更を必要とする新規ノードを順番に完了する必要があります。最初にすべての MCO 設定を適用し、ノードが解決するのを待機します。次に、SR-IOV 設定を適用します。

新規ノードが SR-IOV を含む Machine Config Pool に追加される場合は、Machine Config Pool から SR-IOV ポリシーを削除してから新規ワーカーを追加すことで、この問題を回避できます。次に、SR-IOV ポリシーを再度適用します。

(BZ#1921321)

PTP (Precision Time Protocol) の障害が、アダプターカードの Mellanox MT27800 ファミリー [ConnectX-5] で確認されます。ptp4l ログでは、クロックの同期を妨げるエラーが確認されています。

このようなエラーにより、NIC ハードウェアクロックのリセットが必要となるため、通常のシステムクロック更新よりも大規模な更新が必要になります。この問題の根本的な原因は不明であり、現時点で回避策はありません。

(BZ#1913279)

最新の Dell ファームウェア (04.40.00.00) ノードを使用してベアメタルへの IPI インストールを試みると、デプロイが行われず、エラーがステータスに表示されます。これは、eHTML5 を Virtual Console Plugin として使用する Dell Firmware (4.40.00.00) によって生じます。

この問題を回避するには、Virtual Console Plugin を HTML5 に変更し、デプロイメントを再度実行します。ノードが正常にデプロイされるはずです。詳細は、仮想メディアを使用してインストールするためにファームウェア要件 について参照してください。

(BZ#1915828)

ブートストラップ時に Kuryr を使用する RHOSP のクラスターのインストールは以下のメッセージを出してタイムアウトします。

INFO Waiting up to 20m0s for the Kubernetes API at https://api.ostest.shiftstack.com:6443...
INFO API v1.20.0+ba45583 up
INFO Waiting up to 30m0s for bootstrapping to complete...
ERROR Attempted to gather ClusterOperator status after wait failure: listing ClusterOperator objects: Get "https://api.ostest.shiftstack.com:6443/apis/config.openshift.io/v1/clusteroperators": dial tcp 10.46.44.166:6443: connect: connection refused
INFO Use the following commands to gather logs from the cluster
INFO openshift-install gather bootstrap --help
FATAL failed to wait for bootstrapping to complete: timed out waiting for the condition

INFO Waiting up to 20m0s for the Kubernetes API at https://api.ostest.shiftstack.com:6443...
INFO API v1.20.0+ba45583 up
INFO Waiting up to 30m0s for bootstrapping to complete...
ERROR Attempted to gather ClusterOperator status after wait failure: listing ClusterOperator objects: Get "https://api.ostest.shiftstack.com:6443/apis/config.openshift.io/v1/clusteroperators": dial tcp 10.46.44.166:6443: connect: connection refused
INFO Use the following commands to gather logs from the cluster
INFO openshift-install gather bootstrap --help
FATAL failed to wait for bootstrapping to complete: timed out waiting for the condition

タイムアウトは、Kuryr がクラスターのノードの RHOSP Networking サービス (neutron) サブネットを検出する方法の変更によって生じます。

回避策として、インストールドキュメントの Kubernetes マニフェストおよび Ignition 設定ファイルの作成セクションで説明されているコントロールプレーンマシンのマニフェストは削除しないでください。以下のコマンドを実行するように指示される場合:

rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml

$ rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml

代わりに以下のコマンドを実行します。

rm -f openshift/99_openshift-cluster-api_worker-machineset-*.yaml

$ rm -f openshift/99_openshift-cluster-api_worker-machineset-*.yaml

(BZ#1927244)

すべての HTTP トラフィックを HTTPS にリダイレクトする管理者によってプロビジョニングされる外部ロードバランサーを使用してデフォルトの Ingress Controller を公開するクラスターがある場合、4.6 から 4.7 へのアップグレードプロセスで Edge Termination を使用するように新規のクリアテキストの Ingress Canary ルートにパッチを適用する必要があります。

oc patch route/canary -n openshift-ingress-canary -p '{"spec":{"tls":{"termination":"edge","insecureEdgeTerminationPolicy":"Redirect"}}}'

$ oc patch route/canary -n openshift-ingress-canary -p '{"spec":{"tls":{"termination":"edge","insecureEdgeTerminationPolicy":"Redirect"}}}'

(BZ#1932401)

openswitch ("net: openvswitch: reorder masks array based on usage") コードへの更新により、openvswitch et/openvswitch/flow_table::flow_lookup がプリエンプション可能な (移行可能な) セクションの CPU ごとのデータにアクセスし、リアルタイムのカーネルパニックが発生します。その結果、kernel-rt は不安定になり、低レイテンシーのアプリケーションに影響します。

これが修正されるまで、OpenShift Container Platform 4.7 にアップグレードしないことが推奨されます。

(BZ#1918456)

SR-IOV デバイスプラグインでは、ノード上の VFIO デバイスをリソースとして公開することを許可しません。これにより、Intel デバイスで DPDK ワークロードがブロックされます。

この問題が修正されるまで、SR-IOV をお使いのお客様におかれましては OpenShift Container Platform 4.7 にアップグレードしないことをお勧めします。

(BZ#1930469)

OpenShift Container Platform 4.7 では、Operator インフラストラクチャーコードに追加される ConfigInformers オブジェクトは正常に起動しません。そのため、ConfigObserver オブジェクトはキャッシュの同期に失敗します。これが生じると、oVirt CSI ドライバー Operator は数分後にシャットダウンし、これにより継続的に再起動が繰り返されます。回避策として、以下の手順を実行できます。

これにより、oVirt CSI ドライバー Operator は継続的に再起動しなくなります。(BZ#1929777)