지원콘솔개발자평가판 시작연락처

7.13. 고급 가상 머신 관리

7.13.1. 가상 머신의 리소스 할당량 작업

가상 시스템의 리소스 할당량을 생성하고 관리합니다.

7.13.1.1. 가상 머신의 리소스 할당량 제한 설정

요청만 사용하는 리소스 할당량은 VM(가상 머신)에서 자동으로 작동합니다. 리소스 할당량에서 제한을 사용하는 경우 VM에 리소스 제한을 수동으로 설정해야 합니다. 리소스 제한은 리소스 요청보다 100MiB 이상이어야 합니다.

프로세스

  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 매니페스트를 저장합니다.

7.13.1.2. 추가 리소스

7.13.2. 가상 머신용 노드 지정

노드 배치 규칙을 사용하여 특정 노드에 VM(가상 머신)을 배치할 수 있습니다.

7.13.2.1. 가상 머신의 노드 배치 정보

VM(가상 머신)이 적절한 노드에서 실행되도록 노드 배치 규칙을 구성할 수 있습니다. 다음과 같은 경우 이 작업을 수행할 수 있습니다.

  • 여러 개의 VM이 있습니다. 내결함성을 보장하기 위해 서로 다른 노드에서 실행하려고 합니다.
  • 두 개의 가상 머신이 있습니다. 중복 노드 간 라우팅을 방지하기 위해 VM을 동일한 노드에서 실행하려고 합니다.
  • VM에는 사용 가능한 모든 노드에 존재하지 않는 특정 하드웨어 기능이 필요합니다.
  • 노드에 기능을 추가하는 Pod가 있으며 해당 노드에 VM을 배치하여 해당 기능을 사용할 수 있습니다.
참고

가상 머신 배치는 워크로드에 대한 기존 노드 배치 규칙에 의존합니다. 워크로드가 구성 요소 수준의 특정 노드에서 제외되면 해당 노드에 가상 머신을 배치할 수 없습니다.

VirtualMachine 매니페스트의 spec 필드에 다음 규칙 유형을 사용할 수 있습니다.

nodeSelector
이 필드에서 지정하는 키-값 쌍으로 레이블이 지정된 노드에서 가상 머신을 예약할 수 있습니다. 노드에는 나열된 모든 쌍과 정확히 일치하는 라벨이 있어야 합니다.
유사성
더 많은 표현 구문을 사용하여 노드와 가상 머신의 일치 규칙을 설정할 수 있습니다. 예를 들어, 규칙을 엄격한 요구 사항이 아닌 기본 설정으로 지정할 수 있으므로 규칙이 충족되지 않은 경우에도 가상 머신을 예약할 수 있습니다. 가상 머신 배치에는 Pod 유사성, Pod 비유사성 및 노드 유사성이 지원됩니다. VirtualMachine 워크로드 유형이 Pod 오브젝트를 기반으로 하므로 Pod 유사성은 가상 머신에서 작동합니다.
허용 오차

일치하는 테인트가 있는 노드에 가상 머신을 예약할 수 있습니다. 테인트가 노드에 적용되는 경우, 해당 노드는 테인트를 허용하는 가상 머신만 허용합니다.

참고

유사성 규칙은 스케줄링 중에만 적용됩니다. 제약 조건이 더 이상 충족되지 않는 경우 OpenShift Container Platform은 실행 중인 워크로드를 다시 예약하지 않습니다.

7.13.2.2. 노드 배치의 예

다음 예시 YAML 파일 조각에서는 nodePlacement, affinity 및 tolerations 필드를 사용하여 가상 머신의 노드 배치를 사용자 지정합니다.

7.13.2.2.1. 예: nodeSelector를 사용한 VM 노드 배치

이 예에서 가상 시스템에는 example-key-1 = example-value-1 및 example-key-2 = example-value-2 레이블을 모두 포함하는 메타데이터가 있는 노드가 필요합니다.

주의

이 설명에 맞는 노드가 없으면 가상 머신이 예약되지 않습니다.

VM 매니페스트 예

metadata:
  name: example-vm-node-selector
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  template:
    spec:
      nodeSelector:
        example-key-1: example-value-1
        example-key-2: example-value-2
# ...

7.13.2.2.2. 예: Pod 유사성 및 Pod 비유사성을 사용한 VM 노드 배치

이 예에서는 example-key-1 = example-value-1 레이블이 있는 실행 중인 pod가 있는 노드에 VM을 예약해야 합니다. 노드에 실행 중인 Pod가 없는 경우 VM은 예약되지 않습니다.

가능한 경우 example-key-2 = example-value-2 레이블이 있는 Pod가 있는 노드에 VM이 예약되지 않습니다. 그러나 모든 후보 노드에 이 레이블이 있는 Pod가 있는 경우 스케줄러는 이 제약 조건을 무시합니다.

VM 매니페스트 예

metadata:
  name: example-vm-pod-affinity
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  template:
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution: 1
          - labelSelector:
              matchExpressions:
              - key: example-key-1
                operator: In
                values:
                - example-value-1
            topologyKey: kubernetes.io/hostname
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution: 2
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: example-key-2
                  operator: In
                  values:
                  - example-value-2
              topologyKey: kubernetes.io/hostname
# ...

1
requiredDuringSchedulingIgnoredDuringExecution 규칙 유형을 사용하는 경우 제약 조건이 충족되지 않으면 VM이 예약되지 않습니다.
2
preferredDuringSchedulingIgnoredDuringExecution 규칙 유형을 사용하는 경우 필요한 모든 제약 조건이 충족되면 여전히 VM이 예약됩니다.
7.13.2.2.3. 예: 노드 선호도를 사용한 VM 노드 배치

이 예에서 VM은 example.io/example-key = example-value-1 레이블 또는 example.io/example-key = example-value-2 레이블이 있는 노드에 예약해야 합니다. 노드에 레이블 중 하나만 있는 경우 제약 조건이 충족됩니다. 레이블이 모두 없으면 VM이 예약되지 않습니다.

가능한 경우 스케줄러는 example-node-label-key = example-node-label-value 레이블이 있는 노드를 피합니다. 그러나 모든 후보 노드에 이 레이블이 있으면 스케줄러는 이 제약 조건을 무시합니다.

VM 매니페스트 예

metadata:
  name: example-vm-node-affinity
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution: 1
            nodeSelectorTerms:
            - matchExpressions:
              - key: example.io/example-key
                operator: In
                values:
                - example-value-1
                - example-value-2
          preferredDuringSchedulingIgnoredDuringExecution: 2
          - weight: 1
            preference:
              matchExpressions:
              - key: example-node-label-key
                operator: In
                values:
                - example-node-label-value
# ...

1
requiredDuringSchedulingIgnoredDuringExecution 규칙 유형을 사용하는 경우 제약 조건이 충족되지 않으면 VM이 예약되지 않습니다.
2
preferredDuringSchedulingIgnoredDuringExecution 규칙 유형을 사용하는 경우 필요한 모든 제약 조건이 충족되면 여전히 VM이 예약됩니다.
7.13.2.2.4. 예: 허용 오차를 사용한 VM 노드 배치

이 예에서는 가상 머신에 예약된 노드가 key=virtualization:NoSchedule 테인트로 레이블이 지정됩니다. 이 가상 머신에는 tolerations가 일치하므로 테인트된 노드에 예약할 수 있습니다.

참고

해당 테인트가 있는 노드에 스케줄링하는 데 테인트를 허용하는 가상 머신은 필요하지 않습니다.

VM 매니페스트 예

metadata:
  name: example-vm-tolerations
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  tolerations:
  - key: "key"
    operator: "Equal"
    value: "virtualization"
    effect: "NoSchedule"
# ...

7.13.2.3. 추가 리소스

7.13.3. 인증서 교체 구성

기존 인증서를 교체하도록 인증서 교체 매개 변수를 구성합니다.

7.13.3.1. 인증서 교체 구성

웹 콘솔에서 또는 HyperConverged CR(사용자 정의 리소스)에 설치 후 OpenShift Virtualization을 설치하는 동안 이 작업을 수행할 수 있습니다.

절차

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

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

  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 파일을 클러스터에 적용합니다.

7.13.3.2. 인증서 교체 매개변수 문제 해결

기본값이 다음 조건 중 하나와 충돌하지 않는 한 하나 이상의 certConfig 값을 삭제하면 기본값으로 되돌아갑니다.

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

기본값이 이러한 조건과 충돌하면 오류가 발생합니다.

다음 예제에서 server.duration 값을 제거하는 경우 기본값 24h0m0s는 ca.duration 값보다 크므로 지정된 조건과 충돌합니다.

예

certConfig:
   ca:
     duration: 4h0m0s
     renewBefore: 1h0m0s
   server:
     duration: 4h0m0s
     renewBefore: 4h0m0s

이 경우 다음과 같은 오류 메시지가 표시됩니다. 

error: hyperconvergeds.hco.kubevirt.io "kubevirt-hyperconverged" could not be patched: admission webhook "validate-hco.kubevirt.io" denied the request: spec.certConfig: ca.duration is smaller than server.duration

오류 메시지는 첫 번째 충돌만 표시합니다. 진행하기 전에 모든 certConfig 값을 검토합니다.

7.13.4. 기본 CPU 모델 구성

HyperConverged CR(사용자 정의 리소스)에서 defaultCPUModel 설정을 사용하여 클러스터 전체 기본 CPU 모델을 정의합니다.

VM(가상 머신) CPU 모델은 VM 및 클러스터 내의 CPU 모델의 가용성에 따라 다릅니다.

  • VM에 정의된 CPU 모델이 없는 경우:

    • defaultCPUModel 은 클러스터 수준에서 정의된 CPU 모델을 사용하여 자동으로 설정됩니다.

  • VM과 클러스터의 둘 다 정의된 CPU 모델이 있는 경우:

    • VM의 CPU 모델이 우선합니다.

  • VM 및 클러스터에 정의된 CPU 모델이 없는 경우:

    • host-model은 호스트 수준에서 정의된 CPU 모델을 사용하여 자동으로 설정됩니다.

7.13.4.1. 기본 CPU 모델 구성

HyperConverged CR(사용자 정의 리소스)을 업데이트하여 defaultCPUModel 을 구성합니다. OpenShift Virtualization이 실행되는 동안 defaultCPUModel 을 변경할 수 있습니다.

참고

defaultCPUModel 은 대소문자를 구분합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.

프로세스

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

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

  2. defaultCPUModel 필드를 CR에 추가하고 클러스터에 존재하는 CPU 모델의 이름으로 값을 설정합니다. 

    apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
 name: kubevirt-hyperconverged
 namespace: openshift-cnv
spec:
  defaultCPUModel: "EPYC"
  3. YAML 파일을 클러스터에 적용합니다.

7.13.5. 가상 머신에 UEFI 모드 사용

UEFI(Unified Extensible Firmware Interface) 모드에서 VM(가상 머신)을 부팅할 수 있습니다.

7.13.5.1. 가상 머신의 UEFI 모드 정보

레거시 BIOS와 같이 UEFI(Unified Extensible Firmware Interface)는 컴퓨터가 시작될 때 하드웨어 구성 요소 및 운영 체제 이미지 파일을 초기화합니다. UEFI는 BIOS보다 최신 기능 및 사용자 지정 옵션을 지원하므로 부팅 시간이 단축됩니다.

ESP(EFI System Partition)라는 특수 파티션에 저장된 .efi 확장자로 파일에 초기화 및 시작에 대한 모든 정보를 저장합니다. ESP에는 컴퓨터에 설치된 운영 체제용 부트 로더 프로그램도 포함되어 있습니다.

7.13.5.2. UEFI 모드에서 가상 머신 부팅

VirtualMachine 매니페스트를 편집하여 UEFI 모드에서 부팅하도록 가상 머신을 구성할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.

프로세스

  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(System Management Mode)을 활성화해야 합니다.
    2
    OpenShift Virtualization은 UEFI 모드를 사용할 때 Secure Boot가 있거나 없는 VM을 지원합니다. Secure Boot가 활성화된 경우 UEFI 모드가 필요합니다. 그러나 Secure Boot를 사용하지 않고 UEFI 모드를 활성화할 수 있습니다.

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

    $ oc create -f <file_name>.yaml

7.13.6. 가상 머신에 대한 PXE 부팅 구성

OpenShift Virtualization에서는 PXE 부팅 또는 네트워크 부팅을 사용할 수 있습니다. 네트워크 부팅의 경우 로컬로 연결된 스토리지 장치 없이 컴퓨터에서 운영 체제 또는 기타 프로그램을 부팅 및 로드할 수 있습니다. 예를 들어, 새 호스트를 배포할 때 PXE 서버에서 원하는 OS 이미지를 선택할 수 있습니다.

7.13.6.1. 사전 요구 사항

  • Linux 브리지가 연결되어 있어야 합니다.
  • PXE 서버는 브리지와 동일한 VLAN에 연결되어 있어야 합니다.

7.13.6.2. 지정된 MAC 주소로 PXE 부팅

관리자는 PXE 네트워크에 대한 NetworkAttachmentDefinition 오브젝트를 생성한 후 네트워크를 통해 클라이언트를 부팅할 수 있습니다. 그런 다음 가상 머신 인스턴스 구성 파일에서 네트워크 연결 정의를 참조한 후 가상 머신 인스턴스를 시작할 수 있습니다. PXE 서버에 필요한 경우 가상 머신 인스턴스 구성 파일에 MAC 주소를 지정할 수도 있습니다.

사전 요구 사항

  • Linux 브리지가 연결되어 있어야 합니다.
  • PXE 서버는 브리지와 동일한 VLAN에 연결되어 있어야 합니다.

절차

  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

    출력 예

      virtualmachineinstance.kubevirt.io "vmi-pxe-boot" created

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

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

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

    $ virtctl vnc vmi-pxe-boot
  7. 부팅 화면에서 PXE 부팅에 성공했는지 확인합니다.

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

    $ virtctl console vmi-pxe-boot

검증

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

    $ ip addr

    출력 예

    ...
3. eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
   link/ether de:00:00:00:00:de brd ff:ff:ff:ff:ff:ff

7.13.6.3. OpenShift Virtualization 네트워킹 용어집

다음 용어는 OpenShift Virtualization 설명서 전체에서 사용됩니다.

CNI(컨테이너 네트워크 인터페이스(Container Network Interface))
컨테이너 네트워크 연결에 중점을 둔 Cloud Native Computing Foundation 프로젝트입니다. OpenShift Virtualization에서는 CNI 플러그인을 사용하여 기본 Kubernetes 네트워킹 기능을 기반으로 빌드합니다.
Multus
Pod 또는 가상 머신에서 필요한 인터페이스를 사용할 수 있도록 여러 CNI가 존재할 수 있는 "메타" CNI 플러그인입니다.
CRD(사용자 정의 리소스 정의(Custom Resource Definition))
사용자 정의 리소스를 정의할 수 있는 Kubernetes API 리소스 또는 CRD API 리소스를 사용하여 정의한 오브젝트입니다.
네트워크 연결 정의(NAD)
Pod, 가상 머신 및 가상 머신 인스턴스를 하나 이상의 네트워크에 연결할 수 있는 Multus 프로젝트에서 도입한 CRD입니다.
노드 네트워크 구성 정책(NNCP)
nmstate 프로젝트에서 도입한 CRD로, 노드에서 요청된 네트워크 구성을 설명합니다. NodeNetworkConfigurationPolicy 매니페스트를 클러스터에 적용하는 방식으로 인터페이스 추가 및 제거를 포함하여 노드 네트워크 구성을 업데이트합니다.

7.13.7. 가상 머신에서 대규모 페이지 사용

대규모 페이지를 클러스터의 가상 머신 백업 메모리로 사용할 수 있습니다.

7.13.7.1. 사전 요구 사항

7.13.7.2. 대규모 페이지의 기능

메모리는 페이지라는 블록으로 관리됩니다. 대부분의 시스템에서 한 페이지는 4Ki입니다. 1Mi 메모리는 256페이지와 같고 1Gi 메모리는 256,000페이지에 해당합니다. CPU에는 하드웨어에서 이러한 페이지 목록을 관리하는 내장 메모리 관리 장치가 있습니다. TLB(Translation Lookaside Buffer)는 가상-물리적 페이지 매핑에 대한 소규모 하드웨어 캐시입니다. TLB에 하드웨어 명령어로 전달된 가상 주소가 있으면 매핑을 신속하게 확인할 수 있습니다. 가상 주소가 없으면 TLB 누락이 발생하고 시스템에서 소프트웨어 기반 주소 변환 속도가 느려져 성능 문제가 발생합니다. TLB 크기는 고정되어 있으므로 TLB 누락 가능성을 줄이는 유일한 방법은 페이지 크기를 늘리는 것입니다.

대규모 페이지는 4Ki보다 큰 메모리 페이지입니다. x86_64 아키텍처에서 일반적인 대규모 페이지 크기는 2Mi와 1Gi입니다. 다른 아키텍처에서는 크기가 달라집니다. 대규모 페이지를 사용하려면 애플리케이션이 인식할 수 있도록 코드를 작성해야 합니다. THP(투명한 대규모 페이지)에서는 애플리케이션 지식 없이 대규모 페이지 관리를 자동화하려고 하지만 한계가 있습니다. 특히 페이지 크기 2Mi로 제한됩니다. THP에서는 THP 조각 모음 작업으로 인해 메모리 사용률이 높아지거나 조각화가 발생하여 노드에서 성능이 저하될 수 있으며 이로 인해 메모리 페이지가 잠길 수 있습니다. 이러한 이유로 일부 애플리케이션은 THP 대신 사전 할당된 대규모 페이지를 사용하도록 설계(또는 권장)할 수 있습니다.

OpenShift Virtualization에서는 사전 할당된 대규모 페이지를 사용하도록 가상 머신을 구성할 수 있습니다.

7.13.7.3. 가상 머신용 대규모 페이지 구성

가상 머신 구성에 memory.hugepages.pageSize 및 resources.requests.memory 매개변수를 포함하여 사전 할당된 대규모 페이지를 사용하도록 가상 머신을 구성할 수 있습니다.

메모리 요청은 페이지 크기로 나눌 수 있어야합니다. 예를 들면 페이지 크기가 1Gi인 500Mi의 메모리는 요청할 수 없습니다.

참고

호스트와 게스트 OS의 메모리 레이아웃은 관련이 없습니다. 가상 머신 매니페스트에서 요청된 대규모 페이지가 QEMU에 적용됩니다. 게스트 내부의 대규모 페이지는 사용 가능한 가상 머신 인스턴스 메모리 양을 기준으로만 구성할 수 있습니다.

실행 중인 가상 머신을 편집하는 경우 변경 사항을 적용하려면 가상 머신을 재부팅해야 합니다.

사전 요구 사항

  • 노드에 사전 할당된 대규모 페이지가 구성되어 있어야 합니다.

절차

  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

7.13.8. 가상 머신 전용 리소스 사용

성능 향상을 위해 CPU와 같은 노드 리소스를 가상 머신에 전용으로 지정할 수 있습니다.

7.13.8.1. 전용 리소스 정보

가상 머신에 전용 리소스를 사용하면 가상 머신의 워크로드가 다른 프로세스에서 사용하지 않는 CPU에 예약됩니다. 전용 리소스를 사용하면 가상 머신의 성능과 대기 시간 예측 정확도를 개선할 수 있습니다.

7.13.8.2. 사전 요구 사항

  • 노드에 CPU 관리자를 구성해야 합니다. 가상 머신 워크로드를 예약하기 전에 노드에 cpumanager = true 라벨이 있는지 확인하십시오.
  • 가상 머신의 전원을 꺼야 합니다.

7.13.8.3. 가상 머신 전용 리소스 활성화

세부 정보 탭에서 가상 머신 전용 리소스를 활성화합니다. Red Hat 템플릿에서 생성된 가상 머신은 전용 리소스로 구성할 수 있습니다.

프로세스

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

7.13.9. 가상 머신 예약

호환성을 위해 VM의 CPU 모델과 정책 특성이 노드에서 지원하는 CPU 모델 및 정책 특성과 일치하도록 하면 노드에 VM(가상 머신)을 예약할 수 있습니다.

7.13.9.1. 정책 특성

VM(가상 머신)을 노드에 예약할 때 호환성을 위해 일치하는 정책 특성과 CPU 기능을 지정하면 VM을 예약할 수 있습니다. VM에 지정되는 정책 특성에 따라 VM이 노드에서 예약되는 방식이 결정됩니다.

정책 특성설명

force

VM이 노드에 강제로 예약됩니다. 호스트 CPU에서 VM CPU를 지원하지 않는 경우에도 마찬가지입니다.

require

VM이 특정 CPU 모델 및 기능 사양으로 구성되지 않은 경우 VM에 적용되는 기본 정책입니다. 이 기본 정책 특성 또는 다른 정책 특성 중 하나를 사용하여 CPU 노드 검색을 지원하도록 노드를 구성하지 않으면 해당 노드에 VM이 예약되지 않습니다. 호스트 CPU가 VM의 CPU를 지원하거나 하이퍼바이저가 지원되는 CPU 모델을 에뮬레이션할 수 있어야 합니다.

optional

호스트의 물리적 머신 CPU에서 VM을 지원하는 경우 해당 VM이 노드에 추가됩니다.

disable

CPU 노드 검색을 통해 VM을 예약할 수 없습니다.

forbid

호스트 CPU에서 기능을 지원하고 CPU 노드 검색을 사용할 수 있는 경우에도 VM을 예약할 수 없습니다.

7.13.9.2. 정책 특성 및 CPU 기능 설정

각 VM(가상 머신)에 대한 정책 특성 및 CPU 기능을 설정하면 정책 및 기능에 따라 노드에 VM을 예약할 수 있습니다. 설정한 CPU 기능은 호스트 CPU의 지원 여부 또는 하이퍼바이저의 에뮬레이션 여부를 확인하기 위해 검증됩니다.

절차

  • VM 구성 파일의 domain 사양을 편집합니다. 다음 예제에서는 VM(가상 머신)에 대한 CPU 기능 및 require 정책을 설정합니다. 

    apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: myvm
spec:
  template:
    spec:
      domain:
        cpu:
          features:
            - name: apic 1
              policy: require 2
    1
    VM의 CPU 기능 이름입니다.
    2
    VM의 정책 특성입니다.

7.13.9.3. 지원되는 CPU 모델을 사용하여 가상 머신 예약

VM(가상 머신)의 CPU 모델을 구성하여 해당 CPU 모델이 지원되는 노드에 예약할 수 있습니다.

절차

  • 가상 머신 구성 파일의 domain 사양을 편집합니다. 다음 예는 VM에 대해 정의된 특정 CPU 모델을 보여줍니다. 

    apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: myvm
spec:
  template:
    spec:
      domain:
        cpu:
          model: Conroe 1
    1
    VM의 CPU 모델입니다.

7.13.9.4. 호스트 모델을 사용하여 가상 머신 예약

VM(가상 머신)의 CPU 모델이 host-model로 설정되어 있으면 VM은 예약된 노드의 CPU 모델을 상속합니다.

절차

  • VM 구성 파일의 domain 사양을 편집합니다. 다음 예제에서는 가상 머신에 지정된 host-model을 보여줍니다. 

    apiVersion: kubevirt/v1alpha3
kind: VirtualMachine
metadata:
  name: myvm
spec:
  template:
    spec:
      domain:
        cpu:
          model: host-model 1
    1
    예약된 노드의 CPU 모델을 상속하는 VM입니다.

7.13.9.5. 사용자 정의 스케줄러를 사용하여 가상 머신 예약

사용자 정의 스케줄러를 사용하여 노드에 VM(가상 머신)을 예약할 수 있습니다.

사전 요구 사항

  • 보조 스케줄러가 클러스터에 대해 구성되어 있습니다.

프로세스

  • VirtualMachine 매니페스트를 편집하여 사용자 지정 스케줄러를 VM 구성에 추가합니다. 예를 들면 다음과 같습니다. 

    apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: vm-fedora
spec:
  running: true
  template:
    spec:
      schedulerName: my-scheduler 1
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
# ...
    1
    사용자 정의 스케줄러의 이름입니다. schedulerName 값이 기존 스케줄러와 일치하지 않으면 virt-launcher Pod는 지정된 스케줄러를 찾을 때까지 Pending 상태로 유지됩니다.

검증

  • virt-launcher Pod 이벤트를 확인하여 VM이 VirtualMachine 매니페스트에 지정된 사용자 정의 스케줄러를 사용하고 있는지 확인합니다.

    1. 다음 명령을 입력하여 클러스터의 Pod 목록을 확인합니다. 

      $ oc get pods

      출력 예

      NAME                             READY   STATUS    RESTARTS   AGE
virt-launcher-vm-fedora-dpc87    2/2     Running   0          24m

    2. 다음 명령을 실행하여 Pod 이벤트를 표시합니다. 

      $ oc describe pod virt-launcher-vm-fedora-dpc87

      출력의 From 필드 값은 스케줄러 이름이 VirtualMachine 매니페스트에 지정된 사용자 정의 스케줄러와 일치하는지 확인합니다.

      출력 예

      [...]
Events:
  Type    Reason     Age   From              Message
  ----    ------     ----  ----              -------
  Normal  Scheduled  21m   my-scheduler  Successfully assigned default/virt-launcher-vm-fedora-dpc87 to node01
[...]

추가 리소스

7.13.10. PCI 패스스루 구성

PCI(Peripheral Component Interconnect) 패스스루 기능을 사용하면 VM(가상 머신)에서 하드웨어 장치에 액세스하고 관리할 수 있습니다. PCI 패스스루가 구성되면 PCI 장치는 게스트 운영 체제에 물리적으로 연결된 것처럼 작동합니다.

클러스터 관리자는 oc CLI(명령줄 인터페이스)를 사용하여 클러스터에서 사용할 수 있는 호스트 장치를 노출하고 관리할 수 있습니다.

7.13.10.1. GPU 패스스루를 위한 노드 준비

GPU 피연산자가 GPU 패스스루용으로 지정한 작업자 노드에 배포되지 않도록 할 수 있습니다.

7.13.10.1.1. NVIDIA GPU 피연산자가 노드에 배포되지 않도록 방지

클러스터에서 NVIDIA GPU Operator 를 사용하는 경우 nvidia.com/gpu.deploy.operands=false 레이블을 GPU 또는 vGPU 피연산자에 대해 구성하지 않으려는 노드에 적용할 수 있습니다. 이 레이블은 GPU 또는 vGPU 피연산자를 구성하는 Pod 생성을 방지하고 이미 존재하는 경우 Pod를 종료합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있어야 합니다.

프로세스

  • 다음 명령을 실행하여 노드에 레이블을 지정합니다. 

    $ oc label node <node_name> nvidia.com/gpu.deploy.operands=false 1
    1
    & lt;node_name >을 NVIDIA GPU 피연산자를 설치하지 않으려는 노드의 이름으로 바꿉니다.

검증

  1. 다음 명령을 실행하여 라벨이 노드에 추가되었는지 확인합니다. 

    $ oc describe node <node_name>

  2. 선택 사항: GPU 피연산자가 이전에 노드에 배포된 경우 제거를 확인합니다.

    1. 다음 명령을 실행하여 nvidia-gpu-operator 네임스페이스에서 Pod의 상태를 확인합니다. 

      $ oc get pods -n nvidia-gpu-operator

      출력 예

      NAME                             READY   STATUS        RESTARTS   AGE
gpu-operator-59469b8c5c-hw9wj    1/1     Running       0          8d
nvidia-sandbox-validator-7hx98   1/1     Running       0          8d
nvidia-sandbox-validator-hdb7p   1/1     Running       0          8d
nvidia-sandbox-validator-kxwj7   1/1     Terminating   0          9d
nvidia-vfio-manager-7w9fs        1/1     Running       0          8d
nvidia-vfio-manager-866pz        1/1     Running       0          8d
nvidia-vfio-manager-zqtck        1/1     Terminating   0          9d

    2. Terminating 상태의 Pod가 제거될 때까지 Pod 상태를 모니터링합니다. 

      $ oc get pods -n nvidia-gpu-operator

      출력 예

      NAME                             READY   STATUS    RESTARTS   AGE
gpu-operator-59469b8c5c-hw9wj    1/1     Running   0          8d
nvidia-sandbox-validator-7hx98   1/1     Running   0          8d
nvidia-sandbox-validator-hdb7p   1/1     Running   0          8d
nvidia-vfio-manager-7w9fs        1/1     Running   0          8d
nvidia-vfio-manager-866pz        1/1     Running   0          8d

7.13.10.2. PCI 패스스루를 위한 호스트 장치 준비

7.13.10.2.1. PCI 패스스루를 위한 호스트 장치 준비 정보

CLI를 사용하여 PCI 패스스루를 위한 호스트 장치를 준비하려면 MachineConfig 오브젝트를 생성하고 커널 인수를 추가하여 IOMMU(Input-Output Memory Management Unit)를 활성화합니다. PCI 장치를 VFIO(가상 기능 I/O) 드라이버에 연결한 다음 HyperConverged CR(사용자 정의 리소스)의 allowedHostDevices 필드를 편집하여 클러스터에 노출합니다. OpenShift Virtualization Operator를 처음 설치할 때 permittedHostDevices 목록이 비어 있습니다.

CLI를 사용하여 클러스터에서 PCI 호스트 장치를 제거하려면 HyperConverged CR에서 PCI 장치 정보를 삭제합니다.

7.13.10.2.2. IOMMU 드라이버를 활성화하려면 커널 인수 추가

커널에서 IOMMU 드라이버를 활성화하려면 MachineConfig 오브젝트를 생성하고 커널 인수를 추가합니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있어야 합니다.
  • CPU 하드웨어는 Intel 또는 AMD입니다.
  • BIOS에서 Directed I/O 확장 또는 AMD IOMMU에 대한 Intel Virtualization Technology를 활성화했습니다.

절차

  1. 커널 인수를 식별하는 MachineConfig 오브젝트를 만듭니다. 다음 예제에서는 Intel CPU에 대한 커널 인수를 보여줍니다. 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker 1
  name: 100-worker-iommu 2
spec:
  config:
    ignition:
      version: 3.2.0
  kernelArguments:
      - intel_iommu=on 3
# ...
    1
    새 커널 인수를 작업자 노드에만 적용합니다.
    2
    name은 머신 구성 및 그 용도 중 이 커널 인수의 순위(100)를 나타냅니다. AMD CPU가 있는 경우 커널 인수를 amd_iommu=on으로 지정합니다.
    3
    Intel CPU의 커널 인수를 intel_iommu로 식별합니다.

  2. 새 MachineConfig 오브젝트를 만듭니다. 

    $ oc create -f 100-worker-kernel-arg-iommu.yaml

검증

  • 새 MachineConfig 오브젝트가 추가되었는지 확인합니다. 

    $ oc get MachineConfig
7.13.10.2.3. VFIO 드라이버에 PCI 장치 바인딩

PCI 장치를 VFIO(Virtual Function I/O) 드라이버에 바인딩하려면 각 장치에서 vendor-ID 및 device-ID 값을 가져오고 값으로 목록을 생성합니다. MachineConfig 오브젝트에 이 목록을 추가합니다. MachineConfig Operator는 PCI 장치가 있는 노드에 /etc/modprobe.d/vfio.conf를 생성하고 PCI 장치를 VFIO 드라이버에 바인딩합니다.

사전 요구 사항

  • CPU에 IOMMU를 사용하도록 커널 인수를 추가했습니다.

절차

  1. lspci 명령을 실행하여 PCI 장치의 vendor-ID 및 device-ID를 가져옵니다. 

    $ lspci -nnv | grep -i nvidia

    출력 예

    02:01.0 3D controller [0302]: NVIDIA Corporation GV100GL [Tesla V100 PCIe 32GB] [10de:1eb8] (rev a1)

  2. Virtual config 파일 100-worker-vfiopci.bu를 생성하여 PCI 장치를 VFIO 드라이버에 바인딩합니다.

    참고

    Butane에 대한 자세한 내용은 “Butane 을 사용하여 머신 구성 생성”을 참조하십시오.

    예

    variant: openshift
version: 4.14.0
metadata:
  name: 100-worker-vfiopci
  labels:
    machineconfiguration.openshift.io/role: worker 1
storage:
  files:
  - path: /etc/modprobe.d/vfio.conf
    mode: 0644
    overwrite: true
    contents:
      inline: |
        options vfio-pci ids=10de:1eb8 2
  - path: /etc/modules-load.d/vfio-pci.conf 3
    mode: 0644
    overwrite: true
    contents:
      inline: vfio-pci

    1
    새 커널 인수를 작업자 노드에만 적용합니다.
    2
    단일 장치를 VFIO 드라이버에 바인딩하려면 이전에 결정한 vendor-ID 값 (10de) 및 device-ID 값 (1eb8) 을 지정합니다. 공급업체 및 장치 정보를 사용하여 여러 장치 목록을 추가할 수 있습니다.
    3
    작업자 노드에서 vfio-pci 커널 모듈을 로드하는 파일입니다.

  3. Butane을 사용하여 작업자 노드로 전달할 구성이 포함된 MachineConfig 오브젝트 파일 100-worker-vfiopci.yaml을 생성합니다. 

    $ butane 100-worker-vfiopci.bu -o 100-worker-vfiopci.yaml

  4. 작업자 노드에 MachineConfig 오브젝트를 적용합니다. 

    $ oc apply -f 100-worker-vfiopci.yaml

  5. MachineConfig 오브젝트가 추가되었는지 확인합니다. 

    $ oc get MachineConfig

    출력 예

    NAME                             GENERATEDBYCONTROLLER                      IGNITIONVERSION  AGE
00-master                        d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
00-worker                        d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
01-master-container-runtime      d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
01-master-kubelet                d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
01-worker-container-runtime      d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
01-worker-kubelet                d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
100-worker-iommu                                                            3.2.0            30s
100-worker-vfiopci-configuration                                            3.2.0            30s

검증

  • VFIO 드라이버가 로드되었는지 확인합니다. 

    $ lspci -nnk -d 10de:

    출력은 VFIO 드라이버가 사용 중인지 확인합니다.

    출력 예

    04:00.0 3D controller [0302]: NVIDIA Corporation GP102GL [Tesla P40] [10de:1eb8] (rev a1)
        Subsystem: NVIDIA Corporation Device [10de:1eb8]
        Kernel driver in use: vfio-pci
        Kernel modules: nouveau

7.13.10.2.4. CLI를 사용하여 클러스터에 PCI 호스트 장치 노출

클러스터에 PCI 호스트 장치를 노출하려면 PCI 장치에 대한 세부 정보를 HyperConverged CR(사용자 정의 리소스)의 spec.permittedHostDevices 배열에 추가합니다.

절차

  1. 다음 명령을 실행하여 기본 편집기에서 HyperConverged CR을 편집합니다. 

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

  2. spec.permittedHostDevices.pciHostDevices 어레이에 PCI 장치 정보를 추가합니다. 예를 들면 다음과 같습니다.

    설정 파일 예

    apiVersion: hco.kubevirt.io/v1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  permittedHostDevices: 1
    pciHostDevices: 2
    - pciDeviceSelector: "10DE:1DB6" 3
      resourceName: "nvidia.com/GV100GL_Tesla_V100" 4
    - pciDeviceSelector: "10DE:1EB8"
      resourceName: "nvidia.com/TU104GL_Tesla_T4"
    - pciDeviceSelector: "8086:6F54"
      resourceName: "intel.com/qat"
      externalResourceProvider: true 5
# ...

    1
    클러스터에서 사용할 수 있는 호스트 장치입니다.
    2
    노드에서 사용할 수 있는 PCI 장치 목록입니다.
    3
    vendor-ID 및 device-ID는 PCI 장치를 식별해야 합니다.
    4
    PCI 호스트 장치의 이름입니다.
    5
    선택 사항: 이 필드를 true 로 설정하면 리소스가 외부 장치 플러그인에서 제공됨을 나타냅니다. OpenShift Virtualization에서는 클러스터에서 이 장치를 사용할 수 있지만 할당 및 모니터링을 외부 장치 플러그인으로 남겨 둡니다.
    참고

    위의 예제 스니펫은 이름이 nvidia.com/GV100GL_Tesla_V100이고 nvidia.com/TU104GL_Tesla_T4가 HyperConverged CR에서 허용된 호스트 장치 목록에 추가된 두 개의 PCI 호스트 장치를 보여줍니다. 이러한 장치는 OpenShift Virtualization에서 작동하도록 테스트 및 검증되었습니다.

  3. 변경 사항을 저장하고 편집기를 종료합니다.

검증

  • 다음 명령을 실행하여 PCI 호스트 장치가 노드에 추가되었는지 확인합니다. 예제 출력에서는 각각nvidia.com/GV100GL_Tesla_V100, nvidia.com/TU104GL_Tesla_T4, intel.com/qat 리소스 이름과 연결된 하나의 장치가 있음을 보여줍니다. 

    $ oc describe node <node_name>

    출력 예

    Capacity:
  cpu:                            64
  devices.kubevirt.io/kvm:        110
  devices.kubevirt.io/tun:        110
  devices.kubevirt.io/vhost-net:  110
  ephemeral-storage:              915128Mi
  hugepages-1Gi:                  0
  hugepages-2Mi:                  0
  memory:                         131395264Ki
  nvidia.com/GV100GL_Tesla_V100   1
  nvidia.com/TU104GL_Tesla_T4     1
  intel.com/qat:                  1
  pods:                           250
Allocatable:
  cpu:                            63500m
  devices.kubevirt.io/kvm:        110
  devices.kubevirt.io/tun:        110
  devices.kubevirt.io/vhost-net:  110
  ephemeral-storage:              863623130526
  hugepages-1Gi:                  0
  hugepages-2Mi:                  0
  memory:                         130244288Ki
  nvidia.com/GV100GL_Tesla_V100   1
  nvidia.com/TU104GL_Tesla_T4     1
  intel.com/qat:                  1
  pods:                           250

7.13.10.2.5. CLI를 사용하여 클러스터에서 PCI 호스트 장치 제거

클러스터에서 PCI 호스트 장치를 제거하려면 HyperConverged CR(사용자 정의 리소스)에서 해당 장치의 정보를 삭제합니다.

절차

  1. 다음 명령을 실행하여 기본 편집기에서 HyperConverged CR을 편집합니다. 

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

  2. 적절한 장치의 pciDeviceSelector,resourceName 및 externalResourceProvider (해당되는 경우) 필드를 삭제하여 spec.permittedHostDevices.pciHostDevices 어레이에서 PCI 장치 정보를 제거합니다. 이 예에서는 intel.com/qat 리소스가 삭제되었습니다.

    설정 파일 예

    apiVersion: hco.kubevirt.io/v1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  permittedHostDevices:
    pciHostDevices:
    - pciDeviceSelector: "10DE:1DB6"
      resourceName: "nvidia.com/GV100GL_Tesla_V100"
    - pciDeviceSelector: "10DE:1EB8"
      resourceName: "nvidia.com/TU104GL_Tesla_T4"
# ...

  3. 변경 사항을 저장하고 편집기를 종료합니다.

검증

  • 다음 명령을 실행하여 PCI 호스트 장치가 노드에서 제거되었는지 확인합니다. 예제 출력에서는 intel.com/qat 리소스 이름과 연결된 장치가 0개 있음을 보여줍니다. 

    $ oc describe node <node_name>

    출력 예

    Capacity:
  cpu:                            64
  devices.kubevirt.io/kvm:        110
  devices.kubevirt.io/tun:        110
  devices.kubevirt.io/vhost-net:  110
  ephemeral-storage:              915128Mi
  hugepages-1Gi:                  0
  hugepages-2Mi:                  0
  memory:                         131395264Ki
  nvidia.com/GV100GL_Tesla_V100   1
  nvidia.com/TU104GL_Tesla_T4     1
  intel.com/qat:                  0
  pods:                           250
Allocatable:
  cpu:                            63500m
  devices.kubevirt.io/kvm:        110
  devices.kubevirt.io/tun:        110
  devices.kubevirt.io/vhost-net:  110
  ephemeral-storage:              863623130526
  hugepages-1Gi:                  0
  hugepages-2Mi:                  0
  memory:                         130244288Ki
  nvidia.com/GV100GL_Tesla_V100   1
  nvidia.com/TU104GL_Tesla_T4     1
  intel.com/qat:                  0
  pods:                           250

7.13.10.3. PCI 패스스루의 가상 머신 구성

PCI 장치를 클러스터에 추가하고 나면 가상 머신에 할당할 수 있습니다. 이제 PCI 장치를 가상 머신에 물리적으로 연결된 것처럼 사용할 수 있습니다.

7.13.10.3.1. 가상 머신에 PCI 장치 할당

PCI 장치를 클러스터에서 사용할 수 있는 경우 가상 머신에 할당하고 PCI 패스스루를 활성화할 수 있습니다.

절차

  • 가상 시스템에 PCI 장치를 호스트 장치로 할당합니다.

    예

    apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  domain:
    devices:
      hostDevices:
      - deviceName: nvidia.com/TU104GL_Tesla_T4 1
        name: hostdevices1

    1
    호스트 장치로 클러스터에서 허용되는 PCI 장치의 이름입니다. 가상 시스템은 이 호스트 장치에 액세스할 수 있습니다.

검증

  • 다음 명령을 사용하여 가상 시스템에서 호스트 장치를 사용할 수 있는지 확인합니다. 

    $ lspci -nnk | grep NVIDIA

    출력 예

    $ 02:01.0 3D controller [0302]: NVIDIA Corporation GV100GL [Tesla V100 PCIe 32GB] [10de:1eb8] (rev a1)

7.13.10.4. 추가 리소스

7.13.11. 가상 GPU 구성

GPU(그래픽 처리 장치) 카드가 있는 경우 OpenShift Virtualization은 VM(가상 머신)에 할당할 수 있는 가상 GPU(vGPU)를 자동으로 생성할 수 있습니다.

7.13.11.1. OpenShift Virtualization에서 가상 GPU 사용 정보

일부 GPU(그래픽 처리 장치) 카드에서는 vGPU(가상 GPU) 생성을 지원합니다. 관리자가 HyperConverged CR(사용자 정의 리소스)에 구성 세부 정보를 제공하는 경우 OpenShift Virtualization은 vGPU 및 기타 중재 장치를 자동으로 생성할 수 있습니다. 이 자동화는 대규모 클러스터에 특히 유용합니다.

참고

기능 및 지원 세부 사항은 하드웨어 벤더의 설명서를 참조하십시오.

중재된 장치
하나 이상의 가상 장치로 구성된 물리적 장치입니다. vGPU는 미디어 장치(mdev)의 유형입니다. 물리적 GPU의 성능은 가상 장치로 나뉩니다. 하나 이상의 VM(가상 머신)에 중재된 장치를 할당할 수 있지만 게스트 수는 GPU와 호환되어야 합니다. 일부 GPU는 여러 게스트를 지원하지 않습니다.

7.13.11.2. 중재된 장치를 위한 호스트 준비

중재된 장치를 구성하려면IOMMU(Input-Output Memory Management Unit) 드라이버를 활성화해야 합니다.

7.13.11.2.1. IOMMU 드라이버를 활성화하려면 커널 인수 추가

커널에서 IOMMU 드라이버를 활성화하려면 MachineConfig 오브젝트를 생성하고 커널 인수를 추가합니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있어야 합니다.
  • CPU 하드웨어는 Intel 또는 AMD입니다.
  • BIOS에서 Directed I/O 확장 또는 AMD IOMMU에 대한 Intel Virtualization Technology를 활성화했습니다.

프로세스

  1. 커널 인수를 식별하는 MachineConfig 오브젝트를 만듭니다. 다음 예제에서는 Intel CPU에 대한 커널 인수를 보여줍니다. 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker 1
  name: 100-worker-iommu 2
spec:
  config:
    ignition:
      version: 3.2.0
  kernelArguments:
      - intel_iommu=on 3
# ...
    1
    새 커널 인수를 작업자 노드에만 적용합니다.
    2
    name은 머신 구성 및 그 용도 중 이 커널 인수의 순위(100)를 나타냅니다. AMD CPU가 있는 경우 커널 인수를 amd_iommu=on으로 지정합니다.
    3
    Intel CPU의 커널 인수를 intel_iommu로 식별합니다.

  2. 새 MachineConfig 오브젝트를 만듭니다. 

    $ oc create -f 100-worker-kernel-arg-iommu.yaml

검증

  • 새 MachineConfig 오브젝트가 추가되었는지 확인합니다. 

    $ oc get MachineConfig

7.13.11.3. NVIDIA GPU Operator 구성

NVIDIA GPU Operator를 사용하여 OpenShift Virtualization에서 GPU 가속 VM(가상 머신)을 실행하기 위한 작업자 노드를 프로비저닝할 수 있습니다.

참고

NVIDIA GPU Operator는 NVIDIA에서만 지원됩니다. 자세한 내용은 Red Hat 지식베이스 의 NVIDIA에서 지원 받기를 참조하십시오.

7.13.11.3.1. NVIDIA GPU Operator 사용 정보

NVIDIA GPU Operator를 OpenShift Virtualization과 함께 사용하여 GPU 지원 가상 머신(VM)을 실행하기 위해 작업자 노드를 신속하게 프로비저닝할 수 있습니다. NVIDIA GPU Operator는 OpenShift Container Platform 클러스터에서 NVIDIA GPU 리소스를 관리하고 GPU 워크로드를 위한 노드를 준비할 때 필요한 작업을 자동화합니다.

애플리케이션 워크로드를 GPU 리소스에 배포하려면 먼저 컴퓨팅 통합 장치 아키텍처(CUDA), Kubernetes 장치 플러그인, 컨테이너 런타임 및 자동 노드 레이블 지정 및 모니터링과 같은 기타 기능을 활성화하는 NVIDIA 드라이버와 같은 구성 요소를 설치해야 합니다. 이러한 작업을 자동화하면 인프라의 GPU 용량을 빠르게 확장할 수 있습니다. NVIDIA GPU Operator는 특히 복잡한 인공 지능 및 머신 러닝(AI/ML) 워크로드를 쉽게 프로비저닝할 수 있습니다.

7.13.11.3.2. 중재된 장치를 구성하는 옵션

NVIDIA GPU Operator를 사용할 때 중재된 장치를 구성하는 데 사용할 수 있는 두 가지 방법이 있습니다. Red Hat 테스트 방법은 OpenShift Virtualization 기능을 사용하여 중재된 장치를 예약하는 반면 NVIDIA 방법은 GPU Operator만 사용합니다.

NVIDIA GPU Operator를 사용하여 중재된 장치 구성
이 방법은 NVIDIA GPU Operator만 사용하여 중재된 장치를 구성합니다. 이 방법을 사용하려면 NVIDIA 문서의 OpenShift Virtualization과 함께 NVIDIA GPU Operator 를 참조하십시오.
OpenShift Virtualization을 사용하여 중재된 장치 구성

Red Hat에서 테스트하는 이 방법은 OpenShift Virtualization의 기능을 사용하여 중재된 장치를 구성합니다. 이 경우 NVIDIA GPU Operator는 NVIDIA vGPU Manager를 사용하여 드라이버를 설치하는 데만 사용됩니다. GPU Operator는 중재된 장치를 구성하지 않습니다.

OpenShift Virtualization 방법을 사용하는 경우 NVIDIA 문서에 따라 GPU Operator를 계속 구성합니다. 그러나 이 방법은 다음과 같은 방법으로 NVIDIA 문서와 다릅니다.

  • HyperConverged CR(사용자 정의 리소스)에서 기본 disableMDEVConfiguration: false 설정을 덮어쓰지 않아야 합니다.

    중요

    NVIDIA 문서에 설명된 대로 이 기능 게이트를 설정하면 OpenShift Virtualization이 중재된 장치를 구성할 수 없습니다.

  • 다음 예와 일치하도록 ClusterPolicy 매니페스트를 구성해야 합니다.

    매니페스트 예

    kind: ClusterPolicy
apiVersion: nvidia.com/v1
metadata:
  name: gpu-cluster-policy
spec:
  operator:
    defaultRuntime: crio
    use_ocp_driver_toolkit: true
    initContainer: {}
  sandboxWorkloads:
    enabled: true
    defaultWorkload: vm-vgpu
  driver:
    enabled: false 1
  dcgmExporter: {}
  dcgm:
    enabled: true
  daemonsets: {}
  devicePlugin: {}
  gfd: {}
  migManager:
    enabled: true
  nodeStatusExporter:
    enabled: true
  mig:
    strategy: single
  toolkit:
    enabled: true
  validator:
    plugin:
      env:
        - name: WITH_WORKLOAD
          value: "true"
  vgpuManager:
    enabled: true 2
    repository: <vgpu_container_registry> 3
    image: <vgpu_image_name>
    version: nvidia-vgpu-manager
  vgpuDeviceManager:
    enabled: false 4
    config:
      name: vgpu-devices-config
      default: default
  sandboxDevicePlugin:
    enabled: false 5
  vfioManager:
    enabled: false 6

    1
    이 값을 false 로 설정합니다. VM에는 필요하지 않습니다.
    2
    이 값을 true 로 설정합니다. VM과 함께 vGPU를 사용하는 데 필요합니다.
    3
    & lt;vgpu_container_registry&gt;를 레지스트리 값으로 바꿉니다.
    4
    OpenShift Virtualization에서 NVIDIA GPU Operator 대신 중재된 장치를 구성할 수 있도록 하려면 이 값을 false 로 설정합니다.
    5
    vGPU 장치를 kubelet으로 검색 및 알리지 않으려면 이 값을 false 로 설정합니다.
    6
    vfio-pci 드라이버를 로드하지 않으려면 이 값을 false 로 설정합니다. 대신 OpenShift Virtualization 설명서에 따라 PCI 패스스루를 구성합니다.

추가 리소스

7.13.11.4. vGPU가 노드에 할당되는 방법

각 물리적 장치에 대해 OpenShift Virtualization은 다음 값을 구성합니다.

  • 단일 mdev 유형입니다.
  • 선택한 mdev 유형의 최대 인스턴스 수입니다.

클러스터 아키텍처는 장치를 생성하고 노드에 할당하는 방법에 영향을 미칩니다.

노드당 여러 카드가 있는 대규모 클러스터

유사한 vGPU 유형을 지원할 수 있는 여러 카드가 있는 노드에서는 관련 장치 유형이 라운드 로빈 방식으로 생성됩니다. 예를 들면 다음과 같습니다. 

# ...
mediatedDevicesConfiguration:
  mediatedDeviceTypes:
  - nvidia-222
  - nvidia-228
  - nvidia-105
  - nvidia-108
# ...

이 시나리오에서 각 노드에는 두 개의 카드가 있으며 둘 다 다음 vGPU 유형을 지원합니다. 

nvidia-105
# ...
nvidia-108
nvidia-217
nvidia-299
# ...

OpenShift Virtualization은 각 노드에서 다음 vGPU를 생성합니다.

  • 첫 번째 카드에 nvidia-105 유형의 16 vGPU입니다.
  • 두 번째 카드에 nvidia-108 유형의 vGPUs입니다.
하나의 노드에는 하나 이상의 요청된 vGPU 유형을 지원하는 단일 카드가 있습니다.

OpenShift Virtualization은 mediatedDeviceTypes 목록에서 먼저 제공되는 지원되는 유형을 사용합니다.

예를 들어 노드 카드의 카드는 nvidia-223 및 nvidia-224 를 지원합니다. 다음 mediatedDeviceTypes 목록이 구성되어 있습니다. 

# ...
mediatedDevicesConfiguration:
  mediatedDeviceTypes:
  - nvidia-22
  - nvidia-223
  - nvidia-224
# ...

이 예제에서 OpenShift Virtualization은 nvidia-223 유형을 사용합니다.

7.13.11.5. 중재된 장치 관리

미디어된 장치를 가상 머신에 할당하려면 먼저 장치를 생성하고 클러스터에 노출해야 합니다. 또한 중재된 장치를 재구성하고 제거할 수 있습니다.

7.13.11.5.1. 미디어된 장치 생성 및 노출

관리자는 조정된 장치를 생성하고 HyperConverged CR(사용자 정의 리소스)을 편집하여 클러스터에 노출할 수 있습니다.

사전 요구 사항

  • IOMMU(Input-Output Memory Management Unit) 드라이버를 활성화했습니다.

  • 하드웨어 벤더가 드라이버를 제공하는 경우 중재된 장치를 생성하려는 노드에 설치한 것입니다.

절차

  1. 다음 명령을 실행하여 기본 편집기에서 HyperConverged CR을 엽니다. 

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

    예 7.2. 중재 장치가 구성된 구성 파일의 예

    apiVersion: hco.kubevirt.io/v1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  mediatedDevicesConfiguration:
    mediatedDeviceTypes:
    - nvidia-231
    nodeMediatedDeviceTypes:
    - mediatedDeviceTypes:
      - nvidia-233
      nodeSelector:
        kubernetes.io/hostname: node-11.redhat.com
  permittedHostDevices:
    mediatedDevices:
    - mdevNameSelector: GRID T4-2Q
      resourceName: nvidia.com/GRID_T4-2Q
    - mdevNameSelector: GRID T4-8Q
      resourceName: nvidia.com/GRID_T4-8Q
# ...

  2. spec.mediatedDevicesConfiguration 스탠자에 추가하여 중재된 장치를 생성합니다.

    YAML 스니펫의 예

    # ...
spec:
  mediatedDevicesConfiguration:
    mediatedDeviceTypes: 1
    - <device_type>
    nodeMediatedDeviceTypes: 2
    - mediatedDeviceTypes: 3
      - <device_type>
      nodeSelector: 4
        <node_selector_key>: <node_selector_value>
# ...

    1
    필수: 클러스터에 대한 글로벌 설정을 구성합니다.
    2
    선택 사항: 특정 노드 또는 노드 그룹에 대한 글로벌 구성을 재정의합니다. 글로벌 mediatedDeviceTypes 구성과 함께 사용해야 합니다.
    3
    nodeMediatedDeviceTypes 를 사용하는 경우 필수 항목입니다. 지정된 노드에 대한 글로벌 mediatedDeviceTypes 구성을 재정의합니다.
    4
    nodeMediatedDeviceTypes 를 사용하는 경우 필수 항목입니다. 키:값 쌍을 포함해야 합니다.
    중요

    OpenShift Virtualization 4.14 이전에는 mediatedDeviceTypes 필드의 이름이 mediatedDevicesTypes 로 지정되었습니다. 중재된 장치를 구성할 때 올바른 필드 이름을 사용해야 합니다.

  3. 클러스터에 노출하려는 장치의 이름 선택기 및 리소스 이름 값을 식별합니다. 다음 단계에서 이러한 값을 HyperConverged CR에 추가합니다.

    1. 다음 명령을 실행하여 resourceName 값을 찾습니다. 

      $ oc get $NODE -o json \
  | jq '.status.allocatable \
    | with_entries(select(.key | startswith("nvidia.com/"))) \
    | with_entries(select(.value != "0"))'

    2. /sys/bus/pci/devices/<slot>:<bus>:<domain>.<function>/mdev_supported_types/<type>/name 을 확인하여 mdevNameSelector 값을 찾습니다.

      예를 들어 nvidia-231 유형의 이름 파일에는 선택기 문자열 GRID T4-2Q 가 포함되어 있습니다. GRID T4-2Q 를 mdevNameSelector 값으로 사용하면 노드에서 nvidia-231 유형을 사용할 수 있습니다.

  4. HyperConverged CR의 spec.permittedHostDevices.mediatedDevices 스탠자에 mdevNameSelector 및 resourceName 값을 추가하여 중재된 장치를 클러스터에 노출합니다.

    YAML 스니펫의 예

    # ...
  permittedHostDevices:
    mediatedDevices:
    - mdevNameSelector: GRID T4-2Q 1
      resourceName: nvidia.com/GRID_T4-2Q 2
# ...

    1
    호스트에서 이 값에 매핑되는 중재된 장치를 노출합니다.
    2
    노드에 할당된 리소스 이름과 일치합니다.
  5. 변경 사항을 저장하고 편집기를 종료합니다.

검증

  • 선택 사항: 다음 명령을 실행하여 장치가 특정 노드에 추가되었는지 확인합니다. 

    $ oc describe node <node_name>
7.13.11.5.2. 미디어된 장치 변경 및 제거 정보

여러 가지 방법으로 중재된 장치를 재구성하거나 제거할 수 있습니다.

  • HyperConverged CR을 편집하고 mediatedDeviceTypes 스탠자의 내용을 변경합니다.
  • node MediatedDeviceTypes 노드 선택기와 일치하는 노드 레이블을 변경합니다.

  • HyperConverged CR의 spec.mediatedDevicesConfiguration 및 spec.permittedHostDevices 스탠자에서 장치 정보를 제거합니다.

    참고

    spec.permittedHostDevices 스탠자에서 장치 정보를 제거하지 않고 spec.mediatedDevicesConfiguration 스탠자에서 장치 정보를 제거하는 경우 동일한 노드에서 새 중재된 장치 유형을 생성할 수 없습니다. 중재된 장치를 올바르게 제거하려면 두 스탠자 모두에서 장치 정보를 제거합니다.

7.13.11.5.3. 클러스터에서 중재된 장치 제거

클러스터에서 중재된 장치를 제거하려면 HyperConverged CR(사용자 정의 리소스)에서 해당 장치의 정보를 삭제합니다.

프로세스

  1. 다음 명령을 실행하여 기본 편집기에서 HyperConverged CR을 편집합니다. 

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

  2. HyperConverged CR의 spec.mediatedDevicesConfiguration 및 spec.permittedHostDevices 스탠자에서 장치 정보를 제거합니다. 두 항목을 모두 제거하면 나중에 동일한 노드에 중재된 장치 유형을 만들 수 있습니다. 예를 들면 다음과 같습니다.

    설정 파일 예

    apiVersion: hco.kubevirt.io/v1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  mediatedDevicesConfiguration:
    mediatedDeviceTypes: 1
      - nvidia-231
  permittedHostDevices:
    mediatedDevices: 2
    - mdevNameSelector: GRID T4-2Q
      resourceName: nvidia.com/GRID_T4-2Q

    1
    nvidia-231 장치 유형을 제거하려면 mediatedDeviceTypes 배열에서 삭제합니다.
    2
    GRID T4-2Q 장치를 제거하려면 mdevNameSelector 필드와 해당 resourceName 필드를 삭제합니다.
  3. 변경 사항을 저장하고 편집기를 종료합니다.

7.13.11.6. 중재된 장치 사용

하나 이상의 가상 머신에 중재된 장치를 할당할 수 있습니다.

7.13.11.6.1. CLI를 사용하여 VM에 vGPU 할당

가상 GPU(vGPU)와 같은 중재된 장치를 VM(가상 머신)에 할당합니다.

사전 요구 사항

  • 중재된 장치는 HyperConverged 사용자 정의 리소스에서 구성됩니다.
  • VM이 중지되었습니다.

프로세스

  • VirtualMachine 매니페스트의 spec.domain.devices.gpus 스탠자를 편집하여 VM(가상 머신)에 중재된 장치를 할당합니다.

    가상 머신 매니페스트의 예

    apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  domain:
    devices:
      gpus:
      - deviceName: nvidia.com/TU104GL_Tesla_T4 1
        name: gpu1 2
      - deviceName: nvidia.com/GRID_T4-2Q
        name: gpu2

    1
    중재된 장치와 관련된 리소스 이름입니다.
    2
    VM에서 장치를 식별하는 이름입니다.

검증

  • 장치를 가상 머신에서 사용할 수 있는지 확인하려면 다음 명령을 실행하여 VirtualMachine 매니페스트의 deviceName 값으로 < device_name >을 대체합니다. 

    $ lspci -nnk | grep <device_name>
7.13.11.6.2. 웹 콘솔을 사용하여 VM에 vGPU 할당

OpenShift Container Platform 웹 콘솔을 사용하여 가상 머신에 가상 GPU를 할당할 수 있습니다.

참고

사용자 지정 템플릿 또는 YAML 파일에서 생성된 가상 머신에 하드웨어 장치를 추가할 수 있습니다. 특정 운영 체제에 대해 사전 제공 부팅 소스 템플릿에 장치를 추가할 수 없습니다.

사전 요구 사항

  • vGPU는 클러스터에서 중재된 장치로 구성됩니다.

    • 클러스터에 연결된 장치를 보려면 사이드 메뉴에서 컴퓨팅 하드웨어 장치를 클릭합니다.
  • VM이 중지되었습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔의 사이드 메뉴에서 가상화 VirtualMachines 를 클릭합니다.
  2. 장치를 할당할 VM을 선택합니다.
  3. 세부 정보 탭에서 GPU 장치를 클릭합니다.
  4. GPU 장치 추가를 클릭합니다.
  5. 이름 필드에 식별 값을 입력합니다.
  6. 장치 이름 목록에서 VM에 추가할 장치를 선택합니다.
  7. 저장을 클릭합니다.

검증

  • 장치가 VM에 추가되었는지 확인하려면 YAML 탭을 클릭하고 VirtualMachine 구성을 검토합니다. 중재된 장치는 spec.domain.devices 스탠자에 추가됩니다.

7.13.11.7. 추가 리소스

7.13.12. 가상 머신에서 Descheduler 제거 활성화

Descheduler를 사용하여 Pod를 더 적절한 노드에 다시 예약할 수 있도록 Pod를 제거할 수 있습니다. Pod가 가상 머신인 경우 Pod 제거로 인해 가상 머신이 다른 노드로 실시간 마이그레이션됩니다.

중요

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

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

7.13.12.1. Descheduler 프로필

기술 프리뷰 DevPreviewLongLifecycle 프로필을 사용하여 가상 머신에서 Descheduler를 활성화합니다. 현재 OpenShift Virtualization에서 사용할 수 있는 유일한 Descheduler 프로필입니다. 적절한 스케줄링을 보장하기 위해 예상 로드에 대한 CPU 및 메모리 요청이 있는 VM을 생성합니다.

DevPreviewLongLifecycle

이 프로필은 노드 간 리소스 사용량의 균형을 유지하고 다음 전략을 활성화합니다.

  • RemovePodsHavingTooManyRestarts: 컨테이너가 너무 여러 번 다시 시작된 Pod와 모든 컨테이너(Init Containers 포함)에서 재시작 횟수가 100을 초과하는 Pod를 제거합니다. VM 게스트 운영 체제를 다시 시작해도 이 수가 늘어나지 않습니다.

  • LowNodeUtilization: 활용도가 낮은 노드가 있는 경우 활용도가 높은 노드에서 Pod를 제거합니다. 제거된 Pod의 대상 노드는 스케줄러에 의해 결정됩니다.

    • 모든 임계값(CPU, 메모리, Pod 수)에서 사용량이 20% 미만인 경우 노드는 활용도가 낮은 것으로 간주됩니다.
    • 모든 임계값(CPU, 메모리, Pod 수)에서 사용량이 50%를 초과하면 노드는 과도하게 사용되는 것으로 간주됩니다.

7.13.12.2. Descheduler 설치

Descheduler는 기본적으로 사용할 수 없습니다. Descheduler를 활성화하려면 OperatorHub에서 Kube Descheduler Operator를 설치하고 Descheduler 프로필을 한 개 이상 활성화해야 합니다.

기본적으로 Descheduler는 예측 모드에서 실행되므로 Pod 제거만 시뮬레이션합니다. Pod 제거를 수행하려면 Descheduler가 자동으로 모드를 변경해야 합니다.

중요

클러스터에서 호스팅되는 컨트롤 플레인을 활성화한 경우 사용자 정의 우선순위 임계값을 설정하여 호스팅된 컨트롤 플레인 네임스페이스의 Pod가 제거될 가능성을 줄입니다. 호스팅된 컨트롤 플레인 우선순위 클래스 클래스의 가장 낮은 우선 순위 값(100000000)이 있으므로 우선순위 임계값 클래스 이름을 hypershift-control-plane 로 설정합니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 OpenShift Container Platform에 로그인되어 있습니다.
  • OpenShift Container Platform 웹 콘솔에 액세스합니다.

프로세스

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

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

    1. 관리 네임스페이스로 이동하여 네임스페이스 생성을 클릭합니다.
    2. 이름 필드에 openshift-kube-descheduler-operator 를 입력하고 라벨 필드에 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 입니다.

나중에 OpenShift CLI(oc)를 사용하여 Descheduler의 프로필 및 설정을 구성할 수도 있습니다.

7.13.12.3. VM(가상 머신)에서 Descheduler 제거 활성화

Descheduler가 설치되면 VirtualMachine CR(사용자 정의 리소스)에 주석을 추가하여 VM에서 Descheduler 제거를 활성화할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔 또는 OpenShift CLI(oc)에 Descheduler를 설치합니다.
  • VM이 실행되고 있지 않은지 확인합니다.

프로세스

  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 으로 설정합니다.

이제 VM에서 Descheduler가 활성화됩니다.

7.13.12.4. 추가 리소스

7.13.13. 가상 머신의 고가용성 정보

실패한 노드를 수동으로 삭제하여 VM 장애 조치를 트리거하거나 노드 수정을 구성하여 VM(가상 머신)의 고가용성을 활성화할 수 있습니다.

실패한 노드 수동 삭제

노드가 실패하고 머신 상태 점검이 클러스터에 배포되지 않으면 runStrategy: Always 가 구성된 가상 머신이 정상 노드로 자동 재배치되지 않습니다. VM 장애 조치를 트리거하려면 Node 오브젝트를 수동으로 삭제해야 합니다.

가상 머신 장애 조치를 트리거하는 데 실패한 노드 삭제 를 참조하십시오.

노드 수정 구성

OperatorHub에서 Self Node Remediation Operator를 설치하고 머신 상태 점검 또는 노드 수정 검사를 활성화하여 노드 수정을 구성할 수 있습니다.

노드 수정, 펜싱 및 유지 관리에 대한 자세한 내용은 Workload Availability for Red Hat OpenShift 설명서를 참조하십시오.

7.13.14. 가상 머신 컨트롤 플레인 튜닝

OpenShift Virtualization에서는 컨트롤 플레인 수준에서 다음과 같은 튜닝 옵션을 제공합니다.

  • 고정 QPS 및 버스트 속도를 사용하여 수백 개의 VM(가상 머신)을 하나의 일괄 처리로 생성하는 highBurst 프로필
  • 워크로드 유형에 따른 마이그레이션 설정 조정

7.13.14.1. highBurst 프로필 구성

highBurst 프로필을 사용하여 하나의 클러스터에서 다수의 VM(가상 머신)을 생성하고 유지 관리합니다.

프로세스

  • 다음 패치를 적용하여 highBurst 튜닝 정책 프로필을 활성화합니다. 

    $ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \
  --type=json -p='[{"op": "add", "path": "/spec/tuningPolicy", \
  "value": "highBurst"}]'

검증

  • 다음 명령을 실행하여 highBurst 튜닝 정책 프로필이 활성화되었는지 확인합니다. 

    $ oc get kubevirt.kubevirt.io/kubevirt-kubevirt-hyperconverged \
  -n openshift-cnv -o go-template --template='{{range $config, \
  $value := .spec.configuration}} {{if eq $config "apiConfiguration" \
  "webhookConfiguration" "controllerConfiguration" "handlerConfiguration"}} \
  {{"\n"}} {{$config}} = {{$value}} {{end}} {{end}} {{"\n"}}

7.13.15. 컴퓨팅 리소스 할당

OpenShift Virtualization에서 VM(가상 머신)에 할당된 컴퓨팅 리소스는 보장된 CPU 또는 시간 초과된 CPU 공유에 의해 지원됩니다.

보장된 CPU(CPU 예약이라고도 함)는 CPU 코어 또는 스레드를 특정 워크로드에 전용하므로 다른 워크로드에서 사용할 수 없습니다. 보장된 CPU를 VM에 할당하면 VM이 예약된 물리적 CPU에만 액세스할 수 있습니다. VM이 보장된 CPU를 사용하도록 전용 리소스를 활성화합니다.

시간 초과된 CPU는 각 워크로드에 대해 공유 물리적 CPU의 시간 슬라이스를 전용으로 사용합니다. VM 생성 중 또는 VM이 오프라인인 경우 슬라이스 크기를 지정할 수 있습니다. 기본적으로 각 vCPU는 물리적 CPU 시간 100밀리초 또는 1/10초를 받습니다.

CPU 예약 유형은 인스턴스 유형 또는 VM 구성에 따라 다릅니다.

7.13.15.1. CPU 리소스 과다 할당

시간 분할을 사용하면 여러 가상 CPU(vCPU)가 단일 물리적 CPU를 공유할 수 있습니다. 이를 CPU 과다 할당 이라고 합니다. 보장된 VM은 오버 커밋할 수 없습니다.

VM에 CPU를 할당할 때 성능보다 VM 밀도를 우선시하도록 CPU 과다 할당을 구성합니다. vCPU의 CPU 초과 커밋이 증가하면 지정된 노드에 더 많은 VM이 적합합니다.

7.13.15.2. CPU 할당 비율 설정

CPU 할당 Ratio는 vCPU를 물리적 CPU의 시간 슬라이스에 매핑하여 오버 커밋 정도를 지정합니다.

예를 들어 10:1의 매핑 또는 비율은 시간 슬라이스를 사용하여 10개의 가상 CPU를 1개의 물리적 CPU에 매핑합니다.

각 물리적 CPU에 매핑된 기본 vCPU 수를 변경하려면 HyperConverged CR에서 vmiCPUAllocationRatio 값을 설정합니다. Pod CPU 요청은 vCPU 수를 CPU 할당 비율의 reciprocal으로 곱하여 계산됩니다. 예를 들어 vmiCPUAllocationRatio 가 10으로 설정된 경우 OpenShift Virtualization은 해당 VM에 대해 Pod에서 10배 더 적은 CPU를 요청합니다.

프로세스

HyperConverged CR에서 vmiCPUAllocationRatio 값을 설정하여 노드 CPU 할당 비율을 정의합니다.

  1. 다음 명령을 실행하여 기본 편집기에서 HyperConverged CR을 엽니다. 

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

  2. vmiCPUAllocationRatio:를 설정합니다. 

    ...
spec:
  resourceRequirements:
    vmiCPUAllocationRatio: 1 1
# ...
    1
    vmiCPUAllocationRatio 를 1 로 설정하면 Pod에 대해 최대 vCPU가 요청됩니다.

7.13.15.3. 추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.