12.2. OpenShift Virtualization クラスター検査フレームワーク

1. サービスアカウント、ロール、ロールバインディングを作成して、レイテンシーチェックアップへのクラスターアクセス権を提供します。
2. config map を作成し、チェックアップを実行して結果を保存するための入力を行います。
3. チェックアップを実行するジョブを作成します。
4. config map で結果を確認します。
5. オプション: チェックアップを再実行するには、既存の config map とジョブを削除し、新しい config map とジョブを作成します。
6. 完了したら、レイテンシーチェックアップリソースを削除します。

手順

1. レイテンシーチェックアップ用の ServiceAccount、Role、RoleBinding マニフェストを作成します。

   例12.1 ロールマニフェストファイルの例

   ---
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: vm-latency-checkup-sa
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: kubevirt-vm-latency-checker
   rules:
   - apiGroups: ["kubevirt.io"]
     resources: ["virtualmachineinstances"]
     verbs: ["get", "create", "delete"]
   - apiGroups: ["subresources.kubevirt.io"]
     resources: ["virtualmachineinstances/console"]
     verbs: ["get"]
   - apiGroups: ["k8s.cni.cncf.io"]
     resources: ["network-attachment-definitions"]
     verbs: ["get"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: kubevirt-vm-latency-checker
   subjects:
   - kind: ServiceAccount
     name: vm-latency-checkup-sa
   roleRef:
     kind: Role
     name: kubevirt-vm-latency-checker
     apiGroup: rbac.authorization.k8s.io
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: kiagnose-configmap-access
   rules:
   - apiGroups: [ "" ]
     resources: [ "configmaps" ]
     verbs: ["get", "update"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: kiagnose-configmap-access
   subjects:
   - kind: ServiceAccount
     name: vm-latency-checkup-sa
   roleRef:
     kind: Role
     name: kiagnose-configmap-access
     apiGroup: rbac.authorization.k8s.io

2. ServiceAccount、Role、RoleBinding マニフェストを適用します。

   $ oc apply -n <target_namespace> -f <latency_sa_roles_rolebinding>.yaml 1

   1

   <target_namespace> は、チェックアップを実行する namespace です。これは、NetworkAttachmentDefinition オブジェクトが存在する既存の namespace である必要があります。

3. チェックアップの入力パラメーターを含む ConfigMap マニフェストを作成します。

   入力 config map の例

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: kubevirt-vm-latency-checkup-config
   data:
     spec.timeout: 5m
     spec.param.networkAttachmentDefinitionNamespace: <target_namespace>
     spec.param.networkAttachmentDefinitionName: "blue-network" 1
     spec.param.maxDesiredLatencyMilliseconds: "10" 2
     spec.param.sampleDurationSeconds: "5" 3
     spec.param.sourceNode: "worker1" 4
     spec.param.targetNode: "worker2" 5

   1

   NetworkAttachmentDefinition オブジェクトの名前。

   2

   オプション: 仮想マシン間の必要な最大待機時間 (ミリ秒単位)。測定されたレイテンシーがこの値を超えると、チェックアップは失敗します。

   3

   オプション: レイテンシーチェックの継続時間 (秒単位)。

   4

   オプション: 指定すると、このノードからターゲットノードまでの待ち時間が測定されます。ソースノードが指定されている場合、spec.param.targetNode フィールドは空にできません。

   5

   オプション: 指定すると、ソースノードからこのノードまでの待ち時間が測定されます。

4. ターゲット namespace に config map マニフェストを適用します。

   $ oc apply -n <target_namespace> -f <latency_config_map>.yaml

5. チェックアップを実行する Job マニフェストを作成します。

   ジョブマニフェストの例

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: kubevirt-vm-latency-checkup
   spec:
     backoffLimit: 0
     template:
       spec:
         serviceAccountName: vm-latency-checkup-sa
         restartPolicy: Never
         containers:
           - name: vm-latency-checkup
             image: registry.redhat.io/container-native-virtualization/vm-network-latency-checkup-rhel9:v4.14.0
             securityContext:
               allowPrivilegeEscalation: false
               capabilities:
                 drop: ["ALL"]
               runAsNonRoot: true
               seccompProfile:
                 type: "RuntimeDefault"
             env:
               - name: CONFIGMAP_NAMESPACE
                 value: <target_namespace>
               - name: CONFIGMAP_NAME
                 value: kubevirt-vm-latency-checkup-config
               - name: POD_UID
                 valueFrom:
                   fieldRef:
                     fieldPath: metadata.uid

6. Job マニフェストを適用します。

   $ oc apply -n <target_namespace> -f <latency_job>.yaml

7. ジョブが完了するまで待ちます。

   $ oc wait job kubevirt-vm-latency-checkup -n <target_namespace> --for condition=complete --timeout 6m

8. 以下のコマンドを実行して、レイテンシーチェックアップの結果を確認します。測定された最大レイテンシーが spec.param.maxDesiredLatencyMilliseconds 属性の値よりも大きい場合、チェックアップは失敗し、エラーが返されます。

   $ oc get configmap kubevirt-vm-latency-checkup-config -n <target_namespace> -o yaml

   出力 config map の例 (成功)

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: kubevirt-vm-latency-checkup-config
     namespace: <target_namespace>
   data:
     spec.timeout: 5m
     spec.param.networkAttachmentDefinitionNamespace: <target_namespace>
     spec.param.networkAttachmentDefinitionName: "blue-network"
     spec.param.maxDesiredLatencyMilliseconds: "10"
     spec.param.sampleDurationSeconds: "5"
     spec.param.sourceNode: "worker1"
     spec.param.targetNode: "worker2"
     status.succeeded: "true"
     status.failureReason: ""
     status.completionTimestamp: "2022-01-01T09:00:00Z"
     status.startTimestamp: "2022-01-01T09:00:07Z"
     status.result.avgLatencyNanoSec: "177000"
     status.result.maxLatencyNanoSec: "244000" 1
     status.result.measurementDurationSec: "5"
     status.result.minLatencyNanoSec: "135000"
     status.result.sourceNode: "worker1"
     status.result.targetNode: "worker2"

   1

   測定された最大レイテンシー (ナノ秒)。

9. オプション: チェックアップが失敗した場合に詳細なジョブログを表示するには、次のコマンドを使用します。

   $ oc logs job.batch/kubevirt-vm-latency-checkup -n <target_namespace>

10. 以下のコマンドを実行して、以前に作成したジョブおよび config map を削除します。

    $ oc delete job -n <target_namespace> kubevirt-vm-latency-checkup

    $ oc delete config-map -n <target_namespace> kubevirt-vm-latency-checkup-config

11. オプション: 別のチェックアップを実行する予定がない場合は、ロールマニフェストを削除します。

    $ oc delete -f <latency_sa_roles_rolebinding>.yaml

1. DPDK チェック用のサービスアカウント、ロール、およびロールバインディングを作成します。
2. config map を作成し、チェックアップを実行して結果を保存するための入力を行います。
3. チェックアップを実行するジョブを作成します。
4. config map で結果を確認します。
5. オプション: チェックアップを再実行するには、既存の config map とジョブを削除し、新しい config map とジョブを作成します。
6. 完了したら、DPDK チェックリソースを削除します。

手順

1. DPDK チェック用の ServiceAccount、Role、および RoleBinding マニフェストを作成します。

   例12.2 サービスアカウント、ロール、ロールバインディングマニフェストファイルの例

   ---
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: dpdk-checkup-sa
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: kiagnose-configmap-access
   rules:
     - apiGroups: [ "" ]
       resources: [ "configmaps" ]
       verbs: [ "get", "update" ]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: kiagnose-configmap-access
   subjects:
     - kind: ServiceAccount
       name: dpdk-checkup-sa
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: kiagnose-configmap-access
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: kubevirt-dpdk-checker
   rules:
     - apiGroups: [ "kubevirt.io" ]
       resources: [ "virtualmachineinstances" ]
       verbs: [ "create", "get", "delete" ]
     - apiGroups: [ "subresources.kubevirt.io" ]
       resources: [ "virtualmachineinstances/console" ]
       verbs: [ "get" ]
     - apiGroups: [ "" ]
       resources: [ "configmaps" ]
       verbs: [ "create", "delete" ]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: kubevirt-dpdk-checker
   subjects:
     - kind: ServiceAccount
       name: dpdk-checkup-sa
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: kubevirt-dpdk-checker

2. ServiceAccount、Role、RoleBinding マニフェストを適用します。

   $ oc apply -n <target_namespace> -f <dpdk_sa_roles_rolebinding>.yaml

3. チェックアップの入力パラメーターを含む ConfigMap マニフェストを作成します。

   入力 config map の例

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: dpdk-checkup-config
   data:
     spec.timeout: 10m
     spec.param.networkAttachmentDefinitionName: <network_name> 1
     spec.param.trafficGenContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-traffic-gen:v0.2.0 2
     spec.param.vmUnderTestContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-vm:v0.2.0" 3

   1

   NetworkAttachmentDefinition オブジェクトの名前。

   2

   トラフィックジェネレーターのコンテナーディスクイメージ。この例では、アップストリームの Project Quay Container Registry からイメージをプルしています。

   3

   テスト対象の仮想マシンのコンテナーディスクイメージ。この例では、アップストリームの Project Quay Container Registry からイメージをプルしています。

4. ターゲット namespace に ConfigMap マニフェストを適用します。

   $ oc apply -n <target_namespace> -f <dpdk_config_map>.yaml

5. チェックアップを実行する Job マニフェストを作成します。

   ジョブマニフェストの例

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: dpdk-checkup
   spec:
     backoffLimit: 0
     template:
       spec:
         serviceAccountName: dpdk-checkup-sa
         restartPolicy: Never
         containers:
           - name: dpdk-checkup
             image: registry.redhat.io/container-native-virtualization/kubevirt-dpdk-checkup-rhel9:v4.14.0
             imagePullPolicy: Always
             securityContext:
               allowPrivilegeEscalation: false
               capabilities:
                 drop: ["ALL"]
               runAsNonRoot: true
               seccompProfile:
                 type: "RuntimeDefault"
             env:
               - name: CONFIGMAP_NAMESPACE
                 value: <target-namespace>
               - name: CONFIGMAP_NAME
                 value: dpdk-checkup-config
               - name: POD_UID
                 valueFrom:
                   fieldRef:
                     fieldPath: metadata.uid

6. Job マニフェストを適用します。

   $ oc apply -n <target_namespace> -f <dpdk_job>.yaml

7. ジョブが完了するまで待ちます。

   $ oc wait job dpdk-checkup -n <target_namespace> --for condition=complete --timeout 10m

8. 次のコマンドを実行して、検査の結果を確認します。

   $ oc get configmap dpdk-checkup-config -n <target_namespace> -o yaml

   出力 config map の例 (成功)

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: dpdk-checkup-config
   data:
     spec.timeout: 10m
     spec.param.NetworkAttachmentDefinitionName: "dpdk-network-1"
     spec.param.trafficGenContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-traffic-gen:v0.2.0"
     spec.param.vmUnderTestContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-vm:v0.2.0"
     status.succeeded: "true" 1
     status.failureReason: "" 2
     status.startTimestamp: "2023-07-31T13:14:38Z" 3
     status.completionTimestamp: "2023-07-31T13:19:41Z" 4
     status.result.trafficGenSentPackets: "480000000" 5
     status.result.trafficGenOutputErrorPackets: "0" 6
     status.result.trafficGenInputErrorPackets: "0" 7
     status.result.trafficGenActualNodeName: worker-dpdk1 8
     status.result.vmUnderTestActualNodeName: worker-dpdk2 9
     status.result.vmUnderTestReceivedPackets: "480000000" 10
     status.result.vmUnderTestRxDroppedPackets: "0" 11
     status.result.vmUnderTestTxDroppedPackets: "0" 12

   1

   検査が成功したか (true)、失敗したか (false) を示します。

   2

   検査が失敗した場合の失敗の理由。

   3

   検査が開始した時刻 (RFC 3339 時刻形式)。

   4

   検査が完了した時刻 (RFC 3339 時刻形式)。

   5

   トラフィックジェネレーターから送信されたパケットの数。

   6

   トラフィックジェネレーターから送信されたエラーパケットの数。

   7

   トラフィックジェネレーターが受信したエラーパケットの数。

   8

   トラフィックジェネレーター仮想マシンがスケジュールされたノード。

   9

   テスト対象の仮想マシンがスケジュールされたノード。

   10

   テスト対象の仮想マシンで受信したパケットの数。

   11

   DPDK アプリケーションによって破棄された入力トラフィックパケット。

   12

   DPDK アプリケーションから破棄された出力トラフィックパケット。

9. 以下のコマンドを実行して、以前に作成したジョブおよび config map を削除します。

   $ oc delete job -n <target_namespace> dpdk-checkup

   $ oc delete config-map -n <target_namespace> dpdk-checkup-config

10. オプション: 別のチェックアップを実行する予定がない場合は、ServiceAccount、Role、RoleBinding マニフェストを削除します。

    $ oc delete -f <dpdk_sa_roles_rolebinding>.yaml