2.4. 既知の問題

OpenShift Container クラスター内の 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 のメタデータに次のアノテーションを追加する必要があります。

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

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

(KATA-1376)

コンテナーのセキュリティーコンテキストで SELinux Multi-Category Security (MCS) ラベルを設定すると、Pod が起動せず、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)

一時メモリーボリュームの sizeLimit オプションは、OpenShift Sandboxed Containers では機能しません。一時ボリュームサイズのデフォルトは、サンドボックスコンテナーに割り当てられたメモリーの 50% です。ボリュームを再マウントすることで、このボリュームのサイズを手動で変更できます。たとえば、サンドボックスコンテナーに割り当てられたメモリーが 6 GB で、一時ボリュームが /var/lib/containers にマウントされている場合は、次のコマンドを使用して、このボリュームのサイズを仮想マシンメモリーのデフォルトの 50% を超えて増やすことができます。。

mount -o remount,size=4G /var/lib/containers

$ mount -o remount,size=4G /var/lib/containers

(KATA-2579)

io.katacontainers.config.hypervisor.default_vcpus アノテーションおよび io.katacontainers.config.hypervisor.default_memory アノテーションは QEMU のセマンティクスに従いますが、ピア Pod には次の制限があります。

代わりに、柔軟な Pod VM サイズには io.katacontainers.config.hypervisor.machine_type: <instance type/instance size> アノテーションを使用することが推奨されます。(KATA-2575、KATA-2577、KATA-2578)

OpenShift Sandboxed Containers Operator 1.4.1 からバージョン 1.5 への自動アップグレード中に、アップグレードが pending 状態でスタックします。

サブスクリプションが自動更新に設定されていると、OpenShift Sandboxed Containers のアップグレードがインストールされます。ただし、KataConfig CR (カスタムリソース) がインストールされている場合、CSV は pending 状態のままになります。

次のコマンドを実行して、Subscription オブジェクトのステータスを確認できます。

oc get sub osc-operator -n openshift-osc-operator -o yaml

$ oc get sub osc-operator -n openshift-osc-operator -o yaml

次のエラーが、Subscription オブジェクトの status セクションと、アップグレードの InstallPlan オブジェクトの status セクションに表示されます。

message: 'error validating existing CRs against new CRD''s schema for "kataconfigs.kataconfiguration.openshift.io":
      error validating custom resource against new schema for KataConfig /example-kataconfig:
      [].status.runtimeClass: Invalid value: "string": status.runtimeClass in body
      must be of type array: "string"'

message: 'error validating existing CRs against new CRD''s schema for "kataconfigs.kataconfiguration.openshift.io":
      error validating custom resource against new schema for KataConfig /example-kataconfig:
      [].status.runtimeClass: Invalid value: "string": status.runtimeClass in body
      must be of type array: "string"'

このエラーが発生した場合は、OpenShift Sandboxed Containers Operator をアンインストールしてから再インストールする必要があります。

(KATA-2593)