サポートコンソール開発者トライアルの開始お問い合わせ

1.6. バグ修正

ベアメタルハードウェアのプロビジョニング
  • これまで、Integrated Lights-Out (iLO) 管理インターフェイスドライバーで設定されたサーバーに OpenShift Container Platform クラスターノードをデプロイしようとすると、そのノードのプロビジョニングに失敗していました。この失敗は、iLO ドライブに ilo/use_web_server_for_images 設定パラメーターがないため、ドライバーがオブジェクトストレージをデフォルトのストレージメカニズムとして使用を試みることで発生していました。この製品にオブジェクトストレージは存在しません。今回の更新により、OpenShift Container Platform 4.13 以降のバージョンでは iLO ドライバーの設定に ilo/use_web_server_for_images が追加され、ドライバーは metal3 Pod で実行される Web サーバーを使用するようになります。(OCPBUGS-5068)
クラウドコンピュート

  • Google Cloud Platform クラスターの一部の設定では、内部ロードバランサーは、インストールプログラムによって作成されたインスタンスグループを使用します。以前は、コントロールプレーンマシンを手動で交換すると、新しいコントロールプレーンノードがコントロールプレーンインスタンスグループに割り当てられませんでした。これにより、内部ロードバランサー経由でノードに到達できなくなりました。この問題を解決するには、管理者が Google Cloud コンソールを使用して、コントロールプレーンマシンを正しいインスタンスグループに手動で移動する必要がありました。

    このリリースでは、交換用コントロールプレーンノードが正しいインスタンスグループに割り当てられます。(BZ#1970464､OCPCLOUD-1562)

  • 以前は、Google Cloud Platform 用に設定されたコンピュートマシンが無効なマシンの調整を試みることができ、それが原因でフェーズが割り当てられないままスタックする可能性がありました。今回のリリースでは、無効な設定を持つマシンは Failed 状態になります。(OCPBUGS-4574)
  • これまで、コントロールプレーンマシンセットのレプリカが準備完了とみなされるには、リンクされたノードも準備完了になる必要があるにもかかわらず、バッキングマシンが Running 状態になると準備完了とみなされていました。このリリースでは、ノードとそのマシンが Ready 状態にならなければ、コントロールプレーンマシンセットのレプリカは準備完了とみなされません。(OCPBUGS-8424)
  • 以前は、Microsoft Azure クラスター上の高速ネットワーク機能でエラーが発生した場合、mapi_instance_create_failed アラートメトリックは開始されませんでした。このリリースでは、欠落していたアラートが追加され、Accelerated Networking が有効になっているクラスターが必要に応じてアラートを生成できるようになりました。(OCPBUGS-5235)
  • 以前は、マシンが Running 状態になると、それ以降のノードの状態変化はチェックされませんでした。以前の解決策 (OCPBUGS-8424) では、ノードとそのマシンが Ready 状態でなければコントロールプレーンマシンセットのレプリカを準備完了とみなさない、という要件が導入されました。その結果、ノードとマシンの準備完了状態をコントロールプレーンマシンセットが逃した場合、レプリカは準備完了になりませんでした。この動作により、Control Plane Machine Set Operator が使用できなくなり、アップグレードがブロックされました。今回のリリースでは、マシンが実行中でノードが準備完了状態ではない場合、準備完了になるまでノードが定期的にチェックされます。この修正により、Control Plane Machine Set Operator が使用できずにアップグレードがブロックされることはなくなりました。(OCPBUGS-10771)
  • 以前は、マシンのヘルスチェックが maxUnhealthy しきい値を超えてアラートが生成されると、クラスターがマシンのヘルスチェックを正常に調整できるほど健全になってもメトリックはリセットされず、アラートが継続していました。このリリースでは、アラートをいつトリガーするか決定するロジックが改善され、クラスターが健全になるとアラートがクリアされるようになりました。(OCPBUGS-4725)
  • 以前の解決策 (OCPBUGS-5546) では、マシン設定オブジェクト内の MachineConfig.Name の clusterName 割り当てを削除しました。その結果、パラメーターの値は空の文字列となり、IP アドレス名を作成するために machineName の値と結合されると、無効な値になっていました。この無効な値が原因で、プロビジョニング中にマシンに障害が発生しました。このリリースでは、有効な IP アドレス名を作成するために、clusterName の値がインフラストラクチャーオブジェクトから取得されます。(OCPBUGS-7696)
  • Kubernetes 1.26 リリースでは、ノードがルーティングトラフィックを受信しないようにするため、NotReady ステータスを持つ健全ではないノードをパブリックロードバランサーから削除するなどの変更が、ノードインフラストラクチャーに導入されました。これらの変更は、Microsoft Azure のクラスター内で実行されているノードに影響を与えました。その結果、ノードは Ready ステータスに復帰できず、アウトバウンド接続も確立できませんでした。この更新により、パブリックロードバランサーからノードを切り離さなくても、NotReady ステータスでマークされたノードが kube-proxy ヘルスプローブで検出されるようになりました。これは、ノードがこれらのフェーズを通してアウトバウンドインターネット接続を維持できることを意味します。(OCPBUGS-7359)
Cloud Credential Operator
  • Amazon Simple Storage Service (Amazon S3) は、Amazon S3 バケット設定を更新しました。これにより、Amazon Web Services (AWS) リージョンで作成されたバケットでは、デフォルトで S3 Block Public Access が有効になり、アクセス制御制限 (ACL) が無効になります。この設定では、S3 バケットリソースの使用をプライベートに制限します。OpenShift Container Platform 4.13 では、パブリックでの S3 バケットリソースの使用を可能にするため、デフォルトの S3 バケット設定を考慮して CCO ユーティリティー (ccoctl) とインストールプログラムが更新されました。(OCPBUGS-11706、OCPBUGS-11661)
開発者コンソール
  • これまで OpenShift Container Platform は、Knative Serving および Eventing に API バージョン v1alpha1 を使用していましたが、バグのため API バージョン v1beta1 はサポートされていませんでした。今回の修正により、OpenShift Container Platform は両方の API バージョンをサポートするようになりました。(OCPBUGS-5164)
  • 以前は、OpenShift Container Platform コンソールでパイプラインを編集すると、Pipeline builder および YAML view 設定オプションで正しいデータがレンダリングされませんでした。この問題により、Pipeline builder でパイプラインを編集できませんでした。今回の更新により、データが正しく解析され、ビルダーを使用してパイプラインを編集できるようになりました。(OCPBUGS-5016)
  • 以前は、トポロジーサイドバーに更新された情報が表示されませんでした。トポロジーサイドバーからリソースを直接更新した場合、サイドバーを再度開いて変更を確認する必要がありました。今回の修正により、更新されたリソースが正しく表示されるようになりました。トポロジーサイドバーで、最新の変更を直接確認できます。(OCPBUGS-4691)
  • 以前は、OpenShift Container Platform の Samples ページでは、リストされているサンプルのタイプを区別できませんでした。今回の修正により、Samples ページに表示されるバッジでサンプルを識別できるようになります。(OCPBUGS-10679)
ドキュメント

以前は、OpenShift Container Platform ドキュメントには、「オンプレミスベアメタルノードを使用してクラスターを拡張する」というタイトルのサブセクションが含まれていました。これは、正確で最新のドキュメントを維持するために削除されました。

etcd Cluster Operator
  • 以前は、Control Plane Machine Set Operator は、クラスターのブートストラップが完了する前にコントロールプレーンマシンを再作成しようとしました。これにより、etcd クラスターのメンバーシップからブートストラップノードが削除され、etcd クォーラムが失われ、クラスターがオフラインになりました。今回の更新により、Control Plane Machine Set Operator は、etcd Cluster Operator がブートストラップノードを削除した後にのみコントロールプレーンマシンを再作成するようになりました。(OCPBUGS-10960)
ホストされたコントロールプレーン
  • 以前は、HostedControlPlane オブジェクトは、HostedCluster リソースによって設定されたスケジューラープロファイルへの変更を識別しませんでした。さらに、HostedControlPlane は変更をスケジューラーに伝達しなかったため、スケジューラーは最新のスケジューラープロファイルの変更を受け取るためにコントロールプレーン Pod を再起動しませんでした。今回の更新により、HostedControlPlane はスケジューラープロファイルの変更を認識し、スケジューラーを動的に再起動するようになりました。その結果、スケジューラーはプロファイルの変更を Pod に適用できるようになりました。(OCPBUGS-7091)
  • これまで、ホストされたクラスターは OpenID Connect (OIDC) プロバイダー (oidc) が使用できないことを考慮せず、そのために machine および machineset オブジェクトの削除が古くなっていました。今回の更新により、ホストされたクラスターは使用できない odic プロバイダーのステータスを検出できるようになりました。そのため、odic プロバイダーが使用できないことが原因で、machine および machineset オブジェクトの削除が古くならなくなりました。(OCPBUGS-10227)
  • 以前は、Amazon Web Services (AWS) コンピュートマシンセットの spec.metadata.annotations パラメーター値は、コンピューティングマシンからそのノードにコピーされませんでした。そのため、ノードにはコンピュートマシンセットで指定されたアノテーションが欠落していました。このリリースでは、アノテーションがノードに正しく適用されます。(OCPBUGS-4566)
Installer
  • 以前は、プライベートクラスターをアンインストールするときに、インストールプログラムが作成した DNS レコードは削除されませんでした。この更新により、インストールプログラムはこれらの DNS レコードを正しく削除するようになりました。(OCPBUGS-7973)
  • 以前は、ベアメタル installer-provisioned infrastructure は、ポート 80 を使用して Baseboard Management Controller (BMC) およびデプロイメントエージェントにイメージを提供していました。ポート 80 はインターネット通信用として一般的に選択されるため、セキュリティーリスクが存在する可能性があります。ベアメタル installer-provisioned infrastructure は、ポート 6180 を使用して、デプロイされたクラスター上の metal3 Pod によって使用されるイメージを提供するようになりました。(OCPBUGS-8511)
  • 以前は、踏み台ホストがクラスターノードと同じ VPC ネットワークで実行されている場合、ブートストラップノードとクラスターノードへの SSH アクセスが失敗していました。また、この設定が原因で、一時ブートストラップノードからクラスターノードへの SSH アクセスが失敗していました。これらの問題は、一時ブートストラップノードとクラスターノード間の SSH トラフィックと、同じ VPC ネットワーク上の踏み台ホストからクラスターノードへの SSH トラフィックをサポートするように IBM Cloud セキュリティーグループルールを更新することで修正されました。installer-provisioned infrastructure での障害発生中に、分析用のログとデバッグ情報を正確に収集できるようになりました。(OCPBUGS-8035)
  • 以前は、role パラメーターが worker に設定されているホストの IP アドレスにランデブー IP を設定し、ISO イメージを生成した場合、エージェントベースのインストーラーはクラスターのインストールに失敗していました。この設定に基づいて ISO イメージを生成しようとすると、検証失敗のメッセージが表示されるようになりました。このメッセージを受信したら、master ロールを持つホストの IP を使用するように、agent-config.yaml ファイルの rendezvousIP フィールドを更新する必要があります。(OCPBUGS-2088)
  • 以前は、インストールプログラムは、aws-sdk-go ライブラリーで定義された新しいリージョン (ap-south-2、ap-southeast-4、eu-central-2、eu-south-2、および me-central-1) を受け入れませんでした。インストールプログラムを使用してインストール設定ファイルを作成した場合、インストールプログラムはこれらの新しいリージョンをリストしたり、これらのリージョンに対する手動エントリーを受け入れたりしませんでした。今回の更新により、インストールプログラムはこれらのリージョンをサポートし、インストール設定ファイルを作成するときにそれらを指定できるようになりました。(OCPBUGS-10213)
  • 以前は、install-config.yaml ファイルの controlPlane.platform.openstack.failureDomain フィールドに基づいて Machine.PrimaryNetwork を設定するコードベースに問題がありました。この問題は、Kuryr で実行される OpenShift Container Platform が、相互間の通信にコントロールプレーンマシンを使用する Red Hat OpenStack Platform (RHOSP) サブネット上のポートを識別する際に影響します。今回の更新により、failureDomain Technology Preview コンポーネントで portTarget の control-plane を設定すると、インストールプログラムによって Machine.PrimaryNetwork フィールドにポートの情報が設定され、OpenShift Container Platform クラスターが Kuryr で正常に実行されるようになります。(OCPBUGS-10658)
  • 以前は、AWS リソースのタグを解除できないため、us-gov-west-1 リージョンにデプロイされた AWS クラスターのアンインストールが失敗していました。その結果、プロセスが無限ループに陥り、インストールプログラムがリソースのタグを解除しようとしていました。今回の更新により、再試行が阻止されます。これにより、クラスターのアンインストールは成功します。(BZ#2070744)
  • 以前は、Google Cloud Platform (GCP) 上で実行されているプライベート OpenShift Container Platform クラスターは追加のファイアウォールルールを受信して、GCP が内部および外部のロードバランサーに対してヘルスチェックを実行できるようにしていました。プライベートクラスターは内部ロードバランサーのみを使用するため、外部ロードバランサーに対するヘルスチェックの実行は必要はありません。今回の更新により、GCP 上で実行されるプライベートクラスターは、外部ロードバランサーのヘルスチェックに起因する追加のファイアウォールルールを受信しなくなります。(BZ#2110982)
Kubernetes Scheduler
  • 以前は、namespace フィルタリングをテストするために LifeCycleUtilization プロファイルを除外すると、次のエラーが Descheduler Operator ログに記録されました: belowE0222 12:43:14.331258 1 target_config_reconciler.go:668] key failed with : only namespace exclusion supported with LowNodeUtilization。その結果、descheduler クラスター Pod は起動しませんでした。今回の更新により、namespace の除外が LifeCycleUtilization プロファイルで機能するようになりました。(OCPBUGS-7876)
管理コンソール
  • 以前は、Create Pod ボタンのレンダリング時にユーザー権限がチェックされず、必要な権限を持たないユーザーに対してボタンがレンダリングされていました。今回の更新により、Create Pod ボタンのレンダリング時にユーザー権限がチェックされ、必要な権限を持つユーザーに対してレンダリングされるようになりました。(BZ#2005232)
  • 以前は、Pod リソースのアクションメニューに、不要な PDB add、edit、および remove アクションがありました。今回の更新により、アクションは削除されました。(BZ#2110565)
  • 以前は、Details ページの PodDisruptionBudget フィールドに誤ったヘルプメッセージがありました。今回の更新により、より説明的なヘルプメッセージが表示されるようになりました。(BZ#2084452)
  • 以前は、メトリクスが無効になっていてナビゲーションメニューに表示されない場合でも、コンソールのルートパスに移動すると、URL が Overview ページにリダイレクトされていました。今回の更新では、メトリクスが無効になっている場合、マストヘッドのロゴをクリックするか、コンソールのルートパスに移動すると、URL が project list ページにリダイレクトされます。(OCPBUGS-3033)
  • 以前は、クラスタードロップダウンが常時表示されない位置に配置されていたため、どのクラスターが表示されているかが不明瞭でした。今回の更新により、クラスタードロップダウンがマストヘッドに追加されたため、クラスタードロップダウンが常に表示され、いつでも表示しているクラスターを確認できるようになりました。(OCPBUGS-7089)
  • 以前は、クラスターバージョンのステータスが Failing、UpdatingAndFailing、Updating の場合はノードの進行状況バーが表示されるように設定されていたため、クラスターの更新時以外でもノードの進行状況バーが表示されていました。今回の更新により、クラスターバージョンのステータスが UpdatingAndFailing または Updating の場合にのみノードの進行状況バーが表示されるようになります。(OCPBUGS-6049)
  • 以前は、ServiceAccount の kubeconfig ファイルをダウンロードすると、エラーが表示され、ServiceAccount トークンに到達できませんでした。このエラーは、自動的に生成されたシークレットが削除されたことが原因で発生していました。今回の更新により、kubeconfig のダウンロードアクションが削除され、エラーは発生しなくなります。(OCPBUGS-7308)
  • 以前は、Pod のセキュリティー対策が原因でアノテーションが欠落しているため、Node details ページの Terminal タブにエラーが表示されていました。必要なアノテーションがないと、ノードデバッグ Pod を開始できません。今回の更新では OpenShift Container Platform にこれらのアノテーションが追加されるため、ノードデバッグ Pod の開始が可能になり、エラーなしで Terminal タブが読み込まれるようになります。(OCPBUGS-4252)
  • 以前は、クラスター管理者が Operator をアンインストールするときに oc delete csv コマンドを発行しようとすると、Operator のサブスクリプションがスタック状態になっていました。サブスクリプションに競合が存在したため、管理者は Operator を再インストールできませんでした。今回の更新により、管理者がアンインストールされた Operator を再インストールしようとすると、詳細なエラーメッセージが表示されます。(OCPBUGS-3822)
  • 以前は、1 つ以上の既存プラグインが失敗した場合、Web コンソールにはコンソールの更新を促すトースト通知が表示されませんでした。このアクションは、Operator がプラグインをコンソールに追加した後にプラグインを表示するために必要です。今回の更新により、Operator がプラグインを追加すると Web コンソールがそれを確認し、以前に失敗したプラグインかにかかわらず、コンソールにトースト通知を表示します。(OCPBUGS-10249)
  • 以前は、終了したコンテナーは、終了したコンテナーごとに {{label}} および {{exitCode}} コードをレンダリングしていました。今回の更新により、internationalization コードが修正され、読み取り可能な出力メッセージが表示されるようになりました。(OCPBUGS-4206)
  • 以前は、リグレッションが導入され、clusterversion status.availableUpdates の値が null および Upgradeable=False の場合に Cluster Settings ページでエラーが返されていました。今回の更新により、status.availableUpdates の値を null 値に設定できるようになりました。(OCPBUGS-6053)
モニタリング
  • 以前は、Kubernetes スケジューラーは、複数の再起動操作を受け取ったノードで特定の Pod のスケジューリングをスキップできました。OpenShift Container Platform 4.13 では、30 分以内にスケジューリングできない Pod に対する KubePodNotScheduled アラートを組み込むことで、この問題に対処しています。(OCPBUGS-2260)
  • 以前は、Thanos Ruler に複数のラベルが定義されている場合、prometheus-operator がカスタムリソースを調整するたびに指定された順序でラベルを追加しないため、statefulset が再作成ループに入る可能性がありました。この修正後、prometheus-operator は statefulset に追加する前に追加ラベルを並べ替えるようになりました。(OCPBUGS-6055)
  • このリリースでは、特定の読み取り専用 tmpfs インスタンスに対して NodeFilesystemAlmostOutOfSpace が起動されなくなりました。この変更により、設計上いっぱいになっている特定の tmpfs マウントポイントに対してアラートが起動される問題が修正されました。(OCPBUGS-6577)
ネットワーク
  • これまで、Ingress Operator は、エラーメッセージが表示されるべきときに、updateIngressClass 関数ログの成功メッセージを表示していました。今回の更新により、Ingress Operator のログメッセージが正確になりました。(OCPBUGS-6700)
  • これまで、Ingress Operator は ingressClass.spec.parameters.scope を指定せず、Ingress Class API オブジェクトはデフォルトで cluster タイプを指定していました。そのため、Operator の開始時にすべての Ingress クラスで不必要な更新が発生していました。今回の更新により、Ingress Operator は ingressClass.spec.parameters.scope で Cluster タイプを指定します。(OCPBUGS-6701)
  • これまで、Ingress Operator の ensureNodePortService ログメッセージに間違ったサービス名が含まれており、誤った情報がログに記録されていました。今回の更新により、Ingress Operator は ensureNodePortService に正確なサービスを記録するようになりました。(OCPBUGS-6698)
  • これまで、OpenShift Container Platform 4.7.0 および 4.6.20 では、Ingress Operator は OpenShift Container Platform に固有のルーター Pod のアノテーションを使用していました。これは、バグを修正するために liveness プローブの猶予期間を設定する一時的な措置でした。その結果、OpenShift Container Platform は修正を実装するためのパッチを適用する必要がありました。今回の更新により、Ingress Operator は terminationGracePeriodSeconds API フィールドを使用し、将来のリリースで以前のパッチを削除できるようになります。(OCPBUGS-4703)
  • これまで、CoreDNS は古いツールチェーンを使用してメインバイナリーと古いベースイメージをビルドしていました。今回の更新により、OpenShift Container Platform は 4.13 を使用してツールチェーンとベースイメージをビルドします。(OCPBUGS-6228)
ノード
  • これまで、LifecycleAndUtilization descheduler プロファイルで有効化される LowNodeUtilization ストラテジーは、namespace の除外をサポートしていませんでした。このリリースでは、LifecycleAndUtilization descheduler プロファイルが設定されている場合は namespace が適切に除外されます。(OCPBUGS-513)
  • これまで、動作のリグレッションにより、Machine Config Operator (MCO) が kubeletconfig または containerruntimeconfig カスタムリソース (CR) 内に重複した MachineConfig オブジェクトを作成していました。重複するオブジェクトの機能が低下し、クラスターのアップグレードに失敗していました。今回の更新により、kubeletconfig および containerruntimeconfig コントローラーは重複オブジェクトを検出して削除できるようになりました。このアクションにより、機能低下した MachineConfig オブジェクトのエラーが削除され、クラスターのアップグレード操作は影響を受けません。(OCPBUGS-7719)
Node Tuning Operator (NTO)
  • これまで、Cloud-native Functions (CNF) テストイメージが、CNF が有効になっている OpenShift Container Platform クラスター上でレイテンシーテストを実行するために 使用する hwlatdetect ツールには、10 秒の検出期間が設定されていました。この設定を 0.95 秒の検出幅設定と組み合わせると、ツールは割り当てられた検出期間の 9.5% の時間でノードを監視するため、hwlatdetect がレイテンシースパイクを見逃す可能性が高まります。今回の更新では検出期間が 1 秒に設定され、ツールは割り当てられた検出期間の約 95% の時間でノードを監視できるようになりました。監視時間の残りの 5% は、カーネルがシステムタスクを実行できるように未割り当てのままになります。(OCPBUGS-12433)
OpenShift CLI (oc)
  • これまで、oc adm upgrade コマンドは ClusterVersion の Failing=True ステータスを読み取りませんでした。今回の更新により、oc adm upgrade には、クラスター状態を要約するときに Failing=True 条件の情報が追加されます。これにより、ClusterOperators の Degraded=True ステータスや、現在のクラスターの動作や将来の更新に影響を与える可能性のある他の問題が可視化されます。(OCPBUGS-3714)
  • これまで、oc-mirror コマンドは、ミラーリングされたディスクイメージから OCI および FBC Operator のカタログコンテンツをコンソールにビルドしていました。その結果、カタログのすべてのコンテンツがミラーリングされるのではなく、一部のコンテンツがカタログから欠落していました。今回の更新により、ミラーリングされたコンテンツを宛先レジストリーにプッシュする前に、それを反映するカタログイメージがビルドされ、より完全なカタログが作成されるようになります。(OCPBUGS-5805)
  • これまで、oc-mirror OpenShift CLI (oc) プラグインは、Operator カタログをエントリーとして ImageContentSourcePolicy リソースに追加していました。Operator カタログは CatalogSource リソース内の宛先レジストリーから直接使用されるため、このリソースにこのエントリーは必要ありません。この問題により、ImageContentSourcePolicy リソース内の予期しないエントリーが原因となって、クラスターがリリースイメージ署名リソースを受信する際に影響が出ていました。今回の更新では、oc-mirror プラグインが ImageContentSourcePolicy リソースから Operator カタログエントリーを削除するため、クラスターは CatalogSource リソース内の Operator カタログから署名リソースを受け取ります。(OCPBUGS-10320)
Operator Lifecycle Manager (OLM)
  • Operator のカスタムリソース (CR) のステータスには、Operator が所有するコンポーネントのリストが含まれます。このリストは group/version/kind (GVK) の順序で並べられていますが、同じ GVK を持つオブジェクトの順序は変更される可能性があります。Operator が同じ GVK を持つ多くのコンポーネントを所有している場合、コンポーネントの順序が変更されるため、Operator Lifecycle Manager (OLM) が Operator CR のステータスを継続的に更新する可能性があります。このバグ修正により OLM が更新され、Operator のコンポーネント参照順序が確定されるようになりました。その結果、コンポーネントのリストに変化がない場合、OLM は CR を繰り返し更新しようとしなくなりました。(OCPBUGS-2556)
  • Operator Lifecycle Manager (OLM) は、Operator の検索とインストールに使用できる一連の CatalogSource オブジェクトを管理します。これらのカタログソースはこのアクションのデフォルトソースであり、Red Hat によって管理されます。しかし、OLM システムが認識しない方法で、デフォルトのカタログソースが変更される可能性がありました。デフォルトのカタログソースを操作不能になるような方法で変更すると、OLM 全体で連鎖的な問題が発生し、ユーザーがクラスターで新しい Operator をインストールしたり、既存の Operator をアップグレードしたりできなくなる可能性があります。このバグ修正により、デフォルトのカタログソースを管理する catalog-operator ランタイムが更新され、CatalogSource 仕様に対する他の変更が認識されるようになります。その結果、デフォルトのカタログソースに変更が加えられると、OLM はその変更を検出し、デフォルトにリセットします。(OCPBUGS-5466)
Red Hat Enterprise Linux CoreOS (RHCOS)
  • これまで、Azure には SR-IOV インターフェイスを NM_UNMANAGED としてマークする udev ルールが initramfs ファイルになかったため、NetworkManager が起動時に SR-IOV インターフェイスを設定していました。今回の更新により、udev ルールが initramfs ファイルに追加され、SR-IOV インターフェイスが NetworkManager によって管理されることはなくなりました。(OCPBUGS-7173)
Security Profiles Operator
  • これまで、net_container などの別のテンプレートを選択した場合、Security Profiles Operator (SPO) SELinux ポリシーはコンテナーテンプレートから低レベルのポリシー定義を継承しませんでした。このポリシーは、コンテナーテンプレートにのみ存在する低レベルのポリシー定義を必要とするため、機能しません。この問題は、SPO SELinux ポリシーが SELinux ポリシーを SPO カスタム形式から 共通中間言語 (CIL) 形式に変換しようとすると発生しました。今回の更新により、SPO から CIL への変換を必要とする SELinux ポリシーにコンテナーテンプレートが追加されます。さらに、SPO SELinux ポリシーは、サポートされている任意のポリシーテンプレートから低レベルのポリシー定義を継承できるようになりました。(OCPBUGS-12879)
スケーラビリティーおよびパフォーマンス

  • これまで、パフォーマンスプロファイルが生成されると、自動的に作成される CRI-O ランタイムファイルが CRI-O ランタイムとして runc を使用するように設定されていました。

    現在は、パフォーマンスプロファイルの生成時にコンテナーランタイムとして crun を設定する機能の一般提供が開始され、作成されたランタイム CRI-O ファイルは ContainerRuntimeConfig CR で設定された defaultRuntime と一致します。これは crun または runc のいずれかになります。デフォルトは runc です。(OCPBUGS-11813)

ストレージ
  • 以前は、openshift-manila-csi-driver namespace には、ワークロードのパーティション設定を管理するために必要なラベルが含まれていませんでした。これらのラベルは、選択した CPU セットでの Manila CSI Pod の実行を制限する操作に影響を与えていました。今回の更新により、openshift-manila-csi-driver namespace に workload.openshift.io/allowed ラベルが追加されました。(OCPBUGS-11341)
Windows コンテナー
  • これまで、Windows ノードのアップグレードプロセス中に Microsoft Windows コンテナーのワークロードが完全には空になりませんでした。その結果、アップグレード中のノードにワークロードが残り、サービスが中断されていました。今回の更新により、Windows Machine Config Operator (WMCO) はワークロードをドレインし、ノードのアップグレードが完了するまでノードを遮断します。このアクションにより、Microsoft Windows インスタンスのシームレスなアップグレードが保証されます。(OCPBUGS-5732)
  • これまで、Windows Machine Config Operator (WMCO) は DaemonSet ワークロードをドレインできませんでした。この問題により、WMCO が削除またはアップグレードしようとした Windows ノードが Windows`DaemonSet` Pod によってブロックされていました。今回の更新により、WMCO にはロールベースのアクセス制御 (RBAC) 権限が追加され、WMCO が DaemonSet ワークロードを削除できるようになりました。WMCO は、containerd shim で作成されたプロセスを削除することもできるため、WMCO がクラスターからノードを削除すると Windows インスタンス上に DaemonSet コンテナーは存在しなくなります。(OCPBUGS-5354)
  • これまでは、リポジトリータグがビルドシステムに伝播されなかったため、containerd コンテナーランタイムは各 Windows ノードで誤ったバージョンを報告していました。この設定により、containerd は Go ビルドバージョンを各 Windows ノードのバージョンとして報告していました。今回の更新により、ビルド時に正しいバージョンがバイナリーに注入され、containerd が各 Windows ノードの正しいバージョンを報告するようになります。(OCPBUGS-5378)
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.