1.6. バグ修正

今回の更新以前は、OpenShift Container Platform 4.7.x 以前でイメージ変更トリガーを含むビルド設定を作成している場合、イメージ変更トリガーはビルドを継続的にトリガーする可能性があります。

この問題は、ビルドの BuildConfig 仕様から lastTriggeredImageID フィールドは非推奨となり、ビルドをインスタンス化する前にイメージ変更トリガーコントローラーがそのフィールドをチェックしなくなったために生じました。OpenShift Container Platform 4.8 では、イメージ変更トリガーコントローラーがチェックするために必要なステータスの新規フィールドが導入されましたが、これは実行しませんでした。

今回の更新により、イメージ変更トリガーコントローラーは、仕様の正しいフィールドと最後にトリガーされたイメージ ID のステータスを継続的にチェックするようになりました。今回のリリースより、必要な場合にのみビルドがトリガーされるようになりました。(BZ#2004203)

今回の更新以前は、OpenShift 同期 Jenkins プラグインのバージョン 1.0.48 におけるパフォーマンスの向上により、Jenkins Kubernetes プラグイン Pod テンプレートにマップされる ConfigMap および ImageStream オブジェクトに受け入れられるラベルが誤って指定されていました。その結果、プラグインは jenkins-agent ラベルの付いた ConfigMap および ImageStream オブジェクトから Pod テンプレートをインポートしなくなりました。

今回の更新により、受け入れ可能なラベル仕様が修正され、プラグインが jenkins-agent ラベルを持つ ConfigMap および ImageStream オブジェクトから Pod テンプレートをインポートするようになりました。(2034839)

以前のバージョンでは、OpenShift Container Platform のアップグレード時に、2 つの Prometheus Pod が同じノードにあるか、Pod が同じ間隔で再起動されるために Prometheus サービスが利用できなくなる可能性がありました。この状態は、Prometheus Pod にはノードの配置に関するソフト非アフィニティールールがあり、PodDisruptionBudget リソースがプロビジョニングされていないために生じました。そのため、メトリックは収集されず、ルールが一定期間評価されませんでした。

この問題を修正するために、Cluster Monitoring Operator(CMO) は 2 つの Prometheus Pod が異なるノードにスケジュールされるようにハード非アフィニティールールを設定するようになりました。CMO は PodDisruptionBudget リソースもプロビジョニングし、1 つ以上の Prometheus Pod が常に実行されていることを確認します。その結果、アップグレード時に、ノードは 1 つ以上の Prometheus Pod が常に実行されるように順番に再起動するようになりました。(BZ#1933847)

以前のバージョンでは、2 つの Thanos Ruler Pod が含まれるノードが停止した場合に、Thanos Ruler サービスが利用不可能になりました。この状況は、Thanos Ruler Pod にはノードの配置に関するソフト非アフィニティールールのみがあるために発生しました。そのため、ユーザー定義のルールは、ノードがオンラインに戻るまで評価されませんでした。

今回のリリースにより、Cluster Monitoring Operator (CMO) はハード非アフィニティールールを設定し、2 つの Thanos Ruler Pod が異なるノードにスケジュールされるようになりました。その結果、単一ノードの停止により、ユーザー定義のルール評価にギャップが発生しなくなりました。(BZ#1955490)

以前のバージョンでは、2 つの Prometheus Pod が同じノードにあり、ノードが停止すると Prometheus サービスが利用できませんでした。この状態は、Prometheus Pod にはノードの配置に関するソフト非アフィニティールールのみがあるために発生しました。そのため、メトリックは収集されず、ノードがオンラインに戻るまでルールは評価されませんでした。

今回のリリースにより、Cluster Monitoring Operator はハード非アフィニティールールを設定して、2 つの Prometheus Pod が異なるノードにスケジュールされるようになりました。その結果、Prometheus Pod は異なるノードにスケジュールされ、単一ノードの停止により、モニタリングにギャップが生じることはなくなりました (BZ#1949262)。

以前のバージョンでは、ユーザー定義のモニタリングが有効にされている場合に、Prometheus Operator コンポーネントのアラートは openshift-user-workload-monitoring namespace を実行する Prometheus Operator には適用されませんでした。そのため、openshift-user-workload-monitoring namespace を管理する Prometheus Operator で問題が発生した場合にアラートが発生しませんでした。

今回のリリースにより、アラートが変更され、openshift-monitoring および openshift-user-workload-monitoring namespace の両方をモニターできるようになりました。その結果、クラスター管理者は、ユーザー定義のモニタリングを管理する Prometheus Operator で問題が発生した場合にアラート通知を受信するようになりました。(BZ#2001566)

以前のバージョンでは、node-exporter エージェントの DaemonSet Pod の数がクラスター内のノード数と等しくない場合、Cluster Monitoring Operator (CMO) は動作が degraded 状態を報告していました。この問題は、ノードのいずれかが ready 状態にない場合に発生しました。

本リリースでは、node-exporter エージェントの DaemonSet Pod の数が、クラスター内の準備状態にあるノード数よりも少なくないことを検証するようになりました。このプロセスでは、node-exporter Pod がすべてのアクティブなノードで実行されるようにします。その結果、ノードのいずれかが Ready 状態にない場合に CMO は degraded 状態を報告しません。(BZ#2004051)

今回の更新以前は、クラスターイメージ設定の各種の許可およびブロックされたレジストリー設定オプションにより、Cluster Samples Operator がイメージストリームを作成できなくなる可能性があります。その結果、Samples Operator は、一般的な OpenShift Container Platform インストールおよびアップグレードのステータスに影響を与えるために、それ自体を degraded とマークする可能性があります。

各種の状況では、Cluster Samples Operator の管理状態は Removed に移行することができます。今回の更新により、イメージコントローラー設定パラメーターがデフォルトのイメージレジストリーまたは samplesRegistry 設定で指定されたイメージレジストリーを使用してイメージストリームを作成できない場合にこれらの状況が含まれるようになりました。Operator のステータスには、クラスターイメージ設定がサンプルイメージストリームの作成を妨げていることも示されるようになりました。(BZ#2002368)