1.4. 既知の問題

OpenShift サンドボックスコンテナーを使用している場合、OpenShift Container Platform クラスターの hostPath ボリュームからマウントされたファイルまたはディレクトリーにアクセスすると、SELinux 拒否を受け取ることがあります。これらの拒否は、特権サンドボックスコンテナーを実行している場合でも発生する可能性があります。これは、特権サンドボックスコンテナーが SELinux チェックを無効にしないためです。

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

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

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

一部の OpenShift サンドボックスコンテナー 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)

OpenShift サンドボックスコンテナーで古いバージョンの Buildah ツールを使用すると、ビルドが次のエラーで失敗します。

process exited with error: fork/exec /bin/sh: no such file or directory

subprocess exited with status 1

process exited with error: fork/exec /bin/sh: no such file or directory

subprocess exited with status 1

quay.io で入手可能な Buildah の最新バージョンを使用する必要があります。

(KATA-1278)

OpenShift サンドボックスコンテナーをアップグレードしても、既存の KataConfig CR は自動的に更新されません。その結果、以前のデプロイメントのモニター Pod は再起動されず、古い kataMonitor イメージで引き続き実行されます。

次のコマンドを使用して、kataMonitor イメージをアップグレードします。

oc patch kataconfig example-kataconfig --type merge --patch '{"spec":{"kataMonitorImage":"registry.redhat.io/openshift-sandboxed-containers/osc-monitor-rhel8:1.3.0"}}'

$ oc patch kataconfig example-kataconfig --type merge --patch '{"spec":{"kataMonitorImage":"registry.redhat.io/openshift-sandboxed-containers/osc-monitor-rhel8:1.3.0"}}'

Web コンソールで KataConfig YAML を編集して、kataMonitor イメージをアップグレードすることもできます。

(KATA-1650)