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.yamlosc-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.yamlosc-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: false4 volumeMode: Block devicePaths:5 - /path/to/device6 - 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"] # ...NodeFeatureDiscoveryCR を作成します。$ oc create -f nfd.yamlNodeFeatureDiscoveryCR は、feature.node.kubernetes.io/runtime.kata=trueラベルをすべての認定ワーカーノードに適用します。
次の例に従って、
kata-config.yamlマニフェストファイルを作成します。apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: example-kataconfig spec: checkNodeEligibility: trueKataConfigCR を作成します。$ 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という名前のRuntimeClassCR を作成します。これにより、ユーザーは、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: false1 logLevel: info # kataConfigPoolSelector: # matchLabels: # <label_key>: '<label_value>'2 次のコマンドを実行して、
KataConfigCR を作成します。$ oc apply -f example-kataconfig.yaml新しい
KataConfigCR が作成され、ワーカーノードにランタイムクラスとして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 kataoverhead.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 上で実行されています。