1.7. バグ修正

assisted-installer

以前のバージョンでは、assisted-service コンテナーは postgres が起動し、接続を受け入れる準備ができるのを待ちませんでした。assisted-service コンテナーはデータベース接続を確立しようとして失敗し、そして assisted-service コンテナーが失敗して再起動していました。この問題は、assisted-service コンテナーが、最大 10 秒間データベースに接続しようとすることで修正されました。postgres が起動して 10 秒以内に接続を受け入れる準備ができると、assisted-service コンテナーはエラー状態に進むことなく接続します。assisted-service コンテナーが 10 秒以内に postgres に接続できない場合、エラー状態になり、再起動し、再度試みます。(BZ#1941859)

ベアメタルハードウェアのプロビジョニング

以前のバージョンでは、Ironic はデフォルトで HTTPS を使用し、正しい証明書バンドルを利用できなかったため、インストール用のイメージのダウンロードに失敗していました。この問題は、イメージのダウンロードを Insecure に設定して、証明書なしで転送を要求することで修正されています。(BZ#1953795)
以前のバージョンでは、デュアルスタックネットワークを使用する場合、ワーカーノードのホスト名は、デプロイメントの前に Ironic が検査するホスト名と一致しないことがありました。そのため、ノードを手動で承認する必要がありました。これは修正されています。(BZ#1955114)
以前のバージョンでは、UEFI モードでは、RHCOS イメージのダウンロード後に ironic-python-agent が UEFI ブートローダーエントリーを作成していました。RHEL 8.4 に基づく RHCOS イメージを使用する場合、このエントリーを使用してイメージを起動できない可能性があります。イメージの起動時に Ironic によりインストールされたエントリーが使用された場合、起動に失敗し、BIOS エラー画面が出力される可能性があります。これは、固定のブートエントリーを使用する代わりに、イメージにある CSV ファイルに基づいてブートエントリーを設定する ironic-python-agent により修正されています。イメージはエラーなしで正常に起動します。(BZ#1972213)
以前のバージョンでは、ノードは、起動時に誤った IP バージョンを選択することがありました (IPv4 ではなく IPv6 を選択したり、またはその逆の場合もあり)。ノードは IP アドレスを受信しなかったために起動できませんでした。これは、IP オプションを downloader (ip=dhcp or ip=dhcp6) に渡す Cluster Bare Metal Operator によって修正され、これにより、起動時に正しく設定され、ノードは予想どおりに起動します。(BZ#1946079)
以前のバージョンでは、Ironic のイメージキャッシュメカニズムが無効化され、virtualmedial iso をホストする HTTP サーバーへの直接接続を有効化し、ローカルストレージの問題を阻止していました。標準に準拠しない HTTP クライアントおよび redfish 実装により、BMC 接続でで障害が発生しました。これは、virtualmedia iso がキャッシュされ、Ironic conductor ノードから提供されるデフォルトの Ironic の動作に戻すことで修正されています。標準に準拠しない HTTP クライアントおよび redfish 実装によって生じる問題が修正されました。(BZ#1962905)
以前のバージョンでは、マシンインスタンスの state アノテーションは設定されていませんでした。その結果、STATE 列は空でした。今回の更新により、マシンインスタンスの state アノテーションが設定され、STATE 列の情報が自動的に入力されるようになりました。(BZ#1857008)
新しい ipmitool パッケージはデフォルトで暗号化スイート 17 を使用するため、暗号化スイート 17 をサポートしない古いハードウェアはデプロイメント中に失敗します。暗号化スイート 17 がハードウェアでサポートされない場合は、ipmitool を使用する古いハードウェアで正常にデプロイメントされるように、Ironic は暗号化スイート 3 を使用するようになりました。(BZ#1897415)
以前のバージョンでは、イメージキャッシュの設定前に導入が実行されたため、永続的な導入に失敗し、再試行されることはありませんでした。これにより、コントロールプレーンのベアメタルホストが adoption failed を報告しました。この更新により、外部でプロビジョニングされるホストの導入は、導入の失敗後にコントロールプレーンホストが正しく導入されるまで自動的に再試行されます。(BZ#1905577)
以前のバージョンでは、カスタムリソース (CR) には、ベースボード管理コントローラー (BMC) の詳細が必要でした。ただし、アシスト付きインストーラーの場合は、この情報が提供されませんでした。この更新により、Operator がノードを作成していないときに、CR が BMC の詳細をバイパスできるようになります。(BZ#1913112)
イメージをノードにプロビジョニングする場合、qemu-image は 1G の RAM に制限されていたため、qemu-img がクラッシュする可能性がありました。この修正により、制限が 2G に引き上げられ、qemu-img がプロビジョニングを確実に完了するようになりました。(BZ#1917482)
redfish/v1/SessionService URL には認証が必要なため、Ironic はサイトにアクセスする際に認証エラーを生成します。Ironic がこのエラーメッセージを報告した際、機能上の問題はなかったため、削除されました。(BZ#1924816)
一部のドライブでは、/dev/sda1 などのパーティションには読み取り専用ファイルがありませんでした。ただし、/dev/sda などのベースデバイスにはこのファイルがあります。そのため、Ironic はパーティションが読み取り専用であることを判断できず、そのドライブでメタデータのクリーニングが失敗する可能性がありました。この更新により、パーティションが読み取り専用として検出され、ベースデバイスの追加チェックが含まれるようになります。その結果、メタデータのクリーニングは読み取り専用パーティションで実行されず、メタデータのクリーニングが失敗しなくなりました。(BZ#1935419)
プロキシーが設定された状態で Baremetal IPI がデプロイされると、内部の machine-os イメージのダウンロードはプロキシーを介して送信されました。これによりイメージが破損し、ダウンロードできなくなりました。この更新により、内部イメージトラフィックが no_proxy に修正され、イメージのダウンロードでプロキシーが使用されなくなります。(BZ#1962592)
以前のバージョンでは、Ironic と RAM ディスク間の大規模なパケット転送によって接続障害が発生した場合、ベアメタルのデプロイメントは失敗していました。今回の更新により、Ironic は、接続エラーを回避するための情報を RAM ディスクにクエリーし、デプロイメントを正常に実行できるようになりました。(BZ#1957976)

ビルド

以前のバージョンでは、CVE-2021-3344 が修正された後、ビルドは OpenShift Container Platform ノードにエンタイトルメントキーを自動的にマウントしませんでした。その結果、エンタイトルメント証明書がホストまたはノードに保存されていた場合は、修正により、エンタイトルメントのあるビルドがシームレスに機能しなくなりました。ホストまたはノードに保存されているエンタイトルメント証明書の取り込みの失敗は、4.7.z では BZ#1945692 で修正され、4.6.z では BZ#1946363 で修正されました。ただし、これらの修正では、Red Hat Enterprise Linux CoreOS (RHCOS) ワーカーノードで実行されているビルドに無害な警告メッセージが導入されました。現在のリリースでは、ビルドが RHEL ワーカーノードにのみエンタイトルメントを自動的にマウントできるようにし、RHCOS ワーカーノードでのマウント試行を回避することで、この問題を修正しています。これで、RHCOS ノードでビルドを実行するときに、エンタイトルメントのマウントに関する無害な警告メッセージが表示されなくなります。(BZ#1951084)
Docker Hub からイメージをプルする一部のユーザーには、以下のエラーが発生する可能性があります。
```
container image registry lookup failed...toomanyrequests: You have reached your pull rate limit
```
このエラーは、oc new-app の呼び出しに使用した docker.io ログインに docker.io の有料サポートが十分にないために発生します。結果として得られるアプリケーションは、イメージプルスロットリングの対象となり、障害が発生する可能性があります。現在のリリースでは、oc new-app ヘルプが更新され、イメージレジストリーおよびリポジトリー仕様でデフォルトがどのように機能するかをユーザーに通知します。これによりユーザーは、可能な場合、デフォルト以外のイメージ参照を使用して、同様のエラーを回避できます。(BZ#1928850)
以前のバージョンでは、ビルドはイメージのプッシュが失敗したかどうかを確認するためのエラーチェックを実行しませんでした。その結果、ビルドは常に Successfully pushed のメッセージをログに記録します。現在、ビルドはエラーが発生したかどうかをチェックし、イメージのプッシュが成功した後にのみ、Successfully pushed のメッセージをログに記録します。(BZ#1947164)
以前のバージョンでは、ドキュメントおよび oc explain ヘルプテキストは、BuildConfig オブジェクト内の buildArgs フィールドが、その基礎となる Kubernetes EnvVar タイプの valueFrom フィールドをサポートしていないことを伝えていませんでした。その結果、ユーザーはそれがサポートされていると信じて使用しようとしました。現在のリリースでは、ドキュメントとヘルプテキストが更新されているため、BuildConfig オブジェクトの buildArgs フィールドが valueFrom フィールドをサポートしていないことがより明確になっています。(BZ#1956826)
ビルドがベースイメージのプルなどのイメージレジストリーと対話する場合、断続的な通信の問題によりビルドが失敗する可能性があります。現在のリリースでは、これらの対話に対する再試行回数が増えています。現在の OpenShift Container Platform ビルドは、イメージレジストリーとの断続的な通信の問題が発生した場合、以前よりも回復力があります。(BZ#1937535)

クラウドコンピュート

以前のバージョンでは、Cluster Image Registry Operator は user_domain_name を不変フィールドと見なし、インストール後に変更しませんでした。これにより、user_domain_name および生成される認証情報への変更を受け入れることが拒否されました。今回の更新により、user_domain_name が変更可能としてマークされ、イメージレジストリー設定に保存されなくなりました。これにより、user_domain_name およびその他すべての auth パラメーターをインストール後に変更できます。(BZ#1937464)
以前のバージョンでは、プロキシーの更新により、継続的インテグレーション (CI) の実行中に、API サーバーの再起動を含む完全なクラスター設定の更新が発生していました。その結果、Machine API Operator の一部のクラスターは、予期しない API サーバーの停止が原因でタイムアウトになっていました。この更新により、プロキシーテストが分離され、事後条件が追加されるため、CI の実行中は Machine API Operator のクラスターが再び安定します。(BZ#1913341)
以前のバージョンでは、さまざまな vCenter タスクタイプの区別がなかったため、Insufficient disk space on datastore 状態のマシンを削除するには、想定外の時間がかかりました。この更新により、マシンコントローラーの削除手順で vCenter タスクタイプがチェックされたため、マシンコントローラーの削除がブロックされなくなりました。その結果、マシンコントローラーはすぐに削除されます。(BZ#1918101)
以前のバージョンでは、インスタンスタイプがない場合でも、ゼロアノテーションからのスケーリングが再びキューに入れられていました。その結果、MachineSet コントローラーログに一定の再キューおよびエラースペースメッセージがありました。この更新では、インスタンスタイプが自動的に解決されない場合、ユーザーはアノテーションを手動で設定することができます。その結果、ユーザーが手動でアノテーションを提供した場合、不明なインスタンスタイプのゼロからのスケーリングが機能します。(BZ#1918910)
以前のバージョンでは、HTTP 応答は Machine API 終了ハンドラーによって適切に閉じられていませんでした。その結果、goroutine が net.http の読み取りおよび書き込みループでリークされ、メモリー使用量が高くなりました。今回の更新で、HTTP 応答が常に正常に閉じられるようになりました。その結果、メモリー使用量が安定するようになりました。(BZ#1934021)
以前のバージョンでは、MachineSet コントローラー内で作成された複数のクライアントセットにより起動時間が遅くなり、一部の大規模なクラスターで Pod が readiness チェックに失敗していました。その結果、MachineSet コントローラーは無限ループでスタックします。この更新により、MachineSet コントローラーが修正され、単一のクライアントが使用されるようになります。その結果、MachineSet コントローラーは想定どおりに動作します。(BZ#1934216)
以前のバージョンでは、最初の起動時に Machine Config Daemon によってアップグレードが実行されたときに、インスタンスの起動に時間がかかりました。その結果、ワーカーノードが再起動ループでスタックし、ワーカーノードが適切に起動しなかったため、マシンヘルスチェック (MCH) はワーカーノードを削除しました。この更新により、MHC は正しく開始されていないノードを削除しなくなりました。代わりに、MHC は、明示的に要求された場合にのみノードを削除します。(BZ#1939054)
以前のバージョンでは、不明な理由で証明書署名要求 (CSR) の承認が遅れていました。その結果、インストール中にクラスターに表示される新しいマシンはすぐには承認されず、クラスターのインストールに時間がかかりました。インストールの初期段階で API サーバーがたまに使用できなくなることを減らすために、この更新により、キャッシュの再同期期間が 10 時間から 10 分に変更されます。その結果、コントロールプレーンマシンがより迅速に承認されるようになり、クラスターのインストールが長引くことはなくなりました。(BZ#1940972)
以前のバージョンでは、デフォルトの Google Cloud Platform (GCP) イメージは古く、新しい Ignition バージョンをサポートしない OpenShift Container Platform 4.6 リリースからのバージョンを参照していました。その結果、デフォルトの GCP イメージを使用するクラスター内の新しいマシンは、OpenShift Container Platform 4.7 以降を起動できませんでした。この更新により、GCP イメージがリリースバージョンと一致するように更新されます。その結果、新しいマシンはデフォルトの GCP イメージで起動できるようになりました。(BZ#1954597)
以前のバージョンでは、仮想マシン (VM) の ProvisioningState 値が厳密にチェックされていたため、存在チェック中に仮想マシンが失敗することがありました。この更新により、チェックがより寛容になり、削除されたマシンのみが存在チェック中に Failed フェーズに入ります。(BZ#1957349)
以前のバージョンでは、AWS クラスターで oc delete machine を使用してコントロールプレーンマシンを削除した場合、そのマシンはロードバランサーから削除されていませんでした。その結果、ロードバランサーは、削除されたコントロールプレーンマシンへの要求を引き続き処理しました。この修正により、コントロールプレーンマシンを削除すると、ロードバランサーはマシンへの要求を処理しなくなります。(BZ#1880757)
以前のバージョンでは、到達不能なマシンを削除すると、永続ボリューム用に作成され、ノードに接続されている vSphere 仮想マシンディスク (VMDK) が誤って削除されていました。その結果、VMDK 上のデータは回復できませんでした。この修正により、vSphere クラウドプロバイダーは、kubelet に到達できない場合に、これらのディスクをチェックしてノードからデタッチします。その結果、VMDK を失うことなく、到達不能なマシンを削除できます。(BZ#1883993)
以前のバージョンでは、生成された AWS インスタンスタイプのリストが古くなっていたため、レプリカがゼロの Cluster Autoscaler とマシンセットを使用すると、一部の新しい Amazon Web Services (AWS) インスタンスタイプをゼロからスケーリングできませんでした。AWS インスタンスタイプの一覧が更新され、新しいインスタンスタイプが含まれるようになりました。この修正により、レプリカがゼロからスケーリングするために、より多くのインスタンスタイプを Cluster Autoscaler Operator で使用できるようになります。(BZ#1896321)
以前のバージョンでは、Pod の Disruption Budget では、アップストリームのエビクション API 機能がないため、到達不能なノードで Pod をドレインしませんでした。その結果、到達不能ノード上のマシンは、削除された後に取り除かれるまでに膨大な時間がかかる可能性があります。現在は、到達不能ノード上のマシンを削除するときの猶予期間のタイムアウトが 1 秒に変更されました。この修正により、Machine API は、到達不能なノードを正常にドレインおよび削除できます。(BZ#1905709)

Cloud Credential Operator

以前のバージョンでは、Cloud Credential Operator は、ベアメタルプラットフォームで unsupported platform type: BareMetal 警告を繰り返していました。この更新により、ベアメタルプラットフォームは不明のプラットフォームとして扱われなくなりました。その結果、誤解を招くロギングメッセージが削減されます。(BZ#1864116)
以前のバージョンでは、Cloud Credential Operator の credentialsRequest カスタムリソース (CR) に保存されたエラーメッセージが繰り返し発生するため、CPU 使用率が過度に高くなり、Amazon Web Services (AWS) のレート制限などの一部のエラーシナリオにログインしていました。この更新により、クラウドプロバイダーから返されるリクエスト ID が削除され、エラーメッセージはユーザーが見つけやすい状態で保存され、credentialsRequest CR で繰り返し発生するエラーメッセージが削除されます。(BZ#1910396)
以前のバージョンでは、CCO デプロイメントが正常ではない場合に、Cloud Credential Operator (CCO) および Cluster Version Operator (CVO) の両方が報告しました。これにより、問題がある場合に 2 つのレポートが作成されました。今回のリリースにより、CCO はデプロイメントが正常ではない場合に報告しなくなりました。(BZ#1957424)

Cluster Version Operator

以前のバージョンでは、Cluster Version Operator は cluster_operator_up メトリクスの設定時に Available パラメーターおよび Degraded パラメーターの両方を評価していました。これにより、アラートに記載された has not been available が Available=True に一致しなかった場合でも、ClusterOperatorDown アラートが Available=True または Degraded=True の Operator に対して表示されました。今回の修正により、Cluster Version Operator は cluster_operator_up メトリクスの設定時に Degraded パラメーターを無視するようになりました。(BZ#1834551)
以前のバージョンでは、Prometheus がクラスターにインストールされている場合、重要なプラットフォームトポロジーメトリクスは使用できず、呼び出し元で生成されたインストーラーメトリクスが "" に設定されていると、CI エラーが発生していました。エラーの原因となっているメトリクスが提供される前にインフォーマーが同期されなかった潜在的な競合状態が修正されました。(BZ#1871303)
以前のバージョンでは、Cluster Version Operator の独自デプロイメントなど、同じキーの複数の容認を持つマニフェストは、最後に読み取られたエントリーのみを受け入れ、前のエントリーを上書きしていました。これにより、in-cluster tolerations がマニフェストに記載されている容認から分離されました。この更新により、Cluster Version Operator は、容認が完全に等しい場合に、容認が一致すると見なすようになりました。これにより、Cluster Version Operator は in-cluster resource のマニフェストに存在するすべての容認を保持することができます。(BZ#1941901)
以前のバージョンでは、Cluster Version Operator は、env および envFrom を設定しなかったマニフェストのこれらのプロパティーを調整しませんでした。そのため、Cluster Version Operator はコンテナー環境を適切に管理しませんでした。今回の更新により、Cluster Version Operator が改善され、env および envFrom がマニフェストで未設定の場合は、これらを消去できるようになりました。これにより、クラスターは、これらのプロパティーに対する cluster-admin の無効な変更から自動的に回復できます。(BZ#1951339)
以前のバージョンでは、cluster-version-operator デプロイメントオブジェクトなど、同じキーの複数の容認を持つマニフェストは、最後に読み取られたエントリーのみを受け入れ、前のエントリーを上書きしていました。これにより、クラスター内の容認がマニフェストに記載されている容認から分離されました。この更新により、Cluster Version Operator は、容認が等しい場合に、容認が一致すると見なすようになりました。これにより、Cluster Version Operator は、クラスター内リソースのマニフェストに存在するすべての容認を保持することができます。(BZ#1941901)
以前のバージョンでは、Cluster Version Operator は、ClusterOperator リソースのパフォーマンスが 10 分間低下すると、ClusterOperatorDegraded アラートを報告していました。このアラートは、リソースがまだ作成中だったため、インストールの途中で発生したことがありました。今回の更新により、期間が 10 分から 30 分に変更され、ClusterOperatorDegraded アラートが途中で発生することなく、十分な時間を提供することで、インストールが進行するようになりました。(BZ#1957991)

コンプライアンス Operator

以前のバージョンでは、ユーザーがコンプライアンスチェックを実行し、NON-COMPLIANT の結果が表示された場合に、ユーザーが対応するために必要な修正手順は示されていませんでした。このリリースでは、ユーザーがルールの検証に必要な手順を確認できるように instructions キーが提供されています。これにより、ユーザーおよび監査担当者は Operator が正しい値をチェックしていることを確認できます。(BZ#1919367)

コンソール kubevirt プラグイン

以前は、ユーザーが仮想化テンプレートにブートソースを追加する際に役立つ Web コンソールフォームでは、テンプレートが使用するオペレーティングシステムに関係なく、説明テキストは Fedora に対してのみ情報を提供していました。この更新により、テンプレートのオペレーティングシステムに固有の例を提供する修正が追加され、ユーザーに関連するガイダンスを提供します。(BZ#1908169)
以前のバージョンでは、ユーザーの仮想マシンテンプレートの作成をサポートする Web コンソールウィザードの説明が曖昧だったことから、操作がテンプレートに適用されるのか、または仮想マシンに適用されるのか、わかりにくい点がありました。今回の修正により説明が明確になり、ユーザーは十分な情報に基づいて決定を下すことができます。(BZ#1922063)
以前のバージョンでは、Web コンソールの曖昧なエラーメッセージにより、テンプレートから作成している仮想マシンにネットワークインターフェイスを追加しようとした一部のユーザーに不必要な混乱が生じていました。今回の更新でエラーメッセージに詳細が追加され、ユーザーはより簡単にエラーをトラブルシューティングできるようになりました。(BZ#1924788)
以前のバージョンでは、Web コンソールの Red Hat Enterprise Linux (RHEL) 6 テンプレートから仮想マシンを作成しようとすると、RHEL 6 がサポートされていない場合でも、ポップアップウィンドウにサポートレベルの定義方法に関する情報が表示されていました今回の修正により、このウィンドウのテキストが変更され、RHEL 6 はサポートされていないことを明確にしました。(BZ#1926776)
以前のバージョンでは、Web コンソールのドロップダウンリストがボタン要素によって隠されていたため、ユーザーは仮想マシンの作成時に特定のオペレーティングシステムを選択できませんでした。今回の修正にはボタン要素の z-index 値の調整が含まれ、エラーが修正されたため、ユーザーは使用可能なオペレーティングシステムを選択できるようになります。(BZ#1930015)
以前のバージョンでは、ストレージクラスが定義されていないクラスターで Web コンソールの新しい仮想マシンウィザードを使用した場合、Web コンソールが無限ループに陥ってクラッシュしていました。今回の修正により、ストレージクラスが定義されていないインスタンスのストレージクラスのドロップダウンリストが削除されました。その結果、Web コンソールはクラッシュしません。(BZ#1930064)
以前のバージョンでは、お気に入りリストから仮想マシンテンプレートを削除するというボタンの機能について、ボタン要素のテキストは明確に説明していませんでした。この修正でテキストが更新され、ボタンの機能が明確になりました。(BZ#1937941)
以前のバージョンでは、RerunOnFailure 実行ストラテジーを持つ仮想マシンの場合は、仮想マシンを停止すると、複数の UI 要素が応答しなくなり、ユーザーがステータス情報を読み取ったり、仮想マシンを再起動したりできなくなりました。今回の更新で、応答しない要素が修正され、ユーザーがそれらの機能を使用できるようになりました。(BZ#1951209)
以前のバージョンでは、別の /var パーティションを持つように設定されたクラスターの場合、ファイルシステムにクエリーを実行すると、/var パーティションのサイズを除く、root ディレクトリーにマウントされたディスクのサイズのみが返されていました。今回の修正により、クエリーの実行方法が変更され、ユーザーはクラスター上のファイルシステムの合計サイズを判断できるようになりました。(BZ#1960612)

コンソールストレージプラグイン

以前のバージョンでは、正しいストレージクラスが利用できない場合に OpenShift Container Storage Operator はエラーメッセージを表示していました。今回の更新によりエラーメッセージが削除され、正しいストレージクラスが利用可能になるまで Next ボタンが無効になります。(BZ#1924641)
以前のバージョンでは、内部接続されたストレージクラスターの作成中にユーザーがブラウザーの戻るボタンをクリックすると、インストールウィザードがプロセスを再開しました。今回の更新でこの問題が修正されています。(BZ#1928008)
ノードをローカルボリューム検出に追加すると、既存のノードの一覧を表示できるようになりました。これにより、不要なナビゲーションが削減されます。(BZ#1947311)
以前のバージョンでは、Create Storage Cluster ウィザードを使用すると、未定義の値を持つ Arbiter ゾーンを有効化できました。この更新の修正では、未定義の値がフィルターに掛けられて除外され、Arbiter ゾーンは定義された値でのみ作成できるようになりました。(BZ#1926798)
以前のバージョンでは、製品タイトルの書き方や登録商標記号の使用方法に一貫性がなかったため、Web コンソールでクイックスタートカードが誤って表示されていました。今回の更新では、製品名が正しく表記され、登録商標記号は最初のカードでのみ一貫して表示されます。(BZ#1931760)

DNS

以前のバージョンでは、BZ#1936587 はグローバル CoreDNS キャッシュの最大 TTL を 900 秒に設定しました。そのため、アップストリームリゾルバーから受信される NXDOMAIN レコードが 900 秒間キャッシュされました。今回の更新により、最大 30 秒間、ネガティブな DNS 応答レコードが明示的にキャッシュされるようになりました。その結果、NXDOMAINs の解決は 900 秒間キャッシュされなくなりました。(BZ#1943578)
BZ#1953097 の修正は、サイズが 1232 バイトの CoreDNS bufsize プラグインを有効化しました。一部のプリミティブ DNS リゾルバーは、512 バイトを超える UDP 経由で DNS 応答メッセージを受信できません。その結果、Go の内部 DNS ライブラリーなどの一部の DNS リゾルバーは、DNS Operator から詳細な DNS 応答を受け取ることができません。今回の更新で、すべてのサーバーで CoreDNS bufsize が 512 バイトに設定されました。その結果、UDP DNS メッセージが適切に受信されるようになりました。(BZ#1966116)
以前のバージョンでは、クラスターのアップストリームリゾルバーは、UDP 経由で 512 バイトを超える DNS 応答を返しました。そのため、coreDNS は SERVFAIL または他のエラーメッセージを返し、クライアントに TCP 上で再試行するように強制しました。今回の更新で、UDP バッファーサイズ 1232 バイトで coreDNS bufisze プラグインが有効になりました。(BZ#1949361)

etcd

以前のバージョンでは、etcd Operator でトランスポートリークが発生したため、時間の経過とともにメモリー使用量が増加していました。メモリーリークは修正されました。(BZ#1925586)
以前のバージョンでは、etcdInsufficientMembers アラートが誤って実行されていました。このリリースでは、アラートが更新され、インスタンスラベルに加えて Pod ラベルが含まれるようになり、クォーラムが失われた場合にのみアラートが実行されるようになりました。(BZ#1929944)
以前のバージョンでは、SO_REUSEADDR ソケットオプションの導入により readiness プローブが正しい readiness (準備状態) を報告しませんでした。そのため、etcd-quorum-guard が失敗した場合でも etcd Pod は準備完了と表示されていました。readiness プローブチェックはこれらのオプションを考慮して更新され、etcd readiness プローブはオペランドの readiness を適切に反映するようになりました。(BZ#1946607)
以前のバージョンでは、spec.loglevel フィールドが etcd オペランドに log-level フラグを設定していなかったため、ユーザーは etcd ログレベルを変更できませんでした。ユーザーは、以下のようにログレベルを設定できるようになりました。
- Debug、Trace、および TraceAll ログレベルは、etcd debug ログレベルにマップします。
- Default または Normal ログレベルは、etcd info ログレベルにマップします。
詳細は、BZ#1948553 を参照してください。
以前のバージョンでは、etcd プロセスに従うと、次のプロセスは関連するポートがリリースされるまで開始されませんでした。このプロセスに SO_REUSEADDR を追加すると、ポートをすぐに再利用できます。詳細は、BZ#1927942 を参照してください。
以前のバージョンでは、network.Status.ServiceNetwork フィールドが設定されていないと、etcd-endpoint の ConfigMap は空のままになっていました。その結果、etcd Operator はスケールアップできませんでした。OpenShift Container Platform 4.8 の新規機能により、etcd Operator は network.Status.ServiceNetwork フィールドが設定されていなくてもスケールアップできるようになりました。(BZ#1902247)

イメージレジストリー

以前のバージョンでは、イメージプルーナーはイメージの削除に失敗した際に停止しました。その結果、2 つのイメージプルーナーがイメージの同時削除を試行する場合、それらのいずれかが not found エラーを出して失敗していました。今回の更新により、not found エラーは無視され、イメージプルーナーは同時削除を容認できるようになりました。(BZ#1890828)
以前のバージョンでは、イメージレジストリー Operator のステータス評価中にルートステータスが含まれていなかったため、ルートが degraded 状態であっても、イメージレジストリー Operator のパフォーマンスは低下しませんでした。今回の修正により、イメージレジストリー Operator は設定済みのすべてのルートを取得し、自身のステータスを評価する際にそれらのステータスを評価するようになりました。今回の更新により、ルートのいずれかが degraded の場合、イメージレジストリー Operator はエラーメッセージと共に自身を degrade として報告します。(BZ#1902076)
以前のバージョンでは、自動作成された Docker 設定シークレットには、統合された内部レジストリールートの認証情報が含まれませんでした。いずれかのルートを介してレジストリーにアクセスするための認証情報がなかったため、レジストリーへのアクセスを試行した Pod は認証情報がないために失敗しました。今回の修正では、デフォルトの Docker 認証情報シークレットに設定されたすべてのレジストリールートが含まれています。現在は、認証情報に各ルートのエントリーが含まれるようになったため、Pod は任意のルートで統合レジストリーに到達できるようになりました。(BZ#1911470)
以前のバージョンでは、イメージレジストリーはクラスター全体の ImageContentSourcePolicy (ICSP) ルールを無視していました。プルスルー中にイメージのミラーは無視され、非接続クラスターでプルの失敗が生じました。今回の更新により、ICSP ルールがターゲットリポジトリーに存在する場合、レジストリーはミラーからプルするようになりました。その結果、設定されたミラーからイメージをプルしても失敗しなくなりました。(BZ#1918376)
以前のバージョンでは、イメージレジストリー Operator は設定リソースの .status.readyReplicas フィールドを更新しなかったため、その値は常に 0 でした。今回の修正により、イメージレジストリー Operator は準備状態にあるイメージレジストリーのレプリカ数をデプロイメントから設定に書き込むようになりました。現在、このフィールドには、準備ができているイメージレジストリーレプリカの数が表示されます。(BZ#1923811)
Azure では、v1 ではなく、ストレージアカウント v2 を使用するようユーザーに勧めています。特定のセキュリティープロファイルでは、管理者は Azure に対して v1 ストレージアカウントの作成を許可しないように強制できます。イメージレジストリーは v1 のストレージアカウントに依存するため、クラスターのインストールはこのような環境で失敗します。今回の修正により、クラスターのブートストラップ中に、イメージレジストリー Operator は V2 ストレージアカウントの作成および使用を試みるようになりました。v1 で実行されているクラスターは、引き続き V1 ストレージアカウントを使用します。インストールは成功し、イメージレジストリー Operator が Available を報告するようになりました。(BZ#1929654)

ImageStreams

以前のバージョンでは、ストリームから複数のイメージをインポートする場合にパフォーマンスが遅くなることがありました。今回のリリースにより、イメージレジストリーへの同時要求の数が 5 から 50 に増え、パフォーマンスが向上します。(BZ#1954715)

Insights Operator

以前のバージョンでは、Insights Operator は openshift-cluster-version namespace で Cluster Version Operator (CVO) Pod またはイベントを収集しませんでした。その結果、Insights Operator は、CVO で発生する可能性のある問題に関する情報を表示せず、ユーザーは CVO に関する診断情報を取得できませんでした。Insights Operator が更新され、openshift-cluster-operator namespace から CVO Pod とイベントが収集されることで、CVO の問題が Insights Operator によって報告されるようになりました。(BZ#1942271)

インストーラー

以前は、IPv6 ネットワークが /64 以外になっている場合は、DNSmasq は接頭辞長を指定する必要がありました。その結果、コントロールプレーンのホストは PXE ブートに失敗しました。この更新には、DNSmasq 設定のサブネット接頭辞長が含まれます。その結果、コントロールプレーンホストは、任意の接頭辞長の IPv6 ネットワークで DHCP および PXE ブートを実行します。(BZ#1927068)
vSphere にインストールする場合、ブートストラップマシンは /etc/resolv.conf ファイルのネームサーバーを正しく更新しないことがありました。その結果、ブートストラップマシンは一時的なコントロールプレーンにアクセスできず、インストールは失敗しました。この修正には、更新する適切な行の検索の信頼性を高める変更が含まれています。ブートストラップマネージャーが一時的なコントロールプレーンにアクセスできるようになったため、正常にインストールすることができます。(BZ#1967355)
以前のバージョンでは、インストーラーはその URL の生成時にブートストラップ Ignition 設定を配置するリージョンを考慮しませんでした。その結果、ブートストラップマシンは、提供された URL が正しくないため、設定を取得できませんでした。今回の更新により、URL の生成時にユーザーのリージョンを考慮し、正しいパブリックエンドポイントを選択するようになりました。その結果、インストーラーは常に正しいブートストラップ Ignition URL を生成します。(BZ#1934123)
以前のバージョンでは、ストレージアカウントを作成する際、Azure の最小 TLS のデフォルトバージョンは 1.0 でした。その結果、ポリシーチェックは失敗しました。今回の更新では、ストレージアカウントの作成時に最小 TLS バージョンを 1.2 に設定するように openshift-installer Azure クライアントを設定します。その結果、ポリシーチェックに合格するようになりました。(BZ#1943157)
以前のバージョンでは、Azure で IPI を使用してデプロイされたプライベートクラスターには、ブートストラップノードへの SSH を許可するインバウンド NSG ルールがありました。これにより、Azure のセキュリティーポリシーがトリガーされる可能性があります。今回の更新で、NSG ルールが削除されました。(BZ#1943219)
以前のバージョンでは、インストーラーは ap-northeast-3 AWS リージョンを認識しませんでした。今回の更新により、インストーラーは既知のパーティションのパターンに適合する不明なリージョンへのインストールを許可します。これにより、ユーザーは ap-northeast-3 AWS リージョンでインフラストラクチャーを作成できるようになりました。(BZ#1944268)
以前のバージョンでは、オンプレミスプラットフォームには内部ロードバランサーを作成する機能がありませんでした。今回の更新により、ユーザーがマニフェストを作成する際にチェックが追加され、このストラテジーが AWS、Azure、GCP などのクラウドプラットフォームでのみ使用されるようになりました。(BZ#1953035)
以前のバージョンでは、Google Cloud Platform リソースに名前を付ける際、フィルターによって、Google という単語を使用する特定の名前を使用できませんでした。この更新により、クラスター名のインストーラーにチェックが追加され、名前を設定するときに Google という単語のいくつかのバリエーションを使用できるようになりました。(BZ#1955336)
以前のバージョンでは、インストーラーでプロビジョニングされるインフラストラクチャーを使用したベアメタルのインストールでは、インストーラープロセスでプロビジョニングネットワークと通信できる必要がありました。現在、インストーラープロセスは、API サーバーの仮想 IP と通信できるようになりました。この変更により、プロビジョニングネットワークがルーティング可能ではなく、インストーラープロセスが Red Hat OpenStack Platform (RHOSP) または Red Hat Advanced Cluster Management 向けの Hive などのリモートのロケーションから実行されるケースが可能になります。API サーバーの仮想 IP で TCP ポート 6385 および 5050 との通信を許可するように、ファイアウォールルールを調整しなければならない場合があります。(BZ#1932799)
以前のリリースでは、Red Hat OpenStack Platform (RHOSP) へのインストールで、platform.openstack.machinesSubnet フィールドに存在しないサブネットの ID が提供されると、openshift-install コマンドは SIGSEGV およびバックトレースを生成していました。openshift-install コマンドが修正され、以下のメッセージのようなエラーが生成されるようになりました。
```
FATAL failed to fetch Metadata: failed to load asset "Install Config": platform.openstack.machinesSubnet: Not found: "<network-ID>"
```
(BZ#1957809)
以前のリリースでは、RHOSP HTTPS 証明書がホスティングデバイスにインポートされない限り、Red Hat OpenStack Platform (RHOSP) へのインストールは失敗していました。cloud.yaml の cacert 値が RHOSP HTTPS 証明書に設定されている場合に、インストールが正常に実行されるようになりました。ホストへの証明書のインポートは不要になりました。(BZ#1786314)
以前のバージョンでは、proxy.config.openshift.io の外部ネットワークエントリーが正しくないため、インストールが失敗する可能性がありました。検証チェックにより、これらの間違いが識別され、修正が可能になりました。(BZ#1873649)
以前は曖昧または紛らわしかった Terraform コンポーネントの説明が、より明確な情報に置き換えられました。(BZ#1880758)
gophercloud/utils に対する以前の変更により、自己署名証明書を使用するカスタム HTTP クライアントが導入されました。この変更により、プロキシー環境変数の設定を含む DefaultTransport の設定が削除されたため、自己署名証明書とプロキシーの両方を使用するインストールで失敗が発生しました。この更新では、カスタム HTTP クライアントが DefaultTransport の設定を継承するため、自己署名証明書およびプロキシーを使用して OpenShift Container Platform をインストールできるようになりました。(BZ#1925216)
以前のバージョンでは、インストーラーは検証中にインストール設定の defaultMachineSet 値を考慮していなかったため、インストーラーが失敗していました。この更新により、デフォルト値がインストール設定に適用され、空のフィールドの検証が開始されます。(BZ#1903055)
以前のバージョンでは、soft-anti-affinity は、クライアントが最小の Nova マイクロバージョンを設定する必要がありました。Ansible OS サーバーモジュールのほとんどのバージョンでは、クライアントが最小値を自動的に設定する必要はありませんでした。その結果、soft-anti-affinity コマンドは失敗する可能性がありました。この更新では、soft-anti-affinity を処理する際に、Python OpenStack クライアントを使用して Nova マイクロバージョンを設定する方法が修正されています。(BZ#1910067)
以前のバージョンでは、OpenStack UPI Playbook は作成されたすべてのリソースにタグを付けていませんでした。その結果、openshift-install destroy コマンドは、すべてのクラスターリソースを適切に識別できず、タイムアウトに達するまでリソースの削除をループし、これによりリソースが残されました。この更新により、欠落していたタグ付けに関する指示が OpenStack UPI Playbook に追加されました。(BZ#1916593)
以前のバージョンでは、Python パッケージエラーが原因で e2e-gcp-upi が成功せず、失敗していました。この更新により、gsutil の正しい Python バージョン (pip バージョン) および CLOUDSDK_PYTHON を設定して、パッケージエラーを解決できます。(BZ#1917931)
以前のバージョンでは、pip バージョン 21 はインストールされた Python バージョン 2 をサポートしていませんでした。その結果、コンテナーのセットアップに必要なすべての依存パッケージの解決中にエラーが発生しました。この更新では、問題を回避するために、pip バージョンが 21 未満の値に修正されています。(BZ#1922235)
以前のバージョンでは、インストーラーはクラウドに関する情報を 2 回収集していました。その結果、OpenStack API へのリクエスト数が 2 倍になり、クラウドに追加の負荷がかかり、インストール時間が長くなりました。この更新では、クォータをチェックする前にクラウドに関する情報を収集し、同じ情報を検証に再利用することで、問題を修正しています。(BZ#1923038)
以前のバージョンでは、/64 以外のサブネットを持つ IPv6 プロビジョニングネットワークでデプロイする場合、DNSmasq は接頭辞長を指定する必要がありました。そのため、/64 以外のネットワークを使用している場合、ホストは PXE ブートに失敗していました。この更新には、DNSmasq 設定の接頭辞長が含まれています。その結果、ホストは DHCP で成功し、任意の接頭辞長の IPv6 ネットワークで PXE ブートを実行します。(BZ#1925291)
以前のバージョンでは、OpenShift Container Platform インストーラーは、Shared Subnet タグを削除する際に、このタグは削除されているとロギングが示していても、IAM パーミッションの問題を報告していませんでした。この更新により、タグ付け解除およびロギングエラーの結果がチェックされます。ログには、共有リソースのタグ解除のステータスが表示されるようになりました。(BZ#1926547)
以前のバージョンでは、Azure クラスターは Premium_LRS のディスクタイプと、クラスターが失敗する原因となった PremiumIO 機能をサポートしていないインスタンスタイプで作成されていました。この更新では、ディスクタイプがデフォルトのディスクタイプである Premium_LRS である場合にのみ、選択されたインスタンスタイプに PremiumIO 機能があるかどうかを確認します。コードは、Azure サブスクリプションとリージョンにクエリーを実行して必要な情報を取得し、条件が満たされない場合はエラーを返します。(BZ#1931115)
以前のバージョンでは、API サーバーの再起動時に API VIP がブートストラップで利用できなくなり、これにより、プロビジョニングサービスが利用できなってプロビジョニングに失敗していました。プロビジョニングサービス (Ironic) が VIP ヘルスチェックに含まれるようになり、API VIP は引き続き利用可能となります。(BZ#1949859)

kube-apiserver

以前のバージョンでは、Google Cloud Platform (GCP) ロードバランサーのヘルスチェッカーがホストに古い conntrack エントリーを残していたため、GCP ロードバランサーを使用する API サーバートラフィックにネットワークの中断が発生していました。ヘルスチェックトラフィックがホストをループしなくなったため、API サーバーに対するネットワークの中断がなくなりました。(BZ#1925698)

Machine Config Operator

以前のバージョンでは、drain timeout とプールのパフォーマンスの低下期間が短すぎたため、より多くの時間を必要とする通常のクラスターで、アラートが早期に発生していました。この更新により、タイムアウトが障害を報告するまでに必要な時間が延長されました。これにより、クラスター Operator には、通常のクラスターのパフォーマンスを早期に低下させることなく、より現実的で有用なアラートが提供されます。(BZ#1968019)
以前のバージョンでは、OpenShift インストーラーでプロビジョニングされるインフラストラクチャー (IPI) を使用して VMware vSphere から新しい仮想マシンを作成中に、ノードがクラスターに参加できませんでした。これは、Dynamic Host Configuration Protocol (DHCP) が、IDI によって提供された名前の代わりにホスト名を入力したときに発生しました。これは解決されています。(BZ#1920807)
以前のバージョンでは、ホスト名が設定される前にネットワークが有効化されると、インストールが失敗する可能性がありました。これにより、ノードがクラスターに参加できなくなり、もう一度試行するまでに 5 分間の遅延が強制されました。この問題は解決され、ノードは最初の試行時に自動的にクラスターに参加します。(BZ#1899187)
以前のバージョンでは、ユーザーはコアユーザーおよび関連する SSH キーを削除できましたが、キーは残っていました。この更新により、ユーザーはコアユーザーを削除できなくなります。(BZ#1885186)
4.6 から 4.7 にアップグレードする場合、vsphere-hostname サービスで設定したホスト名は、ノードのインストール時にのみ適用されました。アップグレード前にホスト名が静的に設定されていない場合には、ホスト名が失われる可能性があります。今回の更新により、ノードがインストールされている場合にのみ、vsphere-hostname サービスの実行を許可していた条件が削除されます。その結果、vSphere ホスト名はアップグレード時に失われなくなりました。(BZ#1942207)
keepalived 2.0.10 のバグにより、liveness プローブが keepalived コンテナーを終了すると、システムに割り当てられた仮想 IP アドレス (VIP) はそのまま残り、keepalived の再起動時にクリーンアップされませんでした。その結果、複数のノードが同じ VIP を保持する可能性がありました。現在は、keepalived の起動時に VIP が削除されるようになりました。その結果、VIP は単一ノードで保持されます。(BZ#1931505)
以前のバージョンでは、rpm-ostree 関連の操作は、Red Hat Enterprise Linux CoreOS (RHCOS) などの CoreOS 以外のノードで適切に処理されませんでした。その結果、カーネルの切り替えなどの操作が RHEL ノードを含むプールに適用されると、RHEL ノードのパフォーマンスは低下していました。今回の更新により、Machine Config Daemon は、CoreOS 以外のノードでサポート対象外の操作が実行されるたびに、メッセージをログに記録します。メッセージのロギング後、エラーではなく nil を返します。プール内の RHEL ノードは、サポート対象外の操作が Machine Config Daemon によって実行された場合、想定どおりに続行されるようになりました。(BZ#1952368)
以前のバージョンでは、空の静的 Pod ファイルは /etc/kubernetes/manifests ディレクトリーに書き込まれていました。その結果、kubelet ログは、一部のユーザーとの混乱を引き起こす可能性のあるエラーを報告していました。空のマニフェストは、不要な場合には別の場所に移動されるようになりました。その結果、エラーは kubelet ログに表示されなくなりました。(BZ#1927042)

メータリング Operator

以前のバージョンでは、レポート Operator は、イベントの調整時にユーザーが指定する保持期間を含む Report カスタムリソース (CR) を誤って処理していました。その結果、Report CR の有効期限が切れると、影響を受けるカスタムリソースは無限に再びキューに入れられるため、レポート Operator が継続的にループしました。今回の更新により、保持期間が指定された期限切れの Report CR が再びキューに入れられることはなくなります。その結果、レポート Operator は期限切れの Report CR のイベントを正しく処理します。(BZ#1926984)

モニタリング

以前のバージョンでは、node-exporter デーモンセットの mountstats コレクターにより、NFS マウントポイントが設定されたノードでのメモリー使用量が高くなっていました。今回の更新で、ユーザーは mountstats コレクターを無効にして、メモリー使用量を軽減できるようになりました。(BZ#1955467)

ネットワーク

以前のバージョンでは、keepalived の誤った設定により、間違ったシステムに VIP が配置される場合があり、正しいシステムに戻れませんでした。この更新では、VIP が正しいシステムに配置されるように、keepalived の誤った設定が削除されます。(BZ#1916890)
iptables の書き換えルールにより、サービス IP と Pod IP の両方を介してサービスに接続するために固定ソースポートを使用するクライアントでは、ポートの競合による問題が発生する可能性があります。今回の更新により、追加の OVS ルールが挿入され、ポートの競合が発生したときに通知し、その競合を回避するために追加の SNAT を実行します。その結果、サービスへの接続時にポートの競合が発生しなくなりました。(BZ#1910378)
以前のバージョンでは、コントロールプレーンノードと egress が割り当てられたノード間の IP ポート 9 は、内部ファイアウォールによってブロックされていました。これにより、egress ノードへの IP アドレスの割り当てが失敗していました。この更新により、IP ポート 9 を介したコントロールプレーンと egress ノード間のアクセスが可能になります。その結果、egress ノードへの IP アドレスの割り当てが正常に許可されるようになりました。(BZ#1942856)
以前のバージョンでは、無効になった古い接続追跡エントリーが原因で、UDP サービストラフィックがブロックされる可能性がありました。これにより、サーバー Pod へのアクセスは、NodePort サービスに切り替えられた後に妨げられました。この更新により、NodePort サービス切り替えの場合は、接続追跡エントリーが削除され、これにより、新しいネットワークトラフィックが切り替えられたエンドポイントに到達できるようになります。(BZ#1949063)
以前のバージョンでは、OVN-Kubernetes ネットワークプロバイダーは、複数の ipBlocks を持つネットワークポリシーを無視していました。最初の ipBlock 後のすべての ipBlock が無視され、これにより、Pod は設定されたすべての IP アドレスに到達できなくなりました。Kubernetes ネットワークポリシーから OVN ACL を生成するためのコードが修正されました。その結果、複数の ipBlocks を持つネットワークポリシーが正しく機能するようになりました。(BZ#1953680)
以前のバージョンでは、OVN-Kubernetes クラスターネットワークプロバイダーを使用すると、エンドポイントのない Kubernetes サービスが誤って接続を受け入れていました。この更新により、エンドポイントのないサービス用にロードバランサーが作成されなくなったため、トラフィックは受け入れられなくなりました。(BZ#1918442)
以前のバージョンでは、Multus の Container Network Interface (CNI) プラグインは、ゼロで始まる数値の IPv6 アドレスを理解していませんでした。この更新により、CNI プラグインはゼロより大きい値で始まる IPv6 で動作します。(BZ#1919048)
以前は、マシン設定ポリシーの変更によって再起動がトリガーされる際に、SR-IOV ネットワーク Operator が再起動を開始した場合、競合状態がトリガーされる可能性がありました。競合状態が発生した場合、ノードは不確定な状態のままになりました。この更新により、そのような状況が回避されます。(BZ#1921321)
以前は、Kuryr クラスターネットワークプロバイダーを使用して、ユーザーによってプロビジョニングされる新しいクラスターを作成すると、クラスターノードによって使用される OpenStack サブセットが検出されず、クラスターのインストールがタイムアウトになることがありました。この更新により、サブネットが正しく検出され、ユーザーによってプロビジョニングされるインストールが成功します。(BZ#1927244)
以前は、OpenShift Container Platform 4.6 から OpenShift Container Platform 4.7 にアップグレードする際に、Cluster Network Operator (CNO) は次のバージョンへのアップグレードを完了したと誤ってマークしていました。後でアップグレードが失敗した場合、CNO は自身のパフォーマンスを degraded と報告しましたが、バージョンは 4.7 であると誤って報告していました。この更新により、CNO は、クラスターネットワークプロバイダーイメージが正常にアップグレードされるのを待ってから、CNO のアップグレードが成功したと報告します。(BZ#1928157)
以前は、OVN-Kubernetes クラスターネットワークプロバイダーを使用する際に、Kubernetes バージョンに数字以外の文字を含むマイナーバージョンが含まれていると、エンドポイントスライスコントローラーが実行されないことがありました。この更新により、エンドポイントスライスコントローラーはデフォルトで有効化されました。(BZ#1929314)
Kuryr クラスターネットワークプロバイダーを使用する場合、インストール後に作成された Neutron ポートは、インストール中に作成された Neutron ポートとは異なるパターンで名前が付けられました。その結果、インストール後に作成された Neutron ポートは、デフォルトのロードバランサーに追加されませんでした。この更新により、Kuryr はどちらの命名規則で作成されていても Neutron ポートを検出します。(BZ#1933269)
以前は、Open Virtual Network (OVN) がヘアピントラフィックパケットのソース IP アドレスをロードバランサーの IP アドレスに変更していました。これにより、ネットワークポリシーの使用中にトラフィックがブロックされることがありました。この更新により、Kuryr はネットワークポリシーの namespace 内のすべてのサービスの IP アドレスへのトラフィックを開き、ヘアピントラフィックはブロックされなくなりました。(BZ#1920532)
以前は、IPv4 アドレスを持つノードでシングルスタック IPv6 クラスターを開始すると、kubelet はノード IP に IPv6 IP ではなく IPv4 IP を使用していた可能性がありました。その結果、ホストネットワーク Pod には IPv6 IP ではなく IPv4 IP が含まれるため、IPv6 のみの Pod からは到達できなくなっていました。この更新により、ノード IP ピッキングコードが修正され、kubelet が IPv6 IP を使用するようになりました。(BZ#1939740)
以前のバージョンでは、不明な理由により、kubelet はノードに誤った IP アドレスを登録する可能性がありました。その結果、ノードは再起動されるまで NotReady 状態になります。systemd マネージャーの設定は環境変数として有効な IP アドレスで再読み込みされるようになりました。つまり、kubelet が誤った IP アドレスを登録することによりノードが NotReady 状態になることはなくなりました。(BZ#1940939)
以前のリリースでは、シャドウ変数のリファクタリングにより、チェックポイントファイルの使用に関連するリグレッションが生じ、SR-IOV Pod サンドボックスが起動しませんでした。kubelet ソケットのパスの確認は、リファクタリング時に適切に考慮されませんでした。この修正により、kubelet ソケットパスの確認が適切に復元され、SR-IOV Pod サンドボックスが適切に作成されるようになりました。(BZ#1968625)

ノード

以前は、Reliable Autonomic Distributed Object Store (RADOS) Block Devices (RBD) は、lsblk を実行している特権なしのコンテナー Pod に表示されていました。これは修正され、lsblk を実行している特権なしのコンテナー Pod に RBD が表示されなくなりました。(BZ#1772993)
以前は、クラスターのアップグレード中に CRI-O が /etc/hostname ファイルを変更していたため、ノードに障害が発生し、再起動時に元に戻りました。この更新により、アップグレード中は /etc/hosts ファイルをそのままにするように CRI-O に特別な処理が加えられ、アップグレードされたノードは問題なく起動できるようになりました(BZ#1921937)
以前は、ネットワークがプロビジョニングされた後の Pod の作成に CRI-O は時間をかけすぎていました。これにより、ネットワーククリーンアップコードにバグが発生し、ネットワークリソースがプロビジョニングされた後にネットワークリソースが適切にクリーンアップされなくなっていました。この更新により、コマンドがタイムアウトした場合でも、ネットワークリソースが適切にクリーンアップされるようにコードが変更されます。これにより、Pod の作成に時間がかかりすぎた場合でも、クラスターは通常のネットワーク操作を続行できます。(BZ#1957224)
以前は、CNI プラグインを使用したノードの再起動は、正常に完了しませんでした。CRI-O は、再起動前に実行されていたすべてのコンテナーで、CNI DEL を呼び出すように変更されました。この更新により、CNI リソースがクリーンアップされ、正常に再起動できるようになります。(BZ#1948137)
以前は、CNI クリーンアップ操作はクリーンアップの失敗をチェックしなかったため、CNI DEL 要求が失敗した場合は、再度呼び出されませんでした。現在は、CRI-O は成功するまで CNI DEL 要求を再度呼び出し、CNI リソースを正しくクリーンアップします。(BZ#1948047)
以前は、コンテナーまたはイメージがディスクにコミットされているときに再起動が起きた場合、コンテナーまたはイメージへの再起動要求が失敗を引き起こす可能性がありました。これにより、コンテナーのストレージが明らかに破損し、イメージのプルまたはイメージからのコンテナーの再作成に失敗しました。この更新は、ノードが再起動されたことを検出し、true の場合はコンテナーストレージをクリアにします。(BZ#1942536)
以前は、runc は、自身を実行したエンティティーのパーミッションを引き継ぎました。ただし、workdir のパーミッションは、container ユーザーによって設定されます。これらのパーミッションが異なると、コンテナー作成エラーが発生し、コンテナーの起動に失敗しました。このパッチは、1 回だけ失敗した場合に備えて、runc を chdir から workdir に複数回更新します。これにより、コンテナーの作成は成功します。(BZ#1934177)
以前のバージョンでは、CRI-O ログには、イメージのプル元のソースについての情報が含まれていませんでした。この修正により、ログプルソースが CRI-O ログの情報レベルに追加されます。(BZ#1881694)
以前のバージョンでは、Pod が迅速に作成および削除された場合、Pod が削除を開始するまでに、Pod サンドボックスの作成を完了するための十分な時間がない場合がありました。その結果、ErrCreatePodSandbox エラーが表示され、Pod の削除が失敗する可能性がありました。このエラーは、Pod が終了している場合に無視されるようになりました。その結果、Pod が Pod サンドボックスの作成を完了できなくても、Pod の終了が失敗することはなくなりました。(BZ#1908378)
以前のバージョンでは、Machine Config Operator (MCO) は トレース を有効なログレベルとして許可しませんでした。その結果、CRI-O がサポートしていても、MCO はトレースレベルのロギングを有効にする方法を提供できませんでした。MCO が トレース ログレベルをサポートするように更新されました。その結果、ユーザーは MCO 設定を通じてトレースログレベルを確認できます。(BZ#1930620)
以前のバージョンでは、kubelet は完全にプルされていないイメージのステータスを取得しようとしました。その結果、crictl はこれらのイメージの error locating item named "manifest" エラーを報告しました。CRI-O は、マニフェストのないイメージを一覧表示しないように更新されました。その結果、crictl はこれらのエラーを報告しなくなりました。(BZ#1942608)
以前のバージョンでは、古いステータスメッセージが削除されませんでした。そのため、Machine Config Operator (MCO) は適切なマシン設定プールを見つけることができない場合がありました。今回のリリースにより、クリーンアップ機能が追加され、ステータスの数を制限できるようになりました。その結果、MCO は最大 3 つの異なる kubeletConfig ステータスを保持します。(BZ#1950133)
以前のバージョンでは、OpenShift Container Platform バージョン 4.6.25 からアップグレードする際に、複数の kubeletconfig CR または ContainerRuntimeConfig CR を持つクラスターで、Machine Config Operator (MCO) が同じ設定に対して、重複するマシン設定を生成する可能性がありました。その結果、MCO は古いコントローラーバージョン (IGNITIONVERSION 3.1.0) を使用するため、アップグレードに失敗していました。今回の更新により、古い重複マシン設定がクリーンアップされ、バージョン 4.6.25 から適切にアップグレードできるようになります。(BZ#1955517)

oauth-apiserver

以前のバージョンでは、一部の OAuth サーバーメトリクスは適切に初期化されず、Prometheus UI での検索には表示されませんでした。不足している OAuth サーバーメトリクスが適切に初期化され、Prometheus UI メトリクスの検索に表示されるようになりました。(BZ#1892642)
以前のバージョンでは、カスタム SCC (Security Context Constraints) に defaultAllowPrivilegeEscalation: false フィールドおよび allowPrivilegedContainer: true フィールドの組み合わせが含まれる場合、セキュリティーコンテキストミューテーターは特権付きの openshift-apiserver Pod および oauth-apiserver Pod を API 検証に失敗した状態に変更しました。Pod は起動に失敗し、OpenShift API が停止することがありました。セキュリティーコンテキストミューテーターは、すでに特権のあるコンテナーの defaultAllowPrivilegeEscalation フィールドを無視し、これらのフィールドを含むカスタム SCC は Pod の起動を妨げなくなりました。(BZ#1934400)

以前は、oc explain コマンドを実行するときに、リソースグループ名がリソース文字列の一部として提供された場合、リソースグループ名は自動的に検出されませんでした。異なるグループの 2 つのリソースが同じリソース名を持っていた場合、グループが --api-version パラメーターで指定されていない限り、最も優先度の高い定義が返されていました。現在は、--api-version パラメーターが含まれていない場合、リソース文字列に対して接頭辞チェックが実行され、グループ名が検出されます。コマンドによって返される説明は、指定されたグループの一致するリソースに関連しています。(BZ#1725981)
以前は、oc image extract コマンドは、イメージのルートディレクトリーからファイルを抽出しませんでした。コマンドが更新され、イメージのルートディレクトリーからファイルを抽出するために使用できるようになりました。(BZ#1919032)
以前は、oc apply コマンドは、呼び出しごとに OpenAPI 仕様を取得していました。コマンドが最初に実行されたときに、OpenAPI 仕様がキャッシュされるようになりました。キャッシュされた OpenAPI 仕様は、oc apply コマンドが複数回実行され、ネットワーク負荷が軽減されたときに再利用されます。(BZ#1921885)
以前は、イメージミラーリング中に作成された承認ヘッダーが、一部のレジストリーのヘッダーサイズ制限を超える可能性がありました。これにより、ミラーリング操作中にエラーが発生します。現在は、oc adm catalog mirror コマンドの --skip-multiple-scopes オプションが true に設定され、承認ヘッダーがヘッダーサイズの制限を超えないようになりました。(BZ#1946839)
以前は、oc volume set コマンドに --claim-class オプションが含まれている場合は、storageClassName 属性は PersistentVolumeClaim オブジェクトに追加されませんでした。代わりに、--claim-class オプションの値が volume.beta.kubernetes.io/storage-class アノテーションに追加されました。これにより、storageClassName 属性の依存関係が原因で、ボリュームのスナップショットが失敗していました。現在は、oc volume set コマンドは --claim-class オプションの値を PersistentVolumeClaim オブジェクトの storageClassName 属性に適用し、ボリュームスナップショットは属性値を参照することができます。(BZ#1954124)
以前は、oc adm top --help の出力には、oc adm top コマンドは Pod とノードの CPU、メモリー、およびストレージリソースの使用状況を表示できると記載されていました。oc adm top コマンドは、ストレージリソースの使用状況を表示しません。現在は、ストレージ参照は oc adm top --help の出力に含まれていません。(BZ#1959648)

Operator Lifecycle Manager (OLM)

以前のバージョンでは、Operator のインストールの一部として適用される CustomResourceDefinition (CRD) オブジェクトが、同じ Operator の新規バージョンのインストール要件を満たす場合がありました。その結果、Operator のアップグレード中に、置き換えられるバージョンが途中で削除される可能性がありました。場合によっては、アップグレードが停止することがありました。今回の更新により、Operator バンドルインストールの一部として作成または更新される CRD には、元のバンドルを示すアノテーションが付けられるようになりました。これらのアノテーションは、ClusterServiceVersion (CSV) オブジェクトによって使用され、既存の CRD と同じバンドルの CRD を区別します。その結果、現行バージョンの CRD が適用されるまでアップグレードは完了しません。(BZ#1947946)
以前のバージョンでは、CatalogSource オブジェクトによって参照されるインデックスを実行する Pod には、securityContext フィールドに明示的に設定された readOnlyRootFileSystem: false がありませんでした。そのため、readOnlyRootFileSystem: true を実施し、その Pod の securityContext に一致する SCC (Security Context Constraints) が存在する場合、SCC はその Pod に割り当てられ、繰り返し失敗します。今回の更新により、securityContext フィールドに readOnlyRootFileSystem: false が明示的に設定されるようになりました。その結果、CatalogSource オブジェクトによって参照される Pod は、読み取り専用のルートファイルシステムを実施する SCC と一致しなくなり、失敗しなくなりました。(BZ#1961472)
以前は、Operator Lifecycle Manager (OLM) は、初期インストール時に startingCSV フィールドでバージョンが指定されていた場合、スキップされたバージョンのインストールを許可していませんでした。これにより、ユーザーがスキップされたバージョンをインストールしたい場合でも、スキップされた理由に関係なく、それらをインストールできなくなりました。この修正により OLM が更新され、Subscription オブジェクトの startingCSV 仕様を使用して、初期インストール時にのみ、ユーザーはスキップされたバージョンをインストールできるようになります。ユーザーがスキップされたバージョンにアップグレードできないのは、想定どおりです。(BZ#1906056)
k8s.io/apiserver は Webhook 承認者のコンテキストエラーを処理していなかったため、タイムアウトなどのコンテキストエラーにより、承認者はパニックに陥りました。この修正により、API サーバーのバージョンが増分され、問題のアップストリーム修正が含まれるようになります。その結果、承認者はコンテキストエラーを適切に処理できます。(BZ#1913525)
以前は、エアギャップ環境全体で Operator カタログをミラーリングするために、oc adm catalog mirror コマンドを使用することは簡単ではありませんでした。この機能拡張により、カタログの内容をファイルシステムにミラーリングし、リムーバブルメディアに配置してから、エアギャップクラスターで使用するためにファイルシステムからレジストリーにミラーリングして戻すことができます。(BZ#1919168)
以前のバージョンでは、カタログ Operator は、タイムアウトを設定せずに、インストールプランのバンドルアンパックジョブを作成していました。これにより、バンドルイメージが存在しないか削除された場合は、ジョブが永久に実行され、ジョブの Pod がイメージの解決に失敗したことを示すことなく、インストールプランは Installing フェーズにとどまりました。この修正により、カタログ Operator は、バンドルアンパックジョブにデフォルトの 10m タイムアウトを設定するようになりました。これは、--bundle-unpack-timeout フラグを使用して設定できます。その結果、バンドルアンパックジョブが設定されたタイムアウト後に失敗し、status.conditions プロパティーと status.bundleLookups.conditions プロパティーに表示される理由により、インストールも Failed フェーズに移行します。(BZ#1921264)
以前のバージョンでは、OpenShift Container Platform 4.6 より前のクラスターにインストールされた Operator は、依存関係の解決とアップグレードの選択の目的で、特定の Operator パッケージからのものとして識別されていませんでした。これにより、既存の Operator インストールが独自のサブスクリプションの基準と競合し、namespace 内のアップグレードと依存関係の解決がブロックされました。この修正により OLM が更新され、サブスクリプションによって参照される Operator のパッケージ名とバージョンを推測するようになりました。その結果、アップグレードと依存関係の解決は想定どおりに進行します。(BZ#1921953)
一時的なエラーに使用される Info ログレベルにより、デフォルト設定の詳細な OLM Operator ログが発生しました。この修正により、一時的なエラーログレベルが debug に変更されます。その結果、debug 設定での重要ではないログの表示が減りました。(BZ#1925614)
以前のバージョンでは、Subscription オブジェクトの spec.config.resources セクションは、設定されていないか空の場合でも、インストールされたデプロイメントに常に適用されていました。これにより、クラスターサービスバージョンで (CSV) で定義されたリソースが無視され、Subscription オブジェクトの spec.config.resources セクションで定義されたリソースのみが使用されました。この修正により、spec.config.resources セクションが nil 以外または空でない値に設定されている場合にのみ、デプロイメント固有のリソースをオーバーライドするように OLM が更新されます。(BZ#1926893)
以前のバージョンでは、依存関係とアップグレードの解決中のサブスクリプションの一意性は、サブスクライブされたパッケージ名に基づいていました。namespace 内の 2 つのサブスクリプションが同じパッケージをサブスクライブする場合、それらは内部的には単一のサブスクリプションとして扱われ、想定外の動作が発生していました。この修正により、サブスクリプションは内部的に .spec.name ではなく .metadata.name で、namespace 内で一意に識別されるようになりました。その結果、アップグレードと依存関係の解決の動作は、同じ .spec.name. 持つ複数の Subscription オブジェクトを含む namespace で一貫しています。(BZ#1932001)
次のカタログ更新ポーリングの試行までの時間が 1 分未満の場合、間隔ジッター関数は再同期の間隔をゼロまで切り捨てます。これにより、Operator カタログがホットループに入り、CPU サイクルが無駄になりました。この修正により、再同期の遅延の計算に使用されるジッター関数の精度が向上します。その結果、カタログ Operator は、次のカタログ更新ポーリングまでほとんどアイドル状態のままになります。(BZ#1932182)
Operator のアップグレード中に、関連する ServiceAccount オブジェクトの所有者参照が更新され、古いオブジェクトではなく、新しい ClusterServiceVersion (CSV) オブジェクトを指すようになりました。これにより、CSV を調整する OLM Operator と、インストールプランを実行するカタログ Operator との間で競合状態が発生し、サービスアカウントの所有権の変更により古い CSV が Pending/RequirementsNotMet としてマークされる可能性があります。これにより、古い CSV が正常なステータスを示すことを新しい CSV が無期限に待機している間に、アップグレードの完了がブロックされました。この修正により、所有者参照を 1 つの手順で更新する代わりに、2 番目の所有者が既存の所有者に追加されるようになりました。その結果、同じサービスアカウントで、古い CSV と新しい CSV の両方の要件を満たすことができます。(BZ#1934080)
以前のバージョンでは、クラスターサービスバージョン (CSV) では、関連するサービスアカウントが ownerReferences 値を設定しないか、または関連する CSV に ownerReferences 値を設定する必要がありました。これにより、Operator のインストールの一部として作成されていない default のサービスアカウントは、metadata.ownerReferences フィールドが空でない場合、CSV 要件として満たされませんでした。この修正により、CSV では、関連付けられたサービスアカウントが、CSV に ownerReferences 値を設定しないか、または関連する CSV に ownerReference 値を設定することが必要となりました。その結果、CSV 以外の ownerReferences 値のみのサービスアカウントは、CSV の要件を満たすことができます。(BZ#1935909)
OpenShift Container Platform 4.5 より前は、openshift-marketplace namespace で Marketplace Operator によってデプロイおよび管理されたデフォルトのカタログは、Marketplace Operator によって公開された API である OperatorSource オブジェクトによって作成されていました。Operator ソースで発生したエラーを示すために、適切なメトリクスとアラートがインストルメント化されました。OpenShift Container Platform 4.6 では、OperatorSource リソースはいくつかのリリースで非推奨になった後に削除され、代わりに Marketplace Operator は OLM の CatalogSource リソースを直接作成しました。ただし、openshift-marketplace namespace にデプロイされたカタログソースに対しては、同じメトリクスとアラートのインストルメンテーションは実行されませんでした。したがって、デフォルトのカタログソースで発生したエラーは、Prometheus アラートでは強調されませんでした。この修正により、OLM に新しい catalogsource_ready メトリクスが導入されます。これは、カタログソースが Unready (準備が未完了) 状態にあることをデフォルトのカタログソースのメトリクスが示すたびに、アラートを発生させるために Marketplace Operator が使用します。その結果、openshift-marketplace namespace の Unready (準備が未完了) 状態のデフォルトのカタログソースに対して、Prometheus アラートが提供されるようになりました。(BZ#1936585)
以前のバージョンでは、候補の Operator 依存関係がデフォルトのチャネルとデフォルト以外のチャネルから利用可能であった場合、Operator Lifecycle Manager (OLM) は、2 つのチャネルのいずれかを任意に指定するサブスクリプションを生成することができました。現在、Operator の依存関係は、最初にデフォルトチャネルからの候補によって満たされ、続いて他のチャネルからの候補によって満たされます。(BZ#1945261)
以前のバージョンでは、クラスターサービスバージョン (CSV) が複数の Operator のコンポーネントとしてコピーされる可能性がありました。これは、Operator のインストール後に namespace が Operator グループに追加された場合に発生する可能性があります。この動作は、メモリー使用量と CPU 負荷に影響を及ぼしていました。現在、CSV は、Copied の理由で Operator の status.components フィールドに表示されず、パフォーマンスへの影響はありません。(BZ#1946838)

Operator SDK

以前のバージョンでは、ManagedFields が調整中に処理されていたため、一部のリソースが無限ループに陥っていました。この修正により、operator-lib が更新され、 ManagedFields が無視されるようになり、ループが一貫して調整されます。(BZ#1856714)
コマンドラインインターフェイス (CLI) で --help が渡された際に、デフォルトのプラグインが呼び出されなかったため、Operator SDK の出力されるヘルプメッセージは最小限となっていました。この修正により、デフォルトのプラグインが呼び出され、ユーザーが operator-sdk init --help コマンドを実行すると、より有用なヘルプメッセージが出力されます。(BZ#166222)
以前のバージョンでは、オプションのバリデーターがない状態で実行すると、警告は表示されずに、operator-sdk bundle が失敗していました。これは修正されています。(BZ#1921727)

openshift-apiserver

以前のリリースでは、カスタム SCC (Security Context Constraints) は、デフォルトセットの他の SCC よりも優先度を高くすることができました。その結果、これらの SSC は openshift-apiserver Pod と一致することがあり、これにより、ルートファイルシステムへの書き込みができなくなりました。また、このバグにより、一部の OpenShift API が停止しました。この修正では、ルートファイルシステムが書き込み可能でなければならないことが、openshift-apiserver Pod に明示的に示されています。その結果、カスタム SCC は openshift-apiserver Pod の実行を阻止することはできません。(BZ#1942725)

Performance Addon Operator

以前のバージョンでは、低レイテンシーの応答を提供するようにコンテナーを設定する場合、CRI-O を使用した動的割り込みマスクが irqbalance システムサービスによって設定された割り込みマスクと一致しませんでした。それぞれが異なるマスクを設定し、コンテナーのレイテンシーを損なっていました。この更新では、irqbalance システムサービスに一致するように CRI-O を設定することにより、割り込みマスクセットが変更されます。その結果、動的割り込みマスク処理が想定どおりに機能するようになりました。(BZ#1934630)

RHCOS

以前のリリースでは、起動プロセスの非常に遅い段階でマルチパスが有効化されていました。その結果、Red Hat Enterprise Linux CoreOS (RHCOS) は、一部のマルチパス環境で I/O エラーを返しました。今回の更新で、起動プロセスの早い段階でマルチパスが有効化されるようになりました。その結果、RHCOS は一部のマルチパス環境で I/O エラーを返さなくなりました。(BZ#1954025)
以前のバージョンでは、潜在的な競合状態により、一部の環境で Red Hat Enterprise Linux CoreOS (RHCOS) PXE デプロイメントの rootfs の取得が失敗する可能性がありました。この修正により、rootfs のプルを試みる前に再試行する接続チェックが追加され、coreos-livepxe-rootfs スクリプトが失敗することがあるポイントに進む前に、リモートサーバーと rootfs ファイルへのアクセスが検証されるようになりました。(BZ#1871303)
以前のバージョンでは、MachineConfig のユーザーによる事前設定は無視されていました。これは、ユーザーが kdump.service の設定を変更できないことを意味していました。現在は、デフォルトの事前設定の優先度はユーザー設定のデフォルトよりも低いため、ユーザー設定はベンダー設定を適切に上書きできます。(BZ#1969208)
以前のバージョンでは、coreos-installer は、インストールイメージで上書きする前にターゲットディスクの GUID Partition Table (GPT) を読み取ろうとするため、GPT が破損しているディスクへのインストールを拒否していました。この修正により、coreos-installer は、既存のパーティションを保持するように指示される場合にのみターゲットディスクの GPT を読み取ることで、GPT が破損しているディスクに正常にインストールできるようになりました。(BZ#1914976)
以前のバージョンでは、フォーマットされていない直接アクセス記憶装置 (DASD) にクラスターをインストールすると、coreos-installer によって誤って書き込まれたディスクセクターが作成されていました。現在は、coreos-installer は、フォーマットされていない新しい DASD ドライブを 4096 バイトセクターに正しくフォーマットします。これにより、coreos-installer は OS イメージのディスクドライブへのインストールを完了することができます。(BZ#1905159)
以前のバージョンでは、s390x z15 システムでのハードウェア支援の zlib 展開により、RHEL rootfs イメージのマウントが失敗し、RHEL 8.3 カーネルを使用する REHL s390x z15 ノードのブートが失敗していました。ハードウェア支援の zlib 圧縮が利用可能な場合に、zlib で圧縮された squashfs ファイルを正しく処理するようにカーネルが更新されました。(BZ#1903383)
以前のバージョンでは、zipl コマンドは 512 バイトのセクターサイズを想定して、ディスクジオメトリーを設定していました。その結果、4k セクターの SCSI ディスクでは、zipl ブートローダー設定に誤ったオフセットが含まれ、zVM を起動できませんでした。この修正により、zipl は、zVM が正常に起動するようにディスクセクターサイズを考慮するようになりました。(BZ#1918723)
以前のバージョンでは、chrony.config は自動的に複数回実行され、最初を除いて毎回失敗する可能性がありました。chrony.config の設定は初回実行時に設定され、変更できないため、これにより問題が発生しました。これらのエラーは、設定のセットアッププロセスを chrony.config の初回実行時に限定することで、回避されるようになりました。(BZ#1924869)
以前のバージョンでは、ワークロードの高い期間中は、ノードは正常ではないように見え、想定どおりに動作しませんでした。これは、メモリーが回収されるよりも速く、ワークロードがメモリーを使用することが原因でした。この更新により、メモリーの回収とメモリー不足の状況が解決され、これらの状況はワークロードが高い状況では発生しなくなりました。(BZ#1931467)
以前のバージョンでは、カーネル引数を使用するボンドインターフェイスの Maximum transmission unit (MTU) 仕様が適切に割り当てられていませんでした。これは修正されています。(BZ#1932502)
以前のバージョンでは、clevis-luks-askpass.path ユニットはデフォルトで有効になっていませんでした。これにより、root 以外 LUKS Clevis デバイスが、再起動時に自動ロック解除に失敗しました。この更新により、デフォルトで clevis-luks-askpass.path ユニットが有効化され、root 以外の LUKS Clevis デバイスが再起動時に自動ロック解除できるようになりました。(BZ#1947490)
以前のバージョンでは、systemd は mountinfo を過度に読み取り、CPU リソースを過剰に消費していたため、コンテナーの起動に失敗していました。この更新により、systemd が mountinfo を読み取る際に制限することが可能となり、コンテナーを正常に開始できるようになりました。(BZ#1957726)
以前のバージョンでは、Machine Config Operator (MCO) が起動時に Ignition を呼び出して、Ignition のバージョンを確認すると、Ignition がクラッシュしていました。そのため、MCO は起動に失敗しました。この更新により、MCO は Ignition バージョンをクエリーしなくなり、MCO は正常に起動します。(BZ#1927731)

ルーティング

以前のバージョンでは、HAProxyDown のアラートメッセージはあいまいでした。その結果、エンドユーザーは、アラートの意味として、HAProxy Pod ではなくルーター Pod を利用できないものと考えていました。この更新により、HAProxyDown のアラートメッセージがより明確になりました。(BZ#1941592)
以前のバージョンでは、ホワイトリスト IP のファイルを生成する HAProxy のヘルパー関数テンプレートは、間違った引数タイプを想定していました。その結果、長い IP リストのバックエンドにホワイトリスト ACL が適用されませんでした。今回の更新により、ヘルパー関数テンプレートの引数タイプが変更され、ホワイトリスト ACL が長い IP リストのバックエンドに適用されるようになりました。(BZ#1964486)
以前のバージョンでは、カスタムドメインを使用して Ingress を作成する場合、正規ルーターのホスト名を使用して OpenShift Container Platform Ingress コントローラーによって Ingress のステータスが更新され、external-dns を使用して Route 53 と同期していました。問題は、正規ルーターのホスト名が DNS に存在せず、OpenShift Container Platform によって作成されなかったことです。OpenShift Container Platform は、apps.<cluster_name>.<base_domain> DNS レコードではなく、*.apps.<cluster_name>.<base_domain> DNS レコードを作成します。そのため、正規ルーターのホスト名が正しくありませんでした。この修正により、正規ルーターのホスト名が router-default.apps.<cluster_name>.<base_domain> に設定されます。正規のホスト名を取得してワイルドカードまたはサブドメインを先頭に追加する自動化機能を備えたクラスター管理者は、正規の Ingress ホスト名が <ingress-controller-name>.apps.<cluster_name>.<base_domain> として設定されていることに留意する必要があります。(BZ#1901648)
以前のバージョンでは、BZ#1932401 の修正により、デフォルトの Go HTTP クライアントトランスポートが上書きされていました。その結果、クラスター全体のプロキシー設定が Ingress Operator Pod に組み込まれなかったため、クラスター全体の egress プロキシーのクラスターでのカナリアチェックが失敗しました。この更新により、カナリアクライアントの HTTP トランスポートにプロキシー設定が明示的に設定されます。その結果、カナリアチェックはすべてのクラスター全体のプロキシーで機能します。(BZ#1935528)
以前のバージョンでは、カナリア DaemonSet はノードセレクターを指定していなかったため、カナリア namespace にデフォルトのノードセレクターを使用していました。その結果、カナリア DaemonSet はインフラストラクチャーノードにスケジュールできず、場合によってはアラートを出力していました。この更新により、カナリア DaemonSet がインフラストラクチャーノードに明示的にスケジュールされ、テイントのマークが付けられたインフラストラクチャーノードが容認されます。これにより、カナリア DaemonSet は、問題やアラートなしにワーカーノードとインフラストラクチャーノードに安全にロールアウトできます。(BZ#1933102)
以前のバージョンでは、アイドル状態にされたワークロードを使用してクラスターを以前のバージョンからアップグレードする場合、アイドル状態にされたワークロードは、oc idle 機能の修正と再作業により、OpenShift Container Platform 4.6 または 4.7 にアップグレードした後は HTTP 要求で起動しませんでした。今回の更新により、アイドリングの変更が Ingress Operator の起動時にエンドポイントからサービスにミラーリングされるようになりました。その結果、アップグレード後のワークロードのアイドリング解除が予想通りに機能するようになりました。(BZ#1925245)
以前のバージョンでは、すべての HTTP トラフィックを HTTPS にリダイレクトする外部ロードバランサーを介してデフォルトの Ingress コントローラーを公開すると、Ingress Operator によって実行される Ingress カナリアエンドポイントチェックが失敗し、最終的に Ingress Operator のパフォーマンスが degraded となりました。この修正により、クリアテキストカナリアルートが edge 暗号化ルートに変換されます。安全でないトラフィックがロードバランサーによってリダイレクトされると、カナリアルートは HTTPS のみのロードバランサーを介し機能するようになりました。(BZ#1932401)
以前のバージョンでは、Ingress Operator カナリアチェッククライアントは、HTTP トラフィックをドロップしたロードバランサーに HTTP 経由でカナリアリクエストを送信していました。これにより、カナリアチェックが失敗した後、Ingress Operator のパフォーマンスが degraded となりました。この修正により、ルーターからのリダイレクトに依存する代わりに、Ingress Operator カナリアチェッククライアントは、最初から HTTPS 経由でカナリアチェック要求を送信します。現在、カナリアチェックは、安全でない HTTP トラフィックをドロップするロードバランサーを介してデフォルトの Ingress Controller を公開するクラスターに対して機能します。(BZ#1934773)
以前のバージョンでは、openshift-router で使用される HAProxy テンプレートは、firstMatch() 関数を繰り返し呼び出していました。その関数は、毎回正規表現を解析して再コンパイルします。firstMatch() を呼び出すたびに正規表現を解析して再コンパイルすると、特に何千ものルートがある設定の場合、コストがかかります。この修正により、firstMatch() の呼び出しで正規表現がすでに表示されている場合、コンパイル済みのバージョンが再利用され、キャッシュされます。現在は、haproxy-config.template を解析および評価する際のランタイムが 60 パーセント短縮されています。(BZ#1937972)
以前のバージョンでは、ユーザーはオーバーライドアノテーションを使用して、無効なホスト名でルートに名前を付けることができました。今回の更新でこの問題が修正されています。(BZ#1925697)
以前のバージョンでは、ルートを介して公開されたサービスから selector を削除すると、サービスの Pod 用に作成される endpointslices が重複し、サーバーエントリーの重複が原因で HAProxy の再読み込みエラーが発生していました。この更新により、HAProxy 設定ファイルを書き出すときに誤って重複するサーバー行が除外されるため、サービスからセレクターを削除してもルーターが失敗することはなくなりました。(BZ#1961550)

サンプル

以前のバージョンでは、Cluster Samples Operator は監視するオブジェクトのコントローラーのキャッシュに変更を加える可能性がありました。これにより、Kubernetes がコントローラーキャッシュを管理する際にエラーが生じました。今回の更新により、Cluster Samples Operator がコントローラーキャッシュの情報を使用する方法が修正されました。そのため、Cluster Samples Operator はコントローラーキャッシュを変更してもエラーが生じなくなりました。(BZ#1949481)

service-ca

OpenShift Container Platform 4.8 を使用すると、ユーザーは、root 以外のユーザーとして service-ca-operator Pod を実行し、組織のニーズに合わせることができます。root 以外のユーザーとして実行する場合、service-ca-operator は以下の UID および GID として実行されます。
```
uid=1001(1001) gid=1001 groups=1001
```
(BZ#1914446)

ストレージ

以前のバージョンでは、capacity breakdown を要求する際に、block type PVC ファイルシステムのメトリクスが報告されていませんでした。これは、ユーザーがすべてのファイルシステムにわたって、メトリクスの不正確なレポートを受け取っていたことを意味しました。今回の更新で、Kubelet から要求される場合は、block type PVC が含まれるようになりました。これにより、すべてのファイルシステムメトリクスの正確なレポートが提供されます。(BZ#1927359)
以前のバージョンでは、/var/lib/kubelet が、Cinder CSI Node Controller コンテナーに 2 回マウントされていました。これにより、CSI Node Controller が起動に失敗し、/var/lib/kubelet/pods の空き領域が不足していることを示すエラーが発生しました。この修正により、/var/lib/kubelet および /var/lib/kubelet/pods の重複マウントが削除され、CSI Node Controller を正常に実行できるようになりました。(BZ#1952211)
以前のバージョンでは、永続ボリューム (PV) の Cinder CSI ドライバーのサイズ変更中に、findmnt コマンドが複数のボリュームマウントを受信し、正しいマウントを選択できなかったため、サイズ変更が停止していました。その結果、ユーザーはファイルシステムを手動で拡張する必要があります。この修正では、PV とともにファイルシステムのサイズが変更されるように、コマンドは最初のマウントを使用するようになりました。(BZ#1919291)
Cinder CSI ドライバー Operator は、VolumeSnapshotClass オブジェクトを手動で作成するのではなく、デフォルトのストレージクラスを作成する際に、Cinder CSI のデフォルトの VolumeSnapshotClass オブジェクトを自動的にプロビジョニングするようになりました。(BZ#1905849)
以前のバージョンでは、recycler-pod テンプレートが kubelet 静的マニフェストディレクトリーに誤って配置されていました。この誤った場所では、recycler の静的 Pod の起動が失敗したことを示す静的 Pod ログメッセージが生成されました。この更新により、誤って配置された recycler-pod テンプレートが静的 Pod マニフェストディレクトリーから削除されました。その結果、エラーメッセージは表示されなくなります。(BZ#1896226)
以前のバージョンでは、ローカルストレージ Operator (LSO) は、ビジー状態のディスクが誤って空きディスクとして検出されたため、他のプロビジョナーに属するディスクを要求できました。LSO がそれらのディスクを要求できないように、ディスクのバインドマウントがチェックされるようになりました。(BZ#1929175)
以前のバージョンでは、device-id に : などのサポートされていない文字が含まれていたため、ローカルストレージ Operator (LSO) は、無効なラベル値で永続ボリューム (PV) を作成しようとしていました。これは、デバイス情報をラベルからアノテーションに移動することで修正されました。(BZ#1933630)
以前のバージョンでは、削除プログラムが正しくエンキューされていなかったため、ローカルストレージ Operator (LSO) は永続ボリューム (PV) をクリーンアップしていませんでした。これにより、PV は released 状態のままになりました。PV が正しくエンキューされるようになり、正しく削除されるようになりました。(BZ#1937145)
以前のバージョンでは、Pod が削除されると、ファイバーチャネルボリュームがノードから誤ってアンマウントされていました。これは、ノード上の kubelet が実行されていないときに、ボリュームを使用する別の Pod が API サーバーで削除されたときに発生しました。この更新により、新しい kubelet が起動すると、ファイバーチャネルボリュームは正しくアンマウントされます。さらに、新しい kubelet が完全に起動し、ボリュームがアンマウントされていることを確認するまで、ボリュームを複数のノードにマウントすることはできません。これにより、ファイバーチャネルボリュームが破損しなくなります。(BZ#1954509)

Web コンソール (Administrator パースペクティブ)

以前のバージョンでは、開発者モードでコンソール UI の CNV namespace 内のカスタムリソースを削除しようとする場合、Delete をクリックすると、Delete ボタンがスタック状態でハングしていました。さらに、CLI で同じアクションを実行する際に表示されるエラーメッセージが表示されませんでした。今回の更新により、エラーメッセージが予想通りに表示され、Delete ボタンはスタックしなくなりました。(BZ#1939753)
以前のバージョンでは、OperatorHub プロバイダータイプ filter プロパティーには、CatalogSource との関係が明確に表示されませんでした。この問題により、ユーザーは filter の基準の意味を理解できませんでした。このパッチにより、プロバイダータイプ filter は Source へ更新されます。これにより、filter と CatalogSource の関係がより明確に表示されます。(BZ#1919406)
以前のバージョンでは、Resources メニューの ResourceListDropdown コンポーネントは、一部の言語では国際化されていませんでした。今回の更新により、Resources メニューが更新され、英語以外のスピーカーのユーザーエクスペリエンスが改善されました。(BZ#1921267)
以前のバージョンでは、Delete Persistent Volume Claim などの一部のメニュー項目は、正しく国際化されていませんでした。現在は、より多くのメニュー項目が正しく国際化されています。(BZ#1926126)
以前のバージョンでは、Add HorizontalPodAutoscaler ページのテキストおよび警告メッセージの一部が国際化されていませんでした。現在、テキストは国際化されています。(BZ#1926131)
以前のバージョンでは、ユーザーが Operator SDK で Operator を作成し、xDescriptors={"urn:alm:<…>:hidden"} などのアノテーションを指定して、Operator インスタンス作成ページからフィールドを非表示にすると、フィールドがページに表示されたままになる場合がありました。現在、非表示フィールドは、Operator インスタンス作成ページから省略されています。(BZ#1966077)
以前のバージョンでは、モバイルデバイスでテーブルが正しく表示されませんでした。今回の更新で、テーブルが正しく表示されるようになりました。(BZ#1927013)
以前のバージョンでは、OpenShift Container Platform Web コンソールの起動に時間がかかる場合がありました。今回の更新により、Web コンソールがより迅速に起動するようになりました。(BZ#1927310)
以前のバージョンでは、OpenShift Container Platform 管理者に対する国際化された通知がなかったため、ユーザーエクスペリエンスが損なわれていました。現在は、国際化が可能になりました。(BZ#1927898)
以前のバージョンでは、Cluster Utilization ダッシュボードで国際化された期間がなかったため、ユーザーエクスペリエンスが損なわれていました。現在は、国際化が可能になりました。(BZ#1927902)
以前のバージョンでは、OpenShift Container Platform Web コンソールの Operator Lifecycle Manager (OLM) ステータス記述子に互換性のないデータタイプが割り当てられるとエラーが生じました。検証が追加され、互換性のないデータタイプが処理から排除され、エラーが回避されました。ログに記録された警告は、互換性のないステータスタイプも識別します。(BZ#1927941)
以下の OpenShift Container Platform Web コンソールビューは、マルチファセットフィルターリングをサポートするようになりました。
- Home Search (Resources タブ)
- Home Events (Resources タブ)
- Workloads Pods (Filter タブ)
詳細は、BZ#1930007 を参照してください。
以下のバグ修正は、OpenShift Container Platform Web コンソールのさまざまな翻訳の問題に対応します。
以前のバージョンでは、Web コンソールはハードコーディングされたチャネル文字列に依存して、チャネルモーダルドロップダウンを設定していました。その結果、ユーザーには、現在のバージョンに対して正しくない可能性のあるチャネル値が表示されていました。Cluster Version Operator が特定バージョンの正しいチャネルを提供しない場合は、チャネルモーダルドロップダウンはテキスト入力フィールドに変わり、ユーザーにチャネルとヘルプテキストを提案するようになりました。コンソールはハードコーディングされたチャネル文字列に依存しなくなりました。(BZ#1932281)
以前のバージョンでは、タイムスタンプは中国語または日本語用に正しくフォーマットされていませんでした。その結果、タイムスタンプが読みにくく、ユーザーエクスペリエンスが低下していました。今回の更新で、中国語と日本語用にタイムスタンプ形式 Moment.js がデフォルトで使用され、ユーザーエクスペリエンスが向上します。(BZ#1932453)
以前のバージョンでは、FilterToolbar コンポーネントの rowFilters プロパティーは、null 値を許可しませんでした。このため、rowFilters プロパティーが定義されていない場合、キャッチされない例外が出力されました。FilterToolbar コンポーネントで rowFilters プロパティーが参照されると、null 値が許可されるようになりました。その結果、rowFilters プロパティーが定義されていない場合は、FilterToolbar は例外を出力しません。(BZ#1937018)
以前のバージョンでは、間違ったスタイルのヘルプテキストが、フィールドレベルのヘルプインスタンスに適用されていました。現在は、フィールドレベルのヘルプインスタンスに対して正しいスタイルのヘルプテキストが表示され、コンソール全体で一貫性が保たれています。(BZ#1942749).
以前のバージョンでは、Operator Lifecycle Manamgent (OLM) ステータス条件記述子は、リソースの詳細ページで通常の詳細項目としてレンダリングされていました。その結果、Conditions テーブルは半分の幅でレンダリングされていました。今回の更新により、条件記述子は、オペランド の詳細ページの通常の Conditions テーブルの下にある全幅テーブルとして、レンダリングされるようになりました。(BZ#1943238)
以前のバージョンでは、Ingresses という単語は中国語ユーザーに翻訳されていましたが、ユーザーエクスペリエンスは良くありませんでした。現在は、Ingress という単語は翻訳されていません。(BZ#1945816)
以前のバージョンでは、Operators という単語は中国語ユーザーに翻訳されていましたが、複数形での翻訳は、ユーザーエクスペリエンスを悪くしていました。現在は、Operators という単語は翻訳されていません。(BZ#1945818)
以前のバージョンでは、コードが正しくないと、User および Group の詳細に、関係のないサブジェクトが表示されていました。現在は、User または Group でフィルターリングするコードが追加され、User および Group の詳細には関連するサブジェクトが表示されるようになりました。(BZ#1951212)
以前のバージョンでは、Pod コンテナーのテキストは国際化されていなかったため、ユーザーエクスペリエンスが低下していました。Pod コンテナーのテキストが国際化されたため、ユーザーエクスペリエンスが改善されました。(BZ#1937102)
以前のバージョンでは、PackageManifest リストページのアイテムは、詳細ページにリンクされていなかったため、ユーザーはリストページから個別の PackageManifest アイテムに簡単にドリルダウンできませんでした。PackageManifest アイテムはそれぞれ、他のリストページの規則に一致する詳細ページにリンクされるようになりました。ユーザーは、リストページから PackageManifest の詳細ページに簡単にアクセスできます。(BZ#1938321)
成功した 完了数の代わりに、必要な 完了数によってソートされた ジョブ テーブルの完了列。データは # Succeeded of # Desired と表示されるため、その列でソートすると、データが 2 番目の数値でソートされるため、わかりにくい結果となっていました。ジョブ 完了列は、わかりやすくするために # Succeeded でソートされるようになりました。(BZ#1902003)
Manage Columns モーダルの入力ラベルは、クリック可能なボタンではなかったため、クリックして列を管理することはできませんでした。このバグ修正により、ラベルは列の管理に使用できるクリック可能なボタンになりました。(BZ#1908343)
CSI プロビジョナーは、Google Cloud Platform でストレージクラスを作成する際に一覧表示されませんでした。今回のバグ修正により、この問題は解決されています。(BZ#1910500)
以前のバージョンでは、ユーザーが User Management Roles リストビューから Cluster Role をクリックする場合、詳細ページのバックリンクは、Cluster Roles であり、Cluster Roles の一般的なリストビューを提供していました。これにより、Web コンソールの後方ナビゲーションが誤ったページにリダイレクトされていました。このリリースでは、バックリンクにより、ユーザーは Cluster Role/RoleBinding の詳細ページから Role/Bindings リストビューに移動できます。これにより、ユーザーは Web コンソールで逆方向に適切にナビゲートできます。(BZ#1915971)
以前のバージョンでは、Created date time はユーザーが読み取れる形式で表示されませんでした。そのため、UTC で表示される時刻を理解して使用することが困難でした。今回のリリースにより、表示される時刻が再フォーマットされ、UTC が読み取り可能になり、理解できるようになりました。(BZ#1917241)
以前のバージョンでは、Web コンソールでの Pod 要求および制限の計算は正しくありませんでした。これは、完了した Pod または init コンテナーを除外しないために生じていました。今回のリリースにより、計算で必要のない Pod が除外され、Pod 要求の Web コンソール計算の結果の精度が改善されました。(BZ#1918785)
以前のバージョンでは、未定義の値を解析すると、Not a Number (NaN) 例外となり、Chart のツールチップのボックスには値が表示されませんでした。今回のリリースにより、データの取得時に開始日が指定され、Chart ツールチップに正しい値が表示されるようになりました。この変更により、結果が同期され、未定義の値が解析されなくなります。(BZ#1906304)
以前のバグ修正中に、Pod ログのダウンロードリンクが、空のダウンロード属性を持つ標準の HTML アンカー要素に変更されました。その結果、ダウンロードファイルはデフォルトのファイル名形式を失いました。この更新により、アンカー要素のダウンロード属性にファイル名が追加され、Pod ログのダウンロード時に <pod-name>-<container-name>.log 形式のデフォルトのファイル名が使用されるようになりました。(BZ#1945630)
以前のバージョンでは、ユーザーにリソースの作成パーミッションがあるものの、編集パーミッションがない場合は、Web コンソールの YAML エディターは誤って読み取り専用モードに設定されていました。エディターのコンテンツは、リソースの作成アクセスのあるユーザーが編集できるようになりました。(BZ#1824911)
以前のバージョンでは、Web コンソールはほとんどの場合に 12 時間形式で時間を表示し、24 時間形式で表示する場合もありました。また、過去の 1 年を上回る日数について年が表示されませんでした。今回のリリースにより、日付と時間が一貫性のある方法でフォーマットされ、ユーザーのロケールと言語設定と一致するようになり、過去の 1 年を上回る日数について年が表示されるようになりました。(BZ#1862084)
以前のバージョンでは、Web コンソールは、イベントを表示する権限を持たないユーザーの ClusterVersion リソースをポーリングしていました。これにより、コンソール Pod ログに多数のエラーが出力されます。これを回避するには、リソースをポーリングする前にユーザーのパーミッションを確認する必要があります。これにより、コンソール Pod ログの不要なエラーが排除されます。(BZ#1848151)
以前のバージョンでは、YAML エディターのキーボードユーザーは、エディターを終了できませんでした。エディター外の view shortcuts ポップオーバーへは、ユーザーはエディター内からアクセスできませんでした。この更新により、ユーザーは opt + F1 キーストロークを使用して、エディターの上に Accessibility help を表示できます。この変更により、YAML エディターのキーボードユーザーは、正しいキーストロークを使用してエディターを終了できます。(BZ#1874931)
OpenShift Container Platform (OCP) の 4.x リリース後、OCP 4 Web コンソールにアップロードされたバイナリーシークレットファイルをロードできませんでした。これにより、インストールが失敗していました。OpenShift Container Platform 4.8 では、この機能が OCP 4 Web コンソールに復元されました。必要なシークレットの入力は、バイナリーファイル形式を使用して実行できるようになりました。(BZ#1879638)
以前のバージョンでは、RoleBinding のリンクを適切に作成するための BZ#1871996 の修正により、namespace が選択された際のバインディングタイプの選択ができなくなりました。その結果、アクティブな namespace を持つユーザーは、アクティブな namespace を All namespaces に変更しないと、クラスター RoleBinding を作成できませんでした。この更新により、BZ#1871996 への変更の一部が元に戻され、ユーザーはアクティブな namespace に関係なくクラスターロールバインディングを作成できます。(BZ#1927882)

Web コンソール (開発者パースペクティブ)

以前のバージョンでは、開発者コンソールでサービスクラスターをローカルにするためにラベルが変更された場合、ユーザーは Knative サービスを作成できませんでした。Knative サービスの更新では、ユーザーが開発者コンソールから cluster-local として Knative サービスを作成できるようにするために、cluster-local でサポートされている最新のラベルを使用します。(BZ#1969951)
以前のバージョンでは、Image Manifest Vulnerabilities (IMV) の重大度が低および中の問題の色が (Quay.io) インターフェイスに表示される色と一致していませんでした。その結果、ユーザーが脆弱性の重大度を高に変更すると、IMV は誤った重大度を付けていました。この結果、IMV を確認する際に混乱が生じました。現在のリリースではこの問題は修正されています。(BZ#1942716)
以前のバージョンでは、Samples Operator がインストールされていないために OpenShift namespace テンプレートを使用できない場合は、Developer パースペクティブの トポロジー ビューがロードされませんでした。今回の更新でこの問題が修正されています。(BZ#1949810)
以前のバージョンでは、devfile をインポートする際に、Web コンソールは、環境変数、ポートおよび制限の設定を提供する build guidance プレースホルダーコンテナーを無視していました。新規のデプロイメントには、プレースホルダーイメージを取得できず、必要な設定が欠落しているために、起動できない 2 つ目のコンテナーが含まれました。これで、build guidance コンテナーが新規のデプロイメントから削除され、コンテナーは環境変数、ポート、および制限設定を追加します。(BZ#1952214)
以前のバージョンでは、別のタブで Developer パースペクティブを切り替え、プロジェクトの詳細を再読み込みする際に、パースペクティブに関連するルートはレンダリングされず、404 エラーが発生しました。今回の更新では、すべての非アクティブなルートが読み込まれ、正しいパースペクティブに切り替わるようになりました。(BZ#1929769)
以前のバージョンでは、ユーザーが namespace に必要なアクセス権を持たないためにエラーが発生すると、Monitoring ダッシュボードページの Workload ドロップダウンメニューに継続的にロード進行中のアイコンが表示されていました。現在のリリースではこの問題は修正されています。Monitoring ダッシュボードページには、Forbidden エラーが発生したことを示すエラーメッセージが表示されます。(BZ#1930546)
以前のバージョンでは、API サーバーはリソースの作成に失敗し、これにより、resource quota リソースの更新時に競合が発生すると、409 ステータスコードを返す可能性がありました。そのため、リソースは作成に失敗し、API 要求を再試行する必要があった可能性があります。今回の更新により、OpenShift Console Web アプリケーションは 409 のステータスコードを受信する際に要求を 3 回試行します。多くの場合、この回数は要求を実行するのに十分な回数です。409 ステータスコードが継続的に発生する場合、コンソールにエラーが表示されます。(BZ#1920699)
以前のバージョンでは、YAML タブを選択しても、metadata.managedFields セクションはすぐに折りたたまれませんでした。これは、Pipeline Builder および Edit HorizontalPodAutoscaler (HPA) などのページの Form または YAML スイッチャーの問題が原因でした。その結果、入力しようとしたドキュメントの部分が折りたたまれました。metadata.managedFields セクションはそのままとなり、カーソルは YAML エディターの左上の開始位置にリセットされました。現在のリリースではこの問題は修正されています。現在は、YAML をロードすると、metadata.managedFields セクションがすぐに折りたたまれます。(BZ#1932472)
以前のバージョンでは、プライベートリポジトリーの Git Import フローで作成されたパイプラインは実行できませんでした。これは、パイプライン ServiceAccount オブジェクトが、プライベート Git リポジトリーの Git インポート フローで作成されたシークレットを使用しないために生じました。今回の更新により、シークレット名をパイプライン ServiceAccount オブジェクトのアノテーションに追加し、パイプライン固有のアノテーションを指定されるシークレットに追加できるようになりました。その結果、プライベート Git リポジトリーのパイプラインは正常に実行されます。(BZ#1970470)
以前のバージョンでは、ユーザーが YAML エディターにフォーマットされた YAML スニペットを挿入すると、新しい選択がスニペットの新しいコンテンツと一致しませんでした。インデントが削除され、選択範囲にランダムな文字がいくつか表示されました。現在のリリースではこの問題は修正されています。これで、カーソルは開始位置に留まり、カーソルの終了位置に欠落しているインデントが追加されます。YAML スニペットの挿入後に、新しい選択が新しいコンテンツと一致します。(BZ#1952545)
以前のバージョンでは、アノテーションは Knative サービスの仕様およびメタデータに渡されていました。その結果、デコレーターは Topology の Knative サービスの関連するリビジョンに表示されました。このリリースでは、アノテーションを Knative サービスメタデータにのみ渡すことで、この問題を修正しています。現在、デコレーターは Topology の Knative サービスに対してのみ表示され、関連するリビジョンには表示されません。(BZ#1954959)
以前のバージョンでは、" などの空の文字列を持つパラメーターを使用してパイプラインを作成した場合、OpenShift Container Platform Web コンソールのフィールドは空の文字列を受け入れませんでした。現在のリリースではこの問題は修正されています。現在は、" は、パラメーターセクション内の有効なデフォルトプロパティーとしてサポートされています。(BZ#1951043)
以前のバージョンでは、ユーザーは Developer パースペクティブからプライベートサービスとして Knative サービスを作成できませんでした。この問題は、networking.knative.dev/visibility': 'cluster-local ラベルを更新して修正されています。(BZ#1970796)
以前のバージョンでは、シンクタイプの Kamelets は、ソースタイプと共にイベントソースのカタログに表示されていました。この問題は、Kamelets のリソースをフィルターリングして、ソースタイプのみをリストアップすることで修正されました。(BZ#1972258)

Windows Container

以前のバージョンでは、ユーザーが追加の Windows ノードをスケーリングすると、ロードバランサーサービスが不安定になりました。この更新により、ロードバランサーサービスが安定化され、ユーザーはパフォーマンスを不安定にすることなく複数の Windows ノードを追加できるようになります。(BZ#1905950)

以前のバージョンでは、ロードバランサーが作成され、それが Windows Pod の実行後に作成された場合は、kube-proxy サービスが予期せずクラッシュしていました。この更新により、kube-proxy サービスは、ロードバランサーサービスを再作成する際にクラッシュしなくなりました。(BZ#1939968)
以前のバージョンでは、ロードバランサーの Ingress の空の IP アドレス値が、データパスを壊していました。その結果、Windows サービスにアクセスできませんでした。今回の更新により、IP アドレスの値が空の場合でも、Windows サービスにアクセスできるようになります。(BZ#1952914)

以前のバージョンでは、ユーザーが Projected ボリュームで Windows Pod を作成した場合、Pod は ContainerCreating フェーズでスタックしたままでした。この更新により、Windows Pod の作成は正常に Running フェーズに進みます。(BZ#1973580)

1.7. バグ修正

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links