10.18. 고급 가상 머신 관리

절차

1. VirtualMachine 매니페스트를 편집하여 VM에 대한 제한을 설정합니다. 예를 들면 다음과 같습니다.

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     name: with-limits
   spec:
     running: false
     template:
       spec:
         domain:
   # ...
           resources:
             requests:
               memory: 128Mi
             limits:
               memory: 256Mi  1

   1

   limits.memory 값이 requests.memory 값보다 큰 100Mi 이상이므로 이 구성이 지원됩니다.

2. VirtualMachine 매니페스트를 저장합니다.

절차

1. 다음 명령을 실행하여 HyperConverged CR을 엽니다.

   $ oc edit hco -n openshift-cnv kubevirt-hyperconverged

2. 다음 예와 같이 spec.certConfig 필드를 편집합니다. 시스템 과부하를 방지하려면 모든 값이 10분 이상인지 확인합니다. golang ParseDuration 형식을 준수하는 문자열로 모든 값을 표현합니다.

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
    name: kubevirt-hyperconverged
    namespace: openshift-cnv
   spec:
     certConfig:
       ca:
         duration: 48h0m0s
         renewBefore: 24h0m0s 1
       server:
         duration: 24h0m0s  2
         renewBefore: 12h0m0s  3

   1

   ca.renewBefore의 값은 ca.duration 값보다 작거나 같아야 합니다.

   2

   server.duration의 값은 ca.duration 값보다 작거나 같아야 합니다.

   3

   server.renewBefore의 값은 server.duration 값보다 작거나 같아야 합니다.

3. YAML 파일을 클러스터에 적용합니다.

절차

1. VirtualMachine 매니페스트 파일을 편집하거나 생성합니다. spec.firmware.bootloader 스탠자를 사용하여 UEFI 모드를 설정합니다.

   보안 부팅이 활성화된 UEFI 모드에서 부팅

   apiversion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     labels:
       special: vm-secureboot
     name: vm-secureboot
   spec:
     template:
       metadata:
         labels:
           special: vm-secureboot
       spec:
         domain:
           devices:
             disks:
             - disk:
                 bus: virtio
               name: containerdisk
           features:
             acpi: {}
             smm:
               enabled: true 1
           firmware:
             bootloader:
               efi:
                 secureBoot: true 2
   ...

   1

   OpenShift Virtualization에서는 UEFI 모드에서 Secure Boot를 사용하려면SMM(시스템 관리 모드)을 활성화해야 합니다.

   2

   OpenShift Virtualization에서는 UEFI 모드를 사용할 때 Secure Boot가 있거나 없는 VM을 지원합니다. Secure Boot가 활성화된 경우 UEFI 모드가 필요합니다. 그러나 Secure Boot를 사용하지 않고 UEFI 모드를 활성화할 수 있습니다.

2. 다음 명령을 실행하여 클러스터에 매니페스트를 적용합니다.

   $ oc create -f <file_name>.yaml

절차

1. 클러스터에서 PXE 네트워크를 구성합니다.

   1. PXE 네트워크 pxe-net-conf에 대한 네트워크 연결 정의 파일을 만듭니다.

      apiVersion: "k8s.cni.cncf.io/v1"
      kind: NetworkAttachmentDefinition
      metadata:
        name: pxe-net-conf
      spec:
        config: '{
          "cniVersion": "0.3.1",
          "name": "pxe-net-conf",
          "plugins": [
            {
              "type": "cnv-bridge",
              "bridge": "br1",
              "vlan": 1 1
            },
            {
              "type": "cnv-tuning" 2
            }
          ]
        }'

      1

      선택 사항: VLAN 태그.

      2

      cnv-tuning 플러그인은 사용자 정의 MAC 주소를 지원합니다.

      참고

      VLAN이 요청된 액세스 포트를 통해 가상 머신 인스턴스가 브리지 br1에 연결됩니다.

2. 이전 단계에서 만든 파일을 사용하여 네트워크 연결 정의를 생성합니다.

   $ oc create -f pxe-net-conf.yaml

3. 인터페이스 및 네트워크에 대한 세부 정보를 포함하도록 가상 머신 인스턴스 구성 파일을 편집합니다.

   1. PXE 서버에 필요한 경우 네트워크 및 MAC 주소를 지정합니다. MAC 주소를 지정하지 않으면 값이 자동으로 할당됩니다.

      인터페이스가 먼저 부팅되도록 bootOrder가 1로 설정되어 있는지 확인하십시오. 이 예에서는 인터페이스가 <pxe-net>이라는 네트워크에 연결되어 있습니다.

      interfaces:
      - masquerade: {}
        name: default
      - bridge: {}
        name: pxe-net
        macAddress: de:00:00:00:00:de
        bootOrder: 1

      참고

      부팅 순서는 인터페이스 및 디스크에 대해 전역적입니다.

   2. 운영 체제가 프로비저닝되면 올바르게 부팅되도록 부팅 장치 번호를 디스크에 할당합니다.

      디스크의 bootOrder 값을 2로 설정합니다.

      devices:
        disks:
        - disk:
            bus: virtio
          name: containerdisk
          bootOrder: 2

   3. 네트워크를 이전에 생성한 네트워크 연결 정의에 연결하도록 지정합니다. 이 시나리오에서 <pxe-net>는 <pxe-net-conf>라는 네트워크 연결 정의에 연결됩니다.

      networks:
      - name: default
        pod: {}
      - name: pxe-net
        multus:
          networkName: pxe-net-conf

4. 가상 머신 인스턴스를 생성합니다.

   $ oc create -f vmi-pxe-boot.yaml

1. 가상 머신 인스턴스가 실행될 때까지 기다립니다.

   $ oc get vmi vmi-pxe-boot -o yaml | grep -i phase
     phase: Running

2. VNC를 사용하여 가상 머신 인스턴스를 확인합니다.

   $ virtctl vnc vmi-pxe-boot

3. 부팅 화면에서 PXE 부팅에 성공했는지 확인합니다.

4. 가상 머신 인스턴스에 로그인합니다.

   $ virtctl console vmi-pxe-boot

5. 가상 머신의 인터페이스 및 MAC 주소를 확인하고, 브릿지에 연결된 인터페이스에 MAC 주소가 지정되었는지 확인합니다. 이 예제에서는 IP 주소 없이 PXE 부팅에 eth1을 사용했습니다. 다른 인터페이스인 eth0은 OpenShift Container Platform에서 IP 주소를 가져왔습니다.

   $ ip addr

절차

1. 가상 머신 구성에서 spec.domain에 resources.requests.memory 및 memory.hugepages.pageSize 매개변수를 추가합니다. 다음 구성 스니펫에서는 가상 머신에서 각 페이지 크기가 1Gi인 총 4Gi의 메모리를 요청합니다.

   kind: VirtualMachine
   ...
   spec:
     domain:
       resources:
         requests:
           memory: "4Gi" 1
       memory:
         hugepages:
           pageSize: "1Gi" 2
   ...

   1

   가상 머신에 대해 요청된 총 메모리 양입니다. 이 값은 페이지 크기로 나눌 수 있어야 합니다.

   2

   각 대규모 페이지의 크기입니다. x86_64 아키텍처에 유효한 값은 1Gi 및 2Mi입니다. 페이지 크기는 요청된 메모리보다 작아야 합니다.

2. 가상 머신 구성을 적용합니다.

   $ oc apply -f <virtual_machine>.yaml

절차

1. OpenShift Container Platform 콘솔 의 사이드 메뉴에서 가상화 VirtualMachine 를 클릭합니다.
2. 가상 머신을 선택하여 VirtualMachine 세부 정보 페이지를 엽니다.
3. Scheduling 탭에서 전용 리소스 옆에 있는 연필 아이콘을 클릭합니다.
4. 전용 리소스(보장된 정책)를 사용하여 이 워크로드 예약을 선택합니다.
5. 저장을 클릭합니다.

절차

1. OpenShift Container Platform 웹 콘솔 의 사이드 메뉴에서 가상화 VirtualMachine 를 클릭합니다.
2. 장치를 할당할 가상 머신을 선택합니다.

3. 세부 정보 탭에서 GPU 장치를 클릭합니다.

   vGPU 장치를 호스트 장치로 추가하는 경우 VNC 콘솔을 사용하여 장치에 액세스할 수 없습니다.

4. GPU 장치 추가를 클릭하고 Name 을 입력하고 장치 이름 목록에서 장치를 선택합니다.
5. 저장을 클릭합니다.
6. YAML 탭을 클릭하여 새 장치가 hostDevices 섹션의 클러스터 구성에 추가되었는지 확인합니다.

절차

1. 다음 콘텐츠를 사용하여 YAML 파일을 생성합니다.

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     labels:
       kubevirt.io/vm: vm2-rhel84-watchdog
     name: <vm-name>
   spec:
     running: false
     template:
       metadata:
        labels:
           kubevirt.io/vm: vm2-rhel84-watchdog
       spec:
         domain:
           devices:
             watchdog:
               name: <watchdog>
               i6300esb:
                 action: "poweroff" 1
   ...

   1

   watchdog 작업 (poweroff, reset, 또는 shutdown)을 지정합니다.

   위의 예제에서는 poweroff 작업을 사용하여 RHEL8 VM에서 i6300esb 워치독 장치를 구성하고 장치를 /dev/watchdog로 노출합니다.

   이제 워치독 바이너리에서 이 장치를 사용할 수 있습니다.

2. 다음 명령을 실행하여 클러스터에 YAML 파일을 적용합니다.

   $ oc apply -f <file_name>.yaml

1. 다음 명령을 실행하여 VM이 워치독 장치에 연결되어 있는지 확인합니다.

   $ lspci | grep watchdog -i

2. 다음 명령 중 하나를 실행하여 워치독이 활성 상태인지 확인합니다.

   • 커널 패닉을 트리거합니다.

     # echo c > /proc/sysrq-trigger

   • 워치독 서비스를 종료합니다.

     # pkill -9 watchdog

절차

1. root 사용자로 watchdog 패키지 및 종속성을 설치합니다.

   # yum install watchdog

2. /etc/watchdog.conf 파일에서 다음 행의 주석을 제거한 후 변경 사항을 저장합니다.

   #watchdog-device = /dev/watchdog

3. 워치독 서비스가 부팅 시 시작되도록 활성화합니다.

   # systemctl enable --now watchdog.service

절차

1. HyperConverged CR(사용자 정의 리소스)을 편집하여 새 storageClassName 을 정의합니다.

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
     name: kubevirt-hyperconverged
   spec:
     dataImportCronTemplates:
     - metadata:
         name: rhel8-image-cron
       spec:
         template:
           spec:
             storageClassName: <appropriate_class_name>
   ...

2. 다음 명령을 실행하여 새 기본 스토리지 클래스를 설정합니다.

   $ oc patch storageclass <current_default_storage_class> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'

   $ oc patch storageclass <appropriate_storage_class> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

절차

1. 다음 명령을 사용하여 편집할 HyperConverged CR을 엽니다.

   $ oc edit -n openshift-cnv HyperConverged

2. HyperConverged CR을 편집하여 dataImportCronTemplates 섹션에 적절한 템플릿 및 부팅 소스를 추가합니다. 예를 들면 다음과 같습니다.

   CentOS 7의 예

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
     name: kubevirt-hyperconverged
   spec:
     dataImportCronTemplates:
     - metadata:
         name: centos7-image-cron
         annotations:
           cdi.kubevirt.io/storage.bind.immediate.requested: "true" 1
       spec:
         schedule: "0 */12 * * *" 2
         template:
           spec:
             source:
               registry: 3
                 url: docker://quay.io/containerdisks/centos:7-2009
             storage:
               resources:
                 requests:
                   storage: 10Gi
         managedDataSource: centos7 4
         retentionPolicy: "None" 5

   1

   volumeBindingMode 가 있는 스토리지 클래스에는 WaitForFirstConsumer 가 설정되어 있는 스토리지 클래스에 필요합니다.

   2

   cron 형식으로 지정된 작업의 스케줄입니다.

   3

   을 사용하여 레지스트리 소스에서 데이터 볼륨을 생성합니다. 노드 docker 캐시를 기반으로 하는 기본 pod pullMethod 및 node pullMethod 를 사용합니다. 노드 Docker 캐시는 Container.Image 를 통해 레지스트리 이미지를 사용할 수 있지만 CDI 가져오기자는 액세스할 수 있는 권한이 없는 경우에 유용합니다.

   4

   사용자 지정 이미지를 사용 가능한 부팅 소스로 감지하려면 이미지의 managedDataSource 의 이름이 VM 템플릿 YAML 파일의 spec.dataVolumeTemplates.spec.sourceRef.name 아래에 있는 템플릿의 DataSource 와 일치해야 합니다.

   5

   cron 작업이 삭제될 때 All 을 사용하여 데이터 볼륨 및 데이터 소스를 유지합니다. None 을 사용하여 cron 작업이 삭제될 때 데이터 볼륨 및 데이터 소스를 삭제합니다.

절차

1. oc get 명령을 사용하여 HyperConverged CR의 dataImportChronTemplates 를 나열합니다.

2. 부팅 소스의 상태를 확인합니다.

   출력 예

   ...
   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   ...
   spec:
     ...
   status: 1
     ...
     dataImportCronTemplates: 2
     - metadata:
         annotations:
           cdi.kubevirt.io/storage.bind.immediate.requested: "true"
         name: centos-7-image-cron
       spec:
         garbageCollect: Outdated
         managedDataSource: centos7
         schedule: 55 8/12 * * *
         template:
           metadata: {}
           spec:
             source:
               registry:
                 url: docker://quay.io/containerdisks/centos:7-2009
             storage:
               resources:
                 requests:
                   storage: 30Gi
           status: {}
       status:
         commonTemplate: true 3
       ...
     - metadata:
         annotations:
           cdi.kubevirt.io/storage.bind.immediate.requested: "true"
         name: user-defined-dic
       spec:
         garbageCollect: Outdated
         managedDataSource: user-defined-centos-stream8
         schedule: 55 8/12 * * *
         template:
           metadata: {}
           spec:
             source:
               registry:
                 pullMethod: node
                 url: docker://quay.io/containerdisks/centos-stream:8
             storage:
               resources:
                 requests:
                   storage: 30Gi
           status: {}
       status: {} 4
   ...

   1

   HyperConverged CR의 status 필드입니다.

   2

   모든 정의된 부팅 소스를 나열하는 dataImportCronTemplates 필드

   3

   시스템 정의 부팅 소스를 나타냅니다.

   4

   사용자 정의 부팅 소스를 나타냅니다.

프로세스

1. OpenShift Container Platform 웹 콘솔에 로그인합니다.

2. Kube Descheduler Operator에 필요한 네임스페이스를 생성합니다.

   1. 관리 네임스페이스로 이동하여 네임스페이스 생성을 클릭합니다.
   2. 이름 필드에 openshift-kube-descheduler-operator 를 입력하고 Labels 필드에 openshift.io/cluster-monitoring=true 를 입력하여 Descheduler 지표를 활성화한 다음 생성을 클릭합니다.

3. Kube Descheduler Operator를 설치합니다.

   1. Operators OperatorHub로 이동합니다.
   2. 필터 박스에 Kube Descheduler Operator를 입력합니다.
   3. Kube Descheduler Operator를 선택하고 설치를 클릭합니다.
   4. Operator 설치 페이지에서 클러스터의 특정 네임스페이스를 선택합니다. 드롭다운 메뉴에서 openshift-kube-descheduler-operator를 선택합니다.
   5. 업데이트 채널 및 승인 전략 값을 원하는 값으로 조정합니다.
   6. 설치를 클릭합니다.

4. Descheduler 인스턴스를 생성합니다.

   1. Operator 설치된 Operator 페이지에서 Kube Descheduler Operator를 클릭합니다.
   2. Kube Descheduler 탭을 선택하고 KubeDescheduler 생성을 클릭합니다.

   3. 필요에 따라 설정을 편집합니다.

      1. 제거를 시뮬레이션하는 대신 Pod를 제거하려면 Mode 필드를 자동으로 변경합니다.

      2. Profiles 섹션을 확장하고 DevPreviewLongLifecycle 를 선택합니다. AffinityAndTaints 프로필은 기본적으로 활성화되어 있습니다.

         중요

         OpenShift Virtualization에서 현재 사용할 수 있는 유일한 프로필은 DevPreviewLongLifecycle 입니다.

절차

1. VM을 시작하기 전에 VirtualMachine CR에 Descheduler.alpha.kubernetes.io/evict 주석을 추가합니다.

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   spec:
     template:
       metadata:
         annotations:
           descheduler.alpha.kubernetes.io/evict: "true"

2. 설치하는 동안 웹 콘솔에서 DevPreviewLongLifecycle 프로필을 아직 설정하지 않은 경우 KubeDescheduler 오브젝트의 spec.profile 섹션에 DevPreviewLongLifecycle 를 지정합니다.

   apiVersion: operator.openshift.io/v1
   kind: KubeDescheduler
   metadata:
     name: cluster
     namespace: openshift-kube-descheduler-operator
   spec:
     deschedulingIntervalSeconds: 3600
     profiles:
     - DevPreviewLongLifecycle
     mode: Predictive 1

   1

   기본적으로 Descheduler는 Pod를 제거하지 않습니다. Pod를 제거하려면 mode 를 Automatic 으로 설정합니다.