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

手順

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

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

   ---
   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.20.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. 次のコマンドを実行して、storage-checkup-config config map を編集します。

   $ oc edit configmap storage-checkup-config -n <checkup_namespace>

2. onfailure 値を使用するように skipTeardown フィールドを設定します。これは、storage_checkup.yaml ファイルに保存されている storage-checkup-config config map を変更することで実行できます。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: storage-checkup-config
     namespace: <checkup_namespace>
   data:
     spec.param.skipTeardown: onfailure
   # ...

3. 次のコマンドを実行して、storage-checkup-config config map を再適用します。

   $ oc apply -f storage_checkup.yaml -n <checkup_namespace>

手順

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

手順

1. ストレージチェックアップ用の ServiceAccount、Role、および RoleBinding マニフェストファイルを作成します。

   サービスアカウント、ロール、およびロールバインディングマニフェストの例:

   ---
   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.20.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.20.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

   ストレージプロファイル spec でオーバーライドされる 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. 次のコマンドを実行して出力を観察し、storage-checkup-config config map の status.failureReason フィールドを確認します。

   $ oc get configmap storage-checkup-config -n <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: "false" 

   1

   
     status.failureReason: "ErrNoDefaultStorageClass" 

   2

   
   # ...

   1

   チェックアップが失敗した場合、status.succeeded 値は false になります。

   2

   チェックアップが失敗した場合、status.failureReason フィールドにエラーメッセージが含まれています。この出力例の ErrNoDefaultStorageClass エラーメッセージは、デフォルトのストレージクラスが設定されていないことを示しています。

2. must-gather ツールによって提供されたディレクトリーで、data.status.failureReason フィールド値のエラーに関連するログ、イベント、または用語を検索します。