1.6.4. クラウドコンピュート
-
以前は、
MachineSet仕様からのテイントの解析エラーにより、オートスケーラーは仕様に直接設定されたテイントを考慮できないことを意味していました。その結果、ゼロからスケーリングするためにMachineSetテイントに依存する場合、仕様からのテイントが考慮されず、スケーリングの決定が正しく行われない可能性がありました。この更新により、ゼロからのスケールロジック内の解析の問題が解決されました。その結果、オートスケーラーは正しくスケールアップし、ワークロードのスケジュールを妨げる taint を特定できるようになりました。(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)