OpenShift Sandboxed Containers リリースノート
Red Hat OpenShift 向け
概要
はじめに
第1章 OpenShift Sandboxed Containers 1.4 リリースノート
1.1. このリリースについて
これらのリリースノートは、Red Hat OpenShift 4.13 とともに OpenShift サンドボックスコンテナー 1.4 の開発を追跡します。
この製品は、Red Hat OpenShift 4.10 の時点で完全にサポートされ、デフォルトで有効になっています。
1.2. 新機能および機能拡張
1.2.1. OpenShift Sandboxed Containers のピア Pod のサポート (テクノロジープレビュー)
AWS または Microsoft Azure のピア Pod を使用して、OpenShift Sandboxed Containers のワークロードをデプロイできるようになりました。これにより、ネストされた仮想化の必要性がなくなります。この機能はテクノロジープレビューであるため、完全にはサポートされていません。詳細は、ピア Pod を使用した OpenShift Sandboxed Containers ワークロードのデプロイ を参照してください。
1.2.2. QEMU エラーログ収集
QEMU の警告ログとエラーログは、ノードジャーナル、Kata ランタイムログ、および CRI-O ログの両方に出力されるようになりました。詳細は、OpenShift Sandboxed Containers のデバッグログの表示 を参照してください。
1.2.3. OpenShift Sandboxed Containers Operator をインストールするための更新チャネル
OpenShift Sandboxed Containers Operator をインストールするときのサブスクリプションチャネルは、一貫性を確保するために、stable-<version> ではなく、常に stable になりました。
1.3. バグ修正
以前は、OpenShift Sandboxed Containers をアップグレードしても、既存の
KataConfigCR は自動的に更新されませんでした。その結果、以前のデプロイメントのモニター Pod は再起動されず、古いkataMonitorイメージで実行され続けました。リリース 1.3.2 以降、
kataMonitorImage はKataConfigCR から削除され、すべてのモニター Pod のアップグレードは Operator によって内部処理されます。以前のリリースでは、ネットワーク接続のないクラスターに OpenShift Sandboxed Containers をインストールできませんでした。kata-monitor コンテナーイメージのプル仕様では、ダイジェストの代わりにタグが使用されていました。これにより、イメージが
ImageContentSourcePolicyリソースでミラーリングされなくなっていました。今回のリリースでは、OpenShift Sandboxed Containers Operator 内のすべてのコンテナーイメージが確実に含まれるように、CSV
spec.relativeImagesセクションが更新されました。その結果、すべてのコンテナーのプル仕様ではタグの代わりにダイジェストが利用されるようになり、切断された環境でも OpenShift Sandboxed Containers をインストールできるようになりました。-
以前のバージョンでは、テイントのマークが付けられたノードで実行されている OpenShift サンドボックスコンテナーでは、メトリクスを使用できませんでした。今回のリリースにより、容認が
kata-monitorPod に追加され、テイントが付けられたノードであっても Pod が任意のノードで実行および収集できるようになりました。(KATA-2121) -
以前は、OpenShift サンドボックスコンテナー Operator のベースイメージは
ubi8/ubi-mimimalイメージを使用していました。このリリースでは、RHEL 9 クラスターと Red Hat OpenShift 4.13 との互換性を確保するために、ベースイメージが ubi9/ubiイメージを使用するように更新されました。(KATA-2212)
1.4. 既知の問題
OpenShift Sandboxed Containers を使用している場合は、Red Hat OpenShift クラスター内の
hostPathボリュームからマウントされたファイルまたはディレクトリーにアクセスすると、SELinux が拒否することがありました。特権 Sandboxed Container は SELinux チェックを無効にしないため、特権 Sandboxed Container を実行している場合でも、このように拒否される可能性があります。ホストで SELinux ポリシーに従うことで、デフォルトでサンドボックス化されたワークロードからホストファイルシステムを完全に分離することが保証されます。これにより、
virtiofsdデーモンまたは QEMU の潜在的なセキュリティー上の欠陥に対する保護も強化されます。マウントされたファイルまたはディレクトリーにホスト上の特定の SELinux 要件がない場合は、代わりにローカル永続ボリュームを使用できます。ファイルは、コンテナーランタイムの SELinux ポリシーに従って、自動的に
container_file_tに再ラベル付けされます。Persistent storage using local volumes を参照してください。マウントされたファイルまたはディレクトリーがホスト上で特定の SELinux ラベルを持つことが予想される場合、自動再ラベル付けはオプションではありません。代わりに、ホストでカスタム SELinux ルールを設定して、
virtiofsdデーモンがこれらの特定のラベルにアクセスできるようにすることができます。(KATA-469)一部の OpenShift Sandboxed Containers Operator Pod は、コンテナーの CPU リソース制限を使用して、Pod で使用可能な CPU の数を増やします。これらの Pod は、要求されたよりも少ない CPU を受け取る可能性があります。コンテナー内で機能が利用可能な場合は、
oc rsh <pod>を使用して Pod にアクセスし、lscpuコマンドを実行することで、CPU リソースの問題を診断できます。$ lscpu
出力例
CPU(s): 16 On-line CPU(s) list: 0-12,14,15 Off-line CPU(s) list: 13
オフライン CPU のリストは、実行ごとに予期せず変更される可能性があります。
回避策として、CPU 制限を設定するのではなく、Pod アノテーションを使用して追加の CPU をリクエストできます。Pod アノテーションを使用する CPU リクエストは、プロセッサーの割り当て方法が異なるため、この問題の影響を受けません。CPU 制限を設定するのではなく、Pod のメタデータに次の
annotationを追加する必要があります。metadata: annotations: io.katacontainers.config.hypervisor.default_vcpus: "16"
ランタイムインストールの進行状況は、
kataConfigカスタムリソース (CR) のstatusセクションに表示されます。ただし、次の条件がすべて当てはまる場合、進行状況は表示されません。-
ワーカーノードが定義されていません。
oc get machineconfigpoolを実行して、マシン設定プール内のワーカーノードの数を確認できます。 -
インストールするノードを選択するための
kataConfigPoolSelectorが指定されていません。
この場合、Operator はノードがコントロールプレーンとワーカーの両方のロールを持つコンバージドクラスターであると想定するため、コントロールプレーンノードでインストールが開始されます。
kataConfigCR のstatusセクションは、インストール中に更新されません。(KATA-1017)-
ワーカーノードが定義されていません。
-
Web コンソールの KataConfig タブで、YAML view で Create KataConfig をクリックすると、
KataConfigYAML にspecフィールドがありません。Form view に切り替えてから YAML view に戻ると、この問題が修正され、完全な YAML が表示されます。(KATA-1372) -
Web コンソールの KataConfig タブに、
KataConfigCR がすでに存在するかどうかにかかわらず、404: Not foundエラーメッセージが表示されます。既存のKataConfigCR にアクセスするには、Home > Search に移動します。Resources リストから、KataConfig を選択します。(KATA-1605) -
KataConfigCR のインストール中に、最初のノードが再起動する前にKataConfigCR の削除が開始されると、ノードのステータスが正しくなくなります。これが発生すると、Operator はKataConfigCR の削除とインストールを同時に試行する状態でスタックします。想定される動作として、インストールが停止し、KataConfigCR が削除されます。(KATA-1851) コンテナーのセキュリティーコンテキストで SELinux Multi-Category Security (MCS) ラベルを設定すると、Pod が起動せず、次のエラーが出力されます。
Error: CreateContainer failed: EACCES: Permission denied: unknown
ランタイムは、Sandboxed Containers の作成時にコンテナーのセキュリティーコンテキストにアクセスできません。これは、
virtiofsdが適切な SELinux ラベルで実行されず、コンテナーのホストファイルにアクセスできないことを意味します。その結果、MCS ラベルを利用してSandboxed Containers 内のファイルをコンテナーごとに分離できません。つまり、すべてのコンテナーがSandboxed Containers 内のすべてのファイルにアクセスできることになります。現在、この問題に対する回避策はありません。Sandboxed Containers ワークロードを停止すると、次の QEMU エラーメッセージがワーカーノードシステムジャーナルに記録されます。
qemu-kvm: Failed to write msg. qemu-kvm: Failed to set msg fds. qemu-kvm: vhost VQ 0 ring restore failed qqemu-kvm: vhost_set_vring_call failed
これらのエラーは無害なので無視してかまいません。
システムジャーナルログにアクセスする方法の詳細は、Red Hat サポートの OpenShift Sandboxed Containers データの収集 を参照してください。
Web コンソールを使用して OpenShift Sandboxed Containers Operator をインストールした場合は、Install をクリックした後に UI に間違った Operator バージョンが表示されることがあります。
バージョンが正しくない場合は、インストールウィンドウに灰色のテキストで次のように表示されます。
<Version number> provided by Red Hat.
正しい Operator をインストールします。Operators → Installed Operators に移動すると、OpenShift Sandboxed Containers Operator の下に正しいバージョンがリストされていることがわかります。
OpenShift Sandboxed Containers でピア Pod を使用する場合は、
KataConfigCR を作成し、enablePeerPodsフィールドをtrueに設定すると、kata-remote-ccランタイムクラスが作成されます。結果として、KataConfigCR にkataランタイムクラスに加えて、kata-remote-ccランタイムクラスが表示され、技術的には、標準の Kata Pod とピア Pod Kata Pod の両方を同じクラスター上で実行できるはずです。クラスター管理者として
KataConfigCR を調べると、Status.runtimeClassフィールドにkataのみが表示されます。ランタイムクラスkata-remote-ccが表示されません。現在、この問題に対する回避策はありません。-
OpenShift Sandboxed Containers の FIPS コンプライアンスは、
kataランタイムクラスにのみ適用されます。新しいピア Pod ランタイムクラスkata-remote-ccはまだ完全にはサポートされておらず、FIPS コンプライアンスについてはテストされていません。(KATA-2166)
1.5. 制限
1.6. エラータの非同期更新
OpenShift サンドボックスコンテナー 4.13 のセキュリティー、バグ修正、および拡張機能の更新は、Red Hat Network を通じて非同期エラータとして発表されます。Red Hat OpenShift 4.13 のすべてのエラータは Red Hat カスタマーポータル から入手できます。非同期エラータの詳細は、Red Hat OpenShift ライフサイクル を参照してください。
Red Hat カスタマーポータルのユーザーは、Red Hat Subscription Management (RHSM) のアカウント設定でエラータの通知を有効にできます。エラータの通知を有効にすると、登録しているシステムに関連するエラータが新たに発表されるたびに、メールで通知が送信されます。
Red Hat Customer Portal のユーザーアカウントには、システムが登録されていて、Red Hat OpenShift エラータ通知メールを生成するための Red Hat OpenShift エンタイトルメントを使用している必要があります。
以下のセクションは、これからも継続して更新され、今後の OpenShift sandboxed containers 1.4 の非同期リリースで発表されるエラータの拡張機能およびバグ修正に関する情報を追加していきます。
1.6.1. RHBA-2023:3529 - OpenShift サンドボックスコンテナー 1.4.0 イメージのリリース、バグ修正、機能強化のアドバイザリー
発行日: 2023-06-08
OpenShift Sandboxed Containers リリース 1.4.0 が利用可能になりました。このアドバイザリーには、機能強化とバグ修正を含む OpenShift Sandboxed Containers の更新が含まれています。
更新に含まれるバグ修正のリストは、 RHBA-2023:3529 アドバイザリーに記載されています。
1.6.2. RHSA-2023:4290 - OpenShift サンドボックスコンテナー 1.4.1 イメージのリリース、バグ修正、およびセキュリティーアドバイザリー
発行日:2023-07-27
OpenShift サンドボックスコンテナーリリース 1.4.1 が利用可能になりました。このアドバイザリーには、セキュリティーおよびバグ修正を含む OpenShift サンドボックスコンテナーの更新が含まれています。
更新に含まれるバグ修正のリストは、RHSA-2023:4290 アドバイザリーに記載されています。