1.8. 既知の問題

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

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

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

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

OpenShift Container Platform 4.9 にアップグレードする場合、Cluster Version Operator は、前提条件チェックに失敗している間、アップグレードを約 5 分間ブロックします。It may not be safe to apply this update エラーテキストは、誤解を招く可能性があります。このエラーは、1 つまたは複数の前提条件チェックが失敗した場合に発生します。状況によっては、これらの前提条件チェックは、etcd バックアップ中など、短期間しか失敗しない場合があります。このような状況では、Cluster Version Operator と対応する Operator は、設計上、失敗した前提条件チェックを自動的に解決し、CVO はアップグレードを正常に開始します。

ユーザーは、クラスターオペレーターのステータスと条件を確認する必要があります。Cluster Version Operator により It may not be safe to apply this update エラーが表示される場合は、これらのステータスと条件により、メッセージの重大度に関する詳細情報が提供されます。詳細については、BZ#1999777、BZ#2061444、BZ#2006611 を参照してください。

クラスター管理者は、503、404、または両方のエラーページのカスタム HTTP エラーコード応答ページを指定できます。カスタムエラーコードの応答ページに適した形式を指定しない場合は、ルーター Pod が停止し、解決されません。ルーターは、カスタムのエラーコードページの更新を反映するようにリロードされません。回避策として、oc rsh コマンドを使用してルーター Pod にローカルでアクセスできます。次に、カスタム http エラーコードページを提供するすべてのルーター Pod で reload-haproxy を実行します。

$ oc -n openshift-ingress rsh router-default-6647d984d8-q7b58
sh-4.4$ bash -x /var/lib/haproxy/reload-haproxy

または、ルートにアノテーションを付け、リロードを強制的に実行できます。(BZ#1990020), (BZ#2003961)

クラスター管理者は、503、404、または両方のエラーページのカスタム HTTP エラーコード応答ページを指定できます。ルーターは、カスタムのエラーコードページの更新を反映するようにリロードされません。回避策として、ルーター Pod で rsh を実行し、カスタム http エラーコードページを提供するすべてのルーター Pod で reload-haproxy を実行します。

$ oc -n openshift-ingress rsh router-default-6647d984d8-q7b58
sh-4.4$ bash -x /var/lib/haproxy/reload-haproxy

または、ルートにアノテーションを付け、リロードを強制的に実行できます。(BZ#1990020)

特定のカーディナリティの高い監視メトリックが誤って削除されたため、このリリースでは、pod、qos、および System のコンテナーパフォーマンスの入力および出力メトリックは使用できません。

この問題に対する回避策はありません。実稼働環境のワークロードのこれらのメトリクスを追跡するには、初期 4.9 リリースにアップグレードしないでください。(BZ#2008120)

Operator Lifecycle Manager (OLM) は、タイムスタンプチェックと廃止された API 呼び出しの組み合わせを使用します。これは skipRange アップグレードでは機能せず、特定のサブスクリプションのアップグレードを実行する必要があるかどうかを判断します。skipRange アップグレードを使用する Operator の場合は、解決までに最大 15 分かかるアップグレードプロセスには遅延があり、さらに長くブロックされる可能性があります。

回避策として、クラスター管理者は openshift-operator-lifecycle-manager namespace で catalog-operator Pod を削除できます。これにより、Pod が自動的に再作成され、skipRange アップグレードがトリガーされます。(BZ#2002276)

OpenShift Container Platform 4.6 以降では、プルのイメージ参照は、以下の Red Hat レジストリーを指定する必要があります。

それらのレジストリーが指定されていない場合、ビルド Pod はイメージをプルできません。

回避策として、イメージのプル仕様で registry.redhat.io/ubi8/ubi:latest や registry.access.redhat.com/rhel7.7:latest などの完全修飾名を使用します。

オプションで、イメージの短縮名を許可するレジストリーを追加 して、イメージレジストリー設定を更新できます。(BZ#2011293)

OpenShift Container Platform 4.8 以前のデフォルトのロードバランシングアルゴリズムは leastconn でした。パススルーでないルートの場合、OpenShift Container Platform 4.8.0 ではデフォルトが random に変更されました。random に切り替えると、長時間のウェブソケット接続を使用する必要がある環境では、メモリー消費量が大幅に増加するため、互換性がありません。この大幅なメモリー消費を軽減するために、OpenShift Container Platform 4.9 では、デフォルトのロードバランシングアルゴリズムが leastconn に戻されました。大幅なメモリー使用量を発生させないソリューションが開発されれば、OpenShift Container Platform の将来のリリースでデフォルトが random に変更される予定です。

以下のコマンドを入力することで、デフォルトの設定を確認することができます。

$ oc get deployment -n openshift-ingress router-default -o yaml | grep -A 2 ROUTER_LOAD_BALANCE_ALGORITHM
        - name: ROUTER_LOAD_BALANCE_ALGORITHM
          value: leastconn

random のオプションはまだ利用可能です。しかし、このアルゴリズムの選択の恩恵を受けたいルートは、以下のコマンドを入力して、ルートごとにアノテーションでそのオプションを明示的に設定する必要があります。

$ oc annotate -n <NAMESPACE> route/<ROUTE-NAME> "haproxy.router.openshift.io/balance=random"

(BZ#2015829)

OpenShift Container Platform のシングルノード設定では、リアルタイムカーネル (kernel-rt) を使用した場合、非リアルタイムカーネルを使用した場合に比べて Pod の作成に 2 倍以上の時間がかかります。kernel-rt を使用した場合、ノードの再起動後のリカバリータイムが影響を受けるため、Pod の作成に時間がかかり、サポートされる Pod の最大数に影響が出ます。

回避策として、kernel-rt を使用する場合は、rcupdate.rcu_normal_after_boot=0 カーネル引数で起動することで、復旧時間を短縮できます。これには、リアルタイムカーネルバージョン kernel-rt-4.18.0-305.16.1.rt7.88.el8_4 以上が必要です。この既知の問題は、OpenShift Container Platform のバージョン 4.8.15 以上に該当します。(BZ#1975356)

DU ノードのゼロタッチプロビジョニング (ZTP) のインストール時に Operator のインストールが失敗する場合があります。InstallPlan API はエラーを報告します。報告されるエラーメッセージは、Bundle unpacking failed.Reason: DeadlineExceeded です。このエラーは、Operator インストールジョブが 600 秒を超えると発生します。

回避策として、失敗した Operator に対して以下の oc コマンドを実行して、Operator のインストールを再試行します。

SR-IOV Operator と Machine Config Operator(MCO) の間に競合状態が存在します。これは、DU ノードの ZTP インストールプロセス中に断続的に発生し、さまざまな形で現れます。競合状態により、以下のエラーが生じる可能性があります。