14.3. 모니터링

1. 서비스 계정, 역할, 역할 바인딩을 생성하여 대기 시간 점검에 클러스터 액세스 권한을 제공합니다.
2. 구성 맵을 생성하여 점검을 실행하고 결과를 저장할 입력을 제공합니다.
3. 점검을 실행하는 작업을 생성합니다.
4. 구성 맵에서 결과를 검토합니다.
5. 선택 사항: 점검을 다시 실행하려면 기존 구성 맵 및 작업을 삭제한 다음 새 구성 맵 및 작업을 생성합니다.
6. 완료되면 latency checkup 리소스를 삭제합니다.

절차

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 >는 점검을 실행할 네임스페이스입니다. NetworkAttachmentDefinition 오브젝트가 있는 기존 네임스페이스여야 합니다.

3. 검사에 대한 입력 매개변수가 포함된 ConfigMap 매니페스트를 생성합니다.

   입력 구성 맵의 예

   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. 대상 네임스페이스에 구성 맵 매니페스트를 적용합니다.

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

5. 점검을 실행할 작업 매니페스트를 생성합니다.

   작업 매니페스트 예

   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. 작업 매니페스트를 적용합니다.

   $ 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

   출력 구성 맵의 예(success)

   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. 다음 명령을 실행하여 이전에 생성한 작업 및 구성 맵을 삭제합니다.

    $ 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. 트래픽 생성 Pod에 대한 DPDK 검사 및 서비스 계정에 대한 서비스 계정, 역할, 역할 바인딩을 생성합니다.
2. 트래픽 생성기 Pod에 대한 보안 컨텍스트 제약 조건 리소스를 생성합니다.
3. 구성 맵을 생성하여 점검을 실행하고 결과를 저장할 입력을 제공합니다.
4. 점검을 실행하는 작업을 생성합니다.
5. 구성 맵에서 결과를 검토합니다.
6. 선택 사항: 점검을 다시 실행하려면 기존 구성 맵 및 작업을 삭제한 다음 새 구성 맵 및 작업을 생성합니다.
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 매니페스트를 생성합니다.

   입력 구성 맵의 예

   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

   트래픽 생성기의 컨테이너 이미지입니다. 이 예에서 이미지는 업스트림 프로젝트 Quay 컨테이너 레지스트리에서 가져옵니다.

   4

   VM의 컨테이너 디스크 이미지입니다. 이 예에서 이미지는 업스트림 프로젝트 Quay 컨테이너 레지스트리에서 가져옵니다.

6. 대상 네임스페이스에 ConfigMap 매니페스트를 적용합니다.

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

7. 점검을 실행할 작업 매니페스트를 생성합니다.

   작업 매니페스트 예

   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. 작업 매니페스트를 적용합니다.

   $ 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

    출력 구성 맵의 예(success)

    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. 다음 명령을 실행하여 이전에 생성한 작업 및 구성 맵을 삭제합니다.

    $ 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

   서비스가 생성된 네임스페이스입니다.

   3

   서비스의 레이블입니다. ServiceMonitor 는 이 서비스와 일치하도록 이 라벨을 사용합니다.

   4

   ClusterIP 서비스의 포트 9100에서 지표를 표시하는 포트에 지정된 이름입니다.

   5

   node-exporter-service 에서 요청을 수신 대기하는 데 사용하는 대상 포트입니다.

   6

   monitor 레이블로 구성된 가상 머신의 TCP 포트 번호입니다.

   7

   가상 머신의 Pod와 일치하는 데 사용되는 레이블입니다. 이 예에서는 라벨 monitor 가 있는 가상 머신의 Pod와 메트릭 값이 일치합니다.

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. 이 디렉터리 경로에 node_exporter.service 파일을 생성합니다. /etc/systemd/system. 이 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. 가상 머신 구성 파일의 템플릿 사양을 편집합니다. 이 예에서 라벨 monitor 에는 값이 있습니다.

   spec:
     template:
       metadata:
         labels:
           monitor: metrics

2. 가상 머신을 중지하고 다시 시작하여 monitor 라벨에 지정된 라벨 이름으로 새 Pod를 생성합니다.

절차

1. ServiceMonitor 리소스 구성에 대한 YAML 파일을 생성합니다. 이 예에서 서비스 모니터는 모든 서비스와 라벨 메트릭 과 일치하고 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 가 생성된 네임스페이스입니다.

   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