14.3. モニタリング

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

手順

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

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

手順

1. DPDK チェックアップとトラフィックジェネレーター Pod 用の ServiceAccount、role、roleBinding マニフェストを作成します。

   例14.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: [ "pods" ]
       verbs: [ "create", "get", "delete" ]
     - apiGroups: [ "" ]
       resources: [ "pods/exec" ]
       verbs: [ "create" ]
     - apiGroups: [ "k8s.cni.cncf.io" ]
       resources: [ "network-attachment-definitions" ]
       verbs: [ "get" ]
   ---
   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
   ---
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: dpdk-checkup-traffic-gen-sa

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

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

3. トラフィックジェネレーター Pod の SecurityContextConstraints マニフェストを作成します。

   セキュリティーコンテキスト制約マニフェストの例

   apiVersion: security.openshift.io/v1
   kind: SecurityContextConstraints
   metadata:
     name: dpdk-checkup-traffic-gen
   allowHostDirVolumePlugin: true
   allowHostIPC: false
   allowHostNetwork: false
   allowHostPID: false
   allowHostPorts: false
   allowPrivilegeEscalation: false
   allowPrivilegedContainer: false
   allowedCapabilities:
   - IPC_LOCK
   - NET_ADMIN
   - NET_RAW
   - SYS_RESOURCE
   defaultAddCapabilities: null
   fsGroup:
     type: RunAsAny
   groups: []
   readOnlyRootFilesystem: false
   requiredDropCapabilities: null
   runAsUser:
     type: RunAsAny
   seLinuxContext:
     type: RunAsAny
   seccompProfiles:
   - runtime/default
   - unconfined
   supplementalGroups:
     type: RunAsAny
   users:
   - system:serviceaccount:dpdk-checkup-ns:dpdk-checkup-traffic-gen-sa

4. SecurityContextConstraints マニフェストを適用します。

   $ oc apply -f <dpdk_scc>.yaml

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

   入力 config map の例

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: dpdk-checkup-config
   data:
     spec.timeout: 10m
     spec.param.networkAttachmentDefinitionName: <network_name> 1
     spec.param.trafficGeneratorRuntimeClassName: <runtimeclass_name> 2
     spec.param.trafficGeneratorImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-traffic-gen:v0.1.1" 3
     spec.param.vmContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-vm:v0.1.1" 4

   1

   NetworkAttachmentDefinition オブジェクトの名前。

   2

   トラフィックジェネレーター Pod が使用する RuntimeClass リソース。

   3

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

   4

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

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

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

7. チェックアップを実行する 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.13.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

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

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

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

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

10. 次のコマンドを実行して、チェックアップの結果を確認します。

    $ 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: 1h2m
      spec.param.NetworkAttachmentDefinitionName: "mlx-dpdk-network-1"
      spec.param.trafficGeneratorRuntimeClassName: performance-performance-zeus10
      spec.param.trafficGeneratorImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-traffic-gen:v0.1.1"
      spec.param.vmContainerDiskImage: "quay.io/kiagnose/kubevirt-dpdk-checkup-vm:v0.1.1"
      status.succeeded: true
      status.failureReason: " "
      status.startTimestamp: 2022-12-21T09:33:06+00:00
      status.completionTimestamp: 2022-12-21T11:33:06+00:00
      status.result.actualTrafficGeneratorTargetNode: worker-dpdk1
      status.result.actualDPDKVMTargetNode: worker-dpdk2
      status.result.dropRate: 0

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

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

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

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

    $ oc delete -f <dpdk_sa_roles_rolebinding>.yaml

手順

1. Service YAML ファイルを作成します。以下の例では、このファイルは node-exporter-service.yaml という名前です。

   kind: Service
   apiVersion: v1
   metadata:
     name: node-exporter-service 1
     namespace: dynamation 2
     labels:
       servicetype: metrics 3
   spec:
     ports:
       - name: exmet 4
         protocol: TCP
         port: 9100 5
         targetPort: 9100 6
     type: ClusterIP
     selector:
       monitor: metrics 7

   1

   仮想マシンからメトリックを公開する node-exporter サービス。

   2

   サービスが作成される namespace。

   3

   サービスのラベル。ServiceMonitor はこのラベルを使用してこのサービスを照会します。

   4

   ClusterIP サービスのポート 9100 でメトリックを公開するポートに指定された名前。

   5

   リクエストをリッスンするために node-exporter-service によって使用されるターゲットポート。

   6

   monitor ラベルが設定された仮想マシンの TCP ポート番号。

   7

   仮想マシンの Pod を照会するために使用されるラベル。この例では、ラベル monitor のある仮想マシンの Pod と、metrics の値がマッチします。

2. node-exporter サービスを作成します。

   $ oc create -f node-exporter-service.yaml

手順

1. 仮想マシンにログインします。

2. node-exporter ファイルのバージョンに適用されるディレクトリーパスを使用して、node-exporter ファイルを仮想マシンにダウンロードします。

   $ wget https://github.com/prometheus/node_exporter/releases/download/v1.3.1/node_exporter-1.3.1.linux-amd64.tar.gz

3. 実行ファイルを展開して、/usr/bin ディレクトリーに配置します。

   $ sudo tar xvf node_exporter-1.3.1.linux-amd64.tar.gz \
       --directory /usr/bin --strip 1 "*/node_exporter"

4. ディレクトリーのパス/etc/systemd/systemに node_exporter.service ファイルを作成します。この systemd サービスファイルは、仮想マシンの再起動時に node-exporter サービスを実行します。

   [Unit]
   Description=Prometheus Metrics Exporter
   After=network.target
   StartLimitIntervalSec=0
   
   [Service]
   Type=simple
   Restart=always
   RestartSec=1
   User=root
   ExecStart=/usr/bin/node_exporter
   
   [Install]
   WantedBy=multi-user.target

5. systemd サービスを有効にし、起動します。

   $ sudo systemctl enable node_exporter.service
   $ sudo systemctl start node_exporter.service

手順

1. 仮想マシン設定ファイルの template spec を編集します。この例では、ラベル monitor の値が metrics になります。

   spec:
     template:
       metadata:
         labels:
           monitor: metrics

2. 仮想マシンを停止して再起動し、monitor ラベルに指定されたラベル名を持つ新しい Pod を作成します。

手順

1. ServiceMonitor リソース設定の YAML ファイルを作成します。この例では、サービスモニターはラベル metrics が指定されたサービスとマッチし、30 秒ごとに exmet ポートをクエリーします。

   apiVersion: monitoring.coreos.com/v1
   kind: ServiceMonitor
   metadata:
     labels:
       k8s-app: node-exporter-metrics-monitor
     name: node-exporter-metrics-monitor 1
     namespace: dynamation 2
   spec:
     endpoints:
     - interval: 30s 3
       port: exmet 4
       scheme: http
     selector:
       matchLabels:
         servicetype: metrics

   1

   ServiceMonitor の名前。

   2

   ServiceMonitor が作成される namespace。

   3

   ポートをクエリーする間隔。

   4

   30 秒ごとにクエリーされるポートの名前

2. node-exporter サービスの ServiceMonitor 設定を作成します。

   $ oc create -f node-exporter-metrics-monitor.yaml

1. 仮想マシン (VM) のウォッチドッグデバイスを設定します。
2. ゲストにウォッチドッグエージェントをインストールします。

手順

1. VM 設定ファイルにゲストエージェント ping プローブの詳細を含めます。以下に例を示します。

   ゲストエージェント ping プローブの例

   # ...
   spec:
     readinessProbe:
       guestAgentPing: {} 1
       initialDelaySeconds: 120 2
       periodSeconds: 20 3
       timeoutSeconds: 10 4
       failureThreshold: 3 5
       successThreshold: 3 6
   # ...

   1

   VM に接続するためのゲストエージェント ping プローブ。

   2

   オプション: VM が起動してからゲストエージェントプローブが開始されるまでの時間 (秒単位)。

   3

   オプション: プローブを実行する間の遅延 (秒単位)。デフォルトの遅延は 10 秒です。この値は timeoutSeconds よりも大きくなければなりません。

   4

   オプション: プローブがタイムアウトになり、VM が失敗したと見なされるまでの非アクティブの秒数。デフォルト値は 1 です。この値は periodSeconds 未満である必要があります。

   5

   オプション: プローブが失敗できる回数。デフォルトは 3 です。指定された試行回数になると、Pod には Unready というマークが付けられます。

   6

   オプション: 成功とみなされるまでにプローブが失敗後に成功を報告する必要のある回数。デフォルトでは 1 回です。

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

   $ oc create -f <file_name>.yaml