3.3. CLI でピア Pod を使用した OpenShift Sandboxed Containers ワークロードのデプロイ


CLI を使用して、OpenShift Sandboxed Containers のワークロードをデプロイできます。まず、OpenShift Sandboxed Containers Operator をインストールしてから、KataConfig カスタムリソースを作成する必要があります。Sandboxed Containers にワークロードをデプロイする準備ができたら、kata-remoteruntimeClassName としてワークロード 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 にアクセスできるようになります。

手順

  1. OpenShift Sandboxed Containers Operator の Namespace オブジェクトを作成します。

    1. 次のマニフェストを含む Namespace オブジェクト YAML ファイルを作成します。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-sandboxed-containers-operator
    2. Namespace オブジェクトを作成します。

      $ oc create -f Namespace.yaml
  2. OpenShift Sandboxed Containers Operator の OperatorGroup オブジェクトを作成します。

    1. 次のマニフェストを含む 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
    2. OperatorGroup オブジェクトを作成します。

      $ oc create -f OperatorGroup.yaml
  3. Subscription オブジェクトを作成して、Namespace を OpenShift Sandboxed Containers Operator にサブスクライブします。

    1. 次のマニフェストを含む 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
    2. 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 コンソールで生成できます。

手順

  1. シークレットオブジェクトに必要なパラメーター値を収集します。それぞれの値を必ず書き留めてください。

    1. インスタンス ID を取得します。

      $ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')

      この値はシークレットオブジェクト自体には必要ありませんが、シークレットオブジェクトの他の値を取得するために使用されます。

    2. AWS リージョンを取得します。

      $ AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}') && echo "AWS_REGION: \"$AWS_REGION\""
    3. 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\""
    4. 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\""
    5. 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\""
  2. 次のマニフェストで 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
    1
    開始する前に準備した AWS_ACCESS_KEY_ID 値を入力します。
    2
    開始する前に準備した AWS_SECRET_ACCESS_KEY 値を入力します。
    3
    取得した AWS_REGION 値を入力します。
    4
    取得した AWS_SUBNET_ID 値を入力します。
    5
    取得した AWS_VPC_ID 値を入力します。
    6
    取得した AWS_SG_IDS 値を入力します。
  3. シークレットオブジェクトを適用します。

    $ 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 を作成する前に取得できます。

手順

  1. 次のマニフェストで 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"
    1
    ワークロードでタイプが定義されていない場合に使用されるデフォルトのインスタンスタイプを定義します。
    2
    Pod の作成時に指定できるすべてのインスタンスタイプを一覧表示します。これにより、必要なメモリーと CPU が少ないワークロードには小さなインスタンスを定義したり、より大きなワークロードには大きなインスタンスを定義したりできます。
  2. 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

手順

  1. Azure サブスクリプション ID を取得します。

    $ AZURE_SUBSCRIPTION_ID=$(az account list --query "[?isDefault].id" -o tsv) && echo "AZURE_SUBSCRIPTION_ID: \"$AZURE_SUBSCRIPTION_ID\""
  2. 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`
    }
  3. シークレットオブジェクトで使用するために、RBAC 出力の値を保存します。
  4. シークレットオブジェクトの追加のパラメーター値を収集します。それぞれの値を必ず書き留めてください。

    1. リソースグループを取得します。

      $ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}') && echo "AZURE_RESOURCE_GROUP: \"$AZURE_RESOURCE_GROUP\""
    2. Azure リージョンを取得します。

      $ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP} --query "{Location:location}" --output tsv) && echo "AZURE_REGION: \"$AZURE_REGION\""
  5. 次のマニフェストで 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
    1
    RBAC ファイルで生成した AZURE_CLIENT_ID 値を入力します。
    2
    RBAC ファイルで生成した AZURE_CLIENT_SECRET 値を入力します。
    3
    RBAC ファイルで生成した AZURE_TENANT_ID 値を入力します。
    4
    取得した AZURE_SUBSCRIPTION_ID 値を入力します。
    5
    取得した AZURE_REGION 値を入力します。
    6
    取得した AZURE_RESOURCE_GROUP 値を入力します。
  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 を作成する前に取得できます。

手順

  1. Azure ピア Pod ConfigMap の設定値を収集します。それぞれの値を必ず書き留めてください。

    1. Azure VNet 名を取得します。

      $ AZURE_VNET_NAME=$(az network vnet list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)

      この値は ConfigMap には必要ありませんが、Azure サブネット ID を取得するために使用されます。

    2. 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\""
    3. 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\""
  2. 次のマニフェストで 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"
    1
    インスタンスがワークロードに定義されていない場合に使用されるデフォルトのインスタンスサイズを定義します。
    2
    Pod の作成時に指定できるすべてのインスタンスサイズを一覧表示します。これにより、必要なメモリーと CPU が少ないワークロードには小さなインスタンスを定義したり、より大きなワークロードには大きなインスタンスを定義したりできます。
    3
    取得した AZURE_SUBNET_ID 値を入力します。
    4
    取得した AZURE_NSG_ID 値を入力します。
  3. 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 鍵のシークレットオブジェクトを作成する必要があります。

手順

  1. SSH 鍵を生成します。

    $ ssh-keygen -f ./id_rsa -N ""
  2. 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 プロバイダーを使用して仮想マシンを作成および管理します。

手順

  1. IBM Z KVM ホストにログインし、libvirt がストレージ管理に使用するシェル変数を設定します。

    1. 次のコマンドを実行して、libvirt プールの名前を設定します。

      $ export LIBVIRT_POOL=<name_of_libvirt_pool_to_create>
    2. 次のコマンドを実行して、libvirt プールの名前を設定します。

      $ export LIBVIRT_VOL_NAME=<name_of_libvirt_volume_to_create>
    3. 次のコマンドを実行して、デフォルトのストレージプールの場所のパスを設定します。

      $ export LIBVIRT_POOL_DIRECTORY=<name_of_target_directory> 1
      1
      libvirt に読み取りおよび書き込みアクセス許可があることを確認するには、libvirt のストレージディレクトリーのサブディレクトリーを使用します。デフォルトは /var/lib/libvirt/images/ です。
  2. 次のコマンドを実行して、libvirt プールを作成します。

    $ virsh pool-define-as $LIBVIRT_POOL --type dir --target "$LIBVIRT_POOL_DIRECTORY"
  3. 次のコマンドを実行して、libvirt プールを開始します。

    $ virsh pool-start $LIBVIRT_POOL
  4. 次のコマンドを実行して、プールの 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。

手順

  1. システムの RHEL ORG_ID および ACTIVATION_KEY シェル変数を設定します。

    1. サブスクライブされた RHEL システムを使用する場合は、次のコマンドを実行して、組織 ID と Red Hat Subscription Management (RHSM) のアクティベーションキーを保持するファイルにシェル環境変数を設定します。

      $ export ORG_ID=$(cat ~/.rh_subscription/orgid)
      
      $ export ACTIVATION_KEY=$(cat ~/.rh_subscription/activation_key)
    2. サブスクライブされていない RHEL システムを使用する場合は、次のコマンドを実行して適切なサブスクリプション値を設定します。

      $ export ORG_ID=<RHEL_ORGID_VALUE>
      
      $ export ACTIVATION_KEY=<RHEL_ACVTIVATION_KEY>
  2. IBM Z システムにログインし、以下の手順を実行します。

    1. s390x RHEL KVM ゲストイメージを Red Hat カスタマーポータル から libvirt ストレージディレクトリーにダウンロードして、libvirt に正しいアクセスを許可します。デフォルトのディレクトリーは /var/lib/libvirt/images です。このイメージは、関連するバイナリーを含むピア Pod VM イメージを生成するために使用されます。
    2. 次のコマンドを実行して、ダウンロードしたイメージの IMAGE_URL シェル環境変数を設定します。

      $ export IMAGE_URL=<location_of_downloaded_KVM_guest_image> 1
      1
      前の手順でダウンロードした KVM ゲストイメージのパスを入力します。
    3. 次のコマンドを実行して、ゲスト KVM イメージを登録します。

      $ export REGISTER_CMD="subscription-manager register --org=${ORG_ID} \
        --activationkey=${ACTIVATION_KEY}"
    4. 次のコマンドを実行して、ゲスト KVM イメージをカスタマイズします。

      $ virt-customize -v -x -a ${IMAGE_URL} --run-command "${REGISTER_CMD}"
    5. 次のコマンドを実行して、イメージのチェックサムを設定します。

      $ 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 イメージを構築する必要があります。

手順

  1. 次のコマンドを実行して、cloud-api-adaptor リポジトリーのクローンをビルドワークステーションに作成します。

    $ git clone --single-branch https://github.com/confidential-containers/cloud-api-adaptor.git
  2. 次のコマンドを実行して、podvm ディレクトリーに移動します。

    $ cd cloud-api-adaptor && git checkout 8577093
  3. 最終的な QCOW2 イメージの生成元となるビルダーイメージを作成します。

    1. サブスクライブされた 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 .
    2. サブスクライブされていない 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 .
  4. 次のコマンドを実行して、ピア 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 .
    注記

    このプロセスにはかなりの時間がかかることが予想されます。

  5. 次のコマンドを実行して、バイナリーを抽出し、ピア 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 .
  6. 次のコマンドを実行して、ピア 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 を入力します。
  7. ピア 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}')

手順

  1. 次のマニフェストを使用して 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
    1
    クラウドプロバイダーとして libvirt を入力します。
    2
    取得した libvirt_gateway_uri 値を入力します。
    3
    取得した libvirt_pool 値を入力します。
    4
    取得した libvirt_volume 値を入力します。
  2. シークレットオブジェクトを作成します。

    $ oc apply -f peer-pods-secret.yaml

シークレットオブジェクトが適用されました。

3.3.4.4. CLI を使用した IBM Z のピア Pod ConfigMap の作成

IBM Z の ConfigMap を作成するときは、libvirt プロバイダーを使用する必要があります。

手順

  1. 次のマニフェストを使用して 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"
  2. ConfigMap を適用します。

    $ oc apply -f peer-pods-cm.yaml

ConfigMap が適用されます。

3.3.4.5. CLI を使用した IBM Z の SSH キーのシークレットオブジェクトの作成

IBM Z でピア Pod を使用するには、SSH 鍵ピアを生成し、SSH 鍵のシークレットオブジェクトを作成する必要があります。

手順

  1. SSH 鍵を生成します。

    $ ssh-keygen -f ./id_rsa -N ""
  2. SSH 公開キーを KVM ホストにコピーします。

    $ ssh-copy-id -i ./id_rsa.pub <KVM_HOST_ADDRESS> 1
    1
    KVM ホストの IP アドレスを入力します。
  3. シークレットオブジェクトを作成します。

    $ 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
  4. 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 とネットワークが遅い。

手順

  1. 次のマニフェストで YAML ファイルを作成します。

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: cluster-kataconfig
    spec:
      enablePeerPods: true
      logLevel: info
  2. (オプション) 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 構文はサポートされていません。
  3. 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-remoteruntimeClassName としてワークロード YAML ファイルに追加する必要があります。

また、YAML ファイルにアノテーションを追加して、ConfigMap で以前に定義したデフォルトのインスタンスサイズまたはタイプを使用してワークロードをデプロイするかどうかも定義する必要があります。インスタンスサイズまたはインスタンスタイプの使用は、クラウドプロバイダーによって異なります。インスタンスのサイズまたはタイプを手動で定義しない場合は、アノテーションを追加して、使用可能なメモリーに基づいて自動インスタンスのサイズまたはタイプの使用を定義する必要があります。

前提条件

  • クラスターに OpenShift Container Platform 4.15 がインストールされている。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift Sandboxed Containers Operator をインストールしている。
  • クラウドプロバイダーに固有のシークレットオブジェクトとピア Pod の ConfigMap を作成している。
  • KataConfig カスタムリソース (CR) を作成している。

手順

  1. runtimeClassName: kata-remote を Pod でテンプレート化されたオブジェクトに追加します。

    • Pod オブジェクト
    • ReplicaSet オブジェクト
    • ReplicationController オブジェクト
    • StatefulSet オブジェクト
    • Deployment オブジェクト
    • DeploymentConfig オブジェクト
  2. 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 フィールドを調べます。runtimeClassNamekata-remote の場合、ワークロードはピア Pod を使用して OpenShift Sandboxed Containers 上で実行されます。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.