1.6. バグ修正

API サーバーと認証
  • 以前は、workloadIsBeingUpdatedTooLong エラーを受け取ると、Cluster Authentication Operator の状態が progressing = false に設定されていました。同時に、degraded = false は、定義された inertia の期間保持されていました。その結果、Progressing の量が減少して Degradedation の時間が増加し、progressing = false および degraded = false が通常より早く設定される状況が発生していました。これにより、正常な状態が想定されていた OpenShift CI テストの一貫性が失われました。この問題は、workloadIsBeingUpdatedTooLong エラーが返されると progressing = false 設定を削除することで修正されました。これで progressing = false 状態がなくなり、OpenShift CI テストの一貫性が向上します。(BZ#2111842)
ベアメタルハードウェアのプロビジョニング
  • サーバーファームウェアの最近のバージョンでは、サーバー操作の間隔が長くなりました。これにより、OpenShift Container Platform インストールプログラムが Baseboard Management Controller (BMC) からの応答を待機しているときに、インストーラーによってプロビジョニングされたインフラストラクチャーのインストール中にタイムアウトが発生します。新しい python3-sushy リリースでは、サーバー側で BMC への接続を試行する回数が増えています。この更新プログラムは、待ち時間の延長を考慮し、インストール中のタイムアウトを回避します。(OCPBUGS-4097)
  • この更新の前は、Ironic プロビジョニングサービスは、厳密な eTag 検証と組み合わせた弱い eTag を使用するベースボード管理コントローラー (BMC) をサポートしていませんでした。設計上、BMC が弱い eTag を提供する場合、Ironic は 2 つの eTag を返します。元の eTag と、弱い eTag をサポートしない BMC との互換性のために強い形式に変換された元の eTag です。Ironic は 2 つの eTag を送信できますが、厳密な eTag 検証を使用する BMC は、2 番目の eTag が存在するため、そのような要求を拒否します。その結果、一部の古いサーバーハードウェアでは、ベアメタルプロビジョニングが次のエラーで失敗しました: HTTP 412 Precondition Failed。OpenShift Container Platform 4.12 以降では、この動作が変更され、弱い eTag が提供された場合に Ironic が 2 つの eTag を送信しようとしなくなりました。代わりに、eTag に依存する Redfish リクエストが eTag 検証エラーで失敗した場合、Ironic は既知の回避策でリクエストを再試行します。これにより、eTag が厳密に検証されているマシンでベアメタルプロビジョニングが失敗するリスクが最小限に抑えられます。(OCPBUGS-3479)
  • 今回の更新の前は、Redfish システムが設定 URI を備えている場合、Ironic プロビジョニングサービスは常にこの URI を使用して、ブート関連の BIOS 設定を変更しようとしまていました。ただし、ベースボード管理コントローラー (BMC) が設定 URI を備えていても、この設定 URI を使用した特定の BIOS 設定の変更をサポートしていない場合、ベアメタルプロビジョニングは失敗します。OpenShift Container Platform 4.12 以降では、システムが設定 URI を備えている場合、Ironic は続行する前に設定 URI を使用して特定の BIOS 設定を変更できることを確認します。それ以外の場合、Ironic はシステム URI を使用して変更を実装します。この追加のロジックにより、Ironic がブート関連の BIOS 設定の変更を適用でき、ベアメタルプロビジョニングが成功することが保証されます。(OCPBUGS-2052)
ビルド

  • デフォルトでは、Buildah は環境変数の内容を含むステップをログファイルに出力します。これには、ビルド入力シークレット が含まれる場合があります。--quiet ビルド引数を使用してこれらの環境変数の出力を抑制することができますが、source-to-image (S2I) ビルドストラテジーを使用する場合は、この引数は使用できません。現在のリリースではこの問題は修正されています。環境変数の出力を抑制するには、ビルド設定で BUILDAH_QUIET 環境変数を設定します。 

    sourceStrategy:
...
  env:
    - name: "BUILDAH_QUIET"
      value: "true"

    (BZ#2099991)

クラウドコンピュート
  • 以前は、自動再起動の GCP インフラストラクチャーのデフォルトオプションを尊重するようにインスタンスが設定されていませんでした。その結果、自動再起動のインフラストラクチャーのデフォルトを使用せずにインスタンスを作成できました。これは、インスタンスが GCP で終了されても、関連付けられたマシンが自動的に再起動されなかったため、まだ Running の状態でリストされていることを意味していました。このリリースでは、自動再起動オプションを渡すためのコードが改善され、ユーザーからのデフォルトのオプション選択をより適切に検出して渡すことができるようになりました。インスタンスはインフラストラクチャーのデフォルトを適切に使用するようになり、ユーザーがデフォルトの機能を要求すると自動的に再起動されます。(OCPBUGS-4504)
  • PodDisruptionBudget オブジェクトの v1beta1 バージョンは、Kubernetes で非推奨になりました。このリリースでは、v1beta1 への内部参照が v1 に置き換えられました。この変更はクラスターオートスケーラーの内部的なものであり、OpenShift Container Platform 4.12 へのアップグレードの準備 に関する Red Hat ナレッジベース記事のアドバイスを超えるユーザーアクションは必要ありません。(OCPBUGS-1484)
  • 以前は、GCP マシンコントローラーは 10 時間ごとにマシンの状態を調整していました。他のプロバイダーは、この値を 10 分に設定して、マシン API システムの外部で発生した変更が短期間で検出されるようにします。GCP の調整期間が長くなると、追加された外部 IP アドレスが長時間検出されないために証明書署名要求 (CSR) の承認が得られないなど、予期しない問題が発生する可能性があります。このリリースでは、GCP マシンコントローラーが更新され、10 分ごとに調整されて他のプラットフォームとの整合性が保たれ、外部の変更がより早く検出されるようになります。(OCPBUGS-4499)
  • 以前は、Cluster Machine Approver Operator のデプロイメントの設定ミスが原因で、TechPreviewNoUpgrade 機能セットを有効にすると、エラーが発生し、Operator の性能が散発的に低下していました。TechPreviewNoUpgrade 機能セットが有効になっているクラスターは Cluster Machine Approver Operator の 2 つのインスタンスを使用し、両方のデプロイメントで同じポートセットを使用したため、単一ノードトポロジーのエラーにつながる競合が発生しました。このリリースでは、Cluster Machine Approver Operator デプロイメントが更新され、デプロイメントごとに異なるポートのセットを使用するようになりました。(OCPBUGS-2621)
  • 以前は、Azure のゼロからのスケーリング機能は、インスタンスタイプの名前を CPU の数とインスタンスタイプに割り当てられたメモリー量にマッピングする、静的にコンパイルされたインスタンスタイプのリストに依存していました。このリストは、時間の経過とともに古くなっています。このリリースでは、インスタンスタイプのサイズに関する情報が Azure API から直接動的に収集され、リストが古くなるのを防ぎます。(OCPBUGS-2558)
  • 以前はMachine API 終了ハンドラー Pod がスポットインスタンスで開始されませんでした。その結果、テイントされたスポットインスタンスで実行されていた Pod は、インスタンスが終了した場合に終了シグナルを受信しませんでした。これにより、ワークロードアプリケーションのデータが失われる可能性があります。このリリースでは、マシン API 終了ハンドラーのデプロイが変更され、テイントを許容するようになりました。また、テイントを持つスポットインスタンスで実行されている Pod は、終了シグナルを受信するようになりました。(OCPBUGS-1274)
  • 以前は、Azure クラスターのエラーメッセージで、内部発行戦略のみを使用する切断されたインストールのパブリック IP アドレスを使用して新しいマシンを作成できないことが説明されていませんでした。このリリースでは、エラーメッセージが更新され、わかりやすくなりました。(OCPBUGS-519)
  • 以前は、Cloud Controller Manager Operator は AWS クラスターの cloud-config 設定ファイルをチェックしませんでした。その結果、設定ファイルを使用して追加の設定を AWS クラウドコントローラーマネージャーコンポーネントに渡すことができませんでした。このリリースでは、Cloud Controller Manager Operator はインフラストラクチャーリソースをチェックし、cloud-config 設定ファイルへの参照を解析して、ユーザーが追加の設定を設定できるようにします。(BZ#2104373)
  • 以前は、Azure が新しいインスタンスタイプを追加し、以前はサポートされていなかったインスタンスタイプで高速ネットワークのサポートを有効にしたときに、マシンコントローラー内の Azure インスタンスのリストが古くなりました。その結果、マシンコントローラーは、以前は高速ネットワークをサポートしていなかったインスタンスタイプを使用してマシンを作成できませんでした (たとえ Azure でこの機能がサポートされていたとしても)。このリリースでは、マシンが作成される前に必要なインスタンスタイプ情報が Azure API から取得され、最新の状態に保たれるため、マシンコントローラーは新しいインスタンスタイプおよび更新されたインスタンスタイプを使用してマシンを作成できます。この修正は、今後追加されるすべてのインスタンスタイプにも適用されます。(BZ#2108647)
  • 以前は、クラスターオートスケーラーは、Cluster API プロバイダーを使用する場合、CSI ドライバーの AWS、IBM Cloud、および Alibaba Cloud トポロジーラベルを尊重しませんでした。その結果、スケールアウトイベント中にノードのバランスをとろうとしたときに、トポロジーラベルを持つノードがオートスケーラーによって適切に処理されませんでした。このリリースでは、オートスケーラーのカスタムプロセッサーが更新され、このラベルが尊重されるようになりました。オートスケーラーは、AWS、IBM Cloud、または Alibaba CSI ラベルでラベル付けされた同様のノードグループのバランスを取ることができるようになりました。(BZ#2001027)
  • 以前は、Power VS クラウドプロバイダーは DHCP サーバーからマシンの IP アドレスを取得できませんでした。IP アドレスを変更してもノードが更新されなかったため、保留中の証明書署名要求など、いくつかの不整合が発生していました。今回のリリースでは、ノードの IP アドレスがマシンの IP アドレスと一致するように、Power VS クラウドプロバイダーが更新され、DHCP サーバーからマシンの IP アドレスをフェッチするようになりました。(BZ#2111474)
  • 以前は、初期バージョンの OpenShift Container Platform で作成された無効な設定のマシンは削除できませんでした。このリリースでは、無効な設定を持つマシンの作成を防止する Webhook は、既存の無効なマシンの削除を防止しなくなりました。ユーザーは、これらのマシンのファイナライザーを手動で削除することにより、クラスターからこれらのマシンを正常に削除できるようになりました。(BZ#2101736)
  • 以前は、NetworkManager がデーモンとして実行されていない、または連続モードで実行されていないために短い DHCP リース時間が発生したため、初期プロビジョニング中にマシンが停止し、クラスター内のノードにならないことがありました。今回のリリースでは、追加のチェックが追加され、マシンがこの状態で停止した場合にマシンが削除され、自動的に再作成されるようになりました。このネットワーク状態の影響を受けるマシンは、マシン API コントローラーからの再起動後にノードになる可能性があります。(BZ#2115090)
  • 以前は、IBM Cloud に存在しないマシンプロファイルを使用して新しい Machine リソースを作成すると、マシンが Provisioning フェーズで停止していました。このリリースでは、検証が IBM Cloud Machine API プロバイダーに追加され、マシンプロファイルが存在することを確認し、マシンプロファイルが無効なマシンは Machine API によって拒否されます。(BZ#2062579)
  • 以前は、AWS の Machine API プロバイダーは、マシンの仕様で定義されたセキュリティーグループが存在することを確認していませんでした。この場合、エラーを返す代わりに、OpenShift Container Platform マシンに使用すべきではないデフォルトのセキュリティーグループを使用し、デフォルトのグループが使用されたことをユーザーに通知せずにマシンを正常に作成しました。このリリースでは、ユーザーがマシン仕様で誤った、または空のセキュリティーグループ名を設定すると、マシン API がエラーを返します。(BZ#2060068)
  • 以前は、Machine API プロバイダーの Azure は、ユーザーが指定したインスタンスタイプの値を大文字と小文字を区別して処理しませんでした。これにより、インスタンスタイプは正しいが大文字と小文字が一致しない場合に、誤検知エラーが発生しました。このリリースでは、インスタンスタイプが小文字に変換されるため、ユーザーは大文字と小文字の不一致による誤検知エラーなしで正しい結果を得ることができます。(BZ#2085390)
  • 以前は、オブジェクトへのアクセスを試行する前に、マシンオブジェクトの注釈で nil 値のチェックが行われませんでした。このような状況はめったにありませんが、マシンの調整時にマシンコントローラーがパニックに陥る原因となりました。このリリースでは、nil 値がチェックされ、マシンコントローラーは注釈なしでマシンを調整できます。(BZ#2106733)
  • 以前は、クラスターの CPU とメモリーの使用量に関するクラスターオートスケーラーメトリクスが、ClusterAutoscaler リソースによって設定された制限に到達したり、超えたりすることはありませんでした。その結果、リソースの制限によりクラスターオートスケーラーがスケーリングできなかった場合、アラートは発生しませんでした。今回のリリースでは、クラスターオートスケーラーに cluster_autoscaler_skiped_scale_events_count と呼ばれる新しいメトリクスが追加され、リソースの制限に到達または超過したことをより正確に検出できるようになりました。クラスターリソースの制限に達したためにクラスターオートスケーラーがクラスターをスケールアップできない場合に、アラートが発生するようになりました。(BZ#1997396)
  • 以前は、マシン API プロバイダーがマシン IP アドレスの取得に失敗した場合、内部 DNS 名が設定されず、マシン証明書署名要求が自動的に承認されませんでした。このリリースでは、Power VS マシンプロバイダーが更新され、IP アドレスの取得に失敗した場合でも、サーバー名を内部 DNS 名として設定するようになりました。(BZ#2111467)
  • 以前は、マシン API の vSphere マシンコントローラーは、VM のクローン作成時に PowerOn フラグを設定していました。これにより、マシンコントローラーが認識しない PowerOn タスクが作成されました。その PowerOn タスクが失敗した場合、マシンは Provisioned フェーズでスタックし、電源がオンになりませんでした。このリリースでは、この問題を回避するためにクローニングシーケンスが変更されています。さらに、マシンコントローラーは、障害が発生した場合に VM の電源投入を再試行し、障害を適切に報告するようになりました。(BZ#2087981, OCPBUGS-954)
  • このリリースでは、AWS セキュリティーグループは、作成後ではなく、すぐにタグ付けされます。これは、AWS に送信されるリクエストが少なくなり、必要なユーザー権限が低下することを意味します。(BZ#2098054, OCPBUGS-3094)
  • 以前は、RHOSP レガシークラウドプロバイダーのバグにより、認証が失敗した後に特定の RHOSP 操作が試行された場合にクラッシュが発生していました。たとえば、サーバーをシャットダウンすると、Kubernetes コントローラーマネージャーが RHOSP からサーバー情報を取得し、このバグがトリガーされます。その結果、最初のクラウド認証が失敗したか、正しく設定されていない場合、サーバーをシャットダウンすると、Kubernetes コントローラーマネージャーがクラッシュしました。今回のリリースでは、RHOSP レガシークラウドプロバイダーが更新され、以前に正常に認証されていない場合、RHOSP API 呼び出しを試行しないようになりました。現在、無効なクラウド認証情報を使用してサーバーをシャットダウンしても、Kubernetes コントローラーマネージャーがクラッシュすることはなくなりました。(BZ#2102383)
開発者コンソール
  • これまで openshift-config namespace は、ProjectHelmChartRepository カスタムリソースと同じ namespace であった HelmChartRepository カスタムリソースに対してハードコーディングされていました。これにより、ユーザーは目的の namespace にプライベート ProjectHelmChartRepository カスタムリソースを追加できませんでした。その結果、ユーザーは openshift-config namespace のシークレットと configmap にアクセスできませんでした。今回の更新で、ProjectHelmChartRepository カスタムリソース定義が修正され、正しいパーミッションを持つユーザーが選択した namespace からシークレットと configmaps を読み取ることができる namespace フィールドが追加されました。さらに、ユーザーはアクセス可能な namespace にシークレットと configmap を追加でき、作成リソースを使用した namespace にプライベート Helm チャートリポジトリーを追加できます。(BZ#2071792)
Image Registry
  • これまで、イメージトリガーコントローラーにはオブジェクトを変更するパーミッションがありませんでした。その結果、イメージトリガーアノテーションが一部のリソースで機能しませんでした。今回の更新により、アノテーションに従ってオブジェクトを更新するために必要なパーミッションをコントローラーに提供するクラスターロールバインディングが作成されます。(BZ#2055620)
  • これまで、Image Registry Operator には node-ca デーモンセットの progressing 状態がなく、正しくないオブジェクトからの generation が使用されていました。そのため、Operator がまだ実行されているのに node-ca デーモンセットが degraded としてマークされる可能性がありました。今回の更新では、インストールが完了していないことを示す progressing 状態が追加されます。その結果、Image Registry Operator は node-ca デーモンセットを正常にインストールし、インストーラーはそれが完全にデプロイされるまで待機するようになりました。( BZ#2093440)
インストーラー
  • 以前は、サポートされているユーザー定義タグの数は 8 で、AWS リソース用に予約された OpenShift Container Platform タグは 2 でした。このリリースでは、サポートされるユーザー定義タグの数が 25 になり、AWS リソース用に予約された OpenShift Container Platform タグが 25 になりました。インストール時に最大 25 のユーザータグを追加できるようになりました。(CFE#592)
  • 以前は、IAM 管理ユーザーに s3:GetBucketPolicy アクセス許可が割り当てられていない場合、Amazon Web Services へのクラスターのインストールが開始され、失敗していました。今回の更新により、必要なすべての権限が割り当てられていることを確認するためにインストールプログラムが使用するチェックリストに、このポリシーが追加されます。その結果、インストールプログラムは、IAM 管理ユーザーに s3:GetBucketPolicy 権限がないという警告を表示してインストールを停止するようになりました。(BZ#2109388)
  • 以前は、Azure DCasv5 シリーズまたは DCadsv5 シリーズの機密 VM がコントロールプレーンノードとして指定されている場合、Microsoft Azure へのクラスターのインストールに失敗していました。今回の更新により、インストールプログラムは、機密 VM がまだサポートされていないことを示すエラーでインストールを停止するようになりました。(BZ#2055247)
  • 以前は、コントロールプレーンマシンが実行されるまで、ブートストラップログを収集することはできませんでした。今回の更新により、ブートストラップログの収集に必要なのは、ブートストラップマシンが使用可能になっていることだけです。(BZ#2105341)
  • 以前は、サービスアカウントに十分な権限がないためにクラスターを Google Cloud Platform にインストールできなかった場合、結果として表示されるエラーメッセージには、失敗の原因としてこれが記載されていませんでした。この更新により、エラーメッセージが改善され、サービスアカウントに割り当てられているアクセス許可を確認するようユーザーに指示されるようになりました。(BZ#2103236)
  • 以前は、無効な GCP リージョンが指定されたために Google Cloud プロバイダー (GCP) へのインストールが失敗した場合、結果のエラーメッセージで、これが失敗の原因として言及されていませんでした。この更新により、エラーメッセージが改善され、リージョンが無効であることが示されるようになりました。(BZ#2102324)
  • 以前は、Hive が古いバージョンの install-config.yaml ファイルを使用していると、Hive を使用したクラスターインストールが失敗することがありました。今回の更新により、インストールプログラムは、Hive が提供する install-config.yaml ファイルの古いバージョンを受け入れることができます。(BZ#2098299)
  • 以前は、省略形式でアドレスをリストするなど、異なるアドレスを表す場合、インストールプログラムは apiVIP および ingressVIP パラメーターが同じ IPv6 アドレスを使用することを誤って許可していました。今回の更新では、インストーラーはフォーマットに関係なくこれら 2 つのパラメーターを正しく検証し、パラメーターごとに個別の IP アドレスを必要とします。(BZ#2103144)
  • 以前は、インストールプログラムを使用してクラスターをアンインストールすると、クラスター名が 22 文字を超える場合、GCP にインストールされたクラスター内のすべてのリソースを削除できませんでした。今回の更新では、インストールプログラムを使用してクラスターをアンインストールすると、クラスター名が長い場合にすべての GCP クラスターリソースが正しく検索され、削除されます。(BZ#2076646)
  • 以前は、machineNetwork パラメーターで複数のネットワークが定義されている Red Hat OpenStack Platform (RHOSP) にクラスターをインストールする場合、インストールプログラムは最初のネットワークのセキュリティーグループルールのみを作成していました。今回の更新により、インストールプログラムは machineNetwork で 定義されたすべてのネットワークに対してセキュリティーグループルールを作成するため、ユーザーはインストール後にセキュリティーグループルールを手動で編集する必要がなくなりました。(BZ#2095323)
  • 以前は、OpenStack にクラスターをインストールするときに、ユーザーが API および Ingress の仮想 IP アドレスを、DHCP サーバーの割り当てプールと競合する値に手動で設定することができました。これにより、DHCP サーバーが VIP アドレスの 1 つを新しいマシンに割り当て、起動に失敗する可能性があります。今回の更新では、インストールプログラムは、ユーザーが指定した VIP アドレスを検証して、DHCP プールと競合しないことを確認します。(BZ#1944365)
  • 以前は、フォルダー内に埋め込まれたデータセンターを使用して vSphere にクラスターをインストールすると、インストールプログラムがデータセンターオブジェクトを見つけることができず、インストールが失敗していました。今回の更新では、インストールプログラムがデータセンターオブジェクトを含むディレクトリーを走査できるようになり、インストールが成功するようになりました。(BZ#2097691)
  • 以前は、インストーラーによってプロビジョニングされたインフラストラクチャーで arm64 アーキテクチャーを使用して Azure にクラスターをインストールすると、hyperVGeneration V1 のイメージ定義リソースのアーキテクチャー値が誤って x64 になりました。今回の更新により、hyperVGeneration V1 のイメージ定義リソースに Arm64 の正しいアーキテクチャー値が含まれるようになりました。(OCPBUGS-3639)
  • 以前は、VMware vSphere にクラスターをインストールするときに、ユーザーが install-config.yaml ファイルの failureDomain セクションでユーザー定義フォルダーを指定すると、インストールが失敗することがありました。今回の更新により、インストールプログラムは install-config.yaml ファイルの failureDomain セクションにあるユーザー定義フォルダーを正しく検証するようになりました。(OCPBUGS-3343)
  • 以前は、VMware vSphere でインストールが失敗した後に部分的にデプロイされたクラスターを破棄すると、一部の仮想マシンフォルダーが破棄されませんでした。このエラーは、複数の vSphere データセンターまたは複数の vSphere クラスターで設定されたクラスターで発生する可能性があります。今回の更新により、インストールの失敗後に部分的にデプロイされたクラスターを破棄するときに、インストーラーによってプロビジョニングされたすべてのインフラストラクチャーが正しく削除されるようになりました。(OCPBUGS-1489)
  • 以前は、VMware vSphere にクラスターをインストールするときに、ユーザーが platform.vsphere.vcenters パラメーターを指定したが、install-config.yaml ファイルで platform.vsphere.failureDomains.topology.networks パラメーターを指定しなかった場合、インストールは失敗しました。今回の更新により、インストールプログラムは、platform.vsphere.vcenters を指定するときに platform.vsphere.failureDomains.topology.networks フィールドが必須であることをユーザーに警告します。(OCPBUGS-1698)
  • 以前は、VMware vSphere にクラスターをインストールするときに、ユーザーが platform.vsphere.vcenters および platform.vsphere.failureDomains パラメーターを定義したが、platform.vsphere.defaultMachinePlatform.zones、または compute.platform.vsphere.zones および controlPlane.platform.vsphere.zones を定義していない場合、インストールは失敗しました。今回の更新により、インストールプログラムは、ユーザーがインストール前にマルチリージョンまたはマルチゾーンデプロイメントで zone パラメーターを定義したか検証します。(OCPBUGS-1490)
Kubernetes コントローラーマネージャー
  • 以前は、モニタリングスタックが存在しない環境で Kubernetes Controller Manager Operator が degraded を報告していました。今回の更新により、モニタリングスタックが存在しない場合、Kubernetes Controller Manager Operator は degradation の兆候のモニタリングをチェックしません。(BZ#2118286)
  • 今回の更新により、Kubernetes Controller Manager アラート (KubeControllerManagerDown、PodDisruptionBudgetAtLimit、PodDisruptionBudgetLimit、GarbageCollectorSyncFailed) に Github Runbook へのリンクが追加されました。Runbook は、ユーザーがこれらのアラートのデバッグを理解するのに役立ちます。(BZ#2001409)
Kubernetes Scheduler
  • 以前は、セカンダリースケジューラーのカスタムリソースが削除されてもセカンダリースケジューラーのデプロイメントは削除されませんでした。その結果、Secondary Schedule Operator と Operand が完全にアンインストールされませんでした。今回の更新により、セカンダリースケジューラーのカスタムリソースに正しい所有者への参照が設定され、セカンダリースケジューラーのデプロイメントを指すようになりました。その結果、セカンダリースケジューラーのカスタムリソースが削除されると、セカンダリースケジューラーのデプロイメントも削除されます。(BZ#2100923)
  • OpenShift Container Platform 4.12 リリースでは、デスケジューラーのプロファイルにロールベースアクセス制御 (RBAC) ルールが追加されるため、デスケジューラーは API グループにイベントを発行できるようになりました。(OCPBUGS-2330)
Machine Config Operator
  • 以前は、重要な証明書を含む Machine Config Operator (MCO) ControllerConfig リソースは、Operator のデーモン同期が成功した場合にのみ同期されていました。設計上、デーモンの同期中にノードの準備ができていないと、デーモンの同期が成功しなくなります。そのため、準備ができていないノードは間接的に ControllerConfig リソースの同期を妨げていたため、これらの証明書の同期が妨げられていました。これにより、ControllerConfig リソースに含まれる証明書をローテーションできないために、準備ができていないノードが存在する場合、最終的にクラスターの機能が低下していました。今回のリリースでは、ControllerConfig リソースの同期はデーモン同期の成功に依存しなくなりました。そのため、デーモン同期が失敗した場合でも ControllerConfig リソースは同期を継続するようになりました。これは、準備ができていないノードが ControllerConfig リソースの同期を妨げることがなくなるため、準備ができていないノードがあっても証明書が更新され続けることを意味します。(BZ#2034883)
管理コンソール
  • 以前は、オペレータの詳細 ページは複数のエラーメッセージを表示しようとしましたが、エラーメッセージコンポーネントは一度に 1 つのエラーメッセージしか表示できませんでした。その結果、関連するエラーメッセージが表示されませんでした。今回の更新では、オペレーターの詳細 ページに最初のエラーメッセージのみが表示されるため、関連するエラーがユーザーに表示されます。(OCPBUGS-3927)
  • 以前は、カスタマーケースマネジメント (CCM) で Azure Red Hat OpenShift の製品名が正しくありませんでした。その結果、コンソールは、CCM のフィールドに正しく入力するために、同じ誤った製品名を使用する必要がありました。CCM の製品名が更新されたら、コンソールも更新する必要がありました。今回の更新により、コンソールからリンクをたどると、CCM と同じ正しい製品名に正しい Azure 製品名が正しく取り込まれます。(OCPBUGS-869)
  • 以前は、プラグインページでエラーが発生した場合、エラーページから離れたときにエラーがリセットされず、エラーの原因ではないページに移動した後もエラーが持続していました。今回の更新により、ユーザーが新しいページに移動したときにエラー状態がデフォルトにリセットされ、新しいページに移動した後にエラーが持続しなくなりました。(BZ#2117738, OCPBUGS-523)
  • 以前は、すべてのネームスペース が選択されている場合、インストールされた Operator の Operator 詳細 ペインにある View it here リンクが正しく構築されませんでした。その結果、リンクは すべてのプロジェクト のクラスターサービスバージョン (CSV) の オペレーターの詳細 ページに移動しようとしましたが、これは無効なルートです。今回の更新により、CSV がインストールされている namespace を使用する ここで表示 リンクが正しくビルドされ、リンクが期待どおりに機能するようになりました。(OCPBUGS-184)
  • 以前は、5 桁を超える行番号を使用すると、行番号が行番号と行の内容の間の垂直の仕切りに重なって読みにくくなるという表面的な問題が発生していました。今回の更新で、行番号に使用できるスペースの量が増え、行番号が長くなったため、行番号が垂直の仕切りに重ならなくなりました。(OCPBUGS-183)
  • 以前は、Web コンソールの管理者パースペクティブで、クラスター設定 ページの デフォルトの更新サーバー ポップアップウィンドウにある OpenShift ローカル更新サービスの詳細を確認する へのリンクで 404 エラーが発生していました。今回の更新により、リンクは期待どおりに機能します。(BZ#2098234)
  • 以前は、MatchExpression コンポーネントは配列型の値を考慮していませんでした。その結果、このコンポーネントを使用してフォームから入力できる値は 1 つだけでした。今回の更新により、MatchExpression コンポーネントはコンマ区切りの値を配列として受け入れるようになりました。(BZ#207690)
  • 以前は、モデルの冗長なチェックが行われてタブのリロードが発生し、再レンダリングされたタブのコンテンツがちらつくことがありました。今回の更新で、冗長なモデルチェックが削除され、モデルは 1 回だけチェックされます。その結果、タブのコンテンツがちらつき、再レンダリングされなくなりました。(BZ#2037329)
  • 以前は、OpenShift Dedicated ノードページのアクションリストから edit ラベルを選択すると、応答がなく、Web フックエラーが返されていました。この問題は修正され、編集が失敗した場合にのみエラーメッセージが返されるようになりました。(BZ#2102098)
  • 以前は、問題が保留中の場合、Insights リンクをクリックするとページがクラッシュしていました。回避策として、変数の initialized を待ってから、Insights リンクをクリックします。その結果、Insights ページが期待どおりに開きます。(BZ#2052662)
  • 以前は、MachineConfigPool リソースが一時停止された場合の一時停止の解除オプションとして Resume rollouts が表示されていました。この文言が更新され、Resume updates と表示されるようになりました。(BZ#2094240)
  • 以前は、マスターノードとワーカーノードのカウントに間違った計算方法が使用されていました。今回の更新により、ノードに master と worker の両方のロールがある場合に、正しいワーカーノードが計算されるようになりました。(BZ#1951901)
  • 以前は、ImageManifestVuln の react-router ルートが競合していると、ImageManifestVuln の詳細ページを ~new の名前でレンダリングしようとしていました。今回、競合ルートを削除するようにコンテナーセキュリティープラグインが更新され、Operator の詳細ページで動的リストと詳細ページのエクステンションが使用されるようになりました。その結果、コンソールは ImageManifestVuln の正しい作成、リスト、および詳細ページをレンダリングします。(BZ#2080260)
  • 以前は、不完全な同期されていない YAML がユーザーに表示されることがありました。今回の更新により、常に同期された YAML が表示されるようになりました。(BZ#2084453)
  • 以前は、使用するためにカスタムリソース (CR) を作成する必要がある Operator をインストールする場合、Create resource ボタンが間違った namespace を指しているために CR のインストールに失敗することがありました。今回の更新により、Create resource ボタンが期待どおりに機能するようになりました。(BZ#2094502)
  • 以前は、Cluster update モーダルでエラーが正しく表示されませんでした。その結果、Cluster update モーダルは、エラーが発生してもエラーを表示または説明しませんでした。今回の更新により、Cluster update モーダルでエラーが正しく表示されるようになりました。(BZ#2096350)
Monitoring
  • この更新の前は、クラスター管理者は、スケジューリングの問題のために準備ができていない Pod と、kubelet によって開始できなかったために準備ができていない Pod を区別できませんでした。どちらの場合も、KubePodNotReady アラートが発生します。今回の更新により、スケジューリングの問題のために Pod の準備ができていない場合に KubePodNotScheduled アラートが発生し、kubelet によって開始できなかったために Pod の準備ができていない場合に KubePodNotReady アラートが発生するようになりました。(OCPBUGS-4431)
  • この更新の前は、node_exporter は tun インターフェイス、br インターフェイス、ovn-k8s-mp インターフェイスなどの仮想ネットワークインターフェイスに関するメトリックを報告していました。今回の更新により、これらの仮想インターフェイスのメトリックは収集されなくなり、監視リソースの消費が減少します。(OCPBUGS-1321)
  • この更新の前は、DNS 解決が遅いために Alertmanager Pod の起動がタイムアウトすることがあり、Alertmanager Pod が起動しませんでした。今回のリリースでは、タイムアウト値が 7 分に増やされ、Pod の起動がタイムアウトするのを防ぎます。(BZ#2083226)
  • この更新の前は、Prometheus Operator が Prometheus Pod の実行またはスケジュールに失敗した場合、システムは失敗の根本的な理由を提供しませんでした。今回の更新により、Prometheus Pod が実行またはスケジュールされていない場合、Cluster Monitoring Operator は clusterOperator の監視ステータスを失敗の理由で更新します。これは、根本的な問題のトラブルシューティングに使用できます。(BZ#2043518)
  • 今回の更新の前に、OpenShift Container Platform Web コンソールで 開発者 パースペクティブからアラートのサイレンスを作成した場合、アラートと一致しない外部ラベルが含まれていました。したがって、アラートは消音されません。今回の更新により、Developer パースペクティブでサイレンスを作成するときに外部ラベルが除外されるようになり、新しく作成されたサイレンスが期待どおりに機能するようになりました。(BZ#2084504)
  • 以前は、ユーザー定義プロジェクト専用の Alertmanager のインスタンスを有効にすると、特定の状況で設定ミスが発生する可能性があり、ユーザー定義プロジェクトの Alertmanager 設定マップ設定が Alertmanager のメインインスタンスのどちらにもロードされなかったことが通知されませんでした。またはユーザー定義プロジェクト専用のインスタンス。今回のリリースでは、この設定ミスが発生した場合、Cluster Monitoring Operator は問題を通知し、解決手順を提供するメッセージを表示するようになりました。(BZ#2099939)
  • この更新の前は、Cluster Monitoring Operator (CMO) が Prometheus の更新に失敗した場合、CMO は以前のデプロイが実行されているかどうかを確認せず、Prometheus Pod の 1 つがまだ実行されていてもクラスター監視が利用できないと報告していました。今回の更新により、CMO はこの状況で実行中の Prometheus Pod をチェックし、Prometheus Pod が実行されていない場合にのみクラスター監視が利用できないことを報告するようになりました。(BZ#2039411)
  • この更新の前に、OpsGenie をアラートレシーバーとして設定した場合、api_key と api_key_file は相互に排他的であり、api_key が優先されるという警告がログに表示されていました。この警告は、api_key_file を定義していない場合でも表示されました。今回の更新により、この警告は、api_key と api_key_file の両方を定義した場合にのみログに表示されます。(BZ#2093892)
  • この更新の前は、Telemeter Client (TC) は、手動で再起動したときにのみ新しいプルシークレットをロードしていました。したがって、プルシークレットが変更または更新され、TC が再起動されていない場合、TC はサーバーでの認証に失敗します。今回の更新で問題が解決され、シークレットがローテーションされるとデプロイが自動的に再開され、更新されたトークンを使用して認証されるようになりました。(BZ#2114721)
ネットワーク
  • 以前は、終了状態にあったルーターが oc cp コマンドを遅らせ、Pod が終了するまで oc adm must-gather コマンドを遅らせていました。今回の更新では、must-gather コマンドの実行が遅れないように、発行された oc cp コマンドごとにタイムアウトが設定されます。その結果、Pod を終了しても、must-gather コマンドが遅延することはなくなりました。(BZ#2103283)
  • 以前は、Private エンドポイントの公開戦略タイプと PROXY プロトコルの両方を使用してイングレスコントローラーを設定することはできませんでした。今回の更新により、ユーザーは Private エンドポイント公開戦略タイプと PROXY プロトコルの両方を使用してイングレスコントローラーを設定できるようになりました。(BZ#2104481)
  • 以前は、routeSelector パラメーターは、ルーターのデプロイ前にイングレスコントローラーのルートステータスをクリアしていました。このため、ルートステータスが正しく再入力されませんでした。古いデータの使用を避けるために、ルートステータス検出が更新され、Kubernetes オブジェクトキャッシュに依存しなくなりました。さらに、この更新プログラムには、ルートの状態を判断するために、ルートのデプロイメントで生成 ID を確認するための修正が含まれています。その結果、ルートステータスは routeSelector の更新で一貫してクリアされます。(BZ#2101878)
  • 以前は、OpenShift Container Platform の 4.8 より前のバージョンからアップグレードされたクラスターは、孤立した Route オブジェクトを持つ可能性がありました。これは、特定の Ingress オブジェクトが示す IngressClass に関係なく、OpenShift Container Platform の以前のバージョンが Ingress オブジェクトを Route オブジェクトに変換することが原因でした。今回の更新により、Ingress から Route への変換後にクラスター内に孤立した Route オブジェクトがまだ存在することについて、アラートがクラスター管理者に送信されます。今回の更新では、IngressClass を指定していない Ingress オブジェクトについてクラスター管理者に通知する別のアラートも追加されています。(BZ#1962502)
  • 以前は、ルーターのデプロイメントが依存する configmap が作成されていない場合、ルーターのデプロイメントは進行しませんでした。今回の更新により、デフォルトのイングレスコントローラーのデプロイが進行中の場合、クラスター Operator は ingress progressing=true を報告します。これにより、ユーザーはコマンド oc get co を使用してイングレスコントローラーの問題をデバッグすることになります。(BZ#2066560)
  • 以前は、誤って作成されたネットワークポリシーが OVN-Kubernetes キャッシュに追加されると、OVN-Kubernetes リーダーが crashloopbackoff 状態になることがありました。今回の更新により、OVN-Kubernetes リーダーは nil ポリシーの削除をスキップして crashloopbackoff 状態にならなくなりました。(BZ#2091238)
  • 以前は、同じ namespace または名前を持つ古い EgressIP Pod を削除してから 60 秒以内に同じ namespace または名前を持つ EgressIP Pod を再作成すると、間違った SNAT が設定されていました。その結果、パケットは EgressIP SNAT ではなく nodeIP で送信される可能性がありました。今回の更新により、トラフィックは nodeIP ではなく EgressIP を使用して Pod から送信されます。(BZ#2097243)
  • 以前は、ACL の arp から arp II nd への変更により、arp を使用する古いアクセス制御リスト (ACL) で、unexpectedly found multiple equivalent ACLs (arp v/s arp||nd) エラーが生成されていました。これにより、ネットワークポリシーが適切に作成されませんでした。今回の更新では、arp 一致のみを持つ古い ACL が削除され、新しい arp II nd 一致を持つ ACL のみが存在するようになりました。これにより、ネットワークポリシーが正しく作成され、ovnkube-master でエラーが観察されなくなります。注: これは、古いバージョンから 4.8.14、4.9.32、4.10.13 以降にアップグレードするお客様に影響します。(BZ#2095852).
  • 今回の更新により、CoreDNS は Kubernetes 1.25 に基づくバージョン 1.10.0 に更新されました。これにより、CoreDNS バージョンと、これも Kubernetes 1.25 に基づく OpenShift Container Platform 4.12 の両方が相互に調整されます。(OCPBUGS-1731)
  • 今回の更新により、OpenShift Container Platform ルーターは、Kubernetes 1.25 をサポートする k8s.io/client-go バージョン 1.25.2 を使用するようになりました。これにより、openshift-router と、これも Kubernetes 1.25 に基づく OpenShift Container Platform 4.12 の両方が相互に調整されます。(OCPBUGS-1730)
  • 今回の更新により、Ingress Operator は Kubernetes 1.25 をサポートする k8s.io/client-go バージョン 1.25.2 を使用するようになりました。これにより、Ingress Operator と、これも Kubernetes 1.25 に基づく OpenShift Container Platform 4.12 の両方が相互に調整されます。(OCPBUGS-1554)
  • 以前は、DNS Operator は openshift-dns namespace を調整しませんでした。OpenShift Container Platform 4.12 では openshift-dns namespace に pod-security ラベルが必要であるため、クラスターの更新時に namespace にこれらのラベルが欠落していました。Pod-security ラベルがないと、Pod は起動できませんでした。今回の更新により、DNS Operator は openshift-dns namespace を調整し、pod-security ラベルが存在するようになりました。その結果、Pod は期待どおりに起動します。(OCPBUGS-1549)
  • これまで、ingresscontroller.spec.tuniningOptions.reloadInterval は有効なパラメーター値として 10 進数をサポートしていませんでした。これは、Ingress オペレーターが指定された値をミリ秒に内部的に変換するためで、これはサポートされている時間単位ではありませんでした。これにより、イングレスコントローラーが削除されませんでした。今回の更新により、ingresscontroller.spec.tuningOptions.reloadInterval が 10 進数をサポートするようになり、ユーザーは、以前はサポートされていなかった reloadInterval パラメーター値を使用して Ingress コントローラーを削除できるようになりました。(OCPBUGS-236)
  • 以前は、クラスター DNS オペレーターは Kubernetes 1.24 に基づく GO Kubernetes ライブラリーを使用していましたが、OpenShift Container Platform 4.12 は Kubernetes 1.25 に基づいていました。今回の更新により、GO Kubernetes API は v1.25.2 になり、クラスター DNS オペレーターが Kubernetes 1.25 API を使用する OpenShift Container Platform 4.12 と連携します。(リンク: OCPBUGS-1558)
  • 以前は、disableNetworkDiagnostics 設定を true に設定しても、network-operator Pod が再作成されると保持されませんでした。今回の更新により、ネットワーク Operator を再起動しても、network`operator.openshift.io/cluster` の disableNetworkDiagnostics 設定プロパティーはデフォルト値にリセットされなくなりました。(OCPBUGS-392)
  • 以前は、ovn-kubernetes は br-ex ブリッジでボンディングされたインターフェイスの正しい MAC アドレスを設定しませんでした。その結果、プライマリー Kubernetes インターフェイスにボンディングを使用するノードは、クラスターに参加できませんでした。今回の更新により、ovn-kubernetes は br-ex ブリッジでボンディングされたインターフェイスの正しい MAC アドレスを設定し、プライマリー Kubernetes インターフェイスにボンディングを使用するノードはクラスターに正常に参加できるようになりました。(BZ2096413)
  • 以前は、Ingress Operator が mTLS の使用を有効にするように設定されている場合、Operator は、他のイベントによって調整されるまで、CRL の更新が必要かどうかを確認しませんでした。その結果、mTLS に使用される CRL が古くなる可能性がありました。今回の更新により、CRL の有効期限が切れると Ingress Operator が自動的に調整し、CRL は nextUpdate フィールドで指定された時間に更新されるようになりました。(BZ#2117524)
ノード
  • 以前は、シンボリックリンクのエラーメッセージがエラーとしてフォーマットされるのではなく、生データとして出力されていたため、理解が困難でした。今回の修正により、エラーメッセージが適切にフォーマットされ、理解しやすくなりました。(BZ#1977660)
  • 以前は、パフォーマンスプロファイルがノードに適用された場合の kubelet のハードエビクションのしきい値は Kubernetes のデフォルトとは異なりました。今回のリリースでは、期待される Kubernetes のデフォルトに一致するようにデフォルトが更新されました。(OCPBUGS-4362).
OpenShift CLI (oc)
  • OpenShift Container Platform 4.12 リリースでは、ターゲット namespace に適切なセキュリティーレベルがない場合にターゲットノードでデバッグセッションに入ると問題が修正されます。これにより、oc CLI で Pod セキュリティーエラーメッセージが表示されました。既存の namespace に適切なセキュリティーレベルが含まれていない場合、ターゲットノードで oc デバッグモードに入ると、OpenShift Container Platform は一時的な namespace を作成するようになりました。(OCPBUGS-852)
  • 以前は、macOS arm64 アーキテクチャーでは、oc バイナリーを手動で署名する必要がありました。その結果、oc バイナリーは期待どおりに機能しませんでした。今回の更新では、oc を模倣するための自己署名バイナリーが実装されています。その結果、macOS arm64 アーキテクチャーの oc バイナリーは適切に動作します。(BZ#2059125)
  • 以前は、must-gather はサーバー上に存在しないリソースを収集しようとしていました。そのため、must-gather はエラーメッセージを出力していました。今回、must-gather はリソースを収集する前にリソースが存在するかどうかをチェックするようになりました。その結果、must-gather は、サーバー上に存在しないリソースの収集に失敗してもエラーを出力しなくなりました。(BZ#2095708)
  • OpenShift Container Platform 4.12 リリースでは、oc-mirror ライブラリーが更新され、ライブラリーがマルチアーキテクチャープラットフォームイメージをサポートするようになりました。これは、プラットフォームリリースペイロードをミラーリングするときに、arm64 をはじめとする幅広いアーキテクチャーから選択できることを意味します。(OCPBUGS-617)
Operator Lifecycle Manager (OLM)
  • OpenShift Container Platform 4.12 リリースより前では、オンクラスター 機能の問題により、package-server-manager コントローラーは package-server クラスターサービスバージョン (CSV) に加えられた変更を元に戻しませんでした。これらの永続的な変更は、Operator がクラスターで開始する方法に影響を与える可能性があります。OpenShift Container Platform 4.12 の場合、package-server-manager コントローラーは常に package-server CSV を元の状態に再構築するため、クラスターのアップグレード操作後に CSV への変更が保持されることはありません。on-cluster 関数は、package-server CSV の状態を制御しなくなりました。(OCPBUGS-867)
  • 以前は、ラベルが namespace に存在する場合でも、Operator Lifecycle Manager (OLM) は namespace を更新してラベルを適用しようとしました。そのため、更新リクエストにより、API および etcd サービスのワークロードが増加しました。今回の更新により、OLM は、更新を発行する前に namespace で既存ラベルと期待されるラベルを比較するようになりました。その結果、OLM は namespace に対して不要な更新をリクエストしなくなりました。(BZ#2105045)
  • これまで Operator Lifecycle Manager (OLM) は、ClusterVersion カスタムリソースの spec.DesiredVersion フィールドの計算ミスに基づき、ブロックされるべきではないマイナークラスターアップグレードを阻止していました。今回の更新により、OLM は、アップグレードをサポートする必要がある場合にクラスターのアップグレードを阻止しなくなりました。(BZ#2097557)
  • これまでリコンサイラーは、リソースのコピーを作成せずにリソースのアノテーションを更新していました。これにより、レコンサイラープロセスを終了させるエラーが発生していました。今回の更新により、リコンサイラーはエラーによって停止しなくなりました。(BZ#2105045)
  • package-server-manifest (PSM) は、正しい package-server Cluster Service Version (CSV) がクラスターにインストールされていることを確認するコントローラーです。以前は、クラスター上のオブジェクトが期待されるオブジェクトに影響を与える可能性がある調整機能の論理エラーが原因で、package-server CSV への変更は元に戻りませんでした。ユーザーは package-server CSV を変更でき、変更は元に戻りませんでした。さらに、クラスターのアップグレードでは、package-server CSV の YAML が更新されませんでした。今回の更新により、期待されるバージョンの CSV が常にゼロからビルドされるようになりました。これにより、クラスター上のオブジェクトが期待される値に影響を与えることができなくなります。その結果、PSM は package-server CSV を変更しようとする試みを元に戻すことができ、クラスターをアップグレードすると期待される package-server CSV がデプロイされるようになりました。(OCPBUGS-858)
  • 以前は、OLM は Operator の CRD ステータスに従って Operator をアップグレードしていました。CRD は、グループ/バージョン/種類 (GVK) 識別子によって定義された順序でコンポーネント参照を一覧表示します。同じコンポーネントを共有する Operator により、GVK が Operator のコンポーネントリストを変更する可能性があり、これにより、OLM が CRD のステータスを継続的に更新するためにより多くのシステムリソースを必要とする可能性があります。今回の更新により、Operator Lifecycle Manager (OLM) は、Operator のコンポーネント参照に従って Operator をアップグレードするようになりました。Operator のカスタムリソース定義 (CRD) ステータスの変更は、OLM Operator のアップグレードプロセスには影響しません。(OCPBUGS-3795)
Operator SDK
  • 今回の更新により、Pod 仕様に securityContext 設定フィールドを含めることで、レジストリー Pod のセキュリティーコンテキストを設定できるようになりました。これにより、Pod 内のすべてのコンテナーにセキュリティーコンテキストが適用されます。securityContext フィールドは、Pod の権限も定義します。(BZ#2091864)
File Integrity Operator
  • これまで File Integrity Operator は、Operator のパーミッションで openshift-file-integrity namespace を使用してテンプレートをデプロイしていました。Operator が namespace にオブジェクトを作成しようとすると、パーミッションの問題により失敗しました。今回のリリースでは、OLM により使用されるデプロイメントリソースが更新され、パーミッションの問題を修正して正しい namespace を使用するようになりました。これにより、ユーザーはデフォルト以外の namespace に Operator をインストールして使用できるようになりました。(BZ#2104897)
  • 以前は、File Integrity Operator の基本的な依存関係によってアラートと通知の処理方法が変更され、結果として Operator はメトリクスを送信しませんでした。このリリースでは、Operator はメトリクスエンドポイントが正しく、起動時に到達可能であることを確認します。(BZ#2115821)
  • 以前は、File Integrity Operator によって発行されたアラートは namespace を設定しませんでした。これにより、アラートがどこから発信されたのか、どのコンポーネントがアラートを発行したのかを理解することが困難になりました。今回のリリースでは、Operator にインストール先の namespace がアラートに含まれるようになり、注意が必要なコンポーネントを絞り込みやすくなりました。(BZ#2101393)
  • 以前は、File Integrity Operator は、アップグレード中にアラートの変更を適切に処理しませんでした。その結果、アラートには、Operator がインストールされた namespace が含まれていませんでした。今回のリリースでは、Operator にインストール先の namespace がアラートに含まれるようになり、注意が必要なコンポーネントを絞り込みやすくなりました。(BZ#2112394)
  • 以前は、File Integrity Operator のサービスアカウント所有権で基礎となる OLM の更新によりリグレッションが発生し、0.1.24 から 0.1.29 への更新が壊れていました。今回の更新により、Operator はデフォルトで 0.1.30 にアップグレードされます。(BZ#2109153)
  • 以前は、File Integrity Operator デーモンは、最近のアクセス許可の変更に対して Roles パラメーターの代わりに ClusterRoles パラメーターを使用していました。その結果、OLM は Operator を更新できませんでした。今回のリリースでは、Operator デーモンは Roles パラメーターの使用に戻り、古いバージョンからバージョン 0.1.29 へのアップグレードは正常に行われます。(BZ#2108475)
Compliance Operator
  • 以前は、Compliance Operator は古いバージョンの Operator SDK を使用していました。これは、Operator を構築するための依存関係です。これにより、Operator SDK で使用される非推奨の Kubernetes 機能に関するアラートが発生しました。今回のリリースでは、Compliance Operator がバージョン 0.1.55 にアップグレードされ、Operator SDK の更新バージョンが含まれています。(BZ#2098581)
  • 以前は、rhcos4-high-master-sysctl-kernel-yama-ptrace-scope および rhcos4-sysctl-kernel-core-pattern ルールに自動修復を適用すると、修復されたにもかかわらず、スキャン結果でこれらのルールが失敗する結果になりました。この問題は、このリリースで修正されています。(BZ#2094382)
  • 以前は、Compliance Operator がデフォルトの namespace に通知をハードコーディングしていました。その結果、Operator が別の namespace にインストールされている場合、Operator からの通知は表示されませんでした。この問題は、このリリースで修正されています。(BZ#2060726)
  • 以前は、Compliance Operator は、Ignition 仕様のないマシン設定を解析するときに API リソースを取得できませんでした。これにより、api-check-pods チェックでクラッシュループが発生しました。今回のリリースでは、Compliance Operator が更新され、Ignition 仕様なしでマシン設定プールを適切に処理できるようになりました。(BZ#2117268)
  • これまで Compliance Operator は、マシン設定と kubelet 設定の間の関係を判別できなかったため、マシン設定をスタック状態に保持していました。これは、マシン設定名に関する誤った仮定が原因でした。このリリースでは、コンプライアンスオペレーターは、kubelet 設定がマシン設定のサブセットであるかどうかを判断できます。(BZ#2102511)
OpenShift API サーバー
  • 以前は、メンバーを追加すると、以前のメンバーがグループから削除されることがありました。その結果、ユーザーはグループ権限を失いました。今回のリリースでは、依存関係が強化され、ユーザーがグループ権限を失うことはなくなりました。(OCPBUGS-533)
Red Hat Enterprise Linux CoreOS (RHCOS)
  • 以前は、Podman 4.0 に更新すると、ユーザーは RHCOS のツールボックスコンテナーでカスタムイメージを使用できなくなりました。この修正により、Podman の新しい動作に対応するようにツールボックスライブラリーコードが更新されるため、ユーザーは期待どおり RHCOS のツールボックスでカスタムイメージを使用できるようになりました。(BZ#2048789)
  • 以前は、podman exec コマンドはネストされたコンテナーではうまく機能しませんでした。oc debug コマンドを使用してノードにアクセスし、toolbox コマンドを使用してコンテナーを実行すると、この問題が発生しました。このため、ユーザーは RHCOS でツールボックスを再利用できませんでした。この修正により、この動作を考慮してツールボックスライブラリーコードが更新され、ユーザーは RHCOS でツールボックスを再利用できるようになりました。(BZ#1915537)
  • 今回の更新により、ツールボックス コマンドを実行すると、コンテナーを起動する前にデフォルトのイメージの更新がチェックされるようになりました。これにより、セキュリティーが向上し、ユーザーに最新のバグ修正が提供されます。(BZ#2049591)
  • 以前は、Podman 4.0 に更新すると、ユーザーは RHCOS で toolbox コマンドを実行できなくなりました。この修正により、Podman の新しい動作に対応するようにツールボックスライブラリーコードが更新されるため、ユーザーは期待どおりに RHCOS で toolbox を実行できるようになりました。(BZ#2093040)
  • 以前は、カスタム SELinux ポリシーモジュールは rpm-ostree で適切にサポートされていなかったため、更新時にシステムの残りの部分と共に更新されませんでした。これは、無関係なコンポーネントの障害として表面化します。今後の OpenShift Container Platform リリースでの SELinux ユーザー空間の改善が保留されているため、この更新は、必要に応じてブート中に SELinux ポリシーを再構築および再ロードする RHCOS への回避策を提供します。(OCPBUGS-595)
スケーラビリティーおよびパフォーマンス
  • 調整済みプロファイルが\変更され、最近の Red Hat Enterprise Linux (RHEL) カーネルパッチに追加され、新しく導入された CPU ごとの kthreads (ktimers) に ksoftirqd および rcuc と同じ優先度を割り当てるようになりました。詳細は、OCPBUGS-3475、BZ#2117780、BZ#2122220 を参照してください。
  • 以前は、tuned サービスを再起動すると、irqbalance 設定が不適切にリセットされ、分離された CPU で再度 IRQ 操作が行われ、分離保証に違反していました。今回の修正により、tuned サービスを (明示的またはバグにより) 再起動しても irqbalance サービスの設定が適切に保持され、IRQ サービスに関する CPU 分離保証が保たれるようになりました。(OCPBUGS-585)
  • 以前は、調整済みデーモンがクラスター Node Tuning Operator の一部として順不同で再起動されると、割り込みハンドラーの CPU アフィニティーがリセットされ、調整が損なわれていました。今回の修正により、tuned の irqbalance プラグインが無効になり、OpenShift Container Platform は CRI-O と irqbalance の間のロジックとインタラクションに依存するようになりました。(BZ#2105123)
  • 以前は、ノードに負荷がかかっているときに新しい veth デバイスごとに低遅延フックスクリプトを実行すると、時間がかかりすぎていました。その結果、Pod 開始イベント中に遅延が蓄積され、kube-apiserver のロールアウト時間が遅くなり、5 分のロールアウトタイムアウトを超えることもありました。今回の修正により、コンテナーの開始時間が短縮され、5 分のしきい値内に収まるはずです。(BZ#2109965)
  • 以前は、oslat 制御スレッドがテストスレッドの 1 つと併置されていたため、測定でレイテンシースパイクが発生していました。今回の修正により、oslat ランナーは制御スレッド用に 1 つの CPU を確保するようになり、テストがビジー状態のスレッドを実行するために使用する CPU が 1 つ少なくなりました。(BZ#2051443)
  • oslat、cyclictest、hwlatdetect とも呼ばれるレイテンシー測定ツールは、完全に分離された CPU 上で実行され、レイテンシースパイクの原因となるヘルパープロセスはバックグラウンドで実行されるようになりました。そのため、より正確なレイテンシー測定が可能になりました。(OCPBUGS-2618)
  • 以前は、group-du-sno-ranGen.yaml の参照 PolicyGenTemplate には 2 つの StorageClass エントリーが含まれていましたが、生成されたポリシーには 1 つしか含まれていませんでした。今回の更新により、生成されたポリシーに両方のポリシーが含まれるようになりました。(BZ#2049306)
ストレージ
  • 以前は、汎用的な一時ボリュームのチェックに失敗していました。今回の更新により、拡張可能なボリュームのチェックに汎用的な一時ボリュームが含まれるようになりました。(BZ#2082773)
  • 以前は、vSphere に複数のシークレットが存在する場合、vSphere CSI Operator がランダムにシークレットを選択し、Operator が再起動することがありました。今回の更新により、vCenter CSI Operator に複数のシークレットがある場合に警告が表示されるようになりました。(BZ#2108473)
  • 以前は、Container Storage Interface (CSI) ドライバーがノードからボリュームをアンマウントできない場合、OpenShift Container Platform はボリュームをデタッチしていました。アンマウントせずにボリュームをデタッチすることは CSI 仕様では許可されておらず、ドライバーが undocumented 状態になる可能性があります。今回の更新により、CSI ドライバーは、異常なノードでのみアンマウントする前にデタッチされ、undocumented 状態を回避するようになりました。(BZ#2049306)
  • 以前は、Manila CSI Driver Operator の VolumeSnapshotClass でアノテーションが欠落していました。そのため、Manila CSI スナップショット作成者はシークレットを見つけることができず、デフォルトの VolumeSnapshotClass でスナップショットを作成できませんでした。今回の更新で問題が修正され、シークレットの名前と namespace がデフォルトの VolumeSnapshotClass に含まれるようになりました。その結果、ユーザーはデフォルトの VolumeSnapshotClass を使用して、Manila CSI Driver Operator でスナップショットを作成できるようになりました。(BZ#2057637)

  • ユーザーは、Azure File の実験的な VHD 機能の利用を選択できるようになりました。これを選択するには、ユーザーはストレージクラスで fstype パラメーターを指定し、--enable-vhd=true で有効にする必要があります。fstype が使用され、機能が true に設定されていない場合、ボリュームはプロビジョニングに失敗します。

    VHD 機能を使用しないようにするには、ストレージクラスから fstype パラメーターを削除します。(BZ#2080449)

  • 以前は、vSphere に複数のシークレットが存在する場合、vSphere CSI Operator がランダムにシークレットを選択し、Operator が再起動することがありました。今回の更新により、vCenter CSI Operator に複数のシークレットがある場合に警告が表示されるようになりました。(BZ#2108473)
Web コンソール (開発者パースペクティブ)
  • 以前は、ユーザーは追加および編集フォームで Git シークレットを選択解除できませんでした。その結果、リソースを再作成する必要がありました。今回の修正では、select secret オプションリストで No Secret を選択するオプションを追加することで、問題を解決しました。その結果、ユーザーは添付されたシークレットを簡単に選択、選択解除、または切り離すことができます。(BZ#2089221)
  • OpenShift Container Platform 4.9 では、Developer Perspective で最小のデータまたはデータがない場合、ほとんどの監視チャートまたはグラフ (CPU 消費、メモリー使用、および帯域幅) は -1 から 1 の範囲を示します。ただし、これらの値はいずれもゼロ未満の値にすることはできません。この問題は、今後のリリースで解決される予定です。(BZ#1904106)
  • 今回の更新前は、ユーザー定義の Alertmanager サービスがデプロイされた場合、OpenShift Container Platform Web コンソールの Developer パースペクティブでアラートを無音にすることができませんでした。これは、Web コンソールが要求を openshift-monitoring namespace のプラットフォーム Alertmanager サービスに転送するためでした。今回の更新により、Web コンソールで Developer パースペクティブを表示してアラートを消音しようとすると、要求が正しい Alertmanager サービスに転送されるようになりました。(OCPBUGS-1789)
  • 以前は、プロジェクトの開発者カタログを拡張する Add Helm Chart Repositories フォームに既知の問題がありました。クイックスタート ガイドでは、必要な namespace に ProjectHelmChartRepository CR を追加できると説明されていますが、これを実行するには kubeadmin からのパーミッションが必要である点については言及されていません。この問題は、クイックスタート に ProjectHelmChartRepository CR を作成するための正しい手順を記載することで解決されました。(BZ#2057306)