2.3. コマンドラインを使用した OpenShift Sandboxed Containers のデプロイ
コマンドラインインターフェイス (CLI) を使用して次のタスクを実行することにより、ベアメタル上に OpenShift sandboxed containers をデプロイできます。
- OpenShift Sandboxed Containers Operator を再インストールします。
Operator のインストール後に、以下のオプションを設定できます。
- ブロックストレージデバイスを設定します。
ノード適格性チェックを設定するには、Node Feature Discovery (NFD) Operator をインストールします。詳細は、ノードの適格性チェック および NFD Operator ドキュメント を参照してください。
-
NodeFeatureDiscovery
カスタムリソースを作成します。
-
-
KataConfig
カスタムリソースを作成します。 - オプション: Pod のオーバーヘッドを変更します。
- OpenShift Sandboxed Containers のワークロードオブジェクトを設定します。
2.3.1. OpenShift Sandboxed Containers Operator のインストール
CLI を使用して、OpenShift Sandboxed Containers Operator をインストールできます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
osc-namespace.yaml
マニフェストファイルを作成します。apiVersion: v1 kind: Namespace metadata: name: openshift-sandboxed-containers-operator
以下のコマンドを実行して namespace を作成します。
$ oc apply -f osc-namespace.yaml
osc-operatorgroup.yaml
マニフェストファイルを作成します。apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: sandboxed-containers-operator-group namespace: openshift-sandboxed-containers-operator spec: targetNamespaces: - openshift-sandboxed-containers-operator
以下のコマンドを実行して Operator グループを作成します。
$ oc apply -f osc-operatorgroup.yaml
osc-subscription.yaml
マニフェストファイルを作成します。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.7.0
次のコマンドを実行して、サブスクリプションを作成します。
$ oc apply -f osc-subscription.yaml
次のコマンドを実行して、Operator が正常にインストールされていることを確認します。
$ oc get csv -n openshift-sandboxed-containers-operator
このコマンドが完了するまでに数分かかる場合があります。
次のコマンドを実行してプロセスを監視します。
$ watch oc get csv -n openshift-sandboxed-containers-operator
出力例
NAME DISPLAY VERSION REPLACES PHASE openshift-sandboxed-containers openshift-sandboxed-containers-operator 1.7.0 1.6.0 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 がインストールされている。
以下の条件を満たすローカルディスクがある。
- ノードに接続されている。
- マウントされていない。
- パーティションが含まれていない。
手順
ローカルボリュームリソースを作成します。このリソースは、ノードおよびローカルボリュームへのパスを定義する必要があります。
注記同じデバイスに別のストレージクラス名を使用しないでください。こうすることで、複数の永続ボリューム (PV) が作成されます。
例: ブロック
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 が作成されます。
OpenShift Container Platform クラスターにローカルボリュームリソースを作成します。作成したばかりのファイルを指定します。
$ oc apply -f <local-volume>.yaml
プロビジョナーが作成され、対応するデーモンセットが作成されていることを確認します。
$ oc get all -n openshift-local-storage
出力例
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
の場合、これはラベルセレクターが無効であることを示します。永続ボリュームが作成されていることを確認します。
$ oc get pv
出力例
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 ワークロードを実行できるようにします。
$ oc debug node/worker-0 -- chcon -vt container_file_t /host/path/to/device
/path/to/device
は、ローカルストレージリソースを作成するときに定義したパスと同じである必要があります。出力例
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 がインストールされている。
手順
以下の例に従って、
nfd.yaml
マニフェストファイルを作成します。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"] # ...
NodeFeatureDiscovery
CR を作成します。$ oc create -f nfd.yaml
NodeFeatureDiscovery
CR は、feature.node.kubernetes.io/runtime.kata=true
ラベルをすべての認定ワーカーノードに適用します。
次の例に従って、
kata-config.yaml
マニフェストファイルを作成します。apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: example-kataconfig spec: checkNodeEligibility: true
KataConfig
CR を作成します。$ oc create -f kata-config.yaml
検証
クラスター内の適格なノードに正しいラベルが適用されていることを確認します。
$ oc get nodes --selector='feature.node.kubernetes.io/runtime.kata=true'
出力例
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. 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 をインストールしておきます。
手順
以下の例に従って
example-kataconfig.yaml
マニフェストファイルを作成します。apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: example-kataconfig spec: checkNodeEligibility: false 1 logLevel: info # kataConfigPoolSelector: # matchLabels: # <label_key>: '<label_value>' 2
次のコマンドを実行して、
KataConfig
CR を作成します。$ oc apply -f example-kataconfig.yaml
新しい
KataConfig
CR が作成され、ワーカーノードにランタイムクラスとしてkata
がインストールされます。kata
のインストールが完了し、ワーカーノードが再起動するのを待ってから、インストールを検証します。次のコマンドを実行して、インストールの進行状況を監視します。
$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
kataNodes
の下にあるすべてのワーカーのステータスがinstalled
で、理由を指定せずにInProgress
の条件がFalse
の場合、kata
はクラスターにインストールされます。
2.3.4. Pod オーバーヘッドの変更
Pod のオーバーヘッド では、ノード上の Pod が使用するシステムリソースの量を記述します。RuntimeClass
カスタムリソースの spec.overhead
フィールドを変更して、Pod のオーバーヘッドを変更できます。たとえば、コンテナーに対する設定が QEMU プロセスおよびゲストカーネルデータでメモリー 350Mi 以上を消費する場合に、RuntimeClass
のオーバーヘッドをニーズに合わせて変更できます。
ゲストで種類にかかわらず、ファイルシステム I/O を実行すると、ファイルバッファーがゲストカーネルに割り当てられます。ファイルバッファーは、virtiofsd
プロセスだけでなく、ホスト上の QEMU プロセスでもマッピングされます。
たとえば、ゲストでファイルバッファーキャッシュ 300Mi を使用すると、QEMU と virtiofsd
の両方が、追加で 300Mi を使用するように見えます。ただし、3 つのケースすべてで同じメモリーが使用されています。したがって、合計メモリー使用量は 3 つの異なる場所にマップされた 300Mi のみです。これは、メモリー使用量メトリックの報告時に適切に考慮されます。
Red Hat はデフォルト値をサポートします。デフォルトのオーバーヘッド値の変更はサポートされておらず、値を変更すると技術的な問題が発生する可能性があります。
手順
次のコマンドを実行して、
RuntimeClass
オブジェクトを取得します。$ oc describe runtimeclass kata
overhead.podFixed.memory
およびcpu
の値を更新し、ファイルをruntimeclass.yaml
として保存します。kind: RuntimeClass apiVersion: node.k8s.io/v1 metadata: name: kata overhead: podFixed: memory: "500Mi" cpu: "500m"
次のコマンドを実行して変更を適用します。
$ oc apply -f runtimeclass.yaml
2.3.5. ワークロードオブジェクトの設定
次の Pod テンプレートオブジェクトのランタイムクラスとして kata
を設定して、OpenShift sandboxed containers のワークロードオブジェクトを設定する必要があります。
-
Pod
オブジェクト -
ReplicaSet
オブジェクト -
ReplicationController
オブジェクト -
StatefulSet
オブジェクト -
Deployment
オブジェクト -
DeploymentConfig
オブジェクト
Operator namespace にワークロードをデプロイしないでください。これらのリソース専用の namespace を作成します。
前提条件
-
KataConfig
カスタムリソース (CR) を作成している。
手順
次の例のように、
spec.runtimeClassName: kata
を各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに追加します。apiVersion: v1 kind: <object> # ... spec: runtimeClassName: kata # ...
OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。
検証
-
Pod テンプレートオブジェクトの
spec.runtimeClassName
フィールドを検査します。値がkata
の場合、ワークロードはピア Pod を使用して OpenShift sandboxed containers 上で実行されています。