1.6. バグ修正
ベアメタルハードウェアのプロビジョニング
-
以前は、RHCOS イメージを一部のディスクに書き込むときに、
qemu-imgがスパース領域を含むディスク全体にスペースを割り当てていました。これにより、一部のハードウェアで書き込みプロセスの時間が長くなりました。この更新により、イメージ作成でqemu-imgスパースが無効になります。その結果、影響を受けるハードウェアでイメージの書き込みに時間がかからなくなりました。(BZ#2002009) -
以前は、
rotationフィールドがRootDeviceHintsに設定されている場合、ホストがプロビジョニングに失敗する可能性がありました。今回の更新により、RootDeviceHintsのrotationalフィールドが適切にコピーされ、チェックされるようになりました。その結果、rotationalフィールドを使用するとプロビジョニングが成功します。(BZ#2053721) 以前は、Ironic は仮想メディアを使用して Nokia OE 20 サーバーをプロビジョニングできませんでした。これは、
TransferProtocolType属性がオプションの属性であるにもかかわらず、BMC がこの属性を明示的にリクエストに設定することを要求したためです。さらに、ほとんどの BMC はsystemリソースのみを使用するのに対し、この BMC は専用のRedFish設定リソースを使用してブート順序をオーバーライドする必要もありました。このエラーは、Nokia OE 20 が vMedia アタッチメントにオプションのTransferProtocolType属性を厳密に必要とし、ブートシーケンスをオーバーライドするためにRedFish設定リソースを使用する必要があるために発生しました。その結果、Nokia OE 20 では仮想メディアベースのプロビジョニングが失敗します。この問題を回避する方法は 2 つあります。-
TransferProtocolType属性が欠落していることを示すエラーで vMedia アタッチメントリクエストが失敗した場合は、リクエストを再試行し、この属性を明示的に指定します。 - システムに RedFish 設定リソースが存在することを確認します。存在する場合は、ブートシーケンスのオーバーライドに使用します。
これらの回避策により、仮想メディアベースのプロビジョニングは Nokia OE 20 マシン上で成功します。(BZ#2059567)
-
- 以前は、Ironic API インスペクターイメージは、OpenShift Container Platform ベアメタル IPI デプロイメントを使用する場合、パッシブマルチパスセットアップの一部であるディスクをクリーンアップできませんでした。この更新プログラムは、アクティブまたはパッシブストレージアレイが使用されている場合の障害を修正します。その結果、お客様がアクティブまたはパッシブのマルチパスセットアップを使用したい場合に、OpenShift Container Platform ベアメタル IPI を使用できるようになりました。(BZ#2089309)
-
以前は、Ironic は
wwnシリアル番号をマルチパス デバイスに一致させることができませんでした。そのため、デバイスマッパーデバイスのwwnシリアル番号は、install-config.yaml設定ファイルのrootDeviceHintパラメーターで使用することができませんでした。今回の更新により、Ironic はwwnシリアル番号をマルチパスデバイスの一意の識別子として認識するようになりました。その結果、install-config.yamlファイルのデバイスマッパーデバイスにwwnシリアル番号を使用できるようになりました。(BZ#2098392) - 今回の更新の前は、Redfish システムが設定 URI を備えている場合、Ironic プロビジョニングサービスは常にこの URI を使用して、ブート関連の BIOS 設定を変更しようとしまていました。ただし、ベースボード管理コントローラー (BMC) が設定 URI を備えていても、この設定 URI を使用した特定の BIOS 設定の変更をサポートしていない場合、ベアメタルプロビジョニングは失敗します。OpenShift Container Platform 4.11 以降では、システムに設定 URI がある場合には、Ironic は続行する前に設定 URI を使用して特定の BIOS 設定を変更できることを確認します。それ以外の場合、Ironic はシステム URI を使用して変更を実装します。この追加のロジックにより、Ironic がブート関連の BIOS 設定の変更を適用でき、ベアメタルプロビジョニングが成功することが保証されます。(OCPBUGS-2052)
ビルド
-
以前は、
BuildConfigインスタンスのImageLabel名にスラッシュ (/) を使用すると、エラーが発生していました。この修正は、検証に使用されるユーティリティーを変更することで問題を解決します。その結果、BuildConfigインスタンスのImageLabel名にフォワードスラッシュを使用できます。(BZ#2105167) -
以前は、
$ oc new-app --search <image_stream_name>コマンドを使用すると、docker.ioイメージに関連する誤ったメッセージを受け取ることがありました。OpenShift Container Platform はdocker.ioを指すイメージストリームを使用しないため、ユーザーに混乱が生じました。この修正により、コードチェックが追加され、docker.ioへの参照が阻止されます。その結果、そのコマンドからの出力にはメッセージが含まれません。(BZ#2049889) - 以前は、Shared Resource CSI Driver メトリックは Telemetry サービスにエクスポートされませんでした。その結果、Shared Resource CSI Driver の使用状況メトリックを分析できませんでした。今回の修正により、Shared Resource CSI Driver メトリックが Telemetry サービスに公開されます。その結果、Shared Resource CSI Driver の使用状況メトリックを収集して分析することができます。(BZ#2058225)
デフォルトでは、Buildah は環境変数の内容を含むステップをログファイルに出力します。これには、ビルド入力シークレット が含まれる場合があります。
--quietビルド引数を使用してこれらの環境変数の出力を抑制することができますが、source-to-image (S2I) ビルドストラテジーを使用する場合は、この引数は使用できません。現在のリリースではこの問題は修正されています。環境変数の出力を抑制するには、ビルド設定でBUILDAH_QUIET環境変数を設定します。sourceStrategy: ... env: - name: "BUILDAH_QUIET" value: "true"-
今回の更新以前は、
$ oc new-app --search <image_stream_name>コマンドを使用すると、コンテナーイメージ"docker.io/library/<image_name>:<tag>"にアクセスできない可能性がある警告が表示されていました。そのため、OpenShift Container Platform でdocker.ioを指すイメージストリームがあるという混乱が生じていました。今回の更新ではコードチェックを追加して問題を解決することで、'docker.io' を指すという混乱が解消されました。現在、そのコマンドからの出力にdocker.ioに関するメッセージは含まれていません (BZ#2049889)。
クラウドコンピュート
-
CertificateSigningRequest(CSR) リソースの更新は、Kubernetes コントローラーマネージャーによって処理され、Cluster Machine Approver Operator によって適切に保留されたままになります。これにより、mapi_current_pending_csrメトリックの値が1に増加します。以前は、Kubernetes コントローラーマネージャーが CSR を承認すると、Operator はそれを無視し、メトリックを変更しませんでした。その結果、mapi_current_pending_csrメトリックは、Operator が次に調整するまで1のままでした。このリリースでは、他のコントローラーからの CSR 承認が常に調整されてメトリックが更新され、調整のたびにmapi_current_pending_csrメトリックの値が更新されます。(BZ#2047702) - 以前は、AWS SDK 内の既知のリージョンのリストに含まれるリージョンのみが検証され、他のリージョンを指定するとエラーが発生しました。これは、新しいリージョンが追加されると、SDK が更新されて新しいリージョン情報が含まれるまで使用できないことを意味していました。今回のリリースでは、リージョンが認識されない場合にユーザーに警告を発するなど、より厳密でない設定でリージョンが検証されるようになりました。その結果、新しいリージョンでは警告メッセージが表示される場合がありますが、すぐに使用することができます。(BZ#2065510)
-
以前は、Cluster Machine Approver Operator が
"Approved"ステータス条件を条件リストに追加していました。その結果、Kubernetes API サーバーは、メッセージ[SHOULD NOT HAPPEN] failed to update managedFieldsを含むエラーをログに記録していました。このリリースでは、Operator が更新され、リストに追加する前にその条件をチェックし、必要な場合にのみ条件を更新します。その結果、CertificateSigningRequestリソースで条件が重複しなくなり、Kubernetes API サーバーは重複に関するエラーをログに記録しなくなりました。(BZ#1978303) - 以前は、Red Hat OpenStack Platform (RHOSP) バージョン 16 に存在した Cisco ACI neutron 実装の欠陥が原因で、特定のネットワークに属するサブネットのクエリーが予期しない結果を返していました。その結果、RHOSP Cluster API プロバイダーは、同じサブネット上で重複するポートを使用してインスタンスをプロビジョニングしようとし、プロビジョニングが失敗する可能性がありました。このリリースでは、RHOSP Cluster API プロバイダーでの追加のフィルタリングにより、サブネットごとに複数のポートが存在しないことが保証され、Cisco ACI を使用して RHOSP バージョン 16 に OpenShift Container Platform をデプロイできるようになりました。(BZ#2033862)
- 以前は、Red Hat OpenStack Platform (RHOSP) Machine API プロバイダーがプロキシー環境変数ディレクティブを使用していなかったため、HTTP または HTTPS プロキシーの背後でのインストールが失敗していました。このリリースでは、プロバイダーはプロキシーディレクティブに従い、egress トラフィックがプロキシー経由でのみ許可される制限された環境で正しく機能します。(BZ#2046133)
- 以前は、OpenShift Container Platform 4.9 から 4.10 にアップグレードすると、複数のコントローラー間で不整合が発生し、誤ったバージョン番号になることがありました。その結果、バージョン番号に一貫性がありませんでした。このリリースでは、バージョン番号の一貫した読み取りが実行され、リリースバージョンはクラスター Operator ステータスで安定しています。(BZ#2059716)
- 以前は、AWS Machine API プロバイダーでロードバランサーターゲットのリークが発生する場合がありました。これは、コントロールプレーンマシンを交換するときに、IP ベースのロードバランサーアタッチメントがロードバランサーの登録内に残る可能性があるためです。このリリースでは、Amazon EC2 インスタンスが AWS から削除される前に、IP ベースのロードバランサーアタッチメントがロードバランサーから削除されます。その結果、リークが回避されます。(BZ#2065160)
-
以前は、アップグレード中に、Machine API を介して作成された新しいマシンが HW-13 にデフォルト設定され、クラスターの機能が低下していました。このリリースでは、テンプレートクローンからマシンを作成する際に、マシンコントローラーが仮想マシンのハードウェアバージョンをチェックします。テンプレートのハードウェアバージョンが 15 未満の場合、マシンは
failed状態になります。これは、OpenShift Container Platform 4.11 以降のバージョンでサポートされる最小のハードウェアバージョンです。(BZ#2059338) - 以前は、Azure 可用性セットの手順名ジェネレーターは、最大 80 文字の制限を超えていました。これにより、Machine API は、複数の可用性セットを作成するのではなく、名前切り捨ての際に同じセットを再利用する可能性があります。このリリースでは、手順名ジェネレーターが更新され、名前が 80 文字を超えないようにし、クラスター名がセット名で重複しないようにします。その結果、Azure 可用性セットが予期しない方法で手順名ジェネレーターによって切り捨てられることがなくなりました。(BZ#2093044)
- Cluster Autoscaler Operator は、リーダー選択パラメーターを設定せずにクラスターオートスケーラーをデプロイしていたため、クラスターの再起動後に、クラスターオートスケーラーが予期せず失敗して再起動することがありました。今回の修正により、Cluster Autoscaler Operator は、適切に定義されたリーダー選出フラグを使用して、クラスターオートスケーラーをデプロイするようになりました。その結果、クラスターオートスケーラーは再起動後に期待どおりに動作します。(BZ#2063194)"
-
以前は、証明書署名要求 (CSR) の更新は
kube-controller-managerによって処理され、マシンの承認者によって適切に保留されていたため、mapi_current_pending_csrが1に増加していました。その後、kube-controller-managerは CSR を承認しましたが、マシンの承認者はそれを無視したため、メトリックは変更されませんでした。その結果、mapi_current_pending_csrは、別のマシン承認者が調整するまで1のままでした。今回の更新により、CSR の承認が他のコントローラーから調整され、メトリックが適切に更新されるようになります。その結果、mapi_current_pending_csrは、調整のたびに常に最新の状態になります。(BZ#2072195) - 以前は、クラスターのインストール時に十分な数のワーカーノードが開始されなかった場合、他の Operator が機能低下を報告していても、Machine API Operator は機能低下を報告しませんでした。このリリースでは、Machine API Operator が機能低下として報告されるようになり、このシナリオではインストールログにエラーが記録されます。その結果、Machine API Operator が失敗した Operator のリストに表示されるので、ユーザーはワーカーノードが不十分な理由としてマシンの状態を調べることを理解するようになりました。(BZ#1994820)
- Machine API Operator がプロキシー環境変数ディレクティブを受け入れなかったため、HTTP または HTTPS プロキシーの背後でのインストールが失敗しました。今回の修正により、Machine API Operator の HTTP トランスポートロジックが、プロキシーディレクティブに従うようになりました。その結果、Machine API Operator は、egress トラフィックがプロキシー経由でのみ許可される制限された環境で動作するようになりました。(BZ#2082667)
- 以前は、数千のタグと重い API 負荷を持つクラスターの vShpere へのインストールは失敗していました。現在、マシンコントローラーは、特定の OpenShift Container Platform インストールに関連するタグのみをクエリーします。その結果、OpenShift Container Platform はこれらのクラスターの vSphere に正しくインストールされます。(BZ#2097153)
-
kubelet はノードゾーンラベルを取得するために vCenter に接続する必要があるため、vCenter 認証情報がシークレットに保存されている場合、kube クライアントが時間どおりに作成されなかったため、kubelet を起動できませんでした。その結果、ノードを再起動すると、
cloud-provider-configconfig map を編集するときに発生するように、ノードが起動しませんでした。今回の修正により、認証情報がシークレットに保存されている場合、kubelet はノード登録後にゾーンラベルを取得するようになりました。その結果、ノードは期待どおりに再起動します。(BZ#1902307) -
以前は、
timeoutオプションがないためにコントローラーがブロックされ、vCenter がまったく応答しないか、応答が非常に遅くなることがありました。このリリースでは、vSphere マシン コントローラー内の vCenter クライアントのtimeoutオプションが追加されています。(BZ#2083237)
Cluster Version Operator
-
以前は、アップグレード中にエラーが発生した場合、Cluster Version Operator (CVO) は現在のリリースマニフェストの調整を停止していました。今回の更新では、リリースの読み込みは調整から分離されているため、調整が読み込みをブロックすることはありません。また、リリースの読み込みのステータスを明確にするために、新しい条件
ReleaseAcceptedが追加されました。(BZ#1822752)
Console Metal3 プラグイン
-
以前は、
bootModeストラテジーを設定するためのオプションが UI にありませんでした。その結果、UI は常にデフォルト (UEFI) のブートストラテジーを使用し、これにより、ベアメタルデプロイメントの一部のタイプの起動で問題が発生していました。この更新により、適切なブートモードストラテジーを選択するための Add Bare Metal ホストフォームに新しいフィールドが公開されます。その結果、ベアメタルマシンが正常に起動します。(BZ#2091030) - 以前は、ノードメンテナンス機能が新しいプロジェクトに移動されたため、API が変更されました。その結果、ノードのメンテナンスが機能しなくなりました。この更新により、新しい API で正しく動作するようにコードが修正されます。その結果、ノードのメンテナンスが再び機能します。(BZ#2090621)
- 以前は、支援インストーラーによって作成されたクラスターの day 2 ワーカーで、基礎となるベアメタルホストとマシンリソースが欠落している場合がありました。その結果、ワーカーノードの詳細を表示しようとすると、UI が失敗しました。今回の更新により、ベアメタルホストとマシンリソースがより適切に処理され、UI に利用可能なすべての詳細が表示されます。(BZ#2090993)
DNS (Domain Name System)
-
Topology Aware Hint (トポロジーを意識したヒント) は、OpenShift Container Platform 4.11 の新機能で、
EndpointSliceコントローラーが、サービスのエンドポイントにトラフィックをルーティングする方法について、Container Network Interface (CNI) にヒントを指定できるようにするものです。DNS Operator は、クラスター DNS サービスの Topology Aware Hint を有効にしていませんでした。その結果、CNI ネットワークプロバイダーは DNS トラフィックをゾーンまたはノードに対してローカルに保持しませんでした。この修正により、DNS Operator が更新され、クラスター DNS サービスで Topology Aware Hint が指定されるようになりました。(BZ#2095941) -
以前は、kubelet は、ノードホストの
/etc/resolv.confに基づいて、Pod のデフォルトの/etc/resolv.confを作成していました。その結果、不正な形式のresolv.confファイルにより、リゾルバーがresolv.confの解析に失敗し、Pod での DNS 解決が中断される可能性がありました。今回の更新により、kubelet はresolv.confファイルを受け入れ、Pod は有効なresolv.confファイルを取得します。(BZ#2063414) -
以前は、DNS Operator は DNS Pod に
cluster-autoscaler.kubernetes.io/enable-ds-evictionアノテーションを設定していませんでした。そのため、クラスターオートスケーラーは、ノードを削除する前にノードから DNS Pod を削除しませんでした。今回の更新により、DNS Operator が変更され、cluster-autoscaler.kubernetes.io/enable-ds-evictionアノテーションが DNS Pod に追加されました。クラスターオートスケーラーによってノードを削除する前に、ノードから DNS Pod を削除できるようになりました。(BZ#2061244)
Image Registry
-
以前は、イメージレジストリーは、完全に一致する場合にのみ
ImageContentSourcePolicy(ICSP) をソースとして使用していました。すべてのサブリポジトリーで、同じソースファイルがプルされると予想されていました。サブリポジトリーの ICSP 名とパスが一致しませんでした。その結果、イメージは使用されませんでした。現在は、ICSP がサブリポジトリーに正常に適用され、ミラーリングされたイメージを使用できるようになりました。(BZ#2014240) - 以前は、プルーナーが失敗した場合、プルーナーが正常に実行されるまで、イメージレジストリー Operator は機能が低下していると報告されていました。今回の更新により、Operator はプルーナーの障害に対する回復力が向上しました。(BZ#1990125)
-
これまでレジストリーは、
ImageContentSourcePolicy(ICSP) を適用するときに完全な一致を使用していました。今回の更新で、ICSP がサブリポジトリーに適用され、ミラーが期待どおりに機能するようになりました。(BZ#2014240) - これまで、Image Registry Operator は RHOSP 上の AWS S3 で機能しませんでした。今回の更新で、イメージレジストリー Operator はすべてのプラットフォームで AWS S3 を信頼するようになりました。(BZ#2007611)
- これまで、OpenShift Container Platform イメージレジストリーは Ceph Radosgw で機能しませんでした。今回の更新で、イメージレジストリーは Ceph Radosgw で機能するようになりました。(BZ#1976782)
-
これまで、Image Registry Operator はアップストリームレジストリーからの
429エラーメッセージを、あたかもデータが利用できないかのように解釈していました。Operator は、429 Too many Requestsの代わりに404 Not Foundメッセージを返しました。今回の更新により、適切な429 Too many Requestsメッセージが返され、管理者はリクエストの再試行する必要があることを認識できるようになりました。(BZ#1923536) - これまで、Image Registry Operator は CloudFront の設定に使用できませんでした。今回の更新により、Image Registry Operator が CloudFront を設定できるようになりました。(BZ#2065224)
- これまで、Image Registry Operator は KMS 暗号化が有効な場合にイメージをプッシュしましたが、プルしませんでした。今回の更新により、KMS 暗号化を有効にしてイメージをプッシュおよびプルできるようになりました。(BZ#2048214)
- これまで、Image Registry Operator は認証情報が提供されないためにパブリックイメージを匿名でプルできませんでした。今回の更新により、クライアントはパブリックイメージを匿名でプルできるようになりました。(BZ#2060605)
-
これまで、Image Registry Operator は
ap-southeast-3AWS リージョンを使用できませんでした。今回の更新により、レジストリーをap-southeast-3に設定できるようになりました。(BZ#2065552)
インストーラー
- 以前は、ユーザーが OpenShift Container Platform クラスター名にピリオドを指定すると、インストールが失敗していました。今回の更新で、クラスター名にピリオドが含まれている場合にエラーを返す検証チェックがインストールプログラムに追加されました。(BZ#2084580)
-
以前は、インストールプログラムを使用して
install-config.yamlファイルを作成するときに、ユーザーは AWSus-gov-east-1リージョンを選択できました。インストールプログラムは、パブリック AWS リージョンのinstall-config.yamlファイルの作成にしか使用できなかったため、デプロイが失敗しました。この更新により、パブリック AWS クラウドでサポートされていないすべての AWS リージョンがインストール プログラムから削除されます。(BZ#2048222) -
以前は、インストールプログラムを使用して
install-config.yamlファイルを作成するときに、ユーザーはap-north-east-3リージョンを選択できませんでした。この問題の原因となった AWS SDK が更新され、ユーザーはap-north-east-3リージョンを選択できるようになりました。(BZ#1996544) - 以前は、インストールプログラムが API 仮想 IP アドレスの DNS レコードを作成しなかったため、プライベート (内部) OpenShift Container Platform クラスターを Azure Stack Hub にインストールできませんでした。この更新により、この問題の原因となった無効なチェックが削除されます。インストールプログラムは、プライベートクラスターの DNS レコードを正しく作成するようになりました。(BZ#2061549)
- 以前は、IBM Cloud VPC クラスターをアンインストールすると、予期しない結果が生じる可能性がありました。ユーザーがクラスター (クラスター 1) をアンインストールすると、別のクラスター (クラスター 2) の DNS レコードが削除されました。これは、クラスター 1 の名前 (example) がクラスター 2 の名前 (myexample) のサブセットである場合、または両方のクラスターがベースドメインを共有している場合に削除されました。この更新では、この動作を修正しています。アンインストールされるクラスターに固有のリソースのみが削除されるようになりました。(BZ#2060617)
- 以前は、Azure Stack Hub は Standard_LRS 以外のディスクタイプをサポートしていませんでした。今回の更新により、ディスクタイプをカスタマイズする機能が追加されました。これにより、手動でカスタマイズしなくても、クラスターにデフォルトのディスクタイプを設定することができます。その結果、ディスクタイプをハードコーディングするのではなく、ユーザーからの入力を受け付け、Stack Hub API に対して検証する方法に切り替えられました。(BZ#2061544)
- 以前は、クラスターを破棄する際、DNS レコードがホストゾーンから削除されたときに、クラスターのプライベート route5 ホストゾーンの ID が誤って報告されていました。これにより、破棄する側のログに誤ったホストゾーン ID が報告されました。この更新では、ログで正しいホストゾーン ID が使用されます。その結果、ベースドメインのホストゾーンで DNS レコードを破棄すると、ログには正しいホストゾーン ID が表示されます。(BZ#1965969)
-
以前は、AWS カスタムサービスエンドポイントをリクエストするときに、システムプロキシー設定が考慮されませんでした。この更新により、AWS カスタムサービスエンドポイントの検証が設定され、AWS カスタムサービスエンドポイントへの
HEADリクエストと共にシステムプロキシー設定が考慮されます。その結果、ユーザーのマシンから AWS カスタムサービスエンドポイントにアクセスすることができます。(BZ#2048451) -
これまで、インストールプログラムは、インストーラーホスト上の
$PATHで 任意の Terraform プロバイダーを使用していました。したがって、$PATHに Terraform プロバイダーがあり、インストールプログラムに組み込まれたプロバイダーではなく、誤ったバージョンまたはプロバイダーを使用していると、インストールは失敗しました。今回の更新により、インストールプログラムはプロバイダーを既知のディレクトリーに組み込み、既知のディレクトリーを使用するように Terraform を設定します。その結果、インストールプログラムは常に既知のディレクトリー内のプロバイダーを使用するため、インストールは成功します。(BZ#1932812) - 以前は、新しいロードバランサーを更新するときに、AWS Terraform プロバイダーに結果整合性の問題がありました。したがって、新しいロードバランサーにアクセスしようとすると、インストールが失敗します。今回の修正により、インストールプログラムがアップストリームの Terraform プロバイダーに更新され、結果整合性が保証されるようになりました。その結果、インストールは失敗しなくなりました。(BZ#1898265)
-
以前は、インストールプログラムには、クォータとパーミッションをチェックする必要な API のリストがあり、そのリストには、ユーザーがパーミッションを提供しないと失敗する不要な API が含まれていました。今回の更新により、API のリストが
requiredとoptionalに分割され、optionalAPI にはアクセスできなくなりました。optionalAPI については、警告メッセージが表示されます。(BZ#2084280) -
以前は、特定のクラスター用に作成されたすべてのリソースを分離して削除するコードをデータベースから削除するためにインストールプログラムによって使用されるタグ
kubernetes.io_cluster<infraID>が.appsエントリーにありませんでした。今回の更新により、作成時にクラスター Ingress Operator にタグが追加され、エントリーが削除可能になりました。(BZ#2055601) -
以前は、内部公開ストラテジーを使用すると、
openshift-installコマンドが失敗していました。今回の更新により、openshift-installコマンドが失敗しなくなりました。(BZ#2047670) - 以前は、新しく作成された Virtual Private Cloud (VPC) に更新するときに、AWS Terraform プロバイダーに結果整合性の問題がありました。その結果、VPC にアクセスしようとすると、インストールプログラムが失敗していました。今回の更新により、インストールプログラムがアップストリームの Terraform プロバイダーに更新され、インストールが失敗しなくなりました。(BZ#2043080)
- 以前は、新しく作成されたネットワークインターフェイスに更新するときに、AWS Terraform プロバイダーに結果整合性の問題がありました。その結果、インストールはネットワークインターフェイスにアクセスできませんでした。今回の更新により、結果整合性を受け入れるように Terraform プロバイダーが更新され、インストールが失敗しなくなりました。(BZ#2047741)
-
以前は、インストーラーによってプロビジョニングされたインフラストラクチャーを使用して VMware クラスターをインストールするときに、
corespersocketの値がnumCoresの値よりも高くなることがありました。これにより、インストール中に予期しない結果が生じる可能性がありました。今回の更新により、ユーザーはクラスターが作成される前にこれらの値を修正するよう警告を受け取ります。(BZ#2034147) - 以前は、まれなバグにより、AWS クラスターのインストール中に不整合が発生していました。このシナリオを回避するために、インストールプログラムが更新されました。(BZ#2046277)
- 以前は、サポートされているユーザー定義タグの数は 8 で、AWS リソース用に予約された OpenShift Container Platform タグは 2 でした。このリリースでは、サポートされるユーザー定義タグの数が 25 になり、AWS リソース用に予約された OpenShift Container Platform タグが 25 になりました。インストール時に最大 25 のユーザータグを追加できるようになりました。(CFE#592)
- 以前は、ブートストラップマシンは、インストーラーによってプロビジョニングされたインフラストラクチャーを使用して Azure にインストールするときに、デフォルトのサイズとインスタンスタイプを使用していました。今回の更新により、ブートストラップマシンは、コントロールプレーンマシンのサイズとインスタンスタイプを使用します。インストール設定のコントロールプレーン設定を変更することで、ブートストラップマシンのサイズとインスタンスタイプを制御できるようになりました。(BZ#2026356)
- 以前は、インストールプログラムが Terraform にあいまいなネットワーク名を提供していました。これにより、Terraform が使用する正しいネットワークを決定できなくなる可能性がありました。今回の更新で、インストールプログラムが Terraform に一意のネットワーク ID を提供するため、インストールが成功するようになります。(BZ#1918005)
- 以前は、AWS にクラスターをインストールするときに、依存する NAT ゲートウェイが作成される前にコントロールプレーンマシンが作成される可能性があり、インストールが失敗していました。今回の更新により、Terraform は、コントロールプレーンマシンが作成される前に、NAT ゲートウェイが作成されていることを確認します。これにより、インストールが成功することが保証されます。(BZ#2049108)
- 以前は、デフォルトの OSN ネットワークではなく OVN ネットワークを使用した場合、必要な最大時間よりも長くかかるため、スケールアップタスクが失敗していました。この更新により、タスクを完了できるように、スケールアップタスク中の再試行回数が 2 倍になります。(BZ#2090151)
-
以前は、データベースから複数のクラスターを並行して削除しようとすると、
vmwareライブラリーおよびgovmomiライブラリーのバグが原因で削除プロセスが失敗していました。このバグにより、クラスターのタグの 1 つが削除され、削除プロセスでタグが見つからなかったときに 404 エラーが発生しました。この更新は、見つからないタグを無視し、エラーなしで終了するように削除プロセスを続行します。(BZ#2021041) - 今回の更新により、Red Hat Virtualization (RHV) 上の OpenShift Container Platform は、コントロールプレーン用の事前割り当てディスクと、インストーラーによってプロビジョニングされたインフラストラクチャー用のワーカーノードをサポートします。高負荷環境では、事前に割り当てられたディスクにより、etcd やその他のコンポーネントのパフォーマンスが向上します。(BZ#2035334)
-
これまで、複数のクラスターを並行して削除しようとすると、
vmware/govmomiライブラリーのバグが原因でプロセスが失敗していました。このバグにより、クラスタータグが削除され、削除プロセスでタグが見つからない場合に404エラーが発生していました。今回の更新では、見つからないタグが無視され、削除を継続してエラーなしで終了するようになりました。(BZ#2021041) - 以前は、VMware vSphere のインストール方法には、設定ファイルの作成中にネットワークの存在を確認する検証が含まれていました。これにより、ユーザーがプロビジョニングしたインフラストラクチャーや、インフラストラクチャーのプロビジョニングの一部としてネットワークを作成できるその他のインストール方法で、エラーが発生しました。この場合、config ファイルの生成時にネットワークが存在しない可能性があります。この修正により、インストールプログラムが更新され、インストーラーによってプロビジョニングされたインフラストラクチャーインストールでのみ、ネットワーク検証が実行されます。その結果、ユーザーがプロビジョニングしたインフラストラクチャーやその他のインストール方法で、ネットワークの存在に関係なく設定ファイルを生成できます。(BZ#2050767)
-
以前は、
runcはlibseccomp2.5 以降に対して反転した依存関係を持っていたため、オペレーティングシステムがバージョン 8.3 以降を使用してインストールされ、8.4 以降に完全に更新されていない場合に問題が発生していました。今回の更新により、RHEL ホストが正常にインストールされ、パッケージの初期バージョンの問題が回避されます。(BZ#2060147) - 以前は、インストールプログラムは、terraform へのネットワークリソースを相対パスで指定していました。ネットワークリソースがフォルダーにネストされている場合、terraform プロバイダーはリソースを見つけることができませんでした。今回の更新により、ネットワークリソースが ID で指定されるようになり、インストールが成功するようになりました。(BZ#2063829)
-
以前は、vSphere RHCOS イメージに
/etc/resolv.confファイルがありませんでした。これにより、デフォルトのnetworkmanager設定で/etc/resolv.confのエラーが表示されました。今回の更新では、rc-manager=unmanaged値が設定され、networkmanager設定は/etc/resolv.confにダイレクトされなくなりました。(BZ#2029438) - 以前は、Amazon Web Services (AWS) では必要ないため、インストールプログラムはクラウドプロバイダー設定を作成しませんでした。これにより、Kubernetes API サーバーでは、クラウドプロバイダーの設定なしでエラーが発生していました。今回の更新により、AWS 用の空のクラウドプロバイダー設定が作成され、Kubernetes API サーバーが正常に実行できるようになりました。(BZ#1926975)
Kubernetes API サーバー
-
以前は、ストリーミングに使用される実行時間の長いリクエストは、
KubeAPIErrorBudgetBurnの計算で考慮されていました。その結果、KubeAPIErrorBudgetBurnからのアラートがトリガーされ、誤検出が発生していました。この更新により、長時間実行されるリクエストがKubeAPIErrorBudgetBurnの計算から除外されます。その結果、KubeAPIErrorBudgetBurnメトリックでの誤検出が減少するようになりました。(BZ#1982704)
Kubernetes Scheduler
- OpenShift Container Platform 4.11 では、ホストされたコントロールプレーンが有効になっているクラスターに descheduler がインストールされている場合、ホストされたコントロールプレーンの namespace はエビクションから除外されます。その結果、descheduler がインストールされている場合、Pod はホストされたコントロールプレーンの namespace から削除されなくなりました。(BZ#2000653)
-
以前は、リソースは、
kubedeschedulerカスタム リソース (CR) の所有者参照で API バージョンを誤って指定していました。その結果、所有者参照が無効になり、kubedeschedulerCR の実行時に影響を受けるリソースが削除されませんでした。この更新では、すべての所有者参照で正しい API バージョンが指定されます。その結果、kubedeschedulerCR への所有者参照を持つすべてのリソースは、CR が削除された後に削除されます。(BZ#1957012)
Machine Config Operator
-
keyFileは RHEL ノード上の NetworkManager のデフォルトプラグインとして設定されていないため、再起動後に RHEL ノードが準備完了状態にならない場合があります。今回の修正により、keyFileはすべてのクラスターノードでデフォルトの NetworkManager プラグインとして設定されます。その結果、ノードは再起動後に正常に準備完了状態になります。(BZ#2060133) -
vSphere UPI クラスターはインストール時に
PlatformStatus.VSphereパラメーターを設定しないため、パラメーターはnilに設定されていました。これにより、MCO のログには、このパラメーターは値をnilにすることはできませんという不要なメッセージが繰り返し出力されるようになりました。この修正により、警告が削除されます。この警告は、別の問題を解決するために追加されたものでした。その結果、ログには vSphere UPI インストールに関するこのメッセージが表示されなくなりました。(BZ#2080267) -
以前は、FIPS と
realTimeKernelの両方でクラスターを作成しようとすると、コード内のマージロジックの問題により、Machine Config Operator (MCO) が低下しました。今回の更新により、FIPS とrealTimeKernelの両方でクラスターを作成するときに MCO が低下しなくなりました。(BZ#2096496)
Compliance Operator
-
以前は、Compliance Operator がマシン設定データへの参照を保持していたため、メモリー使用量が大幅に増加していました。その結果、Compliance Operator は、OOM (Out-of-Memory) 例外のために
CrashLoopBackoffsで失敗していました。回避策として、Compliance Operator の更新バージョンを使用する必要があります。たとえば、0.1.53 では、メモリー内の大規模なマシン設定データセットの処理が改善されています。その結果、Compliance Operator は、大規模なマシン設定データセットを処理する際に引き続き実行されます。(BZ#2094854)
管理コンソール
-
以前は、
InstallPlansを承認するときに、Web コンソールはパーミッションを適切に認証していませんでした。その結果、処理されないエラーが発生する可能性がありました。今回の更新により、一貫性を保つためにパーミッションが変更され、エラーメッセージが Web コンソールに正しく表示されるようになりました。(BZ#2006067)
モニタリング
-
今回の更新前は、コンテナーラベルが高いカーディナリティーのために削除されていたため、
container_fs*メトリックのコンテナーラベルを使用するクエリーを含む OpenShift Container Platform Web コンソールのダッシュボードは、データポイントを返しませんでした。この更新により問題が解決され、これらのダッシュボードに期待どおりにデータが表示されるようになりました。(BZ#2037513) -
この更新の前は、
prometheus-operatorコンポーネントは config map でScrapeTimeoutの任意の時間値を許可していました。ScrapeTimeoutをScrapeInterval値よりも大きい値に設定すると、Prometheus は config map 設定のロードを停止し、その後のすべての設定変更の適用に失敗します。今回の更新により、指定されたScrapeTimeout値がScrapeInterval値より大きい場合、システムは設定を無効としてログに記録しますが、他の config map 設定のロードを続行します。(BZ#2037762) - 今回の更新前は、OpenShift Container Platform Web コンソールの Kubernetes / Compute Resources / Cluster ダッシュボードの CPU 使用率 パネルで、ノードの CPU 使用率を計算するために使用される式が、無効な負の値を誤って表示することがありました。今回の更新により、式が更新され、CPU 使用率 パネルに正しい値が表示されるようになりました。(BZ#2040635)
-
この更新の前は、新しい Pod が使用可能になる前に、更新プロセスによって古い Pod が削除されたため、15 日ごとに発生する自動更新中に、
prometheus-adapterコンポーネントのデータにアクセスできませんでした。このリリースでは、更新プロセス中に古い Pod のデータを引き続き使用できるように、新しい Pod がリクエストを処理できるようになった後、自動更新プロセスで古い Pod のみが削除されるようになりました。(BZ#2048333) -
この更新の前は、
kube-state-metricsから、kube_pod_container_status_terminated_reason、kube_pod_init_container_status_terminated_reason、およびkube_pod_status_scheduled_timeのメトリックが誤って欠落していました。今回のリリースでは、kube-state-metricsがこれらのメトリックを正しく表示して使用できるようになりました。(BZ#2050120) -
この更新の前は、
prometheus-operatorコンポーネントに無効な書き込み再ラベル config map 設定が存在した場合、この設定は引き続きすべての後続の設定を読み込んでいました。このリリースでは、設定を読み込むときに、コンポーネントが有効な書き込み再ラベル設定をチェックします。無効な設定が存在する場合、エラーがログに記録され、設定の読み込みプロセスが停止します。(BZ#2051470) -
この更新の前は、Prometheus Pod の
init-config-reloaderコンテナーは、コンテナーに実際に必要なリソースが少ない場合でも、100mの CPU と50Miのメモリーを要求していました。今回の更新により、コンテナーは1mの CPU と10Miのメモリーを要求します。これらの設定は、config-reloaderコンテナーの設定と一致しています。(BZ#2057025) -
この更新の前は、管理者がユーザーワークロードモニタリングを有効にした場合、
user-workload-monitoring-configconfig map は自動的に作成されませんでした。user-workload-monitoring-config-editロールを持つ管理者以外のユーザーには、config map を手動で作成するパーミッションがなかったため、管理者が config map を作成する必要がありました。今回の更新により、管理者がユーザーワークロードモニタリングを有効にすると、user-workload-monitoring-configconfig map が自動的に作成され、適切なロールを持つユーザーが編集できるようになりました。(BZ#2065577) - この更新の前は、デプロイメントを削除した後、Cluster Monitoring Operator (CMO) は削除が完了することを待たなかったため、調整エラーが発生していました。今回の更新により、CMO はデプロイメントが削除されるまで待機してから、デプロイを再作成するようになり、この問題が解決されました。(BZ#2069068)
- この更新の前は、ユーザーワークロードモニタリングに関しては、Prometheus でメトリクスの外部ラベルを設定した場合、CMO はこれらのラベルを Thanos Ruler に正しく伝播しませんでした。Prometheus のユーザーワークロードモニタリングインスタンスで提供されていないユーザー定義プロジェクトの外部メトリクスをクエリーした場合、Prometheus で外部ラベルを追加するように設定されていても、これらのメトリクスに外部ラベルが表示されないことがありました。今回の更新により、CMO は、Prometheus で設定した外部ラベルを Thanos Ruler に適切に伝播するようになり、外部メトリックをクエリーするときにラベルを表示できるようになりました。したがって、ユーザー定義のプロジェクトの場合、Prometheus のユーザーワークロードモニタリングインスタンスによって提供されない外部メトリクスをクエリーすると、外部ラベルを追加するように Prometheus を設定していても、これらのメトリクスの外部ラベルが表示されないことがあります。今回の更新により、CMO は、Prometheus で設定した外部ラベルを Thanos Ruler に適切に伝播するようになり、外部メトリックをクエリーするときにラベルを表示できるようになりました。(BZ#2073112)
-
この更新の前は、
tunbrインターフェイスがNodeNetworkInterfaceFlappingアラートを誤ってトリガーしていました。今回の更新により、アラートが無視するインターフェイスのリストにtunbrインターフェイスが含まれるようになり、アラートが誤ってトリガーされることはなくなりました。(BZ#2090838) - 以前は、Prometheus Operator は無効な再ラベル設定を許可していました。今回の更新により、Prometheus Operator は再ラベル付けされた設定を検証します。(BZ#2051407)
ネットワーク
- 以前は、追加のネットワークアタッチメントにボンディング CNI プラグインを使用する場合、Multus と互換性がありませんでした。ボンディング CNI プラグインを Whereabouts IPAM プラグインと組み合わせてネットワークアタッチメント定義に使用すると、割り当てられた IP アドレスが正しく調整されませんでした。ボンディング CNI プラグインを使用するネットワークアタッチメント定義が、IP アドレスの割り当てに Whereabouts IPAM プラグインで正しく機能するようになりました。(BZ#2082360)
- 以前は、OVN-Kubernetes クラスターネットワークプロバイダーを複数のデフォルトゲートウェイで使用すると、間違ったゲートウェイが選択され、OVN-Kubernetes Pod が予期せずに停止していました。これらの Pod が失敗しないように、正しいデフォルトゲートウェイが選択されるようになりました。(BZ#2040933)
- OVN-Kubernetes クラスターネットワークプロバイダーを使用するクラスターの場合、以前は NetworkManager サービスがノードで再起動すると、そのノードのネットワーク接続が失われました。現在は、ネットワーク接続は NetworkManager サービスの再起動後も維持されます。(BZ#2048352)
-
以前は、キャッシュの更新を処理する
goroutineが、mutexを保持している間、バッファリングされていないチャネルへの書き込みを停止させる可能性がありました。今回の更新で、これらの競合状態が解決されました。(BZ#2052398) -
以前は、ovn-kubernetes の場合、ボンディングまたは チームインターフェイスを使用して起動時に
br-exをセットアップすると、br-exとボンディングインターフェイスの間でメディアアクセス制御 (MAC) アドレスの不一致が発生していました。その結果、ベアメタルまたは一部の仮想プラットフォームでは、予期しないbr-exMAC アドレスが原因で、ネットワークインターフェイスコントローラー (NIC) ドライバーがトラフィックをドロップしたため、すべてのトラフィックがドロップされました。今回の更新により、br-exとボンディングインターフェイスは、同じ MAC アドレスを使用するため、トラフィックがドロップされなくなりました。(BZ#2103080) -
以前は、
cluster-readerロールを持つユーザーは、NodeNetworkConfigurationPolicyなどのカスタムリソースを kubernetes-nmstate から読み取ることができませんでした。今回の更新により、cluster-readerロールを持つユーザーは、kubernetes-nmstate カスタム リソースを読み取ることができるようになります。(BZ#2022745) -
以前は、サービスエンドポイントが削除されたときに
LoadBalancerIP の contrack エントリーが削除されず、接続が失敗していました。今回の更新により、contrack エントリーによって接続が失敗することはなくなりました。(BZ#2061002) -
以前は、
jq packageがないことが原因で、ノードのデプロイメント時に RHEL ノードを含むクラスターのスケールアップが失敗していました。今回の更新により、デプロイ時に ` jq package` がインストールされ、RHEL ノードを含むクラスターのスケールアップが成功するようになります。(BZ#2052393) - 以前は、サービスの設定変更で、OVN-Kubernetes は必要以上の時間を費やしていました。これにより、サービスの設定変更で著しいレイテンシーが発生していました。今回の更新により、OVN-Kubernetes は、サービスの設定変更のレイテンシーを低減するように最適化されました。(BZ#2070674)
- 以前は、Whereabouts IPAM CNI の IP 調整 CronJob が API 接続の問題により失敗し、CronJob が断続的に失敗していました。今回の更新により、Whereabouts IPAM CNI で起動された CronJob は、api-internal サーバーアドレスと延長された api タイムアウトを使用して、これらの接続の問題を回避しています。(BZ#2048575)
-
今回の更新により、Kubernetes-NMstate がインストールされた OpenShift Container Platform クラスターは、` must-gathers` Kubernetes-NMstate リソースに含まれるようになりました。これにより、
must-gathersに Kubernetes-NMstate のリソースを含めることで、問題の処理が改善されています。(BZ#2062355) -
現在、ロードバランサーサービスがクラスタートラフィックポリシーで設定されている場合、ホストルートが無視されるという既知の問題があります。その結果、ロードバランサーサービスの egress トラフィックは、ホストルーティングテーブルに存在する最適なルートではなく、デフォルトゲートウェイに誘導されます。回避策として、ロードバランサータイプ Service を
Localトラフィックポリシーに設定します。(BZ#2060159) -
以前は、
PodDisruptionBudgetの仕様は単一ノードの OpenShift クラスターには適合せず、これにより、すべての Pod をエビクトできるわけではないことから、アップグレード機能が制限されていました。今回の更新により、PodDisruptionBudgetの仕様がクラスタートポロジーに基づいて調整され、Kubernetes-NMState Operator が単一ノードの OpenShift クラスターでアップグレードできるようになりました。(BZ#2075491) -
以前は、起動時に
br-exブリッジをセットアップするときに、DHCP クライアント ID と IPv6 アドレス生成モードの設定が正しく機能せず、br-exで予期しない IP アドレスが発生していました。今回の更新により、DHCP クライアント ID と IPv6 生成モードの設定がbr-exで適切に設定されるようになりました。(BZ#2058030) -
以前は、CNI 定義の
gatewayフィールドに依存してデフォルトルートを削除し、独自のルートを挿入していたため、egress-router-cniPod に一部のクラスター内部ルートがありませんでした。今回の更新では、egress-router-cniPod が正しいルーティング情報を注入することで、Pod が外部および内部クラスターの宛先に到達できるようにしています。(BZ#2075475) -
以前は、単一ノードの OpenShift で OVN raft クォーラムを作成するために、Pod の Disruption Budget (PDB: 停止状態の予算) が使用されていました。これにより、単一ノードの OpenShift クラスターで役に立たない
PodDisruptionBudgetAtLimitアラートが発生しました。今回の更新により、これらのクラスターでPodDisruptionBudgetAtLimitアラートが発生しなくなりました。(BZ#2037721) -
以前は、OVN-Kubernetes を使用している場合、
NetworkManagerの再起動での競合状態により、DHCP 解決がノードの起動時にbr-exブリッジの設定を正常に完了できないことがありました。今回の更新により、br-exのセットアップ時にNetworkManagerが再起動されなくなり、競合状態がなくなりました。(BZ#2055433) -
これまでは、
PtpConfigSlaveソースカスタムリソース (CR) がサポート対象外のネットワークトランスポート UDPv4 に設定されていたため、分散ユニット (DU ) ノードでエラーが発生していました。今回の修正では、PtpConfigSlaveソース CR が UDPv4 ではなくネットワークトランスポート L2 を使用するように更新されました。その結果、DU ノードでエラーは検出されなくなりました。(BZ#2060492) - これまでは、ネットワークポリシーの更新時に、すべての OpenShift Container Platform ポリシーロギング設定が更新されていました。そのため、同時またはそれ以降のネットワークポリシーで顕著なレイテンシーが発生しました。今回の更新により、新しいポリシーの追加時にすべてのネットワークポリシーが更新されなくなり、レイテンシーが解消されました。(BZ#2089392)
ネットワークパフォーマンスの向上
-
以前は、
systemdサービスは、仮想デバイスを除く udev から見えるすべてのネットワークデバイスに対して、パフォーマンスプロファイルの予約済み CPU リストに従って、デフォルトの Recieve Packet Steering (RPS) マスクを設定していました。crioフックスクリプトは、保証された Pod の/sys/devicesから見えるすべてのネットワークデバイスの RPS マスクを設定します。これにより、ネットワーク パフォーマンスに複数の影響が生じました。今回の更新では、systemdサービスは、/sys/devices/virtualの下にある仮想インターフェイスのデフォルトの RPS マスクのみを設定します。crioフックスクリプトは、物理デバイスも除外するようになりました。この設定により、プロセスの過負荷、長いポーリング間隔、レイテンシーの急増などの問題が軽減されます。(BZ#2081852)
ノード
- 以前は、Pod マネージャーが Pod シークレットと config map の登録と登録解除を処理していました。このため、Pod シークレットを Pod 内にマウントできない場合がありました。今回の修正により、Pod ID は、kubelet が登録済み Pod の管理に使用するキーに含まれるようになりました。その結果、シークレットは期待どおりに適切にマウントされるようになります。(BZ#1999325)
- ガベージコレクションプロセスでのメモリーリークが原因で、メモリー不足のために Pod がノードで起動できない場合があります。この修正により、ガベージコレクションプロセスでメモリーリークが発生しなくなり、ノードが期待どおりに起動するようになります。(BZ#2065749)
- アップストリーム Kubernetes の変更により、kubelet は終了した Pod で readiness プローブを実行していませんでした。その結果、ロードバランサーまたはコントローラーが Pod の終了に反応するのが遅くなり、エラーが発生する可能性がありました。今回の修正により、Pod の終了時に readiness プローブが再び実行されるようになりました。(BZ#2089933)
-
バグが原因で、API で他の Pod が完了したと報告された後に Pod が急速にスケジュールされた場合、kubelet は
OutOfCpuエラーが発生した Pod を誤って拒否する可能性がありました。この修正により、kubelet は、実行中のすべてのコンテナーが停止し、新しいコンテナーが開始されなくなるまで待機してから、API で Pod のフェーズをターミナルと報告するようになりました。この変更後、存続期間の短い Pod が、成功または失敗のいずれかを報告する際に、やや時間がかかる場合があります (約 1 秒)。(BZ#2022507) -
最近のバージョンの
prometheus-adapterは追加の Pod メトリックを送信しているため、Vertical Pod Autoscaler (VPA) レコメンダーは、不要かつ反復的なメッセージを大量に生成しています。この修正により、VPA は余分なメトリックを認識して無視します。その結果、これらのメッセージは生成されなくなりました。(BZ#2102947)
OpenShift CLI (oc)
-
以前は、非推奨の古いイメージバージョンがソースとして使用された場合、
ocカタログのミラーリングが失敗していました。現在は、イメージマニフェストのバージョンが自動的に検出され、ミラーリングが正常に機能します。(BZ#2049133) -
以前は、フォールバック検証がいつ発生したかをログから把握することは困難でした。これを明確にするために、ログが改善されました。その結果、
must-gather runの出力が、より明確になっています。(BZ#2035717) -
以前は、無効な引数を指定して
must-gatherを実行した場合、一貫してエラーが報告されず、代わりに不可能な場合でもデータを収集しようとすることがありました。現在は、must-gatherが無効なオプションで呼び出された場合、有用なエラー出力が提供されるようになりました。(BZ#1999891) -
以前は、
oc adm catalog mirrorコマンドでエラーが発生した場合、そのまま続行され、0終了コードが返されていました。--continue-on-errorフラグが利用可能になり、エラーが発生した場合にコマンドを続行するか、ゼロ以外の終了コードで終了するかをユーザーが決定できるようになりました。(BZ#2088483) -
今回の更新で、
--subresourceフラグがoc adm policy who-canコマンドに追加され、サブリソースで指定されたアクションを誰が実行できるかを確認できるようになりました。(BZ#1905850) -
以前は、ユーザーは
oc projectコマンドでタブ補完を使用できませんでした。現在は、oc projectの後にタブを押すと、プロジェクトが適切にリスト表示されます。(BZ#2080416) -
以前は、スタートアッププローブがデバッグ Pod から削除されなかったため、スタートアッププローブが失敗した場合にデバッグ Pod で問題が発生する可能性がありました。
--keep-startupフラグが追加されました。これはデフォルトではfalseで、スタートアッププローブがデバッグ Pod からデフォルトで削除されることを意味します。(BZ#2056122) -
以前は、
oc debug nodeの呼び出し後にタイムアウトが指定されていなかったため、ユーザーがクラスターからログアウトされることはありませんでした。TMOUT環境変数が追加され、非アクティブ状態が指定された時間経過すると、セッションが自動的に終了するようになりました。(BZ#2043314) -
この更新により、ユーザーがログアウトしている場合でも、
oc loginは Web コンソールの URL を表示するようになりました。(BZ#1957668) -
以前は、コンテナーが見つからない場合に
oc rsyncコマンドが間違ったエラー出力を表示していました。このリリースでは、特定のコンテナーが実行されていない場合に、oc rsyncコマンドが正しいエラーメッセージを表示するようになりました。(BZ#2057633) - 以前は、大きなイメージは、クラスターにとって新しい場合、プルーニングすることができませんでした。これにより、サイズが大きすぎるイメージをフィルタリングする際に、最近のイメージが省略されてしまうことがありました。このリリースでは、指定されたサイズを超えるイメージをプルーニングできるようになりました。(BZ#2083999)
-
以前は、
gatherスクリプトにタイプミスがありました。その結果、Insights データが適切に収集されませんでした。このリリースでは、タイプミスが修正され、Insights データがmust-gatherによって適切に収集されるようになりました。(BZ#2106543) -
以前は、
ocCLI を使用してEgressNetworkPolicyリソースタイプをクラスターに適用できませんでした。このリリースでは、EgressNetworkPolicyリソースを作成、更新、および削除できるようになりました。(BZ#2071614)
Kubernetes コントローラーマネージャー
-
以前は、Pod ファイナライザーを使用してジョブを追跡するためのベータ機能がデフォルトで有効になっていました。場合によっては、Pod のファイナライザーが削除されていないために、Pod が常に削除されるわけではありませんでした。今回の更新により、機能ゲート
JobTrackingWithFinalizersがデフォルトで無効になりました。その結果、削除中に Pod が取り残されることがなくなりました。(BZ#2075621) -
以前は、CR レプリカ数がゼロになるたびに
PodDisruptionBudgetAtLimitアラートが発生していました。今回の更新により、中断するアプリケーションがない場合、またはレプリカ数がゼロの場合に、アラートは発生しなくなりました。(BZ#2053622)
Operator Lifecycle Manager (OLM)
- この更新の前は、リソース名が 63 文字を超えると、無効なサブスクリプションラベルが作成されていました。63 文字の制限を超えるラベルを切り捨てることで問題が解決し、サブスクリプションリソースが Kubernetes API を拒否しなくなりました。(BZ#2016425)
-
この更新の前は、Marketplace Operator のカタログソース Pod がノードのドレインを妨げていました。その結果、Cluster Autoscaler は効果的にスケールダウンできませんでした。今回の更新では、
cluster-autoscaler.kubernetes.io/safe-to-evictアノテーションをカタログソース Pod に追加すると問題が修正され、Cluster Autoscaler が効果的にスケールダウンできるようになりました。(BZ#2053343) -
この更新の前は、Pod をスケジュールできなかった場合など、特定の状況で
collect-profilesジョブが完了するまでに長い時間がかかることがありました。その結果、十分な数のジョブがスケジュールされていても実行できない場合、スケジュールされたジョブの数が Pod クォータ制限を超えていました。今回の更新により、一度に 1 つのcollect-profilesPod のみが存在するようになり、collect-profilesジョブが Pod のクォータ制限を超えなくなりました。(BZ#2055861) -
この更新の前は、パッケージサーバーは、リーダーの選出期間、更新期限、および再試行期間を定義するときに Pod トポロジーを認識していませんでした。その結果、パッケージサーバーは、単一ノード環境など、リソースが限られているトポロジーに負担をかけていました。今回の更新では、妥当なリース期間、更新期限、再試行期間を設定する
LeaderElectionパッケージが導入されました。この修正により、リソースが限られているクラスターの負担が軽減されます。(BZ#2048563) -
以前は、
openshift-marketplacenamespace に不適切なカタログソースがありました。このため、すべてのサブスクリプションがブロックされました。今回の更新により、openshift-marketplacenamespace に不適切なカタログソースがある場合、ユーザーは、元のアノテーションを使用して独自の namespace の品質の高いカタログソースから Operator にサブスクライブできるようになります。その結果、ローカルの namespace に不適切なカタログソースがある場合、ユーザーは namespace のどの Operator にもサブスクライブすることはできません。(BZ#2076323) -
以前は、
operator-marketplaceプロジェクトのポーリング中に情報レベルのログが生成され、これによりログスパムが発生していました。この更新では、コマンドラインフラグを使用してログラインをデバッグレベルに下げ、ユーザーがログレベルをより詳細に制御できるようにします。その結果、ログスパムが減少します。(BZ#2057558) -
以前は、Cluster Version Operator (CVO) によって管理される各コンポーネントは、プロジェクトのリポジトリーの root にある
/manifestディレクトリーで定義された YAML ファイルで設定されていました。/manifestディレクトリーから YAML ファイルを削除する場合、release.openshift.io/delete: “true"アノテーションを追加する必要がありました。そうしないと、CVO はクラスターからリソースを削除しませんでした。今回の更新では、/manifestディレクトリーから削除されたすべてのリソースを再導入し、release.openshift.io/delete: “true"アノテーションを追加して、CVO がリソースをクリーンアップできるようにしています。その結果、OLM コンポーネントに不要になったリソースはクラスターから削除されます。(BZ#1975543) -
以前は、gRPC カタログソースで使用される
CheckRegistryServer関数は、カタログソースに関連付けられたサービスアカウントの存在を確認しませんでした。これにより、サービス アカウントのない異常なカタログ ソースが存在していました。この更新により、gRPCCheckRegistryServer関数は、サービスアカウントが存在するかどうかを確認し、見つからない場合はサービスを再作成します。その結果、OLM は gRPC カタログソースが所有するサービスアカウントを再作成します (存在しない場合)。(BZ#2074612) -
以前は、ユーザーがファイルベースのカタログイメージに対して
opm index pruneを実行したときに発生したエラーメッセージで、不正確な表現により、このコマンドがそのカタログ形式をサポートしていないことが不明確となっていました。今回の更新により、エラーメッセージが明確になり、コマンドopm index pruneは SQLite ベースのイメージのみをサポートすることをユーザーが理解できるようになりました。(BZ#2039135) - 以前は、Operator API の周りに壊れたスレッドセーフがありました。そのため、Operator リソースが適切に削除されませんでした。今回の更新により、Operator リソースが適切に削除されるようになりました。(BZ#2015023)
- 以前は、Pod の障害によって証明書の有効期間が人為的に延長され、証明書が正しくローテーションされませんでした。今回の更新により、証明書の有効期間が正しく決定され、証明書が正しくローテーションされるようになりました。(BZ#2020484)
-
OpenShift Container Platform 4.11 では、デフォルトのクラスター全体の Pod セキュリティーアドミッションポリシーは、すべての namespace の
baselineに設定され、デフォルトの警告レベルはrestrictedに設定されています。この更新の前は、Operator Lifecycle Manager は、operator -marketplacenamespace に Pod セキュリティーアドミッション警告を表示していました。この修正では、警告レベルをbaselineに下げることで問題を解決しています。(BZ#2088541)
Operator SDK
- この更新の前は、Operator SDK は、サポートされているダウンストリームイメージではなくアップストリームイメージを使用して、Hybrid Helm ベースの Operator をスキャフォールディングしていました。今回の更新により、Operator SDK は、サポートされているダウンストリームイメージを使用して、Hybrid Helm ベースの Operator をスキャフォールディングします。(BZ#2039135)
-
OpenShift Container Platform 4.11 では、Operator SDK により
arm64Operator イメージをビルドすることができます。その結果、Operator SDK は、arm64をターゲットとする Operator イメージのビルドをサポートするようになりました。(BZ#2035899) - 以前は、Operator SDK でスキャフォールディングされた Hybrid Helm Operators を実行している {product-tile} は、サポート対象のダウンストリームイメージではなく、アップストリームイメージを使用していました。今回の更新により、Hybrid Helm Operator のスキャフォールディングはダウンストリームイメージを使用するようになりました。(BZ#2066615)
OpenShift API サーバー
- 複数の Authentication Operator コントローラーが同時に同期していたため、Authentication Operator は設定の変更に対応するのに時間がかかりすぎていました。この機能は、Authentication Operator コントローラーがリソースを競合しないように、通常の同期期間にジッターを追加します。その結果、Authentication Operator が設定の変更に対応するのにかかる時間が短縮されました。(BZ#1958198)
- OpenShift Container Platform 4.11 では、外部 ID プロバイダーからの認証試行が監査ログに記録されるようになりました。その結果、外部 ID プロバイダーからのログイン試行の成功、失敗、およびエラーを監査ログで確認することができます。(BZ#2086465)
Red Hat Enterprise Linux CoreOS (RHCOS)
-
今回の更新以前は、マシンが PXE 経由で起動し、
BOOTIF引数がカーネルコマンドラインで指定されている場合に、マシンは 1 つのインターフェイスだけで DHCP を有効にして起動します。今回の更新により、BOOTIF引数が指定されていても、マシンはすべてのインターフェイスで DHCP を有効にして起動するようになりました。(BZ#2032717) - 以前のバージョンでは、VMware OVA イメージからプロビジョニングされたノードは、初回のプロビジョニング後に Ignition config を削除しませんでした。そのため、シークレットが Ignition 設定に保存される際にセキュリティーの問題が作成されました。今回の更新により、新規ノードでの初回プロビジョニング後に、Ignition 設定が VMware ハイパーバイザーから削除され、また既存ノードで以前の OpenShift Container Platform リリースからアップグレードできるようになりました。(BZ#2082274)
-
以前は、
toolboxコマンドに指定された引数は、コマンドが最初に呼び出されたときに無視されていました。この修正により、ツールボックススクリプトが更新され、podman container createコマンドの開始後に、podman startコマンドおよびpodman execコマンドが続くようになりました。また、複数の引数と空白を配列として処理するようにスクリプトを変更しています。その結果、toolboxコマンドに渡された引数は、期待どおりに毎回実行されます。(BZ#2039589)
Performance Addon Operator
-
以前は、CNF cyclictest ランナーは
--mainaffinity引数を提供している必要があり、実行するスレッドをバイナリーに指示していましたが、cyclictest ランナーには--mainaffinity引数がありませんでした。今回の更新により、--mainaffinity引数が cyclictest ランナーに追加され、cyclitestコマンドに適切に渡されるようになりました。(BZ#2051540) -
以前は、
oslatコンテナーの仕様にcpu-quota.crio.io: "disable"アノテーションがなかったため、レイテンシーが大きくなっていました。その結果、作成時にcpu-quay.crio.io:"disable"アノテーションが Pod 定義にありませんでした。今回の更新により、Pod の作成時にcpu-quota.crio.io:"disable"アノテーションが追加され、その結果、oslatPod のspecificationフィールドに表示されるようになります。(BZ#2061676)
Routing
- 以前は、Ingress Operator は、OpenShift Ingress namespace の Kubernetes サービスオブジェクトが、調整しようとしている Ingress Controller によって作成または所有されているかどうかを検証しませんでした。したがって、Ingress Operator は、所有権に関係なく、名前も namespace も同じ Kubernetes サービスを変更または削除し、予期しない動作を引き起こしていました。今回の更新により、サービスの変更または削除を試みる前に、Ingress Operator が既存の Kubernetes サービスの所有権を確認できるようになりました。所有権が一致しない場合、Ingress Operator はエラーを表示し、アクションを起こしません。その結果、Ingress Operator は、変更または削除する OpenShift Ingress namespace と同じ名前のカスタム Kubernetes サービスを変更または削除することができません。(BZ#2054200)
- 以前、OpenShift Container Platform 4.8 は、プラットフォームルートをカスタマイズするための API を追加しました。この API には、カスタマイズ可能なルートの現在のホスト名と、これらのルートに対するユーザーの目的のホスト名をそれぞれ報告するために、クラスターの ingress 設定に status フィールドと spec フィールドが含まれています。API は、これらの値に対する制約も定義しました。これらの制約は限定的であり、いくつかの有効な潜在的なホスト名を除外していました。その結果、API の制限的な検証により、ユーザーは、許可されるべきカスタムホスト名を指定できなくなり、また、許可されるべきドメインでクラスターをインストールできなくなりました。今回の更新により、ホスト名の制約が緩和され、ルートに有効なすべてのホスト名が許可され、OpenShift Container Platform ではユーザーが 10 進数を含む TLD でクラスタードメインを使用できるようになりました。(BZ#2039256)
-
以前は、Ingress Operator はクラスターの
spec.domainパラメーターで設定された Ingress Controller がspec.baseDomainパラメーターと一致するかどうかをチェックしませんでした。これにより、Operator は DNS レコードを作成し、DNSManaged条件をfalseに設定していました。この修正により、Ingress Operator はspec.domainパラメーターがクラスターのspec.baseDomainと一致するかどうかをチェックするようになりました。その結果、カスタム Ingress Controller の場合、Ingress Operator は DNS レコードを作成せず、DNSManaged条件を false に設定します。(BZ#2041616) -
OpenShift Container Platform 4.10 では以前、HAProxy の must-gather 関数の実行に最大 1 時間かかることがありました。これは、終了状態のルーターが
oc cpコマンドを遅らせた場合に発生する可能性があります。遅延は、Pod が終了するまで続きます。新しいリリースでは、oc opコマンドに 10 分の制限を設けることで、長時間の遅延を防止しています。(BZ#2104701) - 以前は、Ingress Controller が削除されたときに、Ingress Operator はルートステータスをクリアせず、削除後もルートが Operator に残っていることを示していました。この修正により、Ingress Controller を削除したときにルートのステータスがクリアされ、削除後に Operator でルートがクリアされるようになります。(BZ#1944851)
-
以前は、
oc explain router.status.ingress.conditionsコマンドの説明ルートステータスの出力では、アプリケーションプログラミングインターフェイス (API) の不適切な表現が原因で、Admittedではなく、Currently only Readyが表示されていました。この修正により、API の表現が修正されています。その結果、コマンド出力は正しくなります。(BZ#2041133) -
以前は、Ingress Operator は、
LoadBalancer-typeのサービスで Operator が管理するアノテーションをユーザーが変更したことを検出していました。その結果、Operator は Ingress Cluster Operator のUpgradeableステータス条件をFalse設定してアップグレードをブロックし、IngressOperator はサービスにアノテーションがない場合、誤ってUpgradeableステータス条件をFalseに設定し、アップグレードをブロックしてしまいました。現在、サービスのアノテーションをチェックするロジックは空のアノテーションを正しく処理し、Ingress Operator はアップグレードを誤ってブロックしなくなりました。(BZ#2097555) -
以前は、Ingress Operator は、Operator が以前のバージョンの OpenShift Container Platform から
LoadBalancer-typeサービスに追加したファイナライザーを削除していました。今回の更新により、Ingress Operator はファイナライザーを削除しなくなりました。(BZ#2069457) -
Ingress Operator は、ingress カナリアルートに対してヘルスチェックを実行します。この更新の前は、接続時に
keepaliveデーモンが有効になっているため、ヘルスチェックの完了後に Ingress Operator がロード バランサー (LB) への TCP 接続を閉じませんでした。既存の接続を使用する代わりに、次のヘルスチェック用に新しい接続が作成されました。その結果、ロードバランサー上に接続が構築され、ロードバランサー上に多数の接続が作成されました。この更新により、カナリアルートへの接続時にkeepaliveデーモンが無効になり、カナリアプローブが実行されるたびに、新しい接続が確立され、閉じられるようになりました。(BZ#2037447) -
以前は、Ingress Controller がルーターのデプロイメントで
allowPrivilegeEscalation値を false に設定しなかったため、ルーター Pod が誤った Security Context Constraint (SCC) に選択され、カスタム SCC との競合が発生していました。この修正により、allowPrivilegeEscalation値がtrueに設定され、ルーター Pod が正しい SCC に選択され、カスタム SCC との競合が回避されるようになります。(BZ#2007246) -
以前は、カナリアルートが Ingress Controller に認められない場合、Ingress Operator のステータス状態が
degradedと表示されませんでした。その結果、カナリアルートは、ステータス条件がnot admittedと表示されるはずであっても、validと表示される可能性がありました。今回の更新により、Ingress Operator のステータスは、カナリアコントローラーのステータスをより正確に反映するようになりました。(BZ#2021446) -
以前は、
openshift-routerプロセスが一時的にSIGTERMシャットダウンシグナルを無視していました。これが原因で、コンテナーが Kubernetes のシャットダウンリクエストを無視し、シャットダウンに 1 時間かかっていました。この更新により、ルーターはSIGTERMシグナルに応答するようになりました。(BZ#2076297) -
以前は、許可されたルートの Ingress Controller が削除されるか、シャーディング設定が追加されると、誤った
admittedステータスが与えられました。今回の更新により、Ingress Controller は、unadmittedルートのステータスをクリアし、誤ったステータスシナリオを回避できるようになりました。(BZ#1944851) -
以前は、バージョン 4.7 以前を使用してインストールされた OpenShift Container Platform クラスターは、
0.0.0.0/0のservice.beta.kubernetes.io/aws-load-balancer-internalアノテーションの値を維持していました。4.8 以降を使用してインストールされたクラスターには、アノテーションの値がtrueになります。アノテーションの値trueを確認する AWS クラウドプロバイダー実装は、値が0.0.0.0/0の場合、誤った結果を返します。そのため、4.10 へのクラスターのアップグレードが完了しませんでした。今回の更新により、アノテーションの値がtrueに正規化され、クラスターのアップグレードが完了するようになりました。(BZ#2055470)
スケーラビリティーおよびパフォーマンス
- この更新の前は、Node Feature Discovery (NFD) がすでにインストールされていたかどうかに関係なく、SRO はデフォルトで NFD をインストールしていました。NFD がインストールされていた場合、これが原因で SRO のデプロイメントが失敗していました。SRO はデフォルトで NFD をデプロイしなくなりました。
ストレージ
- 以前は、OpenShift Container Platform に同梱されている Alibaba Container Storage Interface (CS) ドライバーは、ユーザーが 20 GiB 未満の永続ボリューム要求 (PVC) を作成すると、エラーを返しました。これは、Alibaba Cloud が 20 GiB を超えるボリュームしかサポートしないことが原因でした。この更新により、Alibaba CSI ドライバーは、すべてのボリュームサイズを自動的に 20 GiB 以上に増加し、より小さな PVC が動的にプロビジョニングされるようになりました。これにより、コストが増加する可能性があります。管理者は、コストを制限するために、制限された環境で namespace ごとに PVC カウントのクォータを使用することができます。(BZ#2057495)
-
以前のバージョンでは、Local Storage Operator (LSO) は、ノードの削除が PV の削除要求も発行するように、作成した永続ボリューム (PV) に所有者参照を追加していました。これにより、PV が Pod にアタッチされたまま
Terminating状態となる可能性がありました。LSO はその OwnerReference を作成しなくなりました。つまり、クラスター管理者は、ノードをクラスターから削除した後、未使用の PV を削除する必要があります。(BZ#2061447) 詳細は、Persistent storage using local volumes を参照してください。 - この修正により、read-only-many ボリュームが、GCP CSI ドライバーによって read-only として適切にプロビジョニングされるようになります。(BZ#1968253)
- OpenShift Container Platform では、アップストリームコミュニティーまたは VMware によって出荷された vSphere CSI ドライバーをインストールできます。Red Hat はこのドライバーをサポートしていませんが、Red Hat が出荷する vSphere CSI ドライバーよりも多くの機能を備えているため、クラスター管理者はインストールして使用することができます。OpenShift Container Platform は、アップストリームおよび VMware vSphere CSI ドライバーを使用して 4.11 にアップグレードできますが、サードパーティーの CSI ドライバーが存在するという警告が表示されます。詳細については、(BZ#2089419) および (BZ#2052071) を参照してください。
- 今回の更新により、Amazon Web Services (AWS) のデフォルトの認証情報要求が変更され、Key Managment Service (KMS) からの顧客管理キーを使用する暗号化されたボリュームのマウントが可能になりました。Cloud Creditial Operator (CCO) を使用して手動モードで認証情報要求を作成した管理者は、AWS でお客様が管理する鍵を使用して暗号化されたボリュームをマウントする場合、これらの変更を手動で適用する必要があります。他の管理者は、この変更によって影響を受けることはありません。(BZ#2049872)
- 以前は、IBM Cloud にデプロイされた OpenShift Container Platform クラスターを削除した後に、バックエンドのストレージボリュームが削除されませんでした。そのため、クラスターリソースを完全に削除できませんでした。今回の修正により、インストールプログラムおよび Container Storage Interface (CSI) ドライバーのサポートが追加され、クラスターの削除後にバックエンドボリュームが削除されるようになりました。(BZ#2047732)
Web コンソール (開発者パースペクティブ)
- この更新の前は、無効な devfile リポジトリー (devfile v2.2 より古い) が入力されると、Git Import フォームにエラーメッセージが表示されていました。この更新により、v2.2 より古い devfile はサポートされないというエラーメッセージが表示されるようになりました。(BZ#2046435)
- この更新の前は、ConsoleLink CR (openshift-blog) がクラスターで利用できない場合、ブログリンクは定義されていませんでした。ブログへのリンクをクリックしても、OpenShift ブログにリダイレクトされませんでした。今回の更新により、ConsoleLink CR (openshift-blog) がクラスターに存在しない場合でも、https://developers.redhat.com/products/openshift/whats-new へのフォールバックリンクが追加されます。(BZ#2050637)
- この更新の前に、kafka CR の API バージョンが更新されました。このバージョンは旧バージョンをサポートしていなかったため、ブートストラップサーバー を作成していても、空のブートストラップサーバーが Create Event Source - KafkaSource に表示されていました。今回の更新により、Kafka CR の更新された API は古いバージョンをサポートし、Create Event Source - KafkaSource フォームで ブートストラップサーバー リストをレンダリングします。(BZ#2058623)
- この更新の前に、Import from Git フォームを使用してプライベート Git リポジトリーをインポートすると、プライベートリポジトリーの詳細を取得するためのシークレットがデコードされなかったため、正しいインポートタイプとビルダーイメージが識別されませんでした。今回の更新により、Import from Git フォームはシークレットをデコードして、プライベートリポジトリーの詳細をフェッチします。(BZ#2053501)
- この更新の前は、開発者の観点から、Observe ダッシュボードは、Topology ビューで選択したワークロードではなく、直近に表示したワークロードに対して開いていました。この問題は、セッションが URL のクエリーパラメーターではなく、redux ストアを優先するために発生します。この更新により、Observe ダッシュボードは、URL のクエリーパラメーターに基づいてコンポーネントをレンダリングします。(BZ#2052953)
-
この更新の前は、パイプライン は、クラスターに存在しない場合でも、デフォルトのストレージクラスとしてハードコードされた値
gp2で開始していました。今回の更新により、ハードコードされた値の代わりに、デフォルトで指定されたストレージクラス名を使用できるようになりました。(BZ#2084635) -
この更新の前は、大量のパイプラインログを実行しているときに、自動スクロール機能が動作せず、ログに古いメッセージが表示されていました。大量のパイプライン ログを実行すると、
scrollIntoViewメソッドへの呼び出しが大量に生成されました。この更新により、大量のパイプラインログでscrollIntoViewメソッドへの呼び出しが生成されなくなり、スムーズな自動スクロール機能が提供されるようになりました。(BZ#2014161) - この更新の前は、Create RoleBinding フォームを使用して RoleBinding を作成する場合、サブジェクト名は必須でした。サブジェクト名がない場合は、Project Access タブの読み込みに失敗していました。この更新により、Subject Name プロパティーのない RoleBinding は、Project Access タブに記載されなくなりました。(BZ#2051558)
-
この更新の前は、イベントソースのシンクとトリガーは、それらがスタンドアロンであっても、
k-native service、Broker、またはKameletBindingをバックアップする一部であっても、すべてのリソースを表示していました。アドレス指定されたリソースが、シンクドロップダウンリストに表示するために使用されました。今回の更新で、スタンドアロンリソースのみをシンクとして表示するフィルターが追加されました。(BZ#2054285) - この更新の前は、トポロジービューのサイドバーにある空のタブは、レンダリング前にフィルタリングされていませんでした。これにより、トポロジービューに ワークロード の無効なタブが表示されていました。この更新により、レンダリング前に空のタブが適切にフィルタリングされるようになりました。(BZ#2049483)
-
この更新の前に、Start Last Run ボタンを使用してパイプラインを開始すると、作成された
PipelineRunのstarted-byアノテーションが正しいユーザー名に更新されなかったため、triggered by のセクションに正しいユーザー名が表示されませんでした。この更新により、started-byアノテーションの値が正しいユーザー名に更新され、triggered by セクションに、パイプラインを開始した正しいユーザーのユーザー名が表示されるようになりました。(BZ#2046618) -
この更新の前は、
ProjectHelmChartRepositoryCR がクラスターに表示されませんでした。そのため、この CR の API スキーマは、クラスター内でまだ初期化されませんでした。この更新により、ProjectHelmChartRepositoryがクラスターに表示されるようになりました。(BZ#2054197) - この更新の前は、トポロジーでキーボードを使用してナビゲートすると、選択した項目が強調表示されませんでした。この更新により、キーボードを使用したナビゲーションで、選択されたアイテムがハイライトされ、スタイルが更新されるようになりました。(BZ#2039277)
- この更新の前は、Web ターミナルのレイアウトがデフォルトビューの外で開き、サイズを変更できませんでした。この更新により、Web ターミナルはデフォルトビュー内で開き、適切にサイズ変更されるようになりました。(BZ#2022253)
- この更新の前は、サイドバー項目の一部に namespace コンテキストが含まれていませんでした。その結果、別のブラウザーからリンクを開いた場合、または別のアクティブな namespace からリンクを開いた場合、Web コンソールは正しい namespace に切り替わりませんでした。この更新により、URL を開くときに正しい namespace が選択されるようになりました。(BZ#2039647)
- 以前は、コンソールを使用してテンプレートをインスタンス化する際に、そのパラメーターはシークレットリソースとして保存されていました。テンプレートが削除されてもシークレットは残りました。そのため、クラスター内に不要なシークレットがビルドされました。今回の更新により、テンプレートインスタンスにマップするシークレットに所有者の参照が追加されました。テンプレートインスタンスが削除されると、シークレットも削除されるようになりました。(BZ#2015042)
-
今回の更新により、
jsonDataプロパティーは非推奨となり、pingソースのdataに置き換えられました。(BZ#2084438) -
以前は、OpenShift Container Platform Web コンソールのトポロジービューは 100 を超えるノードを持つクラスターで失敗または遅延していました。今回の更新により、トポロジービューで、100 を超えるノードを持つクラスターの
LimitExceeded状態が表示されるようになりました。代わりに Search ページを使用してリソースを表示するオプションが提供されます。または、Show topology anyway をクリックして、トポロジービューのロードを継続できます。(BZ#2060329) -
以前は、サービスが複数のサービスポートを公開し、ルートのターゲットポートが
8080の場合、ターゲットポートの変更を試みると、ポート8080サービスポートの代わりに別のサービスポートが更新されていました。今回の更新により、新しいターゲットポートが設定されている場合に、アクティブなターゲットポートに対応するサービスポートが置き換えられるようになりました。(BZ#2077943) -
以前は、セルフホスト GitHub および Bitbucket からリポジトリー情報を取得するためにインスタンス API の管理に使用される
git検出は機能しませんでした。今回の更新により、セルフホスト GitHub および Bitbucket インスタンスリポジトリーの検出が機能するようになりました。(BZ#2038244) -
以前は、
apiVersionは EventSource 作成フォームの Resource ドロップダウンメニューに正しい形式で渡されませんでした。そのため、EventSource の作成でInContextが選択されず、Resource ドロップダウンメニューから除外されていました。今回の更新により、Resource ドロップダウンメニューにInContextからのResourceが含まれるようになりました。(BZ#2070020) -
以前は、Pipeline metrics ページにはメトリッククエリーのすべての API 呼び出しが表示され、
404エラーで失敗していました。今回の更新により、prometheus-tenancyAPI を使用してパイプラインのメトリックデータが取得されます。パイプラインメトリックページには、namespace への少なくとも閲覧権限を持つ非管理者ユーザーに、すべてのデータおよびグラフが表示されるようになりました。(BZ#2041769) - 以前は、Crtl+space キーボードショートカットを使用して、クイック検索にアクセスしてモーダルを追加できましたが、同じキーボードショートカットを使用して閉じることができませんでした。今回の更新で、Ctrl+space キーボードショートカットを使用して、クイック検索を閉じ、モーダルを追加できるようになりました。(BZ#2093586)
-
以前は、ユーザーが削除されても、ユーザー設定用に作成されたリソースは削除されませんでした。そのため、
openshift-console-user-settingsnamespace に作成されたリソースは削除されませんでした。今回の更新により、作成時にownerReferenceがメタデータに追加されるようになりました。これにより、ユーザーが存在しなくなったときにリソースが自動的に削除されます。(BZ#2019564)
