3.2. Web コンソールでピア Pod を使用した OpenShift Sandboxed Containers ワークロードのデプロイ


Web コンソールから OpenShift Sandboxed Containers のワークロードをデプロイできます。まず、OpenShift Sandboxed Containers Operator をインストールし、次にシークレットオブジェクト、VM イメージ、およびピア Pod ConfigMap を作成する必要があります。シークレットオブジェクトと ConfigMap は一意です。クラウドプロバイダーに応じて指定します。最後に、KataConfig カスタムリソース (CR) を作成する必要があります。Sandboxed Containers にワークロードをデプロイする準備ができたら、kata-remoteruntimeClassName としてワークロード YAML ファイルに手動で追加する必要があります。

3.2.1. Web コンソールを使用した OpenShift Sandboxed Containers Operator のインストール

OpenShift Container Platform Web コンソールから OpenShift サンドボックスコンテナー Operator をインストールできます。

前提条件

  • OpenShift Container Platform 4.15 がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. Web コンソールの Administrator パースペクティブで、Operators OperatorHub に移動します。
  2. Filter by keyword フィールドに OpenShift sandboxed containers と入力します。
  3. OpenShift sandboxed containers タイルを選択します。
  4. Operator についての情報を確認してから、Install をクリックします。
  5. Install Operator ページで以下を行います。

    1. 選択可能な Update Channel オプションの一覧から stable を選択します。
    2. Installed NamespaceOperator recommend Namespace が選択されていることを確認します。これにより、Operator が必須の openshift-sandboxed-containers-operator namespace にインストールされます。この namespace がまだ存在しない場合は、自動的に作成されます。

      注記

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

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

これで、OpenShift Sandboxed Containers Operator がクラスターにインストールされました。

検証

  1. Web コンソールの Administrator パースペクティブで、Operators Installed Operators に移動します。
  2. OpenShift Sandboxed Containers Operator がインストール済みの Operator リストに表示されていることを確認します。

3.2.2. Web コンソールを使用した AWS のピア Pod パラメーターの設定

AWS 上のピア Pod を使用して OpenShift Sandboxed Containers をデプロイするには、シークレットオブジェクトと ConfigMap を作成する必要があります。

シークレットオブジェクトを作成した後も、ピア Pod を使用して OpenShift Sandboxed Containers をデプロイするために KataConfig カスタムリソース (CR) を作成する必要があります。

前提条件

  • クラスターに OpenShift Container Platform 4.15 がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift Sandboxed Containers Operator をインストールしている。

3.2.2.1. Web コンソールを使用した AWS のシークレットオブジェクトの作成

AWS アクセスキーを指定してシークレットオブジェクトでネットワークを設定します。シークレットオブジェクトは、Pod 仮想マシンイメージの作成に使用され、ピア Pod によって使用されます。

AWS のシークレットオブジェクトを作成するときは、特定の環境値を設定する必要があります。シークレットオブジェクトを作成する前に、これらの値の一部を取得できます。CLI を使用してこれらの値を取得する必要があります。詳細は、CLI を使用した AWS のシークレットオブジェクトの作成 を参照してください。

さらに、AWS Web コンソールで次の値を生成し、保存する必要があります。

  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY

手順

  1. Web コンソールの Administrator パースペクティブで、Operators Installed Operators に移動します。
  2. Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
  3. 右上隅にあるインポートアイコン (+) をクリックします。
  4. Import YAML ウィンドウに、次の 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 値を入力します。
  5. Create をクリックします。

シークレットオブジェクトが作成されます。Workloads Secrets の下に表示されていることが確認できます。

注記

ピア Pod シークレットを更新する場合は、peerpodconfig-ctrl-caa-daemon daemonset を再起動して変更を適用する必要があります。

シークレットを更新したら、Save をクリックして変更を適用します。次に、以下のコマンドを実行して cloud-api-adaptor Pod を再起動します。

$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"

daemonset を再起動すると、ピア Pod が再作成されるので、既存の Pod は更新されないことに注意してください。

3.2.2.2. Web コンソールを使用した AWS 用のピア Pod ConfigMap の作成

Web コンソールを使用して、AWS のピア Pod ConfigMap を作成できます。

手順

  1. Web コンソールの Administrator パースペクティブで、Operators Installed Operators に移動します。
  2. Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
  3. 右上隅にあるインポートアイコン (+) をクリックします。
  4. Import YAML ウィンドウに、次の 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 が少ないワークロードには小さなインスタンスを定義したり、より大きなワークロードには大きなインスタンスを定義したりできます。
  5. Create をクリックします。

ConfigMap オブジェクトが作成されます。Workloads ConfigMaps の下に表示されていることが確認できます。

注記

ピア Pod 設定マップを更新する場合は、peerpodconfig-ctrl-caa-daemon daemonset を再起動して変更を適用する必要があります。

設定マップを更新したら、Save をクリックして変更を適用します。次に、以下のコマンドを実行して 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.2.3. Web コンソールを使用した Azure のピア Pod パラメーターの設定

Microsoft Azure 上のピア Pod を使用して OpenShift Sandboxed Containers をデプロイするには、シークレットオブジェクトと ConfigMap を作成する必要があります。

シークレットオブジェクトを作成した後も、ピア Pod を使用して OpenShift Sandboxed Containers をデプロイするために KataConfig カスタムリソース (CR) を作成する必要があります。

前提条件

  • クラスターに OpenShift Container Platform 4.15 がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift Sandboxed Containers Operator をインストールしている。

3.2.3.1. Web コンソールを使用した Azure のシークレットオブジェクトの作成

Azure アクセスキーを設定し、シークレットオブジェクトでネットワークを設定します。シークレットオブジェクトは、Pod 仮想マシンイメージの作成に使用され、ピア Pod によって使用されます。

Azure のシークレットオブジェクトを作成するときは、特定の環境値を設定する必要があります。これらの値は、シークレットオブジェクトを作成する前に取得できます。CLI を使用してこれらの値を取得する必要があります。詳細は、CLI を使用した Azure のシークレットオブジェクトの作成 を参照してください。

手順

  1. Web コンソールの Administrator パースペクティブで、Operators Installed Operators に移動します。
  2. Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
  3. 右上隅にあるインポートアイコン (+) をクリックします。
  4. Import YAML ウィンドウに、次の 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 値を入力します。
  5. Create をクリックします。

シークレットオブジェクトが作成されます。Workloads Secrets の下に表示されていることが確認できます。

注記

ピア Pod シークレットを更新する場合は、peerpodconfig-ctrl-caa-daemon daemonset を再起動して変更を適用する必要があります。

シークレットを更新したら、Save をクリックして変更を適用します。次に、以下のコマンドを実行して cloud-api-adaptor Pod を再起動します。

$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"

daemonset を再起動すると、ピア Pod が再作成されるので、既存の Pod は更新されないことに注意してください。

3.2.3.2. Web コンソールを使用した Azure のピア Pod ConfigMap の作成

Web コンソールを使用して Azure のピア Pod ConfigMap を作成できます。

手順

  1. Web コンソールの Administrator パースペクティブで、Operators Installed Operators に移動します。
  2. Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
  3. 右上隅にあるインポートアイコン (+) をクリックします。
  4. 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: "<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 値を入力します。
  5. Create をクリックします。

ConfigMap` オブジェクトが作成されます。Workloads ConfigMaps の下に表示されていることが確認できます。

注記

ピア Pod 設定マップを更新する場合は、peerpodconfig-ctrl-caa-daemon daemonset を再起動して変更を適用する必要があります。

設定マップを更新したら、Save をクリックして変更を適用します。次に、以下のコマンドを実行して cloud-api-adaptor Pod を再起動します。

$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"

daemonset を再起動すると、ピア Pod が再作成されるので、既存の Pod は更新されないことに注意してください。

3.2.3.3. Web コンソールを使用した Azure の SSH キーシークレットオブジェクトの作成

Azure でピア Pod を使用するには、SSH キーシークレットオブジェクトを作成する必要があります。オブジェクトの作成用の SSH 鍵がない場合は、CLI を使用して SSH 鍵を生成する必要があります。詳細は、以下を参照してください。

手順

  1. Web コンソールの Administrator パースペクティブから、Workloads Secrets に移動します。
  2. Secrets ウィンドウの左上隅で、openshift-sandboxed-containers-operator プロジェクトにいることを確認します。
  3. Create をクリックし、リストから Key/value secret を選択します。
  4. Secret name フィールドに ssh-key-secret と入力します。
  5. Key フィールドに id_rsa.pub と入力します。
  6. Value フィールドに、公開 SSH 鍵を貼り付けます。
  7. Create をクリックします。

SSH 鍵のシークレットオブジェクトが作成されます。Workloads Secrets の下に表示されていることが確認できます。

KataConfig CR を作成すると、Azure 上のピア Pod を使用して OpenShift Sandboxed Containers を実行できます。

3.2.4. Web コンソールでの KataConfig カスタムリソースの作成

kata-remote をクラスターノードに RuntimeClass としてインストールできるようにするには、KataConfig カスタムリソース (CR) を 1 つ作成する必要があります。

重要

KataConfig CR を作成すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。再起動時間を妨げる要因は次のとおりです。

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

前提条件

  • クラスターに OpenShift Container Platform 4.15 がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift Sandboxed Containers Operator をインストールしている。
注記

ピア Pod の Kata は、デフォルトですべてのワーカーノードにインストールされます。kata-remoteを 特定のノードにのみ RuntimeClass としてインストールする場合は、それらのノードにラベルを追加し、作成時に KataConfig CR でラベルを定義できます。

手順

  1. Web コンソールの Administrator パースペクティブで、Operators Installed Operators に移動します。
  2. Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
  3. KataConfig タブで、Create KataConfig をクリックします。
  4. Create KataConfig ページで、次の詳細を入力します。

    • Name: KataConfig リソースの名前を入力します。デフォルトでは、名前は example-kataconfig として定義されています。
    • Labels (オプション): 関連する識別属性を KataConfig リソースに入力します。各ラベルはキーと値のペアを表します。
    • checkNodeEligibility (オプション、ピア Pod には該当しない): kataRuntimeClass として実行するノードの適格性を、Node Feature Discovery Operator (NFD) を使用して検出するには、このチェックボックスを選択します。詳細は、「クラスターノードが OpenShift Sandboxed Containers を実行する資格があるかどうかを確認する」を参照してください。
    • EnablePeerPods (ピア Pod の場合): ピア Pod を有効にし、パブリッククラウド環境で OpenShift Sandboxed Containers を使用するには、このチェックボックスをオンにします。
    • kataConfigPoolSelector: デフォルトでは、kata-remote はすべてのノードに RuntimeClass としてインストールされます。選択したノードにのみ kata-remoteRuntimeClass としてインストールする場合は、matchExpression を追加する必要があります。

      1. kataConfigPoolSelector エリアを展開します。
      2. kataConfigPoolSelector で、matchExpressions を展開します。これは、ラベルセレクターの要件のリストです。
      3. Add matchExpressions をクリックします。
      4. key フィールドに、セレクターの適用先のラベルキーを追加します。
      5. operator フィールドに、ラベル値に対するキーの関係を追加します。有効な演算子は、InNotInExistsDoesNotExist です。
      6. values エリアを展開し、Add value をクリックします。
      7. Value フィールドで、true または falsekey ラベル値として入力します。
    • logLevel:kata-remoteRuntimeClass として実行しているノードに対して取得するログデータのレベルを定義します。詳細は、「OpenShift Sandboxed Containers データの収集」を参照してください。
  5. Create をクリックします。

新しい KataConfig CR が作成され、ワーカーノードに RuntimeClass として kata-remote をインストールし始めます。インストールが完了してワーカーノードが再起動するまで待ってから、次の手順に進みます。

注記

CR を実行すると、VM イメージが作成されます。イメージの作成はクラウドプロバイダーにより行われ、追加のリソースを使用する場合があります。

重要

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

検証

  1. KataConfig タブで、新しい KataConfig CR を選択します。
  2. KataConfig ページで、YAML タブを選択します。
  3. status フィールドを監視します。

    更新があるたびにメッセージが表示されます。リロード をクリックして、更新された KataConfig CR を表示します。

    status フィールドには conditions および kataNodes サブフィールドがあります。kataNodes サブフィールドはノード一覧のコレクションです。各ノードは、kata インストールの特定状態のノードを一覧表示します。

    kataNodes の下のすべてのワーカーが installs としてリストされ、理由を指定せずに InProgress の条件が False の場合は、kata がクラスターにインストールされていることを示します。詳細は、「移行のインストールとアンインストール」を参照してください。

3.2.5. Web コンソールを使用したピア Pod を含むワークロードの Sandboxed Containers へのデプロイ

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

Sandboxed Containers 内のピア Pod を使用して Pod テンプレート化されたワークロードをデプロイするには、kata-remoteruntimeClassName としてワークロード YAML ファイルに手動で追加する必要があります。

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

前提条件

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

手順

  1. Web コンソールの Administrator パースペクティブから、Workloads をデプロイメントし、作成するワークロードのタイプを選択します。
  2. ワークロードページで、をクリックしてワークロードを作成します。
  3. ワークロードの YAML ファイルで、コンテナーがリストされている spec フィールドに runtimeClassName: kata-remote を追加します。
  4. ワークロードの YAML ファイルにアノテーションを追加して、デフォルトのインスタンスサイズまたはタイプを使用するか、自動インスタンスサイズまたはタイプを使用するかを定義します。インスタンスサイズは特定のクラウドプロバイダーに使用され、インスタンスタイプは他のクラウドプロバイダーに使用されます。

    • 特定のインスタンスサイズタイプについては、次のアノテーションを追加します。

      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 はインスタンスタイプを使用します。
  5. Save をクリックします。

OpenShift Container Platform はワークロードを作成し、スケジューリングを開始します。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.