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 コンテナーランタイムがインストールされていないノードにスケジュールされる場合があります。この問題を回避するには、以下のコマンドを実行して、
RuntimeClass
kata
に手動で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)