1.6. 既知の問題
- Service Mesh をインストールしている場合、OpenShift Container Platform をアップグレードする前に Service Mesh をアップグレードします。回避策については、「Updating OpenShift Service Mesh from version 1.0.1 to 1.0.2」を参照してください。
- クラスターのロールバインディングや SCC (Security Context Constraints) などのリソースを含む、クラスタースコープのリソースが依然としてアプリケーション移行ツールによって処理されません。移行するアプリケーションがソースクラスターのこれらのクラスタースコープのリソースに依存する場合、それらが宛先クラスターで再作成されていることを手動で確認します。これらのリソースを処理できるように、今後のリソースで対象範囲が拡張されます。
- 4.2.0 Dynamic Host Configuration Protocol (DHCP) は現時点でいずれの Multus CNI プラグイとも連動しません。(BZ#1754686)
- クラスターローダーは設定なしで呼び出される場合に失敗します。(BZ#1761925)
-
Cluster Network Operator は、追加のネットワークが
additionalNetworksコレクションから削除される際に、Operator が以前に作成したNetworkAttachmentDefinitionを削除しません。(BZ#1755586) -
Prometheus Operator は
StatefulSetをデプロイし、rules-configmap-reloaderコンテナー上に値が小さすぎるメモリー制限を作成します。(BZ#1735691) - Multus CNI IPAM で dhcp モードを設定すると失敗します。(BZ#1754682)
-
ClusterResourceQuotaのバージョン 4.1 から 4.2 でのスキーマの変更により、破損が生じます。(BZ#1755125) - ベアメタルや vSphere を含む各種のデプロイメントについての障害復旧が機能しません。(BZ#1718436)
-
Cluster Network Operator から
simpleMacvlanConfigを削除しても、古いnetwork Cluster Network Operator-attachment-definitionは削除されません。これらのリソースは手動で削除する必要があります。(BZ#1755586) - NAD が手動で作成されると、SRIVO Operator Pod がクラッシュします。(BZ#1755188)
-
kube-controller-managerにプロキシーが設定されません。(BZ#1753467) -
HTTPS プロキシーを通過する
git clone操作は失敗します。非 TLS (HTTP) プロキシーは問題なく使用できます。(BZ#1750650) - 非接続環境のイメージミラーに関連するイメージ参照を使用するビルドは、ミラーで認証が必要な場合にこれらのイメージ参照のプルまたはプッシュに失敗します。(BZ#1745192)
- イメージストリームのインポートはミラーを使用しません。多くの場合、これは非接続環境で使用されます。(BZ#1741391)
- OpenShift Container Platform 4.2 は、この Red Hat OpenStack Platform 15 バグが修正されるまで Red Hat OpenStack Platform 15 では機能しません。(BZ#1751942)
-
ビルドがビルドシークレットを使用する場合、
imageOptimizationPolicy: SkipLayersを使用してレイヤーを非表示の状態にすることを強くお勧めします。そうしない場合、シークレットはsourceおよびdockerストラテジービルドでリークされる可能性があります。 - AllowVolumeExpansion および他の StorageClass 属性は、OpenShift Container Platform のアップグレード時に更新されません。デフォルトの StorageClass を削除し、アップグレードの完了後に ClusterStorageOperator が適切な属性でこれを再作成できるようにすることが推奨されます。(BZ#1751641)
- Topology リソースパネルのサーバーレス以外のワークロードにサーバーレスワークロードのリソースが表示されます。(BZ#1760810)
- Topology ビュー、Resources サイドパネル、および Deployment Config Details ページの Pod ステータスの記述に一貫性がありません。(BZ#1760827)
- Add ページオプションを使用してアプリケーションが作成される場合、デプロイされたイメージは選択されたターゲットポートを無視し、常に最初のエントリーを使用します。(BZ#1760836)
- アプリケーション名やビルドステータスなどの一部の特長について、Edge ブラウザーの Topology ビューでレンダリングされません。(BZ#1760858)
- ロールアウト失敗時のアクティブな Pod の判別が Topology ビューで正しく行われない可能性があります。(BZ#1760828)
クラスター全体の egress プロキシーが設定され、後に設定が解除される場合、OLM 管理の Operator によって以前にデプロイされたアプリケーションの Pod は
CrashLoopBackOff状態になります。これは、デプロイされた Operator がプロキシーに依存するように設定されているために生じます。注記この問題は、クラスター全体の egress プロキシーで作成される環境変数、Volume、および VolumeMount に適用されます。これは、SubscriptionsConfig オブジェクトを使用して環境変数、Volume、および VolumeMount を設定する際にも同じ問題が発生します。
OpenShift Container Platform の今後のリリースで修正が予定されていますが、CLI または Web コンソールを使用してデプロイメントを削除することで問題を回避することができます。これにより、OLM が Deployment を再生成し、正しいネットワーク設定で Pod を開始します。
クラスター管理者は、以下のコマンドを実行して、影響を受ける OLM が管理する全 Deployment の一覧を取得できます。
$ oc get deployments --all-namespaces \ -l olm.owner,olm.owner!=packageserver 1- 1
- 影響を受けない
packageserverを除きます。
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
