1.3. 既知の問題
-
OpenShift サンドボックスコンテナーを使用している場合、OpenShift Container Platform クラスターの
hostPathボリュームを使用して、ホストノードのファイルシステムから Pod にファイルまたはディレクトリーをマウントすることはできません。別の方法として、ローカル永続ボリュームを使用できます。詳細は 、ローカルボリュームを使用した永続ストレージ を参照してください。(BZ#1904609) OpenShift サンドボックスコンテナーで Fedora を実行している場合は、いくつかのパッケージをインストールするための回避策が必要です。
iputilsなどの一部のパッケージでは、OpenShift Container Platform がデフォルトでコンテナーに付与しないファイルアクセス許可の変更が必要です。このような特別なアクセス許可を必要とするコンテナーを実行するには、ワークロードを説明するアノテーションを YAML ファイルに追加する必要があります。これは、そのワークロードに対してこのようなファイルのアクセス許可を受け入れるようにvirtiofsdに指示します。必要なアノテーションは以下のとおりです。io.katacontainers.config.hypervisor.virtio_fs_extra_args: | [ "-o", "modcaps=+sys_admin", "-o", "xattr" ]4.8 リリースでは、OpenShift Container Platform Web コンソールを使用して
kataConfgPoolSelectorに値を追加すると、scheduling.nodeSelectorが空の値で設定される原因となります。kataの値でRuntimeClassを使用する Pod は、Kata コンテナーランタイムがインストールされていないノードにスケジュールされる場合があります。この問題を回避するには、以下のコマンドを実行して、
RuntimeClasskataに手動でnodeSelector値を指定します。$ oc edit runtimeclass kata以下は、正しい
nodeSelectorステートメントを持つRuntimeClassの例です。apiVersion: node.k8s.io/v1 handler: kata kind: RuntimeClass metadata: creationTimestamp: "2021-06-14T12:54:19Z" name: kata overhead: podFixed: cpu: 250m memory: 350Mi scheduling: nodeSelector: custom-kata-pool: "true"- Operator Hub の OpenShift サンドボックスコンテナー Operator の詳細ページでは、いくつかのフィールドがありません。フィールドがない場合でも、4.8 で OpenShift サンドボックスコンテナー Operator をインストールできます。(BZ#2019383)
-
複数の
KataConfigカスタムリソースを作成すると、警告なしで失敗します。OpenShift Container Platform Web コンソールは、複数のカスタムリソースの作成が失敗したことをユーザーに通知するプロンプトを提供しません。(BZ#2019381) - OpenShift Container Platform Web コンソールの Operator Hub に、Operator のアイコンが表示されない場合があります。(BZ#2019380)