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

手順

1. Web コンソールで Virtualization Checkups に移動します。
2. Network latency タブをクリックします。
3. Install permissions をクリックします。
4. Run checkup をクリックします。
5. Name フィールドに検査の名前を入力します。
6. ドロップダウンメニューから NetworkAttachmentDefinition を選択します。
7. オプション: Sample duration (seconds) フィールドでレイテンシーサンプルの期間を設定します。
8. オプション: Set maximum desired latency (milliseconds) を有効にして時間間隔を定義し、最大遅延時間間隔を定義します。
9. オプション: Select nodes を有効にし、Source node と Target node を指定して、特定のノードをターゲットにします。
10. Run をクリックします。

手順

1. Web コンソールで Virtualization Checkups に移動します。
2. Storage タブをクリックします。
3. Install permissions をクリックします。
4. Run checkup をクリックします。
5. Name フィールドに検査の名前を入力します。
6. Timeout (minutes) フィールドに検査のタイムアウト値を入力します。
7. Run をクリックします。

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
     labels:
       kiagnose/checkup-type: kubevirt-vm-latency
   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
     labels:
       kiagnose/checkup-type: kubevirt-vm-latency
   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.16.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>
     labels:
       kiagnose/checkup-type: kubevirt-vm-latency
   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. ストレージ検査用の ServiceAccount、Role、および RoleBinding マニフェストファイルを作成します。

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

   ---
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: storage-checkup-sa
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: storage-checkup-role
   rules:
     - apiGroups: [ "" ]
       resources: [ "configmaps" ]
       verbs: ["get", "update"]
     - apiGroups: [ "kubevirt.io" ]
       resources: [ "virtualmachines" ]
       verbs: [ "create", "delete" ]
     - apiGroups: [ "kubevirt.io" ]
       resources: [ "virtualmachineinstances" ]
       verbs: [ "get" ]
     - apiGroups: [ "subresources.kubevirt.io" ]
       resources: [ "virtualmachineinstances/addvolume", "virtualmachineinstances/removevolume" ]
       verbs: [ "update" ]
     - apiGroups: [ "kubevirt.io" ]
       resources: [ "virtualmachineinstancemigrations" ]
       verbs: [ "create" ]
     - apiGroups: [ "cdi.kubevirt.io" ]
       resources: [ "datavolumes" ]
       verbs: [ "create", "delete" ]
     - apiGroups: [ "" ]
       resources: [ "persistentvolumeclaims" ]
       verbs: [ "delete" ]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: storage-checkup-role
   subjects:
     - kind: ServiceAccount
       name: storage-checkup-sa
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: storage-checkup-role

2. ターゲット namespace に ServiceAccount、Role、RoleBinding マニフェストを適用します。

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

3. ConfigMap と Job マニフェストファイルを作成します。この config map に、検査ジョブの入力パラメーターを含めます。

   入力 config map とジョブマニフェストの例

   ---
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: storage-checkup-config
     namespace: $CHECKUP_NAMESPACE
   data:
     spec.timeout: 10m
     spec.param.storageClass: ocs-storagecluster-ceph-rbd-virtualization
     spec.param.vmiTimeout: 3m
   ---
   apiVersion: batch/v1
   kind: Job
   metadata:
     name: storage-checkup
     namespace: $CHECKUP_NAMESPACE
   spec:
     backoffLimit: 0
     template:
       spec:
         serviceAccount: storage-checkup-sa
         restartPolicy: Never
         containers:
           - name: storage-checkup
             image: quay.io/kiagnose/kubevirt-storage-checkup:main
             imagePullPolicy: Always
             env:
               - name: CONFIGMAP_NAMESPACE
                 value: $CHECKUP_NAMESPACE
               - name: CONFIGMAP_NAME
                 value: storage-checkup-config

4. ターゲット namespace に ConfigMap と Job マニフェストファイルを適用し、検査を実行します。

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

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

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

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

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

   出力 config map の例 (成功)

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: storage-checkup-config
     labels:
       kiagnose/checkup-type: kubevirt-storage
   data:
     spec.timeout: 10m
     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.cnvVersion: 4.16.2 5
     status.result.defaultStorageClass: trident-nfs 6
     status.result.goldenImagesNoDataSource: <data_import_cron_list> 7
     status.result.goldenImagesNotUpToDate: <data_import_cron_list> 8
     status.result.ocpVersion: 4.16.0 9
     status.result.pvcBound: "true" 10
     status.result.storageProfileMissingVolumeSnapshotClass: <storage_class_list> 11
     status.result.storageProfilesWithEmptyClaimPropertySets: <storage_profile_list> 12
     status.result.storageProfilesWithSmartClone: <storage_profile_list> 13
     status.result.storageProfilesWithSpecClaimPropertySets: <storage_profile_list> 14
     status.result.storageProfilesWithRWX: |-
       ocs-storagecluster-ceph-rbd
       ocs-storagecluster-ceph-rbd-virtualization
       ocs-storagecluster-cephfs
       trident-iscsi
       trident-minio
       trident-nfs
       windows-vms
     status.result.vmBootFromGoldenImage: VMI "vmi-under-test-dhkb8" successfully booted
     status.result.vmHotplugVolume: |-
       VMI "vmi-under-test-dhkb8" hotplug volume ready
       VMI "vmi-under-test-dhkb8" hotplug volume removed
     status.result.vmLiveMigration: VMI "vmi-under-test-dhkb8" migration completed
     status.result.vmVolumeClone: 'DV cloneType: "csi-clone"'
     status.result.vmsWithNonVirtRbdStorageClass: <vm_list> 15
     status.result.vmsWithUnsetEfsStorageClass: <vm_list> 16

   1

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

   2

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

   3

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

   4

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

   5

   OpenShift Virtualization のバージョン。

   6

   デフォルトのストレージクラスがあるかどうかを指定します。

   7

   データソースの準備ができていないゴールデンイメージのリスト。

   8

   データインポート cron が最新ではないゴールデンイメージのリスト。

   9

   OpenShift Container Platform のバージョン。

   10

   10 Mi の PVC が作成され、プロビジョナーによってバインドされているかどうかを指定します。

   11

   スナップショットベースのクローンを使用しているが、VolumeSnapshotClass が欠落しているストレージプロファイルのリスト。

   12

   不明なプロビジョナーを持つストレージプロファイルのリスト。

   13

   スマートクローン (CSI/スナップショット) をサポートするストレージプロファイルのリスト。

   14

   ストレージプロファイル仕様でオーバーライドされる claimPropertySets のリスト。

   15

   仮想化ストレージクラスが存在する場合に Ceph RBD ストレージクラスを使用する仮想マシンのリスト。

   16

   GID と UID がストレージクラスに設定されていない Elastic File Store (EFS) ストレージクラスを使用する仮想マシンのリスト。

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

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

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

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

   $ oc delete -f <storage_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.3 サービスアカウント、ロール、ロールバインディングマニフェストファイルの例

   ---
   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
     labels:
       kiagnose/checkup-type: kubevirt-dpdk
   data:
     spec.timeout: 10m
     spec.param.networkAttachmentDefinitionName: <network_name> 1
     spec.param.trafficGenContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-traffic-gen:v0.4.0 2
     spec.param.vmUnderTestContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-vm:v0.4.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
     labels:
       kiagnose/checkup-type: kubevirt-dpdk
   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.16.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
     labels:
       kiagnose/checkup-type: kubevirt-dpdk
   data:
     spec.timeout: 10m
     spec.param.NetworkAttachmentDefinitionName: "dpdk-network-1"
     spec.param.trafficGenContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-traffic-gen:v0.4.0"
     spec.param.vmUnderTestContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-vm:v0.4.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