第3章 ピア Pod を使用した OpenShift Sandboxed Containers ワークロードのデプロイ
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 仕様に次の変更を加えます。-
この Webhook は、Pod 内のすべてのコンテナーおよび初期化コンテナーの
resources
フィールドからすべてのリソース仕様を削除します。 -
Webhook は、Pod 内の最初のコンテナーのリソースフィールドを変更して、拡張リソース (
kata.peerpods.io/vm
) を仕様に追加します。拡張リソースkata.peerpods.io/vm
は Kubernetes スケジューラーによってアカウンティング目的で使用されます。
-
この Webhook は、Pod 内のすべてのコンテナーおよび初期化コンテナーの
mutating Webhook は、Red Hat OpenShift の特定のシステム namespace が変更されないように除外します。これらのシステム namespace でピア Pod が作成された場合、Pod の仕様に拡張リソースが含まれていない限り、Kubernetes 拡張リソースを使用したリソースアカウンティングは機能しません。
ベストプラクティスとして、特定の namespace でのみピア Pod の作成を許可するクラスター全体のポリシーを定義します。
3.1.1.1. ノードごとのピア Pod VM 制限の変更
peerpodConfig
カスタムリソース(CR)を編集して、ノードごとのピア Pod VM の制限を変更できます。
手順
次のコマンドを実行して、現在の制限を確認します。
$ oc get peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \ -o jsonpath='{.spec.limit}{"\n"}'
次のコマンドを実行して、
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 の有効化
手順
インスタンス ID を取得します。
$ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')
AWS リージョンを取得します。
$ AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}')
セキュリティーグループを取得します。
$ SG=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' --output text --region ${AWS_REGION})
ピア Pod シムを承認し、kata-agent 通信にアクセスすることを許可します。以下のコマンドを実行します。
$ aws ec2 authorize-security-group-ingress --group-id ${SG} --protocol tcp --port 15150 --source-group ${SG} --region ${AWS_REGION}
ピア 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 の有効化
手順
インスタンス ID を取得します。
$ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')
Azure リソースグループを取得します。
$ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}')
Azure ネットワークセキュリティーグループ (NSG) 名を取得します。
$ AZURE_NSG_NAME=$(az network nsg list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)
Azure VNet 名を取得します。
$ AZURE_VNET_NAME=$(az network vnet list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)
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)
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)
ピア 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
ピア 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
これでポートが有効になりました。