4.2. Web コンソールを使用した OpenShift Sandboxed Containers のデプロイ


OpenShift Container Platform Web コンソールを使用して次のタスクを実行することで、Azure に OpenShift sandboxed containers をデプロイできます。

  1. OpenShift Sandboxed Containers Operator を再インストールします。
  2. ピア Pod シークレットを作成します。
  3. ピア Pod の config map を作成します。
  4. Azure シークレットを作成します。
  5. KataConfig カスタムリソースを作成します。
  6. OpenShift Sandboxed Containers のワークロードオブジェクトを設定します。

4.2.1. OpenShift Sandboxed Containers Operator のインストール

OpenShift Container Platform Web コンソールを使用して、OpenShift sandboxed containers Operator をインストールできます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. Web コンソールで、Operators OperatorHub に移動します。
  2. Filter by keyword フィールドに OpenShift sandboxed containers と入力します。
  3. OpenShift sandboxed containers Operator タイルを選択し、Install をクリックします。
  4. Install Operator ページで、利用可能な Update Channel オプションの一覧から stable を選択します。
  5. Installed NamespaceOperator recommend Namespace が選択されていることを確認します。これにより、Operator が必須の openshift-sandboxed-containers-operator namespace にインストールされます。この namespace がまだ存在しない場合は、自動的に作成されます。

    注記

    OpenShift Sandboxed Containers Operator を openshift-sandboxed-containers-operator 以外の namespace にインストールしようとすると、インストールに失敗します。

  6. Approval StrategyAutomatic が選択されていることを確認します。Automatic がデフォルト値であり、新しい z-stream リリースが利用可能になると、OpenShift Sandboxed Containers への自動更新が有効になります。
  7. Install をクリックします。
  8. Operator Installed Operator に移動して、Operator がインストールされていることを確認します。

4.2.2. ピア Pod シークレットの作成

OpenShift Sandboxed Containers のピア Pod シークレットを作成する必要があります。

シークレットには、Pod 仮想マシン (VM) イメージとピア Pod インスタンスを作成するための認証情報が保存されます。

デフォルトでは、OpenShift Sandboxed Containers Operator はクラスターの作成に使用される認証情報に基づいてシークレットを作成します。ただし、異なる認証情報を使用するシークレットを手動で作成することはできます。

前提条件

  • Azure CLI ツールをインストールして設定している。

手順

  1. 次のコマンドを実行して、Azure サブスクリプション ID を取得します。

    $ AZURE_SUBSCRIPTION_ID=$(az account list --query "[?isDefault].id" \
      -o tsv) && echo "AZURE_SUBSCRIPTION_ID: \"$AZURE_SUBSCRIPTION_ID\""
  2. 次のコマンドを実行して RBAC コンテンツを生成します。

    $ 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. secret オブジェクトで使用する RBAC 出力を記録します。
  4. OpenShift Container Platform Web コンソールで、Operators Installed Operators に移動します。
  5. OpenShift sandboxed containers Operator タイルをクリックします。
  6. 右上隅のインポートアイコン (+) をクリックします。
  7. Import YAML ウィンドウに、次の YAML マニフェストを貼り付けます。

    apiVersion: v1
    kind: Secret
    metadata:
      name: peer-pods-secret
      namespace: openshift-sandboxed-containers-operator
    type: Opaque
    stringData:
      AZURE_CLIENT_ID: "<azure_client_id>" 1
      AZURE_CLIENT_SECRET: "<azure_client_secret>" 2
      AZURE_TENANT_ID: "<azure_tenant_id>" 3
      AZURE_SUBSCRIPTION_ID: "<azure_subscription_id>" 4
    1
    AZURE_CLIENT_ID 値を指定します。
    2
    AZURE_CLIENT_SECRET 値を指定します。
    3
    AZURE_TENANT_ID 値を指定します。
    4
    AZURE_SUBSCRIPTION_ID 値を指定します。
  8. Save をクリックして変更を適用します。
  9. Workloads Secrets に移動して、ピア Pod シークレットを確認します。

4.2.3. ピア Pod config map の作成

OpenShift sandboxed containers のピア Pod config map を作成する必要があります。

手順

  1. Azure インスタンスから以下の値を取得します。

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

      $ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}') && echo "AZURE_RESOURCE_GROUP: \"$AZURE_RESOURCE_GROUP\""
    2. Azure VNet 名を取得し、記録します。

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

      この値は、Azure サブネット ID を取得するために使用されます。

    3. 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\""
    4. 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\""
    5. Azure リージョンを取得して記録します。

      $ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP} --query "{Location:location}" --output tsv) && echo "AZURE_REGION: \"$AZURE_REGION\""
  2. OpenShift Container Platform Web コンソールで、Operators Installed Operators に移動します。
  3. Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
  4. 右上隅にあるインポートアイコン (+) をクリックします。
  5. Import YAML ウィンドウに、次の 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: "<azure_subnet_id>" 3
      AZURE_NSG_ID: "<azure_nsg_id>" 4
      PROXY_TIMEOUT: "5m"
      AZURE_IMAGE_ID: "<azure_image_id>" 5
      AZURE_REGION: "<azure_region>" 6
      AZURE_RESOURCE_GROUP: "<azure_resource_group>" 7
      DISABLECVM: "true"
    1
    ワークロードでインスタンスサイズが定義されていない場合、この値がデフォルトになります。
    2
    Pod の作成時に指定できるすべてのインスタンスサイズを一覧表示します。これにより、メモリーと CPU をあまり必要としないワークロードには小さいインスタンスサイズを定義したり、ワークロードが大きい場合は大きいインスタンスサイズを定義したりすることができます。
    3
    取得した AZURE_SUBNET_ID 値を指定します。
    4
    取得した AZURE_NSG_ID 値を指定します。
    5
    オプション: デフォルトでは、この値は、クラスターの認証情報に基づく Azure イメージ ID を使用して KataConfig CR を実行するときに入力されます。独自の Azure イメージを作成する場合は、正しいイメージ ID を指定します。
    6
    取得した AZURE_REGION 値を指定します。
    7
    取得した AZURE_RESOURCE_GROUP 値を指定します。
  6. Save をクリックして変更を適用します。
  7. 新しい config map を表示するには、Workloads ConfigMaps に移動します。

4.2.4. Azure シークレットの作成

Azure 仮想マシン(VM)作成 API で必要な SSH キーシークレットを作成する必要があります。Azure には SSH 公開キーのみが必要です。Confidential Containers は VM の SSH を無効にするため、キーは VM には影響しません。

手順

  1. 次のコマンドを実行して、SSH キーペアを生成します。

    $ ssh-keygen -f ./id_rsa -N ""
  2. OpenShift Container Platform Web コンソールで、Workloads Secrets に移動します。
  3. Secrets ページで、openshift-sandboxed-containers-operator プロジェクトにいることを確認します。
  4. Create をクリックし、Key/value secret を選択します。
  5. Secret name フィールドに ssh-key-secret と入力します。
  6. Key フィールドに id_rsa.pub と入力します。
  7. Value フィールドに、公開 SSH 鍵を貼り付けます。
  8. Create をクリックします。
  9. 作成した SSH 鍵を削除します。

    $ shred --remove id_rsa.pub id_rsa

4.2.5. KataConfig カスタムリソースの作成

ワーカーノードに kata-remoteRuntimeClass としてインストールするには、KataConfig カスタムリソース (CR) を作成する必要があります。

kata-remote ランタイムクラスは、デフォルトですべてのワーカーノードにインストールされます。kata-remote を特定のノードにのみインストールする場合は、それらのノードにラベルを追加し、KataConfig CR でラベルを定義できます。

OpenShift Sandboxed Containers は、kata-remote をプライマリーランタイムとしてではなく、クラスター上の セカンダリーオプション のランタイムとしてインストールします。

重要

KataConfig CR を作成すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。次の要因により再起動時間が長くなる可能性があります。

  • より多くのワーカーノードを持つ大規模な OpenShift Container Platform デプロイメント。
  • BIOS および診断ユーティリティーが有効である。
  • SSD ではなくハードディスクドライブにデプロイしている。
  • 仮想ノードではなく、ベアメタルなどの物理ノードにデプロイしている。
  • CPU とネットワークが遅い。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • オプション: ノードの適格性チェックを有効にする場合は、Node Feature Discovery Operator をインストールしておきます。

手順

  1. OpenShift Container Platform Web コンソールで、Operators Installed Operators に移動します。
  2. OpenShift sandboxed containers Operator を選択します。
  3. KataConfig タブで、Create KataConfig をクリックします。
  4. 以下の詳細を入力します。

    • Name: オプション: デフォルト名は example-kataconfig です。
    • Labels: オプション: 関連する識別属性を KataConfig リソースに入力します。各ラベルはキーと値のペアを表します。
    • enablePeerPods: パブリッククラウド、IBM Z®、および IBM® LinuxONE デプロイメントの場合に選択します。
    • kataConfigPoolSelector。オプション: 選択したノードに kata-remote をインストールするには、選択したノードのラベルに一致する式を追加します。

      1. kataConfigPoolSelector エリアを展開します。
      2. kataConfigPoolSelector エリアで、matchExpressions を展開します。これは、ラベルセレクターの要件のリストです。
      3. Add matchExpressions をクリックします。
      4. Key フィールドに、セレクターの適用先のラベルキーを入力します。
      5. Operator フィールドに、キーとラベル値の関係を入力します。有効な演算子は、InNotInExistsDoesNotExist です。
      6. Values エリアを展開し、Add value をクリックします。
      7. Value フィールドで、true または falsekey ラベル値として入力します。
    • logLevel: ランタイムクラスが kata-remote のノードに対して取得されるログデータのレベルを定義します。
  5. Create をクリックします。KataConfig CR が作成され、ワーカーノードに kata-remote ランタイムクラスをインストールします。

    インストールを確認する前に、kata-remote のインストールが完了し、ワーカーノードが再起動するまで待ちます。

検証

  1. KataConfig タブで、KataConfig CR をクリックして詳細を表示します。
  2. YAML タブをクリックして status スタンザを表示します。

    status スタンザには、conditions および kataNodes キーが含まれています。status.kataNodes の値はノード配列であり、各ノードには kata-remote インストールの特定の状態にあるノードがリストされます。更新があるたびにメッセージが表示されます。

  3. Reload をクリックして、YAML を更新します。

    status.kataNodes 配列内のすべてのワーカーに、値 installed と、理由が指定されていない conditions.InProgress: False が表示される場合、kata-remote はクラスターにインストールされています。

関連情報
Pod VM イメージの確認

kata-remote がクラスターにインストールされると、OpenShift sandboxed containers Operator は、ピア Pod の作成に使用される Pod 仮想マシンイメージを作成します。イメージがクラウドインスタンス上に作成されるため、このプロセスには時間がかかる場合があります。クラウドプロバイダー用に作成した config map を確認し、Pod 仮想マシンイメージが正常に作成されたことを確認できます。

手順

  1. Workloads ConfigMaps に移動します。
  2. プロバイダー config map をクリックすると、詳細が表示されます。
  3. YAML タブをクリックします。
  4. YAML ファイルの status スタンザを確認します。

    AZURE_IMAGE_ID パラメーターが入力されている場合は、Pod 仮想マシンイメージが正常に作成されています。

トラブルシューティング

  1. 次のコマンドを実行してイベントログを取得します。

    $ oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation
  2. 次のコマンドを実行して、ジョブログを取得します。

    $ oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creation

問題を解決できない場合は、Red Hat サポートケースを送信し、両方のログの出力を添付してください。

4.2.6. ワークロードオブジェクトの設定

次の Pod テンプレートオブジェクトのランタイムクラスとして kata-remote を設定して、OpenShift sandboxed containers のワークロードオブジェクトを設定する必要があります。

  • Pod オブジェクト
  • ReplicaSet オブジェクト
  • ReplicationController オブジェクト
  • StatefulSet オブジェクト
  • Deployment オブジェクト
  • DeploymentConfig オブジェクト
重要

Operator namespace にワークロードをデプロイしないでください。これらのリソース専用の namespace を作成します。

YAML ファイルにアノテーションを追加することで、config map で定義したデフォルトのインスタンスサイズを使用してワークロードをデプロイするかどうかを定義できます。

インスタンスサイズを手動で定義しない場合は、使用可能なメモリーに基づいて自動インスタンスサイズを使用するようにアノテーションを追加できます。

前提条件

  • KataConfig カスタムリソース (CR) を作成している。

手順

  1. OpenShift Container Platform Web コンソールで、Workloads workload type (例: Pods) に移動します。
  2. ワークロードタイプページで、オブジェクトをクリックして詳細を表示します。
  3. YAML タブをクリックします。
  4. 次の例のように、各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに spec.runtimeClassName: kata-remote を追加します。

    apiVersion: v1
    kind: <object>
    # ...
    spec:
      runtimeClassName: kata-remote
    # ...
  5. 手動で定義されたインスタンスサイズまたは自動インスタンスサイズを使用するには、Pod テンプレートオブジェクトにアノテーションを追加します。

    • 手動で定義されたインスタンスサイズを使用するには、次のアノテーションを追加します。

      apiVersion: v1
      kind: <object>
      metadata:
        annotations:
          io.katacontainers.config.hypervisor.machine_type: "Standard_B2als_v2" 1
      # ...
      1
      config map で定義したインスタンスサイズを指定します。
    • 自動インスタンスサイズを使用するには、次のアノテーションを追加します。

      apiVersion: v1
      kind: <Pod>
      metadata:
        annotations:
          io.katacontainers.config.hypervisor.default_vcpus: <vcpus>
          io.katacontainers.config.hypervisor.default_memory: <memory>
      # ...

      ワークロードが使用できるメモリーの量を定義します。ワークロードは、使用可能なメモリーの量に基づいて自動インスタンスサイズで実行されます。

  6. Save をクリックして変更を適用します。

    OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。

検証

  • Pod テンプレートオブジェクトの spec.runtimeClassName フィールドを検査します。値が kata-remote の場合、ワークロードはピア Pod を使用して OpenShift Sandboxed Containers で実行されています。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.