1.7. 既知の問題

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

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

OpenShift Container Platform 4.6.8 では、Cluster Logging Operator (CLO) で証明書が再生成される方法が変更されたバグ修正が導入されました。今回の修正により、OpenShift Elasticsearch Operator (EO) がクラスターの再起動を試行する際に CLO が証明書を再生成する可能性が出る問題が生じました。これにより、EO とクラスター間の通信で問題が生じ、EO ノードが一致しない証明書を持つことが予想されます。

Elasticsearch のアップグレード時に、一致しない証明書によって問題が発生する可能性がありました。回避策として、CLO と EO を別々にアップグレードできます。これが機能しない場合は、以下のコマンドを実行して Elasticsearch Pod を再起動します。

$ oc delete pod -l component=es

Pod の再起動後に、一致しない証明書が修正され、アップグレードの問題が解決されます。(BZ#1906641)

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

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

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

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

operator-sdk new または operator-sdk create api コマンドを --helm-chart フラグを指定せずに実行すると、デフォルトのボイラープレート Nginx チャートを使用する Helm ベースの Operator がビルドされます。このサンプルチャートはアップストリーム Kubernetes で正常に機能しますが、OpenShift Container Platform では正常にデプロイできません。

この問題を回避するには、--helm-chart フラグを使用して、OpenShift Container Platform に正常にデプロイされる Helm チャートを提供します。以下は例になります。

$ operator-sdk new <operator_name> --type=helm \
  --helm-chart=<repo>/<name>

(BZ#1874754)

インストーラーでプロビジョニングされるインフラストラクチャーの Google Cloud Platform (GCP) で実行しているクラスターを破棄する際に、インフラストラクチャー ID の接頭辞のないマシンが使用するファイアウォールルールが保持されます。これにより、インストールプログラムの破棄プロセスが失敗します。回避策として、GCP Web コンソールでマシンのファイアウォールルールを手動で削除する必要があります。

$ gcloud compute firewall-rules delete <firewall_rule_name>

見つからないインフラストラクチャー ID を持つマシンのファイアウォールルールが削除されると、クラスターを破棄できます。(BZ#1801968)

OpenShift Container Platform 4.6 では、リソースメトリクス API サーバーはカスタムリソースのサポートを提供します。リソースメトリクス API サーバーは OpenAPI 仕様を実装せず、以下のメッセージが kube-apiserver ログに送信されます。

controller.go:114] loading OpenAPI spec for "v1beta1.metrics.k8s.io" failed with: OpenAPI spec does not exist
controller.go:127] OpenAPI AggregationController: action for item v1beta1.metrics.k8s.io: Rate Limited Requeue.

場合によっては、これらのエラーによって KubeAPIErrorsHigh アラートが実行される可能性はありますが、OpenShift Container Platform 機能の低下についての根本的な問題は認識されません。(BZ#1819053)

AWS アカウントが、グローバル条件を使用してすべてのアクションを拒否するか、または特定のパーミッションを要求する AWS Organizations サービスコントロールポリシー (SCP) を使用するように設定されている場合、パーミッションを検証する AWS ポリシーシミュレーター API が誤検出を生成します。パーミッションを検証できない場合、提供される認証情報にインストールに必要なパーミッションがある場合でも、OpenShift Container Platform AWS のインストールに失敗します。

この問題を回避するには、credentialsMode パラメーターの値を install-config.yaml 設定ファイルに設定して、AWS ポリシーシミュレーターのパーミッションチェックをバイパスできます。credentialsMode の値は、Cloud Credential Operator (CCO) の動作を 3 つのサポートされるモード のいずれかに変更します。

apiVersion: v1
baseDomain: cluster1.example.com
credentialsMode: Mint 1
compute:
- architecture: amd64
  hyperthreading: Enabled
...

このチェックを省略する場合、指定する認証情報に、指定されたモードに必要なパーミッション があることを確認します。

(BZ#1829101)

セキュリティーを強化するために、NET_RAW および SYS_CHROOT 機能は CRI-O 機能のデフォルトリストで選択できなくなりました。

NET_RAW および SYS_CHROOT 機能は OpenShift Container Platform 4.5.16 のデフォルト機能として削除されています。4.5.16 よりも前のリリースで作成されたクラスターへの影響を軽減するために、デフォルトの機能一覧は、 99-worker-generated-crio-capabilities および 99-master-generated-crio-capabilities などの別個のマシン設定に含まれるようになりました。OpenShift Container Platform は、以前のリリースから更新する際に新規マシン設定を作成します。

アップグレード後に、NET_RAW および SYS_CHROOT 機能を無効にしてから、ワークロードをテストすることが推奨されます。これらの機能を削除する準備ができたら、 99-worker-generated-crio-capabilities および 99-master-generated-crio-capabilities マシン設定を削除します。

重要: 以前のリリースから更新する場合は、4.6 に更新する前に 4.5.16 に更新してください。(BZ#1874671).

TLS 検証を必要とする oc コマンドの場合、証明書が Subject Alternative Name を設定しない場合、検証は Common Name フィールドにフォールバックせず、コマンドは以下のエラーを出して失敗します。

x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0

回避策として、適切な Subject Alternative Name が設定された証明書を使用するか、または oc コマンドに GODEBUG=x509ignoreCN=0 を付けてこの動作を一時的に上書きできます。

今後の 4.6 z-stream はエラーではなく警告を返す可能性があり、ユーザーは証明書を準拠するよう更新するためにより長い時間を確保できる可能性があります。

(BZ#1889204)

管理者は、redhat-operators カタログをミラーリングして、ネットワークが制限された環境 (非接続クラスターとしても知られる) の OpenShift Container Platform 4.6 クラスターで Operator Lifecycle Manager (OLM) を使用できます。ただし、以下の Operator は、予想されるパブリックホスト名 registry.redhat.io ではなく、プライベートホスト名 registry-proxy.engineering.redhat.com で mapping.txt ファイルのエントリーを返します。

これにより、イメージのプルはアクセス不可能なプライベートレジストリー (通常は内部 Red Hat テスト用) に対して失敗します。この問題を回避するには、mapping.txt ファイルを生成した後に以下のコマンドを実行します。

$ sed -i -e 's/registry-proxy.engineering.redhat.com/registry.redhat.io/g' \
    -e 's/rh-osbs\/amq7-/amq7\//g' \
    -e 's/amq7\/tech-preview-/amq7-tech-preview\//g' \
    ./redhat-operator-index-manifests/imageContentSourcePolicy.yaml \
    ./redhat-operator-index-manifests/mapping.txt

PowerVM での IBM Power Systems の OpenShift Container Platform については、以下の制限を優先的に考慮してください。

Red Hat Operator の公開プロセスのバグにより、OpenShift Container Platform 4.6 インデックスイメージのステージ環境用のバージョンが一時的に公開されました。このバグが解決され、イメージが正しいコンテンツですぐに再公開されました。

このステージレジストリーイメージの使用時に Operator のインストールまたはアップグレードを試行する場合、openshift-marketplace namespace のジョブは、予想されるパブリックホスト名の registry.redhat.io ではなく、プライベートホスト名の registry.stage.redhat.io を示す以下のエラーを出して失敗する可能性がありました。

ImagePullBackOff for
Back-off pulling image "registry.stage.redhat.io/openshift4/ose-elasticsearch-operator-bundle@sha256:6d2587129c746ec28d384540322b40b05833e7e00b25cca584e004af9a1d292e"

rpc error: code = Unknown desc = error pinging docker registry registry.stage.redhat.io: Get "https://registry.stage.redhat.io/v2/": dial tcp: lookup registry.stage.redhat.io on 10.0.0.1:53: no such host

これにより、イメージのプルはアクセス不可能なプライベートレジストリー (通常は内部 Red Hat テスト用) に対して失敗し、関連する Operator のインストールおよびアップグレードは失敗しました。この問題の回避策については、問題のあるサブスクリプションの更新 について参照してください。(BZ#1909152)