3.2. Web コンソールを使用した OpenShift Sandboxed Containers のデプロイ
OpenShift Container Platform Web コンソールを使用して次のタスクを実行することで、AWS に OpenShift sandboxed containers をデプロイできます。
- OpenShift Sandboxed Containers Operator を再インストールします。
- オプション: ピア Pod との内部通信を許可するには、ポート 15150 と 9000 を有効にします。
- オプション: OpenShift sandboxed containers Operator とともにインストールされる Cloud Credential Operator をアンインストールした場合は、ピア Pod シークレットを作成します。
- オプション: カスタム Pod 仮想マシンイメージを選択します。
- オプション: Kata エージェントポリシーをカスタマイズします。
- ピア Pod の config map を作成します。
-
KataConfig
カスタムリソースを作成します。 - OpenShift Sandboxed Containers のワークロードオブジェクトを設定します。
3.2.1. OpenShift Sandboxed Containers Operator のインストール
OpenShift Container Platform Web コンソールを使用して、OpenShift sandboxed containers Operator をインストールできます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
-
Web コンソールで、Operators
OperatorHub に移動します。 -
Filter by keyword フィールドに
OpenShift sandboxed containers
と入力します。 - OpenShift sandboxed containers Operator タイルを選択し、Install をクリックします。
- Install Operator ページで、利用可能な Update Channel オプションの一覧から stable を選択します。
Installed Namespace で Operator recommended Namespace が選択されていることを確認します。これにより、Operator が必須の
openshift-sandboxed-containers-operator
namespace にインストールされます。この namespace がまだ存在しない場合は、自動的に作成されます。注記OpenShift Sandboxed Containers Operator を
openshift-sandboxed-containers-operator
以外の namespace にインストールしようとすると、インストールに失敗します。- Approval Strategy で Automatic が選択されていることを確認します。Automatic がデフォルト値であり、新しい z-stream リリースが利用可能になると、OpenShift Sandboxed Containers への自動更新が有効になります。
- Install をクリックします。
-
Operator
Installed Operator に移動して、Operator がインストールされていることを確認します。
3.2.2. AWS のポートの有効化
AWS で実行されるピア Pod との内部通信を許可するには、ポート 15150 および 9000 を有効にする必要があります。
前提条件
- OpenShift Sandboxed Containers Operator をインストールしている。
- AWS コマンドラインツールがインストールされている。
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
OpenShift Container Platform クラスターにログインし、インスタンス ID を取得します。
INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' \ -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')
$ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' \ -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')
Copy to Clipboard Copied! AWS リージョンを取得します。
AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}')
$ AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}')
Copy to Clipboard Copied! セキュリティーグループ ID を取得し、配列に保存します。
AWS_SG_IDS=($(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} \ --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' \ --output text --region $AWS_REGION))
$ AWS_SG_IDS=($(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} \ --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' \ --output text --region $AWS_REGION))
Copy to Clipboard Copied! 各セキュリティーグループ 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
$ 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
Copy to Clipboard Copied!
これでポートが有効になりました。
3.2.3. ピア Pod シークレットの作成
ピア Pod のシークレットが空で、Cloud Credential Operator (CCO) がインストールされている場合、OpenShift sandboxed containers Operator は CCO を使用してシークレットを取得します。CCO をアンインストールした場合は、OpenShift sandboxed containers のピア Pod シークレットを手動で作成する必要があります。そうしないと、ピア Pod は動作しなくなります。
シークレットには、Pod 仮想マシン (VM) イメージとピア Pod インスタンスを作成するための認証情報が保存されます。
デフォルトでは、OpenShift Sandboxed Containers Operator はクラスターの作成に使用される認証情報に基づいてシークレットを作成します。ただし、異なる認証情報を使用するシークレットを手動で作成することはできます。
前提条件
AWS コンソールを使用して以下の値が生成されます。
-
AWS_ACCESS_KEY_ID
-
AWS_SECRET_ACCESS_KEY
-
手順
-
OpenShift Container Platform Web コンソールで、Operators
Installed Operators に移動します。 - OpenShift sandboxed containers Operator タイルをクリックします。
- 右上隅のインポートアイコン (+) をクリックします。
Import YAML ウィンドウに、次の 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>" AWS_SECRET_ACCESS_KEY: "<aws_secret_access_key>"
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 Copy to Clipboard Copied! - Save をクリックして変更を適用します。
-
Workloads
Secrets に移動して、ピア Pod シークレットを確認します。
3.2.4. ピア Pod config map の作成
OpenShift sandboxed containers のピア Pod config map を作成する必要があります。
前提条件
- クラスター認証情報に基づくデフォルトの AMI ID を使用していない場合は、Amazon Machine Image (AMI) ID がある。
手順
AWS インスタンスから以下の値を取得します。
インスタンス ID を取得して記録します。
INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')
$ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')
Copy to Clipboard Copied! これは、シークレットオブジェクトの他の値を取得するために使用されます。
AWS リージョンを取得して記録します。
AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}') && echo "AWS_REGION: \"$AWS_REGION\""
$ AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}') && echo "AWS_REGION: \"$AWS_REGION\""
Copy to Clipboard Copied! 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\""
$ 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\""
Copy to Clipboard Copied! 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\""
$ 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\""
Copy to Clipboard Copied! 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\""
$ 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\""
Copy to Clipboard Copied!
-
OpenShift Container Platform Web コンソールで、Operators
Installed Operators に移動します。 - Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
- 右上隅にあるインポートアイコン (+) をクリックします。
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" PODVM_INSTANCE_TYPES: "t2.small,t2.medium,t3.large" PROXY_TIMEOUT: "5m" PODVM_AMI_ID: "<podvm_ami_id>" AWS_REGION: "<aws_region>" AWS_SUBNET_ID: "<aws_subnet_id>" AWS_VPC_ID: "<aws_vpc_id>" AWS_SG_IDS: "<aws_sg_ids>" PEERPODS_LIMIT_PER_NODE: "10" TAGS: "key1=value1,key2=value2" DISABLECVM: "true"
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 PEERPODS_LIMIT_PER_NODE: "10"
8 TAGS: "key1=value1,key2=value2"
9 DISABLECVM: "true"
Copy to Clipboard Copied! - 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
値を指定します。 - 8
- ノードごとに作成できるピア Pod の最大数を指定します。デフォルト値は
10
です。 - 9
- Pod 仮想マシンインスタンスの
key:value
ペアとしてカスタムタグを設定して、ピア Pod のコストを追跡したり、異なるクラスター内のピア Pod を識別したりできます。
- Save をクリックして変更を適用します。
-
新しい config map を表示するには、Workloads
ConfigMaps に移動します。
3.2.5. カスタムピア Pod 仮想マシンイメージの選択
Pod マニフェストにアノテーションを追加することで、ワークロード要件に合わせてカスタマイズされたカスタムピア Pod 仮想マシン (VM) イメージを選択できます。カスタムイメージは、ピア Podconfig map で指定されたデフォルトイメージをオーバーライドします。
前提条件
- 使用予定のカスタム Pod 仮想マシンイメージの ID が利用でき、クラウドプロバイダーまたはハイパーバイザーと互換性がある。
手順
-
OpenShift Container Platform Web コンソールで、Operators
Installed Operators に移動します。 - Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
- 右上隅にあるインポートアイコン (+) をクリックします。
Import YAML ウィンドウに、次の YAML マニフェストを貼り付けます。
apiVersion: v1 kind: Pod metadata: name: pod-manifest annotations: io.katacontainers.config.hypervisor.image: "<custom_image_id>" spec: runtimeClassName: kata-remote containers: - name: <example_container> image: registry.access.redhat.com/ubi9/ubi:9.3 command: ["sleep", "36000"]
apiVersion: v1 kind: Pod metadata: name: pod-manifest annotations: io.katacontainers.config.hypervisor.image: "<custom_image_id>"
1 spec: runtimeClassName: kata-remote
2 containers: - name: <example_container>
3 image: registry.access.redhat.com/ubi9/ubi:9.3 command: ["sleep", "36000"]
Copy to Clipboard Copied! - Save をクリックして変更を適用します。
3.2.6. Kata エージェントポリシーのカスタマイズ
Kata エージェントポリシーは、Kata ランタイムで実行されている Pod のエージェント API 要求を制御するセキュリティーメカニズムです。このポリシーは Rego で記述され、Pod 仮想マシン (VM) 内の Kata エージェントによって適用され、許可または拒否される操作を決定します。
セキュリティーが問題にならない開発やテストなどの特定のユースケースでは、デフォルトのポリシーをカスタムポリシーで上書きできます。たとえば、コントロールプレーンを信頼できる環境で実行する場合があります。カスタムポリシーは、複数の方法で適用できます。
- ポリシーを Pod VM イメージに組み込む。
- ピア Pod の config map にパッチを適用する。
- ワークロード Pod YAML にアノテーションを追加する。
実稼働システムの場合、initdata を使用して Kata エージェントポリシーをオーバーライドする方法が推奨されます。以下の手順では、io.katacontainers.config.agent.policy
アノテーションを使用してカスタムポリシーを個々の Pod に適用します。ポリシーは Base64 でエンコードされた Rego 形式で提供されます。このアプローチでは、Pod 仮想マシンイメージを変更せずに、Pod 作成時にデフォルトのポリシーをオーバーライドします。
カスタムポリシーは、デフォルトのポリシーを完全に置き換えます。特定の API のみを変更するには、完全なポリシーを含め、関連するルールを調整します。
手順
カスタムポリシーを含む
policy.rego
ファイルを作成します。次の例では、デモ用にexec
とlog
を有効にした、設定可能なすべての API を示しています。package agent_policy import future.keywords.in import input default CopyFileRequest := false default CreateContainerRequest := false default CreateSandboxRequest := true default DestroySandboxRequest := true default ExecProcessRequest := true # Enabled to allow exec API default GetOOMEventRequest := true default GuestDetailsRequest := true default OnlineCPUMemRequest := true default PullImageRequest := true default ReadStreamRequest := true # Enabled to allow log API default RemoveContainerRequest := true default RemoveStaleVirtiofsShareMountsRequest := true default SignalProcessRequest := true default StartContainerRequest := true default StatsContainerRequest := true default TtyWinResizeRequest := true default UpdateEphemeralMountsRequest := true default UpdateInterfaceRequest := true default UpdateRoutesRequest := true default WaitProcessRequest := true default WriteStreamRequest := false
package agent_policy import future.keywords.in import input default CopyFileRequest := false default CreateContainerRequest := false default CreateSandboxRequest := true default DestroySandboxRequest := true default ExecProcessRequest := true # Enabled to allow exec API default GetOOMEventRequest := true default GuestDetailsRequest := true default OnlineCPUMemRequest := true default PullImageRequest := true default ReadStreamRequest := true # Enabled to allow log API default RemoveContainerRequest := true default RemoveStaleVirtiofsShareMountsRequest := true default SignalProcessRequest := true default StartContainerRequest := true default StatsContainerRequest := true default TtyWinResizeRequest := true default UpdateEphemeralMountsRequest := true default UpdateInterfaceRequest := true default UpdateRoutesRequest := true default WaitProcessRequest := true default WriteStreamRequest := false
Copy to Clipboard Copied! このポリシーは、
exec
(ExecProcessRequest
) およびlog
(ReadStreamRequest
) API を有効にします。必要に応じて、true
またはfalse
の値を調整してポリシーをさらにカスタマイズします。次のコマンドを実行して、
policy.rego
ファイルを Base64 でエンコードされた文字列に変換します。base64 -w0 policy.rego
$ base64 -w0 policy.rego
Copy to Clipboard Copied! yaml ファイルで使用するために出力を保存します。
-
OpenShift Container Platform Web コンソールで、Operators
Installed Operators に移動します。 - Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
- 右上隅にあるインポートアイコン (+) をクリックします。
Import YAML ウィンドウで、次の YAML マニフェストを貼り付け、Base64 でエンコードされたポリシーを追加します。
apiVersion: v1 kind: Pod metadata: name: <pod_name> annotations: io.katacontainers.config.agent.policy: <base64_encoded_policy> spec: runtimeClassName: kata-remote containers: - name: <container_name> image: registry.access.redhat.com/ubi9/ubi:latest command: - sleep - "36000" securityContext: privileged: false seccompProfile: type: RuntimeDefault
apiVersion: v1 kind: Pod metadata: name: <pod_name> annotations: io.katacontainers.config.agent.policy: <base64_encoded_policy> spec: runtimeClassName: kata-remote containers: - name: <container_name> image: registry.access.redhat.com/ubi9/ubi:latest command: - sleep - "36000" securityContext: privileged: false seccompProfile: type: RuntimeDefault
Copy to Clipboard Copied! - Save をクリックして変更を適用します。
3.2.7. KataConfig カスタムリソースの作成
ワーカーノードに kata-remote
を RuntimeClass
としてインストールするには、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 をインストールしておきます。
手順
-
OpenShift Container Platform Web コンソールで、Operators
Installed Operators に移動します。 - OpenShift sandboxed containers Operator を選択します。
- KataConfig タブで、Create KataConfig をクリックします。
以下の詳細を入力します。
-
Name: オプション: デフォルト名は
example-kataconfig
です。 -
Labels: オプション: 関連する識別属性を
KataConfig
リソースに入力します。各ラベルはキーと値のペアを表します。 - enablePeerPods: パブリッククラウド、IBM Z®、および IBM® LinuxONE デプロイメントの場合に選択します。
kataConfigPoolSelector。オプション: 選択したノードに
kata-remote
をインストールするには、選択したノードのラベルに一致する式を追加します。- kataConfigPoolSelector エリアを展開します。
- kataConfigPoolSelector エリアで、matchExpressions を展開します。これは、ラベルセレクターの要件のリストです。
- Add matchExpressions をクリックします。
- Key フィールドに、セレクターの適用先のラベルキーを入力します。
-
Operator フィールドに、キーとラベル値の関係を入力します。有効な演算子は、
In
、NotIn
、Exists
、DoesNotExist
です。 - Values エリアを展開し、Add value をクリックします。
-
Value フィールドで、
true
またはfalse
を key ラベル値として入力します。
-
logLevel: ランタイムクラスが
kata-remote
のノードに対して取得されるログデータのレベルを定義します。
-
Name: オプション: デフォルト名は
Create をクリックします。
KataConfig
CR が作成され、ワーカーノードにkata-remote
ランタイムクラスをインストールします。インストールを確認する前に、
kata-remote
のインストールが完了し、ワーカーノードが再起動するまで待ちます。
検証
-
KataConfig タブで、
KataConfig
CR をクリックして詳細を表示します。 YAML タブをクリックして
status
スタンザを表示します。status
スタンザには、conditions
およびkataNodes
キーが含まれています。status.kataNodes
の値はノード配列であり、各ノードにはkata-remote
インストールの特定の状態にあるノードがリストされます。更新があるたびにメッセージが表示されます。Reload をクリックして、YAML を更新します。
status.kataNodes
配列内のすべてのワーカーに、値installed
と、理由が指定されていないconditions.InProgress: False
が表示される場合、kata-remote
はクラスターにインストールされています。
関連情報
Pod VM イメージの確認
kata-remote
がクラスターにインストールされると、OpenShift sandboxed containers Operator は、ピア Pod の作成に使用される Pod 仮想マシンイメージを作成します。イメージがクラウドインスタンス上に作成されるため、このプロセスには時間がかかる場合があります。クラウドプロバイダー用に作成した config map を確認し、Pod 仮想マシンイメージが正常に作成されたことを確認できます。
手順
-
Workloads
ConfigMaps に移動します。 - プロバイダー config map をクリックすると、詳細が表示されます。
- YAML タブをクリックします。
YAML ファイルの
status
スタンザを確認します。PODVM_AMI_ID
パラメーターが入力されている場合は、Pod 仮想マシンイメージが正常に作成されています。
トラブルシューティング
次のコマンドを実行してイベントログを取得します。
oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation
$ oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation
Copy to Clipboard Copied! 次のコマンドを実行して、ジョブログを取得します。
oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creation
$ oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creation
Copy to Clipboard Copied!
問題を解決できない場合は、Red Hat サポートケースを送信し、両方のログの出力を添付してください。
3.2.8. ワークロードオブジェクトの設定
次の Pod テンプレートオブジェクトのランタイムクラスとして kata-remote
を設定して、OpenShift sandboxed containers のワークロードオブジェクトを設定する必要があります。
-
Pod
オブジェクト -
ReplicaSet
オブジェクト -
ReplicationController
オブジェクト -
StatefulSet
オブジェクト -
Deployment
オブジェクト -
DeploymentConfig
オブジェクト
Operator namespace にワークロードをデプロイしないでください。これらのリソース専用の namespace を作成します。
YAML ファイルにアノテーションを追加することで、config map で定義したデフォルトのインスタンスタイプを使用してワークロードをデプロイするかどうかを定義できます。
インスタンスタイプを手動で定義しない場合は、使用可能なメモリーに基づいて自動インスタンスタイプを使用するようにアノテーションを追加できます。
前提条件
-
KataConfig
カスタムリソース (CR) を作成している。
手順
-
OpenShift Container Platform Web コンソールで、Workloads
workload type (例: Pods) に移動します。 - ワークロードタイプページで、オブジェクトをクリックして詳細を表示します。
- YAML タブをクリックします。
次の例のように、各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに
spec.runtimeClassName: kata-remote
を追加します。apiVersion: v1 kind: <object> # ... spec: runtimeClassName: kata-remote # ...
apiVersion: v1 kind: <object> # ... spec: runtimeClassName: kata-remote # ...
Copy to Clipboard Copied! 手動で定義されたインスタンスタイプまたは自動インスタンスタイプを使用するには、Pod テンプレートオブジェクトにアノテーションを追加します。
手動で定義されたインスタンスタイプを使用するには、次のアノテーションを追加します。
apiVersion: v1 kind: <object> metadata: annotations: io.katacontainers.config.hypervisor.machine_type: "t3.medium" # ...
apiVersion: v1 kind: <object> metadata: annotations: io.katacontainers.config.hypervisor.machine_type: "t3.medium"
1 # ...
Copy to Clipboard Copied! 自動インスタンスタイプを使用するには、次のアノテーションを追加します。
apiVersion: v1 kind: <Pod> metadata: annotations: io.katacontainers.config.hypervisor.default_vcpus: <vcpus> io.katacontainers.config.hypervisor.default_memory: <memory> # ...
apiVersion: v1 kind: <Pod> metadata: annotations: io.katacontainers.config.hypervisor.default_vcpus: <vcpus> io.katacontainers.config.hypervisor.default_memory: <memory> # ...
Copy to Clipboard Copied! ワークロードが使用できるメモリーの量を定義します。ワークロードは、使用可能なメモリーの量に基づいて自動インスタンスタイプで実行されます。
Save をクリックして変更を適用します。
OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。
検証
-
Pod テンプレートオブジェクトの
spec.runtimeClassName
フィールドを検査します。値がkata-remote
の場合、ワークロードはピア Pod を使用して OpenShift Sandboxed Containers で実行されています。