ユーザーガイド

手順

1. Web コンソールで、Operators → OperatorHub に移動します。
2. Filter by keyword フィールドに OpenShift sandboxed containers と入力します。
3. OpenShift sandboxed containers Operator タイルを選択し、Install をクリックします。
4. Install Operator ページで、利用可能な Update Channel オプションの一覧から stable を選択します。

5. Installed Namespace で Operator recommended Namespace が選択されていることを確認します。これにより、Operator が必須の openshift-sandboxed-containers-operator namespace にインストールされます。この namespace がまだ存在しない場合は、自動的に作成されます。

   注記

   OpenShift Sandboxed Containers Operator を openshift-sandboxed-containers-operator 以外の namespace にインストールしようとすると、インストールに失敗します。

6. Approval Strategy で Automatic が選択されていることを確認します。Automatic がデフォルト値であり、新しい z-stream リリースが利用可能になると、OpenShift Sandboxed Containers への自動更新が有効になります。
7. Install をクリックします。
8. Operator → Installed Operator に移動して、Operator がインストールされていることを確認します。

手順

1. カスタムポリシーを含む 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 の値を調整してポリシーをさらにカスタマイズします。

2. 次のコマンドを実行して、policy.rego ファイルを Base64 でエンコードされた文字列に変換します。

   $ base64 -w0 policy.rego

   次のステップで使用するために出力をコピーします。

3. Base64 でエンコードされたポリシーを my-pod.yaml Pod 仕様ファイルに追加します。

   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

4. 以下のコマンドを実行して Pod マニフェストを適用します。

   $ oc apply -f my-pod.yaml

手順

1. OpenShift Container Platform Web コンソールで、Operators → Installed Operators に移動します。
2. OpenShift sandboxed containers Operator を選択します。
3. KataConfig タブで、Create KataConfig をクリックします。

4. 以下の詳細を入力します。

   • Name: オプション: デフォルト名は example-kataconfig です。
   • Labels: オプション: 関連する識別属性を KataConfig リソースに入力します。各ラベルはキーと値のペアを表します。
   • checkNodeEligibility : オプション: Node Feature Discovery Operator (NFD) を使用してノードの適格性を検出する場合に選択します。

   • kataConfigPoolSelector。オプション: 選択したノードに kata をインストールするには、選択したノードのラベルに一致する式を追加します。

     1. kataConfigPoolSelector エリアを展開します。
     2. kataConfigPoolSelector エリアで、matchExpressions を展開します。これは、ラベルセレクターの要件のリストです。
     3. Add matchExpressions をクリックします。
     4. Key フィールドに、セレクターの適用先のラベルキーを入力します。
     5. Operator フィールドに、キーとラベル値の関係を入力します。有効な演算子は、In、NotIn、Exists、DoesNotExist です。
     6. Values エリアを展開し、Add value をクリックします。
     7. Value フィールドで、true または false を key ラベル値として入力します。
   • logLevel: ランタイムクラスが kata のノードに対して取得されるログデータのレベルを定義します。

5. Create をクリックします。KataConfig CR が作成され、ワーカーノードに kata ランタイムクラスをインストールします。

   kata のインストールが完了し、ワーカーノードが再起動するのを待ってから、インストールを検証します。

検証

1. KataConfig タブで、KataConfig CR をクリックして詳細を表示します。

2. YAML タブをクリックして status スタンザを表示します。

   status スタンザには、conditions および kataNodes キーが含まれています。status.kataNodes の値はノード配列であり、各ノードには kata インストールの特定の状態にあるノードがリストされます。更新があるたびにメッセージが表示されます。

3. Reload をクリックして、YAML を更新します。

   status.kataNodes 配列内のすべてのワーカーに、installed の値と、理由が指定されていない conditions.InProgress: False が表示される場合、kata がクラスターにインストールされています。

手順

1. OpenShift Container Platform Web コンソールで、Workloads → workload type (例: Pods) に移動します。
2. ワークロードタイプページで、オブジェクトをクリックして詳細を表示します。
3. YAML タブをクリックします。

4. 次の例のように、spec.runtimeClassName: kata を各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに追加します。

   apiVersion: v1
   kind: <object>
   # ...
   spec:
     runtimeClassName: kata
   # ...

   OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。

手順

1. osc-namespace.yaml マニフェストファイルを作成します。

   apiVersion: v1
   kind: Namespace
   metadata:
     name: openshift-sandboxed-containers-operator

2. 以下のコマンドを実行して namespace を作成します。

   $ oc apply -f osc-namespace.yaml

3. osc-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

4. 以下のコマンドを実行して Operator グループを作成します。

   $ oc apply -f osc-operatorgroup.yaml

5. osc-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

6. 次のコマンドを実行して、サブスクリプションを作成します。

   $ oc apply -f osc-subscription.yaml

7. 次のコマンドを実行して、Operator が正常にインストールされていることを確認します。

   $ oc get csv -n openshift-sandboxed-containers-operator

   このコマンドが完了するまでに数分かかる場合があります。

8. 次のコマンドを実行してプロセスを監視します。

   $ 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

手順

1. カスタムポリシーを含む 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 の値を調整してポリシーをさらにカスタマイズします。

2. 次のコマンドを実行して、policy.rego ファイルを Base64 でエンコードされた文字列に変換します。

   $ base64 -w0 policy.rego

   次のステップで使用するために出力をコピーします。

3. Base64 でエンコードされたポリシーを my-pod.yaml Pod 仕様ファイルに追加します。

   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

4. 以下のコマンドを実行して Pod マニフェストを適用します。

   $ oc apply -f my-pod.yaml

手順

1. 以下の例に従って example-kataconfig.yaml マニフェストファイルを作成します。

   apiVersion: kataconfiguration.openshift.io/v1
   kind: KataConfig
   metadata:
     name: example-kataconfig
   spec:
     checkNodeEligibility: false 1
     logLevel: info
   #  kataConfigPoolSelector:
   #    matchLabels:
   #      <label_key>: '<label_value>' 2

   1

   オプション: ノード適格性チェックを実行するには、`checkNodeEligibility` を true に設定します。

   2

   オプション: 特定のノードに OpenShift sandboxed containers をインストールするためにノードラベルを適用した場合は、キーと値を指定します。

2. 次のコマンドを実行して、KataConfig CR を作成します。

   $ oc apply -f example-kataconfig.yaml

   新しい KataConfig CR が作成され、ワーカーノードにランタイムクラスとして kata がインストールされます。

   kata のインストールが完了し、ワーカーノードが再起動するのを待ってから、インストールを検証します。

3. 次のコマンドを実行して、インストールの進行状況を監視します。

   $ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"

   kataNodes の下にあるすべてのワーカーのステータスが installed で、理由を指定せずに InProgress の条件が False の場合、kata はクラスターにインストールされます。

手順

1. 次のコマンドを実行して、RuntimeClass オブジェクトを取得します。

   $ oc describe runtimeclass kata

2. overhead.podFixed.memory および cpu の値を更新し、ファイルを runtimeclass.yaml として保存します。

   kind: RuntimeClass
   apiVersion: node.k8s.io/v1
   metadata:
     name: kata
   overhead:
     podFixed:
       memory: "500Mi"
       cpu: "500m"

3. 次のコマンドを実行して変更を適用します。

   $ oc apply -f runtimeclass.yaml

手順

1. 次の例のように、spec.runtimeClassName: kata を各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに追加します。

   apiVersion: v1
   kind: <object>
   # ...
   spec:
     runtimeClassName: kata
   # ...

   OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。

手順

1. Web コンソールで、Operators → OperatorHub に移動します。
2. Filter by keyword フィールドに OpenShift sandboxed containers と入力します。
3. OpenShift sandboxed containers Operator タイルを選択し、Install をクリックします。
4. Install Operator ページで、利用可能な Update Channel オプションの一覧から stable を選択します。

5. Installed Namespace で Operator recommended Namespace が選択されていることを確認します。これにより、Operator が必須の openshift-sandboxed-containers-operator namespace にインストールされます。この namespace がまだ存在しない場合は、自動的に作成されます。

   注記

   OpenShift Sandboxed Containers Operator を openshift-sandboxed-containers-operator 以外の namespace にインストールしようとすると、インストールに失敗します。

6. Approval Strategy で Automatic が選択されていることを確認します。Automatic がデフォルト値であり、新しい z-stream リリースが利用可能になると、OpenShift Sandboxed Containers への自動更新が有効になります。
7. Install をクリックします。
8. Operator → Installed Operator に移動して、Operator がインストールされていることを確認します。

手順

1. OpenShift Container Platform クラスターにログインし、インスタンス 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. セキュリティーグループ ID を取得し、配列に保存します。

   $ AWS_SG_IDS=($(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} \
     --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' \
     --output text --region $AWS_REGION))

4. 各セキュリティーグループ 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

手順

1. OpenShift Container Platform Web コンソールで、Operators → Installed Operators に移動します。
2. OpenShift sandboxed containers Operator タイルをクリックします。
3. 右上隅のインポートアイコン (+) をクリックします。

4. 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>" 1
     AWS_SECRET_ACCESS_KEY: "<aws_secret_access_key>" 2

   1

   AWS_ACCESS_KEY_ID 値を指定します。

   2

   AWS_SECRET_ACCESS_KEY 値を指定します。

5. Save をクリックして変更を適用します。
6. Workloads → Secrets に移動して、ピア Pod シークレットを確認します。

手順

1. AWS インスタンスから以下の値を取得します。

   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}') && echo "AWS_REGION: \"$AWS_REGION\""

   3. 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\""

   4. 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\""

   5. 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\""

2. OpenShift Container Platform Web コンソールで、Operators → Installed Operators に移動します。
3. Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
4. 右上隅にあるインポートアイコン (+) をクリックします。

5. 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" 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"

   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 を識別したりできます。

6. Save をクリックして変更を適用します。
7. 新しい config map を表示するには、Workloads → ConfigMaps に移動します。

手順

1. OpenShift Container Platform Web コンソールで、Operators → Installed Operators に移動します。
2. Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
3. 右上隅にあるインポートアイコン (+) をクリックします。

4. Import YAML ウィンドウに、次の YAML マニフェストを貼り付けます。

   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"]

5. Save をクリックして変更を適用します。

手順

1. カスタムポリシーを含む 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 の値を調整してポリシーをさらにカスタマイズします。

2. 次のコマンドを実行して、policy.rego ファイルを Base64 でエンコードされた文字列に変換します。

   $ base64 -w0 policy.rego

   次のステップで使用するために出力をコピーします。

3. Base64 でエンコードされたポリシーを my-pod.yaml Pod 仕様ファイルに追加します。

   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

4. 以下のコマンドを実行して Pod マニフェストを適用します。

   $ oc apply -f my-pod.yaml

手順

1. OpenShift Container Platform Web コンソールで、Operators → Installed Operators に移動します。
2. OpenShift sandboxed containers Operator を選択します。
3. KataConfig タブで、Create KataConfig をクリックします。

4. 以下の詳細を入力します。

   • Name: オプション: デフォルト名は example-kataconfig です。
   • Labels: オプション: 関連する識別属性を KataConfig リソースに入力します。各ラベルはキーと値のペアを表します。
   • enablePeerPods: パブリッククラウド、IBM Z®、および IBM® LinuxONE デプロイメントの場合に選択します。

   • kataConfigPoolSelector。オプション: 選択したノードに kata-remote をインストールするには、選択したノードのラベルに一致する式を追加します。

     1. kataConfigPoolSelector エリアを展開します。
     2. kataConfigPoolSelector エリアで、matchExpressions を展開します。これは、ラベルセレクターの要件のリストです。
     3. Add matchExpressions をクリックします。
     4. Key フィールドに、セレクターの適用先のラベルキーを入力します。
     5. Operator フィールドに、キーとラベル値の関係を入力します。有効な演算子は、In、NotIn、Exists、DoesNotExist です。
     6. Values エリアを展開し、Add value をクリックします。
     7. Value フィールドで、true または false を key ラベル値として入力します。
   • logLevel: ランタイムクラスが kata-remote のノードに対して取得されるログデータのレベルを定義します。

5. Create をクリックします。KataConfig CR が作成され、ワーカーノードに kata-remote ランタイムクラスをインストールします。

   インストールを確認する前に、kata-remote のインストールが完了し、ワーカーノードが再起動するまで待ちます。

検証

1. KataConfig タブで、KataConfig CR をクリックして詳細を表示します。

2. YAML タブをクリックして status スタンザを表示します。

   status スタンザには、conditions および kataNodes キーが含まれています。status.kataNodes の値はノード配列であり、各ノードには kata-remote インストールの特定の状態にあるノードがリストされます。更新があるたびにメッセージが表示されます。

3. Reload をクリックして、YAML を更新します。

   status.kataNodes 配列内のすべてのワーカーに、値 installed と、理由が指定されていない conditions.InProgress: False が表示される場合、kata-remote はクラスターにインストールされています。

手順

1. Workloads → ConfigMaps に移動します。
2. プロバイダー config map をクリックすると、詳細が表示されます。
3. YAML タブをクリックします。

4. YAML ファイルの status スタンザを確認します。

   PODVM_AMI_ID パラメーターが入力されている場合は、Pod 仮想マシンイメージが正常に作成されています。

トラブルシューティング

1. 次のコマンドを実行してイベントログを取得します。

   $ oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation

2. 次のコマンドを実行して、ジョブログを取得します。

   $ oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creation

手順

1. OpenShift Container Platform Web コンソールで、Workloads → workload type (例: Pods) に移動します。
2. ワークロードタイプページで、オブジェクトをクリックして詳細を表示します。
3. YAML タブをクリックします。

4. 次の例のように、各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに spec.runtimeClassName: kata-remote を追加します。

   apiVersion: v1
   kind: <object>
   # ...
   spec:
     runtimeClassName: kata-remote
   # ...

5. 手動で定義されたインスタンスタイプまたは自動インスタンスタイプを使用するには、Pod テンプレートオブジェクトにアノテーションを追加します。

   • 手動で定義されたインスタンスタイプを使用するには、次のアノテーションを追加します。

     apiVersion: v1
     kind: <object>
     metadata:
       annotations:
         io.katacontainers.config.hypervisor.machine_type: "t3.medium" 1
     # ...

     1 1

     config map で定義したインスタンスタイプを指定します。

   • 自動インスタンスタイプを使用するには、次のアノテーションを追加します。

     apiVersion: v1
     kind: <Pod>
     metadata:
       annotations:
         io.katacontainers.config.hypervisor.default_vcpus: <vcpus>
         io.katacontainers.config.hypervisor.default_memory: <memory>
     # ...

     ワークロードが使用できるメモリーの量を定義します。ワークロードは、使用可能なメモリーの量に基づいて自動インスタンスタイプで実行されます。

6. Save をクリックして変更を適用します。

   OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。

手順

1. osc-namespace.yaml マニフェストファイルを作成します。

   apiVersion: v1
   kind: Namespace
   metadata:
     name: openshift-sandboxed-containers-operator

2. 以下のコマンドを実行して namespace を作成します。

   $ oc apply -f osc-namespace.yaml

3. osc-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

4. 以下のコマンドを実行して Operator グループを作成します。

   $ oc apply -f osc-operatorgroup.yaml

5. osc-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

6. 次のコマンドを実行して、サブスクリプションを作成します。

   $ oc apply -f osc-subscription.yaml

7. 次のコマンドを実行して、Operator が正常にインストールされていることを確認します。

   $ oc get csv -n openshift-sandboxed-containers-operator

   このコマンドが完了するまでに数分かかる場合があります。

8. 次のコマンドを実行してプロセスを監視します。

   $ 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

手順

1. OpenShift Container Platform クラスターにログインし、インスタンス 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. セキュリティーグループ ID を取得し、配列に保存します。

   $ AWS_SG_IDS=($(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} \
     --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' \
     --output text --region $AWS_REGION))

4. 各セキュリティーグループ 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

手順

1. 次の例に従って 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

   1

   AWS_ACCESS_KEY_ID 値を指定します。

   2

   AWS_SECRET_ACCESS_KEY 値を指定します。

2. 以下のコマンドを実行してシークレットを作成します。

   $ oc apply -f peer-pods-secret.yaml

手順

1. AWS インスタンスから以下の値を取得します。

   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}') && echo "AWS_REGION: \"$AWS_REGION\""

   3. 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\""

   4. 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\""

   5. 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\""

2. 以下の例に従って 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
     PEERPODS_LIMIT_PER_NODE: "10" 8
     TAGS: "key1=value1,key2=value2" 9
     DISABLECVM: "true"

   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 を識別したりできます。

3. 以下のコマンドを実行して config map を作成します。

   $ oc apply -f peer-pods-cm.yaml

手順

1. 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-remote 2
     containers:
     - name: <example_container> 3
       image: registry.access.redhat.com/ubi9/ubi:9.3
       command: ["sleep", "36000"]

   1

   カスタムピア Pod イメージ ID を指定します。

   2

   ピア Pod を作成するには、runtimeClassName フィールドが kata-remote に設定されていることを確認します。

   3

   コンテナー名を指定します。

2. 以下のコマンドを実行して Pod を作成します。

   $ oc apply -f pod-manifest.yaml

手順

1. カスタムポリシーを含む 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 の値を調整してポリシーをさらにカスタマイズします。

2. 次のコマンドを実行して、policy.rego ファイルを Base64 でエンコードされた文字列に変換します。

   $ base64 -w0 policy.rego

   次のステップで使用するために出力をコピーします。

3. Base64 でエンコードされたポリシーを my-pod.yaml Pod 仕様ファイルに追加します。

   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

4. 以下のコマンドを実行して Pod マニフェストを適用します。

   $ oc apply -f my-pod.yaml

手順

1. 以下の例に従って 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')。

2. 次のコマンドを実行して、KataConfig CR を作成します。

   $ oc apply -f example-kataconfig.yaml

   新しい KataConfig CR が作成され、ワーカーノードに kata-remote がランタイムクラスとしてインストールされます。

   インストールを確認する前に、kata-remote のインストールが完了し、ワーカーノードが再起動するまで待ちます。

3. 次のコマンドを実行して、インストールの進行状況を監視します。

   $ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"

   kataNodes の下にあるすべてのワーカーのステータスが installed で、理由を指定せずに InProgress の条件が False の場合、kata-remote はクラスターにインストールされます。

4. 次のコマンドを実行してデーモンセットを確認します。

   $ oc get -n openshift-sandboxed-containers-operator ds/osc-caa-ds

5. 次のコマンドを実行してランタイムクラスを確認します。

   $ oc get runtimeclass

   出力例

   NAME             HANDLER          AGE
   kata             kata             152m
   kata-remote      kata-remote      152m

手順

1. ピア Pod 用に作成した config map を取得します。

   $ oc get configmap peer-pods-cm -n openshift-sandboxed-containers-operator -o yaml

2. YAML ファイルの status スタンザを確認します。

   PODVM_AMI_ID パラメーターが入力されている場合は、Pod 仮想マシンイメージが正常に作成されています。

トラブルシューティング

1. 次のコマンドを実行してイベントログを取得します。

   $ oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation

2. 次のコマンドを実行して、ジョブログを取得します。

   $ oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creation

手順

1. 次の例のように、各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに spec.runtimeClassName: kata-remote を追加します。

   apiVersion: v1
   kind: <object>
   # ...
   spec:
     runtimeClassName: kata-remote
   # ...

2. 手動で定義されたインスタンスタイプまたは自動インスタンスタイプを使用するには、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>
     # ...

     ワークロードが使用できるメモリーの量を定義します。ワークロードは、使用可能なメモリーの量に基づいて自動インスタンスタイプで実行されます。

3. 次のコマンドを実行して、変更をワークロードオブジェクトに適用します。

   $ oc apply -f <object.yaml>

   OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。

手順

1. 次のコマンドを実行して、AZURE_RESOURCE_GROUP 環境変数を設定します。

   $ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster \
       -o jsonpath='{.status.platformStatus.azure.resourceGroupName}')

2. 次のコマンドを実行して、AZURE_REGION 環境変数を設定します。

   $ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP}\
       --query "{Location:location}" --output tsv) && \
       echo "AZURE_REGION: \"$AZURE_REGION\""

3. 次のコマンドを実行して、AZURE_VNET_NAME 環境変数を設定します。

   $ AZURE_VNET_NAME=$(az network vnet list \
       -g "${AZURE_RESOURCE_GROUP}" --query '[].name' -o tsv)

4. 次のコマンドを実行して、AZURE_SUBNET_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)

5. 次のコマンドを実行して、ピア Pod サブネットの NAT ゲートウェイ環境変数を設定します。

   $ export PEERPOD_NAT_GW=peerpod-nat-gw

   $ export PEERPOD_NAT_GW_IP=peerpod-nat-gw-ip

6. 次のコマンドを実行して、NAT ゲートウェイのパブリック IP アドレスを作成します。

   $ az network public-ip create -g "${AZURE_RESOURCE_GROUP}" \
       -n "${PEERPOD_NAT_GW_IP}" -l "${AZURE_REGION}" --sku Standard

7. 次のコマンドを実行して、NAT ゲートウェイを作成し、パブリック IP アドレスに関連付けます。

   $ az network nat gateway create -g "${AZURE_RESOURCE_GROUP}" \
       -l "${AZURE_REGION}" --public-ip-addresses "${PEERPOD_NAT_GW_IP}" \
       -n "${PEERPOD_NAT_GW}"

8. 以下のコマンドを実行して、NAT ゲートウェイを使用するように VNet サブネットを更新します。

   $ az network vnet subnet update --nat-gateway "${PEERPOD_NAT_GW}" \
       --ids "${AZURE_SUBNET_ID}"

手順

1. ピア Pod ネットワークの環境変数を設定します。

   1. 次のコマンドを実行して、ピア Pod VNet 環境変数を設定します。

      $ export PEERPOD_VNET_NAME="${PEERPOD_VNET_NAME:-peerpod-vnet}"

      $ export PEERPOD_VNET_CIDR="${PEERPOD_VNET_CIDR:-192.168.0.0/16}"

   2. 次のコマンドを実行して、ピア Pod サブネット環境変数を設定します。

      $ export PEERPOD_SUBNET_NAME="${PEERPOD_SUBNET_NAME:-peerpod-subnet}"

      $ export PEERPOD_SUBNET_CIDR="${PEERPOD_SUBNET_CIDR:-192.168.0.0/16}"

2. Azure の環境変数を設定します。

   $ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster \
       -o jsonpath='{.status.platformStatus.azure.resourceGroupName}')

   $ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP}\
       --query "{Location:location}" --output tsv) && \
       echo "AZURE_REGION: \"$AZURE_REGION\""

   $ AZURE_VNET_NAME=$(az network vnet list \
       -g "${AZURE_RESOURCE_GROUP}" --query '[].name' -o tsv)

3. 次のコマンドを実行して、ピア Pod の NAT ゲートウェイ環境変数を設定します。

   $ export PEERPOD_NAT_GW="${PEERPOD_NAT_GW:-peerpod-nat-gw}"

   $ export PEERPOD_NAT_GW_IP="${PEERPOD_NAT_PUBLIC_IP:-peerpod-nat-gw-ip}"

4. VNET を設定します。

   1. 次のコマンドを実行して、ピア Pod VNet を作成します。

      $ az network vnet create --resource-group "${AZURE_RESOURCE_GROUP}" \
          --name "${PEERPOD_VNET_NAME}" \
          --address-prefixes "${PEERPOD_VNET_CIDR}"

   2. 次のコマンドを実行して、ピア Pod VNet のパブリック IP アドレスを作成します。

      $ az network public-ip create -g "${AZURE_RESOURCE_GROUP}" \
          -n "${PEERPOD_NAT_GW_IP}" -l "${AZURE_REGION}"

   3. 次のコマンドを実行して、ピア Pod VNet の NAT ゲートウェイを作成します。

      $ az network nat gateway create -g "${AZURE_RESOURCE_GROUP}" \
          -l "${AZURE_REGION}" \
          --public-ip-addresses "${PEERPOD_NAT_GW_IP}" \
          -n "${PEERPOD_NAT_GW}"

   4. 次のコマンドを実行して、ピア Pod VNet にサブネットを作成し、NAT ゲートウェイを接続します。

      $ az network vnet subnet create \
          --resource-group "${AZURE_RESOURCE_GROUP}" \
          --vnet-name "${PEERPOD_VNET_NAME}" \
          --name "${PEERPOD_SUBNET_NAME}" \
          --address-prefixes "${PEERPOD_SUBNET_CIDR}" \
          --nat-gateway "${PEERPOD_NAT_GW}"

5. 仮想ネットワークピアリング接続を設定します。

   1. 次のコマンドを実行してピアリング接続を作成します。

      $ az network vnet peering create -g "${AZURE_RESOURCE_GROUP}" \
          -n peerpod-azure-vnet-to-peerpod-vnet \
          --vnet-name "${AZURE_VNET_NAME}" \
          --remote-vnet "${PEERPOD_VNET_NAME}" --allow-vnet-access \
          --allow-forwarded-traffic

   2. 次のコマンドを実行してピアリング接続を同期します。

      $ az network vnet peering sync -g "${AZURE_RESOURCE_GROUP}" \
          -n peerpod-azure-vnet-to-peerpod-vnet \
          --vnet-name "${AZURE_VNET_NAME}"

   3. 次のコマンドを実行してピアリング接続を完了します。

      $ az network vnet peering create -g "${AZURE_RESOURCE_GROUP}" \
          -n peerpod-peerpod-vnet-to-azure-vnet \
          --vnet-name "${PEERPOD_VNET_NAME}" \
          --remote-vnet "${AZURE_VNET_NAME}" --allow-vnet-access \
          --allow-forwarded-traffic

検証

1. 次のコマンドを実行して、クラスター VNet からのピアリング接続ステータスを確認します。

   $ az network vnet peering show -g "${AZURE_RESOURCE_GROUP}" \
       -n peerpod-azure-vnet-to-peerpod-vnet \
       --vnet-name "${AZURE_VNET_NAME}" \
       --query "peeringState" -o tsv

   これにより、Connected が返されるはずです。

2. 次のコマンドを実行して、NAT ゲートウェイがピア Pod サブネットに接続されていることを確認します。

   $ az network vnet subnet show --resource-group "${AZURE_RESOURCE_GROUP}" \
       --vnet-name "${PEERPOD_VNET_NAME}" --name "${PEERPOD_SUBNET_NAME}" \
       --query "natGateway.id" -o tsv

手順

1. Web コンソールで、Operators → OperatorHub に移動します。
2. Filter by keyword フィールドに OpenShift sandboxed containers と入力します。
3. OpenShift sandboxed containers Operator タイルを選択し、Install をクリックします。
4. Install Operator ページで、利用可能な Update Channel オプションの一覧から stable を選択します。

5. Installed Namespace で Operator recommended Namespace が選択されていることを確認します。これにより、Operator が必須の openshift-sandboxed-containers-operator namespace にインストールされます。この namespace がまだ存在しない場合は、自動的に作成されます。

   注記

   OpenShift Sandboxed Containers Operator を openshift-sandboxed-containers-operator 以外の namespace にインストールしようとすると、インストールに失敗します。

6. Approval Strategy で Automatic が選択されていることを確認します。Automatic がデフォルト値であり、新しい z-stream リリースが利用可能になると、OpenShift Sandboxed Containers への自動更新が有効になります。
7. Install をクリックします。
8. Operator → Installed Operator に移動して、Operator がインストールされていることを確認します。

手順

1. 次のコマンドを実行して、Azure サブスクリプション ID を取得します。

   $ AZURE_SUBSCRIPTION_ID=$(az account list --query "[?isDefault].id" \
     -o tsv) && echo "AZURE_SUBSCRIPTION_ID: \"$AZURE_SUBSCRIPTION_ID\""

2. 次のコマンドを実行して 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`
   }

3. secret オブジェクトで使用する RBAC 出力を記録します。
4. OpenShift Container Platform Web コンソールで、Operators → Installed Operators に移動します。
5. OpenShift sandboxed containers Operator タイルをクリックします。
6. 右上隅のインポートアイコン (+) をクリックします。

7. Import YAML ウィンドウに、次の 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

   1

   AZURE_CLIENT_ID 値を指定します。

   2

   AZURE_CLIENT_SECRET 値を指定します。

   3

   AZURE_TENANT_ID 値を指定します。

   4

   AZURE_SUBSCRIPTION_ID 値を指定します。

8. Save をクリックして変更を適用します。
9. Workloads → Secrets に移動して、ピア Pod シークレットを確認します。

手順

1. Azure インスタンスから以下の値を取得します。

   1. Azure リソースグループを取得して記録します。

      $ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}') && echo "AZURE_RESOURCE_GROUP: \"$AZURE_RESOURCE_GROUP\""

   2. Azure VNet 名を取得し、記録します。

      $ AZURE_VNET_NAME=$(az network vnet list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)

      この値は、Azure サブネット ID を取得するために使用されます。

   3. 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\""

   4. 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\""

   5. Azure リージョンを取得して記録します。

      $ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP} --query "{Location:location}" --output tsv) && echo "AZURE_REGION: \"$AZURE_REGION\""

2. OpenShift Container Platform Web コンソールで、Operators → Installed Operators に移動します。
3. Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
4. 右上隅にあるインポートアイコン (+) をクリックします。

5. Import YAML ウィンドウに、次の 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 を使用して KataConfig CR を実行するときに入力されます。独自の Azure イメージを作成する場合は、正しいイメージ ID を指定します。

   6

   取得した AZURE_REGION 値を指定します。

   7

   取得した AZURE_RESOURCE_GROUP 値を指定します。

   8

   ノードごとに作成できるピア Pod の最大数を指定します。デフォルト値は 10 です。

   9

   Pod 仮想マシンインスタンスの key:value ペアとしてカスタムタグを設定して、ピア Pod のコストを追跡したり、異なるクラスター内のピア Pod を識別したりできます。

6. Save をクリックして変更を適用します。
7. 新しい config map を表示するには、Workloads → ConfigMaps に移動します。

手順

1. OpenShift Container Platform Web コンソールで、Operators → Installed Operators に移動します。
2. Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
3. 右上隅にあるインポートアイコン (+) をクリックします。

4. Import YAML ウィンドウに、次の YAML マニフェストを貼り付けます。

   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"]

   1

   カスタムピア Pod イメージ ID を指定します。

   2

   ピア Pod を作成するには、runtimeClassName フィールドが kata-remote に設定されていることを確認します。

   3

   コンテナー名を指定します。

5. Save をクリックして変更を適用します。

手順

1. 次のコマンドを実行して、SSH キーペアを生成します。

   $ ssh-keygen -f ./id_rsa -N ""

2. OpenShift Container Platform Web コンソールで、Workloads → Secrets に移動します。
3. Secrets ページで、openshift-sandboxed-containers-operator プロジェクトにいることを確認します。
4. Create をクリックし、Key/value secret を選択します。
5. Secret name フィールドに ssh-key-secret と入力します。
6. Key フィールドに id_rsa.pub と入力します。
7. Value フィールドに、公開 SSH 鍵を貼り付けます。
8. Create をクリックします。

9. 作成した SSH 鍵を削除します。

   $ shred --remove id_rsa.pub id_rsa

手順

1. カスタムポリシーを含む 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 の値を調整してポリシーをさらにカスタマイズします。

2. 次のコマンドを実行して、policy.rego ファイルを Base64 でエンコードされた文字列に変換します。

   $ base64 -w0 policy.rego

   次のステップで使用するために出力をコピーします。

3. Base64 でエンコードされたポリシーを my-pod.yaml Pod 仕様ファイルに追加します。

   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

4. 以下のコマンドを実行して Pod マニフェストを適用します。

   $ oc apply -f my-pod.yaml

手順

1. OpenShift Container Platform Web コンソールで、Operators → Installed Operators に移動します。
2. OpenShift sandboxed containers Operator を選択します。
3. KataConfig タブで、Create KataConfig をクリックします。

4. 以下の詳細を入力します。

   • Name: オプション: デフォルト名は example-kataconfig です。
   • Labels: オプション: 関連する識別属性を KataConfig リソースに入力します。各ラベルはキーと値のペアを表します。
   • enablePeerPods: パブリッククラウド、IBM Z®、および IBM® LinuxONE デプロイメントの場合に選択します。

   • kataConfigPoolSelector。オプション: 選択したノードに kata-remote をインストールするには、選択したノードのラベルに一致する式を追加します。

     1. kataConfigPoolSelector エリアを展開します。
     2. kataConfigPoolSelector エリアで、matchExpressions を展開します。これは、ラベルセレクターの要件のリストです。
     3. Add matchExpressions をクリックします。
     4. Key フィールドに、セレクターの適用先のラベルキーを入力します。
     5. Operator フィールドに、キーとラベル値の関係を入力します。有効な演算子は、In、NotIn、Exists、DoesNotExist です。
     6. Values エリアを展開し、Add value をクリックします。
     7. Value フィールドで、true または false を key ラベル値として入力します。
   • logLevel: ランタイムクラスが kata-remote のノードに対して取得されるログデータのレベルを定義します。

5. Create をクリックします。KataConfig CR が作成され、ワーカーノードに kata-remote ランタイムクラスをインストールします。

   インストールを確認する前に、kata-remote のインストールが完了し、ワーカーノードが再起動するまで待ちます。

検証

1. KataConfig タブで、KataConfig CR をクリックして詳細を表示します。

2. YAML タブをクリックして status スタンザを表示します。

   status スタンザには、conditions および kataNodes キーが含まれています。status.kataNodes の値はノード配列であり、各ノードには kata-remote インストールの特定の状態にあるノードがリストされます。更新があるたびにメッセージが表示されます。

3. Reload をクリックして、YAML を更新します。

   status.kataNodes 配列内のすべてのワーカーに、値 installed と、理由が指定されていない conditions.InProgress: False が表示される場合、kata-remote はクラスターにインストールされています。

手順

1. Workloads → ConfigMaps に移動します。
2. プロバイダー config map をクリックすると、詳細が表示されます。
3. YAML タブをクリックします。

4. YAML ファイルの status スタンザを確認します。

   AZURE_IMAGE_ID パラメーターが入力されている場合は、Pod 仮想マシンイメージが正常に作成されています。

トラブルシューティング

1. 次のコマンドを実行してイベントログを取得します。

   $ oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation

2. 次のコマンドを実行して、ジョブログを取得します。

   $ oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creation

手順

1. OpenShift Container Platform Web コンソールで、Workloads → workload type (例: Pods) に移動します。
2. ワークロードタイプページで、オブジェクトをクリックして詳細を表示します。
3. YAML タブをクリックします。

4. 次の例のように、各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに spec.runtimeClassName: kata-remote を追加します。

   apiVersion: v1
   kind: <object>
   # ...
   spec:
     runtimeClassName: kata-remote
   # ...

5. 手動で定義されたインスタンスサイズまたは自動インスタンスサイズを使用するには、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>
     # ...

     ワークロードが使用できるメモリーの量を定義します。ワークロードは、使用可能なメモリーの量に基づいて自動インスタンスサイズで実行されます。

6. Save をクリックして変更を適用します。

   OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。

手順

1. osc-namespace.yaml マニフェストファイルを作成します。

   apiVersion: v1
   kind: Namespace
   metadata:
     name: openshift-sandboxed-containers-operator

2. 以下のコマンドを実行して namespace を作成します。

   $ oc apply -f osc-namespace.yaml

3. osc-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

4. 以下のコマンドを実行して Operator グループを作成します。

   $ oc apply -f osc-operatorgroup.yaml

5. osc-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

6. 次のコマンドを実行して、サブスクリプションを作成します。

   $ oc apply -f osc-subscription.yaml

7. 次のコマンドを実行して、Operator が正常にインストールされていることを確認します。

   $ oc get csv -n openshift-sandboxed-containers-operator

   このコマンドが完了するまでに数分かかる場合があります。

8. 次のコマンドを実行してプロセスを監視します。

   $ 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

手順

1. 次のコマンドを実行して、Azure サブスクリプション ID を取得します。

   $ AZURE_SUBSCRIPTION_ID=$(az account list --query "[?isDefault].id" \
     -o tsv) && echo "AZURE_SUBSCRIPTION_ID: \"$AZURE_SUBSCRIPTION_ID\""

2. 次のコマンドを実行して 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`
   }

3. secret オブジェクトで使用する RBAC 出力を記録します。

4. 次の例に従って 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

   1

   AZURE_CLIENT_ID 値を指定します。

   2

   AZURE_CLIENT_SECRET 値を指定します。

   3

   AZURE_TENANT_ID 値を指定します。

   4

   AZURE_SUBSCRIPTION_ID 値を指定します。

5. 以下のコマンドを実行してシークレットを作成します。

   $ oc apply -f peer-pods-secret.yaml

手順

1. Azure インスタンスから以下の値を取得します。

   1. Azure リソースグループを取得して記録します。

      $ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}') && echo "AZURE_RESOURCE_GROUP: \"$AZURE_RESOURCE_GROUP\""

   2. Azure VNet 名を取得し、記録します。

      $ AZURE_VNET_NAME=$(az network vnet list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)

      この値は、Azure サブネット ID を取得するために使用されます。

   3. 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\""

   4. 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\""

   5. Azure リージョンを取得して記録します。

      $ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP} --query "{Location:location}" --output tsv) && echo "AZURE_REGION: \"$AZURE_REGION\""

2. 以下の例に従って 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 を使用して KataConfig CR を実行するときに入力されます。独自の Azure イメージを作成する場合は、正しいイメージ ID を指定します。

   6

   取得した AZURE_REGION 値を指定します。

   7

   取得した AZURE_RESOURCE_GROUP 値を指定します。

   8

   ノードごとに作成できるピア Pod の最大数を指定します。デフォルト値は 10 です。

   9

   Pod 仮想マシンインスタンスの key:value ペアとしてカスタムタグを設定して、ピア Pod のコストを追跡したり、異なるクラスター内のピア Pod を識別したりできます。

3. 以下のコマンドを実行して config map を作成します。

   $ oc apply -f peer-pods-cm.yaml

手順

1. 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-remote 2
     containers:
     - name: <example_container> 3
       image: registry.access.redhat.com/ubi9/ubi:9.3
       command: ["sleep", "36000"]

   1

   カスタムピア Pod イメージ ID を指定します。

   2

   ピア Pod を作成するには、runtimeClassName フィールドが kata-remote に設定されていることを確認します。

   3

   コンテナー名を指定します。

2. 以下のコマンドを実行して Pod を作成します。

   $ oc apply -f pod-manifest.yaml

手順

1. 次のコマンドを実行して、SSH キーペアを生成します。

   $ ssh-keygen -f ./id_rsa -N ""

2. 以下のコマンドを実行して 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

3. 作成した SSH 鍵を削除します。

   $ shred --remove id_rsa.pub id_rsa

手順

1. カスタムポリシーを含む 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 の値を調整してポリシーをさらにカスタマイズします。

2. 次のコマンドを実行して、policy.rego ファイルを Base64 でエンコードされた文字列に変換します。

   $ base64 -w0 policy.rego

   次のステップで使用するために出力をコピーします。

3. Base64 でエンコードされたポリシーを my-pod.yaml Pod 仕様ファイルに追加します。

   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

4. 以下のコマンドを実行して Pod マニフェストを適用します。

   $ oc apply -f my-pod.yaml

手順

1. 以下の例に従って 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')。

2. 次のコマンドを実行して、KataConfig CR を作成します。

   $ oc apply -f example-kataconfig.yaml

   新しい KataConfig CR が作成され、ワーカーノードに kata-remote がランタイムクラスとしてインストールされます。

   インストールを確認する前に、kata-remote のインストールが完了し、ワーカーノードが再起動するまで待ちます。

3. 次のコマンドを実行して、インストールの進行状況を監視します。

   $ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"

   kataNodes の下にあるすべてのワーカーのステータスが installed で、理由を指定せずに InProgress の条件が False の場合、kata-remote はクラスターにインストールされます。

4. 次のコマンドを実行してデーモンセットを確認します。

   $ oc get -n openshift-sandboxed-containers-operator ds/osc-caa-ds

5. 次のコマンドを実行してランタイムクラスを確認します。

   $ oc get runtimeclass

   出力例

   NAME             HANDLER          AGE
   kata             kata             152m
   kata-remote      kata-remote      152m

手順

1. ピア Pod 用に作成した config map を取得します。

   $ oc get configmap peer-pods-cm -n openshift-sandboxed-containers-operator -o yaml

2. YAML ファイルの status スタンザを確認します。

   AZURE_IMAGE_ID パラメーターが入力されている場合は、Pod 仮想マシンイメージが正常に作成されています。

トラブルシューティング

1. 次のコマンドを実行してイベントログを取得します。

   $ oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation

2. 次のコマンドを実行して、ジョブログを取得します。

   $ oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creation

手順

1. 次の例のように、各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに spec.runtimeClassName: kata-remote を追加します。

   apiVersion: v1
   kind: <object>
   # ...
   spec:
     runtimeClassName: kata-remote
   # ...

2. 手動で定義されたインスタンスサイズまたは自動インスタンスサイズを使用するには、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>
     # ...

     ワークロードが使用できるメモリーの量を定義します。ワークロードは、使用可能なメモリーの量に基づいて自動インスタンスサイズで実行されます。

3. 次のコマンドを実行して、変更をワークロードオブジェクトに適用します。

   $ oc apply -f <object.yaml>

   OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。

手順

1. Web コンソールで、Operators → OperatorHub に移動します。
2. Filter by keyword フィールドに OpenShift sandboxed containers と入力します。
3. OpenShift sandboxed containers Operator タイルを選択し、Install をクリックします。
4. Install Operator ページで、利用可能な Update Channel オプションの一覧から stable を選択します。

5. Installed Namespace で Operator recommended Namespace が選択されていることを確認します。これにより、Operator が必須の openshift-sandboxed-containers-operator namespace にインストールされます。この namespace がまだ存在しない場合は、自動的に作成されます。

   注記

   OpenShift Sandboxed Containers Operator を openshift-sandboxed-containers-operator 以外の namespace にインストールしようとすると、インストールに失敗します。

6. Approval Strategy で Automatic が選択されていることを確認します。Automatic がデフォルト値であり、新しい z-stream リリースが利用可能になると、OpenShift Sandboxed Containers への自動更新が有効になります。
7. Install をクリックします。
8. Operator → Installed Operator に移動して、Operator がインストールされていることを確認します。

手順

1. 次のコマンドを実行して、プロジェクト ID 変数を設定します。

   $ export GCP_PROJECT_ID="<project_id>"

2. 次のコマンドを実行して Google Cloud にログインします。

   $ gcloud auth login

3. 次のコマンドを実行して、Google Cloud プロジェクト ID を設定します。

   $ gcloud config set project ${GCP_PROJECT_ID}

4. 次のコマンドを実行してポート 15150 を開きます。

   $ gcloud compute firewall-rules create allow-port-15150-restricted \
      --project=${GCP_PROJECT_ID} \
      --network=default \
      --allow=tcp:15150 \
      --source-ranges=<external_ip_cidr-1>[,<external_ip_cidr-2>,...] 1

   1

   1 つ以上の IP アドレスまたは範囲を CIDR 形式でコンマで区切って指定します。たとえば、203.0.113.5/32,198.51.100.0/24 です。

手順

1. Google Cloud コンソールで IAM & Admin → Service Accounts → Keys に移動し、キーを JSON ファイルとして保存します。

2. 次のコマンドを実行して、JSON ファイルを 1 行の文字列に変換します。

   $ cat <key_file>.json | jq -c .

3. OpenShift Container Platform Web コンソールで、Operators → Installed Operators に移動します。
4. OpenShift sandboxed containers Operator タイルをクリックします。
5. 右上隅のインポートアイコン (+) をクリックします。

6. Import YAML ウィンドウに、次の YAML マニフェストを貼り付けます。

   apiVersion: v1
   kind: Secret
   metadata:
     name: peer-pods-secret
     namespace: openshift-sandboxed-containers-operator
   type: Opaque
   stringData:
     GCP_CREDENTIALS: "<gc_service_account_key_json>" 1

   1

   <gc_service_account_key_json> は、Google Cloud サービスアカウントキーの JSON ファイルから作成した 1 行の文字列に置き換えます。

7. Save をクリックして変更を適用します。
8. Workloads → Secrets に移動して、ピア Pod シークレットを確認します。

手順

1. Compute Engine インスタンスにログインして、次の環境変数を設定します。

   1. 次のコマンドを実行してプロジェクト ID を取得します。

      $ GCP_PROJECT_ID=$(gcloud config get-value project)

   2. 次のコマンドを実行してゾーンを取得します。

      $ GCP_ZONE=$(gcloud config get-value compute/zone)

   3. 次のコマンドを実行して、ネットワーク名のリストを取得します。

      $ gcloud compute networks list --format="value(name)"

   4. 次のコマンドを実行してネットワークを指定します。

      $ GCP_NETWORK=<network_name> 1

      1

      <network_name> は、ネットワークの名前に置き換えます。

2. OpenShift Container Platform Web コンソールで、Operators → Installed Operators に移動します。
3. Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
4. 右上隅にあるインポートアイコン (+) をクリックします。

5. Import YAML ウィンドウに、次の YAML マニフェストを貼り付けます。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: peer-pods-cm
     namespace: openshift-sandboxed-containers-operator
   data:
     CLOUD_PROVIDER: "gcp"
     PROXY_TIMEOUT: "5m"
     GCP_PROJECT_ID: "<gcp_project_id>" 1
     GCP_ZONE: "<gcp_zone>" 2
     GCP_MACHINE_TYPE: "e2-medium" 3
     GCP_NETWORK: "<gcp_network>" 4
     PEERPODS_LIMIT_PER_NODE: "10" 5
     TAGS: "key1=value1,key2=value2" 6
     DISABLECVM: "true"

   1

   使用するプロジェクト ID を指定します。

   2

   取得した GCP_ZONE 値を指定します。このゾーンはワークロードを実行します。

   3

   ワークロードの要件に一致するマシンタイプを指定します。

   4

   取得した GCP_NETWORK 値を指定します。

   5

   ノードごとに作成できるピア Pod の最大数を指定します。デフォルト値は 10 です。

   6

   Pod 仮想マシンインスタンスの key:value ペアとしてカスタムタグを設定して、ピア Pod のコストを追跡したり、異なるクラスター内のピア Pod を識別したりできます。

6. Save をクリックして変更を適用します。
7. 新しい config map を表示するには、Workloads → ConfigMaps に移動します。

手順

1. 次のコマンドを実行して、OpenShift Sandboxed Containers リポジトリーのクローンを作成します。

   $ git clone https://github.com/openshift/sandboxed-containers-operator.git

2. 次のコマンドを実行して、sandboxed-containers-operator/config/peerpods/podvm/bootc に移動します。

   $ cd sandboxed-containers-operator/config/peerpods/podvm/bootc

3. 次のコマンドを実行して、registry.redhat.io にログインします。

   $ podman login registry.redhat.io

   podman build プロセスはレジストリーでホストされる Containerfile.rhel コンテナーイメージにアクセスする必要があるため、registry.redhat.io にログインする必要があります。

4. 次のコマンドを実行して、コンテナーレジストリーのイメージパスを設定します。

   $ IMG="<container_registry_url>/<username>/podvm-bootc:latest"

5. 次のコマンドを実行して、Pod 仮想マシン bootc イメージをビルドします。

   $ podman build -t ${IMG} -f Containerfile.rhel .

6. 次のコマンドを実行して、コンテナーレジストリーにログインします。

   $ podman login <container_registry_url>

7. 次のコマンドを実行して、イメージをコンテナーレジストリーにプッシュします。

   $ podman push ${IMG}

   テストや開発のために、イメージを公開できます。

8. 次のコマンドを実行して、podvm-bootc イメージを確認します。

   $ podman images

   出力例

   REPOSITORY                               TAG     IMAGE ID      CREATED         SIZE
   example.com/example_user/podvm-bootc     latest  88ddab975a07  2 seconds ago   1.82 GB

手順

1. OpenShift Container Platform Web コンソールで、Operators → Installed Operators に移動します。
2. Operator のリストから OpenShift Sandboxed Containers Operator を選択します。
3. 右上隅にあるインポートアイコン (+) をクリックします。

4. Import YAML ウィンドウに、次の YAML マニフェストを貼り付けます。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: gc-podvm-image-cm
     namespace: openshift-sandboxed-containers-operator
   data:
     IMAGE_TYPE: pre-built
     PODVM_IMAGE_URI: <container_registry_url>/<username>/podvm-bootc:latest
     IMAGE_BASE_NAME: "podvm-image"
     IMAGE_VERSION: "0-0-0"
   
     INSTALL_PACKAGES: "no"
     DISABLE_CLOUD_CONFIG: "true"
     UPDATE_PEERPODS_CM: "yes"
     BOOT_FIPS: "no"
   
     BOOTC_BUILD_CONFIG: |
       [[customizations.user]]
       name = "peerpod"
       password = "peerpod"
       groups = ["wheel", "root"]
   
       [[customizations.filesystem]]
       mountpoint = "/"
       minsize = "5 GiB"
   
       [[customizations.filesystem]]
       mountpoint = "/var/kata-containers"
       minsize = "15 GiB"

5. Save をクリックして変更を適用します。
6. 新しい config map を表示するには、Workloads → ConfigMaps に移動します。

手順

1. カスタムポリシーを含む 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 の値を調整してポリシーをさらにカスタマイズします。

2. 次のコマンドを実行して、policy.rego ファイルを Base64 でエンコードされた文字列に変換します。

   $ base64 -w0 policy.rego

   次のステップで使用するために出力をコピーします。

3. Base64 でエンコードされたポリシーを my-pod.yaml Pod 仕様ファイルに追加します。

   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

4. 以下のコマンドを実行して Pod マニフェストを適用します。

   $ oc apply -f my-pod.yaml

手順

1. OpenShift Container Platform Web コンソールで、Operators → Installed Operators に移動します。
2. OpenShift sandboxed containers Operator を選択します。
3. KataConfig タブで、Create KataConfig をクリックします。

4. 以下の詳細を入力します。

   • Name: オプション: デフォルト名は example-kataconfig です。
   • Labels: オプション: 関連する識別属性を KataConfig リソースに入力します。各ラベルはキーと値のペアを表します。
   • enablePeerPods: パブリッククラウド、IBM Z®、および IBM® LinuxONE デプロイメントの場合に選択します。

   • kataConfigPoolSelector。オプション: 選択したノードに kata-remote をインストールするには、選択したノードのラベルに一致する式を追加します。

     1. kataConfigPoolSelector エリアを展開します。
     2. kataConfigPoolSelector エリアで、matchExpressions を展開します。これは、ラベルセレクターの要件のリストです。
     3. Add matchExpressions をクリックします。
     4. Key フィールドに、セレクターの適用先のラベルキーを入力します。
     5. Operator フィールドに、キーとラベル値の関係を入力します。有効な演算子は、In、NotIn、Exists、DoesNotExist です。
     6. Values エリアを展開し、Add value をクリックします。
     7. Value フィールドで、true または false を key ラベル値として入力します。
   • logLevel: ランタイムクラスが kata-remote のノードに対して取得されるログデータのレベルを定義します。

5. Create をクリックします。KataConfig CR が作成され、ワーカーノードに kata-remote ランタイムクラスをインストールします。

   インストールを確認する前に、kata-remote のインストールが完了し、ワーカーノードが再起動するまで待ちます。

検証

1. KataConfig タブで、KataConfig CR をクリックして詳細を表示します。

2. YAML タブをクリックして status スタンザを表示します。

   status スタンザには、conditions および kataNodes キーが含まれています。status.kataNodes の値はノード配列であり、各ノードには kata-remote インストールの特定の状態にあるノードがリストされます。更新があるたびにメッセージが表示されます。

3. Reload をクリックして、YAML を更新します。

   status.kataNodes 配列内のすべてのワーカーに、値 installed と、理由が指定されていない conditions.InProgress: False が表示される場合、kata-remote はクラスターにインストールされています。

手順

1. Workloads → ConfigMaps に移動します。
2. プロバイダー config map をクリックすると、詳細が表示されます。
3. YAML タブをクリックします。

4. YAML ファイルの status スタンザを確認します。

   PODVM_IMAGE_NAME パラメーターが入力されている場合は、Pod 仮想マシンイメージが正常に作成されています。

トラブルシューティング

1. 次のコマンドを実行してイベントログを取得します。

   $ oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation

2. 次のコマンドを実行して、ジョブログを取得します。

   $ oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creation

手順

1. 次の例のように、各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに spec.runtimeClassName: kata-remote を追加します。

   apiVersion: v1
   kind: <object>
   # ...
   spec:
     runtimeClassName: kata-remote
   # ...

   OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。

手順

1. osc-namespace.yaml マニフェストファイルを作成します。

   apiVersion: v1
   kind: Namespace
   metadata:
     name: openshift-sandboxed-containers-operator

2. 以下のコマンドを実行して namespace を作成します。

   $ oc apply -f osc-namespace.yaml

3. osc-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

4. 以下のコマンドを実行して Operator グループを作成します。

   $ oc apply -f osc-operatorgroup.yaml

5. osc-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

6. 次のコマンドを実行して、サブスクリプションを作成します。

   $ oc apply -f osc-subscription.yaml

7. 次のコマンドを実行して、Operator が正常にインストールされていることを確認します。

   $ oc get csv -n openshift-sandboxed-containers-operator

   このコマンドが完了するまでに数分かかる場合があります。

8. 次のコマンドを実行してプロセスを監視します。

   $ 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

手順

1. 次のコマンドを実行して、プロジェクト ID 変数を設定します。

   $ export GCP_PROJECT_ID="<project_id>"

2. 次のコマンドを実行して Google Cloud にログインします。

   $ gcloud auth login

3. 次のコマンドを実行して、Google Cloud プロジェクト ID を設定します。

   $ gcloud config set project ${GCP_PROJECT_ID}

4. 次のコマンドを実行してポート 15150 を開きます。

   $ gcloud compute firewall-rules create allow-port-15150-restricted \
      --project=${GCP_PROJECT_ID} \
      --network=default \
      --allow=tcp:15150 \
      --source-ranges=<external_ip_cidr-1>[,<external_ip_cidr-2>,...] 1

   1

   1 つ以上の IP アドレスまたは範囲を CIDR 形式でコンマで区切って指定します。たとえば、203.0.113.5/32,198.51.100.0/24 です。

手順

1. 次のコマンドを実行して、Google Cloud サービスアカウントキーを作成し、JSON ファイルとして保存します。

   $ gcloud iam service-accounts keys create <key_filename>.json \
     --iam-account=<service_account_email_address>

2. 次のコマンドを実行して、JSON ファイルを 1 行の文字列に変換します。

   $ cat <key_file>.json | jq -c .

3. 次の例に従って peer-pods-secret.yaml マニフェストファイルを作成します。

   apiVersion: v1
   kind: Secret
   metadata:
     name: peer-pods-secret
     namespace: openshift-sandboxed-containers-operator
   type: Opaque
   stringData:
     GCP_CREDENTIALS: "<gc_service_account_key_json>" 1

   1

   <gc_service_account_key_json> は、Google Cloud サービスアカウントキーの JSON ファイルから作成した 1 行の文字列に置き換えます。

4. 以下のコマンドを実行してシークレットを作成します。

   $ oc apply -f peer-pods-secret.yaml

手順

1. Compute Engine インスタンスにログインして、次の環境変数を設定します。

   1. 次のコマンドを実行してプロジェクト ID を取得します。

      $ GCP_PROJECT_ID=$(gcloud config get-value project)

   2. 次のコマンドを実行してゾーンを取得します。

      $ GCP_ZONE=$(gcloud config get-value compute/zone)

   3. 次のコマンドを実行して、ネットワーク名のリストを取得します。

      $ gcloud compute networks list --format="value(name)"

   4. 次のコマンドを実行してネットワークを指定します。

      $ GCP_NETWORK=<network_name> 1

      1

      <network_name> は、ネットワークの名前に置き換えます。

2. 以下の例に従って peer-pods-cm.yaml マニフェストファイルを作成します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: peer-pods-cm
     namespace: openshift-sandboxed-containers-operator
   data:
     CLOUD_PROVIDER: "gcp"
     PROXY_TIMEOUT: "5m"
     GCP_PROJECT_ID: "<gcp_project_id>" 1
     GCP_ZONE: "<gcp_zone>" 2
     GCP_MACHINE_TYPE: "e2-medium" 3
     GCP_NETWORK: "<gcp_network>" 4
     PEERPODS_LIMIT_PER_NODE: "10" 5
     TAGS: "key1=value1,key2=value2" 6
     DISABLECVM: "true"

   1

   使用するプロジェクト ID を指定します。

   2

   取得した GCP_ZONE 値を指定します。このゾーンはワークロードを実行します。

   3

   ワークロードの要件に一致するマシンタイプを指定します。

   4

   取得した GCP_NETWORK 値を指定します。

   5

   ノードごとに作成できるピア Pod の最大数を指定します。デフォルト値は 10 です。

   6

   Pod 仮想マシンインスタンスの key:value ペアとしてカスタムタグを設定して、ピア Pod のコストを追跡したり、異なるクラスター内のピア Pod を識別したりできます。

3. 以下のコマンドを実行して config map を作成します。

   $ oc apply -f peer-pods-cm.yaml

手順

1. 次のコマンドを実行して、OpenShift Sandboxed Containers リポジトリーのクローンを作成します。

   $ git clone https://github.com/openshift/sandboxed-containers-operator.git

2. 次のコマンドを実行して、sandboxed-containers-operator/config/peerpods/podvm/bootc に移動します。

   $ cd sandboxed-containers-operator/config/peerpods/podvm/bootc

3. 次のコマンドを実行して、registry.redhat.io にログインします。

   $ podman login registry.redhat.io

   podman build プロセスはレジストリーでホストされる Containerfile.rhel コンテナーイメージにアクセスする必要があるため、registry.redhat.io にログインする必要があります。

4. 次のコマンドを実行して、コンテナーレジストリーのイメージパスを設定します。

   $ IMG="<container_registry_url>/<username>/podvm-bootc:latest"

5. 次のコマンドを実行して、Pod 仮想マシン bootc イメージをビルドします。

   $ podman build -t ${IMG} -f Containerfile.rhel .

6. 次のコマンドを実行して、コンテナーレジストリーにログインします。

   $ podman login <container_registry_url>

7. 次のコマンドを実行して、イメージをコンテナーレジストリーにプッシュします。

   $ podman push ${IMG}

   テストや開発のために、イメージを公開できます。

8. 次のコマンドを実行して、podvm-bootc イメージを確認します。

   $ podman images

   出力例

   REPOSITORY                               TAG     IMAGE ID      CREATED         SIZE
   example.com/example_user/podvm-bootc     latest  88ddab975a07  2 seconds ago   1.82 GB

手順

1. 次の内容を含む、gc-podvm-image-cm.yaml という名前の Pod 仮想マシンイメージの config map マニフェストを作成します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: gc-podvm-image-cm
     namespace: openshift-sandboxed-containers-operator
   data:
     IMAGE_TYPE: pre-built
     PODVM_IMAGE_URI: <container_registry_url>/<username>/podvm-bootc:latest
     IMAGE_BASE_NAME: "podvm-image"
     IMAGE_VERSION: "0-0-0"
   
     INSTALL_PACKAGES: "no"
     DISABLE_CLOUD_CONFIG: "true"
     UPDATE_PEERPODS_CM: "yes"
     BOOT_FIPS: "no"
   
     BOOTC_BUILD_CONFIG: |
       [[customizations.user]]
       name = "peerpod"
       password = "peerpod"
       groups = ["wheel", "root"]
   
       [[customizations.filesystem]]
       mountpoint = "/"
       minsize = "5 GiB"
   
       [[customizations.filesystem]]
       mountpoint = "/var/kata-containers"
       minsize = "15 GiB"

2. 以下のコマンドを実行して config map を作成します。

   $ oc apply -f gc-podvm-image-cm.yaml

手順

1. カスタムポリシーを含む 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 の値を調整してポリシーをさらにカスタマイズします。

2. 次のコマンドを実行して、policy.rego ファイルを Base64 でエンコードされた文字列に変換します。

   $ base64 -w0 policy.rego

   次のステップで使用するために出力をコピーします。

3. Base64 でエンコードされたポリシーを my-pod.yaml Pod 仕様ファイルに追加します。

   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

4. 以下のコマンドを実行して Pod マニフェストを適用します。

   $ oc apply -f my-pod.yaml

手順

1. 以下の例に従って 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')。

2. 次のコマンドを実行して、KataConfig CR を作成します。

   $ oc apply -f example-kataconfig.yaml

   新しい KataConfig CR が作成され、ワーカーノードに kata-remote がランタイムクラスとしてインストールされます。

   インストールを確認する前に、kata-remote のインストールが完了し、ワーカーノードが再起動するまで待ちます。

3. 次のコマンドを実行して、インストールの進行状況を監視します。

   $ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"

   kataNodes の下にあるすべてのワーカーのステータスが installed で、理由を指定せずに InProgress の条件が False の場合、kata-remote はクラスターにインストールされます。

4. 次のコマンドを実行してデーモンセットを確認します。

   $ oc get -n openshift-sandboxed-containers-operator ds/osc-caa-ds

5. 次のコマンドを実行してランタイムクラスを確認します。

   $ oc get runtimeclass

   出力例

   NAME             HANDLER          AGE
   kata             kata             152m
   kata-remote      kata-remote      152m

手順

1. ピア Pod 用に作成した config map を取得します。

   $ oc get configmap peer-pods-cm -n openshift-sandboxed-containers-operator -o yaml

2. YAML ファイルの status スタンザを確認します。

   PODVM_IMAGE_NAME パラメーターが入力されている場合は、Pod 仮想マシンイメージが正常に作成されています。

トラブルシューティング

1. 次のコマンドを実行してイベントログを取得します。

   $ oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation

2. 次のコマンドを実行して、ジョブログを取得します。

   $ oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creation

手順

1. 次の例のように、各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに spec.runtimeClassName: kata-remote を追加します。

   apiVersion: v1
   kind: <object>
   # ...
   spec:
     runtimeClassName: kata-remote
   # ...

   OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。

手順

1. osc-namespace.yaml マニフェストファイルを作成します。

   apiVersion: v1
   kind: Namespace
   metadata:
     name: openshift-sandboxed-containers-operator

2. 以下のコマンドを実行して namespace を作成します。

   $ oc apply -f osc-namespace.yaml

3. osc-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

4. 以下のコマンドを実行して Operator グループを作成します。

   $ oc apply -f osc-operatorgroup.yaml

5. osc-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

6. 次のコマンドを実行して、サブスクリプションを作成します。

   $ oc apply -f osc-subscription.yaml

7. 次のコマンドを実行して、Operator が正常にインストールされていることを確認します。

   $ oc get csv -n openshift-sandboxed-containers-operator

   このコマンドが完了するまでに数分かかる場合があります。

8. 次のコマンドを実行してプロセスを監視します。

   $ 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

手順

1. KVM ホストにログインします。

2. 次のコマンドを実行して、libvirt プールの名前を設定します。

   $ export LIBVIRT_POOL=<libvirt_pool>

   libvirt プロバイダーのシークレットを作成するには、LIBVIRT_POOL 値が必要です。

3. 次のコマンドを実行して、libvirt ボリュームの名前を設定します。

   $ export LIBVIRT_VOL_NAME=<libvirt_volume>

   libvirt プロバイダーのシークレットを作成するには、LIBVIRT_VOL_NAME 値が必要です。

4. 次のコマンドを実行して、デフォルトのストレージプールの場所のパスを設定します。

   $ export LIBVIRT_POOL_DIRECTORY="/var/lib/libvirt/images/"

5. 次のコマンドを実行して、libvirt プールを作成します。

   $ virsh pool-define-as $LIBVIRT_POOL --type dir --target "$LIBVIRT_POOL_DIRECTORY"

6. 次のコマンドを実行して、libvirt プールを開始します。

   $ virsh pool-start $LIBVIRT_POOL

7. 次のコマンドを実行して、プールの libvirt ボリュームを作成します。

   $ virsh -c qemu:///system \
     vol-create-as --pool $LIBVIRT_POOL \
     --name $LIBVIRT_VOL_NAME \
     --capacity 20G \
     --allocation 2G \
     --prealloc-metadata \
     --format qcow2

手順

1. Dockerfile.podvm-oci ファイルを作成します。

   FROM scratch
   
   ARG PODVM_IMAGE_SRC
   ENV PODVM_IMAGE_PATH="/image/podvm.qcow2"
   
   COPY $PODVM_IMAGE_SRC $PODVM_IMAGE_PATH

2. 次のコマンドを実行して、Pod 仮想マシン QCOW2 イメージを含むコンテナーを構築します。

   $ docker build -t podvm-libvirt \
     --build-arg PODVM_IMAGE_SRC=<podvm_image_source> \ 1
     --build-arg PODVM_IMAGE_PATH=<podvm_image_path> \ 2
     -f Dockerfile.podvm-oci .

   1

   ホスト上の QCOW2 イメージソースを指定します。

   2

   オプション: デフォルトの /image/podvm.qcow2 を使用しない場合は、QCOW2 イメージのパスを指定します。

手順

1. 次の例に従って peer-pods-secret.yaml マニフェストファイルを作成します。

   apiVersion: v1
   kind: Secret
   metadata:
     name: peer-pods-secret
     namespace: openshift-sandboxed-containers-operator
   type: Opaque
   stringData:
     CLOUD_PROVIDER: "libvirt"
     LIBVIRT_URI: "<libvirt_gateway_uri>" 1
     REDHAT_OFFLINE_TOKEN: "<rh_offline_token>" 2

   1

   libvirt URI を指定します。

   2

   Operator ビルドイメージに必要な Red Hat オフライントークンを指定します。

2. 以下のコマンドを実行してシークレットを作成します。

   $ oc apply -f peer-pods-secret.yaml

手順

1. 以下の例に従って peer-pods-cm.yaml マニフェストファイルを作成します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: peer-pods-cm
     namespace: openshift-sandboxed-containers-operator
   data:
     CLOUD_PROVIDER: "libvirt"
     PEERPODS_LIMIT_PER_NODE: "10" 1
     LIBVIRT_POOL: "<libvirt_pool>" 2
     LIBVIRT_VOL_NAME: "<libvirt_volume>" 3
     LIBVIRT_DIR_NAME: "/var/lib/libvirt/images/<directory_name>" 4
     LIBVIRT_NET: "default" 5
     DISABLECVM: "true"

   1

   ノードごとに作成できるピア Pod の最大数を指定します。デフォルト値は 10 です。

   2

   libvirt プールを指定します。libvirt プールを手動で設定した場合は、KVM ホスト設定と同じ名前を使用します。

   3

   libvirt ボリューム名を指定します。libvirt ボリュームを手動で設定した場合は、KVM ホスト設定と同じ名前を使用します。

   4

   .qcow2 や .raw ファイルなどの仮想マシンのディスクイメージを保存するための libvirt ディレクトリーを指定します。libvirt に読み取りおよび書き込みアクセス権限があることを確認するには、libvirt ストレージディレクトリーのサブディレクトリーを使用します。デフォルトは /var/lib/libvirt/images/ です。

   5

   オプション: デフォルトのネットワークを使用しない場合は、libvirt ネットワークを指定します。

2. 以下のコマンドを実行して config map を作成します。

   $ oc apply -f peer-pods-cm.yaml

手順

1. 次の例に従って、libvirt-podvm-image-cm.yaml マニフェストを作成します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: libvirt-podvm-image-cm
     namespace: openshift-sandboxed-containers-operator
   data:
     PODVM_DISTRO: "rhel"
     DOWNLOAD_SOURCES: "no" 1
     CAA_SRC: "https://github.com/confidential-containers/cloud-api-adaptor" 2
     CAA_REF: "main" 3
     CONFIDENTIAL_COMPUTE_ENABLED: "yes"
     UPDATE_PEERPODS_CM: "yes"
     ORG_ID: "<rhel_organization_id>"
     ACTIVATION_KEY: "<rhel_activation_key>" 4
     IMAGE_NAME: "<podvm_libvirt_image>" 5
     PODVM_IMAGE_URI: "oci::<image_repo_url>:<image_tag>::<image_path>" 6
     SE_BOOT: "true" 7
     BASE_OS_VERSION: "<rhel_image_os_version>" 8

   1

   カスタム Cloud API アダプターソースを使用して Pod 仮想マシンイメージを構築する場合は、yes を指定します。

   2

   オプション: Cloud API アダプターのカスタムイメージの URL を指定します。

   3

   オプション: Cloud API アダプターのカスタムイメージのブランチまたはタグを指定します。

   4

   RHEL アクティベーションキーを指定します。

   5

   カスタムピア Pod 仮想マシンイメージ名を指定します。

   6

   オプション: カスタムピア Pod 仮想マシンイメージを作成した場合は、コンテナーレジストリー URL、イメージタグ、およびイメージパス (デフォルト: /image/podvm.qcow2) を指定します。それ以外の場合は、値を "" に設定します。

   7

   デフォルト値 true は、デフォルトの Operator ビルドイメージに対して IBM Secure Execution を有効にします。カスタムピア Pod 仮想マシンイメージを使用する場合は、false に設定します。

   8

   RHEL イメージのオペレーティングシステムのバージョンを指定します。IBM Z® Secure Execution は RHEL 9.5 以降のバージョンをサポートします。

2. 以下のコマンドを実行して config map を作成します。

   $ oc apply -f libvirt-podvm-image-cm.yaml

   libvirt プロバイダー用に libvirt Pod 仮想マシンイメージ config map が作成されます。

手順

1. 次のコマンドを実行して、SSH キーペアを生成します。

   $ ssh-keygen -f ./id_rsa -N ""

2. SSH 公開鍵を KVM ホストにコピーします。

   $ ssh-copy-id -i ./id_rsa.pub <KVM_HOST_IP> 1

   1

   ピア Pod 仮想マシンが実行されている KVM ホストまたは LPAR の IP アドレスを指定します。たとえば、192.168.122.1 です。

3. 以下のコマンドを実行して 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

4. 作成した SSH 鍵を削除します。

   $ shred --remove id_rsa.pub id_rsa

手順

1. 次のコマンドを実行して、libvirt プールの名前を設定します。

   $ export LIBVIRT_POOL=<libvirt_pool> 1

   1

   既存の libvirt プール名を指定します。

2. 次のコマンドを実行して、新しい libvirt ボリュームの名前を設定します。

   $ export LIBVIRT_VOL_NAME=<new_libvirt_volume>

3. 次のコマンドを実行して、プールの libvirt ボリュームを作成します。

   $ virsh -c qemu:///system \
     vol-create-as --pool $LIBVIRT_POOL \
     --name $LIBVIRT_VOL_NAME \
     --capacity 20G \
     --allocation 2G \
     --prealloc-metadata \
     --format qcow2

4. カスタムピア Pod 仮想マシンイメージを libvirt ボリュームにアップロードします。

   $ virsh -c qemu:///system vol-upload \
     --vol $LIBVIRT_VOL_NAME <custom_podvm_image.qcow2> \ 1
     --pool $LIBVIRT_POOL --sparse

   1

   カスタムピア Pod 仮想マシンイメージ名を指定します。

5. 次の例に従って、pod-manifest.yaml マニフェストファイルを作成します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-manifest
     annotations:
       io.katacontainers.config.hypervisor.image: "<new_libvirt_volume>" 1
   spec:
     runtimeClassName: kata-remote 2
     containers:
     - name: <example_container> 3
       image: registry.access.redhat.com/ubi9/ubi:9.3
       command: ["sleep", "36000"]

   1

   カスタムピア Pod 仮想マシンイメージをアップロードした libvirt ボリューム名を指定します。

   2

   ピア Pod を作成するには、runtimeClassName フィールドが kata-remote に設定されていることを確認します。

   3

   コンテナー名を指定します。

6. 以下のコマンドを実行して Pod を作成します。

   $ oc apply -f pod-manifest.yaml

手順

1. カスタムポリシーを含む 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 の値を調整してポリシーをさらにカスタマイズします。

2. 次のコマンドを実行して、policy.rego ファイルを Base64 でエンコードされた文字列に変換します。

   $ base64 -w0 policy.rego

   次のステップで使用するために出力をコピーします。

3. Base64 でエンコードされたポリシーを my-pod.yaml Pod 仕様ファイルに追加します。

   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

4. 以下のコマンドを実行して Pod マニフェストを適用します。

   $ oc apply -f my-pod.yaml

手順

1. 以下の例に従って 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')。

2. 次のコマンドを実行して、KataConfig CR を作成します。

   $ oc apply -f example-kataconfig.yaml

   新しい KataConfig CR が作成され、ワーカーノードに kata-remote がランタイムクラスとしてインストールされます。

   インストールを確認する前に、kata-remote のインストールが完了し、ワーカーノードが再起動するまで待ちます。

3. 次のコマンドを実行して、インストールの進行状況を監視します。

   $ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"

   kataNodes の下にあるすべてのワーカーのステータスが installed で、理由を指定せずに InProgress の条件が False の場合、kata-remote はクラスターにインストールされます。

4. 次のコマンドを実行して、ピア Pod イメージが構築され、libvirt ボリュームにアップロードされたことを確認します。

   $ oc describe configmap peer-pods-cm -n openshift-sandboxed-containers-operator

   出力例

   Name: peer-pods-cm
   Namespace: openshift-sandboxed-containers-operator
   Labels: <none>
   Annotations: <none>
   
   Data
   ====
   CLOUD_PROVIDER: libvirt
   
   BinaryData
   ====
   Events: <none>

5. 次のコマンドを実行して、kata-oc マシン設定プールの進行状況を監視し、UPDATEDMACHINECOUNT が MACHINECOUNT と等しいときに UPDATED 状態であることを確認します。

   $ watch oc get mcp/kata-oc

6. 次のコマンドを実行してデーモンセットを確認します。

   $ oc get -n openshift-sandboxed-containers-operator ds/osc-caa-ds

7. 次のコマンドを実行してランタイムクラスを確認します。

   $ oc get runtimeclass

   出力例

   NAME             HANDLER          AGE
   kata             kata             152m
   kata-remote      kata-remote      152m

手順

1. 次の例のように、各 Pod テンプレート化されたワークロードオブジェクトのマニフェストに spec.runtimeClassName: kata-remote を追加します。

   apiVersion: v1
   kind: <object>
   # ...
   spec:
     runtimeClassName: kata-remote
   # ...

   OpenShift Container Platform はワークロードオブジェクトを作成し、スケジュールを開始します。

手順

1. rvps-configmap.yaml マニフェストファイルを作成します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: rvps-reference-values
     namespace: trustee-operator-system
   data:
     reference-values.json: |
       [ 1
       ]

   1

   必要に応じて、お使いのハードウェアプラットフォームの信頼できるダイジェストを指定します。それ以外の場合は、空のままにします。

2. 次のコマンドを実行して、RVPS config map を作成します。

   $ oc apply -f rvps-configmap.yaml

手順

1. 次の例に従って、attestation-policy.yaml マニフェストファイルを作成します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: attestation-policy
     namespace: trustee-operator-system
   data:
     default.rego: |
       package policy 1
       import future.keywords.every
   
       default allow = false
   
       allow {
         every k, v in input {
             judge_field(k, v)
         }
       }
   
       judge_field(input_key, input_value) {
         has_key(data.reference, input_key)
         reference_value := data.reference[input_key]
         match_value(reference_value, input_value)
       }
   
       judge_field(input_key, input_value) {
         not has_key(data.reference, input_key)
       }
   
       match_value(reference_value, input_value) {
         not is_array(reference_value)
         input_value == reference_value
       }
   
       match_value(reference_value, input_value) {
         is_array(reference_value)
         array_include(reference_value, input_value)
       }
   
       array_include(reference_value_array, input_value) {
         reference_value_array == []
       }
   
       array_include(reference_value_array, input_value) {
         reference_value_array != []
         some i
         reference_value_array[i] == input_value
       }
   
       has_key(m, k) {
         _ = m[k]
       }

   1

   アテステーションポリシーは、Open Policy Agent 仕様に準拠します。この例では、アテステーションポリシーは、アテステーションレポートで提供されたクレームを RVPS データベースに登録されている参照値と比較します。すべての値が一致する場合にのみ、アテステーションプロセスは成功します。

2. 以下のコマンドを実行して、アテステーションポリシー config map を作成します。

   $ oc apply -f attestation-policy.yaml

手順

1. 次の例に従って、tdx-config.yaml マニフェストファイルを作成します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: tdx-config
     namespace: trustee-operator-system
   data:
     sgx_default_qcnl.conf: | \
         {
           "collateral_service": "https://api.trustedservices.intel.com/sgx/certification/v4/",
           "pccs_url": "<pccs_url>" 1
         }

   1

   PCCS URL を指定します (例: https://localhost:8081/sgx/certification/v4/)。

2. 以下のコマンドを実行して TDX config map を作成します。

   $ oc apply -f tdx-config.yaml

手順

1. 次のコマンドを実行して、コンテナーイメージの署名検証用のシークレットを作成します。

   $ oc apply secret generic <type> \ 1
     --from-file=<tag>=./<public_key_file> \ 2
     -n trustee-operator-system

   1

   KBS シークレットタイプ (例: img-sig) を指定します。

   2

   シークレットタグ (例: pub-key) とパブリックコンテナーイメージ署名鍵を指定します。

2. <type> の値を記録します。KbsConfig カスタムリソースを作成するときに、この値を spec.kbsSecretResources キーに追加する必要があります。

手順

1. 次の例に従って、security-policy-config.json ファイルを作成します。

   • 署名検証なし:

     {
       "default": [
       {
         "type": "insecureAcceptAnything"
       }],
       "transports": {}
     }

   • 署名検証あり:

     {
       "default": [
           {
           "type": "insecureAcceptAnything"
           }
       ],
       "transports": {
           "<transport>": { 1
               "<registry>/<image>": 2
               [
                   {
                       "type": "sigstoreSigned",
                       "keyPath": "kbs:///default/<type>/<tag>" 3
                   }
               ]
           }
       }
     }

     1

     transport のイメージリポジトリーを指定します (例: "docker")。詳細は、containers-transports 5 を参照してください。

     2

     コンテナーレジストリーとイメージを指定します (例: "quay.io/my-image")。

     3

     作成したコンテナーイメージ署名検証シークレットのタイプとタグを指定します (例: img-sig/pub-key)。

2. 次のコマンドを実行してセキュリティーポリシーを作成します。

   $ oc apply secret generic security-policy \
     --from-file=osc=./<security-policy-config.json> \
     -n trustee-operator-system

   シークレットタイプ security-policy または osc のキーを変更しないでください。

   security-policy シークレットは、KbsConfig カスタムリソースの spec.kbsSecretResources キーで指定されます。

手順

1. resourcepolicy-configmap.yaml マニフェストファイルを作成します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: resource-policy
     namespace: trustee-operator-system
   data:
     policy.rego: | 1
       package policy 2
       default allow = false
       allow {
         input["tee"] != "sample"
       }

   1

   リソースポリシーの名前 policy.rego は、Trustee config map で定義されたリソースポリシーと一致する必要があります。

   2

   リソースポリシーは Open Policy Agent 仕様に準拠します。この例では、TEE がサンプルのアテスターでない場合にすべてのリソースを取得できます。

2. 次のコマンドを実行して、リソースポリシーの config map を作成します。

   $ oc apply -f resourcepolicy-configmap.yaml