2.3. コマンドラインを使用した OpenShift Sandboxed Containers のデプロイ


コマンドラインインターフェイス (CLI) を使用して次のタスクを実行することにより、ベアメタル上に OpenShift sandboxed containers をデプロイできます。

  1. OpenShift Sandboxed Containers Operator を再インストールします。
  2. Operator のインストール後に、以下のオプションを設定できます。

    • ブロックストレージデバイスを設定します。
    • ノード適格性チェックを設定するには、Node Feature Discovery (NFD) Operator をインストールします。詳細は、ノードの適格性チェック および NFD Operator ドキュメント を参照してください。

      • NodeFeatureDiscovery カスタムリソースを作成します。
  3. オプション: Kata エージェントポリシーをカスタマイズします。
  4. KataConfig カスタムリソースを作成します。
  5. オプション: Pod のオーバーヘッドを変更します。
  6. OpenShift Sandboxed Containers のワークロードオブジェクトを設定します。

2.3.1. OpenShift Sandboxed Containers Operator のインストール

CLI を使用して、OpenShift Sandboxed Containers Operator をインストールできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. osc-namespace.yaml マニフェストファイルを作成します。

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-sandboxed-containers-operator
  2. 以下のコマンドを実行して namespace を作成します。

    Copy to Clipboard Toggle word wrap
    $ oc apply -f osc-namespace.yaml
  3. osc-operatorgroup.yaml マニフェストファイルを作成します。

    Copy to Clipboard Toggle word wrap
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: sandboxed-containers-operator-group
      namespace: openshift-sandboxed-containers-operator
    spec:
      targetNamespaces:
      - openshift-sandboxed-containers-operator
  4. 以下のコマンドを実行して Operator グループを作成します。

    Copy to Clipboard Toggle word wrap
    $ oc apply -f osc-operatorgroup.yaml
  5. osc-subscription.yaml マニフェストファイルを作成します。

    Copy to Clipboard Toggle word wrap
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: sandboxed-containers-operator
      namespace: openshift-sandboxed-containers-operator
    spec:
      channel: stable
      installPlanApproval: Automatic
      name: sandboxed-containers-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      startingCSV: sandboxed-containers-operator.v1.9.0
  6. 次のコマンドを実行して、サブスクリプションを作成します。

    Copy to Clipboard Toggle word wrap
    $ oc apply -f osc-subscription.yaml
  7. 次のコマンドを実行して、Operator が正常にインストールされていることを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc get csv -n openshift-sandboxed-containers-operator

    このコマンドが完了するまでに数分かかる場合があります。

  8. 次のコマンドを実行してプロセスを監視します。

    Copy to Clipboard Toggle word wrap
    $ watch oc get csv -n openshift-sandboxed-containers-operator

    出力例

    Copy to Clipboard Toggle word wrap
    NAME                             DISPLAY                                  VERSION             REPLACES                   PHASE
    openshift-sandboxed-containers   openshift-sandboxed-containers-operator  1.9.0    1.8.1        Succeeded

2.3.2. 任意の設定

OpenShift Sandboxed Containers Operator をインストールした後に、次のオプションを設定できます。

2.3.2.1. ローカルブロックボリュームのプロビジョニング

OpenShift Sandboxed Containers でローカルブロックボリュームを使用できます。まず、Local Storage Operator (LSO) を使用してローカルブロックボリュームをプロビジョニングする必要があります。次に、ローカルブロックボリュームを持つノードを有効にして、OpenShift sandboxed containers ワークロードを実行する必要があります。

Local Storage Operator (LSO) を使用して、OpenShift sandboxed containers のローカルブロックボリュームをプロビジョニングできます。ローカルボリュームプロビジョナーは、定義されたリソースで指定されたパスにあるブロックボリュームデバイスを検索します。

前提条件

  • Local Storage Operator がインストールされている。
  • 以下の条件を満たすローカルディスクがある。

    • ノードに接続されている。
    • マウントされていない。
    • パーティションが含まれていない。

手順

  1. ローカルボリュームリソースを作成します。このリソースは、ノードおよびローカルボリュームへのパスを定義する必要があります。

    注記

    同じデバイスに別のストレージクラス名を使用しないでください。こうすることで、複数の永続ボリューム (PV) が作成されます。

    例: ブロック

    Copy to Clipboard Toggle word wrap
    apiVersion: "local.storage.openshift.io/v1"
    kind: "LocalVolume"
    metadata:
      name: "local-disks"
      namespace: "openshift-local-storage" 
    1
    
    spec:
      nodeSelector: 
    2
    
        nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - ip-10-0-136-143
              - ip-10-0-140-255
              - ip-10-0-144-180
      storageClassDevices:
        - storageClassName: "local-sc" 
    3
    
          forceWipeDevicesAndDestroyAllData: false 
    4
    
          volumeMode: Block
          devicePaths: 
    5
    
            - /path/to/device 
    6

    1
    ローカルストレージ Operator がインストールされている namespace。
    2
    オプション: ローカルストレージボリュームが割り当てられているノードの一覧が含まれるノードセレクター。以下の例では、oc get node から取得したノードホスト名を使用します。値が定義されない場合、ローカルストレージ Operator は利用可能なすべてのノードで一致するディスクの検索を試行します。
    3
    永続ボリュームオブジェクトの作成時に使用するストレージクラスの名前。
    4
    この設定は、パーティションテーブルの署名 (マジックストリング) を削除してディスクを Local Storage Operator プロビジョニングに使用できるようにする winefs を呼び出すかどうかを定義します。署名以外のデータは消去されません。デフォルトは "false" です (wipefs は呼び出されません)。再利用する必要がある以前のデータをディスク上に残す場合、forceWipeDevicesAndDestroyAllData を "true" に設定すると便利です。このようなシナリオでは、このフィールドを true に設定すると、管理者はディスクを手動で消去する必要がありません。
    5
    選択するローカルストレージデバイスの一覧を含むパスです。ローカルブロックデバイスを持つノードを有効にして OpenShift sandboxed containers ワークロードを実行する場合は、このパスを使用する必要があります。
    6
    この値を、LocalVolume リソース by-id へのファイルパス (/dev/disk/by-id/wwn など) に置き換えます。プロビジョナーが正常にデプロイされると、これらのローカルディスク用に PV が作成されます。
  2. OpenShift Container Platform クラスターにローカルボリュームリソースを作成します。作成したばかりのファイルを指定します。

    Copy to Clipboard Toggle word wrap
    $ oc apply -f <local-volume>.yaml
  3. プロビジョナーが作成され、対応するデーモンセットが作成されていることを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc get all -n openshift-local-storage

    出力例

    Copy to Clipboard Toggle word wrap
    NAME                                          READY   STATUS    RESTARTS   AGE
    pod/diskmaker-manager-9wzms                   1/1     Running   0          5m43s
    pod/diskmaker-manager-jgvjp                   1/1     Running   0          5m43s
    pod/diskmaker-manager-tbdsj                   1/1     Running   0          5m43s
    pod/local-storage-operator-7db4bd9f79-t6k87   1/1     Running   0          14m
    
    NAME                                     TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
    service/local-storage-operator-metrics   ClusterIP   172.30.135.36   <none>        8383/TCP,8686/TCP   14m
    
    NAME                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/diskmaker-manager   3         3         3       3            3           <none>          5m43s
    
    NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/local-storage-operator   1/1     1            1           14m
    
    NAME                                                DESIRED   CURRENT   READY   AGE
    replicaset.apps/local-storage-operator-7db4bd9f79   1         1         1       14m

    デーモンセットプロセスの desired 数と current 数をメモします。desired 数が 0 の場合、これはラベルセレクターが無効であることを示します。

  4. 永続ボリュームが作成されていることを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc get pv

    出力例

    Copy to Clipboard Toggle word wrap
    NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
    local-pv-1cec77cf   100Gi      RWO            Delete           Available           local-sc                88m
    local-pv-2ef7cd2a   100Gi      RWO            Delete           Available           local-sc                82m
    local-pv-3fa1c73    100Gi      RWO            Delete           Available           local-sc                48m

重要

LocalVolume オブジェクトを編集しても、破壊的な操作になる可能性があるため、既存の永続ボリュームは変更されません。

2.3.2.2. ノードがローカルブロックデバイスを使用できるようにする

定義されたボリュームリソースで指定されたパスで OpenShift sandboxed containers ワークロードを実行するように、ローカルブロックデバイスを持つノードを設定できます。

前提条件

  • Local Storage Operator (LSO) を使用してブロックデバイスをプロビジョニングしている

手順

  • 次のコマンドを実行して、ローカルブロックデバイスを持つ各ノードが OpenShift sandboxed containers ワークロードを実行できるようにします。

    Copy to Clipboard Toggle word wrap
    $ oc debug node/worker-0 -- chcon -vt container_file_t /host/path/to/device

    /path/to/device は、ローカルストレージリソースを作成するときに定義したパスと同じである必要があります。

    出力例

    Copy to Clipboard Toggle word wrap
    system_u:object_r:container_file_t:s0 /host/path/to/device

2.3.2.3. NodeFeatureDiscovery カスタムリソースの作成

NodeFeatureDiscovery カスタムリソース (CR) を作成して、Node Feature Discovery (NFD) Operator がチェックする設定パラメーターを定義して、ワーカーノードが OpenShift Sandboxed Containers をサポートできるかどうかを判断します。

注記

適格であることがわかっている一部のワーカーノードにのみ kata ランタイムをインストールするには、一部のノードに feature.node.kubernetes.io/runtime.kata=true ラベルを適用し、KataConfig CR で checkNodeEligibility: true を設定します。

すべてのワーカーノードに kata ランタイムをインストールするには、KataConfig CR で checkNodeEligibility: false を設定します。

どちらのシナリオでも、NodeFeatureDiscovery CR を作成する必要はありません。ノードが OpenShift sandboxed containers を実行する資格があることが確実な場合にのみ、feature.node.kubernetes.io/runtime.kata=true ラベルを手動で適用する必要があります。

次の手順では、feature.node.kubernetes.io/runtime.kata=true ラベルをすべての適格なノードに適用し、ノードの適格性を確認するように KataConfig リソースを設定します。

前提条件

  • NFD Operator がインストールされている。

手順

  1. 以下の例に従って、nfd.yaml マニフェストファイルを作成します。

    Copy to Clipboard Toggle word wrap
    apiVersion: nfd.openshift.io/v1
    kind: NodeFeatureDiscovery
    metadata:
      name: nfd-kata
      namespace: openshift-nfd
    spec:
      workerConfig:
        configData: |
          sources:
            custom:
              - name: "feature.node.kubernetes.io/runtime.kata"
                matchOn:
                  - cpuId: ["SSE4", "VMX"]
                    loadedKMod: ["kvm", "kvm_intel"]
                  - cpuId: ["SSE4", "SVM"]
                    loadedKMod: ["kvm", "kvm_amd"]
    # ...
  2. NodeFeatureDiscovery CR を作成します。

    Copy to Clipboard Toggle word wrap
    $ oc create -f nfd.yaml

    NodeFeatureDiscovery CR は、feature.node.kubernetes.io/runtime.kata=true ラベルをすべての認定ワーカーノードに適用します。

  1. 次の例に従って、kata-config.yaml マニフェストファイルを作成します。

    Copy to Clipboard Toggle word wrap
    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: example-kataconfig
    spec:
      checkNodeEligibility: true
  2. KataConfig CR を作成します。

    Copy to Clipboard Toggle word wrap
    $ oc create -f kata-config.yaml

検証

  • クラスター内の適格なノードに正しいラベルが適用されていることを確認します。

    Copy to Clipboard Toggle word wrap
    $ oc get nodes --selector='feature.node.kubernetes.io/runtime.kata=true'

    出力例

    Copy to Clipboard Toggle word wrap
    NAME                           STATUS                     ROLES    AGE     VERSION
    compute-3.example.com          Ready                      worker   4h38m   v1.25.0
    compute-2.example.com          Ready                      worker   4h35m   v1.25.0

2.3.3. Kata エージェントポリシーのカスタマイズ

Kata エージェントポリシーは、Kata ランタイムで実行されている Pod のエージェント API 要求を制御するセキュリティーメカニズムです。このポリシーは Rego で記述され、Pod 仮想マシン (VM) 内の Kata エージェントによって適用され、許可または拒否される操作を決定します。

セキュリティーが問題にならない開発やテストなどの特定のユースケースでは、デフォルトのポリシーをカスタムポリシーで上書きできます。たとえば、コントロールプレーンを信頼できる環境で実行する場合があります。カスタムポリシーは、複数の方法で適用できます。

  • ポリシーを Pod VM イメージに組み込む。
  • ピア Pod の config map にパッチを適用する。
  • ワークロード Pod YAML にアノテーションを追加する。

実稼働システムの場合、initdata を使用して Kata エージェントポリシーをオーバーライドする方法が推奨されます。以下の手順では、io.katacontainers.config.agent.policy アノテーションを使用してカスタムポリシーを個々の Pod に適用します。ポリシーは Base64 でエンコードされた Rego 形式で提供されます。このアプローチでは、Pod 仮想マシンイメージを変更せずに、Pod 作成時にデフォルトのポリシーをオーバーライドします。

注記

カスタムポリシーは、デフォルトのポリシーを完全に置き換えます。特定の API のみを変更するには、完全なポリシーを含め、関連するルールを調整します。

手順

  1. カスタムポリシーを含む policy.rego ファイルを作成します。次の例では、デモ用に execlog を有効にした、設定可能なすべての API を示しています。

    Copy to Clipboard Toggle word wrap
    package agent_policy
    
    import future.keywords.in
    import input
    
    default CopyFileRequest := false
    default CreateContainerRequest := false
    default CreateSandboxRequest := true
    default DestroySandboxRequest := true
    default ExecProcessRequest := true  # Enabled to allow exec API
    default GetOOMEventRequest := true
    default GuestDetailsRequest := true
    default OnlineCPUMemRequest := true
    default PullImageRequest := true
    default ReadStreamRequest := true   # Enabled to allow log API
    default RemoveContainerRequest := true
    default RemoveStaleVirtiofsShareMountsRequest := true
    default SignalProcessRequest := true
    default StartContainerRequest := true
    default StatsContainerRequest := true
    default TtyWinResizeRequest := true
    default UpdateEphemeralMountsRequest := true
    default UpdateInterfaceRequest := true
    default UpdateRoutesRequest := true
    default WaitProcessRequest := true
    default WriteStreamRequest := false

    このポリシーは、exec (ExecProcessRequest) および log (ReadStreamRequest) API を有効にします。必要に応じて、true または false の値を調整してポリシーをさらにカスタマイズします。

  2. 次のコマンドを実行して、policy.rego ファイルを Base64 でエンコードされた文字列に変換します。

    Copy to Clipboard Toggle word wrap
    $ base64 -w0 policy.rego

    yaml ファイルで使用するために出力を保存します。

2.3.4. KataConfig カスタムリソースの作成

ワーカーノードに kata をランタイムクラスとしてインストールするには、KataConfig カスタムリソース (CR) を作成する必要があります。

KataConfig CR を作成すると、OpenShift Sandboxed Containers Operator がトリガーされ、以下が実行されます。

  • QEMU および kata-containers など、必要な RHCOS 拡張を RHCOS ノードにインストールします。
  • CRI-O ランタイムが正しいランタイムハンドラーで設定されていることを確認してください。
  • デフォルト設定で kata という名前の RuntimeClass CR を作成します。これにより、ユーザーは、RuntimeClassName フィールドで CR を参照することにより、kata をランタイムとして使用するようにワークロードを設定できます。この CR は、ランタイムのリソースオーバーヘッドも指定します。

OpenShift sandboxed containers は、プライマリーランタイムとしてではなく クラスター上のセカンダリーのオプション ランタイムとして kata をインストールします。

重要

KataConfig CR を作成すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。再起動時間を妨げる要因は次のとおりです。

  • より多くのワーカーノードを持つ大規模な OpenShift Container Platform デプロイメント。
  • BIOS および診断ユーティリティーが有効である。
  • SSD ではなくハードディスクドライブにデプロイしている。
  • 仮想ノードではなく、ベアメタルなどの物理ノードにデプロイしている。
  • CPU とネットワークが遅い。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • オプション: ノードの適格性チェックを有効にする場合は、Node Feature Discovery Operator をインストールしておきます。

手順

  1. 以下の例に従って example-kataconfig.yaml マニフェストファイルを作成します。

    Copy to Clipboard Toggle word wrap
    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: example-kataconfig
    spec:
      checkNodeEligibility: false 
    1
    
      logLevel: info
    #  kataConfigPoolSelector:
    #    matchLabels:
    #      <label_key>: '<label_value>' 
    2
    1
    オプション: ノード適格性チェックを実行するには、`checkNodeEligibility` を true に設定します。
    2
    オプション: 特定のノードに OpenShift sandboxed containers をインストールするためにノードラベルを適用した場合は、キーと値を指定します。
  2. 次のコマンドを実行して、KataConfig CR を作成します。

    Copy to Clipboard Toggle word wrap
    $ oc apply -f example-kataconfig.yaml

    新しい KataConfig CR が作成され、ワーカーノードにランタイムクラスとして kata がインストールされます。

    kata のインストールが完了し、ワーカーノードが再起動するのを待ってから、インストールを検証します。

  3. 次のコマンドを実行して、インストールの進行状況を監視します。

    Copy to Clipboard Toggle word wrap
    $ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"

    kataNodes の下にあるすべてのワーカーのステータスが installed で、理由を指定せずに InProgress の条件が False の場合、kata はクラスターにインストールされます。

2.3.5. Pod オーバーヘッドの変更

Pod のオーバーヘッド では、ノード上の Pod が使用するシステムリソースの量を記述します。RuntimeClass カスタムリソースの spec.overhead フィールドを変更して、Pod のオーバーヘッドを変更できます。たとえば、コンテナーに対する設定が QEMU プロセスおよびゲストカーネルデータでメモリー 350Mi 以上を消費する場合に、RuntimeClass のオーバーヘッドをニーズに合わせて変更できます。

ゲストで種類にかかわらず、ファイルシステム I/O を実行すると、ファイルバッファーがゲストカーネルに割り当てられます。ファイルバッファーは、virtiofsd プロセスだけでなく、ホスト上の QEMU プロセスでもマッピングされます。

たとえば、ゲストでファイルバッファーキャッシュ 300Mi を使用すると、QEMU と virtiofsd の両方が、追加で 300Mi を使用するように見えます。ただし、3 つのケースすべてで同じメモリーが使用されています。したがって、合計メモリー使用量は 3 つの異なる場所にマップされた 300Mi のみです。これは、メモリー使用量メトリックの報告時に適切に考慮されます。

注記

Red Hat はデフォルト値をサポートします。デフォルトのオーバーヘッド値の変更はサポートされておらず、値を変更すると技術的な問題が発生する可能性があります。

手順

  1. 次のコマンドを実行して、RuntimeClass オブジェクトを取得します。

    Copy to Clipboard Toggle word wrap
    $ oc describe runtimeclass kata
  2. overhead.podFixed.memory および cpu の値を更新し、ファイルを runtimeclass.yaml として保存します。

    Copy to Clipboard Toggle word wrap
    kind: RuntimeClass
    apiVersion: node.k8s.io/v1
    metadata:
      name: kata
    overhead:
      podFixed:
        memory: "500Mi"
        cpu: "500m"
  3. 次のコマンドを実行して変更を適用します。

    Copy to Clipboard Toggle word wrap
    $ oc apply -f runtimeclass.yaml

2.3.6. ワークロードオブジェクトの設定

次の Pod テンプレートオブジェクトのランタイムクラスとして kata を設定して、OpenShift sandboxed containers のワークロードオブジェクトを設定する必要があります。

  • Pod オブジェクト
  • ReplicaSet オブジェクト
  • ReplicationController オブジェクト
  • StatefulSet オブジェクト
  • Deployment オブジェクト
  • DeploymentConfig オブジェクト
重要

Operator namespace にワークロードをデプロイしないでください。これらのリソース専用の namespace を作成します。

前提条件

  • KataConfig カスタムリソース (CR) を作成している。

手順

  1. 次の例のように、spec.runtimeClassName: kata を各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに追加します。

    Copy to Clipboard Toggle word wrap
    apiVersion: v1
    kind: <object>
    # ...
    spec:
      runtimeClassName: kata
    # ...

    OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。

検証

  • Pod テンプレートオブジェクトの spec.runtimeClassName フィールドを検査します。値が kata の場合、ワークロードはピア Pod を使用して OpenShift sandboxed containers 上で実行されています。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat, Inc.