1.6. バグ修正
API サーバーと認証
-
以前は、アップストリームライブラリーの設定により、kube-apiserver ログフォルダー内の
termination.logに無効なパーミッションがありました。このリリースでは、アップストリームライブラリーが更新され、terminate.logに予期されたパーミッションが与えられるようになりました。(OCPBUGS-11856) - 以前は、アップグレード後に既存のマニフェストが機能アノテーションを取得した場合、Cluster Version Operator (CVO) によって機能が有効になりました。これにより、以前にコンソール機能を無効にしていたユーザーの場合、OpenShift Container Platform 4.14 にアップグレードした後にコンソールが有効化されます。このリリースでは、不要なコンソール機能が既存のマニフェストから削除され、コンソール機能は暗黙的に有効化されなくなりました。(OCPBUGS-20331)
-
以前は、
openshift-kube-controller-managernamespace が削除されると、failed to synchronize namespaceというエラーが繰り返しログに記録されていました。このリリースでは、openshift-kube-controller-managernamespace が削除される際に、エラーがログに記録されなくなりました。(OCPBUGS-17458)
ベアメタルハードウェアのプロビジョニング
- 以前は、デュアルスタック GitOps ZTP ハブから IPv6 専用ホストをデプロイすると、正しいコールバック URL がベースボード管理コントローラー (BMC) に渡されませんでした。その結果、IPv4 URL が無条件に渡されました。この問題は解決され、URL の IP バージョンは BMC アドレスの IP バージョンに依存するようになりました。(OCPBUGS-23759)
-
以前は、Bare Metal Operator (BMO) コンテナーには
60000として指定されたhostPortがありましたが、そのhostPortは仕様にもかかわらず実際には使用されていませんでした。その結果、他のサービスはポート 60000 を使用できなくなりました。この修正により、コンテナー設定からhostPort仕様が削除されます。これで、ポート 60000 が他のサービスで使用できるようになりました。(OCPBUGS-18788) -
以前は、Cluster Baremetal Operator (CBO) がインフラストラクチャーの
platformStatusフィールドをチェックすると失敗し、nilを返しました。OpenShift Container Platform 4.15 では、CBO が更新され、apiServerInternalIPsがnilを返した場合に確認して空の値を返すようになり、この問題は解決されました。(OCPBUGS-17589) 以前は、
inspector.ipxe設定ではIRONIC_IP変数が使用されていましたが、IPv6 アドレスには括弧が含まれていたため、考慮されていませんでした。その結果、ユーザーが誤ったboot_mac_addressを指定すると、iPXE はinspector.ipxe設定にフォールバックし、括弧が含まれていなかったため、不正な形式の IPv6 ホストヘッダーが提供されました。OpenShift Container Platform 4.15 では、
inspector.ipxe設定がIRONIC_URL_HOST変数を使用するように更新されました。これにより、IPv6 アドレスが考慮され、この問題は解決されました。(OCPBUGS-27060)- 以前は、Cisco UCS ハードウェアで RedFish 仮想メディアを使用して新しいベアメタルホストに OpenShift Container Platform をデプロイしようとするとバグがありました。このバグにより、Ironic が適切な仮想メディアデバイスを見つけることができなかったため、ベアメタルホストでの新しいプロビジョニングがブロックされました。今回の更新により、Ironic は利用可能なすべての仮想メディアデバイスでより多くのチェックを実行します。その結果、RedFish 仮想メディアを使用するときに Cisco UCS ハードウェアをプロビジョニングできるようになりました。(OCPBUGS-23105)
-
以前は、
secureBootフィールドがdisabledに設定されているノードに、bootModeフィールドをUEFISecureBootに設定して OpenShift Container Platform をインストールすると、インストールプログラムの起動に失敗していました。この更新により、Ironic が更新され、secureBootをenabledに設定して、OpenShift Container Platform をインストールできるようになりました。(OCPBUGS-9303)
ビルド
-
以前は、コンテナー間でコンテンツをコピーするときにタイムスタンプが保持されませんでした。このリリースでは、タイムスタンプを保存できるように
-pフラグがcpコマンドに追加されました。(OCPBUGS-22497)
クラウドコンピュート
-
以前は、
MachineSet仕様からのテイントの解析エラーにより、オートスケーラーは仕様に直接設定されたテイントを考慮できないことを意味していました。その結果、ゼロからスケーリングするためにMachineSetテイントに依存する場合、仕様からのテイントが考慮されず、スケーリングの決定が正しく行われない可能性がありました。この更新により、ゼロからのスケールロジック内の解析の問題が解決されました。その結果、オートスケーラーは正しくスケールアップし、ワークロードのスケジュールを妨げるテインとを特定できるようになりました。(OCPBUGS-27750) - 以前は、イメージ認証情報を提供していた Amazon Web Services (AWS) コードが、OpenShift Container Platform 4.14 の kubelet から削除されました。その結果、kubelet が自身を認証してコンテナーランタイムに認証情報を渡すことができなくなったため、指定されたプルシークレットがない場合、Amazon Elastic Container Registry (ECR) からのイメージのプルが失敗しました。この更新により、別の認証情報プロバイダーが設定され、kubelet に ECR 認証情報を提供するようになりました。その結果、kubelet は ECR からプライベートイメージをプルできるようになりました。(OCPBUGS-27486)
-
以前は、Hosted Control Plane (HCP) KubeVirt クラスターを
--node-selectorコマンドでデプロイするときに、ノードセレクターが HCP namespace 内のkubevirt-cloud-controller-managerPod に適用されませんでした。その結果、HCP Pod 全体を特定のノードに固定できなくなりました。今回の更新により、この問題は修正されました。(OCPBUGS-27071) -
以前は、Microsoft Azure ロードバランサーのデフォルトの仮想マシン (VM) タイプが
StandardからVMSSに変更されました。その結果、サービスタイプのロードバランサーは標準仮想マシンをロードバランサーに接続できませんでした。この更新では、OpenShift Container Platform デプロイメントとの互換性を維持するために、これらの変更を以前の設定に戻します。その結果、ロードバランサーのアタッチメントの一貫性が向上しました。(OCPBUGS-26210) -
以前は、
enable_port_securityフィールドがfalseに設定された追加ポートを持つ RHOSP ノード上のデプロイメントでは、LoadBalancerサービスを作成できませんでした。今回の更新で、この問題は解決されました。(OCPBUGS-22246) - 以前は、ワーカーノードの初回起動時に Nova メタデータサービスが利用できなかった場合、Red Hat OpenStack Platform (RHOSP) 上のワーカーノードの名前には、ドメインコンポーネントが付けられていました。OpenShift Container Platform は、ノード名が Nova インスタンスと同じであることを想定します。名前の不一致により、ノードの証明書要求が拒否され、ノードはクラスターに参加できませんでした。この更新により、ワーカーノードは最初の起動時にメタデータサービスを待機して無期限に再試行し、ノードの名前が正しいことを確認します。(OCPBUGS-22200)
- 以前は、クラスターオートスケーラーは、Container Storage Interface (CSI) ストレージを持つノードで使用するとクラッシュしました。この問題は本リリースで解決されています。(OCPBUGS-23096)
- 以前は、特定のプロキシー環境では、Amazon Web Services (AWS) メタデータサービスが初回起動時に存在せず、起動直後にしか利用できない場合がありました。kubelet のホスト名の取得ではこの遅延が考慮されておらず、その結果、有効なホスト名がないためノードは起動に失敗します。この更新により、ホスト名取得スクリプトは失敗した場合にしばらく再試行されるようになります。その結果、メタデータサービスへのアクセス不能は短期間は許容されます。(OCPBUGS-20369)
- OpenShift Container Platform バージョン 4.14 以降では、Microsoft Azure Stack Hub のインストールが失敗する原因となる既知の問題があります。4.14 以降にアップグレードされた Microsoft Azure Stack Hub クラスターでは、ノードがスケールアップまたはスケールダウンするときにロードバランサーの設定の問題が発生する可能性があります。この問題が解決されるまで、Microsoft Azure Stack Hub 環境での 4.14 のインストールまたは 4.14 へのアップグレードは推奨されません。(OCPBUGS-20213)
- 以前は、Cluster Autoscaler Operator の起動プロセス中のいくつかの条件によってロックが発生し、Operator が正常に起動して自身を使用可能にマークすることができませんでした。その結果、クラスターのパフォーマンスが低下しました。この問題は、このリリースで解決されました。(OCPBUGS-18954)
- 以前は、コントロールノードが 2 番目の内部インスタンスグループに追加されたときに、Google Cloud Platform XPN 内部クラスターのインストールを実行しようとすると失敗していました。このバグは修正されています。(OCPBUGS-5755)
- 以前は、終了ハンドラーは、ノードに終了のマークを付ける前に途中で終了していました。この状況は、コントローラーが終了信号を受信したタイミングに基づいて発生しました。このリリースでは、追加の終了チェックを導入することで、早期終了の可能性が考慮されています。(OCPBUGS-2117)
-
以前は、
Buildクラスター機能が有効になっていなかったため、クラスターバージョン Operator (CVO) はビルドインフォーマーの同期に失敗し、正常に起動しませんでした。このリリースでは、Build機能が有効になっていない場合でも CVO が正常に起動します。(OCPBUGS-22956)
Cloud Credential Operator
-
以前は、Cloud Credential Operator ユーティリティー (
ccoctl) がクラスターレベルでカスタム GCP ロールを作成していたため、各クラスターが許可されるカスタムロール数の割り当て制限に影響していました。GCP 削除ポリシーにより、削除されたカスタムロールが削除後何日間も割り当て制限に影響を与え続けていました。このリリースでは、作成されるカスタムロールの総数を減らすために、カスタムロールがクラスターレベルではなくプロジェクトレベルで追加されます。さらに、ccoctlユーティリティーがインストール中に作成する GCP リソースを削除するときに、カスタムロールをクリーンアップするオプションが利用できるようになりました。これらの変更により、許可されるカスタムロールの数がクォータ制限に達することを回避できます。(OCPBUGS-28850) -
以前は、
Buildクラスター機能が有効になっていなかったため、Cluster Version Operator (CVO) はビルドインフォーマーの同期に失敗し、正常に起動しませんでした。このリリースでは、Build機能が有効になっていない場合でも CVO が正常に起動します。(OCPBUGS-26510) -
以前は、Microsoft Azure バケットのデフォルト動作の変更により、
ccoctl azure createコマンドを実行して作成されたバケットは、パブリック Blob アクセスを許可できませんでした。このリリースでは、ccoctl azure createコマンドを実行して作成されたバケットは、パブリック Blob アクセスを許可するように明示的に設定されています。(OCPBUGS-22369) -
以前は、Azure Managed Identity ロールが Cloud Controller Manager サービスアカウントから省略されていました。その結果、Cloud Controller Manager は、プライベート公開方法を使用して既存の VNet にデプロイされた環境で、サービスタイプのロードバランサーを管理できませんでした。このリリースでは、欠落していたロールが Cloud Credential Operator ユーティリティー (
ccoctl) に追加され、プライベート公開を使用して既存の VNet に Azure Managed Identity をインストールできるようになりました。(OCPBUGS-21745) -
以前は、Cloud Credential Operator は、
kube-systemnamespace に保存されているルートシークレットvshpere-creds内の vCenter サーバー値の更新をサポートしていませんでした。その結果、この値を更新しようとすると、コンポーネントのシークレットが正しく同期されなかったため、古い値と新しい値の両方が存在することになりました。このリリースでは、Cloud Credential Operator が同期中にシークレットデータをリセットするため、vCenter サーバー値の更新がサポートされます。(OCPBUGS-20478) -
以前は、中国リージョンの DNS 接尾辞
.amazonaws.com.cnが、他のリージョンで使用されている接尾辞.amazonaws.comと異なるため、Cloud Credential Operator ユーティリティー (ccoctl) は中国リージョンで AWS Security Token Service (STS) リソースを作成できませんでした。このリリースでは、ccoctlは正しい DNS 接尾辞を検出し、それを使用して必要なリソースを作成できるようになりました。(OCPBUGS-13597)
Cluster Version Operator
- Cluster Version Operator (CVO) は、更新の推奨事項を継続的に取得し、現在のクラスターの状態に対して既知の条件付き更新のリスクを評価します。以前は、リスク評価に失敗すると、CVO が新しい更新推奨事項を取得できなくなりました。更新推奨サービスが適切に定義されていない更新リスクを処理したためにリスク評価が失敗した場合、この問題により、CVO が更新推奨サービスが改善されたリスク宣言を提供していることに気付かない可能性がありました。このリリースでは、CVO は、更新リスクが正常に評価されるかどうかに関係なく、更新推奨サービスのポーリングを継続します。(OCPBUGS-25949)
開発者コンソール
-
以前は、指定されたリソースの API バージョンが最近更新されたため、
BuildRunログは BuildRun の Logs タブに表示されませんでした。この更新により、TaskRunの Logs が、ビルド Operator の v1alpha1 バージョンと v1beta1 バージョンの両方の BuildRun の Logs タブに再度追加されました。(OCPBUGS-29283) - 以前は、ArtifactHub から以前にインストールされた Pipeline Builder の Task が選択されると、コンソール UI が失敗し、エラーページが表示されました。この更新により、コンソール UI はオプションのデータを期待しなくなり、コンソール UI が失敗することもなくなりました。(OCPBUGS-24001)
- 以前は、Shipwright プラグインの Actions メニューの Edit Build と BuildRun オプションでは、YAML タブで編集できませんでした。今回の更新により、YAML タブで編集できるようになりました。(OCPBUGS-23164)
-
以前は、コンソールはリポジトリー内のファイル名
Dockerfileのみを検索して、Import Flows のContainerストラテジーに適したリポジトリーを特定していました。他のコンテナー化ツールが利用できるため、Containerfileファイル名のサポートがContainerストラテジーに適したものになりました。(OCPBUGS-22976) - 以前は、権限のないユーザーがパスとクエリーパラメーターを含むコンソールへのリンクを開き、ログインページにリダイレクトされた場合、ログインの成功後にクエリーパラメーターは復元されませんでした。その結果、ユーザーは検索を復元するか、コンソールへのリンクを再度クリックする必要がありました。今回の更新により、最新バージョンではパスと同様のクエリーパラメーターが保存および復元されます。(OCPBUGS-22199)
-
以前は、Add または Topology ビューから Create Channel ページに移動すると、デフォルト名として
Channelが表示されましたが、Create ボタンは無効になり、名前フィールドの下にRequiredと表示されました。今回の更新により、デフォルトのチャンネル名が追加された場合、Create ボタンをクリックしたときにRequiredメッセージが表示されなくなります。(OCPBUGS-19783) - 以前は、クイック検索機能を使用するときに同様のオプションを選択できました。この更新により、Source-to-image オプションは、Topology クイック検索の Samples オプションと区別されます。(OCPBUGS-18371)
-
以前は、{serverless-product-name} Operator がインストールされていて、Knative (Kn) サービングインスタンスが作成されていない場合、Administration
Cluster Settings から Global configuration ページに移動し、Knative-serving をクリックすると、 404 page not foundエラーが表示されていました。この更新により、Knative-serving を Global configuration に追加する前に、Knative サービングインスタンスが作成されたか判断するためのチェックが行われるようになりました。(OCPBUGS-18267) - 以前は、Edit Knative Service フォームに問題があり、ユーザーは以前に作成した Knative サービスを編集できませんでした。この更新により、以前に作成された Knative サービスを編集できるようになりました。(OCPBUGS-6513)
etcd Cluster Operator
-
以前は、
cluster-backup.shスクリプトはetcdctlバイナリーをローカルマシンに無期限にキャッシュし、更新を不可能にしていました。この更新により、cluster-backup.shスクリプトは実行されるたびに最新のetcdctlバイナリーをプルします。(OCPBUGS-19052)
Hosted Control Plane
-
以前は、ホストされたクラスターでカスタムの Container Network Interface (CNI) プラグインを使用する場合、ロールベースのアクセス制御 (RBAC) ルールは、
hostedcluster.spec.networking.networkTypeフィールドをCalicoに設定した場合にのみ、設定されていました。hostedcluster.spec.networking.networkTypeフィールドをOtherに設定した場合、ロールベースのアクセス制御 (RBAC) ルールが設定されませんでした。このリリースでは、hostedcluster.spec.networking.networkTypeフィールドをOtherに設定すると、RBAC ルールが適切に設定されます。(OCPBUGS-28235) -
以前は、
kube-apiserverリソースのipFamilyPolicyフィールドがSingleStackに設定されていたため、ノードポートが適切に公開されませんでした。この更新により、ipFamilyPolicyがPreferredDualStackに設定されている場合、ノードポートは適切に公開されます。(OCPBUGS-23350) -
以前は、ホストされたクラスターの Open Virtual Network (OVN) を設定した後、
cloud-network-config-controller、multus-admission-controller、および `ovnkube-control-plane` リソースにhypershift.openshift.io/hosted-control-plane:{hostedcluster resource namespace}-{cluster-name}ラベルがありませんでした。この更新により、ホストされたクラスターの Open Virtual Network (OVN) を設定した後、cloud-network-config-controller、multus-admission-controller、および `ovnkube-control-plane` リソースにhypershift.openshift.io/hosted-control-plane:{hostedcluster resource namespace}-{cluster-name}ラベルが含まれるようになりました。(OCPBUGS-19370) -
以前は、ホストされたクラスターを作成した後、config map を作成するために
user-ca-bundle以外の名前を使用すると、Control Plane Operator (CPO) のデプロイメントが失敗していました。この更新により、一意の名前を使用して config map を作成できるようになりました。CPO は正常にデプロイされるようになりました。(OCPBUGS-19419) -
以前は、
.status.controlPlaneEndpoint.port: 443を持つホストされたクラスターは、誤ってパブリックルーターとプライベートルーターにポート 6443 を公開していました。この更新により、.status.controlPlaneEndpoint.port: 443を持つホストされたクラスターは、ポート 443 のみを公開します。(OCPBUGS-20161) -
以前は、Kube API サーバーが IPv4 および IPv6 を使用して公開され、IP アドレスが
HostedClusterリソースに設定されている場合は、IPv6 環境は正しく動作しませんでした。この更新により、Kube API サーバーが IPv4 および IPv6 を使用して公開される場合、IPv6 環境が適切に動作するようになりました。(OCPBUGS-20246) - 以前は、コンソール Operator と Ingress Pod が同じノード上にある場合、コンソール Operator は失敗し、コンソールクラスター Operator を使用不可としてマークしていました。このリリースでは、コンソール Operator と Ingress Pod が同じノード上に配置されている場合、コンソール Operator が失敗しなくなりました。(OCPBUGS-23300)
- 以前は、ホストされたクラスターのアンインストールがスタックした場合、Control Plane Operator (CPO) のステータスが誤って報告されていました。この更新により、CPO のステータスが正しく報告されるようになりました。(OCPBUGS-26412)
- 以前は、初期アップグレードの進行中に OpenShift Container Platform のバージョンをオーバーライドしようとすると、ホストされたクラスターのアップグレードが失敗していました。この更新により、現在のアップグレードを新しい OpenShift Container Platform バージョンでオーバーライドすると、アップグレードが正常に完了します。(OCPBUGS-18122)
- 以前は、Hosted Control Plane のプルシークレットを更新しても、ワーカーノードにすぐには反映されませんでした。この更新により、プルシークレットを変更すると、調整がトリガーされ、ワーカーノードが新しいプルシークレットですぐに更新されます。(OCPBUGS-19834)
- 以前は、Hypershift Operator は、存在しなくなったノードプールの時系列を報告していました。このリリースでは、Hypershift Operator はノードプールの時系列を正しく報告します。(OCPBUGS-20179)
-
以前は、
--enable-uwm-telemetry-remote-writeフラグがデフォルトで有効でした。この設定により、テレメトリー調整がブロックされました。この更新により、--enable-uwm-telemetry-remote-writeフラグを無効にして、テレメトリー調整を可能にすることができます。(OCPBUGS-26410) -
以前は、追加の許可プリンシパルとして IAM ロールパス ARN が指定された場合 (
arn:aws:iam::${ACCOUNT_ID}:role/${PATH}/name)、Control Plane Operator (CPO) は VPC エンドポイントサービスの更新に失敗しました。この更新により、CPO はarn:aws:iam::${ACCOUNT_ID}:role/${PATH}/nameが許可されたプリンシパルを使用して VPC エンドポイントサービスを正常に更新します。(OCPBUGS-23511) -
以前は、OAuth テンプレートをカスタマイズするために
HostedCluster.spec.configuration.oauthフィールドを設定した場合、この設定はホストされたクラスターに反映されませんでした。この更新により、ホストされたクラスターのHostedCluster.spec.configuration.oauthフィールドを正常に設定できるようになります。(OCPBUGS-15215) -
以前は、デュアルスタックネットワークを使用してホストされたクラスターをデプロイする場合、デフォルトで、
clusterIPフィールドが IPv4 ネットワークではなく IPv6 ネットワークに設定されていました。この更新により、デュアルスタックネットワークを使用してホストされたクラスターをデプロイする場合、clusterIPフィールドはデフォルトで IPv4 ネットワークに設定されます。(OCPBUGS-16189) -
以前は、ホストされたクラスターをデプロイするときに、
HostedClusterリソースのadvertiseAddressフィールドを設定すると、ホストされたクラスターのデプロイメントが失敗していました。このリリースでは、HostedClusterリソースのadvertiseAddressフィールドを設定した後、ホストされたクラスターを正常にデプロイできます。(OCPBUGS-19746) -
以前は、ホストされたクラスターで
hostedcluster.spec.networking.networkTypeフィールドをCalicoに設定すると、Cluster Network Operator には、network-node-identityリソースをデプロイするための十分なロールベースのアクセス制御 (RBAC) 権限がありませんでした。この更新により、network-node-identityリソースが正常にデプロイされます。(OCPBUGS-23083) - 以前は、ホストされたクラスターの監査ログのデフォルト設定を更新できませんでした。したがって、ホストされたクラスターのコンポーネントは監査ログを生成できませんでした。この更新により、デフォルト設定を更新することで、ホストされたクラスターのコンポーネントの監査ログを生成できるようになります。(OCPBUGS-13348)
Image Registry
- 以前は、Image Registry プルーナーは、OpenShift API サーバーによって管理されるクラスターロールに依存していました。これにより、アップグレード中にプルーナージョブが断続的に失敗する可能性があります。現在、Image Registry Operator はプルーナークラスターロールを作成するロールを担っており、これにより問題が解決されます。(OCPBUGS-18969)
-
Image Registry Operator は、アクセスキーの取得の一環として、ストレージアカウントリストエンドポイントへの API 呼び出しを行います。複数の OpenShift Container Platform クラスターを含むプロジェクトでは、これにより API 制限に達する可能性があります。その結果、新しいクラスターを作成しようとすると
429エラーが返されました。この更新により、呼び出し間の時間が 5 分から 20 分に延長され、API 制限に達しなくなります。(OCPBUGS-18469) - 以前は、QPS とバーストのデフォルト設定が低いため、API サーバー要求が適切な時間内に返されなかった場合、Image Registry がゲートウェイタイムアウトエラーを返していました。この問題を解決するために、ユーザーは Image Registry を再起動する必要がありました。この更新により、QPS とバーストがデフォルトで高く設定され、この問題は発生しなくなります。(OCPBUGS-18999)
-
以前は、Cluster Image Registry Operator のデプロイメントリソースを作成するとき、エラー処理では最初に値が
nilか確認せずにポインター変数が使用されていました。その結果、ポインター値がnilの場合、パニックがログに報告されました。この更新により、nil チェックが追加され、パニックがログに報告されなくなりました。(OCPBUGS-18103) 以前の OpenShift Container Platform 4.14 リリースでは、OpenShift Container Platform バージョン 4.13 から 4.14 に更新するときにイメージが失われたという認識をユーザーに与える変更が導入されました。デフォルトの内部レジストリーを変更したことが原因で、Microsoft Azure オブジェクトストレージの使用時にレジストリーが誤ったパスを使用していました。このリリースでは、正しいパスが使用され、間違ったストレージパスを使用していたレジストリーにプッシュされた Blob を正しいストレージパスに移動するレジストリー Operator にジョブが追加されました。これにより、2 つの異なるストレージパスが 1 つのパスに効果的にマージされます。
注記この修正は、Azure Stack Hub (ASH) では 機能しません。4.14.14 以降にアップグレードする際に OCP バージョン 4.14.0 - 4.14.13 を使用していた ASH ユーザーは、手動手順を実行して Blob を正しいストレージパスに移動する必要があります。
インストーラー
- 以前は、AWS へのクラスターのインストールが検証エラーにより失敗する場合がありました。この更新により、インストールプログラムは、マシン config Operator を満足させるために必要なクラウド設定オブジェクトを生成します。これにより、インストールは成功します。(OCPBUGS-12707)
- 以前は、認証のために仮想マシンにアタッチされたサービスアカウントを使用して GCP にクラスターをインストールすると、内部データ検証のバグが原因で失敗することがありました。このリリースでは、仮想マシンにアタッチされたサービスアカウントを使用する際に、認証パラメーターを正しく検証するようにインストールプログラムが更新されました。(OCPBUGS-19376)
- 以前は、vSphere 接続設定インターフェイスの "vCenter cluster" フィールドに、クラスター名の代わりにネットワーク名が表示されていました。この更新により、"vCenter cluster" フィールドが更新され、クラスター名が表示されるようになりました。(OCPBUGS-23347)
-
以前は、
credentialsModeパラメーターがManualに設定されていない状態で認証し、gcloud cliツールを使用すると、インストールプログラムはosServiceAccount.jsonファイルから Google Cloud Platform (GCP) 認証情報を取得していました。この操作は、GCP クラスターのインストールが失敗する原因となっていました。現在は、検証チェックによってinstall-config.yamlファイルがスキャンされ、credentialsModeをManualに設定しなかった場合はメッセージが表示されます。Manualモードでは、マニフェストを編集して認証情報を指定する必要があることに注意してください。(OCPBUGS-17757) - 以前は、インストーラーでプロビジョニングされるインフラストラクチャーを使用して OpenShift Container Platform を VMware vSphere にインストールしようとすると、リソースプールオブジェクトに二重バックスラッシュが含まれていました。この形式により、インストールプログラムはネットワークリソースへの誤ったパスを生成し、インストール操作が失敗する原因となりました。インストールプログラムがこのリソースプールオブジェクトを処理した後、プログラムは "network not found" というエラーメッセージを出力しました。インストールプログラムは現在、InventoryPath とネットワーク名を結合する目的でクラスターオブジェクトを取得し、プログラムがリソースプールオブジェクトへの正しいパスを指定できるようにします。(OCPBUGS-23376)
- 以前は、Azure Red Hat OpenShift クラスターをインストールした後、一部のクラスター Operator が使用できなくなりました。これは、クラスターのロードバランサーの 1 つがインストールプロセスの一部として作成されなかったことが原因でした。この更新により、ロードバランサーが正しく作成されるようになりました。クラスターをインストールすると、すべてのクラスター Operator が使用可能になります。(OCPBUGS-24191)
- 以前は、VMware vSphere クラスターにオフラインの ESXi ホストが含まれている場合、"panic: runtime error: invalid memory address or nil pointer dereference" というメッセージが表示されてインストールが失敗していました。この更新により、ESXi ホストが利用できないというエラーメッセージが表示されます。(OCPBUGS-20350)
-
以前は、AWS にクラスターをインストールするときにデフォルトのマシン設定のみを使用して既存の AWS セキュリティーグループを指定した場合 (
platform.aws.defaultMachinePlatform.additonalSecurityGroupsIDs)、セキュリティーグループはコントロールプレーンマシンに適用されませんでした。この更新により、既存の AWS セキュリティーグループがデフォルトのマシン設定を使用して指定される場合、コントロールプレーンに正しく適用されるようになりました。(OCPBUGS-20525) -
以前は、指定されたマシンインスタンスタイプ (
platform.aws.type) が、コントロールプレーンまたはコンピュートマシン (controlPlane.architectureおよびcompute.architecture) に指定されたマシンアーキテクチャーをサポートしていない場合、AWS へのクラスターのインストールは失敗していました。今回の更新により、インストールプログラムは、マシンインスタンスタイプが指定されたアーキテクチャーをサポートしているか確認し、サポートしていない場合はエラーメッセージを表示するようになりました。(OCPBUGS-26051) 以前は、インストールプログラムはクラスターをインストールする前に一部の設定を検証しませんでした。この現象は、これらの設定がデフォルトのマシン設定 (
platform.azure.defaultMachinePlatform) でのみ指定されている場合に発生しました。その結果、次の条件が満たされた場合でもインストールは成功します。- サポート対象外のマシンインスタンスタイプが指定された場合
- 高速ネットワークや Azure Ultra ディスクの使用などの追加機能が、指定されたマシンインスタンスタイプでサポートされていない場合
この修正により、インストールプログラムは、サポート対象外の設定を示すエラーメッセージを表示するようになりました。(OCPBUGS-20364)
- 以前は、AWS クラスターを Secret Commercial Cloud Services (SC2S) リージョンにインストールし、既存の AWS セキュリティーグループを指定すると、そのリージョンではこの機能を利用できないことを示すエラーが表示され、インストールが失敗していました。この修正により、インストールは成功します。(OCPBUGS-18830)
-
以前は、Amazon Web Services (AWS) にクラスターをインストールするために
install-config.yaml設定ファイルのkmsKeyARNセクションで Key Management Service (KMS) 暗号鍵を指定すると、クラスターのインストール操作中に権限ロールが追加されませんでした。この更新により、設定ファイルで鍵を指定すると追加の鍵セットがクラスターに追加され、クラスターが正常にインストールされるようになりました。設定ファイルでcredentialsModeパラメーターを指定すると、すべての KMS 暗号鍵が無視されます。(OCPBUGS-13664) - 以前は、Oracle® Cloud Infrastructure (OCI) でのエージェントベースのインストールでは、インストールの進行状況をユーザーに表示するコンソールが表示されず、インストールの進行状況を追跡することがより困難でした。この更新により、OCI でのエージェントベースのインストールでは、インストールの進行状況がコンソールに表示されるようになりました。(OCPBUGS-19092)
-
以前は、静的ネットワークがエージェントベースのインストーラーの
install-config.yamlまたはagent-config.yamlファイルで定義されており、インターフェイス名の長さが 15 文字を超えている場合、ネットワークマネージャーはインターフェイスの起動を許可しませんでした。この更新により、15 文字を超えるインターフェイス名が切り捨てられ、インストールを続行できるようになりました。(OCPBUGS-18552) -
以前は、ユーザーが
agent-config.yamlファイルでrendezevousIPフィールドを指定せず、ホストが静的ネットワーク設定と同じファイルで定義されていた場合、最初のホストはそのロールに関係なく、ランデブーノードとして指定されていました。これにより、インストールが失敗していました。この更新により、エージェントベースのインストーラーは、masterロールと静的 IP が定義されているホストを最初に検索することにより、ランデブーノードの検索に優先順位を付けます。何も見つからない場合は、ロールが定義されていないホストを通じて潜在的な候補が検索されます。workerロールが明示的に設定されている静的なネットワーク設定を持つホストは無視されます。(OCPBUGS-5471) 以前は、すべてのエージェントベースのインストールの起動プロセス中にエージェントコンソールアプリケーションが表示され、インストールを続行する前にネットワークのカスタマイズが可能でした。クラウドのインストール中にネットワーク設定が必要なことはほとんどないため、これにより、Oracle® Cloud Infrastructure (OCI) でのインストールが不必要に遅くなっていました。
今回の更新により、OCI でのエージェントベースのインストールではエージェントコンソールアプリケーションが表示されなくなり、より迅速にインストールできるようになりました。(OCPBUGS-19093)
-
以前は、プラットフォームが
externalと定義されていた場合、エージェントベースのインストーラーはデフォルトで外部 Cloud Controller Manager (CCM) を有効にしていました。これにより、ユーザーは、外部 CCM を必要としないクラウドプラットフォーム上でインストールを実行するときに、外部 CCM を無効化できませんでした。この更新により、ユーザーは、Oracle® Cloud Infrastructure (OCI) でエージェントベースのインストールを実行する場合にのみ、外部 CCM を有効にする必要があります。(OCPBUGS-18455) -
以前は、
agent wait-forコマンドは.openshift_install.logファイルにログを記録できませんでした。この更新により、agent wait-forコマンドを使用すると、ログが.openshift_install.logファイルに記録されます。(OCPBUGS-5728) 以前は、ブートストラップノードの再起動後にブートストラップマシン上の
assisted-serviceが利用できなくなり、assisted-installer-controllerからの通信が妨げられていました。これにより、assisted-installer-controllerがワーカーノードから初期化されていないテイントを削除できなくなり、クラスターインストールがクラスター Operator の待機中にハングする原因となりました。この更新により、
assisted-serviceが利用できなくなった場合でも、assisted-installer-controllerは初期化されていないテインとを削除でき、インストールを続行できるようになります。(OCPBUGS-20049)-
以前は、エージェントベースのインストーラーで使用される
AgentClusterInstallクラスターマニフェストでは、プラットフォームタイプを誤って小文字にする必要がありました。この更新により、大文字と小文字が混在した値が必要になりますが、元の小文字の値が受け入れられ、正しく変換されるようになりました。(OCPBUGS-19444) -
以前は、アプリケーションセレクターの名前が間違っていたため、
manila-csi-driver-controller-metricsサービスには空のエンドポイントがありました。このリリースでは、アプリケーションセレクター名がopenstack-manila-csiに変更され、問題は修正されました。(OCPBUGS-9331) -
以前は、Assisted Installer によってすべての vSphere ノードの初期化されていないテイントが削除され、これにより、vSphere CCM はノードを適切に初期化できませんでした。これにより、ノードのプロバイダー ID が欠落し、最初のクラスターのインストール中に vSphere CSI Operator の機能が低下しました。このリリースでは、Assisted Installer は、vSphere 認証情報が
install-config.yamlに提供されていたか確認します。認証情報が指定され、OpenShift バージョンが 4.15 以上で、エージェントインストーラーが使用された場合、Assisted-Installer および Assisted-Installer-Controller は初期化されていないテインとを削除しません。これは、ノードのプロバイダー ID と仮想マシンの UUID が適切に設定され、vSphere CSI Operator がインストールされていることを意味します。(OCPBUGS-29485)
Kubernetes コントローラーマネージャー
-
以前は、
maxSurgeフィールドがデーモンセットに設定され、容認値が更新されると、Pod のスケールダウンに失敗し、スケジューリングに別のノードセットが使用されるためにロールアウトが失敗していました。このリリースでは、スケジュールの制約が満たされない場合にノードが適切に除外され、ロールアウトは正常に完了できます。(OCPBUGS-19452)
Machine Config Operator
-
以前は、環境変数のスペルが間違っていると、スクリプトは
node.envファイルの存在を検出できませんでした。これにより、node.envファイルの内容がブートのたびに上書きされ、kubelet ホスト名を変更できなくなりました。この更新により、環境変数のスペルが修正され、node.envファイルへの編集内容が再起動後も保持されます。(OCPBUGS-27307) - 以前は、Machine Config Operator により、新しいマシン config をトリガーすることなく、ユーザー指定の認証局の更新を行うことができました。これらの更新の新しい書き込みメソッドには改行文字が欠けていたため、ディスク上の CA ファイルの内容に対して検証エラーが発生し、Machine Config Daemon の機能が低下しました。このリリースでは、CA ファイルの内容が修正され、更新が想定どおりに行われます。(OCPBUGS-25424)
-
以前は、Machine Config Operator では、中断を防ぐために、マシン config を必要とせずに、ユーザー指定の認証局バンドルの変更をクラスターに適用できました。このため、
user-caバンドルはクラスター上で実行されているアプリケーションに伝播されず、変更の適用を確認するには再起動が必要でした。この更新により、MCO はupdate-ca-trustコマンドを実行し、CRI-O サービスを再起動して、新しい CA が適切に適用されるようになりました。(OCPBUGS-24035) - 以前は、Machine Config Operator が Image Registry 証明書を処理するために使用する初期メカニズムは、既存の config map にパッチを適用するのではなく、削除して新しい config map を作成していました。これにより、MCO からの API 使用量が大幅に増加しました。今回の更新では、代わりに JSON パッチを使用するようにメカニズムが更新され、問題が解決されました。(OCPBUGS-18800)
-
以前は、Machine Config Operator は、
baremetalRuntimeCfgImageコンテナーイメージを複数回プルしていました。1 回目はノードの詳細を取得するため、2 回目以降はイメージが利用可能であることを確認するためでした。これにより、ミラーサーバーまたは Quay が利用できない状況で証明書のローテーション中に問題が発生し、その後のイメージのプルが失敗していました。ただし、最初のイメージのプルによりイメージがすでにノード上にある場合は、それに関係なくノードは kubelet を開始する必要があります。この更新により、baremetalRuntimeCfgImageイメージが 1 回だけプルされるようになり、問題が解決されました。(OCPBUGS-18772) -
以前は、一部のネットワーク環境での OpenShift Container Platform の更新中に、
nmstatectlコマンドは正しい永続 MAC アドレスを取得できませんでした。これにより、インターフェイスの名前が変更され、更新中にノード上のボンディング接続が切断されました。このリリースでは、名前の変更を防ぐためにnmstateパッケージと MCO にパッチが適用され、更新は期待どおりに行われます。(OCPBUGS-17877) -
以前は、Machine Config Operator が Image Registry 証明書のデフォルトのプロバイダーとなり、
node-caデーモンは削除されました。これにより、HyperShift Operator で問題が発生しました。node-caデーモンを削除すると、HyperShift が Ignition 設定を取得してブートストラッププロセスを開始するために使用する Machine Config Server (MCS) 内のイメージレジストリーパスも削除されたためです。この更新により、MCS イメージレジストリーデータを含むフラグが提供され、Ignition がブートストラッププロセス中に使用できるようになり、問題が解決されました。(OCPBUGS-17811) 以前の古い RHCOS ブートイメージには、ブート時にサービス間の競合状態が含まれており、これによりノードはイメージをプルする前に
rhcos-growpartコマンドを実行できず、ノードの起動が阻止されていました。これにより、ディスクに空き領域が残っていないと判断され、古いブートイメージを使用するクラスターでノードのスケーリングが失敗することがありました。この更新では、ノードが正しく起動できるようにサービスの順序をより厳密にするためのプロセスが Machine Config Operator に追加されました。注記このような状況では、新しいブートイメージに更新すると、同様の問題の発生を防ぐことができます。
-
以前は、Machine Config Operator (MCO) は
oc image extractコマンドを利用して更新中にイメージをプルしていましたが、ImageContentSourcePolicy(ICSP) オブジェクトはそれらのイメージのプル時に尊重されませんでした。今回の更新により、MCO は内部でpodman pullコマンドを使用するようになり、ICSP で設定された場所からイメージがプルされるようになりました。(OCPBUGS-13044)
管理コンソール
-
以前は、Expand PVC モーダルは、既存の PVC にユニットを含む
spec.resources.requests.storage値があると想定していました。その結果、Expand PVC モーダルを使用して、ユニットなしでrequest.storage値を持つ PVC を拡張すると、コンソールはモーダルに誤った値を表示していました。この更新により、ユニットの有無にかかわらず、ストレージ値を処理できるようにコンソールが更新されました。(OCPBUGS-27909) - 以前は、ファイルがバイナリーか判断するコンソールチェックは十分に堅牢ではありませんでした。その結果、XML ファイルがバイナリーとして誤って認識され、コンソールに表示されませんでした。今回の更新により、ファイルがバイナリーかをより正確に確認するためのチェックが追加されました。(OCPBUGS-26591)
-
以前は、
spec.unhealthyConditionsのないMachineHealthCheckがクラスター上に存在する場合、Node Overview ページのレンダリングに失敗していました。この更新により、Node Overview ページが更新され、spec.unhealthyConditionsなしでMachineHealthCheckができるようになりました。今後は、spec.unhealthyConditionsのないMachineHealthCheckがクラスター上に存在する場合でも、Node Overview ページがレンダリングされるようになりました。(OCPBUGS-25140) - 以前は、コンソールはアラート通知レシーバーの最新のマッチャーキーを使用した最新状態ではなく、コンソールによって作成されたアラートマネージャーレシーバーは、古い一致キーを使用していました。この更新により、コンソールは代わりにマッチャーを使用し、既存のアラートマネージャーレシーバーを変更するときに既存の一致インスタンスをマッチャーに変換します。(OCPBUGS-23248)
- 以前は、偽装アクセスが誤って適用されていました。この更新により、コンソールは偽装アクセスを正しく適用します。(OCPBUGS-23125)
- 以前は、Advanced Cluster Management for Kubernetes (ACM) および Multicluster Engine for Kubernetes (MCE) Operators がインストールされ、それらのプラグインが有効になっている場合、YAML コード の Monaco Editor の読み込みに失敗していました。この更新では、リソース呼び出しの失敗を防ぐためにオプションのリソースチェーンが追加され、ACM Operator および MCE Operator がインストールされ、それらのプラグインが有効化されている場合に、YAML エディターは読み込みに失敗することがなくなりました。(OCPBUGS-22778)
モニタリング
- 以前は、クラスターで IPv6 が無効になっている場合、monitoring-plugin コンポーネントは起動しませんでした。このリリースでは、クラスター内で次のインターネットプロトコル設定 (IPv4 のみ、IPv6 のみ、および IPv4 と IPv6 の両方を同時に) をサポートするようにコンポーネントが更新されます。この変更により問題は解決され、クラスターが IPv6 のみをサポートするように設定されている場合に、monitoring-plugin コンポーネントが起動するようになりました。(OCPBUGS-21610)
-
以前は、コアプラットフォームモニタリングおよびユーザー定義プロジェクト用の Alertmanager のインスタンスが、アップグレード中に誤ってピアリングされる可能性がありました。この問題は、複数の Alertmanager インスタンスが同じクラスターにデプロイされている場合に発生する可能性があります。このリリースでは、クラスターを対象としていないトラフィックをブロックするのに役立つ
--cluster.labelフラグを Alertmanager に追加することで問題が修正されています。(OCPBUGS-18707) -
以前は、Alertmanager 設定でテキストのみのメールテンプレートを使用してテキストのみのメールアラートを送信することはできませんでした。この更新により、メール受信者の
htmlフィールドを空の文字列に設定することで、テキストのみのメールアラートを送信するように Alertmanager を設定できるようになりました。(OCPBUGS-11713)
ネットワーク
-
以前は、空の仕様で IngressController を作成すると、IngressController のステータスが
Invalidと表示されていました。ただし、route_controller_metrics_routes_per_shardメトリクスは引き続き作成されます。無効な IngressController が削除された場合、route_controller_metrics_routes_per_shardメトリクスはクリアされず、そのメトリクスの情報が表示されます。今回の更新により、許可された IngressController に対してのみメトリクスが作成されるようになり、この問題は解決されました。(OCPBUGS-3541) - 以前は、Go プログラミング言語が解析できるタイムアウト値よりも大きいタイムアウト値は適切に検証されませんでした。その結果、HAProxy が解析できるタイムアウト値よりも大きいタイムアウト値により、HAProxy で問題が発生しました。今回の更新により、タイムアウトに解析できる値より大きな値が指定された場合、HAProxy が解析できる最大値に制限されます。その結果、HAProxy に関する問題は発生しなくなります。(OCPBUGS-6959)
- 以前は、クラスターのシャットダウンまたはハイバーネート中に、外部ネイバーの MAC アドレスが変更される可能性がありました。Gratuitous Address Resolution Protocol (GARP) はこの変更について他のネイバーに通知する必要がありますが、クラスターは GARP を処理しません。これは、GARP が実行されていなかったためです。クラスターが再起動されると、古い MAC アドレスが使用されていたため、OVN-Kubernetes クラスターネットワークからそのネイバーに到達できない可能性がありました。この更新により、エージングメカニズムが有効になり、ネイバーの MAC アドレスが 300 秒ごとに定期的に更新されるようになります。(OCPBUGS-11710)
以前は、IngressController が SSL/TLS で設定されていても
clientca-configmapファイナライザーがない場合は、Ingress Operator は IngressController が削除対象としてマークされているかを確認せずに、ファイナライザーを追加しようとしていました。その結果、IngressController が SSL/TLS で設定され、その後削除された場合、Operator はファイナライザーを正常に削除しました。その後、ファイナライザーを追加し直すために IngressController を更新しようとして失敗を繰り返し、Operator のログにエラーメッセージが記録されていました。この更新により、Ingress Operator は、削除対象としてマークされた IngressController に
clientca-configmapファイナライザーを追加しなくなります。その結果、Ingress Operator は誤った更新を実行しようとしなくなり、関連するエラーをログに記録しなくなります。(OCPBUGS-14994)- 以前は、スケジュールされた Pod の処理と、OVN-Kubernetes の開始時にノード上で完了した Pod の処理の間で、競合状態が発生していました。この状況は、ノードの再起動時によく発生していました。その結果、同じ IP が複数の Pod に誤って割り当てられました。この更新により競合状態が修正され、そのような状況で同じ IP が複数の Pod に割り当てられなくなりました。(OCPBUGS-16634)
- 以前は、ホスト要求の重複によりルートが拒否されるエラーがありました。これが発生すると、システムは最初に遭遇したルートを誤って選択しますが、それが常に競合するルートであるとは限りませんでした。この更新により、競合するホストのすべてのルートが最初に取得され、送信時間に基づいて並べ替えられます。これにより、システムは最新の競合ルートを正確に判断して選択することができます。(OCPBUGS-16707)
-
以前は、新しい
ipspec-hostPod が開始されると、既存のXFRM状態がクリアまたは削除されていました。その結果、既存の north-south トラフィックポリシーが削除されました。この問題は解決されています。(OCPBUGS-19817) -
以前は、Kubevirt プロバイダーを使用する場合、
ovn-k8s-cni-overlay, topology:layer2NetworkAttachmentDefinition がホストされた Pod で機能しませんでした。その結果、Pod は起動しませんでした。この問題は解決され、Pod はovn-k8s-cni-overlayNetworkAttachmentDefinition で起動できるようになりました。(OCPBUGS-22869) 以前は、Azure アップストリーム DNS は、512 バイトを超えるペイロードを返したため、EDNS DNS 以外のクエリーに準拠していませんでした。CoreDNS 1.10.1 はアップストリームクエリーに EDNS を使用しなくなり、元のクライアントクエリーが EDNS を使用する場合にのみ EDNS を使用するため、この組み合わせにより、アップストリームが CoreDNS 1.10.1 を使用する EDNS 以外のクエリーに対して 512 バイトを超えるペイロードを返した場合、オーバーフロー
servfailエラーが発生しました。その結果、OpenShift Container Platform 4.12 から 4.13 にアップグレードすると、以前は機能していた一部の DNS クエリーが失敗するようになりました。このリリースでは、オーバーフロー
servfailエラーを返す代わりに、CoreDNS が応答を切り詰め、クライアントが TCP で再試行できることを示すようになりました。その結果、準拠していないアップストリームを持つクラスターは、オーバーフローエラーが発生した場合に TCP を使用して再試行するようになりました。これにより、OpenShift Container Platform 4.12 と 4.13 の間での機能の中断が阻止されます。(OCPBUGS-27904)、(OCPBUGS-28205)- 以前は、プライベート Microsoft Azure クラスターには、Egress IP アドレスとして指定されたセカンダリー IP アドレスにアウトバウンド接続がないという制限がありました。これは、これらの IP アドレスに関連付けられた Pod がインターネットにアクセスできないことを意味していました。ただし、インフラストラクチャーネットワーク内の外部サーバーに到達できました。これが、Egress IP アドレスの意図された使用例です。この更新により、Microsoft Azure クラスターの Egress IP アドレスが有効になり、アウトバウンドルールを通じてアウトバウンド接続を実現できるようになります。(OCPBUGS-5491)
- 以前は、複数の NICS を使用する場合、ラベル付けの有無かかわらず、Egress IP アドレスが正しい Egress ノードに正しく再割り当てらていませんでした。このバグは修正され、Egress IP アドレスが正しい Egress ノードに再割り当てされるようになりました。(OCPBUGS-18162)
- 以前は、Keepalived プロセスを実行する場所を決定するために導入された新しいロジックでは、Ingress VIP が考慮されていませんでした。その結果、Keepalived Pod が Ingress ノードで実行されなかった可能性があり、クラスターが破損する可能性がありました。この修正により、ロジックに Ingress VIP が含まれるようになり、Keepalived Pod が常に利用可能になります。(OCPBUGS-18771)
-
以前の Hypershift クラスターでは、Pod が常に別のゾーンにスケジュールされているわけではありませんでした。この更新により、
multus-admission-controllerデプロイでは、Hypershift が適切なゾーンで動作するようにPodAntiAffinity仕様が使用されるようになりました。(OCPBUGS-15220) - 以前は、Multus の実装には 10 分間存在した証明書が使用されていました。この更新により、ノードごとの証明書が Multus CNI プラグインに使用され、証明書の存続期間が 24 時間に延長されました。(OCPBUGS-19861)、(OCPBUGS-19859)
-
以前は、
spec.desiredState.ovn.bridge-mappingsAPI 設定により、各 Kubernetes ノードの Open vSwitch (OVS) ローカルテーブル内のすべての外部 ID が削除されました。その結果、OVN シャーシ設定が削除され、デフォルトのクラスターネットワークが切断されました。この修正により、OVS 設定に影響を与えることなくovn.bridge-mappings設定を使用できるようになります。(OCPBUGS-18869) - 以前は、NMEA センテンスが E810 コントローラーに送信される途中で失われた場合、T-GM はネットワーク同期チェーン内のデバイスを同期できませんでした。これらの条件がそろった場合、PTP Operator はエラーを報告しました。このリリースでは、NMEA 文字列が失われた場合に 'FREERUN' を報告する修正が実装されました。(OCPBUGS-20514)
-
以前は、Whereabouts CNI プラグインによって作成されたプールから IP が割り当てられた Pod は、ノードの強制再起動後も
ContainerCreating状態のままでした。このリリースでは、ノードの強制再起動後の IP 割り当てに関連する Whereabouts CNI プラグインの問題が解決されました。(OCPBUGS-18893) 以前は、Assisted Installer を使用すると、OVN-Kubernetes のブートストラップに長い時間がかかりました。この問題は、
ovnkube-control-planeノードが 3 つあったために発生しました。最初の 2 つは正常に起動しましたが、3 つ目はインストール時間が遅れました。この問題はタイムアウトが経過した後にのみ解決されます。その後、インストールが続行されます。この更新により、3 番目の
ovnkube-control-planeノードが削除されました。その結果、インストール時間が短縮されました。(OCPBUGS-29480)
Node
- Machine Config Operator (MCO) がワーカープールとカスタムプールのマシン設定を処理する方法が原因で、MCO はカスタムプールに間違った cgroup バージョン引数を適用する可能性があります。その結果、カスタムプール内のノードに間違った cgroup カーネル引数が設定され、予測できない動作が発生する可能性があります。回避策として、ワーカーおよびコントロールプレーンプールのみに cgroup バージョンのカーネル引数を指定します。(OCPBUGS-19352)
-
以前は、CRI-O は、
crunが cgroups を作成する独自の方法を考慮して cgroup 階層を正しく設定していませんでした。その結果、PerformanceProfile を使用して CPU クォータを無効化できませんでした。この修正により、PerformanceProfile を使用して CPU クォータを無効にすることが期待どおりに機能します。(OCPBUGS-20492) -
以前は、デフォルト設定 (
container_use_dri_devices, true) のため、コンテナーは dri デバイスを使用できませんでした。この修正により、コンテナーは期待どおりに dri デバイスを使用できるようになります。(OCPBUGS-24042) -
以前は、kubelet は
unconfined_service_tSELinux タイプで実行されていました。その結果、Selinux の拒否により、すべてのプラグインがデプロイできませんでした。この修正により、kubelet はkubelet_exec_tSELinux タイプで実行されるようになりました。その結果、プラグインは期待どおりにデプロイされます。(OCPBUGS-20022) -
以前は、
CRI-Oはアップグレード時にコンテナーイメージを自動的に削除していました。これにより、イメージの事前プルに問題が発生しました。このリリースでは、OpenShift Container Platform がマイナーアップグレードを実行するときに、コンテナーイメージは自動的に削除されず、代わりに、ディスク使用量に基づいてトリガーされる kubelet のイメージガベージコレクションの対象となります。(OCPBUGS-25228) - 以前は、ansible Playbook を使用して既存のクラスターに RHCOS マシンを追加する場合、マシンには openvswitch バージョン 2.7 がインストールされていました。この更新により、ansible Playbook を使用して既存のクラスターに追加された RHCOS マシンには、openvswitch バージョン 3.1 がインストールされます。この openvswitch バージョンでは、ネットワークパフォーマンスが向上します。(OCPBUGS-18595)
Node Tuning Operator (NTO)
-
以前は、Tuned プロファイルは、PerformanceProfile の適用後に
Degraded状態を報告していました。生成された Tuned プロファイルは、/etc/sysctl.dファイルを使用して同じ値がすでに設定されているときに、デフォルトの Receive Packet Steering (RPS) マスクのsysctl値を設定しようとしていました。Tuned はそれについて警告し、Node Tuning Operator (NTO) は次のメッセージを表示してこれを機能低下として扱います。The TuneD daemon issued one or more error message(s) when applying the profile profile.TuneD stderr: net.core.rps_default_mask。今回の更新では、Tuned を使用してデフォルトの RPS マスクを設定しないことで重複が解決されました。sysctl.dファイルは、起動時の早い段階で適用されるため、そのまま残されました。(OCPBUGS-25092) -
以前は、Node Tuning Operator (NTO) は
UserAgentを設定せず、デフォルトの UserAgent を使用していました。この更新により、NTO はUserAgentを適切に設定するようになり、クラスターのデバッグが容易になります。(OCPBUGS-19785) -
以前は、クラスター内に多数の CSV が存在するときに Node Tuning Operator (NTO) Pod が再起動すると、NTO Pod は失敗し、
CrashBackLoop状態になりました。この更新により、CSV 要求のリストにページネーションが追加され、CrashBackLoop状態を引き起こすapi-serverタイムアウトの問題が回避されました。(OCPBUGS-14241)
OpenShift CLI (oc)
以前は、チャネル別 (
mirror.operators.catalog.packages.channelsなど) に Operator パッケージをフィルター処理するには、そのチャネルのパッケージを使用するつもりがない場合でも、パッケージのデフォルトチャネルを指定する必要がありました。この情報に基づいて、imageSetConfigにパッケージのデフォルトチャネルが含まれていない場合、結果として生成されるカタログは無効であると見なされます。この更新では、
mirror.operators.catalog.packagesセクションにdefaultChannelフィールドが導入されています。デフォルトのチャネルを選択できるようになりました。このアクションにより、oc-mirrorは、defaultChannelフィールドで選択されたチャネルをパッケージのデフォルトとして定義する新しいカタログをビルドできるようになります。(OCPBUGS-385)-
以前は、
oc-mirrorでのミラーリングにeus-チャネルを使用すると失敗していました。これは、偶数番号のリリースのみをミラーリングするというeus-チャネルの制限によるものでした。この更新により、oc-mirrorはリリースのミラーリングにeus-チャネルを効果的に使用できるようになりました。(OCPBUGS-26065) -
以前は、非表示フォルダーからローカル OCI Operator カタログをミラーリングするために
oc-mirrorを使用すると、エラーerror: ".hidden_folder/data/publish/latest/catalog-oci/manifest-list/kubebuilder/kube-rbac-proxy@sha256:<SHASUM>" is not a valid image reference: invalid reference formatが発生しました。この更新により、イメージ参照がローカル OCI カタログ内で調整され、ミラーリング中のエラーが阻止されます。(OCPBUGS-25077) -
以前は、
must-gatherツールの実行時に OpenShift Container Platform CLI (oc) バージョンが出力されませんでした。このリリースでは、must-gatherの実行時にocバージョンが概要セクションにリストされるようになりました。(OCPBUGS-24199) -
以前は、ターミナルにアタッチせずに
oc debugでコマンドを実行した場合 (oc debug node/worker — sleep 5; exit 1など)、コマンドの終了コードに関係なく、常に0終了コードが返されました。このリリースでは、終了コードがコマンドから適切に返されるようになりました。(OCPBUGS-20342) -
以前は、ミラーリング時に、認証トークンの期限切れが原因で
HTTP401エラーが発生していました。これらのエラーは、カタログイントロスペクションフェーズまたはイメージミラーリングフェーズ中に発生しました。カタログイントロスペクションの場合、この問題は修正されました。さらに、Network Time Protocol (NTP) を修正すると、ミラーリングフェーズ中に発生した問題が解決されます。詳細は、イメージをミラーリングする際の "要求されたリソースへのアクセス" エラーに関する記事を参照してください。(OCPBUGS-7465)
Operator Lifecycle Manager (OLM)
-
Operator をインストールした後、カタログが使用できなくなると、Operator のサブスクリプションは
ResolutionFailedステータス条件で更新されます。この更新前は、カタログが再び利用可能になったときに、ResolutionFailedステータスがクリアされませんでした。今回の更新により、カタログが利用可能になった後、このステータスは想定どおりにサブスクリプションから消去されるようになりました。(OCPBUGS-29116) - この更新により、OLM は、更新されたカスタムリソース定義 (CRD) をインストールするときに、既存のカスタムリソース (CR) が無効化されないことを確認するベストエフォート検証を実行します。(OCPBUGS-18948)
-
この更新前は、Operator のインストールプランで、
clusterSeviceVersionNamesフィールドに重複した値が表示されていました。この更新により、重複した値が削除されます。(OCPBUGS-17408) この更新前は、以前の既存のクラスターロールと同じ名前で Operator グループを作成した場合、Operator Lifecycle Manager (OLM) によってクラスターロールが上書きされました。この修正により、OLM は次の構文を使用して、Operator グループごとに一意のクラスターロール名を生成します。
命名構文
olm.og.<operator_group_name>.<admin_edit_or_view>-<hash_value>
詳細は、「Operator グループ」を参照してください。(OCPBUGS-14698)
以前は、Operator のインストールまたはアップグレードに 10 分超の時間がかかると、次のエラーが発生して操作が失敗することがありました。
Bundle unpacking failed. Reason: DeadlineExceeded, Message: Job was active longer than specified deadline
この問題は、Operator Lifecycle Manager (OLM) に 600 秒のタイムアウトが設定されたバンドル解凍ジョブがあったために発生しました。バンドル解凍ジョブは、クラスター内のネットワークまたは設定の問題が原因で失敗する可能性があります。これらの問題は一時的なものであるか、ユーザーの介入によって解決される可能性があります。このバグ修正により、OLM は失敗した解凍ジョブの再作成をデフォルトで無期限に自動化します。
この更新により、Operator グループにオプションの
operatorframework.io/bundle-unpack-min-retry-intervalアノテーションが追加されました。このアノテーションは、失敗したジョブの再作成を試行する前に待機する最小間隔を設定します。(OCPBUGS-6771)-
Operator Lifecycle Manager (OLM) では、カタログ Operator が、Operator がインストールされていない namespace での
OperatorGroupオブジェクトの欠落に関する多くのエラーをログに記録していました。この修正により、namespace にSubscriptionオブジェクトがない場合、OLM はOperatorGroupオブジェクトが namespace に存在するか確認しなくなります。(OCPBUGS-25330) Security Context Constraints (SCC) API を使用すると、ユーザーはクラスター上でワークロードをスケジュールするためのセキュリティーコンテキストを設定できます。コア OpenShift Container Platform コンポーネントの一部は、コントロールプレーンノード上でスケジュールされた Pod として実行されるため、これらのコアコンポーネントが
openshift-*namespace で適切にスケジュールされることを妨げる SCC を作成する可能性があります。このバグ修正により、
package-server-managerコアコンポーネントの実行に使用されるopenshift-operator-lifecycle-managerサービスアカウントのロールベースのアクセス制御 (RBAC) スコープが縮小されます。この更新により、package-server-managerコンポーネントで予期しないスケジュールの問題を引き起こすクラスターに SCC が適用される可能性が大幅に低くなりました。警告SCC API は、OpenShift Container Platform クラスター上のスケジューリングにグローバルに影響を与える可能性があります。このような制約をクラスター上のワークロードに適用する場合は、SCC のドキュメントを注意深くお読みください。
スケーラビリティーおよびパフォーマンス
-
以前は、
udevイベントと物理デバイスに関連付けられた作成キューの間の競合状態により、一部のキューがゼロにリセットされる必要がある場合に、間違った Receive Packet Steering (RPS) マスクで設定されていました。これにより、物理デバイスのキューに RPS マスクが設定され、Receive Side Scaling (RSS) の代わりに RPS が使用されることになり、パフォーマンスに影響を与える可能性がありました。この修正により、イベントはデバイスの作成時ではなくキューの作成ごとにトリガーされるように変更されました。これにより、欠落するキューがないことが保証されます。すべての物理デバイスのキューが、空の正しい RPS マスクを使用してセットアップされるようになりました。(OCPBUGS-18662) -
以前は、コンテナーの
cgroup階層のセットアップの違いにより、crunOCI ランタイムとPerformanceProfile設定を使用するコンテナーでは、パフォーマンスの低下が発生していました。このリリースでは、PerformanceProfile要求を処理するときに、CRI-O はcrunの違いを考慮し、パフォーマンスを確保するために CPU クォータを正しく設定します。(OCPBUGS-20492)
ストレージ
-
以前は、LVM Storage はオーバープロビジョニングの無効化をサポートしておらず、
LVMClusterCR のthinPoolConfig.overprovisionRatioフィールドの最小値は 2 でした。このリリースでは、thinPoolConfig.overprovisionRatioフィールドの値を 1 に設定することで、オーバープロビジョニングを無効にできます。(OCPBUGS-24396) -
以前は、
deviceSelector.optionalPathsフィールドに無効なデバイスパスを指定してLVMClusterCR が作成された場合、LVMClusterCR はProgressing状態にありました。このリリースでは、deviceSelector.optionalPathsフィールドに無効なデバイスパスが含まれている場合、LVM Storage はLVMClusterCR 状態をFailedに更新します。(OCPBUGS-23995) -
以前は、クラスターが混雑しているときに LVM Storage リソース Pod がプリエンプトされていました。このリリースでは、OpenShift Container Platform の更新時に、クラスターが輻輳しているときに適切なスケジューリングとプリエンプション動作を確保するために、LVM Storage は
priorityClassNameパラメーターを設定します。(OCPBUGS-23375) -
以前は、
LVMClusterCR の作成時に、LVM Storage はボリュームグループのカウントをスキップしていました。その結果、ボリュームグループが有効であっても、LVMClusterCR がProgressing状態に移行しました。このリリースでは、LVMClusterCR の作成時に、LVM Storage はすべてのボリュームグループをカウントし、ボリュームグループが有効であればLVMClusterCR の状態をReadyに更新します。(OCPBUGS-23191) -
以前は、選択したすべてのノードにデフォルトのデバイスクラスが存在しなかった場合、LVM Storage は
LVMClusterCR をセットアップできませんでした。このリリースでは、デフォルトのデバイスクラスが選択したノードの 1 つにのみ存在する場合でも、LVM Storage はすべてのデフォルトのデバイスクラスを検出します。今回の更新により、選択したノードの 1 つでのみデフォルトのデバイスクラスを定義できるようになりました。(OCPBUGS-23181) -
以前は、シングルノード OpenShift (SNO) およびワーカーノードトポロジーでワーカーノードを削除しても、
LVMClusterCR には削除されたワーカーノードの設定が含まれていました。その結果、LVMClusterCR はProgressing状態のままになりました。このリリースでは、SNO およびワーカーノードトポロジー内のワーカーノードを削除すると、LVM Storage はLVMClusterCR 内のワーカーノード設定を削除し、LVMClusterCR の状態をReadyに更新します。(OCPBUGS-13558) - 以前は、AWS EFS CSI ドライバーコンテナーの CPU 制限により、AWS EFS CSI Driver Operator によって管理されるボリュームのパフォーマンスが低下する可能性がありました。このリリースでは、潜在的なパフォーマンスの低下を防ぐために、AWS EFS CSI Driver コンテナーの CPU 制限が削除されました。(OCPBUGS-28645)
-
以前は、Azure Disk CSI ドライバーで
performancePlusパラメーターを使用し、512 GiB 以下のボリュームをプロビジョニングした場合、少なくとも 512 GiB のディスクサイズが必要であるというエラーがドライバーから返されていました。このリリースでは、performancePlusパラメーターを使用して 512 GiB 以下のボリュームをプロビジョニングすると、Azure Disk CSI ドライバーはボリュームのサイズを自動的に 513 GiB に変更します。(OCPBUGS-17542)
