3.3. コマンドラインを使用した OpenShift Sandboxed Containers のデプロイ
コマンドラインインターフェイス (CLI) を使用して次のタスクを実行することにより、AWS に OpenShift sandboxed containers をデプロイできます。
- OpenShift Sandboxed Containers Operator を再インストールします。
- オプション: 各ワーカーノードで実行されている仮想マシンの数を変更します。
- ピア Pod との内部通信を許可するには、ポート 15150 と 9000 を有効にします。
- ピア Pod シークレットを作成します。
- ピア Pod の config map を作成します。
-
KataConfigカスタムリソースを作成します。 - OpenShift Sandboxed Containers のワークロードオブジェクトを設定します。
3.3.1. OpenShift Sandboxed Containers Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
CLI を使用して、OpenShift Sandboxed Containers Operator をインストールできます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
osc-namespace.yamlマニフェストファイルを作成します。apiVersion: v1 kind: Namespace metadata: name: openshift-sandboxed-containers-operator以下のコマンドを実行して namespace を作成します。
$ oc apply -f osc-namespace.yamlosc-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以下のコマンドを実行して Operator グループを作成します。
$ oc apply -f osc-operatorgroup.yamlosc-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次のコマンドを実行して、サブスクリプションを作成します。
$ oc apply -f osc-subscription.yaml次のコマンドを実行して、Operator が正常にインストールされていることを確認します。
$ oc get csv -n openshift-sandboxed-containers-operatorこのコマンドが完了するまでに数分かかる場合があります。
次のコマンドを実行してプロセスを監視します。
$ 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) の制限を変更できます。
手順
次のコマンドを実行して、現在の制限を確認します。
$ oc get peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \ -o jsonpath='{.spec.limit}{"\n"}'次のコマンドを実行して、
peerpodConfigCR の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ロールを持つユーザーとしてクラスターにアクセスできる。
手順
OpenShift Container Platform クラスターにログインし、インスタンス 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}')セキュリティーグループ ID を取得し、配列に保存します。
$ AWS_SG_IDS=($(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} \ --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' \ --output text --region $AWS_REGION))各セキュリティーグループ 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 シークレットの作成 リンクのコピーリンクがクリップボードにコピーされました!
ピア 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
-
手順
次の例に従って
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 以下のコマンドを実行してシークレットを作成します。
$ 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 がある。
手順
AWS インスタンスから以下の値を取得します。
インスタンス 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}') && echo "AWS_REGION: \"$AWS_REGION\""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 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 セキュリティーグループ 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\""
以下の例に従って
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 を使用して
KataConfigCR を実行するときに入力されます。独自の AMI を作成する場合は、正しい AMI ID を指定します。 - 4
- 取得した
AWS_REGION値を指定します。 - 5
- 取得した
AWS_SUBNET_ID値を指定します。 - 6
- 取得した
AWS_VPC_ID値を指定します。 - 7
- 取得した
AWS_SG_IDS値を指定します。
以下のコマンドを実行して 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という名前のRuntimeClassCR を作成します。これにより、RuntimeClassNameフィールドの CR を参照して、kata-remoteをランタイムとして使用するようにワークロードを設定できるようになります。この CR は、ランタイムのリソースオーバーヘッドも指定します。
OpenShift Sandboxed Containers は、kata-remote をプライマリーランタイムとしてではなく、クラスター上の セカンダリーオプション のランタイムとしてインストールします。
KataConfig CR を作成すると、ワーカーノードが自動的に再起動します。再起動には 10 分から 60 分以上かかる場合があります。再起動時間を妨げる要因は次のとおりです。
- より多くのワーカーノードを持つ大規模な OpenShift Container Platform デプロイメント。
- BIOS および診断ユーティリティーが有効である。
- SSD ではなくハードディスクドライブにデプロイしている。
- 仮想ノードではなく、ベアメタルなどの物理ノードにデプロイしている。
- CPU とネットワークが遅い。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
以下の例に従って
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')。
次のコマンドを実行して、
KataConfigCR を作成します。$ oc apply -f example-kataconfig.yaml新しい
KataConfigCR が作成され、ワーカーノードにkata-remoteがランタイムクラスとしてインストールされます。インストールを確認する前に、
kata-remoteのインストールが完了し、ワーカーノードが再起動するまで待ちます。次のコマンドを実行して、インストールの進行状況を監視します。
$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"kataNodesの下にあるすべてのワーカーのステータスがinstalledで、理由を指定せずにInProgressの条件がFalseの場合、kata-remoteはクラスターにインストールされます。次のコマンドを実行してデーモンセットを確認します。
$ oc get -n openshift-sandboxed-containers-operator ds/peerpodconfig-ctrl-caa-daemon次のコマンドを実行してランタイムクラスを確認します。
$ 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 仮想マシンイメージが正常に作成されたことを確認できます。
手順
ピア Pod 用に作成した config map を取得します。
$ oc get configmap peer-pods-cm -n openshift-sandboxed-containers-operator -o yamlYAML ファイルの
statusスタンザを確認します。PODVM_AMI_IDパラメーターが入力されている場合は、Pod 仮想マシンイメージが正常に作成されています。
トラブルシューティング
次のコマンドを実行してイベントログを取得します。
$ oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation次のコマンドを実行して、ジョブログを取得します。
$ 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) を作成している。
手順
次の例のように、各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに
spec.runtimeClassName: kata-remoteを追加します。apiVersion: v1 kind: <object> # ... spec: runtimeClassName: kata-remote # ...手動で定義されたインスタンスタイプまたは自動インスタンスタイプを使用するには、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> # ...ワークロードが使用できるメモリーの量を定義します。ワークロードは、使用可能なメモリーの量に基づいて自動インスタンスタイプで実行されます。
次のコマンドを実行して、変更をワークロードオブジェクトに適用します。
$ oc apply -f <object.yaml>OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。
検証
-
Pod テンプレートオブジェクトの
spec.runtimeClassNameフィールドを検査します。値がkata-remoteの場合、ワークロードはピア Pod を使用して OpenShift Sandboxed Containers で実行されています。