12.2. OpenShift Virtualization 클러스터 검사 프레임워크

OpenShift Virtualization에는 클러스터 유지 관리 및 문제 해결에 사용할 수 있는 다음과 같은 사전 정의된 점검이 포함되어 있습니다.

대기 시간 점검: 보조 네트워크 인터페이스에 연결된 두 개의 VM(가상 머신) 간에 네트워크 연결을 확인하고 대기 시간을 측정합니다.
DPDK 점검: 노드가 패킷 손실이 0인 DPDK(Data Plane Development Kit) 워크로드로 VM을 실행할 수 있는지 확인합니다.
스토리지 점검: 클러스터 스토리지가 OpenShift Virtualization에 대해 최적으로 구성되었는지 확인합니다.

중요

OpenShift Virtualization 클러스터 검사 프레임워크는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

12.2.1. OpenShift Virtualization 클러스터 검사 프레임워크 정보

점검 은 특정 클러스터 기능이 예상대로 작동하는지 확인할 수 있는 자동화된 테스트 워크로드입니다. 클러스터 검사 프레임워크는 기본 Kubernetes 리소스를 사용하여 점검을 구성하고 실행합니다.

클러스터 관리자와 개발자는 사전 정의된 점검을 사용하여 클러스터 유지 관리를 개선하고, 예기치 않은 동작을 해결하고, 오류를 최소화하고, 시간을 절약할 수 있습니다. 또한 수표 결과를 검토하고 추가 분석을 위해 전문가와 공유할 수 있습니다. 공급업체는 제공하는 기능 또는 서비스에 대한 점검을 작성하고 게시하고 고객 환경이 올바르게 구성되었는지 확인할 수 있습니다.

기존 네임스페이스에서 사전 정의된 점검을 실행하려면 점검에 대한 서비스 계정을 설정하고, 서비스 계정에 대한 Role 및 RoleBinding 오브젝트를 생성하고, 점검 권한을 활성화하고, 입력 구성 맵 및 점검 작업을 생성해야 합니다. 점검을 여러 번 실행할 수 있습니다.

중요

항상 다음을 수행해야 합니다.

검사를 적용하기 전에 검사 이미지가 신뢰할 수 있는 소스의인지 확인합니다.
Role 및 RoleBinding 오브젝트를 생성하기 전에 점검 권한을 검토합니다.

12.2.2. 웹 콘솔에서 클러스터 검사 실행

웹 콘솔을 사용하여 클러스터에서 대기 시간 또는 스토리지 점검을 실행합니다.

웹 콘솔에서 대기 시간 점검 및 스토리지 점검을 처음 실행할 때 다음 절차를 사용하십시오. 추가 점검의 경우 두 점검 탭에서 점검 실행을 클릭하고 드롭다운 메뉴에서 적절한 점검을 선택합니다.

중요

대기 시간 점검을 실행하기 전에 먼저 VM의 보조 인터페이스를 노드의 인터페이스에 연결하려면 클러스터 노드에 브리지 인터페이스를 생성해야 합니다. 브리지 인터페이스를 생성하지 않으면 VM이 시작되지 않고 작업이 실패합니다.

12.2.2.1. 웹 콘솔에서 대기 시간 점검 실행

대기 시간 점검을 실행하여 네트워크 연결을 확인하고 보조 네트워크 인터페이스에 연결된 두 가상 머신 간의 대기 시간을 측정합니다.

사전 요구 사항

NetworkAttachmentDefinition 을 네임스페이스에 추가해야 합니다.

프로세스

웹 콘솔에서 가상화 → 확인 으로 이동합니다.
네트워크 대기 시간 탭을 클릭합니다.
권한 설치를 클릭합니다.
Run checkup 을 클릭합니다.
이름 필드에 검사 이름을 입력합니다.
드롭다운 메뉴에서 NetworkAttachmentDefinition 을 선택합니다.
선택 사항: 샘플 기간 (초) 필드에서 대기 시간 샘플 기간을 설정합니다.
선택 사항: 원하는 최대 대기 시간(밀리초)을 활성화하고 시간 간격을 정의하여 최대 대기 시간 기간을 정의합니다.
선택 사항: 노드 선택을 활성화하고 소스 노드 및 대상 노드를 지정하여 특정 노드를 대상으로 지정합니다.
실행을 클릭합니다.

Latency 검사 탭의 Checkups 목록에서 대기 시간 점검 상태를 볼 수 있습니다. 자세한 내용은 점검 이름을 클릭합니다.

12.2.2.2. 웹 콘솔에서 스토리지 점검 실행

스토리지 점검을 실행하여 스토리지가 가상 머신에서 올바르게 작동하는지 확인합니다.

프로세스

웹 콘솔에서 가상화 → 확인 으로 이동합니다.
스토리지 탭을 클릭합니다.
권한 설치를 클릭합니다.
Run checkup 을 클릭합니다.
이름 필드에 검사 이름을 입력합니다.
시간 제한(분) 필드에 검사 시간 값을 입력합니다.
실행을 클릭합니다.

스토리지 탭의 Checkups 목록에서 스토리지 점검 상태를 볼 수 있습니다. 자세한 내용은 점검 이름을 클릭합니다.

12.2.3. CLI에서 대기 시간 점검 실행

사전 정의된 점검을 사용하여 네트워크 연결을 확인하고 보조 네트워크 인터페이스에 연결된 두 가상 머신(VM) 간의 대기 시간을 측정합니다. 대기 시간 검사에서는 ping 유틸리티를 사용합니다.

다음 단계를 수행하여 대기 시간 점검을 실행합니다.

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

사전 요구 사항

OpenShift CLI(oc)를 설치합니다.
클러스터에는 작업자 노드가 두 개 이상 있습니다.
네임스페이스에 대한 네트워크 연결 정의를 구성했습니다.

프로세스

대기 시간 점검을 위한 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

ServiceAccount,Role, RoleBinding 매니페스트를 적용합니다.
```
$ oc apply -n <target_namespace> -f <latency_sa_roles_rolebinding>.yaml 1
```
1
<target_namespace >는 점검을 실행할 네임스페이스입니다. NetworkAttachmentDefinition 오브젝트가 있는 기존 네임스페이스여야 합니다.
점검에 대한 입력 매개변수가 포함된 ConfigMap 매니페스트를 생성합니다.
입력 구성 맵 예
```
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
선택 사항: 지정된 경우 대기 시간은 소스 노드에서 이 노드로 측정됩니다.
대상 네임스페이스에 구성 맵 매니페스트를 적용합니다.
```
$ oc apply -n <target_namespace> -f <latency_config_map>.yaml
```

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

작업 매니페스트 예

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

작업 매니페스트를 적용합니다.

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

작업이 완료될 때까지 기다립니다.

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

다음 명령을 실행하여 대기 시간 점검 결과를 검토합니다. 측정된 최대 대기 시간이 spec.param.maxDesiredLatencyMilliseconds 속성 값보다 크면 점검이 실패하고 오류를 반환합니다.

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

출력 구성 맵 예(성공)

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: 나노초 단위로 측정된 최대 대기 시간입니다.

선택 사항: 점검 실패의 경우 자세한 작업 로그를 보려면 다음 명령을 사용합니다.
```
$ oc logs job.batch/kubevirt-vm-latency-checkup -n <target_namespace>
```

다음 명령을 실행하여 이전에 생성한 작업 및 구성 맵을 삭제합니다.

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

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

선택 사항: 다른 점검을 실행할 계획이 없는 경우 역할 매니페스트를 삭제합니다.
```
$ oc delete -f <latency_sa_roles_rolebinding>.yaml
```

12.2.4. DPDK 점검

사전 정의된 점검을 사용하여 OpenShift Container Platform 클러스터 노드에서 패킷 손실이 없는 DPDK(Data Plane Development Kit) 워크로드로 VM(가상 머신)을 실행할 수 있는지 확인합니다. DPDK 검사에서는 트래픽 생성기와 테스트 DPDK 애플리케이션을 실행하는 VM 간에 트래픽을 실행합니다.

다음 단계를 수행하여 DPDK 검사를 실행합니다.

DPDK 검사에 대한 서비스 계정, 역할 및 역할 바인딩을 생성합니다.
점검을 실행하고 결과를 저장할 입력을 제공하는 구성 맵을 생성합니다.
점검을 실행할 작업을 생성합니다.
구성 맵에서 결과를 검토합니다.
선택 사항: 점검을 재실행하려면 기존 구성 맵 및 작업을 삭제한 다음 새 구성 맵 및 작업을 생성합니다.
완료되면 DPDK 점검 리소스를 삭제합니다.

사전 요구 사항

OpenShift CLI(oc)가 설치되어 있습니다.
클러스터는 DPDK 애플리케이션을 실행하도록 구성되어 있습니다.
프로젝트는 DPDK 애플리케이션을 실행하도록 구성되어 있습니다.

프로세스

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

ServiceAccount,Role, RoleBinding 매니페스트를 적용합니다.

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

점검에 대한 입력 매개변수가 포함된 ConfigMap 매니페스트를 생성합니다.
입력 구성 맵 예
```
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
트래픽 생성기의 컨테이너 디스크 이미지입니다. 이 예에서는 업스트림 프로젝트 Quay 컨테이너 레지스트리에서 이미지를 가져옵니다.
3
테스트 중인 VM의 컨테이너 디스크 이미지입니다. 이 예에서는 업스트림 프로젝트 Quay 컨테이너 레지스트리에서 이미지를 가져옵니다.
대상 네임스페이스에 ConfigMap 매니페스트를 적용합니다.
```
$ oc apply -n <target_namespace> -f <dpdk_config_map>.yaml
```

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

작업 매니페스트 예

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

작업 매니페스트를 적용합니다.

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

작업이 완료될 때까지 기다립니다.

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

다음 명령을 실행하여 점검 결과를 검토합니다.

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

출력 구성 맵 예(성공)

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: 트래픽 생성기 VM이 예약된 노드입니다.
9: 테스트 중인 VM이 예약된 노드입니다.
10: 테스트 중인 VM에서 수신한 패킷 수입니다.
11: DPDK 애플리케이션에서 삭제한 수신 트래픽 패킷입니다.
12: DPDK 애플리케이션에서 삭제된 송신 트래픽 패킷입니다.

다음 명령을 실행하여 이전에 생성한 작업 및 구성 맵을 삭제합니다.

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

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

선택 사항: 다른 점검을 실행하지 않으려면 ServiceAccount,Role, RoleBinding 매니페스트를 삭제합니다.
```
$ oc delete -f <dpdk_sa_roles_rolebinding>.yaml
```

12.2.4.1. DPDK 점검 구성 맵 매개변수

다음 표는 클러스터 DPDK 준비 상태 점검을 실행할 때 입력 ConfigMap 매니페스트의 data 스탠자에 설정할 수 있는 필수 및 선택적 매개변수를 보여줍니다.

표 12.1. DPDK 확인 구성 맵 입력 매개변수
매개변수	설명	필수 항목입니다.
`spec.timeout`	체크아웃에 실패하기 전의 시간(분)입니다.	True
`spec.param.networkAttachmentDefinitionName`	연결된 SR-IOV NIC의 `NetworkAttachmentDefinition` 오브젝트 이름입니다.	True
`spec.param.trafficGenContainerDiskImage`	트래픽 생성기의 컨테이너 디스크 이미지입니다.	True
`spec.param.trafficGenTargetNodeName`	트래픽 생성기 VM을 예약할 노드입니다. 노드는 DPDK 트래픽을 허용하도록 구성해야 합니다.	False
`spec.param.trafficGenPacketsPerSecond`	초당 패킷 수(k) 또는 million(m)입니다. 기본값은 8m입니다.	False
`spec.param.vmUnderTestContainerDiskImage`	테스트 중인 VM의 컨테이너 디스크 이미지입니다.	True
`spec.param.vmUnderTestTargetNodeName`	테스트 중인 VM을 예약해야 하는 노드입니다. 노드는 DPDK 트래픽을 허용하도록 구성해야 합니다.	False
`spec.param.testDuration`	트래픽 생성기가 실행되는 기간(분)입니다. 기본값은 5분입니다.	False
`spec.param.portBandwidthGbps`	SR-IOV NIC의 최대 대역폭입니다. 기본값은 10Gbps입니다.	False
`spec.param.verbose`	`true` 로 설정하면 검사 로그의 상세 정보 표시가 증가합니다. 기본값은 `false`입니다.	False

12.2.4.2. RHEL 가상 머신용 컨테이너 디스크 이미지 빌드

qcow2 형식으로 사용자 지정 RHEL(Red Hat Enterprise Linux) 8 OS 이미지를 빌드하고 이를 사용하여 컨테이너 디스크 이미지를 생성할 수 있습니다. 클러스터에서 액세스할 수 있는 레지스트리에 컨테이너 디스크 이미지를 저장하고 DPDK 검사 구성 맵의 spec.param.vmContainerDiskImage 속성에 이미지 위치를 지정할 수 있습니다.

컨테이너 디스크 이미지를 빌드하려면 이미지 빌더 VM(가상 머신)을 생성해야 합니다. 이미지 빌더 VM 은 사용자 지정 RHEL 이미지를 빌드하는 데 사용할 수 있는 RHEL 8 VM입니다.

사전 요구 사항

이미지 빌더 VM은 RHEL 8.7을 실행해야 하며 /var 디렉터리에 최소 2개의 CPU 코어, 4GiB RAM 및 20GB의 여유 공간이 있어야 합니다.
이미지 빌더 툴과 해당 CLI(composer-cli)를 VM에 설치했습니다.
virt-customize 툴을 설치했습니다.
```
# dnf install libguestfs-tools
```
Podman CLI 툴(podman)을 설치했습니다.

프로세스

RHEL 8.7 이미지를 빌드할 수 있는지 확인합니다.
```
# composer-cli distros list
```
참고
composer-cli 명령을 root가 아닌 것으로 실행하려면 사용자를 weldr 또는 root 그룹에 추가합니다.
```
# usermod -a -G weldr user
```
```
$ newgrp weldr
```

다음 명령을 입력하여 설치할 패키지, 커널 사용자 정의 및 부팅 시 비활성화할 서비스가 포함된 TOML 형식으로 이미지 블루프린트 파일을 생성합니다.

$ cat << EOF > dpdk-vm.toml
name = "dpdk_image"
description = "Image to use with the DPDK checkup"
version = "0.0.1"
distro = "rhel-87"

[[customizations.user]]
name = "root"
password = "redhat"

[[packages]]
name = "dpdk"

[[packages]]
name = "dpdk-tools"

[[packages]]
name = "driverctl"

[[packages]]
name = "tuned-profiles-cpu-partitioning"

[customizations.kernel]
append = "default_hugepagesz=1GB hugepagesz=1G hugepages=1"

[customizations.services]
disabled = ["NetworkManager-wait-online", "sshd"]
EOF

다음 명령을 실행하여 블루프린트 파일을 이미지 빌더 툴로 푸시합니다.
```
# composer-cli blueprints push dpdk-vm.toml
```
블루프린트 이름과 출력 파일 형식을 지정하여 시스템 이미지를 생성합니다. 구성 프로세스를 시작할 때 이미지의 UUID(Universally Unique Identifier)가 표시됩니다.
```
# composer-cli compose start dpdk_image qcow2
```
작성 프로세스가 완료될 때까지 기다립니다. 다음 단계를 계속 진행하려면 작성 상태가 FINISHED 로 표시되어야 합니다.
```
# composer-cli compose status
```
다음 명령을 입력하여 UUID를 지정하여 qcow2 이미지 파일을 다운로드합니다.
```
# composer-cli compose image <UUID>
```

다음 명령을 실행하여 사용자 지정 스크립트를 생성합니다.

$ cat <<EOF >customize-vm
#!/bin/bash

# Setup hugepages mount
mkdir -p /mnt/huge
echo "hugetlbfs /mnt/huge hugetlbfs defaults,pagesize=1GB 0 0" >> /etc/fstab

# Create vfio-noiommu.conf
echo "options vfio enable_unsafe_noiommu_mode=1" > /etc/modprobe.d/vfio-noiommu.conf

# Enable guest-exec,guest-exec-status on the qemu-guest-agent configuration
sed -i '/^BLACKLIST_RPC=/ { s/guest-exec-status//; s/guest-exec//g }' /etc/sysconfig/qemu-ga
sed -i '/^BLACKLIST_RPC=/ { s/,\+/,/g; s/^,\|,$//g }' /etc/sysconfig/qemu-ga
EOF

virt-customize 툴을 사용하여 이미지 빌더 툴에서 생성한 이미지를 사용자 지정합니다.
```
$ virt-customize -a <UUID>-disk.qcow2 --run=customize-vm --selinux-relabel
```
컨테이너 디스크 이미지를 빌드하는 모든 명령이 포함된 Dockerfile을 생성하려면 다음 명령을 입력합니다.
```
$ cat << EOF > Dockerfile
FROM scratch
COPY --chown=107:107 <UUID>-disk.qcow2 /disk/
EOF
```
다음과 같습니다.
<UUID>-disk.qcow2
qcow2 형식으로 사용자 지정 이미지의 이름을 지정합니다.
다음 명령을 실행하여 컨테이너를 빌드하고 태그를 지정합니다.
```
$ podman build . -t dpdk-rhel:latest
```
다음 명령을 실행하여 컨테이너 디스크 이미지를 클러스터에서 액세스할 수 있는 레지스트리로 푸시합니다.
```
$ podman push dpdk-rhel:latest
```
DPDK 검사 구성 맵의 spec.param.vmUnderTestContainerDiskImage 속성의 컨테이너 디스크 이미지에 대한 링크를 제공합니다.

12.2.5. 스토리지 점검 실행

사전 정의된 점검을 사용하여 OpenShift Container Platform 클러스터 스토리지가 OpenShift Virtualization 워크로드를 실행하도록 최적으로 구성되었는지 확인합니다.

사전 요구 사항

OpenShift CLI(oc)가 설치되어 있습니다.

클러스터 관리자가 다음 예와 같이 스토리지 점검 서비스 계정 및 네임스페이스에 필요한 cluster-reader 권한을 생성했습니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubevirt-storage-checkup-clustereader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-reader
subjects:
- kind: ServiceAccount
  name: storage-checkup-sa
  namespace: <target_namespace> 1

1: 점검을 실행할 네임스페이스입니다.

프로세스

스토리지 점검에 대한 ServiceAccount,Role, RoleBinding 매니페스트 파일을 생성합니다.

예 12.3. 서비스 계정, 역할 및 역할 바인딩 매니페스트의 예

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

대상 네임스페이스에 ServiceAccount,Role, RoleBinding 매니페스트를 적용합니다.
```
$ oc apply -n <target_namespace> -f <storage_sa_roles_rolebinding>.yaml
```

ConfigMap 및 작업 매니페스트 파일을 생성합니다. 구성 맵에는 검사 작업에 대한 입력 매개변수가 포함되어 있습니다.

입력 구성 맵 및 작업 매니페스트 예

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: storage-checkup-config
  namespace: $CHECKUP_NAMESPACE
data:
  spec.timeout: 10m
---
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

대상 네임스페이스에 ConfigMap 및 작업 매니페스트 파일을 적용하여 점검을 실행합니다.
```
$ oc apply -n <target_namespace> -f <storage_configmap_job>.yaml
```

작업이 완료될 때까지 기다립니다.

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

다음 명령을 실행하여 점검 결과를 검토합니다.

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

출력 구성 맵 예(성공)

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
  status.result.defaultStorageClass: trident-nfs 5
  status.result.goldenImagesNoDataSource: <data_import_cron_list> 6
  status.result.goldenImagesNotUpToDate: <data_import_cron_list> 7
  status.result.ocpVersion: 4.16.0
  status.result.storageMissingVolumeSnapshotClass: <storage_class_list>
  status.result.storageProfilesWithEmptyClaimPropertySets: <storage_profile_list> 8
  status.result.storageProfilesWithSpecClaimPropertySets: <storage_profile_list>
  status.result.storageWithRWX: |-
    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> 9
  status.result.vmsWithUnsetEfsStorageClass: <vm_list> 10

1: 검사 성공(true)인지(false)인지 여부를 지정합니다.
2: 검사에 실패하는 경우 실패 이유
3: 검사 시작 시간(RFC 3339 시간 형식)입니다.
4: 검사 완료 시간(RFC 3339 시간 형식)입니다.
5: 기본 스토리지 클래스가 있는지 여부를 지정합니다.
6: 데이터 소스가 준비되지 않은 골든 이미지 목록입니다.
7: 데이터 가져오기 cron이 최신 상태가 아닌 골든 이미지 목록입니다.
8: 알 수 없는 프로비저너가 있는 스토리지 프로필 목록입니다.
9: 가상화 스토리지 클래스가 있는 경우 Ceph RBD 스토리지 클래스를 사용하는 가상 머신 목록입니다.
10: 스토리지 클래스에 GID 및 UID가 설정되지 않은 EFS(Elastic File Store) 스토리지 클래스를 사용하는 가상 머신 목록입니다.

다음 명령을 실행하여 이전에 생성한 작업 및 구성 맵을 삭제합니다.

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

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

선택 사항: 다른 점검을 실행하지 않으려면 ServiceAccount,Role, RoleBinding 매니페스트를 삭제합니다.
```
$ oc delete -f <storage_sa_roles_rolebinding>.yaml
```

12.2. OpenShift Virtualization 클러스터 검사 프레임워크

12.2.1. OpenShift Virtualization 클러스터 검사 프레임워크 정보

12.2.2. 웹 콘솔에서 클러스터 검사 실행

12.2.2.1. 웹 콘솔에서 대기 시간 점검 실행

12.2.2.2. 웹 콘솔에서 스토리지 점검 실행

12.2.3. CLI에서 대기 시간 점검 실행

12.2.4. DPDK 점검

12.2.4.1. DPDK 점검 구성 맵 매개변수

12.2.4.2. RHEL 가상 머신용 컨테이너 디스크 이미지 빌드

12.2.5. 스토리지 점검 실행

12.2.6. 추가 리소스

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 소개

Red Hat legal and privacy links

Red Hat legal and privacy links