1.6. 既知の問題

ImageContentSourcePolicy はリリース時にレジストリーではサポートされません (BZ#1787112)。非接続環境では、Jenkins を有効にして、デフォルトでプルスルー (pull through) を実行できます。このコマンドを、非接続環境で Jenkins を使用するための回避策として使用できます。

$ oc tag <jenkins_source_image> jenkins:2 --reference-policy=source -n openshift

OpenShift Container Platform クラスターを 4.1 から 4.2、次いで 4.3 にアップグレードする場合、Node Tuning Operator のチューニングされた Pod が ContainerCreating 状態のままになる可能性があります。

問題を確認するには、以下を実行します。

$ oc get pods -n openshift-cluster-node-tuning-operator

1 つ以上のチューニングされた Pod が ContainerCreating 状態のままになっています。

この問題を解決するには、以下の回避策を適用します。以下を実行します。

$ oc delete daemonset/tuned -n openshift-cluster-node-tuning-operator
$ oc get daemonset/tuned -n openshift-cluster-node-tuning-operator
$ oc get pods -n openshift-cluster-node-tuning-operator

Pod が Running 状態にあることを確認します。(BZ#1791916)

Node Feature Discovery (NFD) Operator バージョン 4.3 は、OpenShift Container Platform Web コンソールの OpertorHub からのデプロイに失敗します。回避策として、オペレーティングシステムの oc クライアントをダウンロードし、インストーラーから kubeconfig ファイルを ~/.kube/configに配置します。これらのコマンドを実行して、CLI および GitHub から NFD Operator をデプロイします。

$ cd $GOPATH/src/openshift
$ git clone https://github.com/openshift/cluster-nfd-operator.git
$ cd cluster-nfd-operator
$ git checkout release-4.3
$ PULLPOLICY=Always make deploy
$ oc get pods -n openshift-nfd

出力例:

$ oc get pods -n openshift-nfd
NAME READY STATUS RESTARTS AGE
nfd-master-gj4bh 1/1 Running 0 9m46s
nfd-master-hngrm 1/1 Running 0 9m46s
nfd-master-shwg5 1/1 Running 0 9m46s
nfd-operator-b74cbdc66-jsgqq 1/1 Running 0 10m
nfd-worker-87wpn 1/1 Running 2 9m47s
nfd-worker-d7kj8 1/1 Running 1 9m47s
nfd-worker-n4g7g 1/1 Running 1 9m47s

(BZ#1793535)

クラスター全体の egress プロキシーが設定され、後に設定が解除される場合、OLM 管理の Operator によって以前にデプロイされたアプリケーションの Pod は CrashLoopBackOff 状態になります。これは、デプロイされた Operator がプロキシーに依存するように設定されているために生じます。

OpenShift Container Platform の今後のリリースで修正が予定されていますが、CLI または Web コンソールを使用してデプロイメントを削除することで問題を回避することができます。これにより、OLM が Deployment を再生成し、正しいネットワーク設定で Pod を開始します。

クラスター管理者は、以下のコマンドを実行して、影響を受ける OLM が管理する全 Deployment の一覧を取得できます。

$ oc get deployments --all-namespaces \
    -l olm.owner,olm.owner!=packageserver 1

(BZ#1751903)

Day 2 のプロキシーサポート対応に関して Machine Config Operator (MCO) で問題が生じます。既存のプロキシーされていないクラスターがプロキシーを使用するように再設定されるタイミングが記述されます。MCO は ConfigMap の新たに設定されたプロキシー CA 証明書を RHCOS 信頼バンドルに適用する必要がありますが、これが正常に機能しません。回避策として、プロキシー CA 証明書を信頼バンドルに手動で追加してから、信頼バンドルを更新する必要があります。

$ cp /opt/registry/certs/<my_root_ca>.crt /etc/pki/ca-trust/source/anchors/
$ update-ca-trust extract
$ oc adm drain <node>
$ systemctl reboot

(BZ#1784201)

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

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

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

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