1.4. 既知の問題

OpenShift Sandboxed Containers を使用している場合は、Red Hat OpenShift クラスター内の hostPath ボリュームからマウントされたファイルまたはディレクトリーにアクセスすると、SELinux が拒否することがありました。特権 Sandboxed Container は SELinux チェックを無効にしないため、特権 Sandboxed Container を実行している場合でも、このように拒否される可能性があります。

ホストで SELinux ポリシーに従うことで、デフォルトでサンドボックス化されたワークロードからホストファイルシステムを完全に分離することが保証されます。これにより、virtiofsd デーモンまたは QEMU の潜在的なセキュリティー上の欠陥に対する保護も強化されます。

マウントされたファイルまたはディレクトリーにホスト上の特定の SELinux 要件がない場合は、代わりにローカル永続ボリュームを使用できます。ファイルは、コンテナーランタイムの SELinux ポリシーに従って、自動的に container_file_t に再ラベル付けされます。ローカルボリュームを使用した永続ストレージ を参照してください。

マウントされたファイルまたはディレクトリーがホスト上で特定の SELinux ラベルを持つことが予想される場合、自動再ラベル付けはオプションではありません。代わりに、ホストでカスタム SELinux ルールを設定して、virtiofsd デーモンがこれらの特定のラベルにアクセスできるようにすることができます。(KATA-469)

一部の OpenShift Sandboxed Containers Operator Pod は、コンテナーの CPU リソース制限を使用して、Pod で使用可能な CPU の数を増やします。これらの Pod は、要求されたよりも少ない CPU を受け取る可能性があります。コンテナー内で機能が利用可能な場合は、oc rsh <pod> を使用して Pod にアクセスし、lscpu コマンドを実行することで、CPU リソースの問題を診断できます。

lscpu

$ lscpu

CPU(s):                          16
On-line CPU(s) list:             0-12,14,15
Off-line CPU(s) list:            13

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"

metadata:
  annotations:
    io.katacontainers.config.hypervisor.default_vcpus: "16"

(KATA-1376)

ランタイムインストールの進行状況は、kataConfig カスタムリソース (CR) の status セクションに表示されます。ただし、次の条件がすべて当てはまる場合、進行状況は表示されません。

この場合、Operator はノードがコントロールプレーンとワーカーの両方のロールを持つコンバージドクラスターであると想定するため、コントロールプレーンノードでインストールが開始されます。kataConfig CR の status セクションは、インストール中に更新されません。(KATA-1017)

コンテナーのセキュリティーコンテキストで SELinux Multi-Category Security (MCS) ラベルを設定すると、Pod が起動せず、次のエラーが出力されます。

Error: CreateContainer failed: EACCES: Permission denied: unknown

Error: CreateContainer failed: EACCES: Permission denied: unknown

ランタイムは、Sandboxed Containers の作成時にコンテナーのセキュリティーコンテキストにアクセスできません。これは、virtiofsd が適切な SELinux ラベルで実行されず、コンテナーのホストファイルにアクセスできないことを意味します。その結果、MCS ラベルを利用してSandboxed Containers 内のファイルをコンテナーごとに分離できません。つまり、すべてのコンテナーがSandboxed Containers 内のすべてのファイルにアクセスできることになります。現在、この問題に対する回避策はありません。

(KATA-1875)

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

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 データの収集 を参照してください。

(KATA-2133)

Web コンソールを使用して OpenShift Sandboxed Containers Operator をインストールした場合は、Install をクリックした後に UI に間違った Operator バージョンが表示されることがあります。

バージョンが正しくない場合は、インストールウィンドウに灰色のテキストで次のように表示されます。

<Version number> provided by Red Hat.

正しい Operator をインストールします。Operators Installed Operators に移動すると、OpenShift Sandboxed Containers Operator の下に正しいバージョンがリストされていることがわかります。

(KATA-2161)

OpenShift Sandboxed Containers でピア Pod を使用する場合は、KataConfig CR を作成し、enablePeerPods フィールドを true に設定すると、kata-remote-cc ランタイムクラスが作成されます。結果として、KataConfig CR に kata ランタイムクラスに加えて、kata-remote-cc ランタイムクラスが表示され、技術的には、標準の Kata Pod とピア Pod Kata Pod の両方を同じクラスター上で実行できるはずです。

クラスター管理者として KataConfig CR を調べると、Status.runtimeClass フィールドに kata のみが表示されます。ランタイムクラス kata-remote-cc が表示されません。現在、この問題に対する回避策はありません。

(KATA-2164)