3.3. CLI を使用した OpenShift サンドボックスコンテナーワークロードのデプロイ
CLI を使用して、OpenShift サンドボックスコンテナーのワークロードをデプロイできます。まず、OpenShift サンドボックスコンテナー Operator をインストールしてから、KataConfig
カスタムリソースを作成する必要があります。サンドボックスコンテナーにワークロードをデプロイする準備ができたら、ワークロード YAML ファイルに runtimeClassName
として kata
を追加する必要があります。
3.3.1. CLI を使用したサンドボックスコンテナー Operator のインストール
OpenShift Container Platform CLI から OpenShift サンドボックスコンテナー Operator をインストールできます。
前提条件
- OpenShift Container Platform 4.12 をお使いのクラスターがインストールされている。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 OpenShift サンドボックスコンテナーカタログにサブスクライブしている。
注記OpenShift サンドボックスコンテナーカタログにサブスクライブすると、
openshift-sandboxed-containers-operator
namespace の OpenShift サンドボックスコンテナー Operator にアクセスできるようになります。
手順
OpenShift サンドボックスコンテナー Operator の
Namespace
オブジェクトを作成します。次のマニフェストを含む
Namespace
オブジェクト YAML ファイルを作成します。apiVersion: v1 kind: Namespace metadata: name: openshift-sandboxed-containers-operator
Namespace
オブジェクトを作成します。$ oc create -f Namespace.yaml
OpenShift サンドボックスコンテナー Operator の
OperatorGroup
オブジェクトを作成します。次のマニフェストを含む
OperatorGroup
オブジェクト YAML ファイルを作成します。apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: openshift-sandboxed-containers-operator namespace: openshift-sandboxed-containers-operator spec: targetNamespaces: - openshift-sandboxed-containers-operator
OperatorGroup
オブジェクトを作成します。$ oc create -f OperatorGroup.yaml
Subscription
オブジェクトを作成して、Namespace
を OpenShift サンドボックスコンテナー Operator にサブスクライブします。次のマニフェストを含む
Subscription
オブジェクト YAML ファイルを作成します。apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-sandboxed-containers-operator namespace: openshift-sandboxed-containers-operator spec: channel: "stable-1.3" installPlanApproval: Automatic name: sandboxed-containers-operator source: redhat-operators sourceNamespace: openshift-marketplace startingCSV: sandboxed-containers-operator.v1.3.2
Subscription
オブジェクトを作成します。$ oc create -f Subscription.yaml
これで、OpenShift サンドボックスコンテナー Operator がクラスターにインストールされました。
上記のオブジェクトファイル名はすべて提案です。他の名前を使用してオブジェクト YAML ファイルを作成できます。
検証
Operator が正常にインストールされていることを確認します。
$ oc get csv -n openshift-sandboxed-containers-operator
出力例
NAME DISPLAY VERSION REPLACES PHASE openshift-sandboxed-containers openshift-sandboxed-containers-operator 1.3.2 1.3.1 Succeeded
3.3.2. CLI を使用して KataConfig カスタムリソースを作成する
kata
を RuntimeClass
としてノードにインストールするには、1 つの KataConfig
カスタムリソース (CR) を作成する必要があります。KataConfig
CR を作成すると、OpenShift サンドボックス化されたコンテナー Operator がトリガーされ、以下が実行されます。
-
QEMU および
kata-containers
など、必要な RHCOS 拡張を RHCOS ノードにインストールします。 -
ランタイム CRI-O が正しい
kata
ランタイムハンドラーで設定されていることを確認します。 -
デフォルト設定で
kata
という名前のRuntimeClass
CR を作成します。これにより、ユーザーは、RuntimeClassName
フィールドで CR を参照することにより、kata
をランタイムとして使用するようにワークロードを設定できます。この CR は、ランタイムのリソースオーバーヘッドも指定します。
Kata は、デフォルトですべてのワーカーノードにインストールされます。特定のノードにのみ kata
を RuntimeClass
としてインストールする場合は、それらのノードにラベルを追加し、作成時に KataConfig
CR でラベルを定義できます。
前提条件
- クラスターに OpenShift Container Platform 4.12 をインストールしました。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift サンドボックスコンテナー Operator をインストールしました。
KataConfig
CR を作成すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。再起動時間を妨げる要因は次のとおりです。
- より多くのワーカーノードを持つ大規模な OpenShift Container Platform デプロイメント。
- BIOS および診断ユーティリティーのアクティベーション。
- SSD ではなくハードドライブへのデプロイメント。
- 仮想ノードではなく、ベアメタルなどの物理ノードへのデプロイメント。
- 遅い CPU とネットワーク。
手順
次のマニフェストで YAML ファイルを作成します。
apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: cluster-kataconfig spec: checkNodeEligibility: false 1 logLevel: info
- 1
kata
をRuntimeClass
として実行するノードの適格性を検出するには、`checkNodeEligibility` をtrue
に設定します。詳細は、「クラスターノードが OpenShift サンドボックスコンテナーを実行する資格があるかどうかを確認する」を参照してください。
(オプション) 選択したノードにのみ
kata
をRuntimeClass
としてインストールする場合は、マニフェストにラベルを含む YAML ファイルを作成します。apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: cluster-kataconfig spec: checkNodeEligibility: false logLevel: info kataConfigPoolSelector: matchLabels: <label_key>: '<label_value>' 1
- 1
kataConfigPoolSelector
のラベルは単一値のみをサポートします。nodeSelector
構文はサポートされていません。
KataConfig
リソースを作成します。$ oc create -f <file name>.yaml
新しい KataConfig
CR が作成され、ワーカーノードに kata
を RuntimeClass
としてインストールし始めます。kata
のインストールが完了し、ワーカーノードが再起動するのを待ってから、次の手順に進みます。
OpenShift サンドボックスコンテナーは、Kata を主なランタイムとしてではなく、クラスターでセカンダリーオプションのランタイムとしてのみインストールします。
検証
インストールの進捗を監視します。
$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
Is In Progress の値が
false
と表示されたら、インストールは完了です。
関連情報
3.3.3. CLI を使用してサンドボックスコンテナーにワークロードをデプロイする
OpenShift サンドボックスコンテナーは、Kata を主なランタイムとしてではなく、クラスターでセカンダリーオプションのランタイムとしてインストールします。
Pod テンプレート化されたワークロードをサンドボックスコンテナーにデプロイするには、ワークロード YAML ファイルに runtimeClassName
として kata
を追加する必要があります。
前提条件
- クラスターに OpenShift Container Platform 4.12 をインストールしました。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift サンドボックスコンテナー Operator をインストールしました。
-
KataConfig
カスタムリソース (CR) を作成しました。
手順
任意の Pod テンプレートオブジェクトに
runtimeClassName: kata
を追加します。-
Pod
オブジェクト -
ReplicaSet
オブジェクト -
ReplicationController
オブジェクト -
StatefulSet
オブジェクト -
Deployment
オブジェクト -
DeploymentConfig
オブジェクト
-
Pod オブジェクトの例
apiVersion: v1 kind: Pod metadata: name: mypod spec: runtimeClassName: kata
Deployment オブジェクトの例
apiVersion: apps/v1 kind: Deployment metadata: name: mypod labels: app: mypod spec: replicas: 3 selector: matchLabels: app: mypod template: metadata: labels: app: mypod spec: runtimeClassName: kata containers: - name: mypod image: myImage
OpenShift Container Platform はワークロードを作成し、スケジューリングを開始します。
検証
-
Pod テンプレートオブジェクトの
runtimeClassName
フィールドを調べます。runtimeClassName
がkata
の場合、ワークロードは OpenShift サンドボックスコンテナーで実行されています。