1.6. バグ修正


API サーバーと認証
  • 以前は、セキュリティーコンテキストの制約によって変更される Pod 仕様を使用して Pod コントローラーを作成すると、Pod が指定された namespace の Pod セキュリティーレベルを満たしていないという警告がユーザーに表示されることがありました。このリリースでは、Pod コントローラーがその namespace で Pod のセキュリティーに違反しない Pod を作成する場合に、Pod のセキュリティー違反に関する警告が表示されなくなりました。(OCPBUGS-7267)
  • user:check-access スコープのトークンは、SelfSubjectAccessReview リクエストを送信するための十分なパーミッションを付与します。以前は、トークンに user:full スコープまたはロールスコープが含まれていない限り、クラスターはアクセスレビューを実行するための十分なパーミッションを付与しませんでした。このリリースでは、クラスターは、アクセスレビューを実行できるようにするために、完全なユーザーのパーミッション、またはリクエストに設定されたユーザーのロールのパーミッションを持っているかのように、SelfSubjectAccessReview リクエストを承認します。(OCPBUGS-7415)
  • 以前は、Pod セキュリティーアドミッションコントローラーでは、サービスアカウントをロールに正常にバインドするために .subjects[].kindServiceAccount に設定されている場合に、RoleBinding オブジェクトの .subject[].namespace フィールドを設定する必要がありました。このリリースでは、.subject[].namespace が指定されていない場合、Pod セキュリティーアドミッションコントローラーは、RoleBinding オブジェクトの namespace を使用します。(OCPBUGS-160)
  • 以前は、ValidatingWebhookConfiguration オブジェクトと MutatingWebhookConfiguration オブジェクトのすべての Webhook の clientConfig は、service-ca トラストバンドルを使用して適切に注入された caBundle を取得できませんでした。このリリースでは、ValidatingWebhookConfiguration オブジェクトと MutatingWebhookConfiguration オブジェクトのすべての Webhook の clientConfig が、service-ca トラストバンドルを使用して適切に注入された caBundle を取得するようになりました。(OCPBUGS-19318)
  • 以前は、namedCertificatesservingCertificate に無効なシークレット名が指定された場合、kube-apiserver は Degraded=True に変更されませんでした。このリリースでは、kube-apiserver が Degraded=True に切り替わり、証明書が受け入れられなかった理由を表示して、トラブルシューティングを簡素化するようになりました。(OCPBUGS-8404)
  • 以前は、可観測性ダッシュボードは、データを表示するために大規模なクエリーを使用していたため、多数のノードを持つクラスターで頻繁にタイムアウトが発生していました。このリリースでは、可観測性ダッシュボードは、多数のノードを含むクラスターの信頼性を確保するために、事前に計算された記録ルールを使用します。(OCPBUGS-3986)
ベアメタルハードウェアのプロビジョニング
  • 以前は、ベアメタルマシンのホスト名がリバース DNS または DHCP によって提供されなかった場合、インストーラーがプロビジョニングしたインフラストラクチャーでのベアメタルクラスターのプロビジョニング中に、デフォルトで localhost が使用されていました。この問題により、Kubernetes ノード名の競合が発生し、クラスターをデプロイできなくなりました。現在は、ホスト名が localhost であることが検出された場合、プロビジョニングエージェントは永続的なホスト名を BareMetalHost オブジェクトの名前に設定します。(OCPBUGS-9072)
クラウドコンピュート
  • 以前は、マシン API コントローラーは、複数のゾーンを使用する vSphere クラスター内のマシンのゾーンを特定できませんでした。このリリースでは、ゾーン検索ロジックは仮想マシンのホストに基づいており、その結果、マシンオブジェクトは適切なゾーンを示します。(OCPBUGS-7249)
  • 以前は、clouds.yaml ファイル内のクラウド認証情報をローテーションした後、新しいクラウド認証情報を取得するために、OpenStack マシン API プロバイダーを再起動する必要がありました。その結果、ゼロにスケールよう設定されたマシンの機能が影響を受ける可能性があります。この変更により、クラウド認証情報はキャッシュされなくなり、プロバイダーは必要に応じて対応するシークレットを新たに読み取ります。(OCPBUGS-8687)
  • 以前は、Cluster Autoscaler Operator の起動プロセス中のいくつかの条件によってロックが発生し、Operator が正常に起動して自身を使用可能にマークすることができませんでした。その結果、クラスターのパフォーマンスが低下しました。この問題は、このリリースで解決されました。(OCPBUGS-20038)
  • 以前は、コントロールプレーンノードのクライアント認証情報を要求するために使用されるブートストラップ認証情報には、汎用のすべてのサービスアカウントグループが含まれていませんでした。その結果、Cluster Machine Approver は、このフェーズ中に作成された証明書署名要求 (CSR) を無視しました。特定の状況では、これによりブートストラップ中に CSR が承認されなくなり、インストールが失敗する原因となりました。このリリースでは、ブートストラップ認証情報には、Cluster Machine Approver がサービスアカウントに対して期待するグループが含まれています。この変更により、Machine Approver がクラスターのライフサイクルの早い段階でブートストラップ CSR Approver を引き継ぐことができるようになり、CSR Approver に関連するブートストラップの失敗が減少するはずです。(OCPBUGS-8349)
  • 以前は、Nutanix クラスター上のマシンのスケーリングが操作を完了するために利用可能なメモリーを超えた場合、マシンは Provisioning 状態でスタックし、スケールアップまたはスケールダウンできませんでした。この問題はこのリリースで解決されています。(OCPBUGS-19731)
  • 以前は、Control Plane Machine Set Operator が OnDelete 更新ストラテジーを使用するように設定されているクラスターの場合、マシンに関するキャッシュされた情報により、Operator はマシンのバランスを誤って、調整中にマシンを想定外の障害ドメインに配置していました。このリリースでは、Operator は新しいマシンを作成する直前にこの情報を更新し、マシンを配置する障害ドメインを正確に識別します。(OCPBUGS-15338)
  • 以前は、Control Plane Machine Set Operator は Infrastructure オブジェクト仕様を使用してクラスターのプラットフォームタイプを決定していました。このプラクティスは、OpenShift Container Platform バージョン 4.5 以前からアップグレードされたクラスターの場合、クラスターが AWS で実行されていることを Operator が正しく判断できないことを意味しました。そのため、想定どおりに ControlPlaneMachineSet カスタムリソース (CR) を生成できませんでした。このリリースでは、Operator はステータスプラットフォームタイプを使用します。このタイプは、クラスターの作成時に関係なくすべてのクラスターに設定され、すべてのクラスターに対して ControlPlaneMachineSet CR を生成できるようになりました。(OCPBUGS-11389)
  • 以前は、コントロールプレーンマシンセットによって作成されたマシンは、基盤となる Machine API マシンが実行されると、準備完了とみなされていました。このリリースでは、マシンにリンクされているノードの準備も完了するまで、そのマシンは準備完了とみなされなくなりました。(OCPBUGS-7989)
  • 以前は、Control Plane Machine Set Operator は、障害ドメイン全体でのマシンの可用性が改善されなかったとしても、アルファベット順に障害ドメインに優先順位を付け、アルファベット順で後方に位置する障害ドメインからアルファベット順で前方に位置する障害ドメインにマシンを移動していました。このリリースでは、既存のマシンに存在する障害ドメインを優先し、可用性を向上させる既存の障害ドメインを考慮するように Operator が更新されました。(OCPBUGS-7921)
  • 以前は、コントロールプレーンマシンセットを使用する vSphere クラスター上のコントロールプレーンマシンが削除されると、2 つの代替マシンが作成されることがありました。このリリースでは、コントロールプレーンマシンセットによって余分なマシンが作成されなくなりました。(OCPBUGS-7516)
  • 以前は、マシンセット内のアベイラビリティーゾーンとサブネット ID が一致しない場合、ユーザーに不一致が通知されることなく、マシンセット仕様を使用してマシンが正常に作成されました。値の不一致は、一部の設定で問題を引き起こす可能性があるため、この問題が警告メッセージとして表示される場合があります。このリリースでは、不一致に関する警告がログに記録されます。(OCPBUGS-6882)
  • 以前は、IP アドレス管理 (IPAM) ネットワーク設定の代わりに Dynamic Host Configuration Protocol (DHCP) を使用する OpenShift Container Platform クラスターを Nutanix 上に作成する場合、仮想マシンのホスト名は DHCP によって設定されませんでした。このリリースでは、仮想マシンホスト名が Ignition 設定ファイルの値で設定されます。その結果、DHCP および他のネットワーク設定タイプの問題が解決されました。(OCPBUGS-6727)
  • 以前は、openshift-cluster-api namespace に複数のクラスターを作成できました。この namespace には、クラスターを 1 つだけ含める必要があります。このリリースにより、この namespace に追加のクラスターを作成できなくなりました。(OCPBUGS-4147)
  • 以前は、コントロールプレーンマシンセットのカスタムリソースの providerSpec フィールドから一部のパラメーターをクリアすると、コントロールプレーンマシンの削除と作成のループが発生していました。このリリースでは、これらのパラメーターがクリアされたり、空のままになったりするとデフォルト値が適用され、問題は解決されました。(OCPBUGS-2960)
Cloud Credential Operator
  • 以前は、Cloud Credential Operator ユーティリティー (ccoctl) は、AWS GovCloud (米国) および AWS 中国リージョンに対して誤った Amazon Resource Names (ARN) 接頭辞を使用していました。ARN 接頭辞が正しくないため、インストール中に AWS リソースの作成に使用される ccoctl aws create-all コマンドが失敗していました。このリリースでは、ARN 接頭辞を正しい値に更新しました。(OCPBUGS-13549)
  • 以前は、Amazon S3 バケットに対するセキュリティーの変更により、インストール中に AWS リソースを作成するために使用される Cloud Credential Operator ユーティリティー (ccoctl) コマンド (ccoctl aws create-all) が失敗していました。このリリースでは、ccoctl ユーティリティーが更新され、Amazon S3 セキュリティーの変更が反映されています。(OCPBUGS-11671)
Cluster Version Operator
  • 以前は、Cluster Version Operator (CVO) が SecurityContextConstraints リソースを期待どおりに調整しませんでした。CVO は、リリースイメージで定義された状態に合わせて SecurityContextConstraints リソースを適切に調整し、サポートされていない変更をすべて元に戻します。

    以前の OpenShift Container Platform バージョンからアップグレードしたいユーザー、および変更されたシステム SecurityContextConstraints リソースに応じてワークロードを操作するユーザーは、ナレッジベースの記事 の手順に従って、変更されたシステムの SecurityContextConstraint リソースなしでワークロードを実行できるようにする必要があります。(OCPBUGS-19465)

  • 以前は、Cluster Version Operator は、どの条件付き更新リスクを最初に評価するかを決定する際に、可能性のあるターゲットに優先順位を付けていませんでした。リスクが適用されない条件付き更新については、Cluster Version Operator の検出後、これらの更新をより迅速に利用できるようになります。(OCPBUGS-5469)
開発者コンソール
  • 以前は、Developer コンソールで Helm に移動し、Repositories タブをクリックしてから、Helm チャートリポジトリーの kebab メニューから Edit HelmChartRepository を選択して Helm チャートリポジトリーを編集しようとした場合、Error ページに 404: Page Not Found エラーが表示されました。これは、コンポーネントパスが最新ではないことが原因でした。この問題は修正されています。(OCPBUGS-14660)
  • 以前は、Samples ページにリストされているサンプルのタイプを区別することは困難でした。この修正により、Samples ページに表示されるバッジで、サンプルタイプを簡単に識別できるようになります。(OCPBUGS-7446)
  • 以前のパイプライン Metrics ページでは、TaskRun 期間グラフに 4 つの凡例のみが表示されていました。この更新により、TaskRun 期間グラフに存在するすべての凡例を確認できるようになりました。(OCPBUGS-19878)
  • 以前は、Cluster Samples Operator がインストールされていない切断されたクラスターで Import JAR フォームを使用してアプリケーションを作成すると、問題が発生しました。この更新により、Java ビルダーイメージが存在しない場合、Add ページおよび Topology ページの Import JAR フォームが非表示になりました。(OCPBUGS-15011)
  • 以前は、クラスターサービスバージョン (CSV) のコピーが無効になっている場合、Operator がサポートするカタログにはカタログアイテムが表示されませんでした。この修正により、CSV コピーが無効になっている場合でも、Operator がサポートするカタログがすべての namespace に表示されます。(OCPBUGS-14907)
  • 以前は、Git からインポート および イメージのデプロイ フローで、リソースタイプ セクションが 詳細 セクションに移動されました。その結果、作成されたリソースの種類を特定することが困難になりました。この修正により、Resource Type セクションが General セクションに移動されました。(OCPBUGS-7395)
etcd Cluster Operator
  • 以前は、etcdctl バイナリーがローカルマシンに無期限にキャッシュされていたため、バイナリーを更新できませんでした。バイナリーは、cluster-backup.sh スクリプトが呼び出されるたびに、適切に更新されるようになりました。(OCPBUGS-19499)
インストーラー
  • 以前は、サポートされているシークレットパーティションに AWS クラスターをインストールするときに、カスタム Red Hat Enterprise Linux CoreOS (RHCOS) Amazon Machine Image (AMI) を指定しなかった場合、インストールは失敗していました。この更新により、インストールプログラムは、クラスターをデプロイする前に、インストール設定ファイルで RHCOS AMI の ID が指定されたことを検証します。(OCPBUGS-13636)
  • 以前は、OpenShift Container Platform インストールプログラムは、共有 VPC を使用した Google Cloud Platform (GCP) へのインストール中に、ホストプロジェクト内のプライベートホスト型ゾーンを検出しませんでした。この更新により、インストールプログラムはホストプロジェクト内の既存のプライベートホスト型ゾーンを確認し、存在する場合はプライベートホスト型ゾーンを使用します。(OCPBUGS-11736)
  • 以前は、プライベート Azure クラスターをインストールする際に、ユーザー定義の送信ルーティングを設定すると、クラスターがデフォルトのパブリックロードバランサーを使用して誤ってデプロイされました。この動作は、インストーラーがプロビジョニングしたインフラストラクチャーを使用してクラスターをインストールする際に発生しました。この更新により、ユーザー定義のルーティングが設定されている場合、インストールプログラムはパブリックロードバランサーを作成しなくなります。(OCPBUGS-9404)
  • 以前は、RHOSP 上で実行されるクラスターの場合、インストールのプロビジョニング解除フェーズで、インストーラーはオブジェクトストレージコンテナーを連続的に削除していました。この動作により、特に大きなコンテナーの場合、オブジェクトの削除が遅くなり、非効率的になってしまいました。この問題は、Swift コンテナーを使用するイメージストリームが時間の経過とともにオブジェクトを蓄積したことが原因の 1 つとなり、発生しました。現在は、オブジェクトの一括削除は RHOSP API への最大 3 つの呼び出しと同時に行われ、呼び出しあたりにより多くのオブジェクト数を処理することで効率が向上しています。この最適化により、プロビジョニング解除中のリソースのクリーンアップが高速化されます。(OCPBUGS-9081)
  • 以前は、踏み台ホストがクラスターノードと同じ VPC ネットワークで実行されている場合、ブートストラップノードとクラスターノードへの SSH アクセスが失敗していました。また、この設定が原因で、一時ブートストラップノードからクラスターノードへの SSH アクセスが失敗していました。これらの問題は、一時ブートストラップノードとクラスターノード間の SSH トラフィックと、同じ VPC ネットワーク上の bastion ホストからクラスターノードへの SSH トラフィックをサポートするように IBM Cloud SecurityGroupRules を更新することで修正されています。インストーラーがプロビジョニングしたインフラストラクチャーでの障害発生中に、分析用のログとデバッグ情報を正確に収集できます。(OCPBUGS-8035)
  • 以前は、プライベートクラスターをアンインストールするときに、インストールプログラムが作成した DNS レコードは削除されませんでした。この更新により、インストールプログラムはこれらの DNS レコードを正しく削除するようになりました。(OCPBUGS-7973)
  • 以前は、RHOSP API で無効な HTTPS 証明書をチェックするためにドキュメントで提供されているスクリプトは、最新バージョンの RHOSP クライアントを想定していました。最新バージョンのクライアントを持っていないユーザーの場合、このスクリプトは失敗しました。現在、マニュアルの手順がドキュメントに追加されており、ユーザーはこれに従って、クライアントの任意のバージョンでチェックを実行できます。(OCPBUGS-7954)
  • 以前は、エージェントベースのインストールの設定のために、agent-config.yaml または nmstateconfig.yaml ファイルで静的 IP アドレスを定義する場合、設定された静的 IP アドレスがブートストラップ中に設定されていない可能性がありました。その結果、ホストインターフェイスは DHCP 経由でアドレスを選択していました。この更新により、設定された静的 IP アドレスがホストインターフェイスに正しく適用されるように、タイミングの問題が修正されました。(OCPBUGS-16219)
  • 以前は、エージェントベースのインストール中に、ImageContentSources フィールドもミラーリングに設定されている場合にのみ、install-config.yaml ファイルの AdditionalTrustBundle フィールド内の証明書が最終イメージに伝播されました。ミラーリングが設定されていない場合、追加の証明書はブートストラップにはありましたが、最終イメージにはありませんでした。この状況は、インストール中のクラスター全体のプロキシー設定 で説明されているように、プロキシーをセットアップして証明書を追加する場合に、問題を引き起こす可能性があります。この更新により、ImageContentSources フィールドも設定されているかどうかに関係なく、これらの追加の証明書が最終イメージに伝播されます。(OCPBUGS-13535)
  • 以前は、openshift-install agent create コマンドは、無効なコマンドを実行するとヘルプ出力を返しませんでした。この更新により、無効な openshift-install agent create コマンドを実行したときに、ヘルプ出力が表示されるようになりました。(OCPBUGS-10638)
  • 以前は、テクノロジープレビューの障害ドメインを使用する生成されたマシンに対して、プライマリーネットワークが正しく設定されませんでした。その結果、ID control-plane を持つポートターゲットが、マシン上のプライマリーネットワークとして設定されず、Kuryr を使用するインストールが正しく機能しない可能性がありました。このフィールドは、適切なポートターゲットが設定されている場合は、それを使用するように設定されるようになりました。生成されたマシンのプライマリーネットワークが正しく設定されるようになり、Kuryr を使用するインストールを完了できるようになりました。(OCPBUGS-10570)
  • 以前は、ダイジェストを含む releaseImage を使用している際に openshift-install agent create image コマンドを実行すると、コマンドは WARNING The ImageContentSources configuration in install-config.yaml should have at-least one source field matching the releaseImage という警告メッセージを生成しました。このメッセージは、ImageContentSources の設定方法に関係なく毎回生成され、混乱を引き起こす可能性がありました。この更新により、リリースイメージに一致するソースフィールドが少なくとも 1 つ含まれるように ImageContentSources が適切に設定されていない場合にのみ、警告メッセージが生成されるようになりました。(OCPBUGS-10207)
  • 以前は、openshift-install agent create image コマンドを実行してブート可能 ISO イメージを生成すると、コマンド出力にイメージが正常に生成されたことを示すメッセージが表示されていました。この出力メッセージは、エージェントベースのインストーラーが、リリースイメージからベース ISO イメージを展開できなかった場合でも存在しました。この更新により、エージェントベースのインストーラーがベース ISO イメージを見つけられない場合 (releaseImage の問題を示している可能性あり) に、コマンド出力でエラーメッセージが生成されるようになりました。(OCPBUGS-9949)
  • 以前は、インストールプログラムがデフォルトのサービスアカウントの認証情報を使用していたため、パススルー認証情報モードを使用した GCP への共有 VPC インストールが失敗することがありました。この更新により、デフォルトの代わりにノードの作成に使用する別のサービスアカウントを指定できるようになりました。(OCPBUGS-15421)
  • 以前は、agent-config.yaml または nmstateconfig.yaml 設定ファイルのいずれかで、コンピュートノードよりも多くのコントロールプレーンノードを定義すると、警告メッセージが表示されていました。現在は、いずれかのファイルでこの設定を指定すると、どちらのファイルでもコンピュートノードがコントロールプレーンノードを超えることができないことを示すエラーメッセージが表示されます。(OCPBUGS-14877)
  • 以前は、agent-config.yaml ファイルの RendezvousIP フィールドに非標準 IPv6 アドレスが使用されている場合、エージェントベースのインストールは失敗していました。非標準の IPv6 アドレスには、先頭にゼロが含まれます (例: 2001:0db8:0000:0000:0000:0000:0000:0000)。この更新により、これらの有効なアドレスが RendezvousIP に使用できるようになりました。(OCPBUGS-14121)
  • 以前は、Operator がクラウド認証情報をキャッシュしていたため、これらの認証情報がローテーションされると認証の問題が発生していました。現在、Operator は常に最新の認証情報を使用します。Manila CSI Driver Operator は、利用可能な Manila 共有タイプごとに OpenShift ストレージクラスを自動的に作成します。この操作の一環として、Operator は Manila API にクエリーを実行します。(OCPBUGS-14049)
  • 以前は、エージェントベースのインストール中に使用する install-config.yaml ファイルを設定する際に、cpuPartitioning フィールドをデフォルト以外の値に変更しても、このフィールドがエージェントベースのインストールでは無視されることをユーザーに知らせるための警告は生成されませんでした。この更新により、cpuPartitioning フィールドを変更すると、その設定がインストールに影響を与えないという警告がユーザーに表示されるようになりました。(OCPBUGS-13662)
  • 以前は、インストールプログラムが 0.0.0.0 からのトラフィックを許可するデフォルトのネットワークセキュリティーグループを作成したため、既存の Azure Virtual Network (VNet) への Azure クラスターのインストールが失敗することがありました。この障害は、既存の VNet のテナントで、Rule: Network Security Groups shall not allow rule with 0.0.0.0/Any Source/Destination IP Addresses - Custom Deny というルールが有効になっている場合に発生しました。この修正により、インストールプログラムは、クラスターを既存の VNet にインストールする際にデフォルトのネットワークセキュリティーグループを作成しなくなり、インストールは成功するようになりました。(OCPBUGS-11796)
  • インストール中のクラスターのステータスが installing-pending-user-action の場合、ステータスが解決されるまでインストールは完了しません。以前は、openshift-install agent wait-for bootstrap-complete コマンドを実行した場合、このステータスの原因となった問題を解決する方法が示されていませんでした。この更新により、問題解決のためにどのアクションを実行する必要があるかを示すメッセージが、コマンド出力に表示されます。(OCPBUGS-4998)

    たとえば、無効なブートディスクが使用された場合の wait-for 出力は、次のようになります。

    "level=info msg=Cluster has hosts requiring user input
    level=debug msg=Host master-1 Expected the host to boot from disk, but it booted the installation image - please reboot and fix boot order to boot from disk QEMU_HARDDISK drive-scsi0-0-0-0 (sda, /dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:0:0)
    level=debug msg=Host master-2 Expected the host to boot from disk, but it booted the installation image - please reboot and fix boot order to boot from disk QEMU_HARDDISK drive-scsi0-0-0-0 (sda, /dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:0:0)
    level=info msg=cluster has stopped installing... working to recover installation"
  • 以前は、インストールされたクラスター上の assisted-installer-controller は、クラスターのインストールが完了した後でも継続的に実行されていました。assisted-service は、クラウドではなくブートストラップノードで実行され、ブートストラップノードが再起動してクラスターに参加すると assisted-service はオフラインになるため、assisted-installer-controller は assisted-service との通信ができず、更新のポストやログとループのアップロードができませんでした。現在、assisted-installer-controllerassisted-service を使用せずにクラスターのインストールをチェックし、クラスターのインストールが完了すると終了します。(OCPBUGS-4240)
  • 以前は、AWS Commercial Cloud Services (C2S) us-iso-east-1 リージョンへのクラスターのインストールが失敗し、UnsupportedOperation を示すエラーメッセージが表示されました。この修正により、このリージョンへ正常にインストールされるようになりました。(OCPBUGS-2324)
  • 以前は、インストールプログラムが必要なサービスエンドポイントを含む cloud.conf ファイルを作成しなかったため、AWS へのインストールが失敗することがありました。これにより、マシン config Operator がサービスエンドポイントのない空の cloud.conf ファイルを作成し、エラーが発生しました。この更新により、インストールが成功するように、インストールプログラムは常に cloud.conf ファイルを作成するようになりました。(OCPBUGS-20401)
  • 以前は、エージェントベースのインストーラーを使用してクラスターをインストールし、プルシークレットに null の auth または email フィールドが含まれている場合、有用なエラーが表示されずにインストールが失敗していました。この更新により、openshift-install agent wait-for install-complete コマンドがプルシークレットを検証し、null フィールドがある場合に通知するようになりました。(OCPBUGS-14405)
  • 以前は、create agent-config-template コマンドは INFO のみを含む行を出力していましたが、コマンドが成功したかどうか、そしてテンプレートファイルがどこに書き込まれたかに関する詳細は出力されませんでした。コマンドが成功すると、コマンドは INFO Created Agent Config Template in <path> directory を出力します。(OCPBUGS-13408)
  • 以前は、ユーザーが agent-config.yaml ファイルで vendor ヒントを指定すると、その値が間違ったフィールドと照合され、ヒントが一致しませんでした。この更新により、vendor ヒントを使用すると、ディスクが正しく選択されるようになりました。(OCPBUGS-13356)
  • 以前は、AWS にクラスターをインストールするときに、metadataService.authentication フィールドを Required に設定しても、IMDSv2 認証を使用するようにブートストラップ仮想マシンが設定されませんでした。これにより、IMDSv1 認証をブロックするように AWS アカウントを設定した場合、インストールが失敗する可能性があります。この更新により、metadataService.authentication フィールドは、Required に設定されている場合、IMDSv2 認証を使用するようにブートストラップ仮想マシンを正しく設定します。(OCPBUGS-12964)
  • 以前は、プライベート Azure クラスターをインストールする際に、ユーザー定義の送信ルーティングを設定すると、クラスターがデフォルトのパブリックロードバランサーを使用して誤ってデプロイされました。この動作は、インストーラーがプロビジョニングしたインフラストラクチャーを使用してクラスターをインストールする際に発生しました。この更新により、ユーザー定義のルーティングが設定されている場合、インストールプログラムはパブリックロードバランサーを作成しなくなります。(OCPBUGS-9404)
  • 以前は、vSphere Terraform vsphere_virtual_machine リソースには、firmware パラメーターが含まれていませんでした。この問題により、仮想マシンのファームウェアが、efi ではなく、bios にデフォルトで設定されていました。現在、リソースには firmware パラメーターが含まれており、パラメーターのデフォルト値として efi が設定されているため、仮想マシンは Basic Input/Output System (BIOS) インターフェイスではなく、Extensible Firmware Interface (EFI) を実行します。(OCPBUGS-9378)
  • 以前は、RHOSP 上で実行されるクラスターの場合、インストールのプロビジョニング解除フェーズで、インストーラーはオブジェクトストレージコンテナーを連続的に削除していました。この動作により、特に大きなコンテナーの場合、オブジェクトの削除が遅くなり、非効率的になってしまいました。この問題は、Swift コンテナーを使用するイメージストリームが時間の経過とともにオブジェクトを蓄積したことが原因の 1 つとなり、発生しました。現在、オブジェクトの一括削除は RHOSP API への最大 3 つの呼び出しと同時に行われるようになり、呼び出しあたりにより多くのオブジェクト数を処理することで効率が向上します。この最適化により、プロビジョニング解除中のリソースのクリーンアップが高速化されます。(OCPBUGS-9081)
  • 以前は、サブスクリプション ID を指定せずにディスク暗号化を使用し、クラスターを Azure にインストールした場合、インストールプログラムはエラーを表示して終了しませんでした。これにより、インストールは開始しても、その後失敗していました。この更新により、インストールプログラムでは、暗号化された Azure インストールのサブスクリプション ID を指定する必要があり、指定しない場合はエラーを表示して終了するようになりました。(OCPBUGS-8449)
  • 以前は、エージェントベースのインストーラーは pingnslookup などのセカンダリーチェックの結果を表示していましたが、これはインストールが成功した場合でも、害を及ぼさない形で失敗する可能性がありました。これにより、クラスターが正常にインストールされたにもかかわらず、エラーが表示される可能性がありました。この更新により、セカンダリーチェックは、プライマリーインストールのチェックが失敗した場合にのみ、結果を表示するようになり、セカンダリーチェックを使用して、失敗したインストールのトラブルシューティングを行うことができるようになりました。(OCPBUGS-8390)
  • エージェントベースのインストーラーで IPI install-config を使用すると、未使用のフィールドの内容を示す警告ログメッセージが表示されます。以前は、これらの警告にはパスワードなどの機密情報が出力されていました。この更新により、vsphere および baremetal プラットフォームセクションの認証情報フィールドの警告メッセージが変更され、機密情報が記録されないようになりました。(OCPBUGS-8203)
  • 以前は、デフォルトのディスクサイズを検証できなかったため、ノードにカスタムディスクサイズが設定されていない限り、Azure Stack Hub 上のクラスターは新しいコントロールプレーンノードを作成できませんでした。この更新により、デフォルトのディスクサイズが 128 GB に設定され、インストールプログラムは、128 から 1023 GB までのユーザー指定のディスクサイズ値を適用します。(OCPBUGS-6759)
  • 以前は、インストーラーがプロビジョニングしたインフラストラクチャーを使用してベアメタルにインストールする場合、インストールプログラムは、ポート 80 を使用してベースボード管理コントローラー (BMC) とデプロイメントエージェントにイメージを提供していました。多くの種類の公共トラフィックではポート 80 が使用されるため、これによりセキュリティー上の懸念が生じる可能性があります。この更新では、インストールプログラムはこの目的でポート 6180 を使用します。(OCPBUGS-8509)
Machine Config Operator
  • 以前は、AWS にインストールされた OpenShift Container Platform クラスターは、スケールアップできない 4.1 ブートイメージを使用していました。この問題は、Ignition から設定され、新しいマシンの初回起動時に MCO によってレンダリングおよび起動される 2 つの systemd ユニットが、アプリケーション Afterburn に依存しているために発生しました。OpenShift Container Platform 4.1 ブートイメージには Afterburn が含まれていないため、この問題により新しいノードがクラスターに参加できませんでした。現在、systemd ユニットには、Afterburn の存在に依存しないフォールバックコードとともに、Afterburn の追加チェックが含まれています。(OCPBUGS-7559)
管理コンソール
  • 以前は、アラートはログなどの Prometheus 以外のデータソースから読み込まれていました。これにより、すべてのアラートのソースが常に Prometheus として表示されるようになりました。この更新により、アラートソースが正しく表示されるようになりました。(OCPBUGS-9907)
  • 以前は、Patternfly 4 には、マスターノードのログセクションでログコンポーネントを一度選択すると、それを選択または変更できないという問題がありました。この更新により、マスターノードのログセクションからログコンポーネントを変更した場合にページを更新すると、デフォルトのオプションが再ロードされるようになりました。(OCPBUGS-18727)
  • 以前は、alertmanager-main ページの Metrics タブでルートの詳細を表示すると、空のページが表示されていました。この更新により、ユーザー権限が更新され、Metrics タブでルートの詳細を表示できるようになりました。(OCPBUGS-15021)
  • 以前は、Red Hat OpenShift Service on AWS はカスタムブランディングを使用していましたが、ファビコンが表示されなくなるため、カスタムブランディングの使用中に特定のブランディングが表示されませんでした。この更新により、Red Hat OpenShift Service on AWS のブランディングが、Branding API の一部になりました。(OCPBUGS-14716)
  • 以前は、プロキシーが予期されている場合、OpenShift Container Platform Web コンソールはモニタリング Dashboard ページをレンダリングしませんでした。その結果、WebSocket 接続は失敗しました。この更新により、Web コンソールは環境変数からプロキシー設定も検出するようになりました。(OCPBUGS-14550)
  • 以前は、console.openshift.io/disable-operand delete: "true" および operator.openshift.io/uninstall-message: "some message" アノテーションが Operator CSV で使用されている場合、アンインストール手順が Web コンソールで表示されませんでした。この更新では、インストールをオプトアウトする手順が利用可能になりました。(OCPBUGS-13782)
  • 以前は、PersistentVolumeClaims namespace の Details ページのサイズが正しくありませんでした。この更新により、PersistentVolumeClaims namespace の 詳細 ページの Prometheus クエリーにnamespace ラベルが含まれ、サイズが正しくなりました。(OCPBUGS-13208)
  • 以前は、コンソールとダウンロードのルートをカスタマイズした後、ConsoleCLIDownloads リンク内のダウンロードルートが更新されず、デフォルトのダウンロードルートを指していました。この更新により、カスタムダウンロードルートが設定されると、ConsoleCLIDownloads リンクが更新されます。(OCPBUGS-12990)
  • 以前は、出力プレビューにはリストビューの不完全なトポロジー情報が表示されていました。この更新により、リソースが 1 ページを超える場合、リソースの完全なリストが出力されるようになりました。(OCPBUGS-11219)
  • 以前は、応答時間が長いサービスにプロキシーする動的プラグインは 30 秒でタイムアウトし、504 エラーメッセージが表示されました。この更新により、ほとんどのブラウザーの最大タイムアウトに一致するように、5 分間の HAProxy タイムアウトアノテーションがコンソールルートに追加されました。(OCPBUGS-9917)
  • 以前は、提供された API ページでは、提供された API の displayName が使用されていましたが、この値は常に設定されているわけではありませんでした。その結果、リストは空でしたが、すべてのインスタンスをクリックして、新しいインスタンスの YAML に引き続きアクセスすることができました。この更新により、displayName が設定されていない場合、リストにはテキストが表示されます。(OCPBUGS-8682)
  • 以前は、CronJobs テーブルと詳細ビューには suspend の指示がありませんでした。この更新により、spec.suspendCronJobs のリストと詳細ビューに追加されました。(OCPBUGS-8299)
  • 以前は、コンソール Operator の設定でシングルプラグインを有効にすると、再デプロイされたコンソールが失敗していました。この更新により、プラグインのリストが一意になり、Pod が期待どおりに実行されるようになりました。(OCPBUGS-5059)
  • 以前は、プラグインイメージをアップグレードした後も、古いプラグインファイルが引き続き要求されていました。この更新により、plugin-entry.js リソースが要求された際に、?cacheBuster=${getRandomChars()} クエリー文字列が追加されました。(OCPBUGS-3495)
モニタリング
  • この更新前は、node-exporter collected がネットワークインターフェイス情報を収集する方法が原因で、メトリクスのスクレイピング中に大量の CPU リソースが消費される可能性がありました。このリリースでは、ネットワークインターフェイス情報を収集する際の node-exporter のパフォーマンスを向上させることでこの問題を修正し、これにより、メトリクスのスクレイピング中の過剰な CPU 使用の問題を解決します。(OCPBUGS-12714)
  • この更新前は、Thanos Querier はノードのロールごとにメトリクスの重複を排除できませんでした。この問題はこの更新で修正され、Thanos Querier がノードのロールごとにメトリクスの重複を適切に排除できるようになりました。(OCPBUGS-12525)
  • この更新前は、node-exporterbtrfs コレクターが常に有効になっており、Red Hat Enterprise Linux (RHEL) が btrfs ストレージ形式をサポートしていないため、CPU 使用量が増加していました。この更新により、btrfs コレクターが無効になり、問題が解決されました。(OCPBUGS-11434)
  • この更新前は、cluster:capacity_cpu_cores:sum メトリックの場合、infra ロールを持つけれども master ロールは持たないノードには、label_node_role_kubernetes_io ラベルの infra 値が割り当てられませんでした。この更新により、master ロールではなく infra ロールを持つノードが、このメトリックに対して正しく infra としてラベル付けされるようになりました。(OCPBUGS-10387)
  • この更新前は、起動プローブがないため、Kubernetes API に多くのカスタムリソース定義がインストールされている場合、プログラムの初期化に liveness プローブで許可されている時間よりも長い時間がかかるため、Prometheus アダプター Pod は起動できませんでした。この更新により、Prometheus アダプター Pod は、失敗するまで 5 分間待機する起動プローブを使用して設定されるようになり、問題が解決されました。(OCPBUGS-7694)
  • node_exporter コレクターは、物理インターフェイスのみのネットワークインターフェイスメトリクスを収集することを目的としていますが、この更新前は、node-exporter コレクターはこれらのメトリクスを収集するときに、Calico 仮想ネットワークインターフェイスコントローラー (NIC) を除外しませんでした。この更新により、cali[a-f0-9]* 値が collector.netclass.ignored-devices リストに追加され、Calico 仮想 NIC のメトリクスが収集されないようになります。(OCPBUGS-7282)
  • このリリースでは、セキュリティー対策として、Thanos Querier の Cross Origin Resource Sharing (CORS) ヘッダーがデフォルトで無効になりました。引き続き CORS ヘッダーを使用する必要がある場合は、ThanosQuerierConfig リソースの enableCORS パラメーターの値を true に設定して、CORS ヘッダーを有効にできます。(OCPBUGS-11889)
ネットワーク
  • 以前は、クライアント相互 TLS (mTLS) が Ingress コントローラー上で設定されており、CA バンドル内の認証局 (CA) 証明書をダウンロードするために 1 MB を超える証明書失効リスト (CRL) を必要とする場合、サイズ制限のために CRL config map を更新できませんでした。CRL が欠落しているため、有効なクライアント証明書を使用した接続が、unknown ca エラーで拒否されていた可能性があります。

    この更新により、CRL は config map に配置されなくなり、ルーターは CRL を直接ダウンロードするようになりました。その結果、各 Ingress コントローラーの CRL config map は存在しなくなります。CRL が直接ダウンロードされるようになり、有効なクライアント証明書を使用した接続は拒否されなくなりました。(OCPBUGS-6661)

  • 以前は、OpenShift Container Platform の指定された 512 バイトのバッファーサイズを超える UDP 応答を提供する非準拠のアップストリーム DNS サーバーにより、CoreDNS がオーバーフローエラーをスローしていました。したがって、DNS クエリーに対する応答は提供されません。

    この更新により、ユーザーは dnses.operator.openshift.io カスタムリソース (CR) の protocolStrategy フィールドを TCP に設定できるようになりました。このフィールドを TCP に設定すると、CoreDNS はアップストリーム要求に TCP プロトコルを使用し、非準拠のアップストリーム DNS サーバーによる UDP オーバーフローの問題を回避します。(OCPBUGS-6829)

  • 以前は、クラスター管理者が NoExecute 効果を持つテイントを使用してインフラノードを設定した場合、Ingress Operator のカナリア Pod は、これらのインフラノードでスケジュールされませんでした。しばらくすると、DaemonSet 設定がオーバーライドされ、インフラノード上の Pod が終了しました。

    このリリースでは、Ingress Operator は、NoExecute 効果を指定する node-role.kubernetes.io/infra ノード taint を許容するように、カナリア DaemonSet を設定するようになりました。その結果、どのような効果が指定されているかに関係なく、カナリア Pod はインフラノード上でスケジュールされます。(OCPBUGS-9274)

  • 以前は、Ingress コントローラーでクライアント相互 TLS (mTLS) が設定されている場合、クライアント認証局 (CA) 証明書のいずれかに、別の CA によって発行された CRL の証明書失効リスト (CRL) 配布ポイントが含まれており、その CRL の有効期限が切れた場合、配布 CA と発行 CA の間の不一致により、間違った CRL がダウンロードされていました。その結果、CRL バンドルが更新されて、誤ってダウンロードされた CRL の余分なコピーが含まれることになり、更新する必要のある CRL がなくなっていました。CRL がないため、有効なクライアント証明書を使用した接続が、unknown ca というエラーで拒否される可能性がありました。

    この更新により、ダウンロードした CRL はそれらを配布元の CA によって追跡されるようになりました。CRL の有効期限が切れると、配布 CA の CRL 配布ポイントを使用して更新された CRL がダウンロードされます。その結果、有効なクライアント証明書は拒否されなくなりました。(OCPBUGS-9464)

  • 以前は、Gateway API が Red Hat OpenShift Service Mesh に対して有効になっている場合、Ingress Operator は設定に失敗し、the spec.techPreview.controlPlaneMode field is not supported in version 2.4+; use spec.mode というエラーを返していました。このリリースでは、ServiceMeshControlPlane カスタムリソース (CR) の Service Mesh spec.techPreview.controlPlaneMode API フィールドが、spec.mode に置き換えられました。その結果、Ingress Operator は ServiceMeshControlPlane カスタムリソースを作成でき、Gateway API は適切に動作します。(OCPBUGS-10714)
  • 以前は、Gateway API ゲートウェイの DNS を設定するときに、リスナーがクラスターのベースドメインの外部にあるドメインのホスト名を指定した場合でも、Ingress Operator はゲートウェイリスナーの DNS レコードを作成しようとしていました。その結果、Ingress Operator は DNS レコードを公開しようとして失敗し、failed to publish DNS record to zone というエラーを返しました。

    この更新により、ゲートウェイリスナーの DNSRecord カスタムリソース (CR) を作成するときに、ドメインがクラスターの基本ドメイン外にある場合、Ingress Operator は、DNSRecord’s DNS 管理ポリシーを Unmanaged に設定するようになりました。その結果、Ingress Operator はレコードの公開を試行しなくなり、failed to publish DNS record to zone というエラーのログも記録されなくなりました。(OCPBUGS-10875)

  • 以前は、oc explain route.spec.tls.insecureEdgeTerminationPolicy コマンドで、一部のユーザーを混乱させる可能性のある不正確なオプションが記載されていました。このリリースでは、API ドキュメントが更新され、insecureEdgeTerminationPolicy で使用できる正しいオプションが示されるようになりました。これは API ドキュメントの修正のみです。(OCPBUGS-11393)
  • 以前は、Cluster Network Operator コントローラーが必要以上に広範なリソースのセットを監視していたため、そのリコンサイラーがかなり頻繁にトリガーされていました。その結果、Cluster Network Operator と kube-apiserver の両方の負荷が増加しました。

    この更新により、Cluster Network Operator の allowlist コントローラーは、cni-sysctl-allowlist config map の変更を監視します。その結果、allowlist コントローラーのリコンサイラーは、config map が変更されたときにトリガーされるのではなく、cni-sysctl-allowlist config map または default-cni-sysctl-allowlist config map に変更が加えられた場合にのみトリガーされます。その結果、Cluster Network Operator API リクエストと config map リクエストが減少します。(OCPBUGS-11565)

  • HaProxy に関連した segfault 障害が解決されました。ユーザーはこれらのエラーを受信しなくなります。(OCPBUGS-11595)
  • 以前は、ユーザーがポート番号なしで EndpointSlice ポートを作成した場合、CoreDNS が予期せず終了していました。この更新により、CoreDNS が予期せず終了することを防ぐための検証が CoreDNS に追加されました。(OCPBUGS-19805)
  • 以前は、バックエンドサービスが 1 つしかない場合、OpenShift ルーターは重み 0 のルートにトラフィックを送信していました。この更新により、ルーターは重み 0 の単一バックエンドを持つルートにトラフィックを送信しなくなります。(OCPBUGS-16623)
  • 以前は、Ingress Operator は、ルートに spec.subdomain または spec.host パラメーターを指定せずに、カナリアルートを作成していました。通常、API サーバーはこれが原因で、デフォルトの Ingress コントローラーのドメインと一致するクラスターの Ingress ドメインを使用して、spec.host パラメーターのデフォルト値を設定していました。ただし、代替 Ingress ドメインを設定するために appsDomain オプションを使用してクラスターを設定した場合、ルートホストには代替ドメインが設定されます。さらに、カナリアルートを削除すると、デフォルトの Ingress コントローラーのドメインと一致しないドメインでルートが再作成されるため、カナリアチェックが失敗します。現在、Ingress コントローラーは、カナリアルートを作成するときに spec.subdomain パラメーターを指定します。appsDomain オプションを使用してクラスターを設定してからカナリアルートを削除しても、カナリアチェックは失敗しません。(OCPBUGS-16089)
  • 以前は、Ingress Operator は、Operator のステータスを更新するときに、パブリックホスト型ゾーンの DNS レコードのステータスをチェックしませんでした。これにより、パブリックホスト型ゾーンの DNS レコードにエラーがある可能性があると、Ingress Operator が DNS ステータスを Ready と報告していました。現在、Ingress Operator はパブリックとプライベートの両方のホスト型ゾーンのステータスをチェックするため、問題は解決されています。(OCPBUGS-15978)
  • 以前は、CoreDNS bufsize 設定は、512 バイトとして設定されていました。現在、OpenShift Container Platform CoreDNS のバッファーの最大サイズは 1232 バイトです。この変更により、DNS の切り捨てと再試行の発生が減り、DNS のパフォーマンスが向上します。(OCPBUGS-15605)
  • 以前は、Ingress Operator は、spec.template.spec.containers[].ports[].hostPort を指定せずに、ルーターデプロイメントで spec.template.spec.hostNetwork: true パラメーターを指定していました。これにより、API サーバーは各ポートの hostPort フィールドにデフォルト値を設定し、続いて Ingress Operator はこれを外部更新として検出し、元に戻そうとしました。現在は、Ingress Operator がこれらの更新を誤って実行することはなくなりました。(OCPBUGS-14995)
  • 以前は、起動時に DNS Operator には、cluster-dns-operator startup has an error message: [controller-runtime] log.SetLogger(…​) was never called, logs will not be displayed: というエラーメッセージが記録されていました。これは、ユーザーに誤解を与える可能性がありました。これで、起動時にエラーメッセージが表示されなくなりました。(OCPBUGS-14395)
  • 以前は、Ingress Operator は、NodePort および ClusterIP タイプのサービスに対して、spec.internalTrafficPolicyspec.ipFamilies、および spec.ipFamilyPolicy フィールドを未指定のままにしていました。続いて、API はこれらのフィールドにデフォルト値を設定し、Ingress Operator はこれを元に戻そうとします。この更新により、Ingress Operator は初期値を指定し、API のデフォルト値によって引き起こされるエラーを修正しました。(OCPBUGS-13190)
  • 以前は、Transmission Control Protocol (TCP) 接続はすべての DNS に対して負荷分散されていました。この更新により、TCP 接続は、ローカル DNS エンドポイントを優先するように有効化されました。(OCPBUGS-9985)
  • 以前は、Intel E810 NIC の場合、Pod が削除されたときに Virtual Function (VF) を使用して SR-IOV 上の MAC アドレスをリセットすると、障害が発生していました。これにより、SR-IOV VF を使用して Pod を作成するときに長い遅延が発生しました。この更新により、Container Network Interface (CNI) はこの問題を確実に修正するようになりました。(OCPBUGS-5892)
  • 以前は、OpenShift Container Platform で、一部の Pod が terminating 状態でスタックするという問題が確認されました。これにより、許可リストコントローラーの調整ループが影響を受け、不要な再試行が発生して複数の Pod が作成されました。この更新により、許可リストコントローラーは現在のデーモンセットに属する Pod のみを検査するようになります。その結果、1 つ以上の Pod の準備ができていないときに再試行は行われなくなります。(OCPBUGS-16019)
OpenShift CLI (oc)
  • 以前は、タグとダイジェストの両方を持つコンテナーイメージ参照は oc-mirror プラグインによって正しく解釈されず、次のエラーが発生していました。

    "localhost:6000/cp/cpd/postgresql:13.7@sha256" is not a valid image reference: invalid reference format

    この動作は修正され、参照が受け入れられ、正しくミラーリングされるようになりました。(OCPBUGS-11840)

  • 以前は、パスコンポーネントの数が予想される最大パスコンポーネントを超えた場合に、レジストリーに対して 401 - Unauthorized エラーが発生していました。この問題は、パスコンポーネントの数が最大パスコンポーネントを超えたときに oc-mirror が失敗するようにすることで、修正されています。整数値を受け入れる --max-nested-paths フラグを使用して、最大パスコンポーネントを設定できるようになりました。デフォルトでは、パスコンポーネントの最大数に制限はなく、0 に設定されています。生成された ImageContentSourcePolicy には、リポジトリーレベルまでのソースおよびミラー参照が含まれます。(OCPBUGS-8111OCPBUGS-11910OCPBUGS-11922)
  • 以前は、oc-mirror フラグの --short-v、および --verbose は、誤ったバージョン情報を提供していました。oc ミラー version フラグを使用して、oc-mirror の正しいバージョンを確認できるようになりました。oc-mirror フラグの --short-v、および --verbose は非推奨となり、サポートされなくなります。(OCPBUGS-7845)
  • 以前は、イメージの複数のダイジェストがタグなしで imageSetConfig に指定されていた場合、レジストリーからディスクへのミラーリングが失敗していました。oc-mirror は、デフォルトのタグ latest をイメージに追加します。この問題は、省略されたダイジェストをタグとして使用することで修正されました。(OCPBUGS-2633)
  • 以前は、oc-mirror が誤って Operator カタログを ImageContentSourcePolicy 仕様に追加していました。Operator カタログは CatalogSource リソースを通じて宛先レジストリーから直接使用されるため、これは予期しない動作です。このバグは、oc-mirror が Operator カタログを ImageContentSourcePolicy のエントリーとして追加しないようにすることで修正されました。(OCPBUGS-10051)
  • 以前は、レジストリードメイン名がイメージ参照の一部ではない場合、Operator のイメージのミラーリングは失敗していました。この修正により、レジストリーのドメイン名が指定されていない場合、イメージは docker.io からダウンロードされます。(OCPBUGS-10348)
  • 以前は、タグとダイジェストの両方がコンテナーイメージ参照に含まれている場合、oc-mirror がそれを誤って解釈し、invalid reference format エラーが発生していました。この問題は修正され、イメージは正常にミラーリングされます。(OCPBUGS-11840)
  • 以前は、名前が数字で始まる場合は、CatalogSource リソースを作成できませんでした。この修正により、デフォルトで、CatalogSource リソース名が cs- 接頭辞を付けて生成され、RFC 1035 に準拠するようになりました。(OCPBUGS-13332)
  • 以前は、registries.conf ファイルを使用する場合、一部のイメージがマッピングに含まれていませんでした。このバグ修正により、エラーなしでマッピングに含まれるイメージを確認できるようになりました。(OCPBUGS-13962)
  • 以前は、--oci-registries-config フラグで参照される registries.conf ファイル内の安全でないミラーを使用しているときに、oc-mirror がミラーレジストリーとの HTTPS 接続を確立しようとしました。この修正により、コマンドラインで --source-skip-tls または --source-use-http を指定することで、HTTPS 接続を使用しないように oc-mirror を設定できるようになりました。(OCPBUGS-14402)
  • 以前は、oc-mirror プラグインを使用して OCI インデックスをミラーリングしようとすると、イメージミラーリングが失敗していました。この修正により、oc-mirror プラグインを使用して OCI インデックスをミラーリングできるようになりました。(OCPBUGS-15329)
  • 以前は、低帯域幅ネットワーク上で複数の大規模なカタログをミラーリングすると、認証トークンの期限切れによりミラーリングが中断され、結果として HTTP 401 unauthorized エラーが発生していました。この問題は、各カタログのミラーリングプロセスを開始する前に、認証トークンを更新することで修正されました。(OCPBUGS-20137)
Operator Lifecycle Manager (OLM)
  • この更新前は、Operator Lifecycle Manager (OLM) は、API サーバーがビジー状態のときに、初期化エラーが原因でインストールに失敗する可能性がありました。この更新では、初期化エラーに対する 1 分間の再試行間隔を追加することで、問題が修正されています。(OCPBUGS-13128)
  • この更新前は、切断された環境でカスタムカタログがデフォルトの Red Hat カタログと同じ名前を使用すると、競合状態が発生しました。デフォルトの Red Hat カタログが無効になっていた場合、カタログは開始時に作成され、OperatorHub カスタムリソース (CR) が調整された後に削除されました。その結果、カスタムカタログはデフォルトの Red Hat カタログとともに削除されました。この更新により、カタログが削除される前に OperatorHub CR が調整され、競合状態が阻止されます。(OCPBUGS-9357)
  • この更新前は、一部の Operator のチャネルが OperatorHub にランダムな順序で表示されていました。この更新により、Operator チャネルが辞書式順序で表示されるようになりました。(OCPBUGS-7910)
  • この更新前は、所有者参照ファイルでコントローラーフラグが true に設定されていない場合、レジストリー Pod はオートスケーラーによって正常にドレインされませんでした。この更新により、コントローラーフラグが true に設定され、ドレイン中のノードで強制的なシャットダウンが必要なくなりました。(OCPBUGS-7431)
  • この更新前は、証明書の生成方法が原因で、collect-profiles Pod により CPU 使用率が定期的に急増していました。この更新により、証明書が毎日生成され、証明書の読み込みが最適化され、CPU 使用率が低下します。(OCPBUGS-1684)
OpenShift API サーバー
  • 以前は、projects リソースへの更新リクエストとパッチリクエストで、metadata.namespace フィールドが自動的に設定されていました。その結果、影響を受けるリクエストにより偽の検証エラーが生成される可能性がありました。このリリースでは、projects リソースが自動的に設定されなくなりました。(OCPBUGS-8232)
Red Hat Enterprise Linux CoreOS (RHCOS)
  • 以前は、論理ボリュームマネージャー (LVM) メタデータを使用してブロック永続ボリューム要求 (PVC) ストレージにアクセスする OpenShift Container Platform の Pod が終了時にスタックする可能性がありました。これは、同じ LVM デバイスがコンテナー内とホストの両方でアクティブになっていたためです。これは、仮想マシンに LVM を使用する OpenShift Virtualization を使用して、Pod 内で仮想マシンを実行する場合などに発生しました。この更新により、RHCOS はデフォルトで /etc/lvm/devices/system.devices ファイルにあるデバイスのセットアップとアクセスのみを試みます。これにより、仮想マシンゲスト内の LVM デバイスへの競合的なアクセスが阻止されます。(OCPBUGS-5223)
  • 以前は、Google Cloud Platform (GCP) Confidential Computing インスタンス上で Pod が ContainerCreating 状態のままになり、ボリュームマウントが失敗していました。この修正により、Google Cloud Platform の Confidential Computing インスタンスの Persistent Disk ストレージタイプへのサポートが追加され、OpenShift Container Platform で永続ボリュームとして使用できるようになりました。その結果、Pod は Running 状態になり、ボリュームをマウントできるようになりました。(OCPBUGS-7582)
Storage
  • 以前は、IBM Cloud® クラスターでクラスター全体のプロキシーが有効になっている場合、ボリュームのプロビジョニングに失敗しました。(OCPBUGS-18142)
  • Storage Operator オブジェクトの vsphereStorageDriver フィールドは、非推奨になりました。このフィールドは、OpenShift Container Platform 4.13 vSphere クラスターでの CSI 移行をオプトインするために使用されましたが、OpenShift Container Platform 4.14 以降のクラスターには影響しません。(OCPBUGS-13914)
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.