検索

第3章 ピア Pod を使用した OpenShift Sandboxed Containers ワークロードのデプロイ

download PDF

Web コンソールまたは OpenShift CLI (oc) のいずれかを使用して OpenShift Sandboxed Containers Operator をインストールできます。OpenShift Sandboxed Containers Operator をインストールする前に、Red Hat OpenShift クラスターを準備する必要があります。

重要

ピア Pod を使用した OpenShift Sandboxed Containers ワークロードのデプロイは、テクノロジープレビューとしてのみ提供されています。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

3.1. 前提条件

OpenShift Sandboxed Containers をインストールしてピア Pod を有効にする前に、次の要件を満たす必要があります。

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

3.1.1. OpenShift Sandboxed Containers のピア Pod リソース要件について

ピア Pod は、次の 2 つの場所でリソースを使用します。

  • ワーカーノード。ワーカーノードは、メタデータ、Kata shim リソース (containerd-shim-kata-v2)、リモートハイパーバイザー (cloud-api-adaptor) リソース、およびワーカーノードとピア Pod VM 間のトンネル設定を保存します。
  • クラウドインスタンス。これは、クラウド内で実行されている実際のピア Pod VM です。

Kubernetes ワーカーノードで使用される CPU およびメモリーリソースは、ピア Pod の作成に使用される RuntimeClass (kata-remote) 定義に含まれる Pod オーバーヘッド によって処理されます。

クラウド内で実行されているピア Pod VM の総数は、Kubernetes ノード拡張リソースとして定義されます。この制限はノードごとに行われ、peerpodConfig カスタムリソース(CR)の limit 属性で設定されます。kataConfig CR は、kataConfig CR を作成してピア Pod を有効にすると、peerpodconfig-openshift という名前の peerpodConfig CR が作成され、openshift-sandboxed-containers-operator namespace に配置されます。

次の peerpodConfig CR の例は、デフォルトの spec 値を示しています。

apiVersion: confidentialcontainers.org/v1alpha1
kind: PeerPodConfig
metadata:
  name: peerpodconfig-openshift
  namespace: openshift-sandboxed-containers-operator
spec:
  cloudSecretName: peer-pods-secret
  configMapName: peer-pods-cm
  limit: "10" 1
  nodeSelector:
    node-role.kubernetes.io/kata-oc: ""
1
デフォルトの制限は、ノードごとに 10 VM です。

拡張リソースの名前は kata.peerpods.io/vm で、Kubernetes スケジューラーが容量の追跡とアカウンティングを処理できるようにします。

ご使用の環境の要件に基づいて、ノードごとの制限を編集できます。詳細は、ピア Pod のノードごとの VM 制限の変更 を 参照してください。

mutating Webhook により、拡張リソース kata.peerpods.io/vm が Pod 仕様に追加されます。また、リソース固有のエントリーが存在する場合は、Pod 仕様から削除されます。こうすることで、Kubernetes スケジューラーがこれらの拡張リソースを考慮できるようになり、リソースが利用可能な場合にのみピア Pod がスケジュールされるようになります。

mutating Webhook は、次のように Kubernetes Pod を変更します。

  • mutating Webhook は、TARGET_RUNTIME_CLASS 環境変数で指定された RuntimeClassName の想定値であるか、Pod をチェックします。Pod 仕様の値が TARGET_RUNTIME_CLASS の値と一致しない場合、Webhook は Pod を変更せずに終了します。
  • RuntimeClassName の 値が一致する場合、Webhook は Pod 仕様に次の変更を加えます。

    1. この Webhook は、Pod 内のすべてのコンテナーおよび初期化コンテナーの resources フィールドからすべてのリソース仕様を削除します。
    2. Webhook は、Pod 内の最初のコンテナーのリソースフィールドを変更して、拡張リソース (kata.peerpods.io/vm) を仕様に追加します。拡張リソース kata.peerpods.io/vm は Kubernetes スケジューラーによってアカウンティング目的で使用されます。
注記

mutating Webhook は、Red Hat OpenShift の特定のシステム namespace が変更されないように除外します。これらのシステム namespace でピア Pod が作成された場合、Pod の仕様に拡張リソースが含まれていない限り、Kubernetes 拡張リソースを使用したリソースアカウンティングは機能しません。

ベストプラクティスとして、特定の namespace でのみピア Pod の作成を許可するクラスター全体のポリシーを定義します。

3.1.1.1. ノードごとのピア Pod VM 制限の変更

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.1.2. AWS を使用したピア Pod の前提条件

AWS を使用してピア Pod を作成している場合は、次の要件を確認する必要があります。

  • Red Hat OpenShift クラスターは、少なくとも 1 つのワーカーノードとともに AWS にインストールしておく。
  • AWS_ACCESS_KEY_ID および AWS_SECRET_ACCESS_KEY 認証情報にアクセスできる。これらは、クラスターの同じ Virtual Private Cloud (VPC) 内に追加のクラウドインスタンスを作成するために使用されます。
  • AWS CLI ツールをインストールして設定しておく。
  • ポート 15150 および 9000 で内部クラスター通信を有効にする。

    これらのポートは、AWS ウェブコンソールまたは CLI を使用して有効にできます。

3.1.2.1. AWS のポート 15150 および 9000 の有効化

手順

  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}')
  3. セキュリティーグループを取得します。

    $ SG=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' --output text --region ${AWS_REGION})
  4. ピア Pod シムを承認し、kata-agent 通信にアクセスすることを許可します。以下のコマンドを実行します。

    $ aws ec2 authorize-security-group-ingress --group-id ${SG} --protocol tcp --port 15150 --source-group ${SG} --region ${AWS_REGION}
  5. ピア Pod トンネルを設定します。以下のコマンドを実行します。

    $ aws ec2 authorize-security-group-ingress --group-id ${SG} --protocol tcp --port 9000 --source-group ${SG} --region ${AWS_REGION}

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

3.1.3. Azure を使用するピア Pod の前提条件

Microsoft Azure を使用してピア Pod を作成している場合は、次の要件を確認する必要があります。

  • Red Hat OpenShift クラスターを Azure にインストールして、ワーカーノードを最低でも 1 つ用意する。
  • 次の認証情報とサブスクリプションの情報にアクセスできる。

    • AZURE_SUBSCRIPTION_ID
    • AZURE_CLIENT_ID
    • AZURE_CLIENT_SECRET
    • AZURE_TENANT_ID

    これらは、クラスターの同じ Virtual Private Cloud (VPC) 内に追加のクラウドインスタンスを作成するために使用されます。

  • Azure CLI ツールをインストールして設定しておく。
  • ポート 15150 および 9000 でのクラスター通信を有効にする。

    Azure でこれらのポートでの内部通信を許可しておいてください。ただし、通信がブロックされている場合は、Azure Web コンソールまたは CLI を使用してポートを有効にできるようにします。

3.1.3.1. Azure のポート 15150 および 9000 の有効化

手順

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

    $ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')
  2. Azure リソースグループを取得します。

    $ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}')
  3. Azure ネットワークセキュリティーグループ (NSG) 名を取得します。

    $ AZURE_NSG_NAME=$(az network nsg list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)
  4. Azure VNet 名を取得します。

    $ AZURE_VNET_NAME=$(az network vnet list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)
  5. Azure サブネット名を取得します。

    $ AZURE_SUBNET_NAME=$(az network vnet subnet list --resource-group ${AZURE_RESOURCE_GROUP} --vnet-name ${AZURE_VNET_NAME}  --query "[].{Name:name} | [? contains(Name, 'worker')]" --output tsv)
  6. Azure サブネット接頭辞を取得します。

    $ AZURE_SUBNET_PREFIX=$(az network vnet subnet show --name ${AZURE_SUBNET_NAME} --vnet-name ${AZURE_VNET_NAME} --resource-group ${AZURE_RESOURCE_GROUP} --query "addressPrefix" --output tsv)
  7. ピア Pod シムが kata-agent 通信にアクセスすることを許可します。以下のコマンドを実行します。

    $ az network nsg rule create \
      --resource-group $AZURE_RESOURCE_GROUP \
      --nsg-name $AZURE_NSG_NAME \
      --name Allow-Kata-Agent-Internal \
      --access Allow \
      --protocol Tcp \
      --direction Inbound \
      --priority 112 \
      --source-address-prefixes $AZURE_SUBNET_PREFIX \
      --source-port-range "*" \
      --destination-address-prefixes $AZURE_SUBNET_PREFIX  \
      --destination-port-range 15150
  8. ピア Pod トンネルを設定します。以下のコマンドを実行します。

    $ az network nsg rule create \
      --resource-group $AZURE_RESOURCE_GROUP \
      --nsg-name $AZURE_NSG_NAME \
      --name Allow-VXLAN-Internal \
      --access Allow \
      --protocol Tcp \
      --direction Inbound \
      --priority 111 \
      --source-address-prefixes $AZURE_SUBNET_PREFIX \
      --source-port-range "*" \
      --destination-address-prefixes $AZURE_SUBNET_PREFIX  \
      --destination-port-range 9000

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

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.