2.3. バグ修正
-
OpenShift Sandboxed Containers 1.5.0 から 1.5.2 では、ユーザーがピア Pod を作成すると、Go 1.21.1 でのネットワーク機能の動作の変更により、Pod は
ContainerCreating状態のままになり、"Failed to identify the host primary interface" エラーが表示されました。この問題は、OpenShift Sandboxed Containers 1.5.3 で修正されています。(KATA-2847) -
以前は、
KataConfigCR のインストール中にその削除を開始すると、OpenShift Sandboxed Containers Operator がどちらのプロセスも完了せずに、削除とインストールを同時に試行していました。このリリースでは、Operator はインストールの完了後に削除が実行されるようにシリアル化します。(KATA-1851) -
以前のリリースでは、具体的にラベル付けされたノードを使用してデプロイされた kata 対応クラスターを更新できませんでした。ノードラベルに変更を加えても、デプロイメントの変更がトリガーされませんでした。既存の
kataConfigCR を削除し、更新されたラベルで新しいkataConfigCR を作成する必要がありました。以前のリリース (リリース 1.4) から、ノードラベルを更新すると、デプロイメントの変更が自動的にトリガーされます。(KATA-1928) -
以前は、QEMU が
virtiofsdを検出していないと、kataワークロードが削除されるたびに、QEMU はシステムジャーナルにエラーを記録していました。このリリースでは、kataランタイムはvirtiofsdを停止する前に QEMU を停止するようになりました。この修正は、OpenShift Container Platform 4.13 および 4.14 でのみ利用可能です。(KATA-2133) -
以前は、
KataConfigCR でピア Pod を有効にし、インストール後に CR を検査すると、kata-remoteランタイムクラスがstatus.runtimeClassフィールドに表示されませんでした。この問題は、OpenShift Sandboxed Containers 1.5.0 で修正されています。(KATA-2164) -
以前は、ピア Pod VM の実行中に
peerpodconfig-ctrl-caa-daemonPod を再起動すると、同じピア Pod を表す複数の VM が作成される場合がありました。クラウドプロバイダーのコンソールまたは CLI からインスタンスを手動で削除しない限り、冗長インスタンスは、元のピア Pod が実行している限り存在していました。この更新により、peerpodconfig-ctrl-caa-daemonPod を再起動した後、新しいピア Pod VM が作成され、古いインスタンスはすぐに削除されます。(KATA-2519) - 以前のリリースでは、AWS または Azure で実行されているピア Pod VM のインスタンスメタデータを要求すると、AWS または Azure Instance Metadata Service は Pod ではなくワーカーノードのメタデータを返していました。リリース 1.5.1 の更新により、AWS または Azure Instance Metadata Service は予想通りに Pod のメタデータを返します。(KATA-2583)
