3.3. コマンドラインを使用した OpenShift Sandboxed Containers のデプロイ


コマンドラインインターフェイス (CLI) を使用して次のタスクを実行することにより、AWS に OpenShift sandboxed containers をデプロイできます。

  1. OpenShift Sandboxed Containers Operator を再インストールします。
  2. オプション: 各ワーカーノードで実行されている仮想マシンの数を変更します。
  3. ピア Pod との内部通信を許可するには、ポート 15150 と 9000 を有効にします。
  4. ピア Pod シークレットを作成します。
  5. ピア Pod の config map を作成します。
  6. KataConfig カスタムリソースを作成します。
  7. OpenShift Sandboxed Containers のワークロードオブジェクトを設定します。

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

CLI を使用して、OpenShift Sandboxed Containers Operator をインストールできます。

前提条件

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

手順

  1. osc-namespace.yaml マニフェストファイルを作成します。

    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-sandboxed-containers-operator
  2. 以下のコマンドを実行して namespace を作成します。

    $ oc apply -f osc-namespace.yaml
  3. 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
  4. 以下のコマンドを実行して Operator グループを作成します。

    $ oc apply -f osc-operatorgroup.yaml
  5. 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.8.1
  6. 次のコマンドを実行して、サブスクリプションを作成します。

    $ oc apply -f osc-subscription.yaml
  7. 次のコマンドを実行して、Operator が正常にインストールされていることを確認します。

    $ oc get csv -n openshift-sandboxed-containers-operator

    このコマンドが完了するまでに数分かかる場合があります。

  8. 次のコマンドを実行してプロセスを監視します。

    $ watch oc get csv -n openshift-sandboxed-containers-operator

    出力例

    NAME                             DISPLAY                                  VERSION             REPLACES                   PHASE
    openshift-sandboxed-containers   openshift-sandboxed-containers-operator  1.8.1    1.7.0        Succeeded

3.3.2. ノードあたりのピア Pod 仮想マシン数の変更

peerpodConfig カスタムリソース (CR) を編集することで、ノードあたりのピア Pod 仮想マシン (VM) の制限を変更できます。

手順

  1. 次のコマンドを実行して、現在の制限を確認します。

    $ oc get peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \
    -o jsonpath='{.spec.limit}{"\n"}'
  2. 次のコマンドを実行して、peerpodConfig CR の limit 属性を変更します。

    $ oc patch peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \
    --type merge --patch '{"spec":{"limit":"<value>"}}' 1
    1
    <value> は、定義する制限に置き換えます。

3.3.3. AWS のポートの有効化

AWS で実行されるピア Pod との内部通信を許可するには、ポート 15150 および 9000 を有効にする必要があります。

前提条件

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

手順

  1. OpenShift Container Platform クラスターにログインし、インスタンス 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}')
  3. セキュリティーグループ ID を取得し、配列に保存します。

    $ AWS_SG_IDS=($(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} \
      --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' \
      --output text --region $AWS_REGION))
  4. 各セキュリティーグループ ID について、ピア Pod シムが kata-agent 通信にアクセスできるように承認し、ピア Pod トンネルを設定します。

    $ for AWS_SG_ID in "${AWS_SG_IDS[@]}"; do \
      aws ec2 authorize-security-group-ingress --group-id $AWS_SG_ID --protocol tcp --port 15150 --source-group $AWS_SG_ID --region $AWS_REGION \
      aws ec2 authorize-security-group-ingress --group-id $AWS_SG_ID --protocol tcp --port 9000 --source-group $AWS_SG_ID --region $AWS_REGION \
    done

これでポートが有効になりました。

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

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

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

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

前提条件

  • AWS コンソールを使用して以下の値が生成されます。

    • AWS_ACCESS_KEY_ID
    • AWS_SECRET_ACCESS_KEY

手順

  1. 次の例に従って peer-pods-secret.yaml マニフェストファイルを作成します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: peer-pods-secret
      namespace: openshift-sandboxed-containers-operator
    type: Opaque
    stringData:
      AWS_ACCESS_KEY_ID: "<aws_access_key>" 1
      AWS_SECRET_ACCESS_KEY: "<aws_secret_access_key>" 2
    1
    AWS_ACCESS_KEY_ID 値を指定します。
    2
    AWS_SECRET_ACCESS_KEY 値を指定します。
  2. 以下のコマンドを実行してシークレットを作成します。

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

3.3.5. ピア Pod config map の作成

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

前提条件

  • クラスター認証情報に基づくデフォルトの AMI ID を使用していない場合は、Amazon Machine Image (AMI) ID がある。

手順

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

    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. 以下の例に従って peer-pods-cm.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"
      PODVM_AMI_ID: "<podvm_ami_id>" 3
      AWS_REGION: "<aws_region>" 4
      AWS_SUBNET_ID: "<aws_subnet_id>" 5
      AWS_VPC_ID: "<aws_vpc_id>" 6
      AWS_SG_IDS: "<aws_sg_ids>" 7
      DISABLECVM: "true"
    1
    ワークロードでタイプが定義されていない場合に使用されるデフォルトのインスタンスタイプを定義します。
    2
    Pod の作成時に指定できるすべてのインスタンスタイプを一覧表示します。これにより、メモリーと CPU をあまり必要としないワークロードには小さいインスタンスタイプを定義したり、ワークロードが大きい場合は大きいインスタンスタイプを定義したりすることができます。
    3
    オプション: デフォルトでは、この値は、クラスターの認証情報に基づく AMI ID を使用して KataConfig CR を実行するときに入力されます。独自の AMI を作成する場合は、正しい AMI ID を指定します。
    4
    取得した AWS_REGION 値を指定します。
    5
    取得した AWS_SUBNET_ID 値を指定します。
    6
    取得した AWS_VPC_ID 値を指定します。
    7
    取得した AWS_SG_IDS 値を指定します。
  3. 以下のコマンドを実行して config map を作成します。

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

3.3.6. 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 ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. 以下の例に従って 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')
  2. 次のコマンドを実行して、KataConfig CR を作成します。

    $ oc apply -f example-kataconfig.yaml

    新しい KataConfig CR が作成され、ワーカーノードに kata-remote がランタイムクラスとしてインストールされます。

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

  3. 次のコマンドを実行して、インストールの進行状況を監視します。

    $ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"

    kataNodes の下にあるすべてのワーカーのステータスが installed で、理由を指定せずに InProgress の条件が False の場合、kata はクラスターにインストールされます。

  4. 次のコマンドを実行してデーモンセットを確認します。

    $ oc get -n openshift-sandboxed-containers-operator ds/peerpodconfig-ctrl-caa-daemon
  5. 次のコマンドを実行してランタイムクラスを確認します。

    $ oc get runtimeclass

    出力例

    NAME             HANDLER          AGE
    kata             kata             152m
    kata-remote      kata-remote      152m

Pod VM イメージの確認

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

手順

  1. ピア Pod 用に作成した config map を取得します。

    $ oc get configmap peer-pods-cm -n openshift-sandboxed-containers-operator -o yaml
  2. YAML ファイルの status スタンザを確認します。

    PODVM_AMI_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 サポートケースを送信し、両方のログの出力を添付してください。

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

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

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

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

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

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

前提条件

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

手順

  1. 次の例のように、各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに spec.runtimeClassName: kata-remote を追加します。

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

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

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

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

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

  3. 次のコマンドを実行して、変更をワークロードオブジェクトに適用します。

    $ oc apply -f <object.yaml>

    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.