4.4. コマンドラインを使用した OpenShift Sandboxed Containers のデプロイ
コマンドラインインターフェイス (CLI) を使用して次のタスクを実行することにより、Azure に OpenShift sandboxed containers をデプロイできます。
- OpenShift Sandboxed Containers Operator を再インストールします。
- オプション: OpenShift sandboxed containers Operator とともにインストールされる Cloud Credential Operator をアンインストールした場合は、ピア Pod シークレットを作成します。
- オプション: カスタム Pod 仮想マシンイメージを選択します。
- ピア Pod の config map を作成します。
- オプション: Azure シークレットを作成します。
- オプション: Kata エージェントポリシーをカスタマイズします。
-
KataConfigカスタムリソースを作成します。 - オプション:各ワーカーノードで実行されている仮想マシンの数を変更します。
- OpenShift Sandboxed Containers のワークロードオブジェクトを設定します。
4.4.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.9.0次のコマンドを実行して、サブスクリプションを作成します。
$ 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.9.0 1.8.1 Succeeded
4.4.2. ピア Pod シークレットの作成 リンクのコピーリンクがクリップボードにコピーされました!
ピア Pod のシークレットが空で、Cloud Credential Operator (CCO) がインストールされている場合、OpenShift sandboxed containers Operator は CCO を使用してシークレットを取得します。CCO をアンインストールした場合は、OpenShift sandboxed containers のピア Pod シークレットを手動で作成する必要があります。そうしないと、ピア Pod は動作しなくなります。
シークレットには、Pod 仮想マシン (VM) イメージとピア Pod インスタンスを作成するための認証情報が保存されます。
デフォルトでは、OpenShift Sandboxed Containers Operator はクラスターの作成に使用される認証情報に基づいてシークレットを作成します。ただし、異なる認証情報を使用するシークレットを手動で作成することはできます。
前提条件
- Azure CLI ツールをインストールして設定している。
手順
次のコマンドを実行して、Azure サブスクリプション ID を取得します。
$ AZURE_SUBSCRIPTION_ID=$(az account list --query "[?isDefault].id" \ -o tsv) && echo "AZURE_SUBSCRIPTION_ID: \"$AZURE_SUBSCRIPTION_ID\""次のコマンドを実行して RBAC コンテンツを生成します。
$ az ad sp create-for-rbac --role Contributor --scopes /subscriptions/$AZURE_SUBSCRIPTION_ID \ --query "{ client_id: appId, client_secret: password, tenant_id: tenant }"出力例
{ "client_id": `AZURE_CLIENT_ID`, "client_secret": `AZURE_CLIENT_SECRET`, "tenant_id": `AZURE_TENANT_ID` }-
secretオブジェクトで使用する RBAC 出力を記録します。 次の例に従って
peer-pods-secret.yamlマニフェストファイルを作成します。apiVersion: v1 kind: Secret metadata: name: peer-pods-secret namespace: openshift-sandboxed-containers-operator type: Opaque stringData: AZURE_CLIENT_ID: "<azure_client_id>"1 AZURE_CLIENT_SECRET: "<azure_client_secret>"2 AZURE_TENANT_ID: "<azure_tenant_id>"3 AZURE_SUBSCRIPTION_ID: "<azure_subscription_id>"4 以下のコマンドを実行してシークレットを作成します。
$ oc apply -f peer-pods-secret.yaml
4.4.3. ピア Pod config map の作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift sandboxed containers のピア Pod config map を作成する必要があります。
手順
Azure インスタンスから以下の値を取得します。
Azure リソースグループを取得して記録します。
$ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}') && echo "AZURE_RESOURCE_GROUP: \"$AZURE_RESOURCE_GROUP\""Azure VNet 名を取得し、記録します。
$ AZURE_VNET_NAME=$(az network vnet list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)この値は、Azure サブネット ID を取得するために使用されます。
Azure サブネット ID を取得して記録します。
$ AZURE_SUBNET_ID=$(az network vnet subnet list --resource-group ${AZURE_RESOURCE_GROUP} --vnet-name $AZURE_VNET_NAME --query "[].{Id:id} | [? contains(Id, 'worker')]" --output tsv) && echo "AZURE_SUBNET_ID: \"$AZURE_SUBNET_ID\""Azure ネットワークセキュリティーグループ (NSG) ID を取得して記録します。
$ AZURE_NSG_ID=$(az network nsg list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Id:id}" --output tsv) && echo "AZURE_NSG_ID: \"$AZURE_NSG_ID\""Azure リージョンを取得して記録します。
$ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP} --query "{Location:location}" --output tsv) && echo "AZURE_REGION: \"$AZURE_REGION\""
以下の例に従って
peer-pods-cm.yamlマニフェストファイルを作成します。apiVersion: v1 kind: ConfigMap metadata: name: peer-pods-cm namespace: openshift-sandboxed-containers-operator data: CLOUD_PROVIDER: "azure" VXLAN_PORT: "9000" AZURE_INSTANCE_SIZE: "Standard_B2als_v2"1 AZURE_INSTANCE_SIZES: "Standard_B2als_v2,Standard_D2as_v5,Standard_D4as_v5,Standard_D2ads_v5"2 AZURE_SUBNET_ID: "<azure_subnet_id>"3 AZURE_NSG_ID: "<azure_nsg_id>"4 PROXY_TIMEOUT: "5m" AZURE_IMAGE_ID: "<azure_image_id>"5 AZURE_REGION: "<azure_region>"6 AZURE_RESOURCE_GROUP: "<azure_resource_group>"7 PEERPODS_LIMIT_PER_NODE: "10"8 TAGS: "key1=value1,key2=value2"9 DISABLECVM: "true"- 1
- インスタンスサイズがワークロードで定義されていない場合、
"Standard_B2als_v2"インスタンスサイズがデフォルト値になります。 - 2
- Pod を作成するための、スペースなしのインスタンスサイズを指定します。これにより、メモリーと CPU をあまり必要としないワークロードには小さいインスタンスサイズを定義したり、ワークロードが大きい場合は大きいインスタンスサイズを定義したりすることができます。
- 3
- 取得した
AZURE_SUBNET_ID値を指定します。 - 4
- 取得した
AZURE_NSG_ID値を指定します。 - 5
- オプション: デフォルトでは、この値は、クラスターの認証情報に基づく Azure イメージ ID を使用して
KataConfigCR を実行するときに入力されます。独自の Azure イメージを作成する場合は、正しいイメージ ID を指定します。 - 6
- 取得した
AZURE_REGION値を指定します。 - 7
- 取得した
AZURE_RESOURCE_GROUP値を指定します。 - 8
- ノードごとに作成できるピア Pod の最大数を指定します。デフォルト値は
10です。 - 9
- Pod 仮想マシンインスタンスの
key:valueペアとしてカスタムタグを設定して、ピア Pod のコストを追跡したり、異なるクラスター内のピア Pod を識別したりできます。
以下のコマンドを実行して config map を作成します。
$ oc apply -f peer-pods-cm.yaml
4.4.4. カスタムピア Pod 仮想マシンイメージの選択 リンクのコピーリンクがクリップボードにコピーされました!
Pod マニフェストにアノテーションを追加することで、ワークロード要件に合わせてカスタマイズされたカスタムピア Pod 仮想マシン (VM) イメージを選択できます。カスタムイメージは、ピア Podconfig map で指定されたデフォルトイメージをオーバーライドします。
前提条件
- 使用予定のカスタム Pod 仮想マシンイメージの ID が利用でき、クラウドプロバイダーまたはハイパーバイザーと互換性がある。
手順
io.katacontainers.config.hypervisor.imageアノテーションを追加して Pod マニフェストを編集し、pod-manifest.yamlファイルに保存します。apiVersion: v1 kind: Pod metadata: name: pod-manifest annotations: io.katacontainers.config.hypervisor.image: "<custom_image_id>"1 spec: runtimeClassName: kata-remote2 containers: - name: <example_container>3 image: registry.access.redhat.com/ubi9/ubi:9.3 command: ["sleep", "36000"]以下のコマンドを実行して Pod を作成します。
$ oc apply -f pod-manifest.yaml
4.4.5. Azure シークレットの作成 リンクのコピーリンクがクリップボードにコピーされました!
Azure 仮想マシン (VM) 作成 API に必要な SSH 鍵シークレットを作成する必要があります。Azure では SSH 公開鍵のみが必要です。Confidential Containers は仮想マシン内の SSH を無効にするため、鍵は仮想マシン内で効果がありません。
手順
次のコマンドを実行して、SSH キーペアを生成します。
$ ssh-keygen -f ./id_rsa -N ""以下のコマンドを実行して
Secretオブジェクトを作成します。$ oc create secret generic ssh-key-secret \ -n openshift-sandboxed-containers-operator \ --from-file=id_rsa.pub=./id_rsa.pub \ --from-file=id_rsa=./id_rsa作成した SSH 鍵を削除します。
$ shred --remove id_rsa.pub id_rsa
4.4.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このポリシーは、
exec(ExecProcessRequest) およびlog(ReadStreamRequest) API を有効にします。必要に応じて、trueまたはfalseの値を調整してポリシーをさらにカスタマイズします。次のコマンドを実行して、
policy.regoファイルを Base64 でエンコードされた文字列に変換します。$ base64 -w0 policy.regoyaml ファイルで使用するために出力を保存します。
Base64 でエンコードされたポリシーを
my-pod.yamlPod 仕様ファイルに追加します。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以下のコマンドを実行して Pod マニフェストを適用します。
$ oc apply -f my-pod.yaml
4.4.7. 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/osc-caa-ds次のコマンドを実行してランタイムクラスを確認します。
$ oc get runtimeclass出力例
NAME HANDLER AGE kata kata 152m kata-remote kata-remote 152m
4.4.8. ノードあたりのピア 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> は、定義する制限に置き換えます。
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スタンザを確認します。AZURE_IMAGE_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 サポートケースを送信し、両方のログの出力を添付してください。
4.4.9. ワークロードオブジェクトの設定 リンクのコピーリンクがクリップボードにコピーされました!
次の 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: "Standard_B2als_v2"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 で実行されています。