2.3. コマンドラインを使用した OpenShift Sandboxed Containers のデプロイ
コマンドラインインターフェイス (CLI) を使用して次のタスクを実行することにより、ベアメタル上に OpenShift sandboxed containers をデプロイできます。
- OpenShift Sandboxed Containers Operator を再インストールします。
Operator のインストール後に、以下のオプションを設定できます。
- ブロックストレージデバイスを設定します。
ノード適格性チェックを設定するには、Node Feature Discovery (NFD) Operator をインストールします。詳細は、ノードの適格性チェック および NFD Operator ドキュメント を参照してください。
-
NodeFeatureDiscovery
カスタムリソースを作成します。
-
- オプション: Kata エージェントポリシーをカスタマイズします。
-
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
マニフェストファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: v1 kind: Namespace metadata: name: openshift-sandboxed-containers-operator
apiVersion: v1 kind: Namespace metadata: name: openshift-sandboxed-containers-operator
以下のコマンドを実行して namespace を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f osc-namespace.yaml
$ oc apply -f osc-namespace.yaml
osc-operatorgroup.yaml
マニフェストファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: sandboxed-containers-operator-group namespace: openshift-sandboxed-containers-operator spec: targetNamespaces: - openshift-sandboxed-containers-operator
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 グループを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f osc-operatorgroup.yaml
$ oc apply -f osc-operatorgroup.yaml
osc-subscription.yaml
マニフェストファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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
次のコマンドを実行して、サブスクリプションを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f osc-subscription.yaml
$ oc apply -f osc-subscription.yaml
次のコマンドを実行して、Operator が正常にインストールされていることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get csv -n openshift-sandboxed-containers-operator
$ oc get csv -n openshift-sandboxed-containers-operator
このコマンドが完了するまでに数分かかる場合があります。
次のコマンドを実行してプロセスを監視します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow watch oc get csv -n openshift-sandboxed-containers-operator
$ watch oc get csv -n openshift-sandboxed-containers-operator
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NAME DISPLAY VERSION REPLACES PHASE openshift-sandboxed-containers openshift-sandboxed-containers-operator 1.9.0 1.8.1 Succeeded
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 がインストールされている。
以下の条件を満たすローカルディスクがある。
- ノードに接続されている。
- マウントされていない。
- パーティションが含まれていない。
手順
ローカルボリュームリソースを作成します。このリソースは、ノードおよびローカルボリュームへのパスを定義する必要があります。
注記同じデバイスに別のストレージクラス名を使用しないでください。こうすることで、複数の永続ボリューム (PV) が作成されます。
例: ブロック
Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: "local.storage.openshift.io/v1" kind: "LocalVolume" metadata: name: "local-disks" namespace: "openshift-local-storage" spec: nodeSelector: 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" forceWipeDevicesAndDestroyAllData: false volumeMode: Block devicePaths: - /path/to/device
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 クラスターにローカルボリュームリソースを作成します。作成したばかりのファイルを指定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f <local-volume>.yaml
$ oc apply -f <local-volume>.yaml
プロビジョナーが作成され、対応するデーモンセットが作成されていることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get all -n openshift-local-storage
$ oc get all -n openshift-local-storage
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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
の場合、これはラベルセレクターが無効であることを示します。永続ボリュームが作成されていることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get pv
$ oc get pv
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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 Copied! Toggle word wrap Toggle overflow oc debug node/worker-0 -- chcon -vt container_file_t /host/path/to/device
$ oc debug node/worker-0 -- chcon -vt container_file_t /host/path/to/device
/path/to/device
は、ローカルストレージリソースを作成するときに定義したパスと同じである必要があります。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow system_u:object_r:container_file_t:s0 /host/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
マニフェストファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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"] # ...
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 を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc create -f nfd.yaml
$ oc create -f nfd.yaml
NodeFeatureDiscovery
CR は、feature.node.kubernetes.io/runtime.kata=true
ラベルをすべての認定ワーカーノードに適用します。
次の例に従って、
kata-config.yaml
マニフェストファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: example-kataconfig spec: checkNodeEligibility: true
apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: example-kataconfig spec: checkNodeEligibility: true
KataConfig
CR を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc create -f kata-config.yaml
$ oc create -f kata-config.yaml
検証
クラスター内の適格なノードに正しいラベルが適用されていることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get nodes --selector='feature.node.kubernetes.io/runtime.kata=true'
$ oc get nodes --selector='feature.node.kubernetes.io/runtime.kata=true'
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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 のみを変更するには、完全なポリシーを含め、関連するルールを調整します。
手順
カスタムポリシーを含む
policy.rego
ファイルを作成します。次の例では、デモ用にexec
とlog
を有効にした、設定可能なすべての API を示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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
の値を調整してポリシーをさらにカスタマイズします。次のコマンドを実行して、
policy.rego
ファイルを Base64 でエンコードされた文字列に変換します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow base64 -w0 policy.rego
$ 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 をインストールしておきます。
手順
以下の例に従って
example-kataconfig.yaml
マニフェストファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: example-kataconfig spec: checkNodeEligibility: false logLevel: info # kataConfigPoolSelector: # matchLabels: # <label_key>: '<label_value>'
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 を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f example-kataconfig.yaml
$ oc apply -f example-kataconfig.yaml
新しい
KataConfig
CR が作成され、ワーカーノードにランタイムクラスとしてkata
がインストールされます。kata
のインストールが完了し、ワーカーノードが再起動するのを待ってから、インストールを検証します。次のコマンドを実行して、インストールの進行状況を監視します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
$ 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 はデフォルト値をサポートします。デフォルトのオーバーヘッド値の変更はサポートされておらず、値を変更すると技術的な問題が発生する可能性があります。
手順
次のコマンドを実行して、
RuntimeClass
オブジェクトを取得します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc describe runtimeclass kata
$ oc describe runtimeclass kata
overhead.podFixed.memory
およびcpu
の値を更新し、ファイルをruntimeclass.yaml
として保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow kind: RuntimeClass apiVersion: node.k8s.io/v1 metadata: name: kata overhead: podFixed: memory: "500Mi" cpu: "500m"
kind: RuntimeClass apiVersion: node.k8s.io/v1 metadata: name: kata overhead: podFixed: memory: "500Mi" cpu: "500m"
次のコマンドを実行して変更を適用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f runtimeclass.yaml
$ oc apply -f runtimeclass.yaml
2.3.6. ワークロードオブジェクトの設定
次の Pod テンプレートオブジェクトのランタイムクラスとして kata
を設定して、OpenShift sandboxed containers のワークロードオブジェクトを設定する必要があります。
-
Pod
オブジェクト -
ReplicaSet
オブジェクト -
ReplicationController
オブジェクト -
StatefulSet
オブジェクト -
Deployment
オブジェクト -
DeploymentConfig
オブジェクト
Operator namespace にワークロードをデプロイしないでください。これらのリソース専用の namespace を作成します。
前提条件
-
KataConfig
カスタムリソース (CR) を作成している。
手順
次の例のように、
spec.runtimeClassName: kata
を各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow apiVersion: v1 kind: <object> # ... spec: runtimeClassName: kata # ...
apiVersion: v1 kind: <object> # ... spec: runtimeClassName: kata # ...
OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。
検証
-
Pod テンプレートオブジェクトの
spec.runtimeClassName
フィールドを検査します。値がkata
の場合、ワークロードはピア Pod を使用して OpenShift sandboxed containers 上で実行されています。