5.2. IBM Z および IBM LinuxONE への OpenShift Sandboxed Containers のデプロイ
コマンドラインインターフェイス (CLI) を使用して次のタスクを実行することにより、OpenShift sandboxed containers を IBM Z® および IBM® LinuxONE にデプロイできます。
- OpenShift Sandboxed Containers Operator を再インストールします。
- オプション: 各ワーカーノードで実行されている仮想マシンの数を変更します。
- libvirt ボリュームを設定します。
- オプション: カスタムピア Pod 仮想マシンイメージを作成します。
- ピア Pod シークレットを作成します。
- ピア Pod の config map を作成します。
- ピア Pod 仮想マシンイメージ config map を作成します。
- KVM ホストシークレットを作成します。
-
KataConfig
カスタムリソースを作成します。 - OpenShift Sandboxed Containers のワークロードオブジェクトを設定します。
5.2.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
5.2.2. ノードあたりのピア Pod 仮想マシン数の変更
peerpodConfig
カスタムリソース (CR) を編集することで、ノードあたりのピア Pod 仮想マシン (VM) の制限を変更できます。
手順
次のコマンドを実行して、現在の制限を確認します。
$ oc get peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \ -o jsonpath='{.spec.limit}{"\n"}'
次のコマンドを実行して、
peerpodConfig
CR のlimit
属性を変更します。$ oc patch peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \ --type merge --patch '{"spec":{"limit":"<value>"}}' 1
- 1
- <value> は、定義する制限に置き換えます。
5.2.3. libvirt ボリュームの設定
KVM ホストに libvirt ボリュームを設定する必要があります。ピア Pod は、Cloud API アダプターの libvirt プロバイダーを使用して仮想マシンを作成および管理します。
前提条件
- OpenShift Container Platform Web コンソールまたはコマンドラインを使用して、OpenShift Container Platform クラスターに OpenShift sandboxed containers Operator をインストールしている。
- KVM ホストの管理者権限がある。
-
KVM ホストに
podman
がインストールされている。 -
KVM ホストに
virt-customize
がインストールされている。
手順
- KVM ホストにログインします。
次のコマンドを実行して、libvirt プールの名前を設定します。
$ export LIBVIRT_POOL=<libvirt_pool>
libvirt プロバイダーのシークレットを作成するには、
LIBVIRT_POOL
値が必要です。次のコマンドを実行して、libvirt プールの名前を設定します。
$ export LIBVIRT_VOL_NAME=<libvirt_volume>
libvirt プロバイダーのシークレットを作成するには、
LIBVIRT_VOL_NAME
値が必要です。次のコマンドを実行して、デフォルトのストレージプールの場所のパスを設定します。
$ export LIBVIRT_POOL_DIRECTORY=<target_directory> 1
- 1
- libvirt に読み取りおよび書き込みアクセス権限があることを確認するには、libvirt ストレージディレクトリーのサブディレクトリーを使用します。デフォルトは
/var/lib/libvirt/images/
です。
次のコマンドを実行して、libvirt プールを作成します。
$ virsh pool-define-as $LIBVIRT_POOL --type dir --target "$LIBVIRT_POOL_DIRECTORY"
次のコマンドを実行して、libvirt プールを開始します。
$ virsh pool-start $LIBVIRT_POOL
次のコマンドを実行して、プールの libvirt ボリュームを作成します。
$ virsh -c qemu:///system \ vol-create-as --pool $LIBVIRT_POOL \ --name $LIBVIRT_VOL_NAME \ --capacity 20G \ --allocation 2G \ --prealloc-metadata \ --format qcow2
5.2.4. カスタムピア Pod 仮想マシンイメージの作成
デフォルトの Operator ビルドイメージを使用する代わりに、カスタムピア Pod 仮想マシン (VM) イメージを作成できます。
ピア Pod QCOW2 イメージを使用して Open Container Initiative (OCI) コンテナーを構築します。後で、コンテナーレジストリー URL とイメージパスをピア Pod 仮想マシンイメージ config map に追加します。
手順
Dockerfile.podvm-oci
ファイルを作成します。FROM scratch ARG PODVM_IMAGE_SRC ENV PODVM_IMAGE_PATH="/image/podvm.qcow2" COPY $PODVM_IMAGE_SRC $PODVM_IMAGE_PATH
次のコマンドを実行して、Pod 仮想マシン QCOW2 イメージを含むコンテナーを構築します。
$ docker build -t podvm-libvirt \ --build-arg PODVM_IMAGE_SRC=<podvm_image_source> \ 1 --build-arg PODVM_IMAGE_PATH=<podvm_image_path> \ 2 -f Dockerfile.podvm-oci .
5.2.5. ピア Pod シークレットの作成
OpenShift Sandboxed Containers のピア Pod シークレットを作成する必要があります。
シークレットには、Pod 仮想マシン (VM) イメージとピア Pod インスタンスを作成するための認証情報が保存されます。
デフォルトでは、OpenShift Sandboxed Containers Operator はクラスターの作成に使用される認証情報に基づいてシークレットを作成します。ただし、異なる認証情報を使用するシークレットを手動で作成することはできます。
前提条件
-
LIBVIRT_POOL
。KVM ホストで libvirt を設定したときに設定した値を使用します。 -
LIBVIRT_VOL_NAME
。KVM ホストで libvirt を設定したときに設定した値を使用します。 LIBVIRT_URI
。この値は、libvirt ネットワークのデフォルトのゲートウェイ IP アドレスです。この値を取得するには、libvirt ネットワーク設定を確認してください。注記libvirt がデフォルトのブリッジ仮想ネットワークを使用する場合は、以下のコマンドを実行して
LIBVIRT_URI
を取得できます。$ virtint=$(bridge_line=$(virsh net-info default | grep Bridge); echo "${bridge_line//Bridge:/}" | tr -d [:blank:]) $ LIBVIRT_URI=$( ip -4 addr show $virtint | grep -oP '(?<=inet\s)\d+(\.\d+){3}') $ LIBVIRT_GATEWAY_URI="qemu+ssh://root@${LIBVIRT_URI}/system?no_verify=1"
-
REDHAT_OFFLINE_TOKEN
。Red Hat API トークン で RHEL イメージをダウンロードするためにこのトークンを生成している。
手順
次の例に従って
peer-pods-secret.yaml
マニフェストファイルを作成します。apiVersion: v1 kind: Secret metadata: name: peer-pods-secret namespace: openshift-sandboxed-containers-operator type: Opaque stringData: CLOUD_PROVIDER: "libvirt" LIBVIRT_URI: "<libvirt_gateway_uri>" 1 LIBVIRT_POOL: "<libvirt_pool>" 2 LIBVIRT_VOL_NAME: "<libvirt_volume>" 3 REDHAT_OFFLINE_TOKEN: "<rh_offline_token>" 4
以下のコマンドを実行してシークレットを作成します。
$ oc apply -f peer-pods-secret.yaml
5.2.6. ピア Pod config map の作成
OpenShift sandboxed containers のピア Pod config map を作成する必要があります。
手順
以下の例に従って
peer-pods-cm.yaml
マニフェストファイルを作成します。apiVersion: v1 kind: ConfigMap metadata: name: peer-pods-cm namespace: openshift-sandboxed-containers-operator data: CLOUD_PROVIDER: "libvirt" DISABLECVM: "true"
以下のコマンドを実行して config map を作成します。
$ oc apply -f peer-pods-cm.yaml
5.2.7. ピア Pod 仮想マシンイメージ config map の作成
ピア Pod 仮想マシンイメージの config map を作成する必要があります。
手順
次の例に従って、
libvirt-podvm-image-cm.yaml
マニフェストを作成します。apiVersion: v1 kind: ConfigMap metadata: name: libvirt-podvm-image-cm namespace: openshift-sandboxed-containers-operator data: PODVM_DISTRO: "rhel" CAA_SRC: "https://github.com/confidential-containers/cloud-api-adaptor" CAA_REF: "<cloud_api_adaptor_version>" 1 DOWNLOAD_SOURCES: "no" CONFIDENTIAL_COMPUTE_ENABLED: "yes" UPDATE_PEERPODS_CM: "yes" ORG_ID: "<rhel_organization_id>" ACTIVATION_KEY: "<rhel_activation_key>" 2 IMAGE_NAME: "<podvm_libvirt_image>" PODVM_IMAGE_URI: "oci::<image_repo_url>:<image_tag>::<image_path>" 3 SE_BOOT: "true" 4 BASE_OS_VERSION: "<rhel_image_os_version>" 5
- 1
- Cloud API Adaptor ソースの最新バージョンを指定します。
- 2
- RHEL アクティベーションキーを指定します。
- 3
- オプション: コンテナーイメージを作成した場合は、次の値を指定します。
-
image_repo_url
: コンテナーレジストリー URL。 -
image_tag
: イメージタグ。 -
image_path
: イメージパス。デフォルト:/image/podvm.qcow2
。
-
- 4
SE_BOOT: "true"
は、Operator が構築したイメージに対して IBM Secure Execution を有効にします。コンテナーイメージを作成した場合は、false
に設定します。- 5
- RHEL イメージのオペレーティングシステムのバージョンを指定します。IBM Z® Secure Execution は、RHEL 9.4 以降のバージョンをサポートしています。
以下のコマンドを実行して config map を作成します。
$ oc apply -f libvirt-podvm-image-cm.yaml
libvirt プロバイダー用に libvirt Pod 仮想マシンイメージ config map が作成されます。
5.2.8. KVM ホストシークレットの作成
KVM ホストのシークレットを作成する必要があります。
手順
次のコマンドを実行して、SSH キーペアを生成します。
$ ssh-keygen -f ./id_rsa -N ""
SSH 公開鍵を KVM ホストにコピーします。
$ ssh-copy-id -i ./id_rsa.pub <KVM_HOST_IP>
以下のコマンドを実行して
Secret
オブジェクトを作成します。$ oc create secret generic ssh-key-secret \ -n openshift-sandboxed-containers-operator \ --from-file=id_rsa.pub=./id_rsa.pub \ --from-file=id_rsa=./id_rsa
作成した SSH 鍵を削除します。
$ shred --remove id_rsa.pub id_rsa
5.2.9. KataConfig カスタムリソースの作成
ワーカーノードに kata-remote
をランタイムクラスとしてインストールするには、KataConfig
カスタムリソース (CR) を作成する必要があります。
KataConfig
CR を作成すると、OpenShift Sandboxed Containers Operator がトリガーされ、以下が実行されます。
-
デフォルト設定で
kata-remote
という名前のRuntimeClass
CR を作成します。これにより、RuntimeClassName
フィールドの CR を参照して、kata-remote
をランタイムとして使用するようにワークロードを設定できるようになります。この CR は、ランタイムのリソースオーバーヘッドも指定します。
OpenShift Sandboxed Containers は、kata-remote
をプライマリーランタイムとしてではなく、クラスター上の セカンダリーオプション のランタイムとしてインストールします。
KataConfig
CR を作成すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。再起動時間を妨げる要因は次のとおりです。
- より多くのワーカーノードを持つ大規模な OpenShift Container Platform デプロイメント。
- BIOS および診断ユーティリティーが有効である。
- SSD ではなくハードディスクドライブにデプロイしている。
- 仮想ノードではなく、ベアメタルなどの物理ノードにデプロイしている。
- CPU とネットワークが遅い。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
以下の例に従って
example-kataconfig.yaml
マニフェストファイルを作成します。apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: example-kataconfig spec: enablePeerPods: true logLevel: info # kataConfigPoolSelector: # matchLabels: # <label_key>: '<label_value>' 1
- 1
- オプション: 特定のノードに
kata-remote
をインストールするためにノードラベルを適用した場合は、キーと値を指定します (例:osc: 'true')
。
次のコマンドを実行して、
KataConfig
CR を作成します。$ oc apply -f example-kataconfig.yaml
新しい
KataConfig
CR が作成され、ワーカーノードにkata-remote
がランタイムクラスとしてインストールされます。インストールを確認する前に、
kata-remote
のインストールが完了し、ワーカーノードが再起動するまで待ちます。次のコマンドを実行して、インストールの進行状況を監視します。
$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
kataNodes
の下にあるすべてのワーカーのステータスがinstalled
で、理由を指定せずにInProgress
の条件がFalse
の場合、kata
はクラスターにインストールされます。次のコマンドを実行して、ピア Pod イメージが構築され、libvirt ボリュームにアップロードされたことを確認します。
$ oc describe configmap peer-pods-cm -n openshift-sandboxed-containers-operator
出力例
Name: peer-pods-cm Namespace: openshift-sandboxed-containers-operator Labels: <none> Annotations: <none> Data ==== CLOUD_PROVIDER: libvirt BinaryData ==== Events: <none>
次のコマンドを実行して、
kata-oc
マシン設定プールの進行状況を監視し、UPDATEDMACHINECOUNT
がMACHINECOUNT
と等しいときにUPDATED
状態であることを確認します。$ watch oc get mcp/kata-oc
次のコマンドを実行してデーモンセットを確認します。
$ oc get -n openshift-sandboxed-containers-operator ds/peerpodconfig-ctrl-caa-daemon
次のコマンドを実行してランタイムクラスを確認します。
$ oc get runtimeclass
出力例
NAME HANDLER AGE kata kata 152m kata-remote kata-remote 152m
5.2.10. ワークロードオブジェクトの設定
次の Pod テンプレートオブジェクトのランタイムクラスとして kata-remote
を設定して、OpenShift sandboxed containers のワークロードオブジェクトを設定する必要があります。
-
Pod
オブジェクト -
ReplicaSet
オブジェクト -
ReplicationController
オブジェクト -
StatefulSet
オブジェクト -
Deployment
オブジェクト -
DeploymentConfig
オブジェクト
Operator namespace にワークロードをデプロイしないでください。これらのリソース専用の namespace を作成します。
前提条件
-
KataConfig
カスタムリソース (CR) を作成している。
手順
次の例のように、各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに
spec.runtimeClassName: kata-remote
を追加します。apiVersion: v1 kind: <object> # ... spec: runtimeClassName: kata-remote # ...
OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。
検証
-
Pod テンプレートオブジェクトの
spec.runtimeClassName
フィールドを検査します。値がkata-remote
の場合、ワークロードはピア Pod を使用して OpenShift Sandboxed Containers で実行されています。