3.3. CLI でピア Pod を使用した OpenShift Sandboxed Containers ワークロードのデプロイ
CLI を使用して、OpenShift Sandboxed Containers のワークロードをデプロイできます。まず、OpenShift Sandboxed Containers Operator をインストールしてから、KataConfig
カスタムリソースを作成する必要があります。Sandboxed Containers にワークロードをデプロイする準備ができたら、kata-remote
を runtimeClassName
としてワークロード YAML ファイルに追加する必要があります。
3.3.1. CLI を使用したSandboxed Containers Operator のインストール
OpenShift Container Platform CLI から OpenShift サンドボックスコンテナー Operator をインストールできます。
前提条件
- クラスターに OpenShift Container Platform 4.15 がインストールされている。
IBM Z または IBM® LinuxONE へのインストールには、OpenShift Container Platform 4.14 以降がインストールされている。
重要IBM Z でのピア Pod を使用した OpenShift Sandboxed Containers ワークロードのデプロイは、テクノロジープレビューとしてのみ提供されています。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 OpenShift Sandboxed Containers カタログにサブスクライブしている。
注記OpenShift Sandboxed Containers カタログにサブスクライブすると、
openshift-sandboxed-containers-operator
namespace の OpenShift Sandboxed Containers Operator にアクセスできるようになります。
手順
OpenShift Sandboxed Containers Operator の
Namespace
オブジェクトを作成します。次のマニフェストを含む
Namespace
オブジェクト YAML ファイルを作成します。apiVersion: v1 kind: Namespace metadata: name: openshift-sandboxed-containers-operator
Namespace
オブジェクトを作成します。$ oc create -f Namespace.yaml
OpenShift Sandboxed Containers 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 Sandboxed Containers Operator にサブスクライブします。次のマニフェストを含む
Subscription
オブジェクト YAML ファイルを作成します。apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-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.5.3
Subscription
オブジェクトを作成します。$ oc create -f Subscription.yaml
これで、OpenShift Sandboxed Containers Operator がクラスターにインストールされました。
上記のオブジェクトファイル名はすべて提案です。他の名前を使用してオブジェクト YAML ファイルを作成できます。
検証
Operator が正常にインストールされていることを確認します。
$ oc get csv -n openshift-sandboxed-containers-operator
出力例
NAME DISPLAY VERSION REPLACES PHASE openshift-sandboxed-containers openshift-sandboxed-containers-operator 1.5.3 1.5.2 Succeeded
3.3.2. CLI を使用した AWS のピア Pod の設定
AWS で使用するピア Pod を設定するには、シークレットオブジェクト、AWS イメージ VM (AMI)、およびピア Pod の ConfigMap
を作成する必要があります。
AWS のピア Pod を設定した後に、ピア Pod を使用して OpenShift Sandboxed Containers をデプロイするには、KataConfig
カスタムリソース (CR) を作成する必要があります。
前提条件
- クラスターに OpenShift Container Platform 4.15 がインストールされている。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift Sandboxed Containers Operator をインストールしている。
3.3.2.1. CLI を使用した AWS のシークレットオブジェクトの作成
AWS アクセスキーを指定してシークレットオブジェクトでネットワークを設定します。シークレットオブジェクトは、Pod 仮想マシンイメージの作成に使用され、ピア Pod によって使用されます。
AWS のシークレットオブジェクトを作成するときは、特定の環境値を設定する必要があります。シークレットオブジェクトを作成する前に、これらの値の一部を取得できます。ただし、次の値を準備しておく必要があります。
-
AWS_ACCESS_KEY_ID
-
AWS_SECRET_ACCESS_KEY
これらの値は、AWS コンソールで生成できます。
手順
シークレットオブジェクトに必要なパラメーター値を収集します。それぞれの値を必ず書き留めてください。
インスタンス ID を取得します。
$ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')
この値はシークレットオブジェクト自体には必要ありませんが、シークレットオブジェクトの他の値を取得するために使用されます。
AWS リージョンを取得します。
$ AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}') && echo "AWS_REGION: \"$AWS_REGION\""
AWS サブネット ID を取得します。
$ AWS_SUBNET_ID=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].SubnetId' --region ${AWS_REGION} --output text) && echo "AWS_SUBNET_ID: \"$AWS_SUBNET_ID\""
AWS VPC ID を取得します。
$ AWS_VPC_ID=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].VpcId' --region ${AWS_REGION} --output text) && echo "AWS_VPC_ID: \"$AWS_VPC_ID\""
AWS セキュリティーグループ ID を取得します。
$ AWS_SG_IDS=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' --region $AWS_REGION --output json | jq -r '.[][][]' | paste -sd ",") && echo "AWS_SG_IDS: \"$AWS_SG_IDS\""
次のマニフェストで YAML ファイルを作成します。
apiVersion: v1 kind: Secret metadata: name: peer-pods-secret namespace: openshift-sandboxed-containers-operator type: Opaque stringData: AWS_ACCESS_KEY_ID: "<enter value>" 1 AWS_SECRET_ACCESS_KEY: "<enter value>" 2 AWS_REGION: "<enter value>" 3 AWS_SUBNET_ID: "<enter value>" 4 AWS_VPC_ID: "<enter value>" 5 AWS_SG_IDS: "<enter value>" 6
シークレットオブジェクトを適用します。
$ oc apply -f peer-pods-secret.yaml
シークレットオブジェクトが適用されました。
ピア Pod シークレットを更新する場合は、peerpodconfig-ctrl-caa-daemon
daemonset を再起動して変更を適用する必要があります。
シークレットを更新したら、マニフェストを適用します。次に、以下のコマンドを実行して cloud-api-adaptor
Pod を再起動します。
$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
daemonset を再起動すると、ピア Pod が再作成されるので、既存の Pod は更新されないことに注意してください。
3.3.2.2. CLI を使用した AWS 用のピア Pod ConfigMap の作成
AWS の ConfigMap
を作成するときは、AMI ID を設定する必要があります。この値は、ConfigMap
を作成する前に取得できます。
手順
次のマニフェストで YAML ファイルを作成します。
apiVersion: v1 kind: ConfigMap metadata: name: peer-pods-cm namespace: openshift-sandboxed-containers-operator data: CLOUD_PROVIDER: "aws" VXLAN_PORT: "9000" PODVM_INSTANCE_TYPE: "t3.medium" 1 PODVM_INSTANCE_TYPES: "t2.small,t2.medium,t3.large" 2 PROXY_TIMEOUT: "5m"
ConfigMap
を適用します。$ oc apply -f peer-pods-cm.yaml
ConfigMap
が適用されます。
ピア Pod 設定マップを更新する場合は、peerpodconfig-ctrl-caa-daemon
daemonset を再起動して変更を適用する必要があります。
設定マップを更新したら、マニフェストを適用します。次に、以下のコマンドを実行して cloud-api-adaptor
Pod を再起動します。
$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
daemonset を再起動すると、ピア Pod が再作成されるので、既存の Pod は更新されないことに注意してください。
KataConfig
CR を作成すると、AWS 上のピア Pod を使用して OpenShift Sandboxed Containers を実行できます。
3.3.3. CLI を使用した Azure のピア Pod の設定
Microsoft Azure で使用するピア Pod を設定するには、シークレットオブジェクト、Azure イメージ VM、ピア Pod ConfigMap
、および SSH 鍵のシークレットオブジェクトを作成する必要があります。
Azure のピア Pod を設定した後、ピア Pod を使用して OpenShift Sandboxed Containers をデプロイするには、KataConfig
カスタムリソース (CR) を作成する必要があります。
前提条件
- クラスターに OpenShift Container Platform 4.15 がインストールされている。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift Sandboxed Containers Operator をインストールしている。
- Azure CLI ツールをインストールして設定しておく。
3.3.3.1. CLI を使用した Azure のシークレットオブジェクトの作成
Azure アクセスキーを設定し、シークレットオブジェクトでネットワークを設定します。シークレットオブジェクトは、Pod 仮想マシンイメージの作成に使用され、ピア Pod によって使用されます。
Azure のシークレットオブジェクトを作成するときは、特定の環境値を設定する必要があります。これらの値は、シークレットオブジェクトを作成する前に取得できます。ロールベースのアクセス制御 (RBAC) ファイルも作成する必要があります。このファイルでは以下の値が生成されます。
-
AZURE_CLIENT_ID
-
AZURE_CLIENT_SECRET
-
AZURE_TENANT_ID
手順
Azure サブスクリプション ID を取得します。
$ AZURE_SUBSCRIPTION_ID=$(az account list --query "[?isDefault].id" -o tsv) && echo "AZURE_SUBSCRIPTION_ID: \"$AZURE_SUBSCRIPTION_ID\""
RBAC コンテンツを生成します。これにより、クライアント ID、クライアントシークレット、およびテナント ID が生成されます。
$ az ad sp create-for-rbac --role Contributor --scopes /subscriptions/$AZURE_SUBSCRIPTION_ID --query "{ client_id: appId, client_secret: password, tenant_id: tenant }
以下の出力が表示されます。
{ "client_id": `AZURE_CLIENT_ID`, "client_secret": `AZURE_CLIENT_SECRET`, "tenant_id": `AZURE_TENANT_ID` }
- シークレットオブジェクトで使用するために、RBAC 出力の値を保存します。
シークレットオブジェクトの追加のパラメーター値を収集します。それぞれの値を必ず書き留めてください。
リソースグループを取得します。
$ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}') && echo "AZURE_RESOURCE_GROUP: \"$AZURE_RESOURCE_GROUP\""
Azure リージョンを取得します。
$ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP} --query "{Location:location}" --output tsv) && echo "AZURE_REGION: \"$AZURE_REGION\""
次のマニフェストで YAML ファイルを作成します。
apiVersion: v1 kind: Secret metadata: name: peer-pods-secret namespace: openshift-sandboxed-containers-operator type: Opaque stringData: AZURE_CLIENT_ID: "<enter value>" 1 AZURE_CLIENT_SECRET: "<enter value>" 2 AZURE_TENANT_ID: "<enter value>" 3 AZURE_SUBSCRIPTION_ID: "<enter value>" 4 AZURE_REGION: "<enter value>" 5 AZURE_RESOURCE_GROUP: "<enter value>" 6
シークレットオブジェクトを適用します。
$ oc apply -f peer-pods-secret.yaml
シークレットオブジェクトが適用されました。
ピア Pod シークレットを更新する場合は、peerpodconfig-ctrl-caa-daemon
daemonset を再起動して変更を適用する必要があります。
シークレットを更新したら、マニフェストを適用します。次に、以下のコマンドを実行して cloud-api-adaptor
Pod を再起動します。
$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
daemonset を再起動すると、ピア Pod が再作成されるので、既存の Pod は更新されないことに注意してください。
3.3.3.2. CLI を使用した Azure のピア Pod ConfigMap の作成
Azure の ConfigMap
を作成するときは、特定の設定値を指定する必要があります。これらの値は、ConfigMap
を作成する前に取得できます。
手順
Azure ピア Pod
ConfigMap
の設定値を収集します。それぞれの値を必ず書き留めてください。Azure VNet 名を取得します。
$ AZURE_VNET_NAME=$(az network vnet list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)
この値は
ConfigMap
には必要ありませんが、Azure サブネット ID を取得するために使用されます。Azure サブネット ID を取得します。
$ AZURE_SUBNET_ID=$(az network vnet subnet list --resource-group ${AZURE_RESOURCE_GROUP} --vnet-name $AZURE_VNET_NAME --query "[].{Id:id} | [? contains(Id, 'worker')]" --output tsv) && echo "AZURE_SUBNET_ID: \"$AZURE_SUBNET_ID\""
Azure ネットワークセキュリティーグループ (NSG) ID を取得します。
$ AZURE_NSG_ID=$(az network nsg list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Id:id}" --output tsv) && echo "AZURE_NSG_ID: \"$AZURE_NSG_ID\""
次のマニフェストで YAML ファイルを作成します。
apiVersion: v1 kind: ConfigMap metadata: name: peer-pods-cm namespace: openshift-sandboxed-containers-operator data: CLOUD_PROVIDER: "azure" VXLAN_PORT: "9000" AZURE_INSTANCE_SIZE: "Standard_B2als_v2" 1 AZURE_INSTANCE_SIZES: "Standard_B2als_v2,Standard_D2as_v5,Standard_D4as_v5,Standard_D2ads_v5" 2 AZURE_SUBNET_ID: "<enter value>" 3 AZURE_NSG_ID: "<enter value>" 4 PROXY_TIMEOUT: "5m" DISABLECVM: "true"
ConfigMap
を適用します。$ oc apply -f peer-pods-cm.yaml
ConfigMap
がデプロイされました。
ピア Pod 設定マップを更新する場合は、peerpodconfig-ctrl-caa-daemon
daemonset を再起動して変更を適用する必要があります。
設定マップを更新したら、マニフェストを適用します。次に、以下のコマンドを実行して cloud-api-adaptor
Pod を再起動します。
$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
daemonset を再起動すると、ピア Pod が再作成されるので、既存の Pod は更新されないことに注意してください。
3.3.3.3. CLI を使用した Azure の SSH 鍵のシークレットオブジェクト作成
Azure でピア Pod を使用するには、SSH 鍵を生成し、SSH 鍵のシークレットオブジェクトを作成する必要があります。
手順
SSH 鍵を生成します。
$ ssh-keygen -f ./id_rsa -N ""
SSH シークレットオブジェクトを作成します。
$ 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 鍵が作成され、SSH 鍵のシークレットオブジェクトが作成されます。KataConfig
CR を作成すると、Azure 上のピア Pod を使用して OpenShift Sandboxed Containers を実行できます。
3.3.4. CLI を使用した IBM Z のピア Pod のセットアップ
IBM Z 上で実行している OpenShift Container Platform クラスターで使用するピア Pod をセットアップするには、シークレットオブジェクト、RHEL KVM イメージ仮想マシン、およびピア Pod ConfigMap
を作成する必要があります。これらは、libvirt と KVM ホストとの間の通信に必要な認証情報を保持します。
IBM Z のピア Pod を設定した後に、ピア Pod を使用して OpenShift Sandboxed Containers をデプロイするには、KataConfig
カスタムリソース (CR) を作成する必要があります。
前提条件
- OpenShift Container Platform 4.14 以降がクラスターにインストールされている。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift Sandboxed Containers Operator をインストールしている。
- KVM ホストに libvirt がインストールされており、管理者権限が割り当てられている。
3.3.4.1. KVM ホストでの libvirt のセットアップ
KVM ホスト上に libvirt をセットアップする必要があります。IBM Z 上のピア Pod は、クラウド API アダプターの libvirt プロバイダーを使用して仮想マシンを作成および管理します。
手順
IBM Z KVM ホストにログインし、libvirt がストレージ管理に使用するシェル変数を設定します。
次のコマンドを実行して、libvirt プールの名前を設定します。
$ export LIBVIRT_POOL=<name_of_libvirt_pool_to_create>
次のコマンドを実行して、libvirt プールの名前を設定します。
$ export LIBVIRT_VOL_NAME=<name_of_libvirt_volume_to_create>
次のコマンドを実行して、デフォルトのストレージプールの場所のパスを設定します。
$ export LIBVIRT_POOL_DIRECTORY=<name_of_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
3.3.4.2. IBM Z 用のピア PodVM イメージの作成
IBM Z 上でピア Pod を使用して OpenShift Sandboxed Containers を実行するには、まず、libvirt プロバイダーがピア Pod VM を起動する KVM ゲストを作成する必要があります。
イメージが作成されたら、前の手順で作成したボリュームにイメージをアップロードします。
前提条件
- IBM z15 以降、または IBM® LinuxONE III 以降。
- KVM を備えた RHEL 9 以降で実行している少なくとも 1 つの LPAR。
手順
システムの RHEL
ORG_ID
およびACTIVATION_KEY
シェル変数を設定します。サブスクライブされた RHEL システムを使用する場合は、次のコマンドを実行して、組織 ID と Red Hat Subscription Management (RHSM) のアクティベーションキーを保持するファイルにシェル環境変数を設定します。
$ export ORG_ID=$(cat ~/.rh_subscription/orgid) $ export ACTIVATION_KEY=$(cat ~/.rh_subscription/activation_key)
サブスクライブされていない RHEL システムを使用する場合は、次のコマンドを実行して適切なサブスクリプション値を設定します。
$ export ORG_ID=<RHEL_ORGID_VALUE> $ export ACTIVATION_KEY=<RHEL_ACVTIVATION_KEY>
IBM Z システムにログインし、以下の手順を実行します。
-
s390x
RHEL KVM ゲストイメージを Red Hat カスタマーポータル から libvirt ストレージディレクトリーにダウンロードして、libvirt に正しいアクセスを許可します。デフォルトのディレクトリーは/var/lib/libvirt/images
です。このイメージは、関連するバイナリーを含むピア Pod VM イメージを生成するために使用されます。 次のコマンドを実行して、ダウンロードしたイメージの
IMAGE_URL
シェル環境変数を設定します。$ export IMAGE_URL=<location_of_downloaded_KVM_guest_image> 1
- 1
- 前の手順でダウンロードした KVM ゲストイメージのパスを入力します。
次のコマンドを実行して、ゲスト KVM イメージを登録します。
$ export REGISTER_CMD="subscription-manager register --org=${ORG_ID} \ --activationkey=${ACTIVATION_KEY}"
次のコマンドを実行して、ゲスト KVM イメージをカスタマイズします。
$ virt-customize -v -x -a ${IMAGE_URL} --run-command "${REGISTER_CMD}"
次のコマンドを実行して、イメージのチェックサムを設定します。
$ export IMAGE_CHECKSUM=$(sha256sum ${IMAGE_URL} | awk '{ print $1 }')
-
3.3.4.2.1. ピア Pod VM QCOW2 イメージの構築
IBM Z 上でピア Pod を使用して OpenShift Sandboxed Containers を実行するには、ピア Pod VM QCOW2 イメージを構築する必要があります。
手順
次のコマンドを実行して、cloud-api-adaptor リポジトリーのクローンをビルドワークステーションに作成します。
$ git clone --single-branch https://github.com/confidential-containers/cloud-api-adaptor.git
次のコマンドを実行して、
podvm
ディレクトリーに移動します。$ cd cloud-api-adaptor && git checkout 8577093
最終的な QCOW2 イメージの生成元となるビルダーイメージを作成します。
サブスクライブされた RHEL システムを使用する場合は、次のコマンドを実行します。
$ podman build -t podvm_builder_rhel_s390x \ --build-arg ARCH="s390x" \ --build-arg GO_VERSION="1.21.3" \ --build-arg PROTOC_VERSION="25.1" \ --build-arg PACKER_VERSION="v1.9.4" \ --build-arg RUST_VERSION="1.72.0" \ --build-arg YQ_VERSION="v4.35.1" \ --build-arg YQ_CHECKSUM="sha256:4e6324d08630e7df733894a11830412a43703682d65a76f1fc925aac08268a45" \ -f podvm/Dockerfile.podvm_builder.rhel .
サブスクライブされていない RHEL システムを使用する場合は、次のコマンドを実行します。
$ podman build -t podvm_builder_rhel_s390x \ --build-arg ORG_ID=$ORG_ID \ --build-arg ACTIVATION_KEY=$ACTIVATION_KEY \ --build-arg ARCH="s390x" \ --build-arg GO_VERSION="1.21.3" \ --build-arg PROTOC_VERSION="25.1" \ --build-arg PACKER_VERSION="v1.9.4" \ --build-arg RUST_VERSION="1.72.0" \ --build-arg YQ_VERSION="v4.35.1" \ --build-arg YQ_CHECKSUM="sha256:4e6324d08630e7df733894a11830412a43703682d65a76f1fc925aac08268a45" \ -f podvm/Dockerfile.podvm_builder.rhel .
次のコマンドを実行して、ピア Pod を実行するために必要なバイナリーを含む中間イメージパッケージを生成します。
$ podman build -t podvm_binaries_rhel_s390x \ --build-arg BUILDER_IMG="podvm_builder_rhel_s390x:latest" \ --build-arg ARCH=s390x \ -f podvm/Dockerfile.podvm_binaries.rhel .
注記このプロセスにはかなりの時間がかかることが予想されます。
次のコマンドを実行して、バイナリーを抽出し、ピア Pod QCOW2 イメージを構築します。
$ podman build -t podvm_rhel_s390x \ --build-arg ARCH=s390x \ --build-arg CLOUD_PROVIDER=libvirt \ --build-arg BUILDER_IMG="localhost/podvm_builder_rhel_s390x:latest" \ --build-arg BINARIES_IMG="localhost/podvm_binaries_rhel_s390x:latest" \ -v ${IMAGE_URL}:/tmp/rhel.qcow2:Z \ --build-arg IMAGE_URL="/tmp/rhel.qcow2" \ --build-arg IMAGE_CHECKSUM=${IMAGE_CHECKSUM} \ -f podvm/Dockerfile.podvm.rhel .
次のコマンドを実行して、ピア Pod QCOW2 イメージを選択したディレクトリーに抽出します。
$ export IMAGE_OUTPUT_DIR=<image_output_directory> 1 $ mkdir -p $IMAGE_OUTPUT_DIR $ podman save podvm_rhel_s390x | tar -xO --no-wildcards-match-slash '*.tar' | tar -x -C ${IMAGE_OUTPUT_DIR}
- 1
- 最終的な QCOW イメージを抽出する
image_output_directory
を入力します。
ピア Pod QCOW2 イメージを libvirt ボリュームにアップロードします。
$ virsh -c qemu:///system vol-upload \ --vol $LIBVIRT_VOL_NAME \ $IMAGE_OUTPUT_DIR/podvm-*.qcow2 \ --pool $LIBVIRT_POOL --sparse
3.3.4.3. ピア Pod 認証情報の RHEL シークレットの作成
IBM Z のシークレットオブジェクトを作成するときは、特定の環境値を設定する必要があります。シークレットオブジェクトを作成する前に、これらの値の一部を取得できます。ただし、次の値を準備しておく必要があります。
-
LIBVIRT_POOL
-
LIBVIRT_VOL_NAME
-
LIBVIRT_URI
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}')
手順
次のマニフェストを使用して YAML ファイル
peer-pods-secret.yaml
を作成します。apiVersion: v1 kind: Secret metadata: name: peer-pods-secret namespace: openshift-sandboxed-containers-operator type: Opaque stringData: CLOUD_PROVIDER: "libvirt" 1 LIBVIRT_URI: "<libvirt_gateway_uri>" 2 LIBVIRT_POOL: "<libvirt_pool>" 3 LIBVIRT_VOL_NAME: "<libvirt_volume>" 4
シークレットオブジェクトを作成します。
$ oc apply -f peer-pods-secret.yaml
シークレットオブジェクトが適用されました。
3.3.4.4. CLI を使用した IBM Z のピア Pod ConfigMap の作成
IBM Z の ConfigMap
を作成するときは、libvirt プロバイダーを使用する必要があります。
手順
次のマニフェストを使用して YAML ファイル
peer-pods-cm.yaml
を作成します。apiVersion: v1 kind: ConfigMap metadata: name: peer-pods-cm namespace: openshift-sandboxed-containers-operator data: CLOUD_PROVIDER: "libvirt" PROXY_TIMEOUT: "15m"
ConfigMap
を適用します。$ oc apply -f peer-pods-cm.yaml
ConfigMap
が適用されます。
3.3.4.5. CLI を使用した IBM Z の SSH キーのシークレットオブジェクトの作成
IBM Z でピア Pod を使用するには、SSH 鍵ピアを生成し、SSH 鍵のシークレットオブジェクトを作成する必要があります。
手順
SSH 鍵を生成します。
$ ssh-keygen -f ./id_rsa -N ""
SSH 公開キーを KVM ホストにコピーします。
$ ssh-copy-id -i ./id_rsa.pub <KVM_HOST_ADDRESS> 1
- 1
- KVM ホストの IP アドレスを入力します。
シークレットオブジェクトを作成します。
$ 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
シークレットオブジェクトが作成されます。KataConfig
CR を作成すると、IBM Z 上のピア Pod を使用して OpenShift Sandboxed Containers を実行できます。
3.3.5. CLI を使用した KataConfig カスタムリソースの作成
kata-remote
をノードに RuntimeClass
としてインストールするには、KataConfig
カスタムリソース (CR) を 1 つ作成する必要があります。KataConfig
CR を作成すると、OpenShift Sandboxed Containers Operator がトリガーされ、以下が実行されます。
-
QEMU および
kata-containers
など、必要な RHCOS 拡張を RHCOS ノードにインストールします。 - CRI-O ランタイムが正しいランタイムハンドラーで設定されていることを確認してください。
-
デフォルト設定で
kata-remote
という名前のRuntimeClass
CR を作成します。これにより、RuntimeClassName
フィールドの CR を参照して、kata-remote
をランタイムとして使用するようにワークロードを設定できるようになります。この CR は、ランタイムのリソースオーバーヘッドも指定します。
ピア Pod の Kata は、デフォルトですべてのワーカーノードにインストールされます。kata-remote
を特定のノードにのみ RuntimeClass
としてインストールする場合は、それらのノードにラベルを追加し、作成時に KataConfig
CR でラベルを定義できます。
前提条件
- クラスターに OpenShift Container Platform 4.15 がインストールされている。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift Sandboxed Containers Operator をインストールしている。
KataConfig
CR を作成すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。再起動時間を妨げる要因は次のとおりです。
- より多くのワーカーノードを持つ大規模な OpenShift Container Platform デプロイメント。
- BIOS および診断ユーティリティーが有効である。
- SSD ではなくハードディスクドライブにデプロイしている。
- 仮想ノードではなく、ベアメタルなどの物理ノードにデプロイしている。
- CPU とネットワークが遅い。
手順
次のマニフェストで YAML ファイルを作成します。
apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: cluster-kataconfig spec: enablePeerPods: true logLevel: info
(オプション)
kata-remote
を選択したノードにのみRuntimeClass
としてインストールする場合は、マニフェストにラベルを含む YAML ファイルを作成します。apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: cluster-kataconfig spec: enablePeerPods: true logLevel: info kataConfigPoolSelector: matchLabels: <label_key>: '<label_value>' 1
- 1
kataConfigPoolSelector
のラベルは単一値のみをサポートします。nodeSelector
構文はサポートされていません。
KataConfig
リソースを作成します。$ oc create -f cluster-kataconfig.yaml
新しい KataConfig
CR が作成され、ワーカーノードに RuntimeClass
として kata-remote
をインストールし始めます。kata-remote
のインストールが完了し、ワーカーノードが再起動するまで待ってから、次の手順に進みます。
CR を実行すると、VM イメージが作成されます。イメージの作成はクラウドプロバイダーにより行われ、追加のリソースを使用する場合があります。
OpenShift Sandboxed Containers は、kata-remote
をプライマリーランタイムとしてではなく、クラスター上のセカンダリーオプションのランタイムとしてのみインストールします。
検証
インストールの進捗を監視します。
$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
kataNodes の下のすべてのワーカーが
installs
としてリストされ、理由を指定せずにInProgress
の条件がFalse
の場合は、kata
がクラスターにインストールされていることを示します。詳細は、「移行のインストールとアンインストール」を参照してください。
関連情報
3.3.6. CLI を使用したSandboxed Containers 内のピア Pod を含むワークロードのデプロイ
OpenShift Sandboxed Containers は、Kata をプライマリーランタイムとしてではなく、クラスターでセカンダリーオプションのランタイムとしてインストールします。
Sandboxed Containers 内のピア Pod を使用して Pod テンプレート化されたワークロードをデプロイするには、kata-remote
を runtimeClassName
としてワークロード YAML ファイルに追加する必要があります。
また、YAML ファイルにアノテーションを追加して、ConfigMap
で以前に定義したデフォルトのインスタンスサイズまたはタイプを使用してワークロードをデプロイするかどうかも定義する必要があります。インスタンスサイズまたはインスタンスタイプの使用は、クラウドプロバイダーによって異なります。インスタンスのサイズまたはタイプを手動で定義しない場合は、アノテーションを追加して、使用可能なメモリーに基づいて自動インスタンスのサイズまたはタイプの使用を定義する必要があります。
前提条件
- クラスターに OpenShift Container Platform 4.15 がインストールされている。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift Sandboxed Containers Operator をインストールしている。
-
クラウドプロバイダーに固有のシークレットオブジェクトとピア Pod の
ConfigMap
を作成している。 -
KataConfig
カスタムリソース (CR) を作成している。
手順
runtimeClassName: kata-remote
を Pod でテンプレート化されたオブジェクトに追加します。-
Pod
オブジェクト -
ReplicaSet
オブジェクト -
ReplicationController
オブジェクト -
StatefulSet
オブジェクト -
Deployment
オブジェクト -
DeploymentConfig
オブジェクト
-
Pod のテンプレート化されたオブジェクトにアノテーションを追加し、特定のインスタンスサイズまたはタイプを使用するか、自動インスタンスサイズまたはタイプを使用するかを定義します。インスタンスサイズは特定のクラウドプロバイダーに使用され、インスタンスタイプは他のクラウドプロバイダーに使用されます。
特定のインスタンスのサイズまたはタイプについては、次のアノテーションを追加します。
io.katacontainers.config.hypervisor.machine_type: <instance type/instance size>
ワークロードが使用するインスタンスのサイズまたはタイプを定義します。これらのデフォルトのサイズまたはタイプは、ピア Pod の
ConfigMap
を作成するときに事前に定義してあります。そのうちの 1 つを選択してください。自動インスタンスのサイズまたはタイプについては、次のアノテーションを追加します。
io.katacontainers.config.hypervisor.default_vcpus: <vcpus> io.katacontainers.config.hypervisor.default_memory: <memory>
ワークロードが使用できるメモリーの量を定義します。ワークロードは、使用可能なメモリーの量に基づいて、自動インスタンスサイズまたはタイプで実行されます。
Pod
オブジェクトの例apiVersion: v1 kind: Pod metadata: name: hello-openshift labels: app: hello-openshift annotations: io.katacontainers.config.hypervisor.machine_type: Standard_DC4as_v5 1 spec: runtimeClassName: kata-remote containers: - name: hello-openshift image: quay.io/openshift/origin-hello-openshift ports: - containerPort: 8888 securityContext: privileged: false allowPrivilegeEscalation: false runAsNonRoot: true runAsUser: 1001 capabilities: drop: - ALL seccompProfile: type: RuntimeDefault
- 1
- この例では、Azure を使用してピア Pod に事前に定義されたインスタンスサイズを使用します。AWS を使用するピア Pod はインスタンスタイプを使用します。
OpenShift Container Platform はワークロードを作成し、スケジューリングを開始します。
検証
-
Pod テンプレートオブジェクトの
runtimeClassName
フィールドを調べます。runtimeClassName
がkata-remote
の場合、ワークロードはピア Pod を使用して OpenShift Sandboxed Containers 上で実行されます。