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" ]

    (BZ#1915377)

  • 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"

    (BZ#2019384)

  • 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)