OpenShift Virtualization
OpenShift Virtualization 설치, 사용법, 릴리스 정보
초록
1장. OpenShift Virtualization 정보
OpenShift Virtualization의 기능 및 지원 범위에 대해 알아보십시오.
1.1. OpenShift Virtualization으로 수행할 수 있는 작업
OpenShift Virtualization은 컨테이너 워크로드와 함께 가상 머신 워크로드를 실행하고 관리할 수 있는 OpenShift Container Platform의 애드온입니다.
OpenShift Virtualization은 Kubernetes 사용자 정의 리소스를 통해 OpenShift Container Platform 클러스터에 새 오브젝트를 추가하여 가상화 작업을 지원합니다. 다음과 같은 가상화 작업이 지원됩니다.
- Linux 및 Windows 가상 머신 생성 및 관리
- 다양한 콘솔 및 CLI 툴을 통해 가상 머신에 연결
- 기존 가상 머신 가져오기 및 복제
- 가상 머신에 연결된 네트워크 인터페이스 컨트롤러 및 스토리지 디스크 관리
- 노드 간 실시간 가상 머신 마이그레이션
향상된 웹 콘솔에서 제공되는 그래픽 포털을 통해 OpenShift Container Platform 클러스터 컨테이너 및 인프라와 함께 가상화 리소스를 관리할 수 있습니다.
OpenShift Virtualization은 OCS(OpenShift 컨테이너 스토리지)로 테스트되었으며 최상의 경험을 위해 OCS 기능과 함께 사용하도록 설계되었습니다.
OVN-Kubernetes 또는 OpenShiftSDN 기본 CNI(컨테이너 네트워크 인터페이스) 네트워크 공급자와 함께 OpenShift Virtualization을 사용할 수 있습니다.
1.1.1. OpenShift Virtualization 지원 클러스터 버전
OpenShift Container Platform 4.6 클러스터에서 사용할 수 있도록 OpenShift Virtualization 2.5가 지원됩니다.
2장. OpenShift Virtualization 릴리스 정보
2.1. Red Hat OpenShift Virtualization 정보
Red Hat OpenShift Virtualization을 사용하면 기존 VM(가상 머신)을 컨테이너와 함께 실행되는 OpenShift Container Platform으로 가져와 네이티브 Kubernetes 오브젝트로 관리할 수 있습니다.
OpenShift Virtualization은 로고로 표시됩니다.
OVN-Kubernetes 또는 OpenShiftSDN 기본 CNI(컨테이너 네트워크 인터페이스) 네트워크 공급자와 함께 OpenShift Virtualization을 사용할 수 있습니다.
OpenShift Virtualization으로 수행할 수 있는 작업에 대해 자세히 알아보십시오.
2.1.1. OpenShift Virtualization 지원 클러스터 버전
OpenShift Container Platform 4.6 클러스터에서 사용할 수 있도록 OpenShift Virtualization 2.5가 지원됩니다.
2.1.2. 지원되는 게스트 운영 체제
OpenShift Virtualization 게스트에서는 다음 운영 체제를 사용할 수 있습니다.
- Red Hat Enterprise Linux 6, 7, 8
- Microsoft Windows Server 2012 R2, 2016, 2019
- Microsoft Windows 10.
OpenShift Virtualization과 함께 제공되는 다른 운영 체제 템플릿은 지원되지 않습니다.
2.2. 새로운 기능 및 변경된 기능
OpenShift Virtualization은 Microsoft의 Windows SVVP(서버 가상화 유효성 검사 프로그램)에서 Windows Server 워크로드를 실행하도록 인증되었습니다.
SVVP 인증은 다음에 적용됩니다.
- Red Hat Enterprise Linux CoreOS 8 작업자(Microsoft SVVP 카탈로그에서는 RHEL CoreOS 8의 Red Hat OpenShift Container Platform 4라고 함)
- Intel 및 AMD CPU
OpenShift Virtualization 2.5에는 QEMU 게스트 에이전트 데이터를 관리하기 위해 새로운
virtctl
명령 3개가 추가되었습니다.-
virtctl fslist <vmi_name>
은 게스트 머신에서 사용 가능한 전체 파일 시스템 목록을 반환합니다. -
virtctl guestosinfo <vmi_name>
은 운영 체제에 대한 게스트 에이전트 정보를 반환합니다. -
virtctl userlist <vmi_name>
은 게스트 머신에 로그인한 전체 사용자 목록을 반환합니다.
-
-
이제 웹 콘솔의 명령줄 툴 페이지에서
virtctl
클라이언트를 다운로드할 수 있습니다.
- 이제 Red Hat Virtualization에서 SR-IOV(Single Root I/O Virtualization) 네트워크 인터페이스가 있는 가상 머신을 가져올 수 있습니다.
2.2.1. 네트워킹
-
nmstate와 함께 지원되는 본딩 모드에
mode=2 balance-xor
및mode=4 802.3ad
가 포함됩니다.
2.2.2. 스토리지
- CDI(Containerized Data Importer)가 이제 컨테이너 이미지 레지스트리에서 더 빠른 속도로 컨테이너 디스크 스토리지 볼륨을 가져오고 더 효율적으로 스토리지 용량을 할당할 수 있습니다. CDI는 HTTP 끝점에서 가져오는 데 걸리는 시간과 거의 동일한 시간 내에 레지스트리에서 컨테이너 디스크 이미지를 가져올 수 있습니다. 디스크를 디스크 이미지와 동일한 크기의 PVC(영구 볼륨 클레임)로 가져와 기본 스토리지를 더 효율적으로 사용할 수 있습니다.
DataVolume에서 관리하는 VM(가상 머신) 디스크를 준비할 때 문제를 더 쉽게 진단하고 해결할 수 있습니다.
- 비동기 이미지 업로드의 경우 디스크 이미지의 가상 크기가 대상 DataVolume보다 크면 연결이 종료되기 전에 오류 메시지가 반환됩니다.
-
oc describe dv
명령을 사용하여 PVC (PersistentVolumeClaim
)Bound
조건 변경이나 전송 실패를 모니터링할 수 있습니다.Status:Phase
필드의 값이Succeeded
이면 DataVolume을 사용할 준비가 된 것입니다.
전원이 꺼진(오프라인 상태의) VM에 대해 CLI에서 VM(가상 머신) 스냅샷을 생성, 복원, 삭제할 수 있습니다. OpenShift Virtualization은 다음에서 오프라인 VM 스냅샷을 지원합니다.
- Red Hat OpenShift 컨테이너 스토리지
- Kubernetes Volume Snapshot API를 지원하는 CSI(Container Storage Interface) 드라이버가 있는 기타 스토리지 공급자
-
이제 스마트 복제를 사용하여 가상 디스크를 효율적이고 빠르게 복제할 수 있습니다. PVC(
PersistentVolumeClaim
) 소스로 DataVolume을 생성하면 스마트 복제가 자동으로 발생합니다. 스마트 복제를 사용하려면 스토리지 공급자가 CSI Snapshots API를 지원해야 합니다.
2.2.3. 웹 콘솔
가상 머신이 실행 중인 경우 웹 콘솔의 다음 필드 및 탭에 대한 변경 사항을 적용하려면 가상 머신을 재시작해야 합니다.
- 세부 정보 탭의 부팅 순서 및 플레이버
- 네트워크 인터페이스 탭
- 디스크 탭
환경 탭
페이지 상단의 보류 중인 변경 사항 배너에는 가상 머신이 재시작될 때 적용되는 모든 변경 사항 목록이 표시됩니다.
- 별도의 창에서 가상 머신 콘솔을 열 수 있습니다.
- OpenShift Container Platform 웹 콘솔을 사용하여 기본 OS 이미지를 생성하고 자동으로 업로드할 수 있습니다. 기본 OS 이미지는 운영 체제 및 모든 운영 체제의 구성 설정(예: 드라이버)이 포함된 부팅 가능한 디스크입니다. 기본 OS 이미지를 사용하여 특정 구성으로 부팅 가능한 가상 머신을 생성합니다.
- 웹 콘솔을 사용하여 새 영구 볼륨 클레임에 가상 머신 이미지 파일을 업로드할 수 있습니다.
- QEMU 게스트 에이전트가 가상 머신에서 실행되는 경우, 웹 콘솔을 사용하여 가상 머신, 사용자, 파일 시스템, 보조 네트워크에 대한 정보를 볼 수 있습니다.
2.3. 주요 기술 변경 사항
- 블록 기반 스토리지가 있는 VM을 OpenShift Virtualization으로 가져올 수 있습니다.
HCO(HyperConverged Operator), CDI(Containerized Data Importer), HPP(Hostpath Provisioner), VM 가져오기 사용자 정의 리소스가 API 버전
v1beta1
로 이동되었습니다. 이러한 구성 요소의 각 API 버전은 다음과 같습니다.hco.kubevirt.io/v1beta1
cdi.kubevirt.io/v1beta1
hostpathprovisioner.kubevirt.io/v1beta1
v2v.kubevirt.io/v1beta1
-
템플릿에서 생성된 가상 머신에 대해 기본
cloud-init
사용자 암호가 자동으로 생성됩니다.
- 호스트 지원 복제를 사용할 때 더 효율적인 압축 알고리즘으로 인해 가상 머신 디스크를 더 빠른 속도로 복제할 수 있습니다.
- 베어 메탈 배포 시 사용자 프로비저닝 OpenShift Container Platform 설치에서 노드가 실패하면 가상 머신이 다른 노드에서 자동으로 재시작되지 않습니다. 자동 재시작은 머신 상태 확인을 사용하는 설치 관리자 프로비저닝 설치에만 지원됩니다. OpenShift Virtualization을 위한 클러스터 구성에 대해 자세히 알아보십시오.
2.4. 확인된 문제
- OpenShift Container Platform 클러스터에서 OVN-Kubernetes를 기본 CNI(Container Network Interface) 공급자로 사용하는 경우, OVN-Kubernetes의 호스트 네트워크 토폴로지 변경으로 인해 호스트의 기본 인터페이스에 Linux 브리지 또는 본딩을 연결할 수 없습니다. 해결 방법으로 호스트에 연결된 보조 네트워크 인터페이스를 사용하거나 OpenShift SDN 기본 CNI 공급자로 전환할 수 있습니다. (BZ#1887456)
-
웹 콘솔을 사용하여 VMware VDDK(가상 디스크 개발 키트) 이미지를
openshift-cnv/v2v-vmware
구성 맵에 추가하면 관리 리소스라는 오류 메시지가 표시됩니다. 이 오류는 무시해도 됩니다. 저장을 클릭하여 구성 맵을 저장합니다. (BZ#1884538) - 노드가 제거될 때(예: OpenShift Container Platform 클러스터 업그레이드 중 노드가 유지보수 모드에 배치된 경우) 가상 머신이 한 번이 아닌 두 번 마이그레이션됩니다. (BZ#1888790)
- 업그레이드 후 운영 체제 워크로드당 템플릿이 두 개 이상 있을 수 있습니다. 기본 운영 체제(OS) 이미지 기능을 사용하여 복제된 PVC에서 Microsoft Windows 가상 머신을 생성할 때 OS에 올바른 워크로드 값이 정의되어 있어야 합니다. 웹 콘솔에 (사용 가능한 소스) 라벨이 표시되는 경우에도 잘못된 Workload 값을 선택하면 기본 OS 이미지를 사용할 수 없습니다. 기본 OS 이미지는 최신 템플릿에 연결되어 있지만 마법사는 기본 OS 이미지를 지원하도록 구성되지 않은 이전 템플릿을 사용할 수 있습니다. Windows 2010 시스템은 Desktop 의 워크로드 값만 지원하며 Windows 2012, Windows 2016 및 Windows 2019는 Server 의 워크로드 값만 지원합니다. (BZ#1907183)
-
특정 네임스페이스의 가상 머신에 KubeMacPool 라벨을 적용하고
io
특성을 사용하여 해당 네임스페이스에 대한 MAC 주소 풀을 활성화하면io
특성 구성이 VM에 대해 유지되지 않습니다. 해결 방법으로 VM에io
특성을 사용하지 마십시오. 또는 네임스페이스에 대해 KubeMacPool을 비활성화할 수 있습니다. (BZ#1869527)
- OpenShift Virtualization 2.5로 업그레이드하면 운영 체제, 워크로드, 플레이버의 각 조합에 대해 이전 버전과 최신 버전의 공통 템플릿을 모두 사용할 수 있습니다. 공통 템플릿을 사용하여 가상 머신을 생성할 때는 최신 버전의 템플릿을 사용해야 합니다. 문제를 방지하려면 이전 버전을 무시하십시오. (BZ#1859235)
실시간으로 마이그레이션할 수 없는 가상 머신을 실행하면 OpenShift Container Platform 클러스터 업그레이드가 차단될 수 있습니다. 여기에는 hostpath-provisioner 스토리지 또는 SR-IOV 네트워크 인터페이스를 사용하는 가상 머신이 포함됩니다. (BZ#1858777)
해결 방법으로 클러스터를 업그레이드하는 동안 전원이 꺼지도록 가상 머신을 재구성할 수 있습니다. 가상 머신 구성 파일의
spec
섹션에서 다음을 수행합니다.-
evictionStrategy를 삭제합니다. LiveMigrate
필드. 제거 전략을 구성하는 방법에 대한 자세한 내용은 가상 머신 제거 전략 구성을 참조하십시오. -
runStrategy
필드를Always
로 설정합니다.
-
-
알 수 없는 이유로
containerDisk
볼륨 유형의 메모리 사용량이 메모리 제한을 초과할 때까지 점진적으로 증가할 수 있습니다. 이 문제를 해결하려면 VM을 재시작하십시오. (BZ#1855067)
웹 콘솔에서 OpenShift Virtualization Operator의 구독 채널을 편집하려고 할 때 서브스크립션 개요의 채널 버튼을 클릭하면 JavaScript 오류가 발생하는 경우가 있습니다. (BZ#1796410)
해결 방법으로 다음
oc
패치 명령을 실행하여 CLI에서 OpenShift Virtualization 2.5로의 업그레이드 프로세스를 트리거합니다.$ export TARGET_NAMESPACE=openshift-cnv CNV_CHANNEL=2.5 && oc patch -n "${TARGET_NAMESPACE}" $(oc get subscription -n ${TARGET_NAMESPACE} --no-headers -o name) --type='json' -p='[{"op": "replace", "path": "/spec/channel", "value":"'${CNV_CHANNEL}'"}, {"op": "replace", "path": "/spec/installPlanApproval", "value":"Automatic"}]'
이 명령을 실행하면 해당 구독이 채널
2.5
로 업그레이드되고 자동 업데이트가 활성화됩니다.
노드에 다른 CPU 모델이 있으면 실시간 마이그레이션이 실패합니다. 노드의 물리적 CPU 모델이 같은 경우에도 마이크로코드 업데이트로 인한 변화가 미치는 영향은 동일합니다. 기본 설정에서 실시간 마이그레이션과 호환되지 않는 호스트 CPU 통과 동작을 트리거하기 때문입니다. (BZ#1760028)
이 문제를 해결하려면 다음 예와 같이
kubevirt-config
ConfigMap에서 기본 CPU 모델을 설정하십시오.참고실시간 마이그레이션을 지원하는 가상 머신을 시작하기 전에 이러한 변경을 수행해야 합니다.
다음 명령을 실행하여 편집할
kubevirt-config
ConfigMap을 엽니다.$ oc edit configmap kubevirt-config -n openshift-cnv
ConfigMap을 편집합니다.
kind: ConfigMap metadata: name: kubevirt-config data: default-cpu-model: "<cpu-model>" 1
- 1
<cpu-model>
을 실제 CPU 모델 값으로 바꿉니다. 모든 노드에 대해oc describe node <node>
를 실행한 후cpu-model-<name>
라벨에서 이 값을 확인할 수 있습니다. 모든 노드에 존재하는 CPU 모델을 선택합니다.
OpenShift Virtualization에서는
oc adm drain
또는kubectl drain
을 실행하여 트리거되는 노드 드레이닝을 안정적으로 확인할 수 없습니다. OpenShift Virtualization이 배포된 클러스터의 노드에서 이러한 명령을 실행하지 않도록 합니다. 노드에 실행 중인 가상 머신이 있는 경우 노드가 드레이닝되지 않을 수 있습니다.- 현재 해결책은 노드를 유지보수 모드에 배치하는 것입니다.
-
OpenShift Virtualization 스토리지 PV가 RHV VM을 가져오는 데 적합하지 않은 경우 진행률 표시줄이 10%로 유지되고 가져오기가 완료되지 않습니다. VM Import Controller Pod 로그에 다음과 같은 오류 메시지가 표시됩니다.
볼륨을 바인딩하지 못했습니다: PVC에 프로비저닝에 실패했습니다
. (BZ#1857784)
RHV VM을 가져오는 동안 RHV Manager에 잘못된 자격 증명을 입력하면
vm-import-operator
에서 RHV API에 반복적으로 연결을 시도하기 때문에 Manager에서 관리자 계정을 잠글 수 있습니다. (BZ#1887140)계정을 잠금 해제하려면 Manager에 로그인하여 다음 명령을 입력하십시오.
$ ovirt-aaa-jdbc-tool user unlock admin
-
OpenShift Container Platform 클러스터에
기본 사용자 권한이
있는 사용자로 로그인한 경우virtctl guestosinfo <vmi_name>
을 실행하여 게스트 에이전트 정보를 검색할 수 있습니다. 이 문제를 해결하려면oc describe vmi
명령을 실행하여 게스트 에이전트 데이터의 하위 집합을 가져올 수 있습니다. (BZ#2000464)
3장. OpenShift Virtualization 설치
3.1. OpenShift Virtualization을 위한 클러스터 준비
OpenShift Virtualization을 설치하기 전에 이 섹션을 검토하여 클러스터가 요구 사항을 충족하는지 확인합니다.
사용자 프로비저닝, 설치 관리자 프로비저닝 또는 지원 설치 프로그램을 포함하여 설치 방법을 사용하여 OpenShift Container Platform을 배포할 수 있습니다. 그러나 설치 방법과 클러스터 토폴로지는 스냅샷 또는 실시간 마이그레이션과 같은 OpenShift Virtualization 기능에 영향을 줄 수 있습니다.
FIPS 모드
FIPS 모드에서 클러스터를 설치하는 경우 OpenShift Virtualization에 추가 설정이 필요하지 않습니다.
3.1.1. 하드웨어 및 운영 체제 요구 사항
OpenShift Virtualization에 대한 다음 하드웨어 및 운영 체제 요구 사항을 검토합니다.
지원되는 플랫폼
- 온프레미스 베어 메탈 서버
- Amazon Web Services 베어 메탈 인스턴스
AWS 베어 메탈 인스턴스에 OpenShift Virtualization을 설치하는 것은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.
- 다른 클라우드 공급자가 제공하는 베어 메탈 인스턴스 또는 서버는 지원되지 않습니다.
CPU 요구사항
- RHEL (Red Hat Enterprise Linux) 8에서 지원
- Intel 64 또는 AMD64 CPU 확장 지원
- Intel VT 또는 AMD-V 하드웨어 가상화 확장 기능 활성화
- NX(실행 없음) 플래그를 사용할 수 있음
스토리지 요구사항
- OpenShift Container Platform에서 지원
운영 체제 요구 사항
작업자 노드에 설치된 RHCOS(Red Hat Enterprise Linux CoreOS)
참고RHEL 작업자 노드는 지원되지 않습니다.
추가 리소스
- RHCOS 소개
- 지원되는 CPU에 대한 Red Hat Ecosystem Catalog
- 지원되는 스토리지
3.1.2. 물리적 리소스 오버헤드 요구사항
OpenShift Virtualization은 OpenShift Container Platform의 추가 기능이며 클러스터를 계획할 때 고려해야 하는 추가 오버헤드를 적용합니다. 각 클러스터 머신은 OpenShift Container Platform 요구 사항 이외에도 다음과 같은 오버헤드 요구 사항을 충족해야 합니다. 클러스터에서 물리적 리소스를 초과 구독하면 성능에 영향을 미칠 수 있습니다.
이 문서에 명시된 수치는 Red Hat의 테스트 방법론 및 설정을 기반으로 한 것입니다. 고유한 개별 설정 및 환경에 따라 수치가 달라질 수 있습니다.
3.1.2.1. 메모리 오버헤드
아래 식을 사용하여 OpenShift Virtualization의 메모리 오버헤드 값을 계산합니다.
클러스터 메모리 오버헤드
Memory overhead per infrastructure node ≈ 150 MiB
Memory overhead per worker node ≈ 360 MiB
또한, OpenShift Virtualization 환경 리소스에는 모든 인프라 노드에 분산된 총 2179MiB의 RAM이 필요합니다.
가상 머신 메모리 오버헤드
Memory overhead per virtual machine ≈ (1.002 * requested memory) + 146 MiB \ + 8 MiB * (number of vCPUs) \ 1 + 16 MiB * (number of graphics devices) 2
환경에 SR-IOV(Single Root I/O Virtualization) 네트워크 장치 또는 GPU(Graphics Processing Unit)가 포함된 경우 각 장치에 대해 1GiB의 추가 메모리 오버헤드를 할당합니다.
3.1.2.2. CPU 오버헤드
아래 식을 사용하여 OpenShift Virtualization에 대한 클러스터 프로세서 오버헤드 요구 사항을 계산합니다. 가상 머신당 CPU 오버헤드는 개별 설정에 따라 다릅니다.
클러스터 CPU 오버헤드
CPU overhead for infrastructure nodes ≈ 4 cores
OpenShift Virtualization은 로깅, 라우팅 및 모니터링과 같은 클러스터 수준 서비스의 전반적인 사용률을 높입니다. 이 워크로드를 처리하려면 인프라 구성 요소를 호스팅하는 노드에 4 개의 추가 코어 (4000밀리코어)가 해당 노드에 분산되어 있는지 확인합니다.
CPU overhead for worker nodes ≈ 2 cores + CPU overhead per virtual machine
가상 머신을 호스팅하는 각 작업자 노드는 가상 머신 워크로드에 필요한 CPU 외에도 OpenShift Virtualization 관리 워크로드에 대한 2개의 추가 코어(2000밀리코어)용 용량이 있어야 합니다.
가상 머신 CPU 오버헤드
전용 CPU가 요청되면 클러스터 CPU 오버헤드 요구 사항에 대한 1:1 영향이 있습니다. 그러지 않으면 가상 머신에 필요한 CPU 수에 대한 구체적인 규칙이 없습니다.
3.1.2.3. 스토리지 오버헤드
아래 지침을 사용하여 OpenShift Virtualization 환경에 대한 스토리지 오버헤드 요구 사항을 추정할 수 있습니다.
클러스터 스토리지 오버헤드
Aggregated storage overhead per node ≈ 10 GiB
10GiB는 OpenShift Virtualization을 설치할 때 클러스터의 각 노드에 대해 예상되는 온디스크 스토리지 영향입니다.
가상 머신 스토리지 오버헤드
가상 머신당 스토리지 오버헤드는 가상 머신 내의 리소스 할당 요청에 따라 다릅니다. 이 요청은 클러스터의 다른 위치에서 호스팅되는 노드 또는 스토리지 리소스의 임시 스토리지에 대한 요청일 수 있습니다. 현재 OpenShift Virtualization은 실행 중인 컨테이너 자체에 대한 추가 임시 스토리지를 할당하지 않습니다.
3.1.2.4. 예
클러스터 관리자가 클러스터에서 10개의 가상 머신을 호스팅하는 경우 1GiB RAM과 2개의 vCPU가 장착된 메모리의 클러스터 전체에 대한 영향은 11.68GiB입니다. 클러스터의 각 노드에 대한 디스크 스토리지 영향은 10GiB이며 호스트 가상 머신 워크로드가 최소 2개 코어인 작업자 노드에 대한 CPU 영향은 최소 2개입니다.
3.1.3. 오브젝트 최대값
클러스터를 계획할 때 다음과 같은 테스트된 오브젝트 최대값을 고려해야 합니다.
3.1.4. 제한된 네트워크 환경
인터넷 연결이 없는 제한된 환경에서 OpenShift Virtualization을 설치하는 경우 제한된 네트워크에 대해 Operator Lifecycle Manager를 구성해야 합니다.
인터넷 연결이 제한된 경우 Red Hat 제공 OperatorHub에 액세스하도록 Operator Lifecycle Manager에서 프록시 지원을 구성할 수 있습니다.
3.1.5. 실시간 마이그레이션
실시간 마이그레이션에는 다음과 같은 요구 사항이 있습니다.
-
RWX(
ReadWriteMany
) 액세스 모드를 사용한 공유 스토리지 - 충분한 RAM 및 네트워크 대역폭
- 작업자 노드에 용량이 충분한 적절한 CPU입니다. CPU에 다른 용량이 있는 경우 실시간 마이그레이션이 매우 느리거나 실패할 수 있습니다.
3.1.6. 스냅샷 및 복제
스냅샷 및 복제 요구 사항은 OpenShift Virtualization 스토리지 기능을 참조하십시오.
3.1.7. 클러스터 고가용성 옵션
클러스터에 대해 다음과 같은 HA(고가용성) 옵션 중 하나를 구성할 수 있습니다.
머신 상태 점검 을 배포하여 설치 관리자 프로비저닝 인프라 (IPI)의 자동 고가용성을 사용할 수 있습니다.
참고설치 관리자 프로비저닝 인프라를 사용하여 설치하고 MachineHealthCheck가 올바르게 구성된 OpenShift Container Platform 클러스터에서는 노드가 MachineHealthCheck에 실패하여 클러스터에서 사용할 수 없게 되는 경우 재활용됩니다. 실패한 노드에서 실행된 VM에서 다음에 수행되는 작업은 일련의 조건에 따라 다릅니다. 잠재적 결과 및 RunStrategies가 이러한 결과에 미치는 영향에 대한 자세한 내용은 가상 머신에 대한 RunStrategies 정보를 참조하십시오.
모니터링 시스템 또는 자격을 갖춘 사람이 노드 가용성을 모니터링하는 모든 플랫폼에 대한 고가용성을 사용할 수 있습니다. 노드가 손실되면 노드를 종료하고
oc delete node <lost_node>
를 실행합니다.참고외부 모니터링 시스템 또는 인증된 사용자 모니터링 노드 상태가 없으면 가상 머신의 가용성이 저하됩니다.
3.2. 웹 콘솔을 사용한 OpenShift Virtualization 설치
OpenShift Virtualization을 설치하여 OpenShift Container Platform 클러스터에 가상화 기능을 추가합니다.
OpenShift Container Platform 4.6 웹 콘솔을 사용하여 OpenShift Virtualization Operator를 구독하고 배포할 수 있습니다.
3.2.1. 전제 조건
- 클러스터에 OpenShift Container Platform 4.6을 설치합니다.
-
cluster-admin
권한이 있는 사용자로 로그인합니다.
3.2.2. OpenShift Virtualization 카탈로그 구독
OpenShift Virtualization을 설치하기 전에 OpenShift Container Platform 웹 콘솔에서 OpenShift Virtualization 카탈로그를 구독하십시오. 구독하면 openshift-cnv
네임스페이스에서 OpenShift Virtualization Operator에 액세스할 수 있습니다.
프로세스
- 브라우저 창을 열고 OpenShift Container Platform 웹 콘솔에 로그인합니다.
- Operator → OperatorHub 페이지로 이동합니다.
- OpenShift Virtualization을 검색한 후 선택합니다.
- Operator에 대한 정보를 읽고 설치를 클릭합니다.
Operator 설치 페이지에서 다음을 수행합니다.
설치된 네임스페이스의 경우 Operator 권장 네임스페이스 옵션이 선택되어 있는지 확인합니다. 그러면 필수
openshift-cnv
네임스페이스에 Operator가 설치되고, 해당 네임스페이스가 존재하지 않는 경우 자동으로 생성됩니다.주의openshift-cnv
이외의 네임스페이스에 OpenShift Virtualization Operator를 설치하려고 하면 설치가 실패합니다.- 사용 가능한 업데이트 채널 옵션 목록에서 stable을 선택합니다. 이렇게 하면 OpenShift Container Platform 버전과 호환되는 OpenShift Virtualization 버전을 설치할 수 있습니다.
- 승인 전략의 경우 기본값인 자동이 선택되어 있는지 확인합니다. OpenShift Virtualization은 새로운 z 스트림 릴리스가 출시되면 자동으로 업데이트됩니다.
openshift-cnv
네임스페이스에서 Operator를 사용할 수 있도록 설치를 클릭합니다.OpenShift Virtualization 설치가 완료되면 설치된 Operator 화면에서 상태가 성공으로 표시됩니다.
3.2.3. OpenShift Virtualization 배포
OpenShift Virtualization 카탈로그를 구독한 후 OpenShift Virtualization Operator 배포 사용자 정의 리소스를 생성하여 OpenShift Virtualization을 배포합니다.
전제 조건
-
openshift-cnv
네임스페이스에서 OpenShift Virtualization 카탈로그를 구독하십시오.
프로세스
- Operator → 설치된 Operator 페이지로 이동합니다.
- OpenShift Virtualization을 클릭합니다.
OpenShift Virtualization Operator 배포 탭을 클릭하고 Create HyperConverged 클러스터 생성을 클릭합니다.
주의배포 오류를 방지하려면 사용자 정의 리소스의 이름을 바꾸지 마십시오. 다음 단계를 진행하기 전에 사용자 정의 리소스 이름이 기본값인
kubevirt-hyperconverged
로 지정되어 있는지 확인하십시오.- 생성을 클릭하여 OpenShift Virtualization을 시작합니다.
- 워크로드 → Pods 페이지로 이동하여 모두 실행 중 상태가 될 때까지 OpenShift Virtualization Pod를 모니터링합니다. 모든 Pod에 실행 중 상태가 표시되면 OpenShift Virtualization에 액세스할 수 있습니다.
3.2.4. 다음 단계
다음 구성 요소를 추가로 구성하는 것이 좋습니다.
- KubeMacPool 구성 요소는 지정된 네임스페이스의 가상 머신 NIC에 대한 MAC 주소 풀 서비스를 제공합니다. 해당 네임스페이스에 KubeMacPool 라벨을 적용하여 네임스페이스에서 MAC 주소 풀을 활성화합니다.
- hostpath 프로비전 프로그램은 OpenShift Virtualization용으로 설계된 로컬 스토리지 프로비전 프로그램입니다. 가상 머신의 로컬 스토리지를 구성하려면 먼저 hostpath 프로비전 프로그램을 활성화해야 합니다.
OpenShift Virtualization을 설치하여 OpenShift Container Platform 클러스터에 가상화 기능을 추가합니다. 명령줄을 사용하여 OpenShift Virtualization Operator를 구독하고 배포하여 클러스터에 매니페스트를 적용할 수 있습니다.
3.2.5. 전제 조건
- 클러스터에 OpenShift Container Platform 4.6을 설치합니다.
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
3.2.6. CLI를 사용하여 OpenShift Virtualization 카탈로그 구독
OpenShift Virtualization을 설치하기 전에 OpenShift Virtualization 카탈로그를 구독해야 합니다. 구독하면 openshift-cnv
네임스페이스에서 OpenShift Virtualization Operator에 액세스할 수 있습니다.
구독하려면 클러스터에 단일 매니페스트를 적용하여 Namespace
, OperatorGroup
, Subscription
오브젝트를 구성합니다.
절차
다음 매니페스트를 포함하는 YAML 파일을 만듭니다.
apiVersion: v1 kind: Namespace metadata: name: openshift-cnv --- apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: kubevirt-hyperconverged-group namespace: openshift-cnv spec: targetNamespaces: - openshift-cnv --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: hco-operatorhub namespace: openshift-cnv spec: source: redhat-operators sourceNamespace: openshift-marketplace name: kubevirt-hyperconverged startingCSV: kubevirt-hyperconverged-operator.v2.5.8 channel: "stable" 1
- 1
stable
채널을 사용하면 OpenShift Container Platform 버전과 호환되는 OpenShift Virtualization 버전을 설치할 수 있습니다.
다음 명령을 실행하여 OpenShift Virtualization에 필요한
Namespace
,OperatorGroup
및Subscription
오브젝트를 생성합니다.$ oc apply -f <file name>.yaml
3.2.7. CLI를 사용하여 OpenShift Virtualization Operator 배포
oc
CLI를 사용하여 OpenShift Virtualization Operator를 배포할 수 있습니다.
사전 요구 사항
-
openshift-cnv
네임스페이스의 OpenShift Virtualization 카탈로그에 대한 구독이 활성 상태여야 합니다.
절차
다음 매니페스트를 포함하는 YAML 파일을 만듭니다.
apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: BareMetalPlatform: true
다음 명령을 실행하여 OpenShift Virtualization Operator를 배포합니다.
$ oc apply -f <file name>.yaml
검증
openshift-cnv
네임스페이스에서 CSV(클러스터 서비스 버전)의PHASE
를 확인하여 OpenShift Virtualization이 성공적으로 배포되었는지 확인합니다. 다음 명령을 실행합니다.$ watch oc get csv -n openshift-cnv
배포에 성공하면 다음 출력이 표시됩니다.
출력 예
NAME DISPLAY VERSION REPLACES PHASE kubevirt-hyperconverged-operator.v2.5.8 OpenShift Virtualization 2.5.8 Succeeded
3.2.8. 다음 단계
다음 구성 요소를 추가로 구성하는 것이 좋습니다.
- KubeMacPool 구성 요소는 지정된 네임스페이스의 가상 머신 NIC에 대한 MAC 주소 풀 서비스를 제공합니다. 해당 네임스페이스에 KubeMacPool 라벨을 적용하여 네임스페이스에서 MAC 주소 풀을 활성화합니다.
- hostpath 프로비전 프로그램은 OpenShift Virtualization용으로 설계된 로컬 스토리지 프로비전 프로그램입니다. 가상 머신의 로컬 스토리지를 구성하려면 먼저 hostpath 프로비전 프로그램을 활성화해야 합니다.
3.3. virtctl 클라이언트 설치
virtctl
클라이언트는 OpenShift Virtualization 리소스를 관리하는 명령줄 유틸리티입니다. Linux, macOS, Windows 배포에 사용할 수 있습니다.
OpenShift Virtualization 웹 콘솔에서 또는 OpenShift Virtualization 리포지토리를 활성화하고 kubevirt-virtctl
패키지를 설치하여 virtctl
클라이언트를 설치할 수 있습니다.
3.3.1. 웹 콘솔에서 virtctl 클라이언트 설치
명령줄 툴 페이지의 OpenShift Virtualization 웹 콘솔에 링크된 Red Hat Customer Portal에서 virtctl
클라이언트를 다운로드할 수 있습니다.
사전 요구 사항
- 고객 포털의 다운로드 페이지에 액세스하려면 활성화된 OpenShift Container Platform 구독이 있어야 합니다.
절차
- 웹 콘솔의 오른쪽 상단에 있는 아이콘을 클릭하고 명령줄 툴을 선택하여 고객 포털에 액세스합니다.
- 버전: 목록에서 선택한 클러스터에 적합한 버전이 있는지 확인합니다.
-
배포를 위해
virtctl
클라이언트를 다운로드합니다. 모든 다운로드는tar.gz
형식으로 수행됩니다. tarball을 추출합니다. 다음 CLI 명령은 tarball과 동일한 디렉터리에 압축을 풀며 모든 배포에 적용할 수 있습니다.
$ tar -xvf <virtctl-version-distribution.arch>.tar.gz
Linux 및 macOS의 경우:
추출된 폴더 계층 구조로 이동하여
virtctl
바이너리를 실행할 수 있도록 설정합니다.$ chmod +x <virtctl-file-name>
virtctl
바이너리를 PATH의 디렉터리로 이동합니다.경로를 확인하려면 다음을 실행합니다.
$ echo $PATH
Windows 사용자의 경우:
-
추출된 폴더 계층 구조로 이동하고
virtctl
실행 파일을 두 번 클릭하여 클라이언트를 설치합니다.
-
추출된 폴더 계층 구조로 이동하고
3.3.2. OpenShift Virtualization 리포지토리 활성화
Red Hat은 Red Hat Enterprise Linux 8 및 Red Hat Enterprise Linux 7 모두에 OpenShift Virtualization 리포지토리를 제공합니다.
-
Red Hat Enterprise Linux 8 리포지토리:
cnv-2.5-for-rhel-8-x86_64-rpms
-
Red Hat Enterprise Linux 7 리포지토리:
rhel-7-server-cnv-2.5-rpms
subscription-manager
에서 리포지토리를 활성화하는 프로세스는 두 플랫폼에서 동일합니다.
절차
다음 명령을 실행하여 시스템에 적합한 OpenShift Virtualization 리포지토리를 활성화하십시오.
# subscription-manager repos --enable <repository>
3.3.3. virtctl 클라이언트 설치
kubevirt-virtctl
패키지에서 virtctl
클라이언트를 설치합니다.
절차
kubevirt-virtctl
패키지를 설치합니다.# yum install kubevirt-virtctl
3.3.4. 추가 리소스
- OpenShift Virtualization에 CLI 툴 사용하기
3.4. 웹 콘솔을 사용하여 OpenShift Virtualization 설치 제거
OpenShift Container Platform 웹 콘솔을 사용하여 OpenShift Virtualization을 설치 제거할 수 있습니다.
3.4.1. 전제 조건
- OpenShift Virtualization 2.5가 설치되어 있어야 합니다.
가상 머신, 가상 머신 인스턴스, 데이터 볼륨을 모두 삭제해야 합니다.
중요이러한 오브젝트를 삭제하지 않고 OpenShift Virtualization을 제거하려고 하면 오류가 발생합니다.
3.4.2. OpenShift Virtualization Operator 배포 사용자 정의 리소스 삭제
OpenShift Virtualization을 설치 제거하려면 먼저 OpenShift Virtualization Operator 배포 사용자 정의 리소스를 삭제해야 합니다.
사전 요구 사항
- OpenShift Virtualization Operator 배포 사용자 정의 리소스를 만듭니다.
절차
-
OpenShift Container Platform 웹 콘솔의 프로젝트 목록에서
openshift-cnv
를 선택합니다. - Operator → 설치된 Operator 페이지로 이동합니다.
- OpenShift Virtualization을 클릭합니다.
- OpenShift Virtualization Operator 배포 탭을 클릭합니다.
- kubevirt-hyperconverged 사용자 정의 리소스가 포함된 행에서 옵션 메뉴 를 클릭합니다. 확장된 메뉴에서 HyperConverged 클러스터 삭제를 클릭합니다.
- 확인 창에서 삭제를 클릭합니다.
- 워크로드 → Pods 페이지로 이동하여 Operator Pod만 실행 중인지 확인합니다.
터미널 창을 열고 다음 명령을 실행하여 나머지 리소스를 정리합니다.
$ oc delete apiservices v1alpha3.subresources.kubevirt.io -n openshift-cnv
3.4.3. OpenShift Virtualization 카탈로그 구독 삭제
OpenShift Virtualization 제거를 완료하려면 OpenShift Virtualization 카탈로그 구독을 삭제하십시오.
사전 요구 사항
- 활성 상태의 OpenShift Virtualization 카탈로그 구독
절차
- Operator → OperatorHub 페이지로 이동합니다.
- OpenShift Virtualization을 검색한 후 선택합니다.
- 제거를 클릭합니다.
이제 openshift-cnv
네임스페이스를 삭제할 수 있습니다.
3.4.4. 웹 콘솔을 사용하여 네임스페이스 삭제
OpenShift Container Platform 웹 콘솔을 사용하여 네임스페이스를 삭제할 수 있습니다.
네임스페이스 삭제 옵션을 사용하려면 네임스페이스를 삭제할 수 있는 권한이 있어야 합니다.
절차
- 관리 → 네임스페이스로 이동합니다.
- 네임스페이스 목록에서 삭제하려는 네임스페이스를 찾습니다.
- 네임스페이스 목록 맨 오른쪽에 있는 옵션 메뉴 에서 네임스페이스 삭제를 선택합니다.
- 네임스페이스 삭제 창이 열리면 삭제할 네임스페이스 이름을 필드에 입력합니다.
- 삭제를 클릭합니다.
3.5. CLI를 사용하여 OpenShift Virtualization 설치 제거
OpenShift Container Platform CLI를 사용하여 OpenShift Virtualization의 설치를 제거할 수 있습니다.
3.5.1. 전제 조건
- OpenShift Virtualization 2.5가 설치되어 있어야 합니다.
가상 머신, 가상 머신 인스턴스, 데이터 볼륨을 모두 삭제해야 합니다.
중요이러한 오브젝트를 삭제하지 않고 OpenShift Virtualization을 제거하려고 하면 오류가 발생합니다.
3.5.2. OpenShift Virtualization 삭제
CLI를 사용하여 OpenShift Virtualization을 삭제할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 계정을 사용하여 OpenShift Virtualization 클러스터에 액세스할 수 있어야 합니다.
CLI를 사용하여 OLM에서 OpenShift Virtualization Operator 구독을 삭제하면 CSV(ClusterServiceVersion
) 오브젝트가 클러스터에서 삭제되지 않습니다. OpenShift Virtualization을 완전히 설치 제거하려면 CSV를 명시적으로 삭제해야 합니다.
절차
HyperConverged
사용자 정의 리소스를 삭제합니다.$ oc delete HyperConverged kubevirt-hyperconverged -n openshift-cnv
OLM(Operator Lifecycle Manager)에서 OpenShift Virtualization Operator 구독을 삭제합니다.
$ oc delete subscription kubevirt-hyperconverged -n openshift-cnv
OpenShift Virtualization의 CSV(클러스터 서비스 버전) 이름을 환경 변수로 설정합니다.
$ CSV_NAME=$(oc get csv -n openshift-cnv -o=custom-columns=:metadata.name)
이전 단계에서 CSV 이름을 지정하여 OpenShift Virtualization 클러스터에서 CSV를 삭제합니다.
$ oc delete csv ${CSV_NAME} -n openshift-cnv
CSV가 성공적으로 삭제되었다는 확인 메시지가 표시되면 OpenShift Virtualization이 설치 제거됩니다.
출력 예
clusterserviceversion.operators.coreos.com "kubevirt-hyperconverged-operator.v2.5.8" deleted
4장. OpenShift Virtualization 업그레이드
웹 콘솔을 사용하여 다음 마이너 버전의 OpenShift Virtualization으로 수동으로 업그레이드하고 업데이트 상태를 모니터링할 수 있습니다.
4.1. OpenShift Virtualization 업그레이드 정보
4.1.1. OpenShift Virtualization 업그레이드 작동 방식
- OpenShift Container Platform 웹 콘솔을 사용하여 Operator 구독 채널을 변경하는 방식으로 OpenShift Virtualization을 다음 마이너 버전으로 업그레이드할 수 있습니다.
- OpenShift Virtualization을 설치하는 동안 자동 z-stream 업데이트를 활성화할 수 있습니다.
- 업데이트는 OpenShift Container Platform을 설치하는 동안 배포되는 Marketplace Operator를 통해 제공됩니다. Marketplace Operator를 사용하면 클러스터에서 외부 Operator를 사용할 수 있습니다.
- 업데이트를 완료하는 데 걸리는 시간은 네트워크 연결에 따라 달라집니다. 대부분의 자동 업데이트는 15분 이내에 완료됩니다.
4.1.2. OpenShift Virtualization 업그레이드가 클러스터에 미치는 영향
업그레이드해도 가상 머신 워크로드는 중단되지 않습니다.
가상 머신 Pod는 업그레이드 중 재시작되거나 마이그레이션되지 않습니다.
virt-launcher
Pod를 업데이트해야 하는 경우 가상 머신을 재시작하거나 실시간 마이그레이션해야 합니다.참고각 가상 머신에는 가상 머신 인스턴스를 실행하는
virt-launcher
Pod가 있습니다.virt-launcher
Pod는 가상 머신 프로세스를 관리하는 데 사용하는libvirt
인스턴스를 실행합니다.
- 업그레이드해도 네트워크 연결은 중단되지 않습니다.
데이터 볼륨 및 관련 영구 볼륨 클레임은 업그레이드하는 동안 유지됩니다.
중요실시간으로 마이그레이션할 수 없는 가상 머신이 실행 중인 경우 OpenShift Container Platform 클러스터 업그레이드가 차단될 수 있습니다. 여기에는 hostpath 프로비전 프로그램 스토리지 또는 SR-IOV 네트워크 인터페이스를 사용하는 가상 머신이 포함됩니다.
해결 방법으로 클러스터를 업그레이드하는 동안 전원이 자동으로 꺼지도록 가상 머신을 재구성할 수 있습니다.
evictionStrategy를 삭제합니다. LiveMigrate
필드 및runStrategy
필드를Always
로 설정합니다.
4.2. 마이너 릴리스 업그레이드 경로
업그레이드 경로는 설치된 OpenShift Virtualization의 2.4.z 버전에 따라 다릅니다.
OpenShift Virtualization의 마이너 릴리스를 업그레이드하기 전에 OpenShift Container Platform을 4.6으로 업그레이드해야 합니다.
4.2.1. 2.4.3에서 2.5.8로 업그레이드
z-stream을 업그레이드하려면 먼저 2.5.0으로 업그레이드해야 합니다. 그런 다음 2.5.0에서 2.5.1로 업그레이드한 다음 2.5.2 등으로 업그레이드할 수 있습니다.
기본값인 승인 전략이 자동 이면 2.5.0으로 업그레이드한 후 OpenShift Virtualization에서 z-stream을 자동으로 업그레이드합니다.
4.2.2. 2.4.4 또는 2.4.5에서 2.5.8로 업그레이드
2.4.4 또는 2.4.5에서 2.5.2로 직접 업그레이드할 수 있습니다. 그런 다음 2.5.2에서 2.5.3 등으로 업그레이드할 수 있습니다.
기본값인 승인 전략이 Automatic (자동)이면 2.5.2로 업그레이드한 후 OpenShift Virtualization에서 z-stream을 자동으로 업그레이드합니다.
4.3. OpenShift Virtualization을 다음 마이너 버전으로 업그레이드
OpenShift Container Platform 웹 콘솔을 사용하여 Operator 구독 채널을 변경하는 방식으로 OpenShift Virtualization을 다음 마이너 버전으로 수동으로 업그레이드할 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 로그인합니다.
절차
- OpenShift Container Platform 웹 콘솔에 액세스하여 Operator → 설치된 Operator로 이동합니다.
- OpenShift Virtualization을 클릭하여 Operator 세부 정보 페이지를 엽니다.
- 서브스크립션 탭을 클릭하여 서브스크립션 개요 페이지를 엽니다.
- 채널 창에서 버전 번호 오른쪽의 연필 아이콘을 클릭하여 서브스크립션 업데이트 채널 변경 창을 엽니다.
- stable을 선택합니다. 이렇게 하면 OpenShift Container Platform 버전과 호환되는 OpenShift Virtualization 버전을 설치할 수 있습니다.
- 저장을 클릭합니다.
Operator → 설치된 Operator로 이동하여 업그레이드 상태를 확인합니다. 다음
oc
명령을 실행하여 상태를 확인할 수도 있습니다.$ oc get csv -n openshift-cnv
4.4. 업그레이드 상태 모니터링
OpenShift Virtualization 업그레이드 상태를 모니터링하는 가장 좋은 방법은 CSV(클러스터 서비스 버전) PHASE
를 확인하는 것입니다. 웹 콘솔에서 또는 여기에 제공된 명령을 실행하여 CSV 조건을 모니터링할 수도 있습니다.
PHASE
및 조건 값은 사용 가능한 정보를 기반으로 한 근사치입니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 로그인합니다. -
OpenShift CLI(
oc
)를 설치합니다.
절차
다음 명령을 실행합니다.
$ oc get csv
PHASE
필드를 확인하여 출력을 검토합니다. 예를 들면 다음과 같습니다.출력 예
VERSION REPLACES PHASE 2.5.0 kubevirt-hyperconverged-operator.v2.4.3 Installing 2.4.3 Replacing
선택 사항: 다음 명령을 실행하여 모든 OpenShift Virtualization 구성 요소 조건의 집계 상태를 모니터링합니다.
$ oc get hco -n openshift-cnv kubevirt-hyperconverged \ -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}'
업그레이드가 완료되면 다음과 같은 결과가 나타납니다.
출력 예
ReconcileComplete True Reconcile completed successfully Available True Reconcile completed successfully Progressing False Reconcile completed successfully Degraded False Reconcile completed successfully Upgradeable True Reconcile completed successfully
4.5. 추가 리소스
5장. kubevirt-controller 및 virt-launcher에 부여된 추가 보안 권한
kubevirt-controller
및 virt-launcher Pod에는 일반적인 Pod 소유자 외에 일부 SELinux 정책 및 보안 컨텍스트 제약 조건 권한이 부여됩니다. 가상 머신은 이러한 권한을 통해 OpenShift Virtualization 기능을 사용할 수 있습니다.
5.1. virt-launcher Pod에 대해 확장된 SELinux 정책
virt-launcher Pod에 대한 container_t
SELinux 정책은 다음 규칙에 따라 확장됩니다.
-
allow process self (tun_socket (relabelfrom relabelto attach_queue))
-
allow process sysfs_t (file (write))
-
allow process hugetlbfs_t (dir (add_name create write remove_name rmdir setattr))
-
allow process hugetlbfs_t (file (create unlink))
이러한 규칙에서는 다음 가상화 기능을 활성화합니다.
- 자체 TUN 소켓에 큐 라벨을 다시 지정하고 큐를 연결합니다. 이 기능은 네트워크 멀티 큐를 지원하는 데 필요합니다. 멀티 큐를 사용하면 사용 가능한 vCPU 수가 늘어나 네트워크 성능이 확장됩니다.
-
virt-launcher Pod에서 sysfs(
/sys
) 파일에 정보를 쓸 수 있습니다. 이 기능은 SR-IOV(단일 루트 I/O 가상화)를 활성화하는 데 필요합니다. -
hugetlbfs
항목을 읽고 씁니다. 이 기능은 대규모 페이지를 지원하는 데 필요합니다. 대규모 페이지는 메모리 페이지 크기를 늘려서 대량의 메모리를 관리하는 방법입니다.
5.2. kubevirt-controller 서비스 계정에 대한 추가 OpenShift Container Platform 보안 컨텍스트 제약 조건 및 Linux 기능
SCC(보안 컨텍스트 제약 조건)는 Pod에 대한 권한을 제어합니다. 이러한 권한에는 컨테이너 모음인 Pod에서 수행할 수 있는 작업과 액세스할 수 있는 리소스가 포함됩니다. Pod가 시스템에 수용되려면 일련의 조건을 함께 실행해야 하는데, SCC를 사용하여 이러한 조건을 정의할 수 있습니다.
kubevirt-controller
는 클러스터의 가상 머신에 대해 virt-launcher Pod를 생성하는 클러스터 컨트롤러입니다. 이러한 virt-launcher Pod에는 kubevirt-controller
서비스 계정에서 권한을 부여합니다.
5.2.1. kubevirt-controller 서비스 계정에 부여된 추가 SCC
kubevirt-controller
서비스 계정에는 적절한 권한으로 virt-launcher Pod를 생성할 수 있도록 추가 SCC 및 Linux 기능이 부여됩니다. 가상 머신은 이러한 확장된 권한을 통해 일반적인 Pod의 범위를 벗어나는 OpenShift Virtualization 기능을 활용할 수 있습니다.
kubevirt-controller
서비스 계정에는 다음 SCC가 부여됩니다.
-
scc.AllowHostDirVolumePlugin = true
가상 머신에서 hostpath 볼륨 플러그인을 사용할 수 있습니다. -
scc.AllowPrivilegedContainer = false
virt-launcher Pod가 권한 있는 컨테이너로 실행되지 않습니다. -
scc.AllowedCapabilities = []corev1.Capability{"NET_ADMIN", "NET_RAW", "SYS_NICE"}
추가 Linux 기능인NET_ADMIN
,NET_RAW
,SYS_NICE
를 제공합니다.
5.2.2. kubevirt-controller에 대한 SCC 및 RBAC 정의 보기
oc
툴을 사용하여 kubevirt-controller
에 대한 SecurityContextConstraints
정의를 볼 수 있습니다.
$ oc get scc kubevirt-controller -o yaml
oc
툴을 사용하여 kubevirt-controller
clusterrole에 대한 RBAC 정의를 볼 수 있습니다.
$ oc get clusterrole kubevirt-controller -o yaml
5.3. 추가 리소스
- Red Hat Enterprise Linux Virtualization 조정 및 최적화 가이드에는 네트워크 멀티 큐 및 대규모 페이지에 대한 자세한 내용이 있습니다.
-
기능
도움말 페이지에는 Linux 기능에 대한 자세한 내용이 있습니다. -
sysfs(5)
도움말 페이지에는 sysfs에 대한 자세한 내용이 있습니다. - OpenShift Container Platform 인증 가이드에는 보안 컨텍스트 제약 조건에 대한 자세한 내용이 있습니다.
6장. CLI 툴 사용
다음은 클러스터에서 리소스를 관리하는 데 사용되는 두 가지 기본 CLI 툴입니다.
-
OpenShift Virtualization
virtctl
클라이언트 -
OpenShift Container Platform
oc
클라이언트
6.1. 사전 요구 사항
-
virtctl
클라이언트를 설치해야 합니다.
6.2. Virtctl 클라이언트 명령
virtctl
클라이언트는 OpenShift Virtualization 리소스를 관리하는 명령줄 유틸리티입니다. 다음 표에는 OpenShift Virtualization 설명서 전체에서 사용되는 virtctl
명령이 포함되어 있습니다.
명령과 함께 사용할 수 있는 옵션 목록을 보려면 -h
또는 --help
플래그와 함께 실행하십시오. 예를 들면 다음과 같습니다.
$ virtctl image-upload -h
명령 | 설명 |
---|---|
| 가상 머신을 시작합니다. |
| 가상 머신을 중지합니다. |
| 가상 머신 또는 가상 머신 인스턴스를 일시 정지합니다. 머신 상태는 메모리에 유지됩니다. |
| 가상 머신 또는 가상 머신 인스턴스의 일시 정지를 해제합니다. |
| 가상 머신을 마이그레이션합니다. |
| 가상 머신을 재시작합니다. |
| 가상 머신 또는 가상 머신 인스턴스의 지정된 포트를 전달하고 서비스를 노드의 지정된 포트에 노출하는 서비스를 생성합니다. |
| 가상 머신 인스턴스의 직렬 콘솔에 연결합니다. |
| 가상 머신 인스턴스에 대한 VNC 연결을 엽니다. |
| 이미 존재하는 데이터 볼륨에 가상 머신 이미지를 업로드합니다. |
| 가상 머신 이미지를 새 데이터 볼륨에 업로드합니다. |
| 클라이언트 및 서버 버전 정보를 표시합니다. |
|
|
| 게스트 머신에서 사용 가능한 전체 파일 시스템 목록을 반환합니다. |
| 운영 체제에 대한 게스트 에이전트 정보를 반환합니다. |
| 게스트 머신에 로그인한 전체 사용자 목록을 반환합니다. |
6.3. OpenShift Container Platform 클라이언트 명령
OpenShift Container Platform oc
클라이언트는 VirtualMachine
(vm
) 및 VirtualMachineInstance
(vmi
) 오브젝트 유형을 포함하여 OpenShift Container Platform 리소스를 관리하는 명령줄 유틸리티입니다.
-n <namespace>
플래그를 사용하여 다른 프로젝트를 지정할 수 있습니다.
명령 | 설명 |
---|---|
|
OpenShift Container Platform 클러스터에 |
| 현재 프로젝트에서 지정된 오브젝트 유형의 오브젝트 목록을 표시합니다. |
| 현재 프로젝트의 특정 리소스에 대한 세부 정보를 표시합니다. |
| 파일 이름 또는 stdin에서 현재 프로젝트에 리소스를 만듭니다. |
| 현재 프로젝트의 리소스를 편집합니다. |
| 현재 프로젝트의 리소스를 삭제합니다. |
oc
클라이언트 명령에 대한 보다 포괄적인 내용은 OpenShift Container Platform CLI 툴 설명서를 참조하십시오.
7장. 가상 머신
7.1. 가상 머신 생성
가상 머신을 생성하려면 다음 절차 중 하나를 사용하십시오.
- 가상 머신 마법사 실행
- 가상 머신 마법사를 사용하여 사전 구성된 YAML 파일 붙여넣기
- CLI 사용
- 가상 머신 마법사를 사용하여 VMware 가상 머신 또는 템플릿 가져오기
openshift-*
네임스페이스에 가상 머신을 생성하지 마십시오. 대신 새 네임스페이스를 만들거나 openshift
접두사 없이 기존 네임스페이스를 사용하십시오.
7.1.1. 가상 머신 마법사를 실행하여 가상 머신 생성
웹 콘솔에는 일반, 네트워킹, 스토리지, 고급, 검토 단계를 안내하는 대화식 마법사가 있어 가상 머신 생성 프로세스를 단순화합니다. 모든 필수 필드는 *
로 표시됩니다. 필수 필드가 완료되면 가상 머신을 검토하고 생성할 수 있습니다.
NIC(네트워크 인터페이스 컨트롤러) 및 스토리지 디스크를 생성한 후 가상 머신에 연결할 수 있습니다.
부팅 가능 디스크
일반 단계에서 URL
또는 Container
를 소스로 선택하면 rootdisk
디스크가 생성되어 가상 머신에 부팅 가능 디스크로 연결됩니다. rootdisk
를 수정할 수는 있지만 제거할 수는 없습니다.
가상 머신에 연결된 디스크가 없는 경우 PXE 소스에서 프로비저닝된 가상 머신에는 부팅 가능 디스크가 필요하지 않습니다. 하나 이상의 디스크가 가상 머신에 연결된 경우 하나의 디스크를 부팅 가능 디스크로 선택해야 합니다.
전제 조건
- 마법사를 사용하여 가상 머신을 생성할 때 가상 머신의 스토리지 매체에서 RWX(Read-Write-Many) PVC를 지원해야 합니다.
프로세스
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 가상 머신 생성을 클릭하고 마법사로 새로 생성을 선택합니다.
- 일반 단계의 모든 필수 필드를 입력합니다. 템플릿을 선택하면 해당 필드가 자동으로 채워집니다.
다음을 클릭하여 네트워킹 단계를 진행합니다. 기본적으로
nic0
NIC가 연결되어 있습니다.- 선택 사항: 네트워크 인터페이스 추가를 클릭하여 추가 NIC를 생성합니다.
- 선택 사항: 옵션 메뉴 를 클릭하고 삭제를 선택하여 일부 또는 모든 NIC를 제거할 수 있습니다. 가상 머신을 생성하기 위해 NIC를 연결하지 않아도 됩니다. NIC는 가상 머신을 생성한 후 생성할 수 있습니다.
다음을 클릭하여 스토리지 화면을 진행합니다.
- 선택 사항: 디스크 추가를 클릭하여 추가 디스크를 만듭니다. 이러한 디스크는 옵션 메뉴 를 클릭하고 삭제를 선택하여 제거할 수 있습니다.
- 선택 사항: 옵션 메뉴 를 클릭하여 디스크를 편집하고 변경 사항을 저장합니다.
- 검토 및 생성을 클릭합니다. 결과 화면에 가상 머신의 JSON 구성 파일이 표시됩니다.
가상 머신은 가상 머신 탭에 나열됩니다.
웹 콘솔 마법사를 실행하는 경우 가상 머신 마법사 필드 섹션을 참조하십시오.
7.1.1.1. 가상 머신 마법사 필드
이름 | 매개변수 | 설명 |
---|---|---|
템플릿 | 가상 머신을 생성할 템플릿입니다. 템플릿을 선택하면 기타 필드가 자동으로 완성됩니다. | |
소스 | PXE | PXE 메뉴에서 가상 머신을 프로비저닝합니다. 클러스터에 PXE 지원 NIC가 필요합니다. |
URL | HTTP 또는 S3 끝점의 사용 가능한 이미지에서 가상 머신을 프로비저닝합니다. | |
컨테이너 |
클러스터에서 액세스할 수 있는 레지스트리의 부팅 가능한 운영 체제 컨테이너에서 가상 머신을 프로비저닝합니다. 예를 들면 | |
디스크 | 디스크에서 가상 머신을 프로비저닝합니다. | |
운영 체제 | 가상 머신에 대해 선택된 기본 운영 체제입니다. | |
플레이버 | 작음, 중간, 큼, 매우 작음, 사용자 정의 | 가상 머신에 할당된 CPU 및 메모리의 양을 결정하는 사전 설정입니다. 플레이버에 표시되는 사전 설정은 운영 체제에 따라 다릅니다. |
메모리 | 가상 머신에 할당된 메모리 크기(GiB)입니다. | |
CPU | 가상 머신에 할당된 CPU의 양입니다. | |
워크로드 프로필 | 고성능 | 고성능 워크로드에 최적화된 가상 머신 구성입니다. |
서버 | 서버 워크로드를 실행하는 데 최적화된 프로필입니다. | |
데스크탑 | 데스크탑에서 사용할 가상 머신 구성입니다. | |
이름 |
이름에는 소문자( | |
설명 | 선택적 설명 필드입니다. | |
생성 시 가상 머신 시작 | 생성 시 가상 머신을 자동으로 시작하려면 선택합니다. |
7.1.1.2. Cloud-init 필드
이름 | 설명 |
---|---|
호스트 이름 | 가상 머신의 특정 호스트 이름을 설정합니다. |
인증된 SSH 키 | 가상 머신의 ~/.ssh/authorized_keys에 복사되는 사용자의 공개 키입니다. |
사용자 정의 스크립트 | 기타 옵션을 사용자 정의 cloud-init 스크립트를 붙여넣는 필드로 교체합니다. |
7.1.1.3. CD-ROM 필드
소스 | 설명 |
---|---|
컨테이너 |
컨테이너 경로를 지정합니다. 예를 들면 |
URL | URL 경로와 크기(GiB)를 지정합니다. 그런 다음 드롭다운 목록에서 이 URL의 스토리지 클래스를 선택합니다. |
디스크 연결 | 연결할 가상 머신 디스크를 선택합니다. |
7.1.1.4. 네트워킹 필드
이름 | 설명 |
---|---|
이름 | 네트워크 인터페이스 컨트롤러의 이름입니다. |
모델 | 네트워크 인터페이스 컨트롤러의 모델을 나타냅니다. 지원되는 값은 e1000e 및 virtio입니다. |
네트워크 | 사용 가능한 네트워크 연결 정의 목록입니다. |
유형 |
사용 가능한 바인딩 방법 목록입니다. 기본 Pod 네트워크의 경우 권장되는 유일한 바인딩 방법은 |
MAC 주소 | 네트워크 인터페이스 컨트롤러의 MAC 주소입니다. MAC 주소를 지정하지 않으면 주소가 자동으로 할당됩니다. |
7.1.1.5. 스토리지 필드
이름 | 설명 |
---|---|
소스 | 가상 머신의 빈 디스크를 선택하거나 사용 가능한 옵션 중에서 선택합니다. URL,컨테이너,복제된 디스크 연결 또는 디스크 연결. 기존 디스크를 선택하여 가상 머신에 연결하려면 사용 가능한 PVC(영구 볼륨 클레임) 목록에서 복제된 디스크 연결 또는 디스크 연결을 선택합니다. |
이름 |
디스크 이름입니다. 이름에는 소문자( |
크기(GiB) | 디스크 크기(GiB)입니다. |
인터페이스 | 디스크 장치의 유형입니다. 지원되는 인터페이스는 virtIO, SATA, SCSI입니다. |
스토리지 클래스 | 디스크를 만드는 데 사용되는 스토리지 클래스입니다. |
고급 → 볼륨 모드 | 영구 볼륨에서 포맷된 파일 시스템을 사용하는지 또는 원시 블록 상태를 사용하는지를 정의합니다. 기본값은 Filesystem입니다. |
고급 → 액세스 모드 | 영구 볼륨의 액세스 모드입니다. 지원되는 액세스 모드는 ReadWriteOnce, ReadOnlyMany, ReadWriteMany입니다. |
고급 스토리지 설정
다음 고급 스토리지 설정은 비어 있음, URL을 통해 가져오기, 기존 PVC 복제 디스크에 사용할 수 있습니다. 해당 매개변수는 선택 사항입니다. 이러한 매개변수를 지정하지 않으면 kubevirt-storage-class-defaults
구성 맵의 기본값이 사용됩니다.
이름 | 매개변수 | 설명 |
---|---|---|
볼륨 모드 | 파일 시스템 | 파일 시스템 기반 볼륨에 가상 디스크를 저장합니다. |
블록 |
가상 디스크를 블록 볼륨에 직접 저장합니다. 기본 스토리지에서 지원하는 경우에만 | |
액세스 모드 | 단일 사용자(RWO) | 디스크는 단일 노드에서 읽기/쓰기로 마운트할 수 있습니다. |
공유 액세스(RWX) | 디스크는 여러 노드에서 읽기/쓰기로 마운트할 수 있습니다. 참고 이는 가상 머신의 노드 간 실시간 마이그레이션 등 일부 기능에 필요합니다. | |
읽기 전용(ROX) | 디스크는 많은 노드에서 읽기 전용으로 마운트할 수 있습니다. |
kubevirt-storage-class-defaults
구성 맵에 대한 자세한 내용은 데이터 볼륨의 스토리지 기본값을 참조하십시오.
7.1.1.6. 사전 구성된 YAML 파일에 붙여넣어 가상 머신 생성
YAML 구성 파일을 쓰거나 붙여넣어 가상 머신을 생성합니다. YAML 편집 화면을 열 때마다 기본적으로 유효한 example
가상 머신 구성이 제공됩니다.
생성을 클릭할 때 YAML 구성이 유효하지 않으면 오류 메시지에 오류가 발생하는 매개변수가 표시됩니다. 한 번에 하나의 오류만 표시됩니다.
편집하는 동안 YAML 화면을 벗어나면 구성 변경 사항이 취소됩니다.
프로세스
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 가상 머신 생성을 클릭하고 YAML에서 새로 생성을 선택합니다.
편집 가능한 창에서 가상 머신 구성을 작성하거나 붙여넣습니다.
-
또는 YAML 화면에서 기본적으로 제공되는
example
가상 머신을 사용하십시오.
-
또는 YAML 화면에서 기본적으로 제공되는
- 선택 사항: Download (다운로드)를 클릭하여 YAML 구성 파일을 현재 상태로 다운로드합니다.
- 생성을 클릭하여 가상 머신을 생성합니다.
가상 머신은 가상 머신 탭에 나열됩니다.
7.1.2. CLI를 사용하여 가상 머신 생성
virtualMachine
매니페스트에서 가상 머신을 생성할 수 있습니다.
프로세스
VM의
VirtualMachine
매니페스트를 편집합니다. 예를 들어 다음 매니페스트에서는 RHEL(Red Hat Enterprise Linux) VM을 구성합니다.예 7.1. RHEL VM의 매니페스트 예
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: labels: app: <vm_name> 1 name: <vm_name> spec: dataVolumeTemplates: - apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: <vm_name> spec: sourceRef: kind: DataSource name: rhel9 namespace: openshift-virtualization-os-images storage: resources: requests: storage: 30Gi running: false template: metadata: labels: kubevirt.io/domain: <vm_name> spec: domain: cpu: cores: 1 sockets: 2 threads: 1 devices: disks: - disk: bus: virtio name: rootdisk - disk: bus: virtio name: cloudinitdisk interfaces: - masquerade: {} name: default rng: {} features: smm: enabled: true firmware: bootloader: efi: {} resources: requests: memory: 8Gi evictionStrategy: LiveMigrate networks: - name: default pod: {} volumes: - dataVolume: name: <vm_name> name: rootdisk - cloudInitNoCloud: userData: |- #cloud-config user: cloud-user password: '<password>' 2 chpasswd: { expire: False } name: cloudinitdisk
매니페스트 파일을 사용하여 가상 머신을 생성합니다.
$ oc create -f <vm_manifest_file>.yaml
선택 사항: 가상 머신을 시작합니다.
$ virtctl start <vm_name>
7.1.3. 가상 머신 스토리지 볼륨 유형
스토리지 볼륨 유형 | 설명 |
---|---|
임시 | 네트워크 볼륨을 읽기 전용 백업 저장소로 사용하는 로컬 COW(기록 중 복사) 이미지입니다. 백업 볼륨은 PersistentVolumeClaim이어야 합니다. 임시 이미지는 가상 머신이 시작되고 모든 쓰기를 로컬로 저장할 때 생성됩니다. 임시 이미지는 가상 머신이 중지, 재시작 또는 삭제될 때 삭제됩니다. 백업 볼륨(PVC)은 어떤 식으로든 변경되지 않습니다. |
persistentVolumeClaim | 사용 가능한 PV를 가상 머신에 연결합니다. PV를 연결하면 세션이 바뀌어도 가상 머신 데이터가 지속됩니다. 기존 가상 머신을 OpenShift Container Platform으로 가져올 때는 CDI를 사용하여 기존 가상 머신 디스크를 PVC로 가져와서 PVC를 가상 머신 인스턴스에 연결하는 것이 좋습니다. PVC 내에서 디스크를 사용하려면 몇 가지 요구 사항이 있습니다. |
dataVolume |
데이터 볼륨은 가져오기, 복제 또는 업로드 작업을 통해 가상 머신 디스크를 준비하는 프로세스를 관리하여
|
cloudInitNoCloud | 참조된 cloud-init NoCloud 데이터 소스가 포함된 디스크를 연결하여 가상 머신에 사용자 데이터 및 메타데이터를 제공합니다. 가상 머신 디스크 내부에 cloud-init을 설치해야 합니다. |
containerDisk | 컨테이너 이미지 레지스트리에 저장된 가상 머신 디스크와 같은 이미지를 참조합니다. 이 이미지는 가상 머신이 시작될 때 레지스트리에서 가져와서 가상 머신에 디스크로 연결됩니다.
컨테이너 이미지 레지스트리에는 RAW 및 QCOW2 형식의 디스크 유형만 지원됩니다. 이미지 크기를 줄이기 위해 QCOW2를 사용하는 것이 좋습니다. 참고
|
emptyDisk | 가상 머신 인터페이스의 라이프사이클에 연결된 추가 스파스(sparse) QCOW2 디스크를 생성합니다. 해당 데이터는 가상 머신에서 게스트가 시작한 재부팅 후에는 유지되지만 가상 머신이 중지되거나 웹 콘솔에서 재시작되면 삭제됩니다. 빈 디스크는 임시 디스크의 제한된 임시 파일 시스템 크기를 초과하지 않도록 애플리케이션 종속성 및 데이터를 저장하는 데 사용됩니다. 디스크 용량 크기도 제공해야 합니다. |
7.1.4. 가상 머신 RunStrategies 정보
가상 머신에 대한 RunStrategy
는 일련의 조건에 따라 VMI(가상 머신 인스턴스)의 동작을 결정합니다. spec.runStrategy
설정은 spec.running
설정의 대안으로, 가상 머신 구성 프로세스 내에 있습니다. spec.runStrategy
설정을 사용하면 true
또는 false
응답만 있는 spec.running
설정과 달리 VMI를 만들고 관리하는 방법에 대한 유연성을 높일 수 있습니다. 그러나 두 설정은 함께 사용할 수 없습니다. spec.running
또는 spec.runStrategy
중 하나만 사용할 수 있습니다. 둘 다 사용하면 오류가 발생합니다.
RunStrategies는 다음과 같이 네 가지로 정의되어 있습니다.
Always
-
가상 머신이 생성될 때 VMI가 항상 존재합니다. 어떠한 이유로 원본이 중지되면 새 VMI가 생성되는데, 이러한 동작은
spec.running: true
와 동일합니다. RerunOnFailure
- 오류로 인해 이전 인스턴스가 실패하면 VMI가 다시 생성됩니다. 가상 머신이 종료될 때와 같이 성공적으로 중지되면 인스턴스가 다시 생성되지 않습니다.
Manual
-
start
,stop
,restart
virtctl 클라이언트 명령을 사용하여 VMI의 상태 및 존재를 제어할 수 있습니다. Halted
-
가상 머신이 생성될 때 VMI가 존재하지 않으며 이 동작은
spec.running: false
와 동일합니다.
start
, stop
, restart
virtctl 명령의 다양한 조합은 사용되는 RunStrategy
에 영향을 미칩니다.
다음 표에는 다양한 상태에 따른 VM 전환이 표시되어 있습니다. 첫 번째 열에는 VM의 초기 RunStrategy
가 표시되어 있습니다. 각 추가 열에는 virtctl 명령과 해당 명령이 실행된 후의 새 RunStrategy
가 표시되어 있습니다.
초기 RunStrategy | 시작 | 중지 | 재시작 |
---|---|---|---|
Always | - | Halted | Always |
RerunOnFailure | - | Halted | RerunOnFailure |
Manual | Manual | Manual | Manual |
Halted | Always | - | - |
설치 관리자 프로비저닝 인프라를 사용하여 설치한 OpenShift Virtualization 클러스터에서 노드가 MachineHealthCheck에 실패하여 클러스터에서 노드를 사용할 수 없는 경우, 새 노드에 RunStrategy가 Always
또는 RerunOnFailure
인 VM이 다시 예약됩니다.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachine
spec:
RunStrategy: Always 1
template:
...
- 1
- VMI의 현재
RunStrategy
설정입니다.
7.1.5. 추가 리소스
KubeVirt v0.34.1 API 참조의
VirtualMachineSpec
정의에는 가상 머신 사양에 대한 매개변수 및 계층 구조에 대한 광범위한 컨텍스트가 있습니다.참고KubeVirt API 참조는 업스트림 프로젝트 참조이며 OpenShift Virtualization에서 지원되지 않는 매개변수를 포함할 수 있습니다.
-
가상 머신에
containerDisk
볼륨으로 추가할 컨테이너 디스크를 준비합니다. - 머신 상태 점검 배포 및 활성화에 대한 자세한 내용은 머신 상태 점검 배포를 참조하십시오.
- 설치 관리자 프로비저닝 인프라에 대한 자세한 내용은 설치 관리자 프로비저닝 인프라 개요를 참조하십시오.
7.2. 가상 머신 편집
웹 콘솔의 YAML 편집기를 사용하거나 명령줄에서 OpenShift 클라이언트를 사용하여 가상 머신 구성을 업데이트할 수 있습니다. 웹 콘솔의 가상 머신 개요에서 매개변수 서브 세트를 업데이트할 수도 있습니다.
7.2.1. 웹 콘솔에서 가상 머신 편집
관련 필드 옆에 있는 연필 아이콘을 클릭하여 웹 콘솔의 가상 머신 개요 화면에서 가상 머신에 대해 선택된 값을 편집합니다. CLI를 사용하여 다른 값을 편집할 수 있습니다.
프로세스
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 가상 머신을 선택하여 가상 머신 개요 화면을 엽니다.
- 세부 정보 탭을 클릭합니다.
- 연필 아이콘을 클릭하여 필드를 편집할 수 있도록 합니다.
- 관련 사항을 변경하고 저장을 클릭합니다.
가상 머신이 실행 중인 경우 가상 머신을 재시작해야 Boot Order 또는 Flavor에 대한 변경 사항이 적용됩니다.
관련 필드의 오른쪽에서 보류 중인 변경 사항 보기를 클릭하여 보류 중인 변경 사항을 볼 수 있습니다. 페이지 상단의 보류 중인 변경 사항 배너에는 가상 머신이 재시작될 때 적용되는 모든 변경 사항 목록이 표시됩니다.
7.2.2. 웹 콘솔을 사용하여 가상 머신 YAML 구성 편집
웹 콘솔을 사용하여 가상 머신의 YAML 구성을 편집합니다.
일부 매개변수는 업데이트할 수 없습니다. 변경할 수 없는 값을 편집하고 저장을 클릭하면 오류 메시지에 업데이트할 수 없는 매개변수가 표시됩니다.
YAML 구성은 가상 머신이 실행 중인 동안 편집할 수 있지만, 변경 사항은 가상 머신을 중지했다가 다시 시작한 후에만 적용됩니다.
편집하는 동안 YAML 화면을 벗어나면 구성 변경 사항이 취소됩니다.
절차
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 가상 머신을 선택하여 가상 머신 개요 화면을 엽니다.
- YAML 탭을 클릭하여 편집 가능한 구성을 표시합니다.
- 선택 사항: Download (다운로드)를 클릭하여 YAML 파일을 현재 상태로 로컬로 다운로드할 수 있습니다.
- 파일을 편집하고 저장을 클릭합니다.
확인 메시지는 수정이 완료되었음을 나타내며 오브젝트의 업데이트된 버전 번호를 포함합니다.
7.2.3. CLI를 사용하여 가상 머신 YAML 구성 편집
CLI를 사용하여 가상 머신 YAML 구성을 편집하려면 다음 절차를 사용하십시오.
사전 요구 사항
- YAML 오브젝트 구성 파일을 사용하여 가상 머신을 구성했습니다.
-
oc
CLI를 설치했습니다.
절차
다음 명령을 실행하여 가상 머신 구성을 업데이트합니다.
$ oc edit <object_type> <object_ID>
- 오브젝트 구성을 엽니다.
- YAML을 편집합니다.
실행 중인 가상 머신을 편집하는 경우 다음 중 하나를 수행해야 합니다.
- 가상 머신을 재시작합니다.
새 구성을 적용하려면 다음 명령을 실행합니다.
$ oc apply <object_type> <object_ID>
7.2.4. 가상 머신에 가상 디스크 추가
가상 디스크를 가상 머신에 추가하려면 다음 절차를 사용하십시오.
절차
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 가상 머신을 선택하여 가상 머신 개요 화면을 엽니다.
- 디스크 탭을 클릭합니다.
- 디스크 추가를 클릭하여 디스크 추가 창을 엽니다.
디스크 추가 창에서 소스, 이름, 크기, 인터페이스, 유형, 스토리지 클래스를 지정합니다.
-
선택 사항: 고급 목록에서 가상 디스크의 볼륨 모드 및 액세스 모드를 지정합니다. 이러한 매개변수를 지정하지 않으면
kubevirt-storage-class-defaults
구성 맵의 기본값이 사용됩니다.
-
선택 사항: 고급 목록에서 가상 디스크의 볼륨 모드 및 액세스 모드를 지정합니다. 이러한 매개변수를 지정하지 않으면
- 추가를 클릭합니다.
가상 머신이 실행 중인 경우 새 디스크는 재시작 보류 상태에 있으며, 가상 머신을 재시작할 때까지 연결되지 않습니다.
페이지 상단의 보류 중인 변경 사항 배너에는 가상 머신이 재시작될 때 적용되는 모든 변경 사항 목록이 표시됩니다.
kubevirt-storage-class-defaults
구성 맵에 대한 자세한 내용은 데이터 볼륨의 스토리지 기본값을 참조하십시오.
7.2.4.1. 스토리지 필드
이름 | 설명 |
---|---|
소스 | 가상 머신의 빈 디스크를 선택하거나 사용 가능한 옵션 중에서 선택합니다. URL,컨테이너,복제된 디스크 연결 또는 디스크 연결. 기존 디스크를 선택하여 가상 머신에 연결하려면 사용 가능한 PVC(영구 볼륨 클레임) 목록에서 복제된 디스크 연결 또는 디스크 연결을 선택합니다. |
이름 |
디스크 이름입니다. 이름에는 소문자( |
크기(GiB) | 디스크 크기(GiB)입니다. |
인터페이스 | 디스크 장치의 유형입니다. 지원되는 인터페이스는 virtIO, SATA, SCSI입니다. |
스토리지 클래스 | 디스크를 만드는 데 사용되는 스토리지 클래스입니다. |
고급 → 볼륨 모드 | 영구 볼륨에서 포맷된 파일 시스템을 사용하는지 또는 원시 블록 상태를 사용하는지를 정의합니다. 기본값은 Filesystem입니다. |
고급 → 액세스 모드 | 영구 볼륨의 액세스 모드입니다. 지원되는 액세스 모드는 ReadWriteOnce, ReadOnlyMany, ReadWriteMany입니다. |
고급 스토리지 설정
다음 고급 스토리지 설정은 비어 있음, URL을 통해 가져오기, 기존 PVC 복제 디스크에 사용할 수 있습니다. 해당 매개변수는 선택 사항입니다. 이러한 매개변수를 지정하지 않으면 kubevirt-storage-class-defaults
구성 맵의 기본값이 사용됩니다.
이름 | 매개변수 | 설명 |
---|---|---|
볼륨 모드 | 파일 시스템 | 파일 시스템 기반 볼륨에 가상 디스크를 저장합니다. |
블록 |
가상 디스크를 블록 볼륨에 직접 저장합니다. 기본 스토리지에서 지원하는 경우에만 | |
액세스 모드 | 단일 사용자(RWO) | 디스크는 단일 노드에서 읽기/쓰기로 마운트할 수 있습니다. |
공유 액세스(RWX) | 디스크는 여러 노드에서 읽기/쓰기로 마운트할 수 있습니다. 참고 이는 가상 머신의 노드 간 실시간 마이그레이션 등 일부 기능에 필요합니다. | |
읽기 전용(ROX) | 디스크는 많은 노드에서 읽기 전용으로 마운트할 수 있습니다. |
7.2.5. 가상 머신에 네트워크 인터페이스 추가
가상 머신에 네트워크 인터페이스를 추가하려면 다음 절차를 사용하십시오.
절차
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 가상 머신을 선택하여 가상 머신 개요 화면을 엽니다.
- 네트워크 인터페이스 탭을 클릭합니다.
- 네트워크 인터페이스 추가를 클릭합니다.
- 네트워크 인터페이스 추가 창에서 네트워크 인터페이스의 이름, 모델, 네트워크, 유형, MAC 주소를 지정합니다.
- 추가를 클릭합니다.
가상 머신이 실행 중인 경우 새 네트워크 인터페이스는 재시작 보류 상태에 있으며, 가상 머신을 재시작할 때까지 변경 사항이 적용되지 않습니다.
페이지 상단의 보류 중인 변경 사항 배너에는 가상 머신이 재시작될 때 적용되는 모든 변경 사항 목록이 표시됩니다.
7.2.5.1. 네트워킹 필드
이름 | 설명 |
---|---|
이름 | 네트워크 인터페이스 컨트롤러의 이름입니다. |
모델 | 네트워크 인터페이스 컨트롤러의 모델을 나타냅니다. 지원되는 값은 e1000e 및 virtio입니다. |
네트워크 | 사용 가능한 네트워크 연결 정의 목록입니다. |
유형 |
사용 가능한 바인딩 방법 목록입니다. 기본 Pod 네트워크의 경우 권장되는 유일한 바인딩 방법은 |
MAC 주소 | 네트워크 인터페이스 컨트롤러의 MAC 주소입니다. MAC 주소를 지정하지 않으면 주소가 자동으로 할당됩니다. |
7.2.6. 가상 머신의 CD-ROM 편집
가상 머신에 CD-ROM을 구성하려면 다음 절차를 사용하십시오.
프로세스
- 가상 머신 탭에서 가상 머신을 선택합니다.
- 개요 탭을 선택합니다.
CD-ROM 구성을 추가하거나 편집하려면 CD-ROM 라벨 오른쪽에 있는 연필 아이콘을 클릭합니다. CD-ROM 편집 창이 열립니다.
- CD-ROM을 편집할 수 없는 경우 다음 메시지가 표시됩니다. 가상 시스템에 CD-ROM이 연결되어 있지 않습니다.
- 사용 가능한 CD-ROM이 있는 경우 -를 클릭하여 CD-ROM을 제거할 수 있습니다.
CD-ROM 편집 창에서 다음을 수행합니다.
- 미디어 유형 드롭다운 목록에서 CD-ROM 구성 유형을 선택합니다. CD-ROM 구성 유형은 컨테이너, URL, 영구 볼륨 클레임입니다.
- 각 유형에 필요한 정보를 입력합니다.
- 모든 CD-ROM이 추가되면 저장을 클릭합니다.
7.3. 부팅 순서 편집
웹 콘솔 또는 CLI를 사용하여 부팅 순서 목록 값을 업데이트할 수 있습니다.
가상 머신 개요 페이지의 부팅 순서를 사용하여 다음을 수행할 수 있습니다.
- 디스크 또는 NIC(네트워크 인터페이스 컨트롤러)를 선택하고 부팅 순서 목록에 추가합니다.
- 부팅 순서 목록에서 디스크 또는 NIC 순서를 편집합니다.
- 부팅 순서 목록에서 디스크 또는 NIC를 제거하고 부팅 가능 소스 인벤토리로 반환합니다.
7.3.1. 웹 콘솔에서 부팅 순서 목록에 항목 추가
웹 콘솔을 사용하여 부팅 순서 목록에 항목을 추가합니다.
절차
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 가상 머신을 선택하여 가상 머신 개요 화면을 엽니다.
- 세부 정보 탭을 클릭합니다.
- 부팅 순서 오른쪽에 있는 연필 아이콘을 클릭합니다. YAML 구성이 없거나 처음으로 부팅 순서 목록을 생성하는 경우 다음 메시지가 표시됩니다. 리소스가 선택되어 있지 않습니다. VM은 YAML 파일에 나타나는 순서에 따라 디스크에서 부팅하려고 합니다.
- 소스 추가를 클릭하고 가상 시스템의 부팅 가능한 디스크 또는 NIC(네트워크 인터페이스 컨트롤러)를 선택합니다.
- 부팅 순서 목록에 추가 디스크 또는 NIC를 추가합니다.
- 저장을 클릭합니다.
가상 머신이 실행 중인 경우 가상 머신을 재시작해야 Boot Order 변경 사항이 적용됩니다.
부팅 순서 필드 오른쪽에 있는 보류 중인 변경 사항 보기를 클릭하면 보류 중인 변경 사항을 볼 수 있습니다. 페이지 상단의 보류 중인 변경 사항 배너에는 가상 머신이 재시작될 때 적용되는 모든 변경 사항 목록이 표시됩니다.
7.3.2. 웹 콘솔에서 부팅 순서 목록 편집
웹 콘솔에서 부팅 순서 목록을 편집합니다.
절차
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 가상 머신을 선택하여 가상 머신 개요 화면을 엽니다.
- 세부 정보 탭을 클릭합니다.
- 부팅 순서 오른쪽에 있는 연필 아이콘을 클릭합니다.
부팅 순서 목록에서 항목을 이동하는 적절한 방법을 선택합니다.
- 화면 판독기를 사용하지 않는 경우 이동할 항목 옆에 있는 화살표 아이콘 위로 마우스를 가져가서 항목을 위 또는 아래로 끌어 원하는 위치에 놓습니다.
- 화면 판독기를 사용하는 경우 위쪽 화살표 키 또는 아래쪽 화살표 키를 눌러 부팅 순서 목록에서 항목을 이동합니다. 그런 다음 Tab 키를 눌러 원하는 위치에 항목을 놓습니다.
- 저장을 클릭합니다.
가상 머신이 실행중인 경우 가상 머신을 재시작해야 부팅 순서 목록의 변경 사항이 적용됩니다.
부팅 순서 필드 오른쪽에 있는 보류 중인 변경 사항 보기를 클릭하면 보류 중인 변경 사항을 볼 수 있습니다. 페이지 상단의 보류 중인 변경 사항 배너에는 가상 머신이 재시작될 때 적용되는 모든 변경 사항 목록이 표시됩니다.
7.3.3. YAML 구성 파일의 부팅 순서 목록 편집
CLI를 사용하여 YAML 구성 파일의 부팅 순서 목록을 편집합니다.
절차
다음 명령을 실행하여 가상 머신의 YAML 구성 파일을 엽니다.
$ oc edit vm example
YAML 파일을 편집하고 디스크 또는 NIC(네트워크 인터페이스 컨트롤러)와 연결된 부팅 순서 값을 수정합니다. 예를 들면 다음과 같습니다.
disks: - bootOrder: 1 1 disk: bus: virtio name: containerdisk - disk: bus: virtio name: cloudinitdisk - cdrom: bus: virtio name: cd-drive-1 interfaces: - boot Order: 2 2 macAddress: '02:96:c4:00:00' masquerade: {} name: default
- YAML 파일을 저장합니다.
- 컨텐츠 다시 로드를 클릭하여 YAML 파일의 업데이트된 부팅 순서 값을 웹 콘솔의 부팅 순서 목록에 적용합니다.
7.3.4. 웹 콘솔의 부팅 순서 목록에서 항목 제거
웹 콘솔을 사용하여 부팅 순서 목록에서 항목을 제거합니다.
절차
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 가상 머신을 선택하여 가상 머신 개요 화면을 엽니다.
- 세부 정보 탭을 클릭합니다.
- 부팅 순서 오른쪽에 있는 연필 아이콘을 클릭합니다.
- 해당 항목 옆에 있는 제거 아이콘 을 클릭합니다. 항목이 부팅 순서 목록에서 제거되고 사용 가능한 부팅 소스 목록에 저장됩니다. 부팅 순서 목록에서 모든 항목을 제거하면 다음 메시지가 표시됩니다. 리소스가 선택되어 있지 않습니다. VM은 YAML 파일에 나타나는 순서에 따라 디스크에서 부팅하려고 합니다.
가상 머신이 실행 중인 경우 가상 머신을 재시작해야 Boot Order 변경 사항이 적용됩니다.
부팅 순서 필드 오른쪽에 있는 보류 중인 변경 사항 보기를 클릭하면 보류 중인 변경 사항을 볼 수 있습니다. 페이지 상단의 보류 중인 변경 사항 배너에는 가상 머신이 재시작될 때 적용되는 모든 변경 사항 목록이 표시됩니다.
7.4. 가상 머신 삭제
웹 콘솔에서 또는 oc
명령줄 인터페이스를 사용하여 가상 머신을 삭제할 수 있습니다.
7.4.1. 웹 콘솔을 사용하여 가상 머신 삭제
가상 머신을 삭제하면 클러스터에서 가상 머신이 영구적으로 제거됩니다.
가상 머신을 삭제하면 사용하는 데이터 볼륨이 자동으로 삭제됩니다.
절차
- OpenShift Virtualization 콘솔의 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
삭제할 가상 머신의 ⋮ 버튼을 클릭하고 가상 머신 삭제를 선택합니다.
- 또는 가상 머신 이름을 클릭하여 가상 머신 개요 화면을 열고 작업 → 가상 머신 삭제를 클릭합니다.
- 확인 팝업 창에서 삭제를 클릭하여 가상 머신을 영구적으로 삭제합니다.
7.4.2. CLI를 사용하여 가상 머신 삭제
oc
CLI(명령줄 인터페이스)를 사용하여 가상 머신을 삭제할 수 있습니다. oc
클라이언트를 사용하면 여러 가상 머신에서 작업을 수행할 수 있습니다.
가상 머신을 삭제하면 사용하는 데이터 볼륨이 자동으로 삭제됩니다.
사전 요구 사항
- 삭제할 가상 머신의 이름을 확인합니다.
절차
다음 명령을 실행하여 가상 머신을 삭제합니다.
$ oc delete vm <vm_name>
참고이 명령은 현재 프로젝트에 존재하는 오브젝트만 삭제합니다. 삭제하려는 오브젝트가 다른 프로젝트 또는 네임스페이스에 있는 경우
-n <project_name>
옵션을 지정하십시오.
7.5. 가상 머신 인스턴스 관리
OpenShift Virtualization 환경 외부에서 독립적으로 생성된 독립 실행형 VMI(가상 머신 인스턴스)가 있는 경우, 웹 콘솔 또는 CLI(명령줄 인터페이스)를 사용하여 이러한 인스턴스를 관리할 수 있습니다.
7.5.1. 가상 머신 인스턴스 정보
VMI(가상 머신 인스턴스)는 실행 중인 VM(가상 머신)을 나타냅니다. VMI가 VM 또는 다른 오브젝트에 속하는 경우, 웹 콘솔의 해당 소유자를 통해 또는 oc
CLI(명령줄 인터페이스)를 사용하여 VMI를 관리합니다.
독립 실행형 VMI는 스크립트, 자동화 또는 CLI의 다른 방법을 통해 독립적으로 생성 및 시작됩니다. OpenShift Virtualization 환경 외부에서 개발 및 시작된 독립 실행형 VMI가 사용자 환경에 있을 수 있습니다. CLI를 사용하여 이러한 독립 실행형 VMI를 계속 관리할 수 있습니다. 다음과 같이 독립 실행형 VMI와 관련된 특정 작업에 웹 콘솔을 사용할 수도 있습니다.
- 독립 실행형 VMI 및 세부 정보를 나열합니다.
- 독립 실행형 VMI의 라벨 및 주석을 편집합니다.
- 독립 실행형 VMI를 삭제합니다.
VM을 삭제하면 관련 VMI가 자동으로 삭제됩니다. 독립 실행형 VMI는 VM 또는 다른 오브젝트에 속하지 않기 때문에 직접 삭제합니다.
OpenShift Virtualization을 설치 제거하기 전에 CLI 또는 웹 콘솔을 사용하여 독립 실행형 VMI를 나열하고 확인하십시오. 그런 다음 처리 중인 VMI를 삭제합니다.
7.5.2. CLI를 사용하여 모든 가상 머신 인스턴스 나열
oc
CLI(명령줄 인터페이스)를 사용하면 독립 실행형 VMI(가상 머신 인스턴스) 및 가상 머신에 속하는 VMI를 포함하여 클러스터의 모든 VMI를 나열할 수 있습니다.
절차
다음 명령을 실행하여 VMI를 모두 나열합니다.
$ oc get vmis
7.5.3. 웹 콘솔을 사용하여 독립 실행형 가상 머신 인스턴스 나열
웹 콘솔을 사용하면 VM(가상 머신)에 속하지 않는 클러스터의 독립 실행형 VMI(가상 머신 인스턴스)를 나열하고 확인할 수 있습니다.
VM 또는 다른 오브젝트에 속하는 VMI는 웹 콘솔에 표시되지 않습니다. 웹 콘솔에는 독립 실행형 VMI만 표시됩니다. 클러스터의 모든 VMI를 나열하려면 CLI를 사용해야 합니다.
절차
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다. VM 및 독립 실행형 VMI 목록이 표시됩니다. 독립 실행형 VMI에는 가상 머신 인스턴스 이름 옆에 어두운 색상의 배지가 표시됩니다.
7.5.4. 웹 콘솔을 사용하여 독립 실행형 가상 머신 인스턴스 편집
웹 콘솔을 사용하여 독립 실행형 VMI(가상 머신 인스턴스)의 주석 및 라벨을 편집할 수 있습니다. 독립 실행형 VMI의 세부 정보 페이지에 표시되는 기타 항목은 편집할 수 없습니다.
절차
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다. VM(가상 머신) 및 독립 실행형 VMI 목록이 표시됩니다.
- 독립 실행형 VMI의 이름을 클릭하여 가상 머신 인스턴스 개요 화면을 엽니다.
- 세부 정보 탭을 클릭합니다.
- 주석 오른쪽에 있는 연필 아이콘을 클릭합니다.
- 관련 사항을 변경하고 저장을 클릭합니다.
독립 실행형 VMI의 라벨을 편집하려면 작업을 클릭하고 라벨 편집을 선택하십시오. 관련 사항을 변경하고 저장을 클릭합니다.
7.5.5. CLI를 사용하여 독립 실행형 가상 머신 인스턴스 삭제
oc
CLI(명령줄 인터페이스)를 사용하여 독립 실행형 VMI(가상 머신 인스턴스)를 삭제할 수 있습니다.
사전 요구 사항
- 삭제할 VMI의 이름을 확인합니다.
절차
다음 명령을 실행하여 VMI를 삭제합니다.
$ oc delete vmi <vmi_name>
7.5.6. 웹 콘솔을 사용하여 독립 실행형 가상 머신 인스턴스 삭제
웹 콘솔에서 독립 실행형 VMI(가상 머신 인스턴스)를 삭제합니다.
절차
- OpenShift Container Platform 웹 콘솔의 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
삭제할 독립 실행형 VMI(가상 머신 인스턴스)의 ⋮ 버튼을 클릭하고 가상 머신 인스턴스 삭제를 선택합니다.
- 또는 독립 실행형 VMI의 이름을 클릭합니다. 가상 머신 인스턴스 개요 페이지가 표시됩니다.
- 작업 → 가상 머신 인스턴스 삭제를 선택합니다.
- 확인 팝업 창에서 삭제를 클릭하여 독립 실행형 VMI를 영구적으로 삭제합니다.
7.6. 가상 머신 상태 제어
웹 콘솔에서 가상 머신을 중지, 시작, 재시작, 일시 정지 해제할 수 있습니다.
CLI(명령줄 인터페이스)에서 가상 머신을 제어하려면 virtctl
client를 사용하십시오.
7.6.1. 가상 머신 시작
웹 콘솔에서 가상 머신을 시작할 수 있습니다.
절차
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 시작할 가상 머신이 포함된 행을 찾습니다.
사용 사례에 적합한 메뉴로 이동합니다.
여러 가상 머신에서 작업을 수행할 수 있는 이 페이지를 유지하려면 다음을 수행하십시오.
- 행의 맨 오른쪽 끝에 있는 옵션 메뉴 를 클릭합니다.
시작하기 전에 선택한 가상 머신에 대한 포괄적인 정보를 보려면 다음을 수행하십시오.
- 가상 머신 이름을 클릭하여 가상 머신 개요 화면에 액세스합니다.
- 작업을 클릭합니다.
- 가상 머신 시작을 선택합니다.
- 확인 창에서 시작을 클릭하여 가상 머신을 시작합니다.
URL
소스에서 프로비저닝된 가상 머신을 처음 시작하면 가상 머신의 상태가 가져오는 중이 되고 OpenShift Virtualization은 URL 끝점에서 컨테이너를 가져옵니다. 이미지 크기에 따라 이 프로세스에 몇 분이 걸릴 수 있습니다.
7.6.2. 가상 머신 재시작
웹 콘솔에서 실행 중인 가상 머신을 재시작할 수 있습니다.
오류를 방지하려면 가져오는 중 상태의 가상 머신을 재시작하지 마십시오.
절차
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 재시작할 가상 머신이 포함된 행을 찾습니다.
사용 사례에 적합한 메뉴로 이동합니다.
여러 가상 머신에서 작업을 수행할 수 있는 이 페이지를 유지하려면 다음을 수행하십시오.
- 행의 맨 오른쪽 끝에 있는 옵션 메뉴 를 클릭합니다.
재시작하기 전에 선택한 가상 머신에 대한 포괄적인 정보를 보려면 다음을 수행하십시오.
- 가상 머신 이름을 클릭하여 가상 머신 개요 화면에 액세스합니다.
- 작업을 클릭합니다.
- 가상 머신 재시작을 선택합니다.
- 확인 창에서 재시작을 클릭하여 가상 머신을 재시작합니다.
7.6.3. 가상 머신 중지
웹 콘솔에서 가상 머신을 중지할 수 있습니다.
절차
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 중지할 가상 머신이 포함된 행을 찾습니다.
사용 사례에 적합한 메뉴로 이동합니다.
여러 가상 머신에서 작업을 수행할 수 있는 이 페이지를 유지하려면 다음을 수행하십시오.
- 행의 맨 오른쪽 끝에 있는 옵션 메뉴 를 클릭합니다.
중지하기 전에 선택한 가상 머신에 대한 포괄적인 정보를 보려면 다음을 수행하십시오.
- 가상 머신 이름을 클릭하여 가상 머신 개요 화면에 액세스합니다.
- 작업을 클릭합니다.
- 가상 머신 중지를 선택합니다.
- 확인 창에서 중지를 클릭하여 가상 머신을 중지합니다.
7.6.4. 가상 머신 정지 해제
웹 콘솔에서 일시 정지된 가상 머신의 일시 정지를 해제할 수 있습니다.
사전 요구 사항
가상 머신 중 하나 이상의 상태가 일시 정지됨이어야 합니다.
참고virtctl
클라이언트를 사용하여 가상 머신을 일시 정지할 수 있습니다.
절차
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 일시 정지를 해제할 가상 머신이 포함된 행을 찾습니다.
사용 사례에 적합한 메뉴로 이동합니다.
여러 가상 머신에서 작업을 수행할 수 있는 이 페이지를 유지하려면 다음을 수행하십시오.
- 상태 열에서 일시 정지됨을 클릭합니다.
일시 정지하기 전에 선택한 가상 머신에 대한 포괄적인 정보를 보려면 다음을 수행하십시오.
- 가상 머신 이름을 클릭하여 가상 머신 개요 화면에 액세스합니다.
- 상태 오른쪽에 있는 연필 아이콘을 클릭합니다.
- 확인 창에서 일시 정지 해제를 클릭하여 가상 머신의 일시 정지를 해제합니다.
7.7. 가상 머신 콘솔에 액세스
OpenShift Virtualization에서는 다양한 제품 작업을 수행할 수 있도록 여러 개의 가상 머신 콘솔을 제공합니다. OpenShift Container Platform 웹 콘솔과 CLI 명령을 사용하여 이러한 콘솔에 액세스할 수 있습니다.
7.7.1. OpenShift Container Platform 웹 콘솔에서 가상 머신 콘솔에 액세스
OpenShift Container Platform 웹 콘솔에서 직렬 콘솔 또는 VNC 콘솔을 사용하여 가상 머신에 연결할 수 있습니다.
OpenShift Container Platform 웹 콘솔에서 RDP(원격 데스크탑 프로토콜)를 사용하는 데스크탑 뷰어 콘솔을 사용하여 Windows 가상 머신에 연결할 수 있습니다.
7.7.1.1. 직렬 콘솔 연결
웹 콘솔의 가상 머신 개요 화면에 있는 콘솔 탭에서 실행 중인 가상 머신 의 직렬 콘솔에 연결합니다.
절차
- OpenShift Virtualization 콘솔의 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 가상 머신을 선택하여 가상 머신 개요 페이지를 엽니다.
- 콘솔을 클릭합니다. 기본적으로 VNC 콘솔이 열립니다.
- 전환 전에 연결 끊기 를 선택하여 한 번에 하나의 콘솔 세션만 열려 있는지 확인합니다. 그렇지 않으면 VNC 콘솔 세션이 백그라운드에서 활성 상태로 유지됩니다.
- VNC 콘솔 드롭다운 목록을 클릭하고 직렬 콘솔을 선택합니다.
- 연결 끊기 를 클릭하여 콘솔 세션을 종료합니다.
- 선택 사항: 새 창에서 콘솔 열기를 클릭하여 직렬 콘솔을 별도의 창에서 엽니다.
7.7.1.2. VNC 콘솔에 연결
웹 콘솔의 가상 머신 개요 화면에 있는 콘솔 탭에서 실행 중인 가상 머신의 VNC 콘솔에 연결합니다.
절차
- OpenShift Virtualization 콘솔의 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 가상 머신을 선택하여 가상 머신 개요 페이지를 엽니다.
- 콘솔 탭을 클릭합니다. 기본적으로 VNC 콘솔이 열립니다.
- 선택 사항: 새 창에서 콘솔 열기를 클릭하여 VNC 콘솔을 별도의 창에서 엽니다.
- 선택 사항: 키 보내기를 클릭하여 가상 머신에 키 조합을 보냅니다.
7.7.1.3. RDP를 사용하여 Windows 가상 머신에 연결
RDP(원격 데스크탑 프로토콜)를 사용하는 데스크탑 뷰어 콘솔에서는 Windows 가상 머신 연결을 위해 개선된 콘솔 환경을 제공합니다.
RDP를 사용하여 Windows 가상 머신에 연결하려면 웹 콘솔의 가상 머신 세부 정보 화면에 있는 콘솔 탭에서 가상 머신에 대한 console.rdp
파일을 다운로드하여 선호하는 RDP 클라이언트에 제공하십시오.
사전 요구 사항
-
Windows 가상 머신이 실행 중이고 QEMU 게스트 에이전트가 설치되어 있습니다.
qemu-guest-agent
는 VirtIO 드라이버에 포함되어 있습니다. - 계층 2 NIC가 가상 머신에 연결되어 있습니다.
- RDP 클라이언트가 Windows 가상 머신과 동일한 네트워크의 머신에 설치되어 있습니다.
절차
- OpenShift Virtualization 콘솔의 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- Windows 가상 머신을 선택하여 가상 머신 개요 화면을 엽니다.
- 콘솔 탭을 클릭합니다.
- 콘솔 목록에서 데스크탑 뷰어를 선택합니다.
- 네트워크 인터페이스 목록에서 계층 2 NIC를 선택합니다.
-
원격 데스크탑 시작을 클릭하여
console.rdp
파일을 다운로드합니다. RDP 클라이언트를 열고
console.rdp
파일을 참조합니다. 예를 들면 다음과 같이 remmina를 사용합니다.$ remmina --connect /path/to/console.rdp
- 관리자 이름 및 암호를 입력하여 Windows 가상 머신에 연결합니다.
7.7.1.4. 웹 콘솔에서 SSH 명령 복사
웹 콘솔의 Actions 목록에서 SSH를 통해 실행 중인 VM(가상 머신)에 액세스하려면 명령을 복사합니다.
절차
- OpenShift Container Platform 콘솔의 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 가상 머신을 선택하여 가상 머신 개요 페이지를 엽니다.
-
작업 목록에서 SSH 명령 복사 를 선택합니다. 이제 이 명령을 OpenShift CLI(
oc
)에 붙여넣을 수 있습니다.
7.7.2. CLI 명령을 사용하여 가상 머신 콘솔에 액세스
7.7.2.1. SSH를 통해 가상 머신 인스턴스에 액세스
VM(가상 머신)에 포트 22를 노출하면 SSH를 사용하여 VM에 액세스할 수 있습니다.
virtctl expose
명령은 VMI(가상 머신 인스턴스) 포트를 노드 포트에 전달하고, 활성화된 액세스 권한에 대해 서비스를 생성합니다. 다음 예에서는 클러스터 노드의 특정 포트에서 <fedora-vm>
가상 머신의 포트 22로 트래픽을 전달하는 fedora-vm-ssh
서비스를 생성합니다.
사전 요구 사항
- VMI와 동일한 프로젝트에 있어야 합니다.
-
액세스하려는 VMI가
가상
바인딩 방법을 사용하여 기본 Pod 네트워크에 연결되어 있어야 합니다. - 액세스하려는 VMI가 실행 중이어야 합니다.
-
OpenShift CLI(
oc
)를 설치합니다.
절차
다음 명령을 실행하여
fedora-vm-ssh
서비스를 생성합니다.$ virtctl expose vm <fedora-vm> --port=22 --name=fedora-vm-ssh --type=NodePort 1
- 1
<fedora-vm>
은fedora-vm-ssh
서비스를 실행하는 VM의 이름입니다.
서비스를 점검하여 서비스에서 감지한 포트를 확인합니다.
$ oc get svc
출력 예
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE fedora-vm-ssh NodePort 127.0.0.1 <none> 22:32551/TCP 6s
+ 이 예에서는 서비스에서 32551
포트를 감지합니다.
SSH를 통해 VMI에 로그인합니다. 클러스터 노드의
ipAddress
및 이전 단계에서 찾은 포트를 사용하십시오.$ ssh username@<node_IP_address> -p 32551
7.7.2.2. 가상 머신 인스턴스의 직렬 콘솔에 액세스
virtctl console
명령은 지정된 가상 머신 인스턴스에 대한 직렬 콘솔을 엽니다.
사전 요구 사항
-
virt-viewer
패키지가 설치되어 있어야 합니다. - 액세스하려는 가상 머신 인스턴스가 실행 중이어야 합니다.
절차
virtctl
을 사용하여 직렬 콘솔에 연결합니다.$ virtctl console <VMI>
7.7.2.3. VNC를 사용하여 가상 머신 인스턴스의 그래픽 콘솔에 액세스
virtctl
클라이언트 유틸리티는 remote-viewer
기능을 사용하여 실행 중인 가상 머신 인스턴스에 대해 그래픽 콘솔을 열 수 있습니다. 이 기능은 virt-viewer
패키지에 포함되어 있습니다.
사전 요구 사항
-
virt-viewer
패키지가 설치되어 있어야 합니다. - 액세스하려는 가상 머신 인스턴스가 실행 중이어야 합니다.
원격 머신에서 SSH를 통해 virtctl
을 사용하는 경우 X 세션을 머신으로 전달해야 합니다.
절차
virtctl
유틸리티를 사용하여 그래픽 인터페이스에 연결합니다.$ virtctl vnc <VMI>
명령이 실패하는 경우
-v
플래그를 사용하여 문제 해결 정보를 수집합니다.$ virtctl vnc <VMI> -v 4
7.7.2.4. RDP 콘솔을 사용하여 Windows 가상 머신에 연결
RDP(원격 데스크탑 프로토콜)에서는 Windows 가상 머신 연결을 위해 개선된 콘솔 환경을 제공합니다.
RDP를 사용하여 Windows 가상 머신에 연결하려면 연결된 L2 NIC의 IP 주소를 RDP 클라이언트로 지정하십시오.
사전 요구 사항
-
Windows 가상 머신이 실행 중이고 QEMU 게스트 에이전트가 설치되어 있습니다.
qemu-guest-agent
는 VirtIO 드라이버에 포함되어 있습니다. - 계층 2 NIC가 가상 머신에 연결되어 있습니다.
- RDP 클라이언트가 Windows 가상 머신과 동일한 네트워크의 머신에 설치되어 있습니다.
절차
oc
CLI 툴을 통해 액세스 토큰이 있는 사용자로 OpenShift Virtualization 클러스터에 로그인합니다.$ oc login -u <user> https://<cluster.example.com>:8443
oc describe vmi
를 사용하여 실행 중인 Windows 가상 머신의 구성을 표시합니다.$ oc describe vmi <windows-vmi-name>
출력 예
... spec: networks: - name: default pod: {} - multus: networkName: cnv-bridge name: bridge-net ... status: interfaces: - interfaceName: eth0 ipAddress: 198.51.100.0/24 ipAddresses: 198.51.100.0/24 mac: a0:36:9f:0f:b1:70 name: default - interfaceName: eth1 ipAddress: 192.0.2.0/24 ipAddresses: 192.0.2.0/24 2001:db8::/32 mac: 00:17:a4:77:77:25 name: bridge-net ...
-
계층 2 네트워크 인터페이스의 IP 주소를 확인하고 복사합니다. 위 예제에서는
192.0.2.0
이며, IPv6를 선호하는 경우2001:db8::
입니다. - RDP 클라이언트를 열고 이전 단계에서 복사한 IP 주소를 사용하여 연결합니다.
- 관리자 이름 및 암호를 입력하여 Windows 가상 머신에 연결합니다.
7.8. 실패한 노드를 해결하여 가상 머신 장애 조치 트리거
노드가 실패하고 머신 상태 점검이 클러스터에 배포되지 않으면 RunStrategy가 있는 VM(가상 머신)이 포함됩니다. always
구성된 위치는 자동으로 정상 노드로 재배치되지 않습니다. VM 장애 조치를 트리거하려면 Node
오브젝트를 수동으로 삭제해야 합니다.
설치 관리자 프로비저닝 인프라를 사용하여 클러스터를 설치하고 머신 상태 점검을 올바르게 구성한 경우
- 실패한 노드는 자동으로 재활용됩니다.
-
RunStrategy
가Always
또는RerunOnFailure
로 설정된 가상 머신은 정상 노드에 자동으로 예약됩니다.
7.8.1. 사전 요구 사항
-
가상 머신을 실행 중이던 노드에
NotReady
조건이 있습니다. -
실패한 노드에서 실행 중이던 가상 머신의
RunStrategy
가Always
로 설정되어 있습니다. -
OpenShift CLI(
oc
)가 설치되어 있습니다.
7.8.2. 베어 메탈 클러스터에서 노드 삭제
CLI를 사용하여 노드를 삭제하면 Kubernetes에서 노드 오브젝트가 삭제되지만 노드에 존재하는 Pod는 삭제되지 않습니다. 복제 컨트롤러에서 지원하지 않는 기본 Pod는 OpenShift Container Platform에 액세스할 수 없습니다. 복제 컨트롤러에서 지원하는 Pod는 사용 가능한 다른 노드로 다시 예약됩니다. 로컬 매니페스트 Pod를 삭제해야 합니다.
절차
다음 단계를 완료하여 베어 메탈에서 실행 중인 OpenShift Container Platform 클러스터에서 노드를 삭제합니다.
노드를 예약 불가능으로 표시합니다.
$ oc adm cordon <node_name>
노드의 모든 Pod를 드레이닝합니다.
$ oc adm drain <node_name> --force=true
노드가 오프라인 상태이거나 응답하지 않는 경우 이 단계가 실패할 수 있습니다. 노드가 응답하지 않더라도 공유 스토리지에 쓰는 워크로드를 계속 실행되고 있을 수 있습니다. 데이터 손상을 방지하려면 계속하기 전에 물리적 하드웨어의 전원을 끕니다.
클러스터에서 노드를 삭제합니다.
$ oc delete node <node_name>
노드 오브젝트가 클러스터에서 삭제되어도 재부팅 후 또는 kubelet 서비스가 재시작되면 클러스터에 다시 참여할 수 있습니다. 노드와 노드의 모든 데이터를 영구적으로 삭제하려면 노드를 해제해야 합니다.
- 물리 하드웨어의 전원을 끈 경우 노드가 클러스터에 다시 참여할 수 있도록 해당 하드웨어를 다시 켭니다.
7.8.3. 가상 머신 장애 조치 확인
비정상 노드에서 모든 리소스가 종료되면 VM이 재배치될 때마다 정상 노드에 새 VMI(가상 머신 인스턴스)가 자동으로 생성됩니다. VMI가 생성되었는지 확인하려면 oc
CLI를 사용하여 모든 VMI를 확인합니다.
7.8.3.1. CLI를 사용하여 모든 가상 머신 인스턴스 나열
oc
CLI(명령줄 인터페이스)를 사용하면 독립 실행형 VMI(가상 머신 인스턴스) 및 가상 머신에 속하는 VMI를 포함하여 클러스터의 모든 VMI를 나열할 수 있습니다.
절차
다음 명령을 실행하여 VMI를 모두 나열합니다.
$ oc get vmis
7.9. 가상 머신에 QEMU 게스트 에이전트 설치
QEMU 게스트 에이전트는 가상 머신에서 실행되고 가상 머신, 사용자, 파일 시스템, 보조 네트워크에 대한 정보를 호스트에 전달하는 데몬입니다.
7.9.1. Linux 가상 머신에 QEMU 게스트 에이전트 설치
qemu-guest-agent
는 광범위하게 사용되며, Red Hat 가상 머신에 기본적으로 제공됩니다. 에이전트를 설치하고 서비스를 시작하십시오.
절차
- 콘솔 중 하나 또는 SSH를 통해 가상 머신 명령줄에 액세스합니다.
가상 머신에 QEMU 게스트 에이전트를 설치합니다.
$ yum install -y qemu-guest-agent
서비스가 지속되는지 확인하고 다음을 시작합니다.
$ systemctl enable --now qemu-guest-agent
웹 콘솔에서 가상 머신 또는 가상 머신 템플릿을 생성할 때 마법사의 cloud-init 섹션에 있는 사용자 정의 스크립트 필드를 사용하여 QEMU 게스트 에이전트를 설치하고 시작할 수도 있습니다.
7.9.2. Windows 가상 머신에 QEMU 게스트 에이전트 설치
Windows 가상 머신의 경우 QEMU 게스트 에이전트는 VirtIO 드라이버에 포함되어 있으며 다음 절차 중 하나를 사용하여 설치할 수 있습니다.
7.9.2.1. 기존 Windows 가상 머신에 VirtIO 드라이버 설치
연결된 SATA CD 드라이브에서 기존 Windows 가상 머신에 VirtIO 드라이버를 설치합니다.
다음 절차에서는 일반적인 방법을 사용하여 Windows에 드라이버를 추가합니다. 프로세스는 Windows 버전마다 약간 다를 수 있습니다. 구체적인 설치 단계는 사용 중인 Windows 버전의 설치 설명서를 참조하십시오.
절차
- 가상 머신을 시작하고 그래픽 콘솔에 연결합니다.
- Windows 사용자 세션에 로그인합니다.
장치 관리자를 열고 기타 장치를 확장하여 알 수 없는 장치를 나열합니다.
-
Device Properties
을 열어 알 수 없는 장치를 확인합니다. 장치를 마우스 오른쪽 버튼으로 클릭하고 속성을 선택합니다. - 세부 정보 탭을 클릭하고 속성 목록에서 하드웨어 ID를 선택합니다.
- 하드웨어 ID의 값을 지원되는 VirtIO 드라이버와 비교합니다.
-
- 장치를 마우스 오른쪽 단추로 클릭하고 드라이버 소프트웨어 업데이트를 선택합니다.
- 컴퓨터에서 드라이버 소프트웨어 찾아보기를 클릭하고 VirtIO 드라이버가 있는 연결된 SATA CD 드라이브를 찾습니다. 드라이버는 드라이버 유형, 운영 체제, CPU 아키텍처에 따라 계층적으로 정렬됩니다.
- 다음을 클릭하여 드라이버를 설치합니다.
- 필요한 모든 VirtIO 드라이버에 대해 이 과정을 반복합니다.
- 드라이버 설치 후 닫기를 클릭하여 창을 닫습니다.
- 가상 머신을 재부팅하여 드라이버 설치를 완료합니다.
7.9.2.2. Windows 설치 중 VirtIO 드라이버 설치
Windows를 설치하는 동안 연결된 SATA CD 드라이버에서 VirtIO 드라이버를 설치합니다.
이 절차에서는 일반적인 Windows 설치 방법을 사용하며, 설치 방법은 Windows 버전마다 다를 수 있습니다. 설치 중인 Windows 버전에 대한 설명서를 참조하십시오.
절차
- 가상 머신을 시작하고 그래픽 콘솔에 연결합니다.
- Windows 설치 프로세스를 시작합니다.
- 고급 설치를 선택합니다.
-
저장 대상은 드라이버가 로드되어야 인식됩니다.
Load driver
를 클릭합니다. - 드라이버는 SATA CD 드라이브로 연결되어 있습니다. 확인을 클릭하고 스토리지 드라이버를 로드할 CD 드라이브를 찾습니다. 드라이버는 드라이버 유형, 운영 체제, CPU 아키텍처에 따라 계층적으로 정렬됩니다.
- 필요한 모든 드라이버에 대해 위의 두 단계를 반복합니다.
- Windows 설치를 완료합니다.
7.10. 가상 머신에 대한 QEMU 게스트 에이전트 정보 보기
QEMU 게스트 에이전트가 가상 머신에서 실행되는 경우, 웹 콘솔을 사용하여 가상 머신, 사용자, 파일 시스템, 보조 네트워크에 대한 정보를 볼 수 있습니다.
7.10.1. 사전 요구 사항
- 가상 머신에 QEMU 게스트 에이전트를 설치합니다.
7.10.2. 웹 콘솔의 QEMU 게스트 에이전트 정보
QEMU 게스트 에이전트가 설치되면 가상 머신 개요 탭의 세부 정보 창과 세부 정보 탭에 호스트 이름, 운영 체제, 시간대, 로그인된 사용자에 대한 정보가 표시됩니다.
가상 머신 개요에는 가상 머신에 설치된 게스트 운영 체제에 대한 정보가 표시됩니다. 세부 정보 탭에는 로그인한 사용자에 대한 정보가 포함된 테이블이 표시됩니다. 디스크 탭에는 파일 시스템에 대한 정보가 포함된 테이블이 표시됩니다.
QEMU 게스트 에이전트가 설치되지 않은 경우 가상 머신 개요 탭과 세부 정보 탭에 가상 머신이 생성될 때 지정된 운영 체제 정보가 표시됩니다.
7.10.3. 웹 콘솔에서 QEMU 게스트 에이전트 정보 보기
웹 콘솔을 사용하여 QEMU 게스트 에이전트에서 호스트로 전달하는 가상 머신에 대한 정보를 볼 수 있습니다.
절차
- 사이드 메뉴에서 워크로드 → 가상 머신을 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 가상 머신 이름을 선택하여 가상 머신 개요 화면을 열고 세부 정보 창을 확인합니다.
- 로그인된 사용자를 클릭하여 사용자에 대한 정보가 표시되는 세부 정보 탭을 확인합니다.
- 파일 시스템에 대한 정보를 보려면 디스크 탭을 클릭합니다.
7.11. 가상 머신에서 구성 맵, 시크릿, 서비스 계정 관리
시크릿, 구성 맵, 서비스 계정을 사용하여 구성 데이터를 가상 머신에 전달할 수 있습니다. 예를 들면 다음을 수행할 수 있습니다.
- 가상 머신에 시크릿을 추가하여 자격 증명이 필요한 서비스에 대한 액세스 권한을 부여합니다.
- Pod 또는 다른 오브젝트에서 데이터를 사용할 수 있도록 구성 맵에 기밀이 아닌 구성 데이터를 저장합니다.
- 서비스 계정을 특정 구성 요소와 연결하여 해당 구성 요소가 API 서버에 액세스하도록 허용합니다.
OpenShift Virtualization은 시크릿, 구성 맵, 서비스 계정을 가상 머신 디스크로 노출하므로 추가 오버헤드 없이 여러 플랫폼에서 사용할 수 있습니다.
7.11.1. 가상 머신에 시크릿, 구성 맵 또는 서비스 계정 추가
OpenShift Container Platform 웹 콘솔을 사용하여 가상 머신에 시크릿, 구성 맵 또는 서비스 계정을 추가합니다.
사전 요구 사항
- 추가할 시크릿, 구성 맵 또는 서비스 계정은 대상 가상 머신과 동일한 네임스페이스에 있어야 합니다.
절차
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 가상 머신을 선택하여 가상 머신 개요 화면을 엽니다.
- 환경 탭을 클릭합니다.
- 리소스 선택을 클릭하고 목록에서 시크릿, 구성 맵 또는 서비스 계정을 선택합니다. 선택한 리소스에 대해 6자리 일련 번호가 자동으로 생성됩니다.
- 저장을 클릭합니다.
- 선택사항입니다. 구성 맵, 시크릿 또는 서비스 계정 추가를 클릭하여 다른 오브젝트를 추가합니다.
- 다시 로드를 클릭하여 폼을 마지막 저장된 상태로 재설정할 수 있습니다.
- 환경 리소스는 가상 머신에 디스크로 추가됩니다. 다른 디스크를 마운트할 때와 같이 시크릿, 구성 맵 또는 서비스 계정을 마운트할 수 있습니다.
- 가상 머신이 실행 중인 경우 가상 머신을 재시작해야 변경 사항이 적용됩니다. 새로 추가된 리소스는 페이지 상단 보류 중인 변경 사항 배너의 환경 및 디스크 탭 모두에서 보류 중인 변경 사항으로 표시됩니다.
검증
- 가상 머신 개요 페이지에서 디스크 탭을 클릭합니다.
- 시크릿, 구성 맵 또는 서비스 계정이 디스크 목록에 포함되어 있는지 확인합니다.
선택사항입니다. 변경 사항을 적용할 적절한 방법을 선택합니다.
- 가상 머신이 실행 중인 경우 작업 → 가상 머신 재시작을 클릭하여 가상 머신을 재시작합니다.
- 가상 머신이 중지된 경우 작업 → 가상 머신 시작을 클릭하여 가상 머신을 시작합니다.
이제 다른 디스크를 마운트할 때와 같이 시크릿, 구성 맵 또는 서비스 계정을 마운트할 수 있습니다.
7.11.2. 가상 머신에서 시크릿, 구성 맵 또는 서비스 계정 제거
OpenShift Container Platform 웹 콘솔을 사용하여 가상 머신에서 시크릿, 구성 맵 또는 서비스 계정을 제거합니다.
사전 요구 사항
- 하나 이상의 시크릿, 구성 맵 또는 서비스 계정이 가상 머신에 연결되어 있어야 합니다.
절차
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 가상 머신을 선택하여 가상 머신 개요 화면을 엽니다.
- 환경 탭을 클릭합니다.
- 목록에서 삭제할 항목을 찾아 항목 오른쪽에서 제거를 클릭합니다.
- 저장을 클릭합니다.
다시 로드를 클릭하여 폼을 마지막 저장된 상태로 재설정할 수 있습니다.
검증
- 가상 머신 개요 페이지에서 디스크 탭을 클릭합니다.
- 제거한 시크릿, 구성 맵 또는 서비스 계정이 더 이상 디스크 목록에 포함되어 있지 않은지 확인합니다.
7.11.3. 추가 리소스
7.12. 기존 Windows 가상 머신에 VirtIO 드라이버 설치
7.12.1. VirtIO 드라이버 이해
VirtIO 드라이버는 Microsoft Windows 가상 머신을 OpenShift Virtualization에서 실행하는 데 필요한 준가상화 장치 드라이버입니다. 지원되는 드라이버는 Red Hat Ecosystem Catalog의 container-native-virtualization/virtio-win
컨테이너 디스크에 있습니다.
드라이버 설치를 사용하려면 container-native-virtualization/virtio-win
컨테이너 디스크를 가상 머신에 SATA CD 드라이브로 연결해야 합니다. VirtIO 드라이버는 가상 머신에 Windows를 설치하는 동안 설치하거나 기존 Windows 설치에 추가할 수 있습니다.
드라이버를 설치하면 container-native-virtualization/virtio-win
컨테이너 디스크를 가상 머신에서 제거할 수 있습니다.
또한 다음을 참조하십시오. 새 Windows 가상 머신에 Virtio 드라이버 설치.
7.12.2. Microsoft Windows 가상 머신에 지원되는 VirtIO 드라이버
드라이버 이름 | 하드웨어 ID | 설명 |
---|---|---|
viostor |
VEN_1AF4&DEV_1001 | 블록 드라이버입니다. 기타 장치 그룹에 SCSI 컨트롤러로 표시되기도 합니다. |
viorng |
VEN_1AF4&DEV_1005 | 엔트로피 소스 드라이버입니다. 기타 장치 그룹에 PCI 장치로 표시되기도 합니다. |
NetKVM |
VEN_1AF4&DEV_1000 | 네트워크 드라이버입니다. 기타 장치 그룹에 이더넷 컨트롤러로 표시되기도 합니다. VirtIO NIC가 구성된 경우에만 사용할 수 있습니다. |
7.12.3. 가상 머신에 VirtIO 드라이버 컨테이너 디스크 추가
OpenShift Virtualization에서는 Microsoft Windows용 VirtIO 드라이버를 컨테이너 디스크로 배포하며, Red Hat Ecosystem Catalog에서 사용할 수 있습니다. 이러한 드라이버를 Windows 가상 머신에 설치하려면 가상 머신 구성 파일에서 container-native-virtualization/virtio-win
컨테이너 디스크를 가상 머신에 SATA CD 드라이브로 연결하십시오.
사전 요구 사항
-
Red Hat Ecosystem Catalog에서
container-native-virtualization/virtio-win
컨테이너 디스크를 다운로드합니다. 이 작업은 컨테이너 디스크가 클러스터에 없는 경우 Red Hat 레지스트리에서 다운로드되므로 필수 사항은 아니지만, 설치 시간을 줄일 수 있습니다.
절차
Windows 가상 머신 구성 파일에서
container-native-virtualization/virtio-win
컨테이너 디스크를cdrom
디스크로 추가합니다. 컨테이너 디스크가 클러스터에 없는 경우 레지스트리에서 다운로드됩니다.spec: domain: devices: disks: - name: virtiocontainerdisk bootOrder: 2 1 cdrom: bus: sata volumes: - containerDisk: image: container-native-virtualization/virtio-win name: virtiocontainerdisk
- 1
- OpenShift Virtualization은
VirtualMachine
구성 파일에 정의된 순서대로 가상 머신 디스크를 부팅합니다.container-native-virtualization/virtio-win
컨테이너 디스크 전에 기타 디스크를 가상 머신에 정의하거나, 선택적bootOrder
매개변수를 사용하여 가상 머신을 올바른 디스크에서 부팅할 수 있습니다. 디스크에bootOrder
를 지정하는 경우 구성의 모든 디스크에 지정해야 합니다.
가상 머신이 시작되면 디스크를 사용할 수 있습니다.
-
실행 중인 가상 머신에 컨테이너 디스크를 추가할 때는 CLI에
oc apply -f <vm.yaml>
을 사용하거나 가상 머신을 재부팅하여 변경 사항을 적용합니다. -
가상 머신이 실행 중이 아닌 경우에는
virtctl start <vm>
을 사용합니다.
-
실행 중인 가상 머신에 컨테이너 디스크를 추가할 때는 CLI에
가상 머신이 시작되면 연결된 SATA CD 드라이브에서 VirtIO 드라이버를 설치할 수 있습니다.
7.12.4. 기존 Windows 가상 머신에 VirtIO 드라이버 설치
연결된 SATA CD 드라이브에서 기존 Windows 가상 머신에 VirtIO 드라이버를 설치합니다.
다음 절차에서는 일반적인 방법을 사용하여 Windows에 드라이버를 추가합니다. 프로세스는 Windows 버전마다 약간 다를 수 있습니다. 구체적인 설치 단계는 사용 중인 Windows 버전의 설치 설명서를 참조하십시오.
절차
- 가상 머신을 시작하고 그래픽 콘솔에 연결합니다.
- Windows 사용자 세션에 로그인합니다.
장치 관리자를 열고 기타 장치를 확장하여 알 수 없는 장치를 나열합니다.
-
Device Properties
을 열어 알 수 없는 장치를 확인합니다. 장치를 마우스 오른쪽 버튼으로 클릭하고 속성을 선택합니다. - 세부 정보 탭을 클릭하고 속성 목록에서 하드웨어 ID를 선택합니다.
- 하드웨어 ID의 값을 지원되는 VirtIO 드라이버와 비교합니다.
-
- 장치를 마우스 오른쪽 단추로 클릭하고 드라이버 소프트웨어 업데이트를 선택합니다.
- 컴퓨터에서 드라이버 소프트웨어 찾아보기를 클릭하고 VirtIO 드라이버가 있는 연결된 SATA CD 드라이브를 찾습니다. 드라이버는 드라이버 유형, 운영 체제, CPU 아키텍처에 따라 계층적으로 정렬됩니다.
- 다음을 클릭하여 드라이버를 설치합니다.
- 필요한 모든 VirtIO 드라이버에 대해 이 과정을 반복합니다.
- 드라이버 설치 후 닫기를 클릭하여 창을 닫습니다.
- 가상 머신을 재부팅하여 드라이버 설치를 완료합니다.
7.12.5. 가상 머신에서 VirtIO 컨테이너 디스크 제거
필요한 모든 VirtIO 드라이버를 가상 머신에 설치한 후에는 container-native-virtualization/virtio-win
컨테이너 디스크를 더 이상 가상 머신에 연결할 필요가 없습니다. 가상 머신 구성 파일에서 container-native-virtualization/virtio-win
컨테이너 디스크를 제거하십시오.
절차
구성 파일을 편집하여
disk
및volume
을 제거합니다.$ oc edit vm <vm-name>
spec: domain: devices: disks: - name: virtiocontainerdisk bootOrder: 2 cdrom: bus: sata volumes: - containerDisk: image: container-native-virtualization/virtio-win name: virtiocontainerdisk
- 가상 머신을 재부팅하여 변경 사항을 적용합니다.
7.13. 새로운 Windows 가상 머신에 VirtIO 드라이버 설치
7.13.1. 사전 요구 사항
- ISO를 데이터 볼륨으로 가져와서 가상 머신에 연결하는 등 가상 머신에서 Windows 설치 미디어에 액세스할 수 있습니다.
7.13.2. VirtIO 드라이버 이해
VirtIO 드라이버는 Microsoft Windows 가상 머신을 OpenShift Virtualization에서 실행하는 데 필요한 준가상화 장치 드라이버입니다. 지원되는 드라이버는 Red Hat Ecosystem Catalog의 container-native-virtualization/virtio-win
컨테이너 디스크에 있습니다.
드라이버 설치를 사용하려면 container-native-virtualization/virtio-win
컨테이너 디스크를 가상 머신에 SATA CD 드라이브로 연결해야 합니다. VirtIO 드라이버는 가상 머신에 Windows를 설치하는 동안 설치하거나 기존 Windows 설치에 추가할 수 있습니다.
드라이버를 설치하면 container-native-virtualization/virtio-win
컨테이너 디스크를 가상 머신에서 제거할 수 있습니다.
또한 다음을 참조하십시오. 기존 Windows 가상 머신에 VirtIO 드라이버 설치.
7.13.3. Microsoft Windows 가상 머신에 지원되는 VirtIO 드라이버
드라이버 이름 | 하드웨어 ID | 설명 |
---|---|---|
viostor |
VEN_1AF4&DEV_1001 | 블록 드라이버입니다. 기타 장치 그룹에 SCSI 컨트롤러로 표시되기도 합니다. |
viorng |
VEN_1AF4&DEV_1005 | 엔트로피 소스 드라이버입니다. 기타 장치 그룹에 PCI 장치로 표시되기도 합니다. |
NetKVM |
VEN_1AF4&DEV_1000 | 네트워크 드라이버입니다. 기타 장치 그룹에 이더넷 컨트롤러로 표시되기도 합니다. VirtIO NIC가 구성된 경우에만 사용할 수 있습니다. |
7.13.4. 가상 머신에 VirtIO 드라이버 컨테이너 디스크 추가
OpenShift Virtualization에서는 Microsoft Windows용 VirtIO 드라이버를 컨테이너 디스크로 배포하며, Red Hat Ecosystem Catalog에서 사용할 수 있습니다. 이러한 드라이버를 Windows 가상 머신에 설치하려면 가상 머신 구성 파일에서 container-native-virtualization/virtio-win
컨테이너 디스크를 가상 머신에 SATA CD 드라이브로 연결하십시오.
사전 요구 사항
-
Red Hat Ecosystem Catalog에서
container-native-virtualization/virtio-win
컨테이너 디스크를 다운로드합니다. 이 작업은 컨테이너 디스크가 클러스터에 없는 경우 Red Hat 레지스트리에서 다운로드되므로 필수 사항은 아니지만, 설치 시간을 줄일 수 있습니다.
절차
Windows 가상 머신 구성 파일에서
container-native-virtualization/virtio-win
컨테이너 디스크를cdrom
디스크로 추가합니다. 컨테이너 디스크가 클러스터에 없는 경우 레지스트리에서 다운로드됩니다.spec: domain: devices: disks: - name: virtiocontainerdisk bootOrder: 2 1 cdrom: bus: sata volumes: - containerDisk: image: container-native-virtualization/virtio-win name: virtiocontainerdisk
- 1
- OpenShift Virtualization은
VirtualMachine
구성 파일에 정의된 순서대로 가상 머신 디스크를 부팅합니다.container-native-virtualization/virtio-win
컨테이너 디스크 전에 기타 디스크를 가상 머신에 정의하거나, 선택적bootOrder
매개변수를 사용하여 가상 머신을 올바른 디스크에서 부팅할 수 있습니다. 디스크에bootOrder
를 지정하는 경우 구성의 모든 디스크에 지정해야 합니다.
가상 머신이 시작되면 디스크를 사용할 수 있습니다.
-
실행 중인 가상 머신에 컨테이너 디스크를 추가할 때는 CLI에
oc apply -f <vm.yaml>
을 사용하거나 가상 머신을 재부팅하여 변경 사항을 적용합니다. -
가상 머신이 실행 중이 아닌 경우에는
virtctl start <vm>
을 사용합니다.
-
실행 중인 가상 머신에 컨테이너 디스크를 추가할 때는 CLI에
가상 머신이 시작되면 연결된 SATA CD 드라이브에서 VirtIO 드라이버를 설치할 수 있습니다.
7.13.5. Windows 설치 중 VirtIO 드라이버 설치
Windows를 설치하는 동안 연결된 SATA CD 드라이버에서 VirtIO 드라이버를 설치합니다.
이 절차에서는 일반적인 Windows 설치 방법을 사용하며, 설치 방법은 Windows 버전마다 다를 수 있습니다. 설치 중인 Windows 버전에 대한 설명서를 참조하십시오.
절차
- 가상 머신을 시작하고 그래픽 콘솔에 연결합니다.
- Windows 설치 프로세스를 시작합니다.
- 고급 설치를 선택합니다.
-
저장 대상은 드라이버가 로드되어야 인식됩니다.
Load driver
를 클릭합니다. - 드라이버는 SATA CD 드라이브로 연결되어 있습니다. 확인을 클릭하고 스토리지 드라이버를 로드할 CD 드라이브를 찾습니다. 드라이버는 드라이버 유형, 운영 체제, CPU 아키텍처에 따라 계층적으로 정렬됩니다.
- 필요한 모든 드라이버에 대해 위의 두 단계를 반복합니다.
- Windows 설치를 완료합니다.
7.13.6. 가상 머신에서 VirtIO 컨테이너 디스크 제거
필요한 모든 VirtIO 드라이버를 가상 머신에 설치한 후에는 container-native-virtualization/virtio-win
컨테이너 디스크를 더 이상 가상 머신에 연결할 필요가 없습니다. 가상 머신 구성 파일에서 container-native-virtualization/virtio-win
컨테이너 디스크를 제거하십시오.
절차
구성 파일을 편집하여
disk
및volume
을 제거합니다.$ oc edit vm <vm-name>
spec: domain: devices: disks: - name: virtiocontainerdisk bootOrder: 2 cdrom: bus: sata volumes: - containerDisk: image: container-native-virtualization/virtio-win name: virtiocontainerdisk
- 가상 머신을 재부팅하여 변경 사항을 적용합니다.
7.14. 고급 가상 머신 관리
7.14.1. 관리 작업 자동화
Red Hat Ansible Automation Platform을 사용하여 OpenShift Virtualization 관리 작업을 자동화할 수 있습니다. Ansible Playbook을 사용하여 새 가상 머신을 생성하며 기본 사항을 살펴보십시오.
7.14.1.1. Red Hat Ansible Automation 정보
Ansible은 시스템 구성, 소프트웨어 배포, 롤링 업데이트 수행에 사용되는 자동화 툴입니다. Ansible은 OpenShift Virtualization을 지원하며, Ansible 모듈을 사용하면 템플릿, 영구 볼륨 클레임, 가상 머신 작업과 같은 클러스터 관리 작업을 자동화할 수 있습니다.
Ansible을 통해 OpenShift Virtualization 관리를 자동화할 수 있으며, 이러한 자동화는 oc
CLI 툴 또는 API를 통해서도 수행할 수 있습니다. Ansible은 KubeVirt 모듈을 다른 Ansible 모듈과 통합할 수 있다는 점에서 고유합니다.
7.14.1.2. 가상 머신 생성 자동화
kubevirt_vm
Ansible Playbook을 사용하면 Red Hat Ansible Automation Platform을 통해 OpenShift Container Platform 클러스터에 가상 머신을 생성할 수 있습니다.
사전 요구 사항
- Red Hat Ansible Engine 버전 2.8 이상
절차
kubevirt_vm
작업이 포함되도록 Ansible Playbook YAML 파일을 편집합니다.kubevirt_vm: namespace: name: cpu_cores: memory: disks: - name: volume: containerDisk: image: disk: bus:
참고이 스니펫에는 플레이북의
kubevirt_vm
부분만 포함됩니다.생성할 가상 머신을 반영하도록
namespace
,cpu_cores
수,memory
,disks
등의 값을 편집합니다. 예를 들면 다음과 같습니다.kubevirt_vm: namespace: default name: vm1 cpu_cores: 1 memory: 64Mi disks: - name: containerdisk volume: containerDisk: image: kubevirt/cirros-container-disk-demo:latest disk: bus: virtio
생성 후 즉시 가상 머신을 부팅하려면 YAML 파일에
state: running
을 추가합니다. 예를 들면 다음과 같습니다.kubevirt_vm: namespace: default name: vm1 state: running 1 cpu_cores: 1
- 1
- 이 값을
state: absent
로 변경하면 이미 존재하는 가상 머신이 삭제됩니다.
플레이북의 파일 이름을 유일한 인수로 사용하여
ansible-playbook
명령을 실행합니다.$ ansible-playbook create-vm.yaml
출력을 검토하여 실행이 성공했는지 확인합니다.
출력 예
(...) TASK [Create my first VM] ************************************************************************ changed: [localhost] PLAY RECAP ******************************************************************************************************** localhost : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
플레이북 파일에
state:running
을 포함하지 않은 경우 지금 VM을 부팅하려면state:running
을 포함하도록 파일을 편집한 후 플레이북을 다시 실행합니다.$ ansible-playbook create-vm.yaml
가상 머신이 생성되었는지 확인하려면 VM 콘솔에 액세스하십시오.
7.14.1.3. 예제: 가상 머신 생성을 위한 Ansible Playbook
kubevirt_vm
Ansible Playbook을 사용하여 가상 머신 생성을 자동화할 수 있습니다.
다음 YAML 파일은 kubevirt_vm
플레이북의 예입니다. 이 예에는 샘플 값이 포함되어 있으며, 플레이북을 실행하는 경우 해당 값을 사용자의 정보로 교체해야 합니다.
--- - name: Ansible Playbook 1 hosts: localhost connection: local tasks: - name: Create my first VM kubevirt_vm: namespace: default name: vm1 cpu_cores: 1 memory: 64Mi disks: - name: containerdisk volume: containerDisk: image: kubevirt/cirros-container-disk-demo:latest disk: bus: virtio
7.14.2. 가상 머신에 대한 PXE 부팅 구성
OpenShift Virtualization에서는 PXE 부팅 또는 네트워크 부팅을 사용할 수 있습니다. 네트워크 부팅의 경우 로컬로 연결된 스토리지 장치 없이 컴퓨터에서 운영 체제 또는 기타 프로그램을 부팅 및 로드할 수 있습니다. 예를 들어, 새 호스트를 배포할 때 PXE 서버에서 원하는 OS 이미지를 선택할 수 있습니다.
7.14.2.1. 사전 요구 사항
- Linux 브리지가 연결되어 있어야 합니다.
- PXE 서버는 브리지와 동일한 VLAN에 연결되어 있어야 합니다.
7.14.2.2. 지정된 MAC 주소로 PXE 부팅
관리자는 PXE 네트워크에 대한 NetworkAttachmentDefinition
오브젝트를 생성한 후 네트워크를 통해 클라이언트를 부팅할 수 있습니다. 그런 다음 가상 머신 인스턴스 구성 파일에서 네트워크 연결 정의를 참조한 후 가상 머신 인스턴스를 시작할 수 있습니다. PXE 서버에 필요한 경우 가상 머신 인스턴스 구성 파일에 MAC 주소를 지정할 수도 있습니다.
사전 요구 사항
- Linux 브리지가 연결되어 있어야 합니다.
- PXE 서버는 브리지와 동일한 VLAN에 연결되어 있어야 합니다.
절차
클러스터에서 PXE 네트워크를 구성합니다.
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 } ] }'
참고VLAN이 요청된 액세스 포트를 통해 가상 머신 인스턴스가 브리지
br1
에 연결됩니다.
이전 단계에서 만든 파일을 사용하여 네트워크 연결 정의를 생성합니다.
$ oc create -f pxe-net-conf.yaml
인터페이스 및 네트워크에 대한 세부 정보를 포함하도록 가상 머신 인스턴스 구성 파일을 편집합니다.
PXE 서버에 필요한 경우 네트워크 및 MAC 주소를 지정합니다. MAC 주소를 지정하지 않으면 값이 자동으로 할당됩니다. 그러나 이때 자동으로 할당된 MAC 주소는 영구적이지 않습니다.
인터페이스가 먼저 부팅되도록
bootOrder
가1
로 설정되어 있는지 확인하십시오. 이 예에서는 인터페이스가<pxe-net>
이라는 네트워크에 연결되어 있습니다.interfaces: - masquerade: {} name: default - bridge: {} name: pxe-net macAddress: de:00:00:00:00:de bootOrder: 1
참고부팅 순서는 인터페이스 및 디스크에 대해 전역적입니다.
운영 체제가 프로비저닝되면 올바르게 부팅되도록 부팅 장치 번호를 디스크에 할당합니다.
디스크의
bootOrder
값을2
로 설정합니다.devices: disks: - disk: bus: virtio name: containerdisk bootOrder: 2
네트워크를 이전에 생성한 네트워크 연결 정의에 연결하도록 지정합니다. 이 시나리오에서
<pxe-net>
는<pxe-net-conf>
라는 네트워크 연결 정의에 연결됩니다.networks: - name: default pod: {} - name: pxe-net multus: networkName: pxe-net-conf
가상 머신 인스턴스를 생성합니다.
$ oc create -f vmi-pxe-boot.yaml
출력 예
virtualmachineinstance.kubevirt.io "vmi-pxe-boot" created
가상 머신 인스턴스가 실행될 때까지 기다립니다.
$ oc get vmi vmi-pxe-boot -o yaml | grep -i phase phase: Running
VNC를 사용하여 가상 머신 인스턴스를 확인합니다.
$ virtctl vnc vmi-pxe-boot
- 부팅 화면에서 PXE 부팅에 성공했는지 확인합니다.
가상 머신 인스턴스에 로그인합니다.
$ virtctl console vmi-pxe-boot
가상 머신의 인터페이스 및 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.14.2.3. 템플릿: PXE 부팅을 위한 가상 머신 인스턴스 구성 파일
apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachineInstance metadata: creationTimestamp: null labels: special: vmi-pxe-boot name: vmi-pxe-boot spec: domain: devices: disks: - disk: bus: virtio name: containerdisk bootOrder: 2 - disk: bus: virtio name: cloudinitdisk interfaces: - masquerade: {} name: default - bridge: {} name: pxe-net macAddress: de:00:00:00:00:de bootOrder: 1 machine: type: "" resources: requests: memory: 1024M networks: - name: default pod: {} - multus: networkName: pxe-net-conf name: pxe-net terminationGracePeriodSeconds: 0 volumes: - name: containerdisk containerDisk: image: kubevirt/fedora-cloud-container-disk-demo - cloudInitNoCloud: userData: | #!/bin/bash echo "fedora" | passwd fedora --stdin name: cloudinitdisk status: {}
7.14.2.4. OpenShift Virtualization 네트워킹 용어집
OpenShift Virtualization은 사용자 정의 리소스 및 플러그인을 사용하여 고급 네트워킹 기능을 제공합니다.
다음 용어는 OpenShift Virtualization 설명서 전체에서 사용됩니다.
- CNI(컨테이너 네트워크 인터페이스(Container Network Interface))
- 컨테이너 네트워크 연결에 중점을 둔 Cloud Native Computing Foundation 프로젝트입니다. OpenShift Virtualization에서는 기본 Kubernetes 네트워킹 기능을 기반으로 하도록 CNI 플러그인을 사용합니다.
- Multus
- Pod 또는 가상 머신에서 필요한 인터페이스를 사용하도록 여러 CNI가 존재할 수 있는 ‘메타’ CNI 플러그인입니다.
- CRD(사용자 정의 리소스 정의(Custom Resource Definition))
- 사용자 정의 리소스를 정의할 수 있는 Kubernetes API 리소스 또는 CRD API 리소스를 사용하여 정의한 오브젝트입니다.
- 네트워크 연결 정의
- Pod, 가상 머신, 가상 머신 인스턴스를 하나 이상의 네트워크에 연결할 수 있는 Multus 프로젝트에서 도입한 CRD입니다.
- PXE(Preboot eXecution Environment)
- 관리자가 네트워크를 통해 서버에서 클라이언트 머신을 부팅할 수 있는 인터페이스입니다. 네트워크 부팅을 통해 운영 체제 및 기타 소프트웨어를 클라이언트에 원격으로 로드할 수 있습니다.
7.14.3. 게스트 메모리 관리
특정 사용 사례에 맞게 게스트 메모리 설정을 조정하려면 게스트의 YAML 구성 파일을 편집하면 됩니다. OpenShift Virtualization에서는 게스트 메모리 과다 할당을 구성하고 게스트 메모리 오버헤드 계산을 비활성화할 수 있습니다.
다음 절차를 수행하면 메모리 부족으로 인해 가상 머신 프로세스가 종료될 가능성이 높아집니다. 이러한 위험을 인지하는 경우에만 진행하십시오.
7.14.3.1. 게스트 메모리 과다 할당 구성
가상 워크로드에 사용 가능한 것보다 많은 메모리가 필요한 경우, 메모리 과다 할당을 사용하여 호스트의 메모리 전체 또는 대부분을 VMI(가상 머신 인스턴스)에 할당할 수 있습니다. 메모리 과다 할당을 사용하면 일반적으로 호스트에 예약되는 리소스를 최대화할 수 있습니다.
예를 들어 호스트에 32GB RAM이 있으면 메모리 과다 할당을 사용하여 각각 4GB의 RAM이 있는 VM(가상 머신) 8개를 만들 수 있습니다. 이러한 할당은 가상 머신에서 모든 메모리를 동시에 사용하지 않는다는 가정 하에 작동합니다.
메모리를 과다 할당하면 메모리 부족(OOM 종료)으로 인해 가상 머신 프로세스가 종료될 가능성이 높아집니다.
VM이 OOM인해 종료될 가능성은 특정 구성, 노드 메모리, 사용 가능한 스왑 공간, 가상 머신 메모리 사용량, 커널 동일 페이지 병합(KSM) 및 기타 요인에 따라 달라집니다.
절차
클러스터에서 요청한 것보다 사용 가능한 메모리가 많다는 것을 가상 머신 인스턴스에 명시적으로 알리기 위해 가상 머신 구성 파일을 편집하여
spec.domain.memory.guest
를spec.domain.resources.requests.memory
보다 높은 값으로 설정합니다. 이 과정을 메모리 과다 할당이라고 합니다.이 예제에서는 클러스터에서
1024M
를 요청했지만 가상 머신 인스턴스에는2048M
가 사용 가능한 것으로 표시됩니다. 노드에 사용 가능한 메모리가 충분한 경우 가상 머신 인스턴스에서 최대 2048M를 사용합니다.kind: VirtualMachine spec: template: domain: resources: requests: memory: 1024M memory: guest: 2048M
참고노드의 메모리가 부족한 경우에는 Pod에 대한 제거 규칙과 동일한 제거 규칙이 가상 머신 인스턴스에 적용됩니다.
가상 머신을 생성합니다.
$ oc create -f <file_name>.yaml
7.14.3.2. 게스트 메모리 오버헤드 계산 비활성화
사용자가 요청한 양 이외에 각 가상 머신 인스턴스에서 소량의 메모리를 요청합니다. 이러한 추가 메모리는 각 VirtualMachineInstance
프로세스를 래핑하는 인프라에 사용됩니다.
일반적으로 권장되지는 않지만 게스트 메모리 오버헤드 계산을 비활성화하여 노드에서 가상 머신 인스턴스의 밀도를 높일 수 있습니다.
게스트 메모리 오버헤드 계산을 비활성화하면 메모리 부족(OOM 종료됨)으로 인해 가상 머신 프로세스가 종료될 가능성이 높아집니다.
VM이 OOM인해 종료될 가능성은 특정 구성, 노드 메모리, 사용 가능한 스왑 공간, 가상 머신 메모리 사용량, 커널 동일 페이지 병합(KSM) 및 기타 요인에 따라 달라집니다.
절차
게스트 메모리 오버헤드 계산을 사용하지 않으려면 YAML 구성 파일을 편집하여
overcommitGuestOverhead
값을true
로 설정합니다. 이 매개변수는 기본적으로 비활성화되어 있습니다.kind: VirtualMachine spec: template: domain: resources: overcommitGuestOverhead: true requests: memory: 1024M
참고overcommitGuestOverhead
가 활성화되면 게스트 오버헤드가 메모리 제한에 추가됩니다(있는 경우).가상 머신을 생성합니다.
$ oc create -f <file_name>.yaml
7.14.4. 가상 머신에서 대규모 페이지 사용
대규모 페이지를 클러스터의 가상 머신 백업 메모리로 사용할 수 있습니다.
7.14.4.1. 사전 요구 사항
- 노드에 사전 할당된 대규모 페이지가 구성되어 있어야 합니다.
7.14.4.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.14.4.3. 가상 머신용 대규모 페이지 구성
가상 머신 구성에 memory.hugepages.pageSize
및 resources.requests.memory
매개변수를 포함하여 사전 할당된 대규모 페이지를 사용하도록 가상 머신을 구성할 수 있습니다.
메모리 요청은 페이지 크기로 나눌 수 있어야합니다. 예를 들면 페이지 크기가 1Gi
인 500Mi
의 메모리는 요청할 수 없습니다.
호스트와 게스트 OS의 메모리 레이아웃은 관련이 없습니다. 가상 머신 매니페스트에서 요청된 대규모 페이지가 QEMU에 적용됩니다. 게스트 내부의 대규모 페이지는 사용 가능한 가상 머신 인스턴스 메모리 양을 기준으로만 구성할 수 있습니다.
실행 중인 가상 머신을 편집하는 경우 변경 사항을 적용하려면 가상 머신을 재부팅해야 합니다.
사전 요구 사항
- 노드에 사전 할당된 대규모 페이지가 구성되어 있어야 합니다.
절차
가상 머신 구성에서
spec.domain
에resources.requests.memory
및memory.hugepages.pageSize
매개변수를 추가합니다. 다음 구성 스니펫에서는 가상 머신에서 각 페이지 크기가1Gi
인 총4Gi
의 메모리를 요청합니다.kind: VirtualMachine ... spec: domain: resources: requests: memory: "4Gi" 1 memory: hugepages: pageSize: "1Gi" 2 ...
가상 머신 구성을 적용합니다.
$ oc apply -f <virtual_machine>.yaml
7.14.5. 가상 머신 전용 리소스 사용
성능 향상을 위해 CPU와 같은 노드 리소스를 가상 머신에 전용으로 지정할 수 있습니다.
7.14.5.1. 전용 리소스 정보
가상 머신에 전용 리소스를 사용하면 가상 머신의 워크로드가 다른 프로세스에서 사용하지 않는 CPU에 예약됩니다. 전용 리소스를 사용하면 가상 머신의 성능과 대기 시간 예측 정확도를 개선할 수 있습니다.
7.14.5.2. 사전 요구 사항
-
노드에 CPU 관리자를 구성해야 합니다. 가상 머신 워크로드를 예약하기 전에 노드에
cpumanager = true
라벨이 있는지 확인하십시오. - 가상 머신의 전원을 꺼야 합니다.
7.14.5.3. 가상 머신 전용 리소스 활성화
웹 콘솔의 가상 머신 개요 페이지에서 가상 머신 전용 리소스를 활성화할 수 있습니다.
프로세스
- 사이드 메뉴에서 워크로드 → 가상 머신을 클릭합니다.
- 가상 머신을 선택하여 가상 머신 개요 페이지를 엽니다.
- 세부 정보 탭을 클릭합니다.
- 전용 리소스 필드 오른쪽에 있는 연필 아이콘을 클릭하여 전용 리소스 창을 엽니다.
- 전용 리소스(보장된 정책)를 사용하여 이 워크로드 예약을 선택합니다.
- 저장을 클릭합니다.
7.14.6. 가상 머신 예약
호환성을 위해 VM의 CPU 모델과 정책 특성이 노드에서 지원하는 CPU 모델 및 정책 특성과 일치하도록 하면 노드에 VM(가상 머신)을 예약할 수 있습니다.
7.14.6.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.14.6.2. 정책 특성 및 CPU 기능 설정
각 VM(가상 머신)에 대한 정책 특성 및 CPU 기능을 설정하면 정책 및 기능에 따라 노드에 VM을 예약할 수 있습니다. 설정한 CPU 기능은 호스트 CPU의 지원 여부 또는 하이퍼바이저의 에뮬레이션 여부를 확인하기 위해 검증됩니다.
7.14.6.3. 지원되는 CPU 모델을 사용하여 가상 머신 예약
VM(가상 머신) 또는 VMI(가상 머신 인스턴스)의 CPU 모델을 구성하면 해당 CPU 모델이 지원되는 노드에 VM 또는 VMI를 예약할 수 있습니다.
절차
가상 머신 구성 파일의
domain
사양을 편집합니다. 다음 예제에서는 VMI에 대해 정의된 특정 CPU 모델을 보여줍니다.apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachineInstance metadata: name: myvmi spec: domain: cpu: model: Conroe 1
- 1
- VMI의 CPU 모델입니다.
7.14.6.4. 호스트 모델을 사용하여 가상 머신 예약
VM(가상 머신)의 CPU 모델이 host-model
로 설정되어 있으면 VM은 예약된 노드의 CPU 모델을 상속합니다.
절차
VM 구성 파일의
domain
사양을 편집합니다. 다음 예제에서는 VMI(가상 머신 인스턴스)에 지정되는host-model
을 보여줍니다.apiVersion: kubevirt/v1alpha3 kind: VirtualMachineInstance metadata: name: myvmi spec: domain: cpu: model: host-model 1
- 1
- 예약된 노드의 CPU 모델을 상속하는 VM 또는 VMI입니다.
7.15. 가상 머신 가져오기
7.15.1. 데이터 볼륨 가져오기에 필요한 TLS 인증서
7.15.1.1. 데이터 볼륨 가져오기 인증을 위한 TLS 인증서 추가
레지스트리 또는 HTTPS에서 데이터를 가져오려면 이러한 소스 끝점에 대한 TLS 인증서를 구성 맵에 추가해야 합니다. 이 구성 맵은 대상 데이터 볼륨의 네임스페이스에 있어야 합니다.
TLS 인증서의 상대 파일 경로를 참조하여 구성 맵을 만듭니다.
절차
올바른 네임스페이스에 있는지 확인합니다. 구성 맵은 동일한 네임스페이스에 있는 경우에만 데이터 볼륨에서 참조할 수 있습니다.
$ oc get ns
config map을 생성합니다.
$ oc create configmap <configmap-name> --from-file=</path/to/file/ca.pem>
7.15.1.2. 예제: TLS 인증서에서 생성된 구성 맵
다음은 ca.pem
TLS 인증서에서 생성한 구성 맵의 예입니다.
apiVersion: v1 kind: ConfigMap metadata: name: tls-certs data: ca.pem: | -----BEGIN CERTIFICATE----- ... <base64 encoded cert> ... -----END CERTIFICATE-----
7.15.2. 데이터 볼륨을 사용하여 가상 머신 이미지 가져오기
데이터 볼륨을 사용하여 가상 머신 이미지를 PVC(영구 볼륨 클레임)로 가져오려면 CDI(Containerized Data Importer)를 사용합니다. 영구 저장을 위해 데이터 볼륨을 가상 머신에 연결할 수 있습니다.
가상 머신 이미지는 HTTP 또는 HTTPS 끝점에서 호스팅하거나, 컨테이너 디스크에 빌드하고 컨테이너 레지스트리에 저장할 수 있습니다.
디스크 이미지를 PVC로 가져오면 PVC에 요청한 전체 스토리지 용량을 사용하도록 디스크 이미지가 확장됩니다. 이 공간을 사용하기 위해 가상 머신의 디스크 파티션 및 파일 시스템을 확장해야 할 수 있습니다.
크기 조정 절차는 가상 머신에 설치된 운영 체제에 따라 다릅니다. 자세한 내용은 운영 체제 설명서를 참조하십시오.
7.15.2.1. 사전 요구 사항
- 끝점에 TLS 인증서가 필요한 경우 인증서가 데이터 볼륨과 동일한 네임스페이스의 구성 맵에 포함되어 있고 데이터 볼륨 구성에 참조되어 있어야 합니다.
컨테이너 디스크를 가져오려면 다음을 수행합니다.
- 가져오기 전에 가상 머신 이미지에서 컨테이너 디스크를 준비하여 컨테이너 레지스트리에 저장해야 할 수 있습니다.
-
컨테이너 레지스트리에 TLS가 없는 경우 컨테이너 디스크를 가져오기 전에 해당 레지스트리를
cdi-insecure-registries
구성 맵에 추가해야 합니다.
- 이 작업을 완료하려면 스토리지 클래스를 정의하거나 CDI 스크래치 공간을 준비해야 할 수 있습니다.
7.15.2.2. CDI 지원 작업 매트릭스
이 매트릭스에는 끝점에 대한 콘텐츠 유형에 따라 지원되는 CDI 작업과 이러한 작업 중 스크래치 공간이 필요한 작업이 표시되어 있습니다.
콘텐츠 유형 | HTTP | HTTPS | HTTP 기본 인증 | 레지스트리 | 업로드 |
---|---|---|---|---|---|
KubeVirt(QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt(RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ 지원되는 작업
□ 지원되지 않는 작업
* 스크래치 공간 필요
** 사용자 정의 인증 기관이 필요한 경우 스크래치 공간 필요
7.15.2.3. 데이터 볼륨 정보
Dataolume
오브젝트는 CDI(Containerized Data Importer) 프로젝트에서 제공하는 사용자 정의 리소스입니다. 데이터 볼륨은 기본 PVC(영구 볼륨 클레임)와 관련된 가져오기, 복제, 업로드 작업을 오케스트레이션합니다. 데이터 볼륨은 OpenShift Virtualization과 통합되며 PVC가 준비되기 전에 가상 머신이 시작되지 않도록 합니다.
7.15.2.4. 데이터 볼륨을 사용하여 가상 머신 이미지를 스토리지로 가져오기
데이터 볼륨을 사용하여 가상 머신 이미지를 스토리지로 가져올 수 있습니다.
가상 머신 이미지는 HTTP 또는 HTTPS 끝점에서 호스팅하거나 이미지를 컨테이너 디스크에 빌드하고 컨테이너 레지스트리에 저장할 수 있습니다.
VirtualMachine
구성 파일에서 이미지의 데이터 소스를 지정합니다. 가상 머신이 생성되면 가상 머신 이미지가 있는 데이터 볼륨을 스토리지로 가져옵니다.
사전 요구 사항
가상 머신 이미지를 가져오려면 다음이 있어야 합니다.
-
RAW, ISO 또는 QCOW2 형식의 가상 머신 디스크 이미지(필요한 경우
xz
또는gz
를 사용하여 압축) - 데이터 소스에 액세스하는 데 필요한 인증 자격 증명과 함께 이미지가 호스팅되는 HTTP 또는 HTTPS 끝점
-
RAW, ISO 또는 QCOW2 형식의 가상 머신 디스크 이미지(필요한 경우
- 컨테이너 디스크를 가져오려면 데이터 소스에 액세스하는 데 필요한 인증 자격 증명과 함께 컨테이너 디스크에 빌드되고 컨테이너 레지스트리에 저장된 가상 머신 이미지가 있어야 합니다.
- 가상 머신이 자체 서명된 인증서 또는 시스템 CA 번들에서 서명되지 않은 인증서를 사용하는 서버와 통신해야 하는 경우 데이터 볼륨과 동일한 네임스페이스에 구성 맵을 생성해야 합니다.
절차
데이터 소스에 인증이 필요한 경우 데이터 소스 인증 정보를 지정하여
Secret
매니페스트를 생성하고 이를endpoint-secret.yaml
로 저장합니다.apiVersion: v1 kind: Secret metadata: name: endpoint-secret 1 labels: app: containerized-data-importer type: Opaque data: accessKeyId: "" 2 secretKey: "" 3
보안 매니페스트
를
적용합니다.$ oc apply -f endpoint-secret.yaml
가져올 가상 머신 이미지의 데이터 소스를 지정하여
VirtualMachine
매니페스트를 편집하고vm-fedora-datavolume.yaml
로 저장합니다.apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: creationTimestamp: null labels: kubevirt.io/vm: vm-fedora-datavolume name: vm-fedora-datavolume 1 spec: dataVolumeTemplates: - metadata: creationTimestamp: null name: fedora-dv 2 spec: storage: resources: requests: storage: 10Gi storageClassName: local source: http: 3 url: "https://mirror.arizona.edu/fedora/linux/releases/35/Cloud/x86_64/images/Fedora-Cloud-Base-35-1.2.x86_64.qcow2" 4 secretRef: endpoint-secret 5 certConfigMap: "" 6 status: {} running: true template: metadata: creationTimestamp: null labels: kubevirt.io/vm: vm-fedora-datavolume spec: domain: devices: disks: - disk: bus: virtio name: datavolumedisk1 machine: type: "" resources: requests: memory: 1.5Gi terminationGracePeriodSeconds: 60 volumes: - dataVolume: name: fedora-dv name: datavolumedisk1 status: {}
- 1
- 가상 머신의 이름을 지정합니다.
- 2
- 데이터 볼륨의 이름을 지정합니다.
- 3
- HTTP 또는 HTTPS 엔드포인트에
http
를 지정합니다.레지스트리에서
가져온 컨테이너 디스크 이미지의 레지스트리를 지정합니다. - 4
- 가져올 가상 머신 이미지의 소스입니다. 이 예제에서는 HTTPS 끝점에서 가상 머신 이미지를 참조합니다. 컨테이너 레지스트리 끝점은 예를 들면
url: "docker://kubevirt/fedora-cloud-container-disk-demo:latest"
와 같습니다. - 5
- 데이터 소스에 대한 보안을 생성한 경우 필수 항목입니다.
- 6
- 선택 사항: CA 인증서 구성 맵을 지정합니다.
가상 머신을 생성합니다.
$ oc create -f vm-fedora-datavolume.yaml
참고oc create
명령은 데이터 볼륨과 가상 머신을 생성합니다. CDI 컨트롤러에서 올바른 주석을 사용하여 기본 PVC를 생성하고 가져오기 프로세스가 시작됩니다. 가져오기가 완료되면 데이터 볼륨 상태가Succeeded
로 변경됩니다. 가상 머신을 시작할 수 있습니다.데이터 볼륨 프로비저닝은 백그라운드에서 이루어지므로 프로세스를 모니터링할 필요가 없습니다.
검증
가져오기 Pod는 지정된 URL에서 가상 머신 이미지 또는 컨테이너 디스크를 다운로드하여 프로비저닝된 PV에 저장합니다. 다음 명령을 실행하여 가져오기 Pod의 상태를 확인합니다.
$ oc get pods
다음 명령을 실행하여 상태가
Succeeded
될 때까지 데이터 볼륨을 모니터링합니다.$ oc describe dv fedora-dv 1
- 1
VirtualMachine
매니페스트에 정의된 데이터 볼륨 이름을 지정합니다.
직렬 콘솔에 액세스하여 프로비저닝이 완료되고 가상 머신이 시작되었는지 확인합니다.
$ virtctl console vm-fedora-datavolume
7.15.3. 데이터 볼륨을 사용하여 가상 머신 이미지를 블록 스토리지로 가져오기
기존 가상 머신 이미지를 OpenShift Container Platform 클러스터로 가져올 수 있습니다. OpenShift Virtualization은 데이터 볼륨을 사용하여 데이터 가져오기와 기본 PVC(영구 볼륨 클레임) 생성을 자동화합니다.
디스크 이미지를 PVC로 가져오면 PVC에 요청한 전체 스토리지 용량을 사용하도록 디스크 이미지가 확장됩니다. 이 공간을 사용하기 위해 가상 머신의 디스크 파티션 및 파일 시스템을 확장해야 할 수 있습니다.
크기 조정 절차는 가상 머신에 설치된 운영 체제에 따라 다릅니다. 자세한 내용은 운영 체제 설명서를 참조하십시오.
7.15.3.1. 사전 요구 사항
- CDI 지원 작업 매트릭스에 따라 스크래치 공간이 필요한 경우, 이 작업을 완료하기 위해서는 먼저 스토리지 클래스를 정의하거나 CDI 스크래치 공간을 준비해야 합니다.
7.15.3.2. 데이터 볼륨 정보
Dataolume
오브젝트는 CDI(Containerized Data Importer) 프로젝트에서 제공하는 사용자 정의 리소스입니다. 데이터 볼륨은 기본 PVC(영구 볼륨 클레임)와 관련된 가져오기, 복제, 업로드 작업을 오케스트레이션합니다. 데이터 볼륨은 OpenShift Virtualization과 통합되며 PVC가 준비되기 전에 가상 머신이 시작되지 않도록 합니다.
7.15.3.3. 블록 영구 볼륨 정보
PV(블록 영구 볼륨)는 원시 블록 장치에서 지원하는 PV입니다. 이러한 볼륨은 파일 시스템이 없으며 오버헤드를 줄여 가상 머신의 성능을 향상시킬 수 있습니다.
원시 블록 볼륨은 volumeMode를 지정하여 프로비저닝됩니다. PV 및 PVC(영구 볼륨 클레임) 사양에서 block
7.15.3.4. 로컬 블록 영구 볼륨 생성
파일을 채우고 루프 장치로 마운트하여 노드에 로컬 블록 PV(영구 볼륨)를 생성합니다. 그런 다음 PV 매니페스트에서 이 루프 장치를 Block
볼륨으로 참조하고 가상 머신 이미지의 블록 장치로 사용할 수 있습니다.
절차
-
로컬 PV를 생성할 노드에
root
로 로그인합니다. 이 절차에서는 예제로node01
을 사용합니다. 블록 장치로 사용할 수 있도록 파일을 생성하고 null 문자로 채웁니다. 다음 예제에서는 크기가 2Gb(20X100Mb 블록)인 파일
loop10
을 생성합니다.$ dd if=/dev/zero of=<loop10> bs=100M count=20
loop10
파일을 루프 장치로 마운트합니다.$ losetup </dev/loop10>d3 <loop10> 1 2
마운트된 루프 장치를 참조하는
PersistentVolume
매니페스트를 생성합니다.kind: PersistentVolume apiVersion: v1 metadata: name: <local-block-pv10> annotations: spec: local: path: </dev/loop10> 1 capacity: storage: <2Gi> volumeMode: Block 2 storageClassName: local 3 accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Delete nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - <node01> 4
블록 PV를 생성합니다.
# oc create -f <local-block-pv10.yaml>1
- 1
- 이전 단계에서 생성한 영구 볼륨의 파일 이름입니다.
7.15.3.5. 데이터 볼륨을 사용하여 가상 머신 이미지를 블록 스토리지로 가져오기
데이터 볼륨을 사용하여 가상 머신 이미지를 블록 스토리지로 가져올 수 있습니다. 가상 머신을 생성하기 전에 VirtualMachine
매니페스트의 데이터 볼륨을 참조합니다.
사전 요구 사항
-
RAW, ISO 또는 QCOW2 형식의 가상 머신 디스크 이미지(필요한 경우
xz
또는gz
를 사용하여 압축) - 데이터 소스에 액세스하는 데 필요한 인증 자격 증명과 함께 이미지가 호스팅되는 HTTP 또는 HTTPS 끝점
절차
데이터 소스에 인증이 필요한 경우 데이터 소스 인증 정보를 지정하여
Secret
매니페스트를 생성하고 이를endpoint-secret.yaml
로 저장합니다.apiVersion: v1 kind: Secret metadata: name: endpoint-secret 1 labels: app: containerized-data-importer type: Opaque data: accessKeyId: "" 2 secretKey: "" 3
보안 매니페스트
를
적용합니다.$ oc apply -f endpoint-secret.yaml
DataVolume
매니페스트를 생성하여 가상 머신 이미지의 데이터 소스 및storage.volumeMode
의 경우Block
을 지정합니다.apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: import-pv-datavolume 1 spec: storageClassName: local 2 source: http: url: "https://mirror.arizona.edu/fedora/linux/releases/35/Cloud/x86_64/images/Fedora-Cloud-Base-35-1.2.x86_64.qcow2" 3 secretRef: endpoint-secret 4 storage: volumeMode: Block 5 resources: requests: storage: 10Gi
데이터 볼륨을 생성하여 가상 머신 이미지를 가져옵니다.
$ oc create -f import-pv-datavolume.yaml
가상 머신을 생성하기 전에 VirtualMachine
매니페스트에서 이 데이터 볼륨을 참조할 수 있습니다.
7.15.3.6. CDI 지원 작업 매트릭스
이 매트릭스에는 끝점에 대한 콘텐츠 유형에 따라 지원되는 CDI 작업과 이러한 작업 중 스크래치 공간이 필요한 작업이 표시되어 있습니다.
콘텐츠 유형 | HTTP | HTTPS | HTTP 기본 인증 | 레지스트리 | 업로드 |
---|---|---|---|---|---|
KubeVirt(QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt(RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ 지원되는 작업
□ 지원되지 않는 작업
* 스크래치 공간 필요
** 사용자 정의 인증 기관이 필요한 경우 스크래치 공간 필요
7.15.4. 단일 Red Hat Virtualization 가상 머신 가져오기
VM 가져오기 마법사 또는 CLI를 사용하여 단일 RHV(Red Hat Virtualization) 가상 머신을 OpenShift Virtualization으로 가져올 수 있습니다.
7.15.4.1. OpenShift Virtualization 스토리지 기능 매트릭스
다음 표에는 VM 가져오기를 지원하는 OpenShift Virtualization 스토리지 유형이 설명되어 있습니다.
RHV VM 가져오기 | |
---|---|
OpenShift Container Storage: rbd 블록 모드 볼륨 | 있음 |
OpenShift Virtualization hostpath 프로비전 프로그램 | 아니요 |
기타 다중 노드 쓰기 가능 스토리지 | 예 [1] |
기타 단일 노드 쓰기 가능 스토리지 | 예 [2] |
- PVC에서 ReadWriteMany 액세스 모드를 요청해야 합니다.
- PVC에서 ReadWriteOnce 액세스 모드를 요청해야 합니다.
7.15.4.2. 가상 머신 가져오기 사전 요구 사항
RHV(Red Hat Virtualization)에서 OpenShift Virtualization으로 가상 머신을 가져오려면 다음과 같은 사전 요구 사항을 충족해야 합니다.
- 관리자 권한이 있어야 합니다.
스토리지:
- OpenShift Virtualization 로컬 및 공유 영구 스토리지 클래스에서 VM 가져오기를 지원해야 합니다.
- Ceph RBD 블록 모드 볼륨을 사용하는 경우 가상 디스크를 수용할 수 있도록 스토리지가 충분히 커야 합니다. 디스크가 사용 가능한 스토리지에 비해 너무 크면 가져오기 프로세스가 실패하고 가상 디스크를 복사하는 데 사용되는 PV가 해제되지 않습니다.
네트워크:
- RHV 네트워크와 OpenShift Virtualization 네트워크는 이름이 동일하거나 서로 매핑되어야 합니다.
-
RHV VM 네트워크 인터페이스는
e1000
,rtl8139
또는virtio
여야 합니다.
VM 디스크:
-
디스크 인터페이스는
sata
,virtio_scsi
또는virtio
여야 합니다. - 디스크를 직접 LUN으로 구성하지 않아야 합니다.
-
디스크 상태는
illegal
또는locked
가 아니어야 합니다. -
스토리지 유형이
image
여야 합니다. - SCSI 예약을 비활성화해야 합니다.
-
ScsiGenericIO
를 비활성화해야 합니다.
-
디스크 인터페이스는
VM 구성:
- VM에서 GPU 리소스를 사용하는 경우 GPU를 제공하는 노드를 구성해야 합니다.
- VM을 vGPU 리소스용으로 구성해서는 안 됩니다.
-
VM에
illegal
상태의 디스크가 있는 스냅샷이 없어야 합니다. - VM을 OpenShift Container Platform으로 생성한 후 RHV에 추가해서는 안 됩니다.
- VM을 USB 장치용으로 구성해서는 안 됩니다.
-
워치독 모델은
diag288
이 아니어야 합니다.
7.15.4.3. VM 가져오기 마법사를 사용하여 가상 머신 가져오기
VM 가져오기 마법사를 사용하여 단일 가상 머신을 가져올 수 있습니다.
절차
- 웹 콘솔에서 워크로드 → 가상 머신을 클릭합니다.
- 가상 머신 생성을 클릭하고 마법사로 가져오기를 선택합니다.
- 공급자 목록에서 RHV(Red Hat Virtualization)를 선택합니다.
새 인스턴스에 연결 또는 저장된 RHV 인스턴스를 선택합니다.
새 인스턴스에 연결을 선택하는 경우 다음 필드를 채우십시오.
-
API URL: 예를 들면
https://<RHV_Manager_FQDN>/ovirt-engine/api
입니다. CA 인증서: Browse(찾아보기 )를 클릭하여 RHV Manager CA 인증서를 업로드하거나 CA 인증서를 필드에 붙여넣습니다.
다음 명령을 실행하여 CA 인증서를 확인합니다.
$ openssl s_client -connect <RHV_Manager_FQDN>:443 -showcerts < /dev/null
CA 인증서는 출력의 두 번째 인증서입니다.
-
사용자 이름: RHV Manager 사용자 이름(예:
ocpadmin@internal
) - 암호: RHV Manager 암호
-
API URL: 예를 들면
- 저장된 RHV 인스턴스를 선택하면 저장된 자격 증명을 사용하여 마법사가 RHV 인스턴스에 연결됩니다.
확인 및 저장을 클릭하고 연결이 완료될 때까지 기다립니다.
참고연결 세부 정보는 시크릿에 저장됩니다. 잘못된 URL, 사용자 이름 또는 암호를 사용하여 공급자를 추가하는 경우 워크로드 → 시크릿을 클릭하고 공급자 시크릿을 삭제합니다.
- 클러스터와 가상 머신을 선택합니다.
- 다음을 클릭합니다.
- 검토 화면에서 설정을 검토합니다.
- 선택 사항: 생성 시 가상 머신 시작을 선택할 수 있습니다.
편집을 클릭하여 다음 설정을 업데이트합니다.
- 일반 → 이름: VM 이름은 63자로 제한됩니다.
일반 → 설명: VM에 대한 선택적 설명입니다.
스토리지 클래스: NFS 또는 ocs-storagecluster-ceph-rbd 를 선택합니다.
ocs-storagecluster-ceph-rbd를 선택하는 경우 디스크의 볼륨 모드를 블록으로 설정해야 합니다.
- 고급 → 볼륨 모드: Block 을 선택합니다.
- 고급 → 볼륨 모드: Block 을 선택합니다.
- 네트워킹 → 네트워크: 사용 가능한 네트워크 연결 정의 오브젝트 목록에서 네트워크를 선택할 수 있습니다.
가져오기 설정을 편집한 경우 가져오기 또는 검토 및 가져오기를 클릭합니다.
가상 머신 생성 완료 메시지와 가상 머신용으로 생성된 리소스 목록이 표시됩니다. 가상 머신은 워크로드 → 가상 머신에 나타납니다.
가상 머신 마법사 필드
이름 | 매개변수 | 설명 |
---|---|---|
템플릿 | 가상 머신을 생성할 템플릿입니다. 템플릿을 선택하면 기타 필드가 자동으로 완성됩니다. | |
소스 | PXE | PXE 메뉴에서 가상 머신을 프로비저닝합니다. 클러스터에 PXE 지원 NIC가 필요합니다. |
URL | HTTP 또는 S3 끝점의 사용 가능한 이미지에서 가상 머신을 프로비저닝합니다. | |
컨테이너 |
클러스터에서 액세스할 수 있는 레지스트리의 부팅 가능한 운영 체제 컨테이너에서 가상 머신을 프로비저닝합니다. 예를 들면 | |
디스크 | 디스크에서 가상 머신을 프로비저닝합니다. | |
운영 체제 | 가상 머신에 대해 선택된 기본 운영 체제입니다. | |
플레이버 | 작음, 중간, 큼, 매우 작음, 사용자 정의 | 가상 머신에 할당된 CPU 및 메모리의 양을 결정하는 사전 설정입니다. 플레이버에 표시되는 사전 설정은 운영 체제에 따라 다릅니다. |
메모리 | 가상 머신에 할당된 메모리 크기(GiB)입니다. | |
CPU | 가상 머신에 할당된 CPU의 양입니다. | |
워크로드 프로필 | 고성능 | 고성능 워크로드에 최적화된 가상 머신 구성입니다. |
서버 | 서버 워크로드를 실행하는 데 최적화된 프로필입니다. | |
데스크탑 | 데스크탑에서 사용할 가상 머신 구성입니다. | |
이름 |
이름에는 소문자( | |
설명 | 선택적 설명 필드입니다. | |
생성 시 가상 머신 시작 | 생성 시 가상 머신을 자동으로 시작하려면 선택합니다. |
네트워킹 필드
이름 | 설명 |
---|---|
이름 | 네트워크 인터페이스 컨트롤러의 이름입니다. |
모델 | 네트워크 인터페이스 컨트롤러의 모델을 나타냅니다. 지원되는 값은 e1000e 및 virtio입니다. |
네트워크 | 사용 가능한 네트워크 연결 정의 목록입니다. |
유형 |
사용 가능한 바인딩 방법 목록입니다. 기본 Pod 네트워크의 경우 권장되는 유일한 바인딩 방법은 |
MAC 주소 | 네트워크 인터페이스 컨트롤러의 MAC 주소입니다. MAC 주소를 지정하지 않으면 주소가 자동으로 할당됩니다. |
스토리지 필드
이름 | 설명 |
---|---|
소스 | 가상 머신의 빈 디스크를 선택하거나 사용 가능한 옵션 중에서 선택합니다. URL,컨테이너,복제된 디스크 연결 또는 디스크 연결. 기존 디스크를 선택하여 가상 머신에 연결하려면 사용 가능한 PVC(영구 볼륨 클레임) 목록에서 복제된 디스크 연결 또는 디스크 연결을 선택합니다. |
이름 |
디스크 이름입니다. 이름에는 소문자( |
크기(GiB) | 디스크 크기(GiB)입니다. |
인터페이스 | 디스크 장치의 유형입니다. 지원되는 인터페이스는 virtIO, SATA, SCSI입니다. |
스토리지 클래스 | 디스크를 만드는 데 사용되는 스토리지 클래스입니다. |
고급 → 볼륨 모드 | 영구 볼륨에서 포맷된 파일 시스템을 사용하는지 또는 원시 블록 상태를 사용하는지를 정의합니다. 기본값은 Filesystem입니다. |
고급 스토리지 설정
이름 | 매개변수 | 설명 |
---|---|---|
볼륨 모드 | 파일 시스템 | 파일 시스템 기반 볼륨에 가상 디스크를 저장합니다. |
블록 |
가상 디스크를 블록 볼륨에 직접 저장합니다. 기본 스토리지에서 지원하는 경우에만 | |
액세스 모드 [1] | 단일 사용자(RWO) | 디스크는 단일 노드에서 읽기/쓰기로 마운트할 수 있습니다. |
공유 액세스(RWX) | 디스크는 여러 노드에서 읽기/쓰기로 마운트할 수 있습니다. | |
읽기 전용(ROX) | 디스크는 많은 노드에서 읽기 전용으로 마운트할 수 있습니다. |
- 명령줄 인터페이스를 사용하여 액세스 모드를 변경할 수 있습니다.
7.15.4.4. CLI를 사용하여 가상 머신 가져오기
Secret
및 VirtualMachineImport
CR(사용자 정의 리소스)을 생성하여 CLI로 가상 머신을 가져올 수 있습니다. Secret
CR은 RHV Manager 자격 증명과 CA 인증서를 저장합니다. VirtualMachineImport
CR은 VM 가져오기 프로세스의 매개변수를 정의합니다.
선택 사항: VirtualMachineImport
CR과 별도의 ResourceMapping
CR을 생성할 수 있습니다. ResourceMapping
CR은 예를 들면 추가 RHV VM을 가져오는 경우 향상된 유연성을 제공합니다.
기본 대상 스토리지 클래스는 NFS여야 합니다. Cinder에서는 RHV VM 가져오기를 지원하지 않습니다.
절차
다음 명령을 실행하여
Secret
CR을 생성합니다.$ cat <<EOF | oc create -f - apiVersion: v1 kind: Secret metadata: name: rhv-credentials namespace: default 1 type: Opaque stringData: ovirt: | apiUrl: <api_endpoint> 2 username: ocpadmin@internal password: 3 caCert: | -----BEGIN CERTIFICATE----- 4 -----END CERTIFICATE----- EOF
$ openssl s_client -connect :443 -showcerts < /dev/null
선택 사항: 다음 명령을 실행하여
VirtualMachineImport
CR에서 리소스 매핑을 분리하려면ResourceMapping
CR을 생성합니다.$ cat <<EOF | kubectl create -f - apiVersion: v2v.kubevirt.io/v1alpha1 kind: ResourceMapping metadata: name: resourcemapping_example namespace: default spec: ovirt: networkMappings: - source: name: <rhv_logical_network>/<vnic_profile> 1 target: name: <target_network> 2 type: pod storageMappings: 3 - source: name: <rhv_storage_domain> 4 target: name: <target_storage_class> 5 volumeMode: <volume_mode> 6 EOF
- 1
- RHV 논리 네트워크 및 vNIC 프로필을 지정합니다.
- 2
- OpenShift Virtualization 네트워크를 지정합니다.
- 3
- 스토리지 매핑이
ResourceMapping
CR과VirtualMachineImport
CR에 모두 지정된 경우VirtualMachineImport
CR이 우선합니다. - 4
- RHV 스토리지 도메인을 지정합니다.
- 5
NFS
또는ocs-storagecluster-ceph-rbd
를 지정합니다.- 6
ocs-storagecluster-ceph-rbd
스토리지 클래스를 지정한 경우 볼륨 모드를Block
으로 지정해야 합니다.
다음 명령을 실행하여
VirtualMachineImport
CR을 생성합니다.$ cat <<EOF | oc create -f - apiVersion: v2v.kubevirt.io/v1beta1 kind: VirtualMachineImport metadata: name: vm-import namespace: default spec: providerCredentialsSecret: name: rhv-credentials namespace: default # resourceMapping: 1 # name: resourcemapping-example # namespace: default targetVmName: vm_example 2 startVm: true source: ovirt: vm: id: <source_vm_id> 3 name: <source_vm_name> 4 cluster: name: <source_cluster_name> 5 mappings: 6 networkMappings: - source: name: <source_logical_network>/<vnic_profile> 7 target: name: <target_network> 8 type: pod storageMappings: 9 - source: name: <source_storage_domain> 10 target: name: <target_storage_class> 11 accessMode: <volume_access_mode> 12 diskMappings: - source: id: <source_vm_disk_id> 13 target: name: <target_storage_class> 14 EOF
- 1
ResourceMapping
CR을 생성하는 경우resourceMapping
섹션의 주석을 제거하십시오.- 2
- 대상 VM 이름을 지정합니다.
- 3
- 소스 VM ID를 지정합니다(예:
80554327-0569-496b-bdeb-fcbbf52b827b
). Manager 머신의 웹 브라우저에https://www.example.com/ovirt-engine/api/vms/
를 입력하여 모든 VM을 나열하는 방식으로 VM ID를 가져올 수 있습니다. 가져올 VM과 해당 VM ID를 찾습니다. VM 이름이나 클러스터 이름을 지정할 필요가 없습니다. - 4
- 소스 VM 이름을 지정하는 경우 소스 클러스터도 지정해야 합니다. 소스 VM ID는 지정하지 않도록 합니다.
- 5
- 소스 클러스터를 지정하는 경우 소스 VM 이름도 지정해야 합니다. 소스 VM ID는 지정하지 않도록 합니다.
- 6
ResourceMapping
CR을 생성하는 경우mappings
섹션을 주석으로 처리합니다.- 7
- 소스 VM의 논리 네트워크 및 vNIC 프로필을 지정합니다.
- 8
- OpenShift Virtualization 네트워크를 지정합니다.
- 9
- 스토리지 매핑이
ResourceMapping
CR과VirtualMachineImport
CR에 모두 지정된 경우VirtualMachineImport
CR이 우선합니다. - 10
- 소스 스토리지 도메인을 지정합니다.
- 11
- 대상 스토리지 클래스를 지정합니다.
- 12
ReadWriteOnce
,ReadWriteMany
또는ReadOnlyMany
를 지정합니다. 액세스 모드가 지정되지 않은 경우 {virt}는 RHV VM의 호스트 → 마이그레이션 모드 설정 또는 가상 디스크 액세스 모드를 기반으로 올바른 볼륨 액세스 모드를 결정합니다.-
RHV VM 마이그레이션 모드가
수동 및 자동 마이그레이션 허용
인 경우 기본 액세스 모드는ReadWriteMany
입니다. -
RHV 가상 디스크 액세스 모드가
ReadOnly
이면 기본 액세스 모드는ReadOnlyMany
입니다. -
다른 모든 설정에서 기본 액세스 모드는
ReadWriteOnce
입니다.
-
RHV VM 마이그레이션 모드가
- 13
- 소스 VM 디스크 ID를 지정합니다(예:
8181ecc1-5db8-4193-9c92-3ddab3be7b05
). Manager 머신의 웹 브라우저에https://www.example.com/ovirt-engine/api/vms/vm23
을 입력하고 VM 세부 정보를 검토하여 디스크 ID를 가져올 수 있습니다. - 14
- 대상 스토리지 클래스를 지정합니다.
가상 머신 가져오기 진행률을 보고 가져오기가 성공했는지 확인합니다.
$ oc get vmimports vm-import -n default
가져오기가 성공했음을 나타내는 출력은 다음 예와 유사합니다.
출력 예
... status: conditions: - lastHeartbeatTime: "2020-07-22T08:58:52Z" lastTransitionTime: "2020-07-22T08:58:52Z" message: Validation completed successfully reason: ValidationCompleted status: "True" type: Valid - lastHeartbeatTime: "2020-07-22T08:58:52Z" lastTransitionTime: "2020-07-22T08:58:52Z" message: 'VM specifies IO Threads: 1, VM has NUMA tune mode specified: interleave' reason: MappingRulesVerificationReportedWarnings status: "True" type: MappingRulesVerified - lastHeartbeatTime: "2020-07-22T08:58:56Z" lastTransitionTime: "2020-07-22T08:58:52Z" message: Copying virtual machine disks reason: CopyingDisks status: "True" type: Processing dataVolumes: - name: fedora32-b870c429-11e0-4630-b3df-21da551a48c0 targetVmName: fedora32
7.15.4.4.1. VM 가져오기를 위한 구성 맵 만들기
기본 vm-import-controller
매핑을 재정의하거나 매핑을 추가하려는 경우 RHV(Red Hat Virtualization) 가상 머신 운영 체제를 OpenShift Virtualization 템플릿에 매핑하는 구성 맵을 만들 수 있습니다.
기본 vm-import-controller
구성 맵에는 다음 RHV 운영 체제와 해당하는 공통 OpenShift Virtualization 템플릿이 포함되어 있습니다.
RHV VM 운영 체제 | OpenShift Virtualization 템플릿 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
절차
웹 브라우저에서
http://<RHV_Manager_FQDN>/ovirt-engine/api/vms/<VM_ID>
로 이동하여 RHV VM 운영 체제의 REST API 이름을 확인합니다. 운영 체제 이름은 XML 출력의<os>
섹션에 다음 예와 같이 표시됩니다.... <os> ... <type>rhel_8x64</type> </os>
사용 가능한 OpenShift Virtualization 템플릿 목록을 확인합니다.
$ oc get templates -n openshift --show-labels | tr ',' '\n' | grep os.template.kubevirt.io | sed -r 's#os.template.kubevirt.io/(.*)=.*#\1#g' | sort -u
출력 예
fedora31 fedora32 ... rhel8.1 rhel8.2 ...
- RHV VM 운영 체제와 일치하는 OpenShift Virtualization 템플릿이 사용 가능한 템플릿 목록에 나타나지 않으면 OpenShift Virtualization 웹 콘솔을 사용하여 템플릿을 만듭니다.
RHV VM 운영 체제를 OpenShift Virtualization 템플릿에 매핑하는 구성 맵을 만듭니다.
$ cat <<EOF | oc create -f - apiVersion: v1 kind: ConfigMap metadata: name: os-configmap namespace: default 1 data: guestos2common: | "Red Hat Enterprise Linux Server": "rhel" "CentOS Linux": "centos" "Fedora": "fedora" "Ubuntu": "ubuntu" "openSUSE": "opensuse" osinfo2common: | "<rhv-operating-system>": "<vm-template>" 2 EOF
구성 맵 예
$ cat <<EOF | oc apply -f - apiVersion: v1 kind: ConfigMap metadata: name: os-configmap namespace: default data: osinfo2common: | "other_linux": "fedora31" EOF
사용자 정의 구성 맵이 생성되었는지 확인합니다.
$ oc get cm -n default os-configmap -o yaml
vm-import-controller-config
구성 맵을 패치하여 새 구성 맵을 적용합니다.$ oc patch configmap vm-import-controller-config -n openshift-cnv --patch '{ "data": { "osConfigMap.name": "os-configmap", "osConfigMap.namespace": "default" 1 } }'
- 1
- 구성 맵에서 네임스페이스를 변경한 경우 업데이트하십시오.
OpenShift Virtualization 웹 콘솔에 템플릿이 표시되는지 확인합니다.
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 템플릿 탭을 클릭하고 목록에서 템플릿을 찾습니다.
7.15.4.5. 가상 머신 가져오기 문제 해결
7.15.4.5.1. 로그
VM Import Controller Pod 로그에서 오류가 있는지 확인할 수 있습니다.
절차
다음 명령을 실행하여 VM Import Controller Pod 이름을 확인합니다.
$ oc get pods -n <namespace> | grep import 1
- 1
- 가져온 가상 머신의 네임스페이스를 지정합니다.
출력 예
vm-import-controller-f66f7d-zqkz7 1/1 Running 0 4h49m
다음 명령을 실행하여 VM Import Controller Pod 로그를 확인합니다.
$ oc logs <vm-import-controller-f66f7d-zqkz7> -f -n <namespace> 1
- 1
- VM Import Controller Pod 이름과 네임스페이스를 지정합니다.
7.15.4.5.2. 오류 메시지
다음과 같은 오류 메시지가 나타날 수 있습니다.
OpenShift Virtualization 스토리지 PV가 적합하지 않은 경우, VM Import Controller Pod 로그에 다음 오류 메시지가 표시되고 진행률 표시줄이 10%에서 멈춥니다.
Failed to bind volumes: provisioning failed for PVC
호환되는 스토리지 클래스를 사용해야 합니다. Cinder 스토리지 클래스는 지원되지 않습니다.
7.15.4.5.3. 확인된 문제
- 가상 디스크에 Ceph RBD 블록 모드 볼륨을 사용하고 있고 사용 가능한 스토리지 공간이 가상 디스크에 비해 너무 작으면 가져오기 프로세스 표시줄이 75%에서 20분 이상 중지되고 마이그레이션이 실패합니다. 웹 콘솔에 오류 메시지가 표시되지 않습니다. BZ#1910019
7.15.5. 단일 VMware 가상 머신 또는 템플릿 가져오기
VM Import 마법사를 사용하여 VMware vSphere 6.5, 6.7 또는 7.0 VM 또는 VM 템플릿을 OpenShift Virtualization으로 가져올 수 있습니다.
VM 템플릿을 가져오는 경우 OpenShift Virtualization에서 해당 템플릿을 기반으로 가상 머신을 생성합니다.
7.15.5.1. OpenShift Virtualization 스토리지 기능 매트릭스
다음 표에는 VM 가져오기를 지원하는 OpenShift Virtualization 스토리지 유형이 설명되어 있습니다.
VMware VM 가져오기 | |
---|---|
OpenShift Container Storage: rbd 블록 모드 볼륨 | 있음 |
OpenShift Virtualization hostpath 프로비전 프로그램 | 있음 |
기타 다중 노드 쓰기 가능 스토리지 | 예 [1] |
기타 단일 노드 쓰기 가능 스토리지 | 예 [2] |
- PVC에서 ReadWriteMany 액세스 모드를 요청해야 합니다.
- PVC에서 ReadWriteOnce 액세스 모드를 요청해야 합니다.
7.15.5.2. VDDK 이미지 준비
가져오기 프로세스에서는 VMware VDDK(가상 디스크 개발 키트)를 사용하여 VMware 가상 디스크를 복사합니다.
VDDK SDK를 다운로드하여 VDDK 이미지를 생성한 후 이미지를 이미지 레지스트리에 업로드하고 v2v-vmware
구성 맵에 추가할 수 있습니다.
VDDK 이미지에 사용할 내부 OpenShift Container Platform 이미지 레지스트리 또는 안전한 외부 이미지 레지스트리를 구성할 수 있습니다. OpenShift Virtualization 환경에서 레지스트리에 액세스할 수 있어야 합니다.
VDDK 이미지를 공용 레지스트리에 저장하면 VMware 라이센스 약관을 위반할 수 있습니다.
7.15.5.2.1. 내부 이미지 레지스트리 구성
Image Registry Operator 구성을 업데이트하여 베어 메탈에 내부 OpenShift Container Platform 이미지 레지스트리를 구성할 수 있습니다.
경로를 사용하여 레지스트리를 노출하면 OpenShift Container Platform 클러스터 내에서 직접 또는 외부에서 레지스트리에 액세스할 수 있습니다.
이미지 레지스트리의 관리 상태 변경
이미지 레지스트리를 시작하려면 Image Registry Operator 구성의 managementState
를 Removed
에서 Managed
로 변경해야 합니다.
절차
managementState
Image Registry Operator 구성을Removed
에서Managed
로 변경합니다. 예를 들면 다음과 같습니다.$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"managementState":"Managed"}}'
베어메탈 및 기타 수동 설치를 위한 레지스트리 스토리지 구성
클러스터 관리자는 설치한 후 스토리지를 사용하도록 레지스트리를 구성해야 합니다.
사전 요구 사항
- 클러스터 관리자 권한이 있어야 합니다.
- 베어 메탈과 같이 수동으로 프로비저닝된 RHCOS(Red Hat Enterprise Linux CoreOS) 노드를 사용하는 클러스터입니다.
Red Hat OpenShift Container Storage와 같이 클러스터용 영구 스토리지 프로비저닝.
중요OpenShift Container Platform은 복제본이 하나만 있는 경우 이미지 레지스트리 스토리지에 대한
ReadWriteOnce
액세스를 지원합니다. 두 개 이상의 복제본으로 고 가용성을 지원하는 이미지 레지스트리를 배포하려면ReadWriteMany
액세스가 필요합니다.- "100Gi" 용량이 필요합니다.
절차
스토리지를 사용하도록 레지스트리를 구성하기 위해
configs.imageregistry/cluster
리소스에서spec.storage.pvc
를 변경합니다.참고공유 스토리지를 사용할 때 보안 설정을 확인하여 외부에서의 액세스를 방지합니다.
레지스트리 pod가 없는지 확인합니다.
$ oc get pod -n openshift-image-registry
참고스토리지 유형이
emptyDIR
인 경우, 복제본 번호가1
보다 클 수 없습니다.레지스트리 구성을 확인합니다.
$ oc edit configs.imageregistry.operator.openshift.io
출력 예
storage: pvc: claim:
image-registry-storage
PVC의 자동 생성을 허용하도록claim
필드를 비워 둡니다.clusteroperator
상태를 확인합니다.$ oc get clusteroperator image-registry
이미지를 빌드 및 푸시할 수 있도록 레지스트리의 관리가 설정되어 있는지 확인하십시오.
다음을 실행합니다.
$ oc edit configs.imageregistry/cluster
다음으로 라인을 변경하십시오.
managementState: Removed
다음으로 변경
managementState: Managed
클러스터에서 직접 레지스트리에 액세스
클러스터 내부에서 레지스트리에 액세스할 수 있습니다.
절차
내부 경로를 사용하여 클러스터에서 레지스트리에 액세스합니다.
노드의 이름을 가져와서 노드에 액세스합니다.
$ oc get nodes
$ oc debug nodes/<node_name>
노드에서
oc
및podman
과 같은 툴에 대한 액세스를 활성화하려면 다음 명령을 실행합니다.sh-4.2# chroot /host
액세스 토큰을 사용하여 컨테이너 이미지 레지스트리에 로그인합니다.
sh-4.2# oc login -u kubeadmin -p <password_from_install_log> https://api-int.<cluster_name>.<base_domain>:6443
sh-4.2# podman login -u kubeadmin -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000
다음과 같은 로그인 확인 메시지가 표시되어야합니다.
Login Succeeded!
참고사용자 이름에 모든 값을 지정할 수 있으므로 토큰에는 필요한 모든 정보가 포함됩니다. 콜론이 포함된 사용자 이름을 지정하면 로그인에 실패합니다.
이미지 레지스트리 Operator가 경로를 생성하므로
default-route-openshift-image-registry.<cluster_name>
과 유사합니다.레지스트리에 대해
podman pull
및podman push
작업을 수행합니다.중요모든 이미지를 가져올 수 있지만 system:registry 역할이 추가된 경우 프로젝트의 레지스트리에만 이미지를 푸시할 수 있습니다.
다음 예에서는 다음을 사용합니다.
구성 요소 값 <registry_ip>
172.30.124.220
<port>
5000
<project>
openshift
<image>
image
<tag>
생략됨 (기본값
latest
)모든 이미지를 가져옵니다.
sh-4.2# podman pull name.io/image
<registry_ip>:<port>/<project>/<image>
형식으로 새 이미지에 태그를 지정합니다. OpenShift Container Platform이 레지스트리에 이미지를 올바르게 배치하고 나중에 액세스할 수 있도록 이 풀 사양에 프로젝트 이름이 표시되어야합니다.sh-4.2# podman tag name.io/image image-registry.openshift-image-registry.svc:5000/openshift/image
참고사용자가 이미지를 작성하거나 푸시할 수 있도록 지정된 프로젝트에 대한
system:image-builder
역할이 있어야합니다. 그렇지 않으면 다음 단계의podman push
가 실패합니다. 테스트를 위해 이미지를 푸시할 새 프로젝트를 만들 수 있습니다.새로 태그가 지정된 이미지를 레지스트리로 푸시합니다.
sh-4.2# podman push image-registry.openshift-image-registry.svc:5000/openshift/image
수동으로 보안 레지스트리 공개
클러스터 내에서 OpenShift Container Platform 레지스트리에 로그인하지 않고 외부에서 레지스트리에 액세스할 수 있도록 레지스트리의 라우팅을 공개합니다. 이를 통해 라우팅 주소를 사용하여 클러스터 외부에서 레지스트리에 로그인하고 라우팅 호스트를 사용하여 기존 프로젝트에 이미지를 태그 지정하거나 푸시할 수 있습니다.
사전 요구 사항
다음 사전 요구 사항이 자동으로 수행됩니다.
- 레지스트리 Operator를 배포합니다.
- Ingress Operator를 배포합니다.
절차
configs.imageregistry.operator.openshift.io
리소스에서 DefaultRoute
매개 변수를 사용하거나 사용자 지정 라우팅을 사용하여 라우팅을 공개할 수 있습니다.
DefaultRoute
를 사용하여 레지스트리를 공개하려면 다음을 수행합니다.
DefaultRoute
를True
로 설정합니다.$ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge
podman
으로 로그인합니다.$ HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')
$ podman login -u kubeadmin -p $(oc whoami -t) --tls-verify=false $HOST 1
- 1
--tls-verify=false
는 클러스터의 기본 라우팅 인증서를 신뢰할 수없는 경우 필요합니다. Ingress Operator를 사용하여 신뢰할 수있는 사용자 지정 인증서를 기본 인증서로 설정할 수 있습니다.
사용자 지정 라우팅을 사용하여 레지스트리를 공개하려면 다음을 수행합니다.
라우팅의 TLS 키로 보안 시크릿을 만듭니다.
$ oc create secret tls public-route-tls \ -n openshift-image-registry \ --cert=</path/to/tls.crt> \ --key=</path/to/tls.key>
이 단계는 선택 사항입니다. 보안 시크릿을 생성하지 않으면 라우팅은 Ingress Operator의 기본 TLS 구성을 사용합니다.
레지스트리 Operator에서 다음을 수행합니다.
spec: routes: - name: public-routes hostname: myregistry.mycorp.organization secretName: public-route-tls ...
참고레지스트리 라우팅에 대한 사용자 지정 TLS 구성을 제공하는 경우에만
secretName
을 설정합니다.
7.15.5.2.2. 외부 이미지 레지스트리 구성
VDDK 이미지에 외부 이미지 레지스트리를 사용하는 경우 외부 이미지 레지스트리의 인증 기관을 OpenShift Container Platform 클러스터에 추가할 수 있습니다.
필요한 경우 Docker 자격 증명에서 풀 시크릿을 생성하여 서비스 계정에 추가할 수 있습니다.
클러스터에 인증 기관 추가
다음 절차에 따라 이미지를 내보내고 가져올 때 사용할 클러스터에 인증서 CA(인증 기관)를 추가할 수 있습니다.
사전 요구 사항
- 클러스터 관리자 권한이 있어야합니다.
-
레지스트리의 공용 인증서(일반적으로
/etc/docker/certs.d/
디렉터리에 있는hostname/ca.crt
파일)에 액세스할 수 있어야 합니다.
절차
자체 서명 인증서를 사용하는 레지스트리의 경우 신뢰할 수 있는 인증서가 있는
openshift-config
네임스페이스에ConfigMap
을 생성합니다. 각 CA 파일에 대해ConfigMap
의 키가hostname[..port]
형식의 레지스트리 호스트 이름인지 확인하십시오.$ oc create configmap registry-cas -n openshift-config \ --from-file=myregistry.corp.com..5000=/etc/docker/certs.d/myregistry.corp.com:5000/ca.crt \ --from-file=otherregistry.com=/etc/docker/certs.d/otherregistry.com/ca.crt
클러스터 이미지 구성을 업데이트합니다.
$ oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-cas"}}}' --type=merge
Pod에서 다른 보안 레지스트리의 이미지를 참조하도록 허용
Docker 클라이언트의 .dockercfg
$HOME/.docker/config.json
파일은 이전에 보안 또는 비보안 레지스트리에 로그인한 적이 있는 경우 인증 정보를 저장하는 Docker 인증 정보 파일입니다.
OpenShift Container Platform의 내부 레지스트리가 아닌 다른 위치에서 보안 컨테이너 이미지를 가져오려면 Docker 인증 정보에서 풀 시크릿을 생성하여 서비스 계정에 추가해야 합니다.
프로세스
보안 레지스트리의
.dockercfg
파일이 이미 있는 경우 다음을 실행하여 해당 파일에서 시크릿을 생성할 수 있습니다.$ oc create secret generic <pull_secret_name> \ --from-file=.dockercfg=<path/to/.dockercfg> \ --type=kubernetes.io/dockercfg
$HOME/.docker/config.json
파일이 있는 경우 다음을 실행합니다.$ oc create secret generic <pull_secret_name> \ --from-file=.dockerconfigjson=<path/to/.docker/config.json> \ --type=kubernetes.io/dockerconfigjson
보안 레지스트리의 Docker 인증 정보 파일이 아직 없는 경우 다음을 실행하여 시크릿을 생성할 수 있습니다.
$ oc create secret docker-registry <pull_secret_name> \ --docker-server=<registry_server> \ --docker-username=<user_name> \ --docker-password=<password> \ --docker-email=<email>
Pod의 이미지 가져오기에 시크릿을 사용하려면 서비스 계정에 이 시크릿을 추가해야 합니다. 이 예제의 서비스 계정 이름은 Pod에서 사용하는 서비스 계정 이름과 일치해야 합니다.
default
는 기본 서비스 계정입니다.$ oc secrets link default <pull_secret_name> --for=pull
7.15.5.2.3. VDDK 이미지 생성 및 사용
VMware VDDK(가상 디스크 개발 키트)를 다운로드하고 VDDK 이미지를 빌드한 다음 VDDK 이미지를 이미지 레지스트리에 푸시할 수 있습니다. 그런 다음 v2v-vmware
구성 맵에 VDDK 이미지를 추가합니다.
사전 요구 사항
- OpenShift Container Platform 내부 이미지 레지스트리 또는 보안 외부 레지스트리에 액세스할 수 있어야 합니다.
절차
임시 디렉터리를 만들고 해당 디렉터리로 이동합니다.
$ mkdir /tmp/<dir_name> && cd /tmp/<dir_name>
- 브라우저에서 VMware 코드로 이동하여 SDK를 클릭합니다.
- Compute Virtualization에서 VDDK(가상 디스크 개발 키트)를 클릭합니다.
- 사용 중인 VMware vSphere 버전에 해당하는 VDDK 버전(예: vSphere 7.0의 경우 VDDK 7.0)을 선택하고, 다운로드를 클릭한 다음 임시 디렉터리에 VDDK 아카이브를 저장합니다.
VDDK 아카이브를 추출합니다.
$ tar -xzf VMware-vix-disklib-<version>.x86_64.tar.gz
Dockerfile
을 생성합니다.$ cat > Dockerfile <<EOF FROM busybox:latest COPY vmware-vix-disklib-distrib /vmware-vix-disklib-distrib RUN mkdir -p /opt ENTRYPOINT ["cp", "-r", "/vmware-vix-disklib-distrib", "/opt"] EOF
이미지를 빌드합니다.
$ podman build . -t <registry_route_or_server_path>/vddk:<tag> 1
- 1
- 이미지 레지스트리를 지정합니다.
-
내부 OpenShift Container Platform 레지스트리의 경우 내부 레지스트리 경로를 사용합니다(예:
image-registry.openshift-image-registry.svc:5000/openshift/vddk:<tag>
). -
외부 레지스트리의 경우 서버 이름, 경로, 태그를 지정합니다(예:
server.example.com:5000/vddk:<tag>
).
-
내부 OpenShift Container Platform 레지스트리의 경우 내부 레지스트리 경로를 사용합니다(예:
이미지를 로컬 레지스트리로 푸시합니다.
$ podman push <registry_route_or_server_path>/vddk:<tag>
- OpenShift Virtualization 환경에서 이미지에 액세스할 수 있는지 확인합니다.
openshift-cnv 프로젝트에서
v2v-vmware
구성 맵을 편집합니다.$ oc edit configmap v2v-vmware -n openshift-cnv
vddk-init-image
매개변수를data
스탠자에 추가합니다.... data: vddk-init-image: <registry_route_or_server_path>/vddk:<tag>
7.15.5.3. VM 가져오기 마법사를 사용하여 가상 머신 가져오기
VM 가져오기 마법사를 사용하여 단일 가상 머신을 가져올 수 있습니다.
또한 VM 템플릿을 가져올 수도 있습니다. VM 템플릿을 가져오는 경우 OpenShift Virtualization에서 해당 템플릿을 기반으로 가상 머신을 생성합니다.
사전 요구 사항
- 관리자 권한이 있어야 합니다.
- VMware VDDK(가상 디스크 개발 키트) 이미지는 OpenShift Virtualization 환경에서 액세스할 수 있는 이미지 레지스트리에 있어야 합니다.
-
VDDK 이미지는
v2v-vmware
구성 맵에 추가해야 합니다. - VM의 전원을 꺼야 합니다.
- 가상 디스크가 IDE 또는 SCSI 컨트롤러에 연결되어 있어야 합니다. 가상 디스크가 SATA 컨트롤러에 연결되어 있는 경우 IDE 컨트롤러로 변경한 다음 VM을 마이그레이션할 수 있습니다.
- OpenShift Virtualization 로컬 및 공유 영구 스토리지 클래스에서 VM 가져오기를 지원해야 합니다.
OpenShift Virtualization 스토리지는 가상 디스크를 수용할 수 있을 만큼 충분히 커야 합니다.
주의Ceph RBD 블록 모드 볼륨을 사용하는 경우 가상 디스크를 수용할 수 있도록 스토리지가 충분히 커야 합니다. 디스크가 사용 가능한 스토리지에 비해 너무 크면 가져오기 프로세스가 실패하고 가상 디스크를 복사하는 데 사용되는 PV가 해제되지 않습니다. 오브젝트 삭제를 지원할 리소스가 충분하지 않기 때문에 다른 가상 머신을 가져오거나 스토리지를 정리할 수 없습니다. 이 상황을 해결하려면 스토리지 백엔드에 오브젝트 스토리지 장치를 추가해야 합니다.
OpenShift Virtualization 송신 네트워크 정책에서 다음 트래픽을 허용해야 합니다.
대상 프로토콜 포트 VMware ESXi 호스트
TCP
443
VMware ESXi 호스트
TCP
902
VMware vCenter
TCP
5840
절차
- 웹 콘솔에서 워크로드 → 가상 머신을 클릭합니다.
- 가상 머신 생성을 클릭하고 마법사로 가져오기를 선택합니다.
- 공급자 목록에서 VMware를 선택합니다.
새 인스턴스에 연결 또는 저장된 vCenter 인스턴스를 선택합니다.
- 새 인스턴스에 연결을 선택한 경우 vCenter 호스트 이름, 사용자 이름, 암호를 입력합니다.
- 저장된 vCenter 인스턴스를 선택하면 저장된 자격 증명을 사용하여 마법사가 vCenter 인스턴스에 연결됩니다.
확인 및 저장을 클릭하고 연결이 완료될 때까지 기다립니다.
참고연결 세부 정보는 시크릿에 저장됩니다. 잘못된 호스트 이름, 사용자 이름 또는 암호를 사용하여 공급자를 추가하는 경우 워크로드 → 시크릿을 클릭하고 공급자 시크릿을 삭제합니다.
- 가상 머신 또는 템플릿을 선택합니다.
- 다음을 클릭합니다.
- 검토 화면에서 설정을 검토합니다.
편집을 클릭하여 다음 설정을 업데이트합니다.
일반:
- 설명
- 운영 체제
- 플레이버
- 메모리
- CPU
- 워크로드 프로필
네트워킹:
- 이름
- 모델
- 네트워크
- 유형
- MAC 주소
스토리지: VM 디스크의 옵션 메뉴 를 클릭하고 편집 을 선택하여 다음 필드를 업데이트합니다.
- 이름
- 출처: 예를 들면 디스크 가져오기 입니다.
- 크기
- 인터페이스
스토리지 클래스: NFS 또는 ocs-storagecluster-ceph-rbd(ceph-rbd) 를 선택합니다.
ocs-storagecluster-ceph-rbd를 선택하는 경우 디스크의 볼륨 모드를 블록으로 설정해야 합니다.
기타 스토리지 클래스도 작동할 수 있지만 공식적으로 지원되지 않습니다.
- 고급 → 볼륨 모드: Block 을 선택합니다.
- 고급 → 액세스 모드
고급 → Cloud-init:
- 양식: Hostname(호스트 이름) 및 Authenticated SSH Keys(인증된 SSH 키 )를 입력합니다.
-
사용자 정의 스크립트: 텍스트 필드에
cloud-init
스크립트를 입력합니다.
- 고급 → 가상 하드웨어: 가져온 가상 머신에 가상 CD-ROM을 연결할 수 있습니다.
가져오기 설정을 편집한 경우 가져오기 또는 검토 및 가져오기를 클릭합니다.
가상 머신 생성 완료 메시지와 가상 머신용으로 생성된 리소스 목록이 표시됩니다. 가상 머신은 워크로드 → 가상 머신에 나타납니다.
가상 머신 마법사 필드
이름 | 매개변수 | 설명 |
---|---|---|
템플릿 | 가상 머신을 생성할 템플릿입니다. 템플릿을 선택하면 기타 필드가 자동으로 완성됩니다. | |
소스 | PXE | PXE 메뉴에서 가상 머신을 프로비저닝합니다. 클러스터에 PXE 지원 NIC가 필요합니다. |
URL | HTTP 또는 S3 끝점의 사용 가능한 이미지에서 가상 머신을 프로비저닝합니다. | |
컨테이너 |
클러스터에서 액세스할 수 있는 레지스트리의 부팅 가능한 운영 체제 컨테이너에서 가상 머신을 프로비저닝합니다. 예를 들면 | |
디스크 | 디스크에서 가상 머신을 프로비저닝합니다. | |
운영 체제 | 가상 머신에 대해 선택된 기본 운영 체제입니다. | |
플레이버 | 작음, 중간, 큼, 매우 작음, 사용자 정의 | 가상 머신에 할당된 CPU 및 메모리의 양을 결정하는 사전 설정입니다. 플레이버에 표시되는 사전 설정은 운영 체제에 따라 다릅니다. |
메모리 | 가상 머신에 할당된 메모리 크기(GiB)입니다. | |
CPU | 가상 머신에 할당된 CPU의 양입니다. | |
워크로드 프로필 | 고성능 | 고성능 워크로드에 최적화된 가상 머신 구성입니다. |
서버 | 서버 워크로드를 실행하는 데 최적화된 프로필입니다. | |
데스크탑 | 데스크탑에서 사용할 가상 머신 구성입니다. | |
이름 |
이름에는 소문자( | |
설명 | 선택적 설명 필드입니다. | |
생성 시 가상 머신 시작 | 생성 시 가상 머신을 자동으로 시작하려면 선택합니다. |
Cloud-init 필드
이름 | 설명 |
---|---|
호스트 이름 | 가상 머신의 특정 호스트 이름을 설정합니다. |
인증된 SSH 키 | 가상 머신의 ~/.ssh/authorized_keys에 복사되는 사용자의 공개 키입니다. |
사용자 정의 스크립트 | 기타 옵션을 사용자 정의 cloud-init 스크립트를 붙여넣는 필드로 교체합니다. |
네트워킹 필드
이름 | 설명 |
---|---|
이름 | 네트워크 인터페이스 컨트롤러의 이름입니다. |
모델 | 네트워크 인터페이스 컨트롤러의 모델을 나타냅니다. 지원되는 값은 e1000e 및 virtio입니다. |
네트워크 | 사용 가능한 네트워크 연결 정의 목록입니다. |
유형 |
사용 가능한 바인딩 방법 목록입니다. 기본 Pod 네트워크의 경우 권장되는 유일한 바인딩 방법은 |
MAC 주소 | 네트워크 인터페이스 컨트롤러의 MAC 주소입니다. MAC 주소를 지정하지 않으면 주소가 자동으로 할당됩니다. |
스토리지 필드
이름 | 설명 |
---|---|
소스 | 가상 머신의 빈 디스크를 선택하거나 사용 가능한 옵션 중에서 선택합니다. URL,컨테이너,복제된 디스크 연결 또는 디스크 연결. 기존 디스크를 선택하여 가상 머신에 연결하려면 사용 가능한 PVC(영구 볼륨 클레임) 목록에서 복제된 디스크 연결 또는 디스크 연결을 선택합니다. |
이름 |
디스크 이름입니다. 이름에는 소문자( |
크기(GiB) | 디스크 크기(GiB)입니다. |
인터페이스 | 디스크 장치의 유형입니다. 지원되는 인터페이스는 virtIO, SATA, SCSI입니다. |
스토리지 클래스 | 디스크를 만드는 데 사용되는 스토리지 클래스입니다. |
고급 → 볼륨 모드 | 영구 볼륨에서 포맷된 파일 시스템을 사용하는지 또는 원시 블록 상태를 사용하는지를 정의합니다. 기본값은 Filesystem입니다. |
고급 → 액세스 모드 | 영구 볼륨의 액세스 모드입니다. 지원되는 액세스 모드는 ReadWriteOnce, ReadOnlyMany, ReadWriteMany입니다. |
고급 스토리지 설정
다음 고급 스토리지 설정은 비어 있음, URL을 통해 가져오기, 기존 PVC 복제 디스크에 사용할 수 있습니다. 해당 매개변수는 선택 사항입니다. 이러한 매개변수를 지정하지 않으면 kubevirt-storage-class-defaults
구성 맵의 기본값이 사용됩니다.
이름 | 매개변수 | 설명 |
---|---|---|
볼륨 모드 | 파일 시스템 | 파일 시스템 기반 볼륨에 가상 디스크를 저장합니다. |
블록 |
가상 디스크를 블록 볼륨에 직접 저장합니다. 기본 스토리지에서 지원하는 경우에만 | |
액세스 모드 | 단일 사용자(RWO) | 디스크는 단일 노드에서 읽기/쓰기로 마운트할 수 있습니다. |
공유 액세스(RWX) | 디스크는 여러 노드에서 읽기/쓰기로 마운트할 수 있습니다. 참고 이는 가상 머신의 노드 간 실시간 마이그레이션 등 일부 기능에 필요합니다. | |
읽기 전용(ROX) | 디스크는 많은 노드에서 읽기 전용으로 마운트할 수 있습니다. |
7.15.5.3.1. 가져온 가상 머신의 NIC 이름 업데이트
OpenShift Virtualization 이름 지정 규칙을 준수하도록 VMware에서 가져온 가상 머신의 NIC 이름을 업데이트해야 합니다.
절차
- 가상 머신에 로그인합니다.
-
/etc/sysconfig/network-scripts
디렉터리로 이동합니다. 네트워크 구성 파일의 이름을 변경합니다.
$ mv vmnic0 ifcfg-eth0 1
- 1
- 첫 번째 네트워크 구성 파일의 이름은
ifcfg-eth0
입니다. 추가 네트워크 구성 파일은 순서대로 번호가 지정됩니다(예:ifcfg-eth1
,ifcfg-eth2)
.
네트워크 구성 파일에서
NAME
및DEVICE
매개변수를 업데이트합니다.NAME=eth0 DEVICE=eth0
네트워크를 재시작합니다.
$ systemctl restart network
7.15.5.4. 가상 머신 가져오기 문제 해결
7.15.5.4.1. 로그
V2V 변환 Pod 로그에서 오류가 있는지 확인할 수 있습니다.
절차
7.15.5.4.2. 오류 메시지
다음과 같은 오류 메시지가 나타날 수 있습니다.
VMware VM을 가져오기 전에 종료하지 않으면 OpenShift Container Platform 콘솔에서 가져온 가상 머신에 오류 메시지
Readiness probe failed
가 표시되고, V2V Conversion Pod 로그에 다음 오류 메시지가 표시됩니다.INFO - have error: ('virt-v2v error: internal error: invalid argument: libvirt domain ‘v2v_migration_vm_1’ is running or paused. It must be shut down in order to perform virt-v2v conversion',)"
관리자가 아닌 사용자가 VM을 가져오려고 하면 OpenShift Container Platform 콘솔에 다음 오류 메시지가 표시됩니다.
Could not load config map vmware-to-kubevirt-os in kube-public namespace Restricted Access: configmaps "vmware-to-kubevirt-os" is forbidden: User cannot get resource "configmaps" in API group "" in the namespace "kube-public"
VM은 관리자만 가져올 수 있습니다.
7.16. 가상 머신 복제
7.16.1. 네임스페이스 간에 데이터 볼륨을 복제할 수 있는 사용자 권한 활성화
네임스페이스의 격리 특성으로 인해 기본적으로 사용자는 다른 네임스페이스에 리소스를 복제할 수 없습니다.
사용자가 가상 머신을 다른 네임스페이스에 복제할 수 있도록 하려면 cluster-admin
역할의 사용자가 새 클러스터 역할을 만들어야 합니다. 이 클러스터 역할을 사용자에게 바인딩하면 사용자가 가상 머신을 대상 네임스페이스에 복제할 수 있습니다.
7.16.1.1. 사전 요구 사항
-
cluster-admin
역할의 사용자만 클러스터 역할을 생성할 수 있습니다.
7.16.1.2. 데이터 볼륨 정보
Dataolume
오브젝트는 CDI(Containerized Data Importer) 프로젝트에서 제공하는 사용자 정의 리소스입니다. 데이터 볼륨은 기본 PVC(영구 볼륨 클레임)와 관련된 가져오기, 복제, 업로드 작업을 오케스트레이션합니다. 데이터 볼륨은 OpenShift Virtualization과 통합되며 PVC가 준비되기 전에 가상 머신이 시작되지 않도록 합니다.
7.16.1.3. 데이터 볼륨 복제를 위한 RBAC 리소스 생성
datavolumes
리소스에 대한 모든 작업 권한을 활성화하는 새 클러스터 역할을 만듭니다.
절차
ClusterRole
매니페스트를 만듭니다.apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: <datavolume-cloner> 1 rules: - apiGroups: ["cdi.kubevirt.io"] resources: ["datavolumes/source"] verbs: ["*"]
- 1
- 클러스터 역할의 고유 이름입니다.
클러스터에 클러스터 역할을 만듭니다.
$ oc create -f <datavolume-cloner.yaml> 1
- 1
- 이전 단계에서 만든
ClusterRole
매니페스트 파일 이름입니다.
소스 및 대상 네임스페이스 모두에 적용되고 이전 단계에서 만든 클러스터 역할을 참조하는
RoleBinding
매니페스트를 만듭니다.apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: <allow-clone-to-user> 1 namespace: <Source namespace> 2 subjects: - kind: ServiceAccount name: default namespace: <Destination namespace> 3 roleRef: kind: ClusterRole name: datavolume-cloner 4 apiGroup: rbac.authorization.k8s.io
클러스터에 역할 바인딩을 만듭니다.
$ oc create -f <datavolume-cloner.yaml> 1
- 1
- 이전 단계에서 만든
RoleBinding
매니페스트 파일 이름입니다.
7.16.2. 가상 머신 디스크를 새 데이터 볼륨으로 복제
데이터 볼륨 구성 파일에서 소스 PVC(영구 볼륨 클레임)를 참조하여 가상 머신 디스크의 PVC를 새 데이터 볼륨으로 복제할 수 있습니다.
볼륨 모드가 서로 다르면 복제 작업을 수행할 수 없습니다. 소스 사양과 대상 사양의 volumeMode
값이 일치해야 합니다.
예를 들어 volumeMode가 있는 PV(영구 볼륨)에서 복제를 시도하는 경우 다음을 실행합니다.
을(를) volumeMode인 PV에 차단합니다. filesystem
, 오류 메시지와 함께 작업이 실패합니다.
7.16.2.1. 사전 요구 사항
- 가상 머신 디스크의 PVC를 다른 네임스페이스로 복제하려면 추가 권한이 필요합니다.
7.16.2.2. 데이터 볼륨 정보
Dataolume
오브젝트는 CDI(Containerized Data Importer) 프로젝트에서 제공하는 사용자 정의 리소스입니다. 데이터 볼륨은 기본 PVC(영구 볼륨 클레임)와 관련된 가져오기, 복제, 업로드 작업을 오케스트레이션합니다. 데이터 볼륨은 OpenShift Virtualization과 통합되며 PVC가 준비되기 전에 가상 머신이 시작되지 않도록 합니다.
7.16.2.3. 가상 머신 디스크의 영구 볼륨 클레임을 새 데이터 볼륨으로 복제
기존 가상 머신 디스크의 PVC(영구 볼륨 클레임)를 새 데이터 볼륨으로 복제할 수 있습니다. 그러면 새 데이터 볼륨을 새 가상 머신에 사용할 수 있습니다.
데이터 볼륨이 가상 머신과 독립적으로 생성되는 경우 데이터 볼륨의 라이프사이클은 가상 머신과 독립적입니다. 가상 머신이 삭제되어도 데이터 볼륨이나 연결된 PVC가 삭제되지 않습니다.
사전 요구 사항
- 사용할 기존 가상 머신 디스크의 PVC를 결정합니다. PVC와 연결된 가상 머신의 전원을 꺼야 복제할 수 있습니다.
-
OpenShift CLI(
oc
)를 설치합니다.
절차
- 복제하려는 가상 머신 디스크를 검사하여 연결된 PVC의 이름과 네임스페이스를 확인합니다.
데이터 볼륨에 대해 새 데이터 볼륨의 이름, 소스 PVC의 이름과 네임스페이스, 새 데이터 볼륨의 크기를 지정하는 YAML 파일을 생성합니다.
예를 들면 다음과 같습니다.
apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: <cloner-datavolume> 1 spec: source: pvc: namespace: "<source-namespace>" 2 name: "<my-favorite-vm-disk>" 3 pvc: accessModes: - ReadWriteOnce resources: requests: storage: <2Gi> 4
데이터 볼륨을 생성하여 PVC 복제를 시작합니다.
$ oc create -f <cloner-datavolume>.yaml
참고데이터 볼륨이 있으면 PVC가 준비될 때까지 가상 머신이 시작되지 않으므로 PVC가 복제되는 동안 새 데이터 볼륨을 참조하는 가상 머신을 생성할 수 있습니다.
7.16.2.4. 템플릿: 데이터 볼륨 복제 구성 파일
example-clone-dv.yaml
apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: "example-clone-dv" spec: source: pvc: name: source-pvc namespace: example-ns pvc: accessModes: - ReadWriteOnce resources: requests: storage: "1G"
7.16.2.5. CDI 지원 작업 매트릭스
이 매트릭스에는 끝점에 대한 콘텐츠 유형에 따라 지원되는 CDI 작업과 이러한 작업 중 스크래치 공간이 필요한 작업이 표시되어 있습니다.
콘텐츠 유형 | HTTP | HTTPS | HTTP 기본 인증 | 레지스트리 | 업로드 |
---|---|---|---|---|---|
KubeVirt(QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt(RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ 지원되는 작업
□ 지원되지 않는 작업
* 스크래치 공간 필요
** 사용자 정의 인증 기관이 필요한 경우 스크래치 공간 필요
7.16.3. 데이터 볼륨 템플릿을 사용하여 가상 머신 복제
기존 VM의 PVC(영구 볼륨 클레임)를 복제하여 새 가상 머신을 생성할 수 있습니다. 가상 머신 구성 파일에 dataVolumeTemplate
을 포함하여 원래 PVC에서 새 데이터 볼륨을 생성합니다.
볼륨 모드가 서로 다르면 복제 작업을 수행할 수 없습니다. 소스 사양과 대상 사양의 volumeMode
값이 일치해야 합니다.
예를 들어 volumeMode가 있는 PV(영구 볼륨)에서 복제를 시도하는 경우 다음을 실행합니다.
을(를) volumeMode인 PV에 차단합니다. filesystem
, 오류 메시지와 함께 작업이 실패합니다.
7.16.3.1. 사전 요구 사항
- 가상 머신 디스크의 PVC를 다른 네임스페이스로 복제하려면 추가 권한이 필요합니다.
7.16.3.2. 데이터 볼륨 정보
Dataolume
오브젝트는 CDI(Containerized Data Importer) 프로젝트에서 제공하는 사용자 정의 리소스입니다. 데이터 볼륨은 기본 PVC(영구 볼륨 클레임)와 관련된 가져오기, 복제, 업로드 작업을 오케스트레이션합니다. 데이터 볼륨은 OpenShift Virtualization과 통합되며 PVC가 준비되기 전에 가상 머신이 시작되지 않도록 합니다.
7.16.3.3. 데이터 볼륨 템플릿을 사용하여 복제된 영구 볼륨 클레임에서 새 가상 머신 생성
기존 가상 머신의 PVC(영구 볼륨 클레임)를 데이터 볼륨에 복제하는 가상 머신을 생성할 수 있습니다. 가상 머신 매니페스트에서 dataVolumeTemplate
을 참조하면 source
PVC가 데이터 볼륨에 복제되어 가상 머신 생성에 자동으로 사용됩니다.
데이터 볼륨이 가상 머신의 데이터 볼륨 템플릿의 일부로 생성되면 데이터 볼륨의 라이프사이클이 가상 머신에 따라 달라집니다. 가상 머신이 삭제되면 데이터 볼륨 및 연결된 PVC도 삭제됩니다.
사전 요구 사항
- 사용할 기존 가상 머신 디스크의 PVC를 결정합니다. PVC와 연결된 가상 머신의 전원을 꺼야 복제할 수 있습니다.
-
OpenShift CLI(
oc
)를 설치합니다.
절차
- 복제하려는 가상 머신을 검사하여 연결된 PVC의 이름과 네임스페이스를 확인합니다.
VirtualMachine
오브젝트에 대한 YAML 파일을 만듭니다. 다음 가상 머신 예제에서는source-namespace
네임스페이스에 있는my-favorite-vm-disk
를 복제합니다.favorite-clone
이라는2Gi
데이터 볼륨이my-favorite-vm-disk
에서 생성됩니다.예를 들면 다음과 같습니다.
apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: labels: kubevirt.io/vm: vm-dv-clone name: vm-dv-clone 1 spec: running: false template: metadata: labels: kubevirt.io/vm: vm-dv-clone spec: domain: devices: disks: - disk: bus: virtio name: root-disk resources: requests: memory: 64M volumes: - dataVolume: name: favorite-clone name: root-disk dataVolumeTemplates: - metadata: name: favorite-clone spec: pvc: accessModes: - ReadWriteOnce resources: requests: storage: 2Gi source: pvc: namespace: "source-namespace" name: "my-favorite-vm-disk"
- 1
- 생성할 가상 머신입니다.
PVC 복제 데이터 볼륨으로 가상 머신을 생성합니다.
$ oc create -f <vm-clone-datavolumetemplate>.yaml
7.16.3.4. 템플릿: 데이터 볼륨 가상 머신 구성 파일
example-dv-vm.yaml
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachine
metadata:
labels:
kubevirt.io/vm: example-vm
name: example-vm
spec:
dataVolumeTemplates:
- metadata:
name: example-dv
spec:
pvc:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1G
source:
http:
url: "" 1
running: false
template:
metadata:
labels:
kubevirt.io/vm: example-vm
spec:
domain:
cpu:
cores: 1
devices:
disks:
- disk:
bus: virtio
name: example-dv-disk
machine:
type: q35
resources:
requests:
memory: 1G
terminationGracePeriodSeconds: 0
volumes:
- dataVolume:
name: example-dv
name: example-dv-disk
- 1
- 해당하는 경우 가져올 이미지의
HTTP
소스입니다.
7.16.3.5. CDI 지원 작업 매트릭스
이 매트릭스에는 끝점에 대한 콘텐츠 유형에 따라 지원되는 CDI 작업과 이러한 작업 중 스크래치 공간이 필요한 작업이 표시되어 있습니다.
콘텐츠 유형 | HTTP | HTTPS | HTTP 기본 인증 | 레지스트리 | 업로드 |
---|---|---|---|---|---|
KubeVirt(QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt(RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ 지원되는 작업
□ 지원되지 않는 작업
* 스크래치 공간 필요
** 사용자 정의 인증 기관이 필요한 경우 스크래치 공간 필요
7.16.4. 가상 머신 디스크를 새 블록 스토리지 데이터 볼륨에 복제
데이터 볼륨 구성 파일의 소스 PVC(영구 볼륨 클레임)를 참조하여 가상 머신 디스크의 PVC를 새 블록 데이터 볼륨에 복제할 수 있습니다.
볼륨 모드가 서로 다르면 복제 작업을 수행할 수 없습니다. 소스 사양과 대상 사양의 volumeMode
값이 일치해야 합니다.
예를 들어 volumeMode가 있는 PV(영구 볼륨)에서 복제를 시도하는 경우 다음을 실행합니다.
을(를) volumeMode인 PV에 차단합니다. filesystem
, 오류 메시지와 함께 작업이 실패합니다.
7.16.4.1. 사전 요구 사항
- 가상 머신 디스크의 PVC를 다른 네임스페이스로 복제하려면 추가 권한이 필요합니다.
7.16.4.2. 데이터 볼륨 정보
Dataolume
오브젝트는 CDI(Containerized Data Importer) 프로젝트에서 제공하는 사용자 정의 리소스입니다. 데이터 볼륨은 기본 PVC(영구 볼륨 클레임)와 관련된 가져오기, 복제, 업로드 작업을 오케스트레이션합니다. 데이터 볼륨은 OpenShift Virtualization과 통합되며 PVC가 준비되기 전에 가상 머신이 시작되지 않도록 합니다.
7.16.4.3. 블록 영구 볼륨 정보
PV(블록 영구 볼륨)는 원시 블록 장치에서 지원하는 PV입니다. 이러한 볼륨은 파일 시스템이 없으며 오버헤드를 줄여 가상 머신의 성능을 향상시킬 수 있습니다.
원시 블록 볼륨은 volumeMode를 지정하여 프로비저닝됩니다. PV 및 PVC(영구 볼륨 클레임) 사양에서 block
7.16.4.4. 로컬 블록 영구 볼륨 생성
파일을 채우고 루프 장치로 마운트하여 노드에 로컬 블록 PV(영구 볼륨)를 생성합니다. 그런 다음 PV 매니페스트에서 이 루프 장치를 Block
볼륨으로 참조하고 가상 머신 이미지의 블록 장치로 사용할 수 있습니다.
절차
-
로컬 PV를 생성할 노드에
root
로 로그인합니다. 이 절차에서는 예제로node01
을 사용합니다. 블록 장치로 사용할 수 있도록 파일을 생성하고 null 문자로 채웁니다. 다음 예제에서는 크기가 2Gb(20X100Mb 블록)인 파일
loop10
을 생성합니다.$ dd if=/dev/zero of=<loop10> bs=100M count=20
loop10
파일을 루프 장치로 마운트합니다.$ losetup </dev/loop10>d3 <loop10> 1 2
마운트된 루프 장치를 참조하는
PersistentVolume
매니페스트를 생성합니다.kind: PersistentVolume apiVersion: v1 metadata: name: <local-block-pv10> annotations: spec: local: path: </dev/loop10> 1 capacity: storage: <2Gi> volumeMode: Block 2 storageClassName: local 3 accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Delete nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - <node01> 4
블록 PV를 생성합니다.
# oc create -f <local-block-pv10.yaml>1
- 1
- 이전 단계에서 생성한 영구 볼륨의 파일 이름입니다.
7.16.4.5. 가상 머신 디스크의 영구 볼륨 클레임을 새 데이터 볼륨으로 복제
기존 가상 머신 디스크의 PVC(영구 볼륨 클레임)를 새 데이터 볼륨으로 복제할 수 있습니다. 그러면 새 데이터 볼륨을 새 가상 머신에 사용할 수 있습니다.
데이터 볼륨이 가상 머신과 독립적으로 생성되는 경우 데이터 볼륨의 라이프사이클은 가상 머신과 독립적입니다. 가상 머신이 삭제되어도 데이터 볼륨이나 연결된 PVC가 삭제되지 않습니다.
사전 요구 사항
- 사용할 기존 가상 머신 디스크의 PVC를 결정합니다. PVC와 연결된 가상 머신의 전원을 꺼야 복제할 수 있습니다.
-
OpenShift CLI(
oc
)를 설치합니다. - 소스 PVC와 크기가 같거나 더 큰 블록 PV(영구 볼륨)가 한 개 이상 사용 가능합니다.
절차
- 복제하려는 가상 머신 디스크를 검사하여 연결된 PVC의 이름과 네임스페이스를 확인합니다.
데이터 볼륨에 대해 새 데이터 볼륨의 이름, 소스 PVC의 이름과 네임스페이스,
volumeMode를 지정하는 YAML 파일을 생성합니다. block
사용 가능한 블록 PV와 새 데이터 볼륨의 크기를 사용하도록 합니다.예를 들면 다음과 같습니다.
apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: <cloner-datavolume> 1 spec: source: pvc: namespace: "<source-namespace>" 2 name: "<my-favorite-vm-disk>" 3 pvc: accessModes: - ReadWriteOnce resources: requests: storage: <2Gi> 4 volumeMode: Block 5
데이터 볼륨을 생성하여 PVC 복제를 시작합니다.
$ oc create -f <cloner-datavolume>.yaml
참고데이터 볼륨이 있으면 PVC가 준비될 때까지 가상 머신이 시작되지 않으므로 PVC가 복제되는 동안 새 데이터 볼륨을 참조하는 가상 머신을 생성할 수 있습니다.
7.16.4.6. CDI 지원 작업 매트릭스
이 매트릭스에는 끝점에 대한 콘텐츠 유형에 따라 지원되는 CDI 작업과 이러한 작업 중 스크래치 공간이 필요한 작업이 표시되어 있습니다.
콘텐츠 유형 | HTTP | HTTPS | HTTP 기본 인증 | 레지스트리 | 업로드 |
---|---|---|---|---|---|
KubeVirt(QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt(RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ 지원되는 작업
□ 지원되지 않는 작업
* 스크래치 공간 필요
** 사용자 정의 인증 기관이 필요한 경우 스크래치 공간 필요
7.17. 가상 머신 네트워킹
7.17.1. 기본 Pod 네트워크에 대한 가상 머신 구성
masquerade
바인딩 모드를 사용하도록 네트워크 인터페이스를 구성하여 가상 머신을 기본 내부 Pod 네트워크에 연결할 수 있습니다.
KubeMacPool 구성 요소는 지정된 네임스페이스의 가상 머신 NIC에 대한 MAC 주소 풀 서비스를 제공합니다. 이는 기본적으로 활성화되어 있지 않습니다. 해당 네임스페이스에 KubeMacPool 라벨을 적용하여 네임스페이스에서 MAC 주소 풀을 활성화합니다.
7.17.1.1. 명령줄에서 가상 모드 구성
가상 모드를 사용하여 Pod IP 주소를 통해 나가는 가상 머신의 트래픽을 숨길 수 있습니다. 가상 모드에서는 NAT(Network Address Translation)를 사용하여 가상 머신을 Linux 브리지를 통해 Pod 네트워크 백엔드에 연결합니다.
가상 머신 구성 파일을 편집하여 가상 모드를 사용하도록 설정하고 트래픽이 가상 머신에 유입되도록 허용하십시오.
사전 요구 사항
- 가상 머신은 DHCP를 사용하여 IPv4 주소를 가져오도록 구성해야 합니다. 아래 예제는 DHCP를 사용하도록 구성되어 있습니다.
절차
가상 머신 구성 파일의
interfaces
스펙을 편집합니다.kind: VirtualMachine spec: domain: devices: interfaces: - name: default masquerade: {} 1 ports: - port: 80 2 networks: - name: default pod: {}
참고포트 49152 및 49153은 libvirt 플랫폼에서 사용하도록 예약되어 있으며 이러한 포트에 대한 기타 모든 들어오는 트래픽은 삭제됩니다.
가상 머신을 생성합니다.
$ oc create -f <vm-name>.yaml
7.17.1.2. 가상 머신에서 서비스 생성
먼저 가상 머신을 노출하는 Service
오브젝트를 생성하여 실행 중인 가상 머신에서 서비스를 생성합니다.
ClusterIP
서비스 유형은 클러스터 내에서 가상 머신을 내부적으로 노출합니다. NodePort
또는 LoadBalancer
서비스 유형은 클러스터 외부에 가상 머신을 노출합니다.
이 절차에서는 type의
.
Service
오브젝트를 생성, 연결 및 노출하는 방법에 대한 예를 보여줍니다. 가상 머신 지원 서비스로서의 ClusterIP
서비스 type
이 지정되지 않은 경우 ClusterIP
가 기본 서비스 type
입니다.
절차
다음과 같이 가상 머신 YAML을 편집합니다.
apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: name: vm-ephemeral namespace: example-namespace spec: running: false template: metadata: labels: special: key 1 spec: domain: devices: disks: - name: containerdisk disk: bus: virtio - name: cloudinitdisk disk: bus: virtio interfaces: - masquerade: {} name: default resources: requests: memory: 1024M networks: - name: default pod: {} volumes: - name: containerdisk containerDisk: image: kubevirt/fedora-cloud-container-disk-demo - name: cloudinitdisk cloudInitNoCloud: userData: | #!/bin/bash echo "fedora" | passwd fedora --stdin
- 1
spec.template.metadata.labels
섹션에special: key
라벨을 추가합니다.
참고가상 머신의 라벨은 Pod로 전달됩니다.
VirtualMachine
구성의 라벨(예:special: key
)은 이 절차의 뒷부분에서 생성하는Service
YAMLselector
특성의 라벨과 일치해야 합니다.- 가상 머신 YAML을 저장하여 변경 사항을 적용합니다.
Service
YAML을 편집하여Service
오브젝트를 생성하고 노출하는 데 필요한 설정을 구성합니다.apiVersion: v1 kind: Service metadata: name: vmservice 1 namespace: example-namespace 2 spec: ports: - port: 27017 protocol: TCP targetPort: 22 3 selector: special: key 4 type: ClusterIP 5
- 1
- 생성하고 노출하는 서비스의
name
을 지정합니다. - 2
Service
YAML의metadata
섹션에 가상 머신 YAML에서 지정한namespace
에 해당하는namespace
를 지정합니다.- 3
targetPort 추가: 22
, SSH 포트22
에 서비스를 노출합니다.- 4
Service
YAML의spec
섹션에서selector
특성에special: key
를 추가합니다. 이는 가상 머신 YAML 구성 파일에서 추가한labels
에 해당합니다.- 5
Service
YAML의spec
섹션에type을 추가합니다. ClusterIP 서비스 용 ClusterIP
NodePort
및LoadBalancer
와 같은 클러스터 외부에서 다른 유형의 서비스를 생성하고 노출하려면type을 교체합니다. ClusterIP
(이)가유형입니다. NodePort
또는유형: LoadBalancer
에 해당하는 경우.
-
Service
YAML을 저장하여 서비스 구성을 저장합니다. ClusterIP
서비스를 생성합니다.$ oc create -f <service_name>.yaml
- 가상 머신을 시작합니다. 가상 머신이 이미 실행 중인 경우 가상 머신을 재시작하십시오.
Service
오브젝트를 쿼리하여 해당 오브젝트가 사용 가능하고ClusterIP
유형으로 구성되어 있는지 확인합니다.검증
oc get service
명령을 실행하여 가상 머신 및Service
YAML 파일에서 참조하는namespace
를 지정합니다.$ oc get service -n example-namespace
출력 예
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE vmservice ClusterIP 172.30.3.149 <none> 27017/TCP 2m
-
출력에 표시된 것처럼
vmservice
가 실행되고 있습니다. -
TYPE
은Service
YAML에서 지정한 대로ClusterIP
로 표시됩니다.
-
출력에 표시된 것처럼
서비스를 지원하는 데 사용할 가상 머신에 대한 연결을 활성화합니다. 클러스터 내의 오브젝트(예: 다른 가상 머신)에서 연결합니다.
다음과 같이 가상 머신 YAML을 편집합니다.
apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: name: vm-connect namespace: example-namespace spec: running: false template: spec: domain: devices: disks: - name: containerdisk disk: bus: virtio - name: cloudinitdisk disk: bus: virtio interfaces: - masquerade: {} name: default resources: requests: memory: 1024M networks: - name: default pod: {} volumes: - name: containerdisk containerDisk: image: kubevirt/fedora-cloud-container-disk-demo - name: cloudinitdisk cloudInitNoCloud: userData: | #!/bin/bash echo "fedora" | passwd fedora --stdin
oc create
명령을 실행하여 두 번째 가상 머신을 만듭니다. 여기서file.yaml
은 가상 머신 YAML의 이름입니다.$ oc create -f <file.yaml>
- 가상 머신을 시작합니다.
다음
virtctl
명령을 실행하여 가상 머신에 연결합니다.$ virtctl -n example-namespace console <new-vm-name>
참고서비스 유형
LoadBalancer
의 경우vinagre
클라이언트를 사용하여 공용 IP 및 포트를 통해 가상 머신을 연결합니다. 서비스 유형LoadBalancer
를 사용할 때는 외부 포트가 동적으로 할당됩니다.ssh
명령을 실행하여 연결을 인증합니다. 여기서172.30.3.149
는 서비스의 ClusterIP이고fedora
는 가상 머신의 사용자 이름입니다.$ ssh fedora@172.30.3.149 -p 27017
검증
- 노출하려는 서비스를 지원하는 가상 머신의 명령 프롬프트가 표시됩니다. 그러면 실행 중인 가상 머신에서 서비스를 지원하는 것입니다.
7.17.2. Linux 브리지 네트워크에 가상 머신 연결
기본적으로 OpenShift Virtualization은 하나의 내부 Pod 네트워크를 사용하여 설치됩니다.
추가 네트워크에 연결하려면 Linux 브리지 네트워크 연결 정의(NAD)를 생성해야 합니다.
가상 머신을 추가 네트워크에 연결하려면 다음을 수행합니다.
- Linux 브리지 노드 네트워크 구성 정책을 만듭니다.
- Linux 브리지 네트워크 연결 정의를 만듭니다.
- 가상 머신이 네트워크 연결 정의를 인식할 수 있도록 가상 머신을 구성합니다.
스케줄링, 인터페이스 유형 및 기타 노드 네트워킹 활동에 대한 자세한 내용은 노드 네트워킹 섹션을 참조하십시오.
7.17.2.1. 네트워크 연결 정의를 통해 네트워크에 연결
7.17.2.1.1. Linux 브리지 노드 네트워크 구성 정책 생성
NodeNetworkConfigurationPolicy
매니페스트 YAML 파일을 사용하여 Linux 브리지를 만듭니다.
절차
NodeNetworkConfigurationPolicy
매니페스트를 생성합니다. 이 예제에는 해당 정보로 교체해야 하는 샘플 값이 포함되어 있습니다.apiVersion: nmstate.io/v1 kind: NodeNetworkConfigurationPolicy metadata: name: br1-eth1-policy 1 spec: desiredState: interfaces: - name: br1 2 description: Linux bridge with eth1 as a port 3 type: linux-bridge 4 state: up 5 ipv4: enabled: false 6 bridge: options: stp: enabled: false 7 port: - name: eth1 8
7.17.2.2. Linux 브리지 네트워크 연결 정의 생성
7.17.2.2.1. 사전 요구 사항
- 모든 노드에서 Linux 브리지를 구성하고 연결해야 합니다. 자세한 내용은 노드 네트워킹 섹션을 참조하십시오.
가상 머신의 네트워크 연결 정의에서 IPAM(IP 주소 관리) 구성은 지원되지 않습니다.
7.17.2.2.2. 웹 콘솔에서 Linux 브리지 네트워크 연결 정의 생성
네트워크 연결 정의는 계층 2 장치를 OpenShift Virtualization 클러스터의 특정 네임스페이스에 노출하는 사용자 정의 리소스입니다.
네트워크 관리자는 네트워크 연결 정의를 생성하여 기존 계층 2 네트워킹을 Pod 및 가상 머신에 제공할 수 있습니다.
절차
- 웹 콘솔에서 네트워킹 → 네트워크 연결 정의를 클릭합니다.
네트워크 연결 정의 생성을 클릭합니다.
참고네트워크 연결 정의는 Pod 또는 가상 머신과 동일한 네임스페이스에 있어야 합니다.
- 고유한 이름과 선택적 설명을 입력합니다.
- 네트워크 유형 목록을 클릭하고 CNV Linux 브리지를 선택합니다.
- 브리지 이름 필드에 브리지 이름을 입력합니다.
- 선택 사항: 리소스에 VLAN ID가 구성된 경우 VLAN 태그 번호 필드에 ID 번호를 입력합니다.
- 선택 사항: MAC Spoof Check 를 선택하여 MAC 스푸핑 필터링을 활성화합니다. 이 기능은 단일 MAC 주소만 Pod를 종료할 수 있도록 허용하여 MAC 스푸핑 공격에 대한 보안을 제공합니다.
생성을 클릭합니다.
참고Linux 브리지 네트워크 연결 정의는 가상 머신을 VLAN에 연결하는 가장 효율적인 방법입니다.
7.17.2.2.3. CLI에서 Linux 브리지 네트워크 연결 정의 생성
네트워크 관리자는 cnv-bridge
유형의 네트워크 연결 정의를 구성하여 Pod 및 가상 머신에 계층 2 네트워킹을 제공할 수 있습니다.
네트워크 연결 정의는 Pod 또는 가상 머신과 동일한 네임스페이스에 있어야 합니다.
절차
- 가상 머신과 동일한 네임스페이스에 네트워크 연결 정의를 생성합니다.
다음 예와 같이 네트워크 연결 정의에 가상 머신을 추가합니다.
apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: <bridge-network> 1 annotations: k8s.v1.cni.cncf.io/resourceName: bridge.network.kubevirt.io/<bridge-interface> 2 spec: config: '{ "cniVersion": "0.3.1", "name": "<bridge-network>", 3 "type": "cnv-bridge", 4 "bridge": "<bridge-interface>", 5 "macspoofchk": true, 6 "vlan": 1 7 }'
- 1
NetworkAttachmentDefinition
개체의 이름입니다.- 2
- 선택 사항: 노드 선택에 대한 주석 키-값 쌍입니다. 여기서
bridge-interface
는 일부 노드에 구성된 브릿지의 이름입니다. 네트워크 연결 정의에 이 주석을 추가하면bridge-interface
브리지가 연결된 노드에서만 가상 머신 인스턴스가 실행됩니다. - 3
- 구성의 이름입니다. 구성 이름이 네트워크 연결 정의의
name
값과 일치하는 것이 좋습니다. - 4
- 이 네트워크 연결 정의에 대한 네트워크를 제공하는 CNI(컨테이너 네트워크 인터페이스) 플러그인의 실제 이름입니다. 다른 CNI를 사용하려는 경우를 제외하고 이 필드를 변경하지 마십시오.
- 5
- 노드에 구성된 Linux 브리지의 이름입니다.
- 6
- 선택 사항: MAC 스푸핑 검사를 활성화하는 플래그입니다.
true
로 설정하면 Pod 또는 게스트 인터페이스의 MAC 주소를 변경할 수 없습니다. 이 속성은 단일 MAC 주소만 Pod를 종료할 수 있도록 허용하여 MAC 스푸핑 공격에 대한 보안을 제공합니다. - 7
- 선택 사항: VLAN 태그입니다. 노드 네트워크 구성 정책에 추가 VLAN 구성이 필요하지 않습니다.
참고Linux 브리지 네트워크 연결 정의는 가상 머신을 VLAN에 연결하는 가장 효율적인 방법입니다.
네트워크 연결 정의를 만듭니다.
$ oc create -f <network-attachment-definition.yaml> 1
- 1
- 여기서
<network-attachment-definition.yaml>
은 네트워크 연결 정의 매니페스트의 파일 이름입니다.
검증
다음 명령을 실행하여 네트워크 연결 정의가 생성되었는지 확인합니다.
$ oc get network-attachment-definition <bridge-network>
7.17.2.3. Linux 브리지 네트워크에 대한 가상 머신 구성
7.17.2.3.1. 웹 콘솔에서 가상 머신의 NIC를 생성
웹 콘솔에서 추가 NIC를 생성하고 가상 머신에 연결합니다.
절차
- OpenShift Virtualization 콘솔의 올바른 프로젝트에서 사이드 메뉴에 있는 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 가상 머신을 선택하여 가상 머신 개요 화면을 엽니다.
- 네트워크 인터페이스를 클릭하여 가상 머신에 이미 연결된 NIC를 표시합니다.
- 네트워크 인터페이스 추가를 클릭하여 목록에 새 슬롯을 만듭니다.
- 네트워크 드롭다운 목록을 사용하여 추가 네트워크에 대한 네트워크 연결 정의를 선택합니다.
- 새 NIC의 이름, 모델, 유형, MAC 주소를 입력합니다.
- Add(추가 )를 클릭하여 NIC를 저장하고 가상 머신에 연결합니다.
7.17.2.3.2. 네트워킹 필드
이름 | 설명 |
---|---|
이름 | 네트워크 인터페이스 컨트롤러의 이름입니다. |
모델 | 네트워크 인터페이스 컨트롤러의 모델을 나타냅니다. 지원되는 값은 e1000e 및 virtio입니다. |
네트워크 | 사용 가능한 네트워크 연결 정의 목록입니다. |
유형 |
사용 가능한 바인딩 방법 목록입니다. 기본 Pod 네트워크의 경우 권장되는 유일한 바인딩 방법은 |
MAC 주소 | 네트워크 인터페이스 컨트롤러의 MAC 주소입니다. MAC 주소를 지정하지 않으면 주소가 자동으로 할당됩니다. |
7.17.2.3.3. CLI의 추가 네트워크에 가상 머신 연결
브리지 인터페이스를 추가하고 가상 머신 구성에서 네트워크 연결 정의를 지정하여 가상 머신을 추가 네트워크에 연결합니다.
이 절차에서는 YAML 파일을 사용하여 구성을 편집하고 업데이트된 파일을 클러스터에 적용하는 방법을 시연합니다. 또는 oc edit <object> <name>
명령을 사용하여 기존 가상 머신을 편집할 수도 있습니다.
사전 요구 사항
- 구성을 편집하기 전에 가상 머신을 종료합니다. 실행 중인 가상 머신을 편집하는 경우 변경 사항을 적용하려면 가상 머신을 다시 시작해야 합니다.
절차
- 브리지 네트워크에 연결하려는 가상 머신 구성을 생성하거나 편집합니다.
spec.template.spec.domain.devices.interfaces
목록에 브리지 인터페이스를 추가하고spec.template.spec.networks
목록에 네트워크 연결 정의를 추가합니다. 이 예제에서는a-bridge-network
네트워크 연결 정의에 연결하는bridge-net
브리지 인터페이스를 추가합니다.apiVersion: v1 kind: VirtualMachine metadata: name: <example-vm> spec: template: spec: domain: devices: interfaces: - masquerade: {} name: <default> - bridge: {} name: <bridge-net> 1 ... networks: - name: <default> pod: {} - name: <bridge-net> 2 multus: networkName: <a-bridge-network> 3 ...
- 1
- 브리지 인터페이스의 이름입니다.
- 2
- 네트워크의 이름입니다. 이 값은 해당
spec.template.spec.domain.devices.interfaces
항목의name
값과 일치해야 합니다. - 3
- 네트워크 연결 정의의 이름, 존재하는 네임스페이스가 접두사로 지정됩니다. 네임스페이스는
default
네임스페이스 또는 VM을 생성할 동일한 네임스페이스여야 합니다. 이 경우multus
가 사용됩니다. Multus는 Pod 또는 가상 머신에서 필요한 인터페이스를 사용하도록 여러 CNI가 존재할 수 있는 클라우드 네트워크 인터페이스(CNI) 플러그인입니다.
설정을 적용합니다.
$ oc apply -f <example-vm.yaml>
- 선택 사항: 실행 중인 가상 머신을 편집한 경우 변경 사항을 적용하려면 가상 머신을 다시 시작해야 합니다.
7.17.3. 가상 머신용 IP 주소 구성
가상 머신에 대해 동적으로 또는 정적으로 프로비저닝된 IP 주소를 구성할 수 있습니다.
사전 요구 사항
- 가상 머신은 외부 네트워크에 연결되어 있어야 합니다.
- 가상 시스템의 동적 IP를 구성하려면 추가 네트워크에서 DHCP 서버를 사용할 수 있어야 합니다.
7.17.3.1. cloud-init를 사용하여 새 가상 머신의 IP 주소 구성
cloud-init를 사용하여 가상 머신을 생성할 때 IP 주소를 구성할 수 있습니다. IP 주소는 동적으로 또는 정적으로 프로비저닝될 수 있습니다.
절차
가상 머신을 구성하고 가상 머신 구성의
spec.volumes.cloudInitNoCloud.networkData
필드에 cloud-init 네트워크 세부 정보를 포함합니다.동적 IP를 구성하려면 인터페이스 이름과
dhcp4
부울을 지정합니다.kind: VirtualMachine spec: ... volumes: - cloudInitNoCloud: networkData: | version: 2 ethernets: eth1: 1 dhcp4: true 2
고정 IP를 구성하려면 인터페이스 이름과 IP 주소를 지정합니다.
kind: VirtualMachine spec: ... volumes: - cloudInitNoCloud: networkData: | version: 2 ethernets: eth1: 1 addresses: - 10.10.10.14/24 2
7.17.4. 가상 머신의 SR-IOV 네트워크 장치 구성
클러스터에서 가상 머신의 SR-IOV(Single Root I/O Virtualization) 장치를 구성할 수 있습니다. 이 프로세스는 OpenShift Container Platform의 SR-IOV 장치를 구성하는 것과 유사하지만 동일하지는 않습니다.
SR-IOV 네트워크 인터페이스에 연결된 가상 머신에서는 실시간 마이그레이션이 지원되지 않습니다.
7.17.4.1. 사전 요구 사항
- SR-IOV Operator가 설치되어있어야 합니다.
- SR-IOV Operator가 구성되어 있어야 합니다.
7.17.4.2. SR-IOV 네트워크 장치의 자동 검색
SR-IOV Network Operator는 작업자 노드에서 SR-IOV 가능 네트워크 장치를 클러스터에서 검색합니다. Operator는 호환되는 SR-IOV 네트워크 장치를 제공하는 각 작업자 노드에 대해 SriovNetworkNodeState CR(사용자 정의 리소스)을 생성하고 업데이트합니다.
CR에는 작업자 노드와 동일한 이름이 할당됩니다. status.interfaces
목록은 노드의 네트워크 장치에 대한 정보를 제공합니다.
SriovNetworkNodeState
오브젝트를 수정하지 마십시오. Operator는 이러한 리소스를 자동으로 생성하고 관리합니다.
7.17.4.2.1. SriovNetworkNodeState 오브젝트의 예
다음 YAML은 SR-IOV Network Operator가 생성한 SriovNetworkNodeState
오브젝트의 예입니다.
SriovNetworkNodeState 오브젝트
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodeState metadata: name: node-25 1 namespace: openshift-sriov-network-operator ownerReferences: - apiVersion: sriovnetwork.openshift.io/v1 blockOwnerDeletion: true controller: true kind: SriovNetworkNodePolicy name: default spec: dpConfigVersion: "39824" status: interfaces: 2 - deviceID: "1017" driver: mlx5_core mtu: 1500 name: ens785f0 pciAddress: "0000:18:00.0" totalvfs: 8 vendor: 15b3 - deviceID: "1017" driver: mlx5_core mtu: 1500 name: ens785f1 pciAddress: "0000:18:00.1" totalvfs: 8 vendor: 15b3 - deviceID: 158b driver: i40e mtu: 1500 name: ens817f0 pciAddress: 0000:81:00.0 totalvfs: 64 vendor: "8086" - deviceID: 158b driver: i40e mtu: 1500 name: ens817f1 pciAddress: 0000:81:00.1 totalvfs: 64 vendor: "8086" - deviceID: 158b driver: i40e mtu: 1500 name: ens803f0 pciAddress: 0000:86:00.0 totalvfs: 64 vendor: "8086" syncStatus: Succeeded
7.17.4.3. SR-IOV 네트워크 장치 구성
SR-IOV Network Operator는 SriovNetworkNodePolicy.sriovnetwork.openshift.io
CustomResourceDefinition을 OpenShift Container Platform에 추가합니다. SriovNetworkNodePolicy CR(사용자 정의 리소스)을 만들어 SR-IOV 네트워크 장치를 구성할 수 있습니다.
SriovNetworkNodePolicy
오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다.
구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - SR-IOV Network Operator가 설치되어 있습니다.
- 비운 노드에서 제거된 워크로드를 처리하기 위해 클러스터에 사용 가능한 노드가 충분합니다.
- SR-IOV 네트워크 장치 구성에 대한 컨트롤 플레인 노드를 선택하지 않았습니다.
절차
-
SriovNetworkNodePolicy
오브젝트를 생성한 후 YAML을<name>-sriov-node-network.yaml
파일에 저장합니다.<name>
을 이 구성의 이름으로 바꿉니다.
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: <name> 1 namespace: openshift-sriov-network-operator 2 spec: resourceName: <sriov_resource_name> 3 nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true" 4 priority: <priority> 5 mtu: <mtu> 6 numVfs: <num> 7 nicSelector: 8 vendor: "<vendor_code>" 9 deviceID: "<device_id>" 10 pfNames: ["<pf_name>", ...] 11 rootDevices: ["<pci_bus_id>", "..."] 12 deviceType: vfio-pci 13 isRdma: false 14
- 1
- CR 오브젝트의 이름을 지정합니다.
- 2
- SR-IOV Operator가 설치된 네임스페이스를 지정합니다.
- 3
- SR-IOV 장치 플러그인의 리소스 이름을 지정합니다. 리소스 이름에 대해 여러
SriovNetworkNodePolicy
오브젝트를 생성할 수 있습니다. - 4
- 구성할 노드를 선택하려면 노드 선택기를 지정합니다. 선택한 노드의 SR-IOV 네트워크 장치만 구성됩니다. SR-IOV CNI(Container Network Interface) 플러그인 및 장치 플러그인은 선택된 노드에만 배치됩니다.
- 5
- 선택 사항:
0
에서99
사이의 정수 값을 지정합니다. 숫자가 작을수록 우선 순위가 높아지므로 우선 순위10
은 우선 순위99
보다 높습니다. 기본값은99
입니다. - 6
- 선택 사항: 가상 기능의 최대 전송 단위(MTU) 값을 지정합니다. 최대 MTU 값은 NIC 모델마다 다를 수 있습니다.
- 7
- SR-IOV 물리적 네트워크 장치에 생성할 가상 기능(VF) 수를 지정합니다. Intel NIC(Network Interface Controller)의 경우 VF 수는 장치에서 지원하는 총 VF보다 클 수 없습니다. Mellanox NIC의 경우 VF 수는
128
보다 클 수 없습니다. - 8
nicSelector
매핑은 Operator가 구성할 이더넷 장치를 선택합니다. 모든 매개변수에 값을 지정할 필요는 없습니다. 의도하지 않게 이더넷 장치를 선택할 가능성을 최소화하기 위해 이더넷 어댑터를 충분히 정밀하게 식별하는 것이 좋습니다.rootDevices
를 지정하면vendor
,deviceID
또는pfNames
의 값도 지정해야 합니다.pfNames
와rootDevices
를 동시에 지정하는 경우 동일한 장치를 가리키는지 확인하십시오.- 9
- 선택 사항: SR-IOV 네트워크 장치의 공급업체 16진수 코드를 지정합니다. 허용되는 유일한 값은
8086
또는15b3
입니다. - 10
- 선택 사항: SR-IOV 네트워크 장치의 장치 16진수 코드를 지정합니다. 허용되는 값은
158b
,1015
,1017
입니다. - 11
- 선택 사항: 이 매개 변수는 이더넷 장치에 대해 하나 이상의 물리적 기능(PF) 이름으로 이루어진 배열을 허용합니다.
- 12
- 이 매개변수는 이더넷 장치의 물리적 기능을 위해 하나 이상의 PCI 버스 주소 배열을 허용합니다. 다음 형식으로 주소를 입력합니다.
0000:02:00.1
. - 13
vfio-pci
드라이버 유형은 OpenShift Virtualization의 가상 기능에 필요합니다.- 14
- 선택 사항: RDMA(원격 직접 메모리 액세스) 모드를 활성화할지 여부를 지정합니다. Mellanox 카드의 경우
isRdma
를false
로 설정합니다. 기본값은false
입니다.참고isRDMA
플래그가true
로 설정된 경우 RDMA 가능 VF를 일반 네트워크 장치로 계속 사용할 수 있습니다. 어느 모드에서나 장치를 사용할 수 있습니다.-
선택 사항:
SriovNetworkNodePolicy.Spec.NodeSelector
로 SR-IOV 가능 클러스터 노드에 레이블을 지정하지 않은 경우 레이블을 지정합니다. 노드 레이블링에 대한 자세한 내용은 "노드에서 라벨을 업데이트하는 방법"을 참조하십시오.
-
선택 사항:
SriovNetworkNodePolicy
오브젝트를 생성합니다.$ oc create -f <name>-sriov-node-network.yaml
<name>
은 이 구성의 이름을 지정합니다.구성 업데이트를 적용하면
sriov-network-operator
네임스페이스의 모든 Pod가Running
상태로 전환됩니다.SR-IOV 네트워크 장치가 구성되어 있는지 확인하려면 다음 명령을 입력합니다.
<node_name>
을 방금 구성한 SR-IOV 네트워크 장치가 있는 노드 이름으로 바꿉니다.$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'
7.17.4.4. 다음 단계
7.17.5. SR-IOV 네트워크 정의
가상 머신의 SR-IOV(Single Root I/O Virtualization) 장치에 대한 네트워크 연결을 생성할 수 있습니다.
네트워크를 정의한 후에는 가상 머신을 SR-IOV 네트워크에 연결할 수 있습니다.
7.17.5.1. 사전 요구 사항
- 가상 머신의 SR-IOV 장치가 구성되어 있어야 합니다.
7.17.5.2. SR-IOV 추가 네트워크 구성
SriovNetwork
오브젝트를 생성하여 SR-IOV 하드웨어를 사용하는 추가 네트워크를 구성할 수 있습니다. SriovNetwork
오브젝트를 생성하면 SR-IOV Operator에서 NetworkAttachmentDefinition
오브젝트를 자동으로 생성합니다.
그러면 사용자가 가상 머신 구성에서 네트워크를 지정하여 가상 머신을 SR-IOV 네트워크에 연결할 수 있습니다.
SriovNetwork
오브젝트가 SriovNetwork
상태의 Pod 또는 가상 머신에 연결된 경우 수정하거나 삭제하지 마십시오.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
절차
-
다음
SriovNetwork
오브젝트를 생성한 후 YAML을<name>-sriov-network.yaml
파일에 저장합니다.<name>
을 이 추가 네트워크의 이름으로 변경합니다.
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: <name> 1 namespace: openshift-sriov-network-operator 2 spec: resourceName: <sriov_resource_name> 3 networkNamespace: <target_namespace> 4 vlan: <vlan> 5 spoofChk: "<spoof_check>" 6 linkState: <link_state> 7 maxTxRate: <max_tx_rate> 8 minTxRate: <min_rx_rate> 9 vlanQoS: <vlan_qos> 10 trust: "<trust_vf>" 11 capabilities: <capabilities> 12
- 1
<name>
을 오브젝트의 이름으로 바꿉니다. SR-IOV Network Operator는 동일한 이름으로NetworkAttachmentDefinition
오브젝트를 생성합니다.- 2
- SR-IOV Network Operator가 설치된 네임스페이스를 지정합니다.
- 3
<sriov_resource_name>
을 이 추가 네트워크에 대한 SR-IOV 하드웨어를 정의하는SriovNetworkNodePolicy
오브젝트의spec.resourceName
매개변수 값으로 바꿉니다.- 4
<target_namespace>
를 SriovNetwork의 대상 네임스페이스로 바꿉니다. 대상 네임스페이스의 pod 또는 가상 머신만 SriovNetwork에 연결할 수 있습니다.- 5
- 선택 사항:
<vlan>
을 추가 네트워크의 VLAN(Virtual LAN) ID로 바꿉니다. 정수 값은0
에서4095
사이여야 합니다. 기본값은0
입니다. - 6
- 선택 사항:
<spoof_check>
를 VF의 스푸핑 검사 모드로 바꿉니다. 허용되는 값은 문자열"on"
및"off"
입니다.중요SR-IOV Network Operator가 지정한 값을 따옴표로 묶거나 CR을 거부해야 합니다.
- 7
- 선택 사항:
<link_state>
를 VF(가상 기능)의 링크 상태로 바꿉니다. 허용되는 값은enable
,disable
및auto
입니다. - 8
- 선택 사항: VF의 경우
<max_tx_rate>
를 최대 전송 속도(Mbps)로 바꿉니다. - 9
- 선택 사항: VF의 경우
<min_tx_rate>
를 최소 전송 속도(Mbps)로 바꿉니다. 이 값은 항상 최대 전송 속도보다 작거나 같아야 합니다.참고인텔 NIC는
minTxRate
매개변수를 지원하지 않습니다. 자세한 내용은 BZ#1772847에서 참조하십시오. - 10
- 선택 사항:
<vlan_qos>
를 VF의 IEEE 802.1p 우선 순위 수준으로 바꿉니다. 기본값은0
입니다. - 11
- 선택 사항:
<trust_vf>
를 VF의 신뢰 모드로 바꿉니다. 허용되는 값은 문자열"on"
및"off"
입니다.중요SR-IOV Network Operator가 지정한 값을 따옴표로 묶거나 CR을 거부해야 합니다.
- 12
- 선택 사항:
<capabilities>
를 이 네트워크에 구성할 수 있는 기능으로 바꿉니다.
오브젝트를 생성하려면 다음 명령을 입력합니다.
<name>
을 이 추가 네트워크의 이름으로 변경합니다.$ oc create -f <name>-sriov-network.yaml
선택 사항: 이전 단계에서 생성한
SriovNetwork
오브젝트와 연결된NetworkAttachmentDefinition
오브젝트가 존재하는지 확인하려면 다음 명령을 입력합니다.<namespace>
를SriovNetwork
오브젝트에 지정한 네임스페이스로 바꿉니다.$ oc get net-attach-def -n <namespace>
7.17.5.3. 다음 단계
7.17.6. SR-IOV 네트워크에 가상 머신 연결
가상 머신을 연결하여 SR-IOV(Single Root I/O Virtualization) 네트워크를 보조 네트워크로 사용할 수 있습니다.
7.17.6.1. 사전 요구 사항
- 가상 머신의 SR-IOV 장치가 구성되어 있어야 합니다.
- SR-IOV 네트워크가 정의되어 있어야 합니다.
7.17.6.2. SR-IOV 네트워크에 가상 머신 연결
가상 머신 구성에 네트워크 세부 정보를 포함하여 가상 머신을 SR-IOV 네트워크에 연결할 수 있습니다.
절차
가상 머신 구성의
spec.domain.devices.interfaces
및spec.networks
에 SR-IOV 네트워크 세부 정보를 포함합니다.kind: VirtualMachine ... spec: domain: devices: interfaces: - name: <default> 1 masquerade: {} 2 - name: <nic1> 3 sriov: {} networks: - name: <default> 4 pod: {} - name: <nic1> 5 multus: networkName: <sriov-network> 6 ...
가상 머신 구성을 적용합니다.
$ oc apply -f <vm-sriov.yaml> 1
- 1
- 가상 머신 YAML 파일의 이름입니다.
7.17.7. 가상 머신에서 NIC의 IP 주소 보기
웹 콘솔 또는 oc
클라이언트를 사용하여 NIC(네트워크 인터페이스 컨트롤러)의 IP 주소를 볼 수 있습니다. QEMU 게스트 에이전트는 가상 머신의 보조 네트워크에 대한 추가 정보를 표시합니다.
7.17.7.1. CLI에서 가상 머신 인터페이스의 IP 주소 보기
네트워크 인터페이스 구성은 oc describe vmi <vmi_name>
명령에 포함되어 있습니다.
가상 머신에서 ip addr
을 실행하거나 oc get vmi <vmi_name> -o yaml
을 실행하여 IP 주소 정보를 볼 수도 있습니다.
절차
oc describe
명령을 사용하여 가상 머신 인터페이스 구성을 표시합니다.$ oc describe vmi <vmi_name>
출력 예
... Interfaces: Interface Name: eth0 Ip Address: 10.244.0.37/24 Ip Addresses: 10.244.0.37/24 fe80::858:aff:fef4:25/64 Mac: 0a:58:0a:f4:00:25 Name: default Interface Name: v2 Ip Address: 1.1.1.7/24 Ip Addresses: 1.1.1.7/24 fe80::f4d9:70ff:fe13:9089/64 Mac: f6:d9:70:13:90:89 Interface Name: v1 Ip Address: 1.1.1.1/24 Ip Addresses: 1.1.1.1/24 1.1.1.2/24 1.1.1.4/24 2001:de7:0:f101::1/64 2001:db8:0:f101::1/64 fe80::1420:84ff:fe10:17aa/64 Mac: 16:20:84:10:17:aa
7.17.7.2. 웹 콘솔에서 가상 머신 인터페이스의 IP 주소 보기
가상 머신의 가상 머신 개요 화면에 IP 정보를 표시합니다.
절차
- OpenShift Virtualization 콘솔의 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 가상 머신 이름을 선택하여 가상 머신 개요 화면을 엽니다.
연결된 각 NIC에 대한 정보는 IP 주소 아래에 표시됩니다.
7.17.8. 가상 머신의 MAC 주소 풀 사용
KubeMacPool 구성 요소는 지정된 네임스페이스의 가상 머신 NIC에 대한 MAC 주소 풀 서비스를 제공합니다. 해당 네임스페이스에 KubeMacPool 라벨을 적용하여 네임스페이스에서 MAC 주소 풀을 활성화합니다.
7.17.8.1. About KubeMacPool
네임스페이스의 KubeMacPool 구성 요소를 활성화하면 MAC 주소 풀의 MAC 주소가 해당 네임스페이스의 가상 머신 NIC에 할당됩니다. 이렇게 하면 다른 가상 머신의 MAC 주소와 충돌하지 않는 고유한 MAC 주소가 NIC에 할당됩니다.
해당 가상 머신에서 생성된 가상 머신 인스턴스에서는 재부팅 시 할당되는 MAC 주소가 유지됩니다.
KubeMacPool은 가상 머신과 독립적으로 생성된 가상 머신 인스턴스는 처리하지 않습니다.
KubeMacPool은 기본적으로 비활성화되어 있습니다. 네임스페이스에 KubeMacPool 라벨을 적용하여 네임스페이스의 MAC 주소 풀을 활성화합니다.
7.17.8.2. CLI에서 네임스페이스의 MAC 주소 풀 활성화
mutatevirtualmachines.kubemacpool.io=allocate
라벨을 네임스페이스에 적용하여 네임스페이스에서 가상 머신의 MAC 주소 풀을 활성화합니다.
절차
네임스페이스에 KubeMacPool 라벨을 추가합니다. 다음 예제에서는
<namespace1>
및<namespace2>
네임스페이스에 KubeMacPool 라벨을 추가합니다.$ oc label namespace <namespace1> <namespace2> mutatevirtualmachines.kubemacpool.io=allocate
7.17.8.3. CLI에서 네임스페이스의 MAC 주소 풀 비활성화
mutatevirtualmachines.kubemacpool.io
라벨을 제거하여 네임스페이스에 있는 가상 머신의 MAC 주소 풀을 비활성화합니다.
절차
네임스페이스에서 KubeMacPool 라벨을 제거합니다. 다음 예제에서는
<namespace1>
및<namespace2>
네임스페이스에서 KubeMacPool 라벨을 제거합니다.$ oc label namespace <namespace1> <namespace2> mutatevirtualmachines.kubemacpool.io-
7.18. 가상 머신 디스크
7.18.1. 스토리지 기능
다음 표를 사용하여 OpenShift Virtualization의 로컬 및 공유 영구 스토리지에 대한 기능 가용성을 확인합니다.
7.18.1.1. OpenShift Virtualization 스토리지 기능 매트릭스
가상 머신 실시간 마이그레이션 | 호스트 지원 가상 머신 디스크 복제 | 스토리지 지원 가상 머신 디스크 복제 | 가상 머신 스냅샷 | |
---|---|---|---|---|
OpenShift Container Storage: rbd 블록 모드 볼륨 | 있음 | 있음 | 있음 | 있음 |
OpenShift Virtualization hostpath 프로비전 프로그램 | 아니요 | 있음 | 아니요 | 아니요 |
기타 다중 노드 쓰기 가능 스토리지 | 예 [1] | 있음 | 예 [2] | 예 [2] |
기타 단일 노드 쓰기 가능 스토리지 | 아니요 | 있음 | 예 [2] | 예 [2] |
- PVC에서 ReadWriteMany 액세스 모드를 요청해야 합니다.
- 스토리지 공급자는 Kubernetes 및 CSI Snapshot API를 모두 지원해야 합니다.
다음을 사용하는 가상 머신은 실시간 마이그레이션할 수 없습니다.
- RWO(ReadWriteOnce) 액세스 모드를 사용하는 스토리지 클래스
- SR-IOV 및 GPU와 같은 패스스루(Passthrough)
이러한 가상 머신의 경우 evictionStrategy
필드를 LiveMigrate
로 설정하지 않도록 합니다.
7.18.2. 가상 머신 로컬 스토리지 구성
hostpath 프로비전 프로그램 기능을 사용하여 가상 머신의 로컬 스토리지를 구성할 수 있습니다.
7.18.2.1. hostpath 프로비전 프로그램 정보
hostpath 프로비전 프로그램은 OpenShift Virtualization용으로 설계된 로컬 스토리지 프로비전 프로그램입니다. 가상 머신의 로컬 스토리지를 구성하려면 먼저 hostpath 프로비전 프로그램을 활성화해야 합니다.
OpenShift Virtualization Operator를 설치하면 hostpath provisioner Operator가 자동으로 설치됩니다. 사용하려면 다음을 수행해야 합니다.
SELinux를 구성합니다.
-
RHCOS(Red Hat Enterprise Linux CoreOS) 8 작업자를 사용하는 경우 각 노드에서
MachineConfig
오브젝트를 생성해야 합니다. -
또는 SELinux 라벨
container_file_t
를 각 노드의 PV(영구 볼륨) 백업 디렉터리에 적용합니다.
-
RHCOS(Red Hat Enterprise Linux CoreOS) 8 작업자를 사용하는 경우 각 노드에서
-
HostPathProvisioner
사용자 정의 리소스를 만듭니다. -
hostpath 프로비전 프로그램에 대한
StorageClass
오브젝트를 만듭니다.
hostpath provisioner Operator는 사용자 정의 리소스를 생성할 때 각 노드에 프로비전 프로그램을 DaemonSet로 배포합니다. 사용자 정의 리소스 파일에서 hostpath 프로비전 프로그램에서 생성하는 영구 볼륨의 백업 디렉터리를 지정합니다.
7.18.2.2. RHCOS(Red Hat Enterprise Linux CoreOS) 8에서 hostpath 프로비전 프로그램에 대한 SELinux 구성
HostPathProvisioner
사용자 정의 리소스를 만들기 전에 SELinux를 구성해야 합니다. RHCOS(Red Hat Enterprise Linux CoreOS) 8 작업자에서 SELinux를 구성하려면 각 노드에 MachineConfig
오브젝트를 생성해야 합니다.
사전 요구 사항
각 노드에 hostpath 프로비전 프로그램에서 생성하는 PV(영구 볼륨)에 대한 백업 디렉터리를 생성합니다.
중요RHCOS에서
/
파티션을 읽기 전용이므로 백업 디렉터리는 파일 시스템의 루트 디렉터리에 있으면 안 됩니다. 예를 들어/var/<directory_name>은 사용할 수 있지만
은 사용할 수 없습니다./<
directory_name>
절차
MachineConfig
파일을 생성합니다. 예를 들면 다음과 같습니다.$ touch machineconfig.yaml
hostpath 프로비전 프로그램으로 PV를 생성할 디렉터리를 포함하도록 파일을 편집합니다. 예를 들면 다음과 같습니다.
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: 50-set-selinux-for-hostpath-provisioner labels: machineconfiguration.openshift.io/role: worker spec: config: ignition: version: 3.1.0 systemd: units: - contents: | [Unit] Description=Set SELinux chcon for hostpath provisioner Before=kubelet.service [Service] ExecStart=/usr/bin/chcon -Rt container_file_t <backing_directory_path> 1 [Install] WantedBy=multi-user.target enabled: true name: hostpath-provisioner.service
- 1
- 프로비전 프로그램으로 PV를 생성할 백업 디렉터리를 지정합니다. 이 디렉토리는 파일 시스템의 루트 디렉토리(
/
)에 있으면 안 됩니다.
MachineConfig
오브젝트를 생성합니다.$ oc create -f machineconfig.yaml -n <namespace>
7.18.2.3. hostpath 프로비전 프로그램을 사용하여 로컬 스토리지 활성화
hostpath 프로비전 프로그램을 배포하고 가상 머신에서 로컬 스토리지를 사용하도록 설정하려면 먼저 HostPathProvisioner
사용자 정의 리소스를 만들어야 합니다.
사전 요구 사항
각 노드에 hostpath 프로비전 프로그램에서 생성하는 PV(영구 볼륨)에 대한 백업 디렉터리를 생성합니다.
중요/
파티션은 RHCOS(Red Hat Enterprise Linux CoreOS)에서 읽기 전용이므로 백업 디렉터리는 파일 시스템의 루트 디렉터리에 있지 않아야 합니다. 예를 들어/var/<directory_name>은 사용할 수 있지만
은 사용할 수 없습니다./<
directory_name>SELinux 컨텍스트
container_file_t
를 각 노드의 PV 백업 디렉터리에 적용합니다. 예를 들면 다음과 같습니다.$ sudo chcon -t container_file_t -R <backing_directory_path>
참고RHCOS(Red Hat Enterprise Linux CoreOS) 8 작업자를 사용하는 경우
MachineConfig
매니페스트를 사용하여 SELinux를 구성해야 합니다.
절차
HostPathProvisioner
사용자 정의 리소스 파일을 만듭니다. 예를 들면 다음과 같습니다.$ touch hostpathprovisioner_cr.yaml
spec.pathConfig.path
값이 hostpath 프로비전 프로그램으로 PV를 생성할 디렉터리가 되도록 파일을 편집합니다. 예를 들면 다음과 같습니다.apiVersion: hostpathprovisioner.kubevirt.io/v1beta1 kind: HostPathProvisioner metadata: name: hostpath-provisioner spec: imagePullPolicy: IfNotPresent pathConfig: path: "<backing_directory_path>" 1 useNamingPrefix: false 2
참고백업 디렉터리를 만들지 않은 경우 프로비전 프로그램에서 백업 디렉터리를 만들려고 합니다.
container_file_t
SELinux 컨텍스트를 적용하지 않은 경우Permission denied
오류가 발생할 수 있습니다.openshift-cnv
네임스페이스에 사용자 정의 리소스를 만듭니다.$ oc create -f hostpathprovisioner_cr.yaml -n openshift-cnv
7.18.2.4. 스토리지 클래스 생성
스토리지 클래스를 생성할 때 해당 스토리지 클래스에 속하는 PV(영구 볼륨)의 동적 프로비저닝에 영향을 주는 매개변수를 설정합니다. StorageClass
오브젝트를 생성한 후에는 이 오브젝트의 매개변수를 업데이트할 수 없습니다.
OpenShift Container Platform Container Storage와 함께 OpenShift Virtualization을 사용하는 경우 가상 머신 디스크를 생성할 때 RBD 블록 모드 PVC(영구 볼륨 클레임)를 지정합니다. 가상 시스템 디스크를 사용하면 RBD 블록 모드 볼륨이 더 효율적이며 Ceph FS 또는 RBD 파일 시스템 모드 PVC보다 더 나은 성능을 제공합니다.
RBD 블록 모드 PVC를 지정하려면 'ocs-storagecluster-ceph-rbd' 스토리지 클래스와 VolumeMode를 사용합니다. block
.
절차
스토리지 클래스를 정의하는 YAML 파일을 만듭니다. 예를 들면 다음과 같습니다.
$ touch storageclass.yaml
파일을 편집합니다. 예를 들면 다음과 같습니다.
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: hostpath-provisioner 1 provisioner: kubevirt.io/hostpath-provisioner reclaimPolicy: Delete 2 volumeBindingMode: WaitForFirstConsumer 3
- 1
- 필요한 경우 이 값을 변경하여 스토리지 클래스의 이름을 변경할 수 있습니다.
- 2
reclaimPolicy
에 사용할 수 있는 값은Delete
및Retain
두 가지입니다. 값을 지정하지 않는 경우 스토리지 클래스는 기본값인Delete
로 설정됩니다.- 3
volumeBindingMode
값은 동적 프로비저닝 및 볼륨 바인딩이 발생하는 시기를 결정합니다. PVC(영구 볼륨 클레임)를 사용하는 Pod를 생성한 후 PV의 바인딩 및 프로비저닝을 수행하려면WaitForFirstConsumer
를 지정합니다. 이렇게 하면 PV에서 Pod의 스케줄링 요구 사항을 충족할 수 있습니다.
참고가상 머신은 로컬 PV를 기반으로 하는 데이터 볼륨을 사용합니다. 로컬 PV는 특정 노드에 바인딩됩니다. 디스크 이미지는 가상 머신에서 사용할 수 있는 반면 가상 머신은 이전에 로컬 스토리지 PV가 고정된 노드에 예약할 수 없습니다.
이 문제를 해결하려면 Kubernetes Pod 스케줄러를 사용하여 올바른 노드의 PV에 PVC를 바인딩합니다.
volumeBindingMode
가WaitForFirstConsumer
로 설정된StorageClass
를 사용하면 PVC를 사용하여Pod
가 생성될 때까지 PV의 바인딩 및 프로비저닝이 지연됩니다.StorageClass
오브젝트를 만듭니다.$ oc create -f storageclass.yaml
추가 리소스
7.18.3. 컴퓨팅 리소스 할당량이 있는 네임스페이스를 사용하도록 CDI 구성
CDI(Containerized Data Importer)를 사용하면 CPU 및 메모리 리소스가 제한된 네임스페이스로 가상 머신 디스크를 가져오고, 업로드하고, 복제할 수 있습니다.
7.18.3.1. 네임스페이스의 CPU 및 메모리 할당량 정보
ResourceQuota
오브젝트로 정의하는 리소스 할당량은 네임스페이스에 제한을 적용하여 해당 네임스페이스 내의 리소스에서 사용할 수 있는 총 컴퓨팅 리소스 양을 제한합니다.
CDIConfig
오브젝트는 CDI(Containerized Data Importer)에 대한 사용자 구성을 정의합니다. CDIConfig
오브젝트의 CPU 및 메모리 요청 및 한계 값은 기본값인 0으로 설정되어 있습니다. 이렇게 하면 컴퓨팅 리소스 요구 사항 없이 CDI에서 생성한 Pod에 기본값을 제공하고 할당량을 통해 제한이 적용되는 네임스페이스에서 해당 Pod를 실행할 수 있습니다.
7.18.3.2. CPU 및 메모리 기본값을 덮어쓰도록 CDIConfig
오브젝트 편집
CDIConfig
오브젝트의 spec
특성을 편집하여 CPU와 메모리의 요청 및 한계에 대한 기본 설정을 해당 사용 사례에 맞게 수정합니다.
전제 조건
-
OpenShift CLI(
oc
)를 설치합니다.
프로세스
다음 명령을 실행하여
cdiconfig/config
를 편집합니다.$ oc edit cdiconfig/config
CDIConfig
오브젝트의spec: podResourceRequirements
특성을 편집하여 CPU와 메모리의 기본 요청 및 한계를 변경합니다.apiVersion: cdi.kubevirt.io/v1beta1 kind: CDIConfig metadata: labels: app: containerized-data-importer cdi.kubevirt.io: "" name: config spec: podResourceRequirements: limits: cpu: "4" memory: "1Gi" requests: cpu: "1" memory: "250Mi" ...
-
편집기를 저장하고 종료하여
CDIConfig
오브젝트를 업데이트합니다.
검증
다음 명령을 실행하여
CDIConfig
상태를 보고 변경 사항을 확인합니다.$ oc get cdiconfig config -o yaml
7.18.3.3. 추가 리소스
7.18.4. 웹 콘솔을 사용하여 로컬 디스크 이미지 업로드
웹 콘솔을 사용하여 로컬에 저장된 디스크 이미지 파일을 업로드할 수 있습니다.
7.18.4.1. 사전 요구 사항
- 가상 머신 이미지 파일이 IMG, ISO 또는 QCOW2 형식이어야 합니다.
- CDI 지원 작업 매트릭스에 따라 스크래치 공간이 필요한 경우, 이 작업을 완료하기 위해서는 먼저 스토리지 클래스를 정의하거나 CDI 스크래치 공간을 준비해야 합니다.
7.18.4.2. CDI 지원 작업 매트릭스
이 매트릭스에는 끝점에 대한 콘텐츠 유형에 따라 지원되는 CDI 작업과 이러한 작업 중 스크래치 공간이 필요한 작업이 표시되어 있습니다.
콘텐츠 유형 | HTTP | HTTPS | HTTP 기본 인증 | 레지스트리 | 업로드 |
---|---|---|---|---|---|
KubeVirt(QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt(RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ 지원되는 작업
□ 지원되지 않는 작업
* 스크래치 공간 필요
** 사용자 정의 인증 기관이 필요한 경우 스크래치 공간 필요
7.18.4.3. 웹 콘솔을 사용하여 이미지 파일 업로드
웹 콘솔을 사용하여 이미지 파일을 새 PVC(영구 볼륨 클레임)에 업로드합니다. 나중에 이 PVC를 사용하여 이미지를 새 가상 머신에 연결할 수 있습니다.
사전 요구 사항
다음 중 하나가 있어야 합니다.
- ISO 또는 IMG 형식의 원시 가상 머신 이미지 파일
- QCOW2 형식의 가상 머신 이미지 파일
최상의 결과를 얻으려면 업로드하기 전에 다음 지침에 따라 이미지 파일을 압축하십시오.
xz
또는gzip
을 사용하여 원시 이미지 파일을 압축합니다.참고압축된 원시 이미지 파일을 사용할 때 가장 효율적으로 업로드할 수 있습니다.
클라이언트에 권장되는 방법을 사용하여 QCOW2 이미지 파일을 압축합니다.
- Linux 클라이언트를 사용하는 경우 virt-sparsify 툴을 사용하여 QCOW2 파일을 스파스(sparsify) 형식으로 변환합니다.
-
Windows 클라이언트를 사용하는 경우
xz
또는gzip
을 사용하여 QCOW2 파일을 압축합니다.
절차
- 웹 콘솔의 사이드 메뉴에서 스토리지 → 영구 볼륨 클레임을 클릭합니다.
- 영구 볼륨 클레임 생성 드롭다운 목록을 클릭하여 확장합니다.
- 사용할 데이터 업로드 폼을 클릭하여 영구 볼륨 클레임에 데이터 업로드 페이지를 엽니다.
- 찾아보기를 클릭하여 파일 관리자를 열고 업로드할 이미지를 선택하거나, 파일을 여기로 드래그하거나 업로드할 항목 찾아보기 필드로 파일을 드래그합니다.
선택 사항: 이 이미지를 특정 운영 체제의 기본 이미지로 설정합니다.
- 이 데이터를 가상 머신 운영 체제에 연결 확인란을 선택합니다.
- 목록에서 운영 체제를 선택합니다.
- 영구 볼륨 클레임 이름 필드는 고유한 이름으로 자동으로 채워지며 편집할 수 없습니다. 필요한 경우 나중에 확인할 수 있도록 PVC에 지정된 이름을 기록해 두십시오.
- 스토리지 클래스 목록에서 스토리지 클래스를 선택합니다.
크기 필드에 PVC 크기 값을 입력합니다. 드롭다운 목록에서 해당 측정 단위를 선택합니다.
주의PVC 크기는 압축되지 않은 가상 디스크의 크기보다 커야 합니다.
- 선택한 스토리지 클래스와 일치하는 액세스 모드를 선택합니다.
- 업로드를 클릭합니다.
7.18.5. virtctl 툴을 사용하여 로컬 디스크 이미지 업로드
virtctl
명령줄 유틸리티를 사용하여 로컬에 저장된 디스크 이미지를 신규 또는 기존 데이터 볼륨에 업로드할 수 있습니다.
7.18.5.1. 사전 요구 사항
-
kubevirt-virtctl
패키지를 설치합니다. - CDI 지원 작업 매트릭스에 따라 스크래치 공간이 필요한 경우, 이 작업을 완료하기 위해서는 먼저 스토리지 클래스를 정의하거나 CDI 스크래치 공간을 준비해야 합니다.
7.18.5.2. 데이터 볼륨 정보
Dataolume
오브젝트는 CDI(Containerized Data Importer) 프로젝트에서 제공하는 사용자 정의 리소스입니다. 데이터 볼륨은 기본 PVC(영구 볼륨 클레임)와 관련된 가져오기, 복제, 업로드 작업을 오케스트레이션합니다. 데이터 볼륨은 OpenShift Virtualization과 통합되며 PVC가 준비되기 전에 가상 머신이 시작되지 않도록 합니다.
7.18.5.3. 업로드 데이터 볼륨 생성
로컬 디스크 이미지를 업로드하는 데 사용할 upload
데이터 소스가 있는 데이터 볼륨을 수동으로 생성할 수 있습니다.
절차
spec: source: upload{}
를 지정하는 데이터 볼륨 구성을 만듭니다.apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: <upload-datavolume> 1 spec: source: upload: {} pvc: accessModes: - ReadWriteOnce resources: requests: storage: <2Gi> 2
다음 명령을 실행하여 데이터 볼륨을 생성합니다.
$ oc create -f <upload-datavolume>.yaml
7.18.5.4. 데이터 볼륨에 로컬 디스크 이미지 업로드
virtctl
CLI 유틸리티를 사용하여 클라이언트 머신의 로컬 디스크 이미지를 클러스터의 DV(데이터 볼륨)에 업로드할 수 있습니다. 클러스터에 이미 존재하는 DV를 사용하거나 이 절차 중에 새 DV를 만들 수 있습니다.
로컬 디스크 이미지를 업로드한 후 가상 머신에 추가할 수 있습니다.
사전 요구 사항
다음 중 하나가 있어야 합니다.
- ISO 또는 IMG 형식의 원시 가상 머신 이미지 파일
- QCOW2 형식의 가상 머신 이미지 파일
최상의 결과를 얻으려면 업로드하기 전에 다음 지침에 따라 이미지 파일을 압축하십시오.
xz
또는gzip
을 사용하여 원시 이미지 파일을 압축합니다.참고압축된 원시 이미지 파일을 사용할 때 가장 효율적으로 업로드할 수 있습니다.
클라이언트에 권장되는 방법을 사용하여 QCOW2 이미지 파일을 압축합니다.
- Linux 클라이언트를 사용하는 경우 virt-sparsify 툴을 사용하여 QCOW2 파일을 스파스(sparsify) 형식으로 변환합니다.
-
Windows 클라이언트를 사용하는 경우
xz
또는gzip
을 사용하여 QCOW2 파일을 압축합니다.
-
kubevirt-virtctl
패키지가 클라이언트 머신에 설치되어 있어야 합니다. - 클라이언트 머신이 OpenShift Container Platform 라우터의 인증서를 신뢰하도록 구성되어 있어야 합니다.
절차
다음 항목을 확인합니다.
- 사용할 업로드 데이터 볼륨의 이름. 이 데이터 볼륨이 없으면 자동으로 생성됩니다.
- 업로드 절차 중 데이터 볼륨을 생성하려는 경우 데이터 볼륨의 크기. 크기는 디스크 이미지의 크기보다 크거나 같아야 합니다.
- 업로드하려는 가상 머신 디스크 이미지의 파일 위치.
virtctl image-upload
명령을 실행하여 디스크 이미지를 업로드합니다. 이전 단계에서 확인한 매개변수를 지정합니다. 예를 들면 다음과 같습니다.$ virtctl image-upload dv <datavolume_name> \ 1 --size=<datavolume_size> \ 2 --image-path=</path/to/image> \ 3
참고-
새 데이터 볼륨을 생성하지 않으려면
--size
매개변수를 생략하고--no-create
플래그를 포함합니다. - 디스크 이미지를 PVC에 업로드할 때 PVC 크기는 압축되지 않은 가상 디스크의 크기보다 커야 합니다.
-
HTTPS를 사용할 때 비보안 서버 연결을 허용하려면
--insecure
매개변수를 사용하십시오.--insecure
플래그를 사용하면 업로드 끝점의 신뢰성이 확인되지 않습니다.
-
새 데이터 볼륨을 생성하지 않으려면
선택사항입니다. 데이터 볼륨이 생성되었는지 확인하려면 다음 명령을 실행하여 모든 데이터 볼륨을 확인합니다.
$ oc get dvs
7.18.5.5. CDI 지원 작업 매트릭스
이 매트릭스에는 끝점에 대한 콘텐츠 유형에 따라 지원되는 CDI 작업과 이러한 작업 중 스크래치 공간이 필요한 작업이 표시되어 있습니다.
콘텐츠 유형 | HTTP | HTTPS | HTTP 기본 인증 | 레지스트리 | 업로드 |
---|---|---|---|---|---|
KubeVirt(QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt(RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ 지원되는 작업
□ 지원되지 않는 작업
* 스크래치 공간 필요
** 사용자 정의 인증 기관이 필요한 경우 스크래치 공간 필요
7.18.6. 블록 스토리지 데이터 볼륨에 로컬 디스크 이미지 업로드
virtctl
명령줄 유틸리티를 사용하여 로컬 디스크 이미지를 블록 데이터 볼륨에 업로드할 수 있습니다.
이 워크플로우에서는 영구 볼륨으로 사용할 로컬 블록 장치를 생성한 후 이 블록 볼륨을 upload
데이터 볼륨과 연결하고, virtctl
을 사용하여 로컬 디스크 이미지를 데이터 볼륨에 업로드합니다.
7.18.6.1. 사전 요구 사항
-
kubevirt-virtctl
패키지를 설치합니다. - CDI 지원 작업 매트릭스에 따라 스크래치 공간이 필요한 경우, 이 작업을 완료하기 위해서는 먼저 스토리지 클래스를 정의하거나 CDI 스크래치 공간을 준비해야 합니다.
7.18.6.2. 데이터 볼륨 정보
Dataolume
오브젝트는 CDI(Containerized Data Importer) 프로젝트에서 제공하는 사용자 정의 리소스입니다. 데이터 볼륨은 기본 PVC(영구 볼륨 클레임)와 관련된 가져오기, 복제, 업로드 작업을 오케스트레이션합니다. 데이터 볼륨은 OpenShift Virtualization과 통합되며 PVC가 준비되기 전에 가상 머신이 시작되지 않도록 합니다.
7.18.6.3. 블록 영구 볼륨 정보
PV(블록 영구 볼륨)는 원시 블록 장치에서 지원하는 PV입니다. 이러한 볼륨은 파일 시스템이 없으며 오버헤드를 줄여 가상 머신의 성능을 향상시킬 수 있습니다.
원시 블록 볼륨은 volumeMode를 지정하여 프로비저닝됩니다. PV 및 PVC(영구 볼륨 클레임) 사양에서 block
7.18.6.4. 로컬 블록 영구 볼륨 생성
파일을 채우고 루프 장치로 마운트하여 노드에 로컬 블록 PV(영구 볼륨)를 생성합니다. 그런 다음 PV 매니페스트에서 이 루프 장치를 Block
볼륨으로 참조하고 가상 머신 이미지의 블록 장치로 사용할 수 있습니다.
절차
-
로컬 PV를 생성할 노드에
root
로 로그인합니다. 이 절차에서는 예제로node01
을 사용합니다. 블록 장치로 사용할 수 있도록 파일을 생성하고 null 문자로 채웁니다. 다음 예제에서는 크기가 2Gb(20X100Mb 블록)인 파일
loop10
을 생성합니다.$ dd if=/dev/zero of=<loop10> bs=100M count=20
loop10
파일을 루프 장치로 마운트합니다.$ losetup </dev/loop10>d3 <loop10> 1 2
마운트된 루프 장치를 참조하는
PersistentVolume
매니페스트를 생성합니다.kind: PersistentVolume apiVersion: v1 metadata: name: <local-block-pv10> annotations: spec: local: path: </dev/loop10> 1 capacity: storage: <2Gi> volumeMode: Block 2 storageClassName: local 3 accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Delete nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - <node01> 4
블록 PV를 생성합니다.
# oc create -f <local-block-pv10.yaml>1
- 1
- 이전 단계에서 생성한 영구 볼륨의 파일 이름입니다.
7.18.6.5. 업로드 데이터 볼륨 생성
로컬 디스크 이미지를 업로드하는 데 사용할 upload
데이터 소스가 있는 데이터 볼륨을 수동으로 생성할 수 있습니다.
절차
spec: source: upload{}
를 지정하는 데이터 볼륨 구성을 만듭니다.apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: <upload-datavolume> 1 spec: source: upload: {} pvc: accessModes: - ReadWriteOnce resources: requests: storage: <2Gi> 2
다음 명령을 실행하여 데이터 볼륨을 생성합니다.
$ oc create -f <upload-datavolume>.yaml
7.18.6.6. 데이터 볼륨에 로컬 디스크 이미지 업로드
virtctl
CLI 유틸리티를 사용하여 클라이언트 머신의 로컬 디스크 이미지를 클러스터의 DV(데이터 볼륨)에 업로드할 수 있습니다. 클러스터에 이미 존재하는 DV를 사용하거나 이 절차 중에 새 DV를 만들 수 있습니다.
로컬 디스크 이미지를 업로드한 후 가상 머신에 추가할 수 있습니다.
사전 요구 사항
다음 중 하나가 있어야 합니다.
- ISO 또는 IMG 형식의 원시 가상 머신 이미지 파일
- QCOW2 형식의 가상 머신 이미지 파일
최상의 결과를 얻으려면 업로드하기 전에 다음 지침에 따라 이미지 파일을 압축하십시오.
xz
또는gzip
을 사용하여 원시 이미지 파일을 압축합니다.참고압축된 원시 이미지 파일을 사용할 때 가장 효율적으로 업로드할 수 있습니다.
클라이언트에 권장되는 방법을 사용하여 QCOW2 이미지 파일을 압축합니다.
- Linux 클라이언트를 사용하는 경우 virt-sparsify 툴을 사용하여 QCOW2 파일을 스파스(sparsify) 형식으로 변환합니다.
-
Windows 클라이언트를 사용하는 경우
xz
또는gzip
을 사용하여 QCOW2 파일을 압축합니다.
-
kubevirt-virtctl
패키지가 클라이언트 머신에 설치되어 있어야 합니다. - 클라이언트 머신이 OpenShift Container Platform 라우터의 인증서를 신뢰하도록 구성되어 있어야 합니다.
절차
다음 항목을 확인합니다.
- 사용할 업로드 데이터 볼륨의 이름. 이 데이터 볼륨이 없으면 자동으로 생성됩니다.
- 업로드 절차 중 데이터 볼륨을 생성하려는 경우 데이터 볼륨의 크기. 크기는 디스크 이미지의 크기보다 크거나 같아야 합니다.
- 업로드하려는 가상 머신 디스크 이미지의 파일 위치.
virtctl image-upload
명령을 실행하여 디스크 이미지를 업로드합니다. 이전 단계에서 확인한 매개변수를 지정합니다. 예를 들면 다음과 같습니다.$ virtctl image-upload dv <datavolume_name> \ 1 --size=<datavolume_size> \ 2 --image-path=</path/to/image> \ 3
참고-
새 데이터 볼륨을 생성하지 않으려면
--size
매개변수를 생략하고--no-create
플래그를 포함합니다. - 디스크 이미지를 PVC에 업로드할 때 PVC 크기는 압축되지 않은 가상 디스크의 크기보다 커야 합니다.
-
HTTPS를 사용할 때 비보안 서버 연결을 허용하려면
--insecure
매개변수를 사용하십시오.--insecure
플래그를 사용하면 업로드 끝점의 신뢰성이 확인되지 않습니다.
-
새 데이터 볼륨을 생성하지 않으려면
선택사항입니다. 데이터 볼륨이 생성되었는지 확인하려면 다음 명령을 실행하여 모든 데이터 볼륨을 확인합니다.
$ oc get dvs
7.18.6.7. CDI 지원 작업 매트릭스
이 매트릭스에는 끝점에 대한 콘텐츠 유형에 따라 지원되는 CDI 작업과 이러한 작업 중 스크래치 공간이 필요한 작업이 표시되어 있습니다.
콘텐츠 유형 | HTTP | HTTPS | HTTP 기본 인증 | 레지스트리 | 업로드 |
---|---|---|---|---|---|
KubeVirt(QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt(RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ 지원되는 작업
□ 지원되지 않는 작업
* 스크래치 공간 필요
** 사용자 정의 인증 기관이 필요한 경우 스크래치 공간 필요
7.18.7. 오프라인 가상 머신 스냅샷 관리
전원이 꺼진(오프라인 상태의) VM에 대해 VM(가상 머신) 스냅샷을 생성, 복원, 삭제할 수 있습니다. OpenShift Virtualization은 다음에서 오프라인 VM 스냅샷을 지원합니다.
- Red Hat OpenShift 컨테이너 스토리지
- Kubernetes Volume Snapshot API를 지원하는 CSI(Container Storage Interface) 드라이버가 있는 기타 스토리지 공급자
7.18.7.1. 가상 머신 스냅샷 정보
스냅샷은 특정 시점의 VM(가상 머신) 상태 및 데이터를 나타냅니다. 스냅샷을 사용하면 백업 및 재해 복구를 위해 기존 VM을 (스냅샷에 표시된) 이전 상태로 복원하거나 이전 개발 버전으로 신속하게 롤백할 수 있습니다.
오프라인 VM 스냅샷은 전원이 꺼진(중지됨 상태) VM에서 생성됩니다. 스냅샷에는 VM에 연결된 각 CSI(Container Storage Interface) 볼륨 복사본과 VM 사양 및 메타데이터 복사본이 저장됩니다. 스냅샷을 생성한 후에는 변경할 수 없습니다.
클러스터 관리자와 애플리케이션 개발자는 오프라인 VM 스냅샷 기능을 사용하여 다음을 수행할 수 있습니다.
- 새 프로젝트 생성
- 특정 VM에 연결된 모든 스냅샷 나열
- 스냅샷에서 VM 복원
- 기존 VM 스냅샷 삭제
7.18.7.1.1. 가상 머신 스냅샷 컨트롤러 및 CRD(사용자 정의 리소스 정의)
스냅샷 관리를 위해 VM 스냅샷 기능에 다음과 같이 CRD로 정의되는 새 API 오브젝트 세 가지가 도입되었습니다.
-
VirtualMachineSnapshot
: 스냅샷 생성에 대한 사용자 요청을 나타냅니다. 여기에는 VM의 현재 상태 정보가 포함됩니다. -
VirtualMachineSnapshotContent
: 클러스터에서 프로비저닝된 리소스(스냅샷)를 나타냅니다. VM 스냅샷 컨트롤러에서 생성하며 VM을 복원하는 데 필요한 모든 리소스에 대한 참조를 포함합니다. -
VirtualMachineRestore
: 스냅샷에서 VM을 복원하라는 사용자 요청을 나타냅니다.
VM 스냅샷 컨트롤러는 VirtualMachineSnapshot
오브젝트와 이 오브젝트에 대해 생성된 VirtualMachineSnapshotContent
오브젝트를 일대일 매핑으로 바인딩합니다.
7.18.7.2. CLI에서 오프라인 가상 머신 스냅샷 생성
VirtualMachineSnapshot
오브젝트를 생성하여 오프라인 VM에 대한 VM(가상 머신) 스냅샷을 생성할 수 있습니다.
사전 요구 사항
- PVC(영구 볼륨 클레임)이 CSI(Container Storage Interface) 볼륨 스냅샷을 지원하는 스토리지 클래스에 있는지 확인합니다.
-
OpenShift CLI(
oc
)를 설치합니다. - 스냅샷을 생성할 VM의 전원을 끕니다.
프로세스
YAML 파일을 생성하여 새
VirtualMachineSnapshot
의 이름과 소스 VM의 이름을 지정하는VirtualMachineSnapshot
오브젝트를 정의합니다.예를 들면 다음과 같습니다.
apiVersion: snapshot.kubevirt.io/v1alpha1 kind: VirtualMachineSnapshot metadata: name: my-vmsnapshot 1 spec: source: apiGroup: kubevirt.io kind: VirtualMachine name: my-vm 2
VirtualMachineSnapshot
리소스를 생성합니다. 스냅샷 컨트롤러에서VirtualMachineSnapshotContent
오브젝트를 생성하여VirtualMachineSnapshot
에 바인딩하고VirtualMachineSnapshot
오브젝트의status
및readyToUse
필드를 업데이트합니다.$ oc create -f <my-vmsnapshot>.yaml
검증
VirtualMachineSnapshot
오브젝트가 생성되고VirtualMachineSnapshotContent
에 바인딩되었는지 확인합니다.readyToUse
플래그를true
로 설정해야 합니다.$ oc describe vmsnapshot <my-vmsnapshot>
출력 예
apiVersion: snapshot.kubevirt.io/v1alpha1 kind: VirtualMachineSnapshot metadata: creationTimestamp: "2020-09-30T14:41:51Z" finalizers: - snapshot.kubevirt.io/vmsnapshot-protection generation: 5 name: mysnap namespace: default resourceVersion: "3897" selfLink: /apis/snapshot.kubevirt.io/v1alpha1/namespaces/default/virtualmachinesnapshots/my-vmsnapshot uid: 28eedf08-5d6a-42c1-969c-2eda58e2a78d spec: source: apiGroup: kubevirt.io kind: VirtualMachine name: my-vm status: conditions: - lastProbeTime: null lastTransitionTime: "2020-09-30T14:42:03Z" reason: Operation complete status: "False" 1 type: Progressing - lastProbeTime: null lastTransitionTime: "2020-09-30T14:42:03Z" reason: Operation complete status: "True" 2 type: Ready creationTime: "2020-09-30T14:42:03Z" readyToUse: true 3 sourceUID: 355897f3-73a0-4ec4-83d3-3c2df9486f4f virtualMachineSnapshotContentName: vmsnapshot-content-28eedf08-5d6a-42c1-969c-2eda58e2a78d 4
-
VirtualMachineSnapshotContent
리소스의spec:volumeBackups
속성을 확인하여 예상 PVC가 스냅샷에 포함되어 있는지 확인합니다.
7.18.7.3. CLI를 사용하여 스냅샷에서 가상 머신 복원
VM 스냅샷을 사용하여 기존 VM(가상 머신)을 이전 구성으로 복원할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. - 이전 상태로 복원하려는 VM의 전원을 끕니다.
절차
YAML 파일을 생성하여 복원할 VM의 이름과 소스로 사용할 스냅샷 이름을 지정하는
VirtualMachineRestore
오브젝트를 정의합니다.예를 들면 다음과 같습니다.
apiVersion: snapshot.kubevirt.io/v1alpha1 kind: VirtualMachineRestore metadata: name: my-vmrestore 1 spec: target: apiGroup: kubevirt.io kind: VirtualMachine name: my-vm 2 virtualMachineSnapshotName: my-vmsnapshot 3
VirtualMachineRestore
리소스를 만듭니다. 스냅샷 컨트롤러는VirtualMachineRestore
오브젝트의 상태 필드를 업데이트하고 기존 VM 구성을 스냅샷의 콘텐츠로 교체합니다.$ oc create -f <my-vmrestore>.yaml
검증
VM이 스냅샷에 표시된 이전 상태로 복원되었는지 확인합니다.
complete
플래그가true
로 설정되어야 합니다.$ oc get vmrestore <my-vmrestore>
출력 예
apiVersion: snapshot.kubevirt.io/v1alpha1 kind: VirtualMachineRestore metadata: creationTimestamp: "2020-09-30T14:46:27Z" generation: 5 name: my-vmrestore namespace: default ownerReferences: - apiVersion: kubevirt.io/v1alpha3 blockOwnerDeletion: true controller: true kind: VirtualMachine name: my-vm uid: 355897f3-73a0-4ec4-83d3-3c2df9486f4f resourceVersion: "5512" selfLink: /apis/snapshot.kubevirt.io/v1alpha1/namespaces/default/virtualmachinerestores/my-vmrestore uid: 71c679a8-136e-46b0-b9b5-f57175a6a041 spec: target: apiGroup: kubevirt.io kind: VirtualMachine name: my-vm virtualMachineSnapshotName: my-vmsnapshot status: complete: true 1 conditions: - lastProbeTime: null lastTransitionTime: "2020-09-30T14:46:28Z" reason: Operation complete status: "False" 2 type: Progressing - lastProbeTime: null lastTransitionTime: "2020-09-30T14:46:28Z" reason: Operation complete status: "True" 3 type: Ready deletedDataVolumes: - test-dv1 restoreTime: "2020-09-30T14:46:28Z" restores: - dataVolumeName: restore-71c679a8-136e-46b0-b9b5-f57175a6a041-datavolumedisk1 persistentVolumeClaim: restore-71c679a8-136e-46b0-b9b5-f57175a6a041-datavolumedisk1 volumeName: datavolumedisk1 volumeSnapshotName: vmsnapshot-28eedf08-5d6a-42c1-969c-2eda58e2a78d-volume-datavolumedisk1
7.18.7.4. CLI에서 가상 머신 스냅샷 삭제
적절한 VirtualMachineSnapshot
오브젝트를 삭제하여 기존 VM(가상 머신) 스냅샷을 삭제할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다.
절차
VirtualMachineSnapshot
오브젝트를 삭제합니다. 스냅샷 컨트롤러는VirtualMachineSnapshot
을 연결된VirtualMachineSnapshotContent
오브젝트와 함께 삭제합니다.$ oc delete vmsnapshot <my-vmsnapshot>
검증
스냅샷이 삭제되고 더 이상 이 VM에 연결되어 있지 않은지 확인합니다.
$ oc get vmsnapshot
7.18.7.5. 추가 리소스
7.18.8. 로컬 가상 머신 디스크를 다른 노드로 이동
로컬 볼륨 스토리지를 사용하는 가상 머신을 특정 노드에서 실행하도록 이동할 수 있습니다.
다음과 같은 이유로 가상 머신을 특정 노드로 이동할 수 있습니다.
- 현재 노드에서는 로컬 스토리지 구성을 제한합니다.
- 새 노드가 해당 가상 머신의 워크로드에 더 최적화되어 있습니다.
로컬 스토리지를 사용하는 가상 머신을 이동하려면 데이터 볼륨을 사용하여 기본 볼륨을 복제해야 합니다. 복제 작업이 완료되면 새 데이터 볼륨을 사용하도록 가상 머신 구성을 편집하거나 새 데이터 볼륨을 다른 가상 머신에 추가할 수 있습니다.
cluster-admin
역할이 없는 사용자는 다른 네임스페이스에 볼륨을 복제하려면 추가 사용자 권한이 있어야 합니다.
7.18.8.1. 다른 노드에 로컬 볼륨 복제
가상 머신 디스크를 특정 노드에서 실행하기 위해 기본 PVC(영구 볼륨 클레임)를 복제하여 가상 머신 디스크를 이동할 수 있습니다.
가상 머신 디스크가 올바른 노드에 복제되었는지 확인하려면 새 PV(영구 볼륨)를 생성하거나 올바른 노드에서 가상 머신 디스크를 확인합니다. 데이터 볼륨에서 참조할 수 있도록 PV에 고유한 라벨을 적용하십시오.
대상 PV는 소스 PVC와 크기가 같거나 커야 합니다. 대상 PV가 소스 PVC보다 작으면 복제 작업이 실패합니다.
사전 요구 사항
- 가상 머신이 실행되고 있지 않아야 합니다. 가상 머신 디스크를 복제하기 전에 가상 머신의 전원을 끄십시오.
절차
노드에 새 로컬 PV를 생성하거나 노드의 기존 로컬 PV를 확인합니다.
nodeAffinity.nodeSelectorTerms
매개변수를 포함하는 로컬 PV를 생성합니다. 다음 매니페스트에서는node01
에10Gi
로컬 PV를 생성합니다.kind: PersistentVolume apiVersion: v1 metadata: name: <destination-pv> 1 annotations: spec: accessModes: - ReadWriteOnce capacity: storage: 10Gi 2 local: path: /mnt/local-storage/local/disk1 3 nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - node01 4 persistentVolumeReclaimPolicy: Delete storageClassName: local volumeMode: Filesystem
대상 노드에 이미 존재하는 PV를 확인합니다. 구성에서
nodeAffinity
필드를 확인하여 PV가 프로비저닝되는 노드를 확인할 수 있습니다.$ oc get pv <destination-pv> -o yaml
다음 스니펫은 PV가
node01
에 있음을 보여줍니다.출력 예
... spec: nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname 1 operator: In values: - node01 2 ...
PV에 고유한 라벨을 추가합니다.
$ oc label pv <destination-pv> node=node01
다음을 참조하는 데이터 볼륨 매니페스트를 생성합니다.
- 가상 머신의 PVC 이름 및 네임스페이스
- 이전 단계에서 PV에 적용한 라벨
대상 PV의 크기
apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: <clone-datavolume> 1 spec: source: pvc: name: "<source-vm-disk>" 2 namespace: "<source-namespace>" 3 pvc: accessModes: - ReadWriteOnce selector: matchLabels: node: node01 4 resources: requests: storage: <10Gi> 5
클러스터에 데이터 볼륨 매니페스트를 적용하여 복제 작업을 시작합니다.
$ oc apply -f <clone-datavolume.yaml>
데이터 볼륨은 가상 머신의 PVC를 특정 노드의 PV에 복제합니다.
7.18.9. 빈 디스크 이미지를 추가하여 가상 스토리지 확장
OpenShift Virtualization에 빈 디스크 이미지를 추가하여 스토리지 용량을 늘리거나 새 데이터 파티션을 만들 수 있습니다.
7.18.9.1. 데이터 볼륨 정보
Dataolume
오브젝트는 CDI(Containerized Data Importer) 프로젝트에서 제공하는 사용자 정의 리소스입니다. 데이터 볼륨은 기본 PVC(영구 볼륨 클레임)와 관련된 가져오기, 복제, 업로드 작업을 오케스트레이션합니다. 데이터 볼륨은 OpenShift Virtualization과 통합되며 PVC가 준비되기 전에 가상 머신이 시작되지 않도록 합니다.
7.18.9.2. 데이터 볼륨에 빈 디스크 이미지 만들기
데이터 볼륨 구성 파일을 사용자 정의하고 배포하여 영구 볼륨 클레임에 빈 디스크 이미지를 새로 만들 수 있습니다.
사전 요구 사항
- 사용 가능한 영구 볼륨이 1개 이상 있습니다.
-
OpenShift CLI(
oc
)를 설치합니다.
절차
데이터 볼륨 구성 파일을 편집합니다.
apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: blank-image-datavolume spec: source: blank: {} pvc: # Optional: Set the storage class or omit to accept the default # storageClassName: "hostpath" accessModes: - ReadWriteOnce resources: requests: storage: 500Mi
다음 명령을 실행하여 빈 디스크 이미지를 만듭니다.
$ oc create -f <blank-image-datavolume>.yaml
7.18.9.3. 템플릿: 빈 디스크 이미지의 데이터 볼륨 구성 파일
blank-image-datavolume.yaml
apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: blank-image-datavolume spec: source: blank: {} pvc: # Optional: Set the storage class or omit to accept the default # storageClassName: "hostpath" accessModes: - ReadWriteOnce resources: requests: storage: 500Mi
7.18.10. 스마트 복제를 사용하여 데이터 볼륨 복제
스마트 복제는 복제 프로세스의 성능을 향상시키도록 설계된 OCS(OpenShift Container Platform Storage)의 기본 제공 기능입니다. 스마트 복제로 생성된 복제본은 호스트 지원 복제로 생성된 복제본보다 더 빠르고 효율적입니다.
스마트 복제를 활성화하기 위해 특별히 수행해야 할 작업은 없지만 이 기능을 사용하려면 스토리지 환경이 스마트 복제와 호환되는지 확인해야 합니다.
PVC(영구 볼륨 클레임) 소스를 사용하여 데이터 볼륨을 생성하면 복제 프로세스가 자동으로 시작됩니다. 해당 환경에서 스마트 복제를 지원하는지와 관계없이 데이터 볼륨 복제본은 항상 제공됩니다. 그러나 스토리지 공급자가 스마트 복제를 지원하는 경우에만 스마트 복제의 성능적인 이점을 활용할 수 있습니다.
7.18.10.1. 스마트 복제 이해
데이터 볼륨이 스마트 복제될 때는 다음 작업이 수행됩니다.
- 소스 PVC(영구 볼륨 클레임)의 스냅샷이 생성됩니다.
- 스냅샷에서 PVC가 생성됩니다.
- 스냅샷이 삭제됩니다.
7.18.10.2. 데이터 볼륨 복제
사전 요구 사항
스마트 복제를 수행하려면 다음 조건이 필요합니다.
- 스토리지 공급자에서 스냅샷을 지원해야 합니다.
- 소스 및 대상 PVC가 동일한 네임스페이스에 정의되어 있어야 합니다.
- 소스 및 대상 PVC가 동일한 스토리지 클래스에 정의되어 있어야 합니다.
-
VolumeSnapshotClass
오브젝트에서 소스 및 대상 PVC 모두에 정의된 스토리지 클래스를 참조해야 합니다.
이러한 사전 요구 사항 중 하나라도 충족되지 않으면 PVC 소스를 사용하여 데이터 볼륨을 생성할 때 호스트 지원 복제가 자동으로 수행됩니다.
절차
데이터 볼륨 복제를 시작하려면 다음을 수행합니다.
DataVolume
오브젝트에 대해 새 데이터 볼륨의 이름, 소스 PVC의 이름과 네임스페이스, 새 데이터 볼륨의 크기를 지정하는 YAML 파일을 생성합니다. 이 예제에서는 블록 모드에서 소스 PVC를 복제하므로volumeMode: block
이(가) 사용됩니다.apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: <cloner-datavolume> 1 spec: source: pvc: namespace: "<source-namespace>" 2 name: "<my-favorite-vm-disk>" 3 pvc: accessModes: - ReadWriteMany resources: requests: storage: <2Gi> 4 volumeMode: Block 5
데이터 볼륨을 생성하여 PVC 복제를 시작합니다.
$ oc create -f <cloner-datavolume>.yaml
참고데이터 볼륨이 있으면 PVC가 준비될 때까지 가상 머신이 시작되지 않으므로 PVC가 복제되는 동안 새 데이터 볼륨을 참조하는 가상 머신을 생성할 수 있습니다.
7.18.10.3. 추가 리소스
7.18.11. 데이터 볼륨의 스토리지 기본값
kubevirt-storage-class-defaults
구성 맵에서는 데이터 볼륨에 대한 액세스 모드 및 볼륨 모드 기본값을 제공합니다. 웹 콘솔에서 기본 스토리지와 더 일치하는 데이터 볼륨을 생성하기 위해 구성 맵에서 스토리지 클래스 기본값을 편집하거나 추가할 수 있습니다.
7.18.11.1. 데이터 볼륨의 스토리지 설정 정보
웹 콘솔에서 데이터 볼륨을 생성하려면 액세스 모드 및 볼륨 모드를 정의해야 합니다. 이러한 스토리지 설정은 기본적으로 ReadWriteOnce
액세스 모드 및 Filesystem
볼륨 모드로 구성됩니다.
이러한 설정은 openshift-cnv
네임스페이스에서 kubevirt-storage-class-defaults
구성 맵을 편집하여 수정할 수 있습니다. 다른 스토리지 클래스에 대한 설정을 추가하여 웹 콘솔에서 다른 스토리지 유형의 데이터 볼륨을 생성할 수도 있습니다.
기본 스토리지에서 지원하는 스토리지 설정을 구성해야 합니다.
웹 콘솔에서 생성하는 모든 데이터 볼륨에서는 구성 맵에도 정의되어 있는 스토리지 클래스를 지정하지 않는 한 기본 스토리지 설정을 사용합니다.
7.18.11.1.1. 액세스 모드
데이터 볼륨에서는 다음과 같은 액세스 모드를 지원합니다.
-
ReadWriteOnce
: 볼륨은 단일 노드에서 읽기-쓰기로 마운트할 수 있습니다.ReadWriteOnce
는 다양한 기능을 제공하며 기본 설정입니다. -
ReadWriteMany
: 볼륨은 여러 노드에서 읽기-쓰기로 마운트할 수 있습니다.ReadWriteMany
는 가상 머신의 노드 간 실시간 마이그레이션 등 일부 기능에 필요합니다.
기본 스토리지에서 지원하는 경우 ReadWriteMany
를 사용하는 것이 좋습니다.
7.18.11.1.2. 볼륨 모드
볼륨 모드는 볼륨이 포맷된 파일 시스템과 함께 사용되는지 또는 원시 블록 상태로 유지되는지를 정의합니다. 데이터 볼륨에서는 다음과 같은 볼륨 모드를 지원합니다.
-
파일 시스템
: 데이터 볼륨에 파일 시스템을 만듭니다. 이 설정은 기본 설정입니다. -
블록
: 블록 데이터 볼륨을 만듭니다. 기본 스토리지에서 지원하는 경우에만Block
을 사용하십시오.
7.18.11.2. 웹 콘솔에서 kubevirt-storage-class-defaults 구성 맵 편집
openshift-cnv
네임스페이스에서 kubevirt-storage-class-defaults
구성 맵을 편집하여 데이터 볼륨 스토리지 설정을 수정합니다. 다른 스토리지 클래스에 대한 설정을 추가하여 웹 콘솔에서 다른 스토리지 유형의 데이터 볼륨을 생성할 수도 있습니다.
기본 스토리지에서 지원하는 스토리지 설정을 구성해야 합니다.
절차
- 사이드 메뉴에서 워크로드 → 구성 맵을 클릭합니다.
- 프로젝트 목록에서 openshift-cnv를 선택합니다.
- kubevirt-storage-class-defaults를 클릭하여 구성 맵 개요를 엽니다.
- YAML 탭을 클릭하여 편집 가능한 구성을 표시합니다.
기본 스토리지에 적합한 스토리지 구성으로
data
값을 업데이트합니다.... data: accessMode: ReadWriteOnce 1 volumeMode: Filesystem 2 <new>.accessMode: ReadWriteMany 3 <new>.volumeMode: Block 4
- 저장을 클릭하여 구성 맵을 업데이트합니다.
7.18.11.3. CLI에서 kubevirt-storage-class-defaults 구성 맵 편집
openshift-cnv
네임스페이스에서 kubevirt-storage-class-defaults
구성 맵을 편집하여 데이터 볼륨 스토리지 설정을 수정합니다. 다른 스토리지 클래스에 대한 설정을 추가하여 웹 콘솔에서 다른 스토리지 유형의 데이터 볼륨을 생성할 수도 있습니다.
기본 스토리지에서 지원하는 스토리지 설정을 구성해야 합니다.
절차
다음 명령을 실행하여 구성 맵을 편집합니다.
$ oc edit configmap kubevirt-storage-class-defaults -n openshift-cnv
구성 맵의
data
값을 업데이트합니다.... data: accessMode: ReadWriteOnce 1 volumeMode: Filesystem 2 <new>.accessMode: ReadWriteMany 3 <new>.volumeMode: Block 4
- 편집기를 저장하고 종료하여 구성 맵을 업데이트합니다.
7.18.11.4. 여러 스토리지 클래스 기본값 예제
다음 YAML 파일은 두 스토리지 클래스, migration
및 block
에 대한 스토리지 설정이 구성된 kubevirt-storage-class-defaults
구성 맵의 예입니다.
구성 맵을 업데이트하기 전에 기본 스토리지에서 모든 설정을 지원하는지 확인하십시오.
kind: ConfigMap apiVersion: v1 metadata: name: kubevirt-storage-class-defaults namespace: openshift-cnv ... data: accessMode: ReadWriteOnce volumeMode: Filesystem nfs-sc.accessMode: ReadWriteMany nfs-sc.volumeMode: Filesystem block-sc.accessMode: ReadWriteMany block-sc.volumeMode: Block
7.18.12. 기본 OS 이미지 생성 및 사용
기본 OS(운영 체제) 이미지는 부팅 가능한 디스크로, OS 및 OS의 모든 구성 설정(예: 드라이버)을 포함합니다. 기본 OS 이미지를 사용하여 특정 구성으로 부팅 가능한 가상 머신을 생성합니다.
기본 OS 이미지를 사용하려면 최신 버전의 OpenShift Virtualization을 설치해야 합니다. 그런 다음 OpenShift Container Platform 웹 콘솔을 통해 PVC(영구 볼륨 클레임)를 생성하여 해당 PVC에 기본 OS 이미지를 업로드합니다. 업로드 후에는 웹 콘솔의 마법사를 사용하여 업로드한 이미지에서 가상 머신 또는 가상 머신 템플릿을 만듭니다.
7.18.12.1. 기본 OS 이미지를 저장할 영구 볼륨 클레임 생성
다음 단계에 따라 기본 OS(운영 체제) 이미지를 업로드하고 저장하는 데 사용하는 PVC(영구 볼륨 클레임)를 생성합니다.
전제 조건
-
os-images.kubevirt.io:edit
RBAC 역할의 사용자 또는 관리자로 로그인해야 합니다.
절차
- 기본 OS 이미지로 업로드하고 저장할 부팅 가능한 디스크의 로컬 이미지를 선택합니다.
- OpenShift Container Platform 웹 콘솔의 사이드바 메뉴에서 스토리지 > 영구 볼륨 클레임을 클릭합니다. 영구 볼륨 클레임 페이지가 표시됩니다.
- 영구 볼륨 클레임 생성 버튼을 클릭하고 사용할 데이터 업로드 폼 옵션을 선택합니다.
영구 볼륨 클레임에 데이터 업로드 폼을 작성하여 기본 OS 이미지를 업로드하고 저장하는 데 사용하는 PVC를 생성합니다.
- 찾아보기를 클릭하여 부팅 가능한 이미지를 찾아 기본 OS 이미지로 업로드하고 저장합니다.
- 이 데이터를 가상 머신 운영 체제에 연결 확인란을 선택합니다.
- 운영 체제 목록에서 업로드할 부팅 가능한 디스크의 OS를 선택합니다.
- 스토리지 클래스 목록에서 사용할 스토리지 클래스를 선택합니다.
- 크기 필드에 생성 중인 PVC 크기를 입력합니다.
- 액세스 모드를 선택합니다.
- 생성을 클릭하여 PVC를 생성합니다.
영구 볼륨 클레임 세부 정보 화면에 생성한 PVC에 대한 정보가 표시됩니다.
7.18.12.2. 기본 OS 이미지에서 가상 머신 생성
기본 OS(운영 체제) 이미지에 대한 PVC(영구 볼륨 클레임)를 생성한 후에는 PVC에 업로드한 기본 OS 이미지에서 새 가상 머신 또는 가상 머신 템플릿을 생성합니다.
관리자 이외의 사용자 권한으로 기본 OS 이미지에서 가상 머신 및 가상 머신 템플릿을 생성할 수 있습니다. 기본 OS 이미지를 PVC에 업로드하고 저장하려면 관리자 권한이 필요합니다.
전제 조건
- PVC를 생성할 때 이 데이터를 가상 머신 운영 체제에 연결 확인란을 선택했습니다.
프로세스
- OpenShift Container Platform 웹 콘솔의 사이드바 메뉴에서 워크로드 > 가상화를 클릭합니다. 가상화 페이지가 표시됩니다. 웹 콘솔 도움말 또는 기존 설명서를 사용하여 가상 머신 템플릿을 생성합니다.
업로드된 기본 OS 이미지에서 가상 머신 또는 가상 머신 템플릿을 생성합니다.
- 가상 머신 생성 > 마법사로 새로 생성을 선택합니다. 가상 머신 생성 마법사가 표시됩니다.
- 일반 마법사 페이지에서 OS 및 버전 이름 옆에 (사용 가능한 소스) 라벨이 표시된 운영 체제 목록에서 OS를 선택합니다. (사용 가능한 소스) 라벨은 이 OS에서 기본 OS 이미지를 사용할 수 있음을 나타냅니다.
- 사용 가능한 운영 체제 소스 복제 확인란이 선택되었는지 확인합니다.
- 검토 및 확인 버튼을 클릭합니다.
- 설정 검토 및 확인 마법사 페이지에서 가상 머신에 대한 정보를 검토하고 필요한 경우 변경합니다.
- 가상 머신 생성을 클릭하여 가상 머신을 생성합니다. 가상 머신 생성 완료 페이지에 가상 머신 세부 정보 보기 또는 목록으로 이동 링크가 표시되어 가상 머신 및 가상 머신 템플릿 목록을 확인할 수 있습니다.
7.18.12.3. 추가 리소스
7.18.13. 가상 머신에서 컨테이너 디스크 사용
가상 머신 이미지를 컨테이너 디스크에 빌드하고 컨테이너 레지스트리에 저장할 수 있습니다. 그러면 컨테이너 디스크를 가상 머신의 영구 스토리지로 가져오거나 임시 저장을 위해 가상 머신에 직접 연결할 수 있습니다.
대규모 컨테이너 디스크를 사용하는 경우 I/O 트래픽이 증가하여 작업자 노드에 영향을 줄 수 있습니다. 이로 인해 노드를 사용할 수 없게 될 수 있습니다. 다음을 통해 이를 해결할 수 있습니다.
7.18.13.1. 컨테이너 디스크 정보
컨테이너 디스크는 컨테이너 이미지 레지스트리에 컨테이너 이미지로 저장되어 있는 가상 머신 이미지입니다. 컨테이너 디스크를 사용하면 동일한 디스크 이미지를 여러 가상 머신에 제공하고 다수의 가상 머신 복제본을 생성할 수 있습니다.
컨테이너 디스크는 가상 머신에 연결된 데이터 볼륨을 사용하여 PVC(영구 볼륨 클레임)로 가져오거나 가상 머신에 임시 containerDisk
볼륨으로 직접 연결할 수 있습니다.
7.18.13.1.1. 데이터 볼륨을 사용하여 컨테이너 디스크를 PVC로 가져오기
CDI(Containerized Data Importer)를 사용하여 데이터 볼륨을 통해 컨테이너 디스크를 PVC로 가져옵니다. 그러면 영구 저장을 위해 데이터 볼륨을 가상 머신에 연결할 수 있습니다.
7.18.13.1.2. 컨테이너 디스크를 가상 머신에 containerDisk
볼륨으로 연결
containerDisk
는 임시 볼륨입니다. 이 볼륨은 가상 머신이 중지, 재시작 또는 삭제될 때 삭제됩니다. containerDisk
볼륨이 포함된 가상 머신이 시작되면 레지스트리에서 컨테이너 이미지가 풀링되어 가상 머신이 호스팅되는 노드에서 호스팅됩니다.
CD-ROM과 같은 읽기 전용 파일 시스템이나 일회용 가상 머신에는 containerDisk
볼륨을 사용하십시오.
데이터가 호스팅 노드의 로컬 스토리지에 임시로 기록되므로 읽기-쓰기 파일 시스템에는 containerDisk
볼륨을 사용하지 않는 것이 좋습니다. 이 볼륨을 사용하면 데이터를 대상 노드로 마이그레이션해야 하므로 노드 유지보수의 경우와 같이 가상 머신의 실시간 마이그레이션 속도가 느려집니다. 또한 노드의 전원이 끊기거나 노드가 예기치 않게 종료되면 모든 데이터가 손실됩니다.
7.18.13.2. 가상 머신용 컨테이너 디스크 준비
컨테이너 디스크를 가상 머신에서 사용하려면 가상 머신 이미지를 사용하여 빌드하고 컨테이너 레지스트리에 푸시해야 합니다. 그러면 데이터 볼륨을 사용하여 컨테이너 디스크를 PVC로 가져와서 가상 머신에 연결하거나 컨테이너 디스크를 임시 containerDisk
볼륨으로 가상 머신에 직접 연결할 수 있습니다.
컨테이너 디스크 내부의 디스크 이미지 크기는 컨테이너 디스크가 호스팅되는 레지스트리의 최대 계층 크기로 제한됩니다.
Red Hat Quay의 경우 Red Hat Quay 를 처음 배포할 때 생성되는 YAML 구성 파일을 편집하여 최대 계층 크기를 변경할 수 있습니다.
사전 요구 사항
-
podman
을 아직 설치하지 않은 경우 설치합니다. - 가상 머신 이미지는 QCOW2 또는 RAW 형식이어야 합니다.
절차
Dockerfile을 생성하여 가상 머신 이미지를 컨테이너 이미지로 빌드합니다. 가상 머신 이미지는 UID가
107
인 QEMU에 속하고 컨테이너 내부의/disk/
디렉터리에 있어야 합니다. 그런 다음/disk/
디렉터리에 대한 권한을0440
으로 설정해야 합니다.다음 예제에서는 Red Hat UBI(Universal Base Image)를 사용하여 첫 번째 단계에서 이러한 구성 변경을 처리하고, 두 번째 단계에서 최소
scratch
이미지를 사용하여 결과를 저장합니다.$ cat > Dockerfile << EOF FROM registry.access.redhat.com/ubi8/ubi:latest AS builder ADD --chown=107:107 <vm_image>.qcow2 /disk/ 1 RUN chmod 0440 /disk/* FROM scratch COPY --from=builder /disk/* /disk/ EOF
- 1
- 여기서 <vm_image>는 QCOW2 또는 RAW 형식의 가상 머신 이미지입니다.
원격 가상 머신 이미지를 사용하려면<vm_image>.qcow2
를 원격 이미지의 전체 URL로 교체하십시오.
컨테이너를 빌드하고 태그를 지정합니다.
$ podman build -t <registry>/<container_disk_name>:latest .
컨테이너 이미지를 레지스트리에 푸시합니다.
$ podman push <registry>/<container_disk_name>:latest
컨테이너 레지스트리에 TLS가 없는 경우 컨테이너 디스크를 영구 스토리지로 가져오기 전에 이를 비보안 레지스트리로 추가해야 합니다.
7.18.13.3. 컨테이너 레지스트리에서 비보안 레지스트리를 사용하도록 TLS 비활성화
cdi-insecure-registries
구성 맵에 레지스트리를 추가하여 컨테이너 레지스트리의 TLS(전송 계층 보안)를 비활성화할 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 로그인합니다.
절차
openshift-cnv
네임스페이스의cdi-insecure-registries
구성 맵에 레지스트리를 추가합니다.$ oc patch configmap cdi-insecure-registries -n openshift-cnv \ --type merge -p '{"data":{"mykey": "<insecure-registry-host>:5000"}}' 1
- 1
<insecure-registry-host>
를 레지스트리 호스트 이름으로 교체합니다.
7.18.13.4. 다음 단계
- 컨테이너 디스크를 가상 머신의 영구 스토리지로 가져옵니다.
-
임시 저장을 위해
containerDisk
볼륨을 사용하는 가상 머신을 생성합니다.
7.18.14. CDI 스크래치 공간 준비
7.18.14.1. 데이터 볼륨 정보
Dataolume
오브젝트는 CDI(Containerized Data Importer) 프로젝트에서 제공하는 사용자 정의 리소스입니다. 데이터 볼륨은 기본 PVC(영구 볼륨 클레임)와 관련된 가져오기, 복제, 업로드 작업을 오케스트레이션합니다. 데이터 볼륨은 OpenShift Virtualization과 통합되며 PVC가 준비되기 전에 가상 머신이 시작되지 않도록 합니다.
7.18.14.2. 스크래치 공간 이해
CDI(Containerized Data Importer)에는 가상 머신 이미지 가져오기 및 업로드와 같은 일부 작업을 완료하기 위해 스크래치 공간(임시 스토리지)이 필요합니다. 이 프로세스 동안 CDI는 대상 DV(데이터 볼륨)를 지원하는 PVC 크기와 같은 스크래치 공간 PVC를 프로비저닝합니다. 스크래치 공간 PVC는 작업이 완료되거나 중단된 후 삭제됩니다.
CDIConfig
오브젝트를 사용하면 CDIConfig
오브젝트의 spec:
섹션에 scratchSpaceStorageClass
를 설정하여 스크래치 공간 PVC를 바인딩하는 데 사용할 스토리지 클래스를 정의할 수 있습니다.
정의된 스토리지 클래스가 클러스터의 스토리지 클래스와 일치하지 않으면 클러스터에 정의된 기본 스토리지 클래스가 사용됩니다. 클러스터에 기본 스토리지 클래스가 정의되어 있지 않은 경우에는 원래 DV 또는 PVC를 프로비저닝하는 데 사용된 스토리지 클래스가 사용됩니다.
CDI에서는 원본 데이터 볼륨을 지원하는 PVC에 관계없이 file
볼륨 모드로 스크래치 공간을 요청해야 합니다. 원본 PVC를 block
볼륨 모드로 지원하는 경우 file
볼륨 모드 PVC를 프로비저닝할 수 있는 스토리지 클래스를 정의해야 합니다.
수동 프로비저닝
스토리지 클래스가 없는 경우 CDI는 프로젝트에서 이미지의 크기 요구 사항과 일치하는 PVC를 사용합니다. 이러한 요구 사항과 일치하는 PVC가 없는 경우에는 CDI 가져오기 Pod가 적절한 PVC를 사용할 수 있거나 타임아웃 기능에서 Pod를 종료할 때까지 Pending 상태로 유지됩니다.
7.18.14.3. 스크래치 공간이 필요한 CDI 작업
유형 | 이유 |
---|---|
레지스트리 가져오기 | CDI에서는 이미지를 스크래치 공간으로 다운로드하고 레이어를 추출하여 이미지 파일을 찾아야 합니다. 그런 다음 해당 이미지 파일을 원시 디스크로 변환하기 위해 QEMU-IMG로 전달합니다. |
이미지 업로드 | QEMU-IMG에서는 STDIN의 입력을 허용하지 않습니다. 대신 변환을 위해 QEMU-IMG로 전달할 수 있을 때까지 업로드할 이미지를 스크래치 공간에 저장합니다. |
보관된 이미지의 HTTP 가져오기 | QEMU-IMG에서는 CDI에서 지원하는 아카이브 형식 처리 방법을 확인할 수 없습니다. 대신, QEMU-IMG에 전달할 때까지 해당 이미지를 보관하지 않고 스크래치 공간에 저장합니다. |
인증된 이미지의 HTTP 가져오기 | QEMU-IMG에서 인증을 부적절하게 처리합니다. 대신, QEMU-IMG로 전달할 때까지 이미지를 스크래치 공간에 저장하고 인증합니다. |
사용자 정의 인증서의 HTTP 가져오기 | QEMU-IMG에서는 HTTPS 끝점의 사용자 정의 인증서를 부적절하게 처리합니다. 대신, CDI에서는 파일을 QEMU-IMG에 전달할 때까지 이미지를 스크래치 공간에 다운로드합니다. |
7.18.14.4. CDI 구성에 스토리지 클래스 정의
CDI 구성에 스토리지 클래스를 정의하여 CDI 작업을 위한 스크래치 공간을 동적으로 프로비저닝합니다.
프로세스
oc
클라이언트를 사용하여cdiconfig/config
를 편집하고, 클러스터의 스토리지 클래스와 일치하도록spec: scratchSpaceStorageClass
를 추가하거나 편집합니다.$ oc edit cdiconfig/config
API Version: cdi.kubevirt.io/v1beta1 kind: CDIConfig metadata: name: config ... spec: scratchSpaceStorageClass: "<storage_class>" ...
7.18.14.5. CDI 지원 작업 매트릭스
이 매트릭스에는 끝점에 대한 콘텐츠 유형에 따라 지원되는 CDI 작업과 이러한 작업 중 스크래치 공간이 필요한 작업이 표시되어 있습니다.
콘텐츠 유형 | HTTP | HTTPS | HTTP 기본 인증 | 레지스트리 | 업로드 |
---|---|---|---|---|---|
KubeVirt(QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt(RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ 지원되는 작업
□ 지원되지 않는 작업
* 스크래치 공간 필요
** 사용자 정의 인증 기관이 필요한 경우 스크래치 공간 필요
추가 리소스
- 스토리지 클래스 및 스토리지 클래스를 클러스터에 정의하는 방법에 대한 자세한 내용은 동적 프로비저닝 섹션을 참조하십시오.
7.18.15. 영구 볼륨 다시 사용
정적으로 프로비저닝된 PV(영구 볼륨)를 다시 사용하려면 먼저 볼륨을 회수해야 합니다. 이를 위해서는 스토리지 구성을 다시 사용할 수 있도록 PV를 삭제해야 합니다.
7.18.15.1. 정적으로 프로비저닝된 영구 볼륨 회수 정보
PV(영구 볼륨)를 회수할 때는 PVC(영구 볼륨 클레임)에서 PV를 바인딩 해제하고 PV를 삭제합니다. 기본 스토리지에 따라 공유 스토리지를 수동으로 삭제해야 할 수도 있습니다.
그런 다음 PV 구성을 다시 사용하여 다른 이름으로 PV를 생성할 수 있습니다.
정적으로 프로비저닝된 PV를 회수하려면 PV에 Retain
이라는 회수 정책이 있어야 합니다. 회수 정책이 없으면 PVC를 PV에서 바인딩 해제할 때 PV의 상태가 실패가 됩니다.
OpenShift Container Platform 4에서는 Recycle
회수 정책이 사용되지 않습니다.
7.18.15.2. 정적으로 프로비저닝된 영구 볼륨 회수
PVC(영구 볼륨 클레임)를 바인딩 해제하고 PV를 삭제하여 정적으로 프로비저닝된 PV(영구 볼륨)를 회수합니다. 공유 스토리지를 수동으로 삭제해야 할 수도 있습니다.
정적으로 프로비저닝된 PV를 회수하는 방법은 기본 스토리지에 따라 다릅니다. 이 절차에서는 일반적인 접근법을 제공하며 사용 중인 스토리지에 따라 사용자 정의가 필요할 수 있습니다.
절차
PV의 회수 정책이
Retain
으로 설정되어 있는지 확인합니다.PV의 회수 정책을 확인합니다.
$ oc get pv <pv_name> -o yaml | grep 'persistentVolumeReclaimPolicy'
persistentVolumeReclaimPolicy
가Retain
으로 설정되지 않은 경우, 다음 명령을 사용하여 회수 정책을 편집합니다.$ oc patch pv <pv_name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
PV를 사용하는 리소스가 없는지 확인합니다.
$ oc describe pvc <pvc_name> | grep 'Mounted By:'
PVC를 사용하는 모든 리소스를 제거한 후 계속합니다.
PVC를 삭제하여 PV를 해제합니다.
$ oc delete pvc <pvc_name>
선택 사항: PV 구성을 YAML 파일로 내보냅니다. 이 절차의 뒷부분에서 공유 스토리지를 수동으로 제거하는 경우 이 구성을 참조할 수 있습니다. PV를 회수한 후 새 PV를 동일한 스토리지 구성으로 생성하기 위해 이 파일의
spec
매개변수를 기반으로 사용할 수도 있습니다.$ oc get pv <pv_name> -o yaml > <file_name>.yaml
PV를 삭제합니다.
$ oc delete pv <pv_name>
선택 사항: 스토리지 유형에 따라 공유 스토리지 폴더의 콘텐츠를 제거해야 할 수 있습니다.
$ rm -rf <path_to_share_storage>
선택 사항: 삭제된 PV와 동일한 스토리지 구성을 사용하는 PV를 생성합니다. 회수된 PV 구성을 이전에 내보낸 경우 해당 파일의
spec
매개변수를 새 PV 매니페스트의 기반으로 사용할 수 있습니다.참고충돌을 피하려면 새 PV 오브젝트에 삭제한 오브젝트와 다른 이름을 지정하는 것이 좋습니다.
$ oc create -f <new_pv_name>.yaml
추가 리소스
- 가상 머신 로컬 스토리지 구성
- OpenShift Container Platform Storage 설명서에는 영구 스토리지에 대한 자세한 내용이 있습니다.
7.18.16. 데이터 볼륨 삭제
oc
명령줄 인터페이스를 사용하여 데이터 볼륨을 수동으로 삭제할 수 있습니다.
가상 머신을 삭제하면 사용하는 데이터 볼륨이 자동으로 삭제됩니다.
7.18.16.1. 데이터 볼륨 정보
Dataolume
오브젝트는 CDI(Containerized Data Importer) 프로젝트에서 제공하는 사용자 정의 리소스입니다. 데이터 볼륨은 기본 PVC(영구 볼륨 클레임)와 관련된 가져오기, 복제, 업로드 작업을 오케스트레이션합니다. 데이터 볼륨은 OpenShift Virtualization과 통합되며 PVC가 준비되기 전에 가상 머신이 시작되지 않도록 합니다.
7.18.16.2. 모든 데이터 볼륨 나열
oc
명령줄 인터페이스를 사용하여 클러스터의 데이터 볼륨을 나열할 수 있습니다.
절차
다음 명령을 실행하여 모든 데이터 볼륨을 나열합니다.
$ oc get dvs
7.18.16.3. 데이터 볼륨 삭제
oc
CLI(명령줄 인터페이스)를 사용하여 데이터 볼륨을 삭제할 수 있습니다.
사전 요구 사항
- 삭제할 데이터 볼륨의 이름을 확인합니다.
절차
다음 명령을 실행하여 데이터 볼륨을 삭제합니다.
$ oc delete dv <datavolume_name>
참고이 명령은 현재 프로젝트에 존재하는 오브젝트만 삭제합니다. 삭제하려는 오브젝트가 다른 프로젝트 또는 네임스페이스에 있는 경우
-n <project_name>
옵션을 지정하십시오.
8장. 가상 머신 템플릿
8.1. 가상 머신 템플릿 생성
가상 머신 템플릿을 사용하면 유사한 구성의 가상 머신을 여러 개 생성할 수 있습니다. 템플릿을 생성한 후 가상 머신을 생성할 때 해당 템플릿을 참조합니다.
8.1.1. 웹 콘솔에서 대화식 마법사를 사용하여 가상 머신 템플릿 생성
웹 콘솔에는 일반, 네트워킹, 스토리지, 고급, 검토 단계를 안내하는 대화식 마법사가 있어 가상 머신 템플릿 생성 프로세스를 단순화합니다. 모든 필수 필드는 *
로 표시됩니다. 마법사에서는 필수 필드에 값을 제공해야 다음 단계로 이동할 수 있습니다.
프로세스
- OpenShift Virtualization 콘솔의 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 템플릿 탭을 클릭합니다.
- 템플릿 생성을 클릭하고 마법사로 새로 생성을 선택합니다.
- 일반 단계의 모든 필수 필드를 입력합니다.
다음을 클릭하여 네트워킹 화면을 진행합니다. 기본적으로 이름이
nic0
인 NIC가 연결되어 있습니다.- 선택 사항: 네트워크 인터페이스 추가를 클릭하여 추가 NIC를 생성합니다.
- 선택 사항: 옵션 메뉴 를 클릭하고 삭제를 선택하여 일부 또는 모든 NIC를 제거할 수 있습니다. 템플릿으로 생성한 가상 머신에는 NIC를 연결할 필요가 없습니다. NIC는 가상 머신을 생성한 후 생성할 수 있습니다.
다음을 클릭하여 스토리지 화면을 진행합니다.
- 선택 사항: 디스크 추가를 클릭하여 추가 디스크를 만듭니다.
- 선택 사항: 디스크를 클릭하여 사용 가능한 필드를 수정합니다. ✓ 버튼을 클릭하여 변경 사항을 저장합니다.
선택 사항: Disk(디스크 )를 클릭하여 Select Storage (스토리지 선택) 목록에서 사용 가능한 디스크를 선택합니다.
참고일반 단계에서 URL 또는 Container를 소스로 선택하면
rootdisk
디스크가 생성되어 가상 머신에 부팅 가능 디스크로 연결됩니다.rootdisk
를 수정할 수는 있지만 제거할 수는 없습니다.가상 머신에 연결된 디스크가 없는 경우 PXE 소스에서 프로비저닝된 가상 머신에는 부팅 가능 디스크가 필요하지 않습니다. 하나 이상의 디스크가 가상 머신에 연결된 경우 하나의 디스크를 부팅 가능 디스크로 선택해야 합니다.
가상 머신 템플릿 생성 >을 클릭합니다. 결과 화면에 가상 머신 템플릿의 JSON 구성 파일이 표시됩니다.
템플릿은 가상 머신 템플릿 탭에 나열됩니다.
8.1.2. 가상 머신 템플릿 대화식 마법사 필드
다음 표에는 가상 머신 템플릿 생성 대화식 대화 상자의 기본 설정, 네트워킹, 스토리지 창 필드가 설명되어 있습니다.
8.1.2.1. 가상 머신 템플릿 마법사 필드
이름 | 매개변수 | 설명 |
---|---|---|
소스 | PXE | PXE 메뉴에서 가상 머신을 프로비저닝합니다. 클러스터에 PXE 지원 NIC가 필요합니다. |
URL | HTTP 또는 S3 끝점의 사용 가능한 이미지에서 가상 머신을 프로비저닝합니다. | |
컨테이너 |
클러스터에서 액세스할 수 있는 레지스트리의 부팅 가능한 운영 체제 컨테이너에서 가상 머신을 프로비저닝합니다. 예를 들면 | |
디스크 | 디스크에서 가상 머신을 프로비저닝합니다. | |
운영 체제 | 가상 머신에 대해 선택된 기본 운영 체제입니다. | |
플레이버 | 작음, 중간, 큼, 매우 작음, 사용자 정의 | 가상 머신에 할당된 CPU 및 메모리의 양을 결정하는 사전 설정입니다. 플레이버에 표시되는 사전 설정은 운영 체제에 따라 다릅니다. |
메모리 | 가상 머신에 할당된 메모리 크기(GiB)입니다. | |
CPU | 가상 머신에 할당된 CPU의 양입니다. | |
워크로드 프로필 | 고성능 | 고성능 워크로드에 최적화된 가상 머신 구성입니다. |
서버 | 서버 워크로드를 실행하는 데 최적화된 프로필입니다. | |
데스크탑 | 데스크탑에서 사용할 가상 머신 구성입니다. | |
이름 |
이름에는 소문자( | |
설명 | 선택적 설명 필드입니다. |
8.1.2.2. Cloud-init 필드
이름 | 설명 |
---|---|
호스트 이름 | 가상 머신의 특정 호스트 이름을 설정합니다. |
인증된 SSH 키 | 가상 머신의 ~/.ssh/authorized_keys에 복사되는 사용자의 공개 키입니다. |
사용자 정의 스크립트 | 기타 옵션을 사용자 정의 cloud-init 스크립트를 붙여넣는 필드로 교체합니다. |
8.1.2.3. 네트워킹 필드
이름 | 설명 |
---|---|
이름 | 네트워크 인터페이스 컨트롤러의 이름입니다. |
모델 | 네트워크 인터페이스 컨트롤러의 모델을 나타냅니다. 지원되는 값은 e1000e 및 virtio입니다. |
네트워크 | 사용 가능한 네트워크 연결 정의 목록입니다. |
유형 |
사용 가능한 바인딩 방법 목록입니다. 기본 Pod 네트워크의 경우 권장되는 유일한 바인딩 방법은 |
MAC 주소 | 네트워크 인터페이스 컨트롤러의 MAC 주소입니다. MAC 주소를 지정하지 않으면 주소가 자동으로 할당됩니다. |
8.1.2.4. 스토리지 필드
이름 | 설명 |
---|---|
소스 | 가상 머신의 빈 디스크를 선택하거나 사용 가능한 옵션 중에서 선택합니다. URL,컨테이너,복제된 디스크 연결 또는 디스크 연결. 기존 디스크를 선택하여 가상 머신에 연결하려면 사용 가능한 PVC(영구 볼륨 클레임) 목록에서 복제된 디스크 연결 또는 디스크 연결을 선택합니다. |
이름 |
디스크 이름입니다. 이름에는 소문자( |
크기(GiB) | 디스크 크기(GiB)입니다. |
인터페이스 | 디스크 장치의 유형입니다. 지원되는 인터페이스는 virtIO, SATA, SCSI입니다. |
스토리지 클래스 | 디스크를 만드는 데 사용되는 스토리지 클래스입니다. |
고급 → 볼륨 모드 | 영구 볼륨에서 포맷된 파일 시스템을 사용하는지 또는 원시 블록 상태를 사용하는지를 정의합니다. 기본값은 Filesystem입니다. |
고급 → 액세스 모드 | 영구 볼륨의 액세스 모드입니다. 지원되는 액세스 모드는 ReadWriteOnce, ReadOnlyMany, ReadWriteMany입니다. |
고급 스토리지 설정
다음 고급 스토리지 설정은 비어 있음, URL을 통해 가져오기, 기존 PVC 복제 디스크에 사용할 수 있습니다. 해당 매개변수는 선택 사항입니다. 이러한 매개변수를 지정하지 않으면 kubevirt-storage-class-defaults
구성 맵의 기본값이 사용됩니다.
이름 | 매개변수 | 설명 |
---|---|---|
볼륨 모드 | 파일 시스템 | 파일 시스템 기반 볼륨에 가상 디스크를 저장합니다. |
블록 |
가상 디스크를 블록 볼륨에 직접 저장합니다. 기본 스토리지에서 지원하는 경우에만 | |
액세스 모드 | 단일 사용자(RWO) | 디스크는 단일 노드에서 읽기/쓰기로 마운트할 수 있습니다. |
공유 액세스(RWX) | 디스크는 여러 노드에서 읽기/쓰기로 마운트할 수 있습니다. 참고 이는 가상 머신의 노드 간 실시간 마이그레이션 등 일부 기능에 필요합니다. | |
읽기 전용(ROX) | 디스크는 많은 노드에서 읽기 전용으로 마운트할 수 있습니다. |
8.2. 가상 머신 템플릿 편집
YAML 편집기에서 전체 구성을 편집하거나 가상 머신 템플릿 개요 화면에서 매개변수 서브 세트를 편집하여 웹 콘솔에서 가상 머신 템플릿을 업데이트할 수 있습니다.
8.2.1. 웹 콘솔에서 가상 머신 템플릿 편집
관련 필드 옆에 있는 연필 아이콘을 클릭하여 웹 콘솔의 가상 머신 템플릿 개요 화면에서 가상 머신 템플릿에 대해 선택된 값을 편집합니다. CLI를 사용하여 다른 값을 편집할 수 있습니다.
프로세스
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 템플릿 탭을 클릭합니다.
- 가상 머신 템플릿을 선택하여 가상 머신 템플릿 개요 화면을 엽니다.
- 세부 정보 탭을 클릭합니다.
- 연필 아이콘을 클릭하여 필드를 편집할 수 있도록 합니다.
- 관련 사항을 변경하고 저장을 클릭합니다.
가상 머신 템플릿을 편집해도 해당 템플릿에서 이미 생성된 가상 머신에는 영향을 미치지 않습니다.
8.2.2. 웹 콘솔에서 가상 머신 템플릿 YAML 구성 편집
웹 콘솔에서 가상 머신 템플릿의 YAML 구성을 편집할 수 있습니다.
일부 매개변수는 수정할 수 없습니다. 구성이 유효하지 않은 상태에서 저장을 클릭하면 해당 매개변수를 수정할 수 없다는 오류 메시지가 표시됩니다.
편집하는 동안 YAML 화면에서 벗어나면 구성 변경 사항이 취소됩니다.
절차
- OpenShift Virtualization 콘솔의 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 템플릿 탭을 클릭합니다.
- 템플릿을 선택합니다.
- YAML 탭을 클릭하여 편집 가능한 구성을 표시합니다.
- 파일을 편집하고 저장을 클릭합니다.
확인 메시지에 업데이트된 오브젝트 버전 번호와 수정이 완료되었다는 내용이 표시됩니다.
8.2.3. 가상 머신 템플릿에 가상 디스크 추가
가상 디스크를 가상 머신 템플릿에 추가하려면 이 절차를 사용하십시오.
절차
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 템플릿 탭을 클릭합니다.
- 가상 머신 템플릿을 선택하여 가상 머신 템플릿 개요 화면을 엽니다.
- 디스크 탭을 클릭합니다.
- 디스크 추가를 클릭하여 디스크 추가 창을 엽니다.
디스크 추가 창에서 소스, 이름, 크기, 인터페이스, 유형, 스토리지 클래스를 지정합니다.
-
선택 사항: 고급 목록에서 가상 디스크의 볼륨 모드 및 액세스 모드를 지정합니다. 이러한 매개변수를 지정하지 않으면
kubevirt-storage-class-defaults
구성 맵의 기본값이 사용됩니다.
-
선택 사항: 고급 목록에서 가상 디스크의 볼륨 모드 및 액세스 모드를 지정합니다. 이러한 매개변수를 지정하지 않으면
- 추가를 클릭합니다.
8.2.4. 가상 머신 템플릿에 네트워크 인터페이스 추가
네트워크 인터페이스를 가상 머신 템플릿에 추가하려면 이 절차를 사용하십시오.
절차
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 템플릿 탭을 클릭합니다.
- 가상 머신 템플릿을 선택하여 가상 머신 템플릿 개요 화면을 엽니다.
- 네트워크 인터페이스 탭을 클릭합니다.
- 네트워크 인터페이스 추가를 클릭합니다.
- 네트워크 인터페이스 추가 창에서 네트워크 인터페이스의 이름, 모델, 네트워크, 유형, MAC 주소를 지정합니다.
- 추가를 클릭합니다.
8.2.5. 가상 머신 템플릿의 CD-ROM 편집
가상 머신에 CD-ROM을 구성하려면 다음 절차를 사용하십시오.
프로세스
- 가상 머신 템플릿 탭에서 가상 머신 템플릿을 선택합니다.
- 개요 탭을 선택합니다.
CD-ROM 구성을 추가하거나 편집하려면 CD-ROM 라벨 오른쪽에 있는 연필 아이콘을 클릭합니다. CD-ROM 편집 창이 열립니다.
- CD-ROM을 편집할 수 없는 경우 다음 메시지가 표시됩니다. 가상 시스템에 CD-ROM이 연결되어 있지 않습니다.
- 사용 가능한 CD-ROM이 있는 경우 -를 클릭하여 CD-ROM을 제거할 수 있습니다.
CD-ROM 편집 창에서 다음을 수행합니다.
- 미디어 유형 드롭다운 목록에서 CD-ROM 구성 유형을 선택합니다. CD-ROM 구성 유형은 컨테이너, URL, 영구 볼륨 클레임입니다.
- 각 유형에 필요한 정보를 입력합니다.
- 모든 CD-ROM이 추가되면 저장을 클릭합니다.
8.3. 가상 머신 템플릿 전용 리소스 활성화
가상 머신은 성능 향상을 위해 CPU와 같은 노드 리소스를 전용으로 사용할 수 있습니다.
8.3.1. 전용 리소스 정보
가상 머신에 전용 리소스를 사용하면 가상 머신의 워크로드가 다른 프로세스에서 사용하지 않는 CPU에 예약됩니다. 전용 리소스를 사용하면 가상 머신의 성능과 대기 시간 예측 정확도를 개선할 수 있습니다.
8.3.2. 사전 요구 사항
-
노드에 CPU 관리자를 구성해야 합니다. 가상 머신 워크로드를 예약하기 전에 노드에
cpumanager
=true
라벨이 있는지 확인하십시오.
8.3.3. 가상 머신 템플릿 전용 리소스 활성화
웹 콘솔의 가상 머신 템플릿 개요 페이지에서 가상 머신 템플릿 전용 리소스를 활성화할 수 있습니다.
프로세스
- 사이드 메뉴에서 워크로드 → 가상 머신 템플릿을 클릭합니다.
- 가상 머신 템플릿을 선택하여 가상 머신 템플릿 개요 페이지를 엽니다.
- 세부 정보 탭을 클릭합니다.
- 전용 리소스 필드 오른쪽에 있는 연필 아이콘을 클릭하여 전용 리소스 창을 엽니다.
- 전용 리소스(보장된 정책)를 사용하여 이 워크로드 예약을 선택합니다.
- 저장을 클릭합니다.
8.4. 가상 머신 템플릿 삭제
웹 콘솔에서 가상 머신 템플릿을 삭제할 수 있습니다.
8.4.1. 웹 콘솔에서 가상 머신 템플릿 삭제
가상 머신 템플릿을 삭제하면 클러스터에서 해당 템플릿이 영구적으로 제거됩니다.
프로세스
- OpenShift Virtualization 콘솔의 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 템플릿 탭을 클릭합니다.
이 창에서 가상 머신 템플릿을 삭제하면 하나의 창에서 여러 템플릿에 대한 작업을 더 쉽게 수행할 수 있습니다. 가상 머신 템플릿 세부 정보 창에서 가상 머신 템플릿을 삭제하면 선택한 템플릿에 대한 포괄적인 세부 정보를 볼 수 있습니다.
- 삭제할 템플릿의 옵션 메뉴 를 클릭하고 템플릿 삭제를 선택합니다.
- 템플릿 이름을 클릭하여 가상 머신 템플릿 세부 정보 창을 열고 작업 → 템플릿 삭제를 클릭합니다.
- 확인 팝업 창에서 삭제를 클릭하여 템플릿을 영구적으로 삭제합니다.
9장. 실시간 마이그레이션
9.1. 가상 머신 실시간 마이그레이션
9.1.1. 실시간 마이그레이션 이해
실시간 마이그레이션은 가상 워크로드 또는 액세스를 중단하지 않고 실행 중인 VMI(가상 머신 인스턴스)를 클러스터의 다른 노드로 이동하는 프로세스입니다. VMI에서 LiveMigrate
제거 전략을 사용하는 경우 VMI가 유지보수 모드로 실행되는 노드가 유지보수 모드에 배치될 때 자동으로 마이그레이션됩니다. 마이그레이션할 VMI를 선택하여 실시간 마이그레이션을 수동으로 시작할 수도 있습니다.
가상 머신에 실시간 마이그레이션할 공유 RWX(ReadWriteMany) 액세스 모드의 PVC(영구 볼륨 클레임)가 있어야 합니다.
SR-IOV 네트워크 인터페이스에 연결된 가상 머신에서는 실시간 마이그레이션이 지원되지 않습니다.
9.1.2. 실시간 마이그레이션을 위해 액세스 모드 업데이트
실시간 마이그레이션이 제대로 작동하려면 RWX(ReadWriteMany) 액세스 모드를 사용해야 합니다. 필요한 경우 이 절차를 사용하여 액세스 모드를 업데이트하십시오.
절차
RWX 액세스 모드를 설정하려면 다음
oc patch
명령을 실행합니다.$ oc patch -n openshift-cnv \ cm kubevirt-storage-class-defaults \ -p '{"data":{"'$<STORAGE_CLASS>'.accessMode":"ReadWriteMany"}}'
9.2. 실시간 마이그레이션 제한 및 타임아웃
마이그레이션 프로세스에서 클러스터를 전부 사용하지 않도록 실시간 마이그레이션 제한 및 타임아웃이 적용됩니다. kubevirt-config
구성 파일을 편집하여 다음 설정을 구성합니다.
9.2.1. 실시간 마이그레이션 제한 및 타임아웃 구성
업데이트된 키:값 필드를 openshift-cnv
네임스페이스에 있는 kubevirt-config
구성 파일에 추가하여 클러스터의 실시간 마이그레이션 제한 및 타임아웃을 구성합니다.
절차
kubevirt-config
구성 파일을 편집하고 필요한 실시간 마이그레이션 매개변수를 추가합니다. 다음 예제에서는 기본값을 보여줍니다.$ oc edit configmap kubevirt-config -n openshift-cnv
설정 파일 예
apiVersion: v1 data: default-network-interface: masquerade feature-gates: DataVolumes,SRIOV,LiveMigration,CPUManager,CPUNodeDiscovery,Sidecar,Snapshot migrations: |- parallelMigrationsPerCluster: "5" parallelOutboundMigrationsPerNode: "2" bandwidthPerMigration: "64Mi" completionTimeoutPerGiB: "800" progressTimeout: "150" machine-type: pc-q35-rhel8.3.0 selinuxLauncherType: virt_launcher.process smbios: |- Family: Red Hat Product: Container-native virtualization Manufacturer: Red Hat Sku: 2.6.0 Version: 2.6.0 kind: ConfigMap metadata: creationTimestamp: "2021-03-26T18:01:04Z" labels: app: kubevirt-hyperconverged name: kubevirt-config namespace: openshift-cnv resourceVersion: "15371295" selfLink: /api/v1/namespaces/openshift-cnv/configmaps/kubevirt-config uid: <uuid>
9.2.2. 클러스터 수준의 실시간 마이그레이션 제한 및 타임아웃
매개변수 | 설명 | 기본 |
---|---|---|
| 클러스터에서 병렬로 실행되고 있는 마이그레이션의 수입니다. | 5 |
| 노드당 최대 아웃바운드 마이그레이션의 수입니다. | 2 |
| 각 마이그레이션의 대역폭 제한(MiB/s)입니다. | 64Mi |
|
이 시점에 메모리 GiB당 초 단위로 마이그레이션이 완료되지 않으면 마이그레이션이 취소됩니다. 예를 들어, 메모리가 6GiB인 가상 머신 인스턴스는 4800초 내에 마이그레이션이 완료되지 않으면 타임아웃됩니다. | 800 |
| 이 시간(초) 내에 메모리 복사를 진행하지 못하면 마이그레이션이 취소됩니다. | 150 |
9.3. 가상 머신 인스턴스를 다른 노드로 마이그레이션
웹 콘솔 또는 CLI를 사용하여 다른 노드로의 가상 머신 인스턴스 실시간 마이그레이션을 수동으로 시작합니다.
9.3.1. 웹 콘솔에서 가상 머신 인스턴스 실시간 마이그레이션 시작
실행 중인 가상 머신 인스턴스를 클러스터의 다른 노드로 마이그레이션합니다.
가상 머신 마이그레이션 작업은 모든 사용자에게 표시되지만 관리자만 가상 머신 마이그레이션을 시작할 수 있습니다.
절차
- OpenShift Virtualization 콘솔의 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
이 화면에서 마이그레이션을 시작하면 한 화면에서 여러 가상 머신에 대한 작업을 더 쉽게 수행할 수 있습니다. 가상 머신 개요 화면에서 마이그레이션을 시작하면 선택한 가상 머신에 대한 포괄적인 세부 정보를 볼 수 있습니다.
- 가상 머신 끝에 있는 옵션 메뉴 를 클릭하고 가상 머신 마이그레이션을 선택합니다.
- 가상 머신 이름을 클릭하여 가상 머신 개요 화면을 열고 작업 → 가상 머신 마이그레이션을 클릭합니다.
- 마이그레이션을 클릭하여 가상 머신을 다른 노드로 마이그레이션합니다.
9.3.2. CLI에서 가상 머신 인스턴스 실시간 마이그레이션 시작
클러스터에서 VirtualMachineInstanceMigration
오브젝트를 생성하고 가상 머신 인스턴스의 이름을 참조하여 실행 중인 가상 머신 인스턴스의 실시간 마이그레이션을 시작합니다.
절차
마이그레이션할 가상 머신 인스턴스에 대한
VirtualMachineInstanceMigration
구성 파일을 생성합니다. 예를 들면vmi-migrate.yaml
은 다음과 같습니다.apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachineInstanceMigration metadata: name: migration-job spec: vmiName: vmi-fedora
다음 명령을 실행하여 클러스터에 오브젝트를 생성합니다.
$ oc create -f vmi-migrate.yaml
VirtualMachineInstanceMigration
오브젝트는 가상 머신 인스턴스의 실시간 마이그레이션을 트리거합니다. 이 오브젝트는 수동으로 삭제하지 않는 한 가상 머신 인스턴스가 실행되는 동안 클러스터에 존재합니다.
9.4. 가상 머신 인스턴스의 실시간 마이그레이션 모니터링
웹 콘솔 또는 CLI에서 가상 머신 인스턴스의 실시간 마이그레이션 진행 상태를 모니터링할 수 있습니다.
9.4.1. 웹 콘솔에서 가상 머신 인스턴스 실시간 마이그레이션 모니터링
마이그레이션 기간 동안 가상 머신의 상태는 마이그레이션 중입니다. 이 상태는 가상 머신 탭 또는 마이그레이션 중인 가상 머신의 가상 머신 개요 화면에 표시됩니다.
절차
- OpenShift Virtualization 콘솔의 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 가상 머신을 선택하여 가상 머신 개요 화면을 엽니다.
9.4.2. CLI에서 가상 머신 인스턴스 실시간 마이그레이션 모니터링
가상 머신 마이그레이션 상태는 VirtualMachineInstance
구성의 Status
구성 요소에 저장됩니다.
절차
마이그레이션 중인 가상 머신 인스턴스에
oc describe
명령을 사용합니다.$ oc describe vmi vmi-fedora
출력 예
... Status: Conditions: Last Probe Time: <nil> Last Transition Time: <nil> Status: True Type: LiveMigratable Migration Method: LiveMigration Migration State: Completed: true End Timestamp: 2018-12-24T06:19:42Z Migration UID: d78c8962-0743-11e9-a540-fa163e0c69f1 Source Node: node2.example.com Start Timestamp: 2018-12-24T06:19:35Z Target Node: node1.example.com Target Node Address: 10.9.0.18:43891 Target Node Domain Detected: true
9.5. 가상 머신 인스턴스의 실시간 마이그레이션 취소
가상 머신 인스턴스가 원래 노드에 남아 있도록 실시간 마이그레이션을 취소합니다.
웹 콘솔 또는 CLI에서 실시간 마이그레이션을 취소할 수 있습니다.
9.5.1. 웹 콘솔에서 가상 머신 인스턴스의 실시간 마이그레이션 취소
가상화 → 가상 머신 탭의 각 가상 머신에 있는 옵션 메뉴 를 사용하거나 가상 머신 개요 화면의 모든 탭에 있는 작업 메뉴에서 가상 머신 인스턴스의 실시간 마이그레이션을 취소할 수 있습니다.
절차
- OpenShift Virtualization 콘솔의 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
이 화면에서 마이그레이션을 취소하면 여러 가상 머신에 대한 작업을 더 쉽게 수행할 수 있습니다. 가상 머신 개요 화면에서 마이그레이션을 취소하면 선택한 가상 머신에 대한 포괄적인 세부 정보를 볼 수 있습니다.
- 가상 머신 끝에 있는 옵션 메뉴 를 클릭하고 가상 머신 마이그레이션 취소를 선택합니다.
- 가상 머신 이름을 선택하여 가상 머신 개요 화면을 열고 작업 → 가상 머신 마이그레이션 취소를 클릭합니다.
- 마이그레이션 취소를 클릭하여 가상 머신 실시간 마이그레이션을 취소합니다.
9.5.2. CLI에서 가상 머신 인스턴스 실시간 마이그레이션 취소
마이그레이션과 연결된 VirtualMachineInstanceMigration
오브젝트를 삭제하여 가상 머신 인스턴스의 실시간 마이그레이션을 취소합니다.
절차
이 예제에서 실시간 마이그레이션 작업인
migration-job
을 트리거한VirtualMachineInstanceMigration
오브젝트를 삭제합니다.$ oc delete vmim migration-job
9.6. 가상 머신 제거 전략 구성
LiveMigrate
제거 전략을 사용하면 노드가 유지보수 또는 드레인 모드에 배치되는 경우 가상 머신 인스턴스가 중단되지 않습니다. 이 제거 전략이 포함된 가상 머신 인스턴스는 다른 노드로 실시간 마이그레이션됩니다.
9.6.1. LiveMigration 제거 전략을 사용하여 사용자 정의 가상 머신 구성
사용자 정의 가상 머신에는 LiveMigration
제거 전략만 구성하면 됩니다. 공통 템플릿에는 이 제거 전략이 기본적으로 구성되어 있습니다.
절차
evictionStrategy를 추가합니다. LiveMigrate
옵션은 가상 머신 구성 파일의spec.template.spec
섹션에 있습니다. 이 예제에서는oc edit
를 사용하여VirtualMachine
구성 파일의 관련 스니펫을 업데이트합니다.$ oc edit vm <custom-vm> -n <my-namespace>
apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: name: custom-vm spec: template: spec: evictionStrategy: LiveMigrate ...
가상 머신을 재시작하여 업데이트를 적용합니다.
$ virtctl restart <custom-vm> -n <my-namespace>
10장. 노드 유지보수
10.1. TLS 인증서 자동 갱신
OpenShift Virtualization 구성 요소에 대한 모든 TLS 인증서는 자동으로 갱신되고 순환됩니다. 수동으로 새로 고치지 않아도 됩니다.
10.1.1. TLS 인증서 자동 갱신
TLS 인증서는 다음 일정에 따라 자동으로 삭제되고 교체됩니다.
- KubeVirt 인증서는 매일 갱신됩니다.
- CDI(Containerized Data Importer) 컨트롤러 인증서는 15일마다 갱신됩니다.
- MAC 풀 인증서는 매년 갱신됩니다.
자동 TLS 인증서 순환이 수행되어도 작업이 중단되지 않습니다. 예를 들면 다음 작업이 중단되지 않고 계속 수행됩니다.
- 마이그레이션
- 이미지 업로드
- VNC 및 콘솔 연결
10.2. 더 이상 사용되지 않는 CPU 모델에 대한 노드 라벨링 관리
VM(가상 머신)의 CPU 모델 및 정책 특성이 특정 노드에서 지원하는 CPU 모델 및 정책 특성과 호환되는 경우 해당 노드에서 VM을 스케줄링할 수 있습니다. 구성 맵에서 더 이상 사용되지 않는 CPU 모델 목록을 지정하면 CPU 모델에 대해 생성된 라벨 목록에서 해당 모델을 제외할 수 있습니다.
10.2.1. 더 이상 사용되지 않는 CPU 모델에 대한 노드 라벨링 이해
노드에서 스케줄링된 VM에 유효한 CPU 모델만 지원하도록 하려면 더 이상 사용되지 않는 CPU 모델 목록이 포함된 구성 맵을 생성합니다. node-labeller
는 더 이상 사용되지 않는 CPU 모델 목록을 가져올 때 해당 CPU 모델을 제거하고 유효한 CPU 모델에 대한 라벨을 생성합니다.
더 이상 사용되지 않는 CPU 모델 목록이 포함된 구성 맵을 구성하지 않으면 사용자 환경에 없는 더 이상 사용되지 않는 CPU 모델을 비롯하여 모든 CPU 모델이 라벨을 위해 평가됩니다.
반복 프로세스를 거치는 동안 최소 CPU 모델의 기본 CPU 기능 목록이 노드에 대해 생성되는 라벨 목록에서 제거됩니다. 예를 들어 환경에는 두 가지 CPU 모델이 지원될 수 있습니다. Penryn
과 Haswell
.
Penryn
이 minCPU
의 CPU 모델로 지정되면 node-labeller
는 Penryn
의 각 기본 CPU 기능을 평가하고 Haswell
에서 지원하는 각 CPU 기능과 비교합니다. Penryn
및 Haswell
모두에서 CPU 기능을 지원하면 node-labeller
는 CPU 기능 목록에서 해당 기능을 제거하고 라벨을 생성합니다. 특정 CPU 기능을 Haswell
에서만 지원하고 Penryn
에서는 지원하지 않는 경우에는 생성되는 라벨 목록에 해당 CPU 기능이 포함됩니다. node-labeller
는 이 반복 프로세스를 따라 최소 CPU 모델에 있는 기본 CPU 기능을 제거하고 라벨을 생성합니다.
다음 예제에서는 minCPU
의 CPU 모델로 지정된 Penryn
의 전체 CPU 기능 목록을 보여줍니다.
Penryn의 CPU 기능 예
apic clflush cmov cx16 cx8 de fpu fxsr lahf_lm lm mca mce mmx msr mtrr nx pae pat pge pni pse pse36 sep sse sse2 sse4.1 ssse3 syscall tsc
다음 예제에서는 Haswell
의 전체 CPU 기능 목록을 보여줍니다.
Haswell의 CPU 기능 예
aes apic avx avx2 bmi1 bmi2 clflush cmov cx16 cx8 de erms fma fpu fsgsbase fxsr hle invpcid lahf_lm lm mca mce mmx movbe msr mtrr nx pae pat pcid pclmuldq pge pni popcnt pse pse36 rdtscp rtm sep smep sse sse2 sse4.1 sse4.2 ssse3 syscall tsc tsc-deadline x2apic xsave
다음 예제에서는 Penryn
의 CPU 기능을 반복하고 Haswell
의 CPU 기능과 비교한 후 node-labeller
에서 생성한 노드 라벨 목록을 보여줍니다.
반복 후 노드 라벨의 예
aes avx avx2 bmi1 bmi2 erms fma fsgsbase hle invpcid movbe pcid pclmuldq popcnt rdtscp rtm sse4.2 tsc-deadline x2apic xsave
10.2.2. 더 이상 사용되지 않는 CPU 모델에 대한 구성 맵 구성
더 이상 사용되지 않는 CPU 모델에 대한 구성 맵을 구성하려면 이 절차를 사용하십시오.
절차
ConfigMap
오브젝트를 생성하여obsoleteCPUs
배열에 더 이상 사용되지 않는 CPU 모델을 지정합니다. 예를 들면 다음과 같습니다.apiVersion: v1 kind: ConfigMap metadata: name: cpu-plugin-configmap 1 data: 2 cpu-plugin-configmap: obsoleteCPUs: 3 - "486" - "pentium" - "pentium2" - "pentium3" - "pentiumpro" minCPU: "Penryn" 4
10.3. 노드 유지보수 모드
10.3.1. 노드 유지보수 모드 이해
노드를 유지보수 모드에 배치하면 노드가 스케줄링할 수 없는 것으로 표시되고 모든 가상 머신과 Pod가 드레인됩니다. LiveMigrate
제거 전략이 있는 가상 머신 인스턴스는 서비스 손실 없이 다른 노드로 실시간 마이그레이션됩니다. 이 제거 전략은 공통 템플릿으로 생성한 가상 머신에는 기본적으로 구성되지만 사용자 정의 가상 머신은 수동으로 구성해야 합니다.
제거 전략이 없는 가상 머신 인스턴스는 노드에서 삭제되고 다른 노드에서 다시 생성됩니다.
가상 머신에 실시간 마이그레이션할 공유 RWX(ReadWriteMany) 액세스 모드의 PVC(영구 볼륨 클레임)가 있어야 합니다.
추가 리소스:
10.4. 노드를 유지보수 모드로 설정
10.4.1. 노드 유지보수 모드 이해
노드를 유지보수 모드에 배치하면 노드가 스케줄링할 수 없는 것으로 표시되고 모든 가상 머신과 Pod가 드레인됩니다. LiveMigrate
제거 전략이 있는 가상 머신 인스턴스는 서비스 손실 없이 다른 노드로 실시간 마이그레이션됩니다. 이 제거 전략은 공통 템플릿으로 생성한 가상 머신에는 기본적으로 구성되지만 사용자 정의 가상 머신은 수동으로 구성해야 합니다.
제거 전략이 없는 가상 머신 인스턴스는 노드에서 삭제되고 다른 노드에서 다시 생성됩니다.
가상 머신에 실시간 마이그레이션할 공유 RWX(ReadWriteMany) 액세스 모드의 PVC(영구 볼륨 클레임)가 있어야 합니다.
웹 콘솔 또는 CLI에서 노드를 유지보수 모드에 배치합니다.
10.4.2. 웹 콘솔에서 노드를 유지보수 모드로 설정
컴퓨팅 → 노드 목록의 각 노드에 있는 옵션 메뉴 를 사용하거나 노드 세부 정보 화면의 작업 컨트롤을 사용하여 노드를 유지보수 모드로 설정합니다.
절차
- OpenShift Virtualization 콘솔에서 컴퓨팅 → 노드를 클릭합니다.
이 화면에서 노드를 유지보수 모드로 설정하면 한 화면에서 여러 노드에 대한 작업을 더 쉽게 수행할 수 있습니다. 노드 세부 정보 화면에서 노드를 유지보수 모드로 설정하면 선택한 노드에 대한 포괄적인 세부 정보를 볼 수 있습니다.
- 노드 끝에 있는 옵션 메뉴 를 클릭하고 유지보수 시작을 선택합니다.
- 노드 이름을 클릭하여 노드 세부 정보 화면을 열고 작업 → 유지보수 시작을 클릭합니다.
- 확인 창에서 유지보수 시작을 클릭합니다.
노드는 LiveMigration
제거 전략이 있는 가상 머신 인스턴스를 실시간 마이그레이션하고 더 이상 노드를 스케줄링할 수 없습니다. 노드의 기타 모든 Pod 및 가상 머신이 삭제되고 다른 노드에서 다시 생성됩니다.
10.4.3. CLI에서 노드를 유지보수 모드로 설정
노드 이름과 노드를 유지보수 모드로 설정하는 이유를 참조하는 NodeMaintenance
CR(사용자 정의 리소스) 오브젝트를 생성하여 노드를 유지보수 모드로 설정합니다.
프로세스
노드 유지보수 CR 구성을 생성합니다. 이 예제에서는
node02-maintenance.yaml
이라는 CR을 사용합니다.apiVersion: nodemaintenance.kubevirt.io/v1beta1 kind: NodeMaintenance metadata: name: node02-maintenance spec: nodeName: node02 reason: "Replacing node02"
클러스터에서
NodeMaintenance
오브젝트를 생성합니다.$ oc apply -f <node02-maintenance.yaml>
노드는 LiveMigration
제거 전략이 있는 가상 머신 인스턴스를 실시간 마이그레이션한 후 더 이상 스케줄링할 수 없도록 노드를 오염시킵니다. 노드의 기타 모든 Pod 및 가상 머신이 삭제되고 다른 노드에서 다시 생성됩니다.
추가 리소스:
10.5. 유지보수 모드에서 노드 재시작
노드를 재시작하면 노드가 유지보수 모드에서 해제되어 노드를 다시 스케줄링할 수 있습니다.
웹 콘솔 또는 CLI에서 노드를 유지보수 모드로 재시작합니다.
10.5.1. 웹 콘솔에서 유지보수 모드로 노드 재시작
컴퓨팅 → 노드 목록의 각 노드에 있는 옵션 메뉴 를 사용하거나 노드 세부 정보 화면의 작업 컨트롤을 사용하여 노드를 유지보수 모드로 재시작합니다.
절차
- OpenShift Virtualization 콘솔에서 컴퓨팅 → 노드를 클릭합니다.
이 화면에서 노드를 재시작하면 한 화면에서 여러 노드에 대한 작업을 더 쉽게 수행할 수 있습니다. 노드 세부 정보 화면에서 노드를 재시작하면 선택한 노드에 대한 포괄적인 세부 정보를 볼 수 있습니다.
- 노드 끝에 있는 옵션 메뉴 를 클릭하고 유지보수 중지를 선택합니다.
- 노드 이름을 클릭하여 노드 세부 정보 화면을 열고 작업 → 유지보수 중지를 클릭합니다.
- 확인 창에서 유지보수 중지를 클릭합니다.
노드는 스케줄링할 수 있지만 유지보수 전에 노드에서 실행 중이던 가상 머신 인스턴스는 이 노드에 자동으로 마이그레이션되지 않습니다.
10.5.2. CLI에서 유지보수 모드로 노드 재시작
유지보수 모드에서 노드를 재시작하고 노드의 NodeMaintenance
오브젝트를 삭제하여 다시 스케줄링할 수 있도록 만듭니다.
프로세스
NodeMaintenance
오브젝트를 찾습니다.$ oc get nodemaintenance
선택 사항:
NodeMaintenance
오브젝트가 올바른 노드와 연결되어 있는지 확인합니다.$ oc describe nodemaintenance <node02-maintenance>
출력 예
Name: node02-maintenance Namespace: Labels: Annotations: API Version: nodemaintenance.kubevirt.io/v1beta1 Kind: NodeMaintenance ... Spec: Node Name: node02 Reason: Replacing node02
NodeMaintenance
오브젝트를 삭제합니다.$ oc delete nodemaintenance <node02-maintenance>
11장. 노드 네트워킹
11.1. 노드 네트워크 상태 관찰
노드 네트워크 상태는 클러스터의 모든 노드에 대한 네트워크 구성입니다.
11.1.1. nmstate 정보
OpenShift Virtualization에서는 nmstate
를 사용하여 노드 네트워크의 상태를 보고하고 구성합니다. 이를 통해 단일 구성 매니페스트를 클러스터에 적용하여(예: 모든 노드에서 Linux 브리지 생성) 네트워크 정책 구성을 수정할 수 있습니다.
노드 네트워킹은 다음 오브젝트에서 모니터링하고 업데이트합니다.
NodeNetworkState
- 해당 노드의 네트워크 상태를 보고합니다.
NodeNetworkConfigurationPolicy
-
노드에서 요청된 네트워크 구성을 설명합니다.
NodeNetworkConfigurationPolicy
매니페스트를 클러스터에 적용하는 방식으로 인터페이스 추가 및 제거를 포함하여 노드 네트워크 구성을 업데이트합니다. NodeNetworkConfigurationEnactment
- 각 노드에 적용된 네트워크 정책을 보고합니다.
OpenShift Virtualization에서는 다음과 같은 nmstate 인터페이스 유형을 사용할 수 있습니다.
- Linux 브리지
- VLAN
- 본딩
- 이더넷
OpenShift Container Platform 클러스터에서 OVN-Kubernetes를 기본 CNI(Container Network Interface) 공급자로 사용하는 경우, OVN-Kubernetes의 호스트 네트워크 토폴로지 변경으로 인해 호스트의 기본 인터페이스에 Linux 브리지 또는 본딩을 연결할 수 없습니다. 해결 방법으로 호스트에 연결된 보조 네트워크 인터페이스를 사용하거나 OpenShift SDN 기본 CNI 공급자로 전환할 수 있습니다.
11.1.2. 노드의 네트워크 상태 보기
NodeNetworkState
오브젝트는 클러스터의 모든 노드에 존재합니다. 이 오브젝트는 주기적으로 업데이트되며 해당 노드의 네트워크 상태를 캡처합니다.
절차
클러스터의 모든
NodeNetworkState
오브젝트를 나열합니다.$ oc get nns
NodeNetworkState
오브젝트를 검사하여 해당 노드의 네트워크를 확인합니다. 이 예제의 출력은 명확성을 위해 수정되었습니다.$ oc get nns node01 -o yaml
출력 예
apiVersion: nmstate.io/v1alpha1 kind: NodeNetworkState metadata: name: node01 1 status: currentState: 2 dns-resolver: ... interfaces: ... route-rules: ... routes: ... lastSuccessfulUpdateTime: "2020-01-31T12:14:00Z" 3
11.2. 노드 네트워크 구성 업데이트
NodeNetworkConfigurationPolicy
매니페스트를 클러스터에 적용하여 노드 네트워크 구성을 업데이트(예: 노드에서 인터페이스 추가 또는 제거)할 수 있습니다.
11.2.1. nmstate 정보
OpenShift Virtualization에서는 nmstate
를 사용하여 노드 네트워크의 상태를 보고하고 구성합니다. 이를 통해 단일 구성 매니페스트를 클러스터에 적용하여(예: 모든 노드에서 Linux 브리지 생성) 네트워크 정책 구성을 수정할 수 있습니다.
노드 네트워킹은 다음 오브젝트에서 모니터링하고 업데이트합니다.
NodeNetworkState
- 해당 노드의 네트워크 상태를 보고합니다.
NodeNetworkConfigurationPolicy
-
노드에서 요청된 네트워크 구성을 설명합니다.
NodeNetworkConfigurationPolicy
매니페스트를 클러스터에 적용하는 방식으로 인터페이스 추가 및 제거를 포함하여 노드 네트워크 구성을 업데이트합니다. NodeNetworkConfigurationEnactment
- 각 노드에 적용된 네트워크 정책을 보고합니다.
OpenShift Virtualization에서는 다음과 같은 nmstate 인터페이스 유형을 사용할 수 있습니다.
- Linux 브리지
- VLAN
- 본딩
- 이더넷
OpenShift Container Platform 클러스터에서 OVN-Kubernetes를 기본 CNI(Container Network Interface) 공급자로 사용하는 경우, OVN-Kubernetes의 호스트 네트워크 토폴로지 변경으로 인해 호스트의 기본 인터페이스에 Linux 브리지 또는 본딩을 연결할 수 없습니다. 해결 방법으로 호스트에 연결된 보조 네트워크 인터페이스를 사용하거나 OpenShift SDN 기본 CNI 공급자로 전환할 수 있습니다.
11.2.2. 노드에서 인터페이스 만들기
NodeNetworkConfigurationPolicy
매니페스트를 클러스터에 적용하여 클러스터의 노드에서 인터페이스를 만듭니다. 매니페스트는 요청된 인터페이스 구성을 자세히 설명합니다.
기본적으로 매니페스트는 클러스터의 모든 노드에 적용됩니다. 특정 노드에 인터페이스를 추가하려면 spec: nodeSelector
매개변수와 노드 선택기에 적합한 <key>:<value>
를 추가합니다.
절차
NodeNetworkConfigurationPolicy
매니페스트를 생성합니다. 다음 예제에서는 모든 작업자 노드에서 Linux 브리지를 구성합니다.apiVersion: nmstate.io/v1alpha1 kind: NodeNetworkConfigurationPolicy metadata: name: <br1-eth1-policy> 1 spec: nodeSelector: 2 node-role.kubernetes.io/worker: "" 3 desiredState: interfaces: - name: br1 description: Linux bridge with eth1 as a port 4 type: linux-bridge state: up ipv4: dhcp: true enabled: true bridge: options: stp: enabled: false port: - name: eth1
노드 네트워크 정책을 생성합니다.
$ oc apply -f <br1-eth1-policy.yaml> 1
- 1
- 노드 네트워크 구성 정책 매니페스트의 파일 이름입니다.
추가 리소스
11.2.3. 노드에 노드 네트워크 정책 업데이트 확인
NodeNetworkConfigurationPolicy
매니페스트는 클러스터의 노드에 대해 요청된 네트워크 구성을 설명합니다. 노드 네트워크 정책에는 요청된 네트워크 구성과 클러스터 전체에 대한 정책 실행 상태가 포함됩니다.
노드 네트워크 정책을 적용하면 클러스터의 모든 노드에 대해 NodeNetworkConfigurationEnactment
오브젝트가 생성됩니다. 노드 네트워크 구성 시행은 해당 노드에서 정책의 실행 상태를 나타내는 읽기 전용 오브젝트입니다. 정책이 노드에 적용되지 않으면 문제 해결을 위해 해당 노드에 대한 시행에 역추적이 포함됩니다.
절차
정책이 클러스터에 적용되었는지 확인하려면 정책과 해당 상태를 나열합니다.
$ oc get nncp
선택 사항: 정책을 구성하는 데 예상보다 오래 걸리는 경우 특정 정책의 요청된 상태 및 상태 조건을 검사할 수 있습니다.
$ oc get nncp <policy> -o yaml
선택 사항: 모든 노드에서 정책을 구성하는 데 예상보다 오래 걸리는 경우 클러스터의 시행 상태를 나열할 수 있습니다.
$ oc get nnce
선택 사항: 실패한 구성에 대한 오류 보고를 포함하여 특정 시행의 구성을 보려면 다음을 수행합니다.
$ oc get nnce <node>.<policy> -o yaml
11.2.4. 노드에서 인터페이스 제거
NodeNetworkConfigurationPolicy
오브젝트를 편집하고 인터페이스의 state
를 없음
으로 설정하여 클러스터의 1개 이상의 노드에서 인터페이스를 제거할 수 있습니다.
노드에서 인터페이스를 제거해도 노드 네트워크 구성이 이전 상태로 자동 복원되지 않습니다. 이전 상태를 복원하려면 정책에서 노드 네트워크 구성을 정의해야 합니다.
브리지 또는 본딩 인터페이스를 제거하면 이전에 해당 브릿지 또는 본딩 인터페이스에 연결되었거나 종속되었던 클러스터의 모든 노드 NIC가 down
상태가 되어 연결할 수 없습니다. 연결 손실을 방지하기 위해, 노드 NIC를 동일한 정책으로 구성하여 DHCP 또는 고정 IP 주소의 상태를 up
으로 구성합니다.
인터페이스를 추가한 노드 네트워크 정책을 삭제해도 노드의 정책 구성은 변경되지 않습니다. NodeNetworkConfigurationPolicy
는 클러스터의 오브젝트이지만 요청된 구성만 나타냅니다.
마찬가지로 인터페이스를 제거해도 정책은 삭제되지 않습니다.
절차
인터페이스를 생성하는 데 사용되는
NodeNetworkConfigurationPolicy
매니페스트를 업데이트합니다. 다음 예에서는 Linux 브릿지를 제거한 후 연결이 손실되지 않도록 DHCP로eth1
NIC를 구성합니다.apiVersion: nmstate.io/v1alpha1 kind: NodeNetworkConfigurationPolicy metadata: name: <br1-eth1-policy> 1 spec: nodeSelector: 2 node-role.kubernetes.io/worker: "" 3 desiredState: interfaces: - name: br1 type: linux-bridge state: absent 4 - name: eth1 5 type: ethernet 6 state: up 7 ipv4: dhcp: true 8 enabled: true 9
- 1
- 정책 이름입니다.
- 2
- 선택 사항:
nodeSelector
매개변수를 포함하지 않으면 정책이 클러스터의 모든 노드에 적용됩니다. - 3
- 이 예제에서는
node-role.kubernetes.io/worker: ""
노드 선택기를 사용하여 클러스터의 모든 작업자 노드를 선택합니다. - 4
absent
상태로 변경하면 인터페이스가 제거됩니다.- 5
- 브리지 인터페이스에서 연결을 해제할 인터페이스의 이름입니다.
- 6
- 인터페이스 유형입니다. 이 예제에서는 이더넷 네트워킹 인터페이스를 생성합니다.
- 7
- 인터페이스에 요청되는 상태입니다.
- 8
- 선택 사항:
dhcp
를 사용하지 않는 경우 고정 IP를 설정하거나 IP 주소 없이 인터페이스를 종료할 수 있습니다. - 9
- 이 예제에서
ipv4
를 활성화합니다.
노드에서 정책을 업데이트하고 인터페이스를 제거합니다.
$ oc apply -f <br1-eth1-policy.yaml> 1
- 1
- 정책 매니페스트의 파일 이름입니다.
11.2.5. 다양한 인터페이스에 대한 예제 정책 구성
11.2.5.1. 예제: Linux 브리지 인터페이스 노드 네트워크 구성 정책
NodeNetworkConfigurationPolicy
매니페스트를 클러스터에 적용하여 클러스터의 노드에서 Linux 브리지 인터페이스를 만듭니다.
다음 YAML 파일은 Linux 브리지 인터페이스의 매니페스트 예제입니다. 여기에는 해당 정보로 교체해야 하는 샘플 값이 포함되어 있습니다.
apiVersion: nmstate.io/v1alpha1 kind: NodeNetworkConfigurationPolicy metadata: name: br1-eth1-policy 1 spec: nodeSelector: 2 kubernetes.io/hostname: <node01> 3 desiredState: interfaces: - name: br1 4 description: Linux bridge with eth1 as a port 5 type: linux-bridge 6 state: up 7 ipv4: dhcp: true 8 enabled: true 9 bridge: options: stp: enabled: false 10 port: - name: eth1 11
- 1
- 정책 이름입니다.
- 2
- 선택 사항:
nodeSelector
매개변수를 포함하지 않으면 정책이 클러스터의 모든 노드에 적용됩니다. - 3
- 이 예제에서는
hostname
노드 선택기를 사용합니다. - 4
- 인터페이스 이름입니다.
- 5
- 선택 사항: 사람이 읽을 수 있는 인터페이스 설명입니다.
- 6
- 인터페이스 유형입니다. 이 예제에서는 브리지를 만듭니다.
- 7
- 생성 후 인터페이스에 요청되는 상태입니다.
- 8
- 선택 사항:
dhcp
를 사용하지 않는 경우 고정 IP를 설정하거나 IP 주소 없이 인터페이스를 종료할 수 있습니다. - 9
- 이 예제에서
ipv4
를 활성화합니다. - 10
- 이 예제에서
stp
를 비활성화합니다. - 11
- 브리지가 연결되는 노드 NIC입니다.
11.2.5.2. 예제: VLAN 인터페이스 노드 네트워크 구성 정책
NodeNetworkConfigurationPolicy
매니페스트를 클러스터에 적용하여 클러스터의 노드에서 VLAN 인터페이스를 만듭니다.
다음 YAML 파일은 VLAN 인터페이스의 매니페스트 예제입니다. 여기에는 해당 정보로 교체해야 하는 샘플 값이 포함되어 있습니다.
apiVersion: nmstate.io/v1alpha1 kind: NodeNetworkConfigurationPolicy metadata: name: vlan-eth1-policy 1 spec: nodeSelector: 2 kubernetes.io/hostname: <node01> 3 desiredState: interfaces: - name: eth1.102 4 description: VLAN using eth1 5 type: vlan 6 state: up 7 vlan: base-iface: eth1 8 id: 102 9
11.2.5.3. 예제: 본딩 인터페이스 노드 네트워크 구성 정책
NodeNetworkConfigurationPolicy
매니페스트를 클러스터에 적용하여 클러스터의 노드에서 본딩 인터페이스를 만듭니다.
OpenShift Virtualization에서는 다음 본딩 모드만 지원합니다.
-
mode=1 active-backup
-
mode=2 balance-xor
-
mode=4 802.3ad
-
mode=5 balance-tlb
- mode=6 balance-alb
다음 YAML 파일은 본딩 인터페이스의 매니페스트 예제입니다. 여기에는 해당 정보로 교체해야 하는 샘플 값이 포함되어 있습니다.
apiVersion: nmstate.io/v1alpha1 kind: NodeNetworkConfigurationPolicy metadata: name: bond0-eth1-eth2-policy 1 spec: nodeSelector: 2 kubernetes.io/hostname: <node01> 3 desiredState: interfaces: - name: bond0 4 description: Bond enslaving eth1 and eth2 5 type: bond 6 state: up 7 ipv4: dhcp: true 8 enabled: true 9 link-aggregation: mode: active-backup 10 options: miimon: '140' 11 slaves: 12 - eth1 - eth2 mtu: 1450 13
- 1
- 정책 이름입니다.
- 2
- 선택 사항:
nodeSelector
매개변수를 포함하지 않으면 정책이 클러스터의 모든 노드에 적용됩니다. - 3
- 이 예제에서는
hostname
노드 선택기를 사용합니다. - 4
- 인터페이스 이름입니다.
- 5
- 선택 사항: 사람이 읽을 수 있는 인터페이스 설명입니다.
- 6
- 인터페이스 유형입니다. 이 예제에서는 본딩을 생성합니다.
- 7
- 생성 후 인터페이스에 요청되는 상태입니다.
- 8
- 선택 사항:
dhcp
를 사용하지 않는 경우 고정 IP를 설정하거나 IP 주소 없이 인터페이스를 종료할 수 있습니다. - 9
- 이 예제에서
ipv4
를 활성화합니다. - 10
- 본딩의 드라이버 모드입니다. 이 예제에서는 활성 백업 모드를 사용합니다.
- 11
- 선택 사항: 이 예에서는 miimon을 사용하여 140ms마다 본딩 링크를 검사합니다.
- 12
- 본딩의 하위 노드 NIC입니다.
- 13
- 선택 사항: 본딩의 최대 전송 단위(MTU). 지정하지 않는 경우 이 값은 기본적으로
1500
으로 설정됩니다.
11.2.5.4. 예제: 이더넷 인터페이스 노드 네트워크 구성 정책
NodeNetworkConfigurationPolicy
매니페스트를 클러스터에 적용하여 클러스터의 노드에서 이더넷 인터페이스를 구성합니다.
다음 YAML 파일은 이더넷 인터페이스의 매니페스트 예제입니다. 여기에는 해당 정보로 교체해야 하는 샘플 값이 포함되어 있습니다.
apiVersion: nmstate.io/v1alpha1 kind: NodeNetworkConfigurationPolicy metadata: name: eth1-policy 1 spec: nodeSelector: 2 kubernetes.io/hostname: <node01> 3 desiredState: interfaces: - name: eth1 4 description: Configuring eth1 on node01 5 type: ethernet 6 state: up 7 ipv4: dhcp: true 8 enabled: true 9
- 1
- 정책 이름입니다.
- 2
- 선택 사항:
nodeSelector
매개변수를 포함하지 않으면 정책이 클러스터의 모든 노드에 적용됩니다. - 3
- 이 예제에서는
hostname
노드 선택기를 사용합니다. - 4
- 인터페이스 이름입니다.
- 5
- 선택 사항: 사람이 읽을 수 있는 인터페이스 설명입니다.
- 6
- 인터페이스 유형입니다. 이 예제에서는 이더넷 네트워킹 인터페이스를 생성합니다.
- 7
- 생성 후 인터페이스에 요청되는 상태입니다.
- 8
- 선택 사항:
dhcp
를 사용하지 않는 경우 고정 IP를 설정하거나 IP 주소 없이 인터페이스를 종료할 수 있습니다. - 9
- 이 예제에서
ipv4
를 활성화합니다.
11.2.5.5. 예제: 동일한 노드 네트워크 구성 정책의 여러 인터페이스
동일한 노드 네트워크 구성 정책으로 여러 개의 인터페이스를 생성할 수 있습니다. 이러한 인터페이스는 서로를 참조할 수 있으므로 단일 정책 매니페스트를 사용하여 네트워크 구성을 빌드하고 배포할 수 있습니다.
다음 예제 스니펫에서는 두 NIC에 걸친 bond10
이라는 본딩과 이 본딩에 연결되는 br1
이라는 Linux 브리지를 생성합니다.
... interfaces: - name: bond10 description: Bonding eth2 and eth3 for Linux bridge type: bond state: up link-aggregation: slaves: - eth2 - eth3 - name: br1 description: Linux bridge on bond type: linux-bridge state: up bridge: port: - name: bond10 ...
11.2.6. 예: IP 관리
다음 예제 구성 스니펫에서는 다양한 IP 관리 방법을 보여줍니다.
이 예제에서는 ethernet
인터페이스 유형을 사용하여 예제를 단순화하면서 정책 구성에 관련 컨텍스트를 표시합니다. 이러한 IP 관리 예제는 다른 인터페이스 유형과 함께 사용할 수 있습니다.
11.2.6.1. 고정
다음 스니펫은 이더넷 인터페이스에서 IP 주소를 정적으로 구성합니다.
...
interfaces:
- name: eth1
description: static IP on eth1
type: ethernet
state: up
ipv4:
address:
- ip: 192.168.122.250 1
prefix-length: 24
enabled: true
...
- 1
- 이 값을 인터페이스의 고정 IP 주소로 교체합니다.
11.2.6.2. IP 주소 없음
다음 스니펫에서는 인터페이스에 IP 주소가 없습니다.
... interfaces: - name: eth1 description: No IP on eth1 type: ethernet state: up ipv4: enabled: false ...
11.2.6.3. 동적 호스트 구성
다음 스니펫에서는 동적 IP 주소, 게이트웨이 주소, DNS를 사용하는 이더넷 인터페이스를 구성합니다.
... interfaces: - name: eth1 description: DHCP on eth1 type: ethernet state: up ipv4: dhcp: true enabled: true ...
다음 스니펫에서는 동적 IP 주소를 사용하지만 동적 게이트웨이 주소 또는 DNS를 사용하지 않는 이더넷 인터페이스를 구성합니다.
... interfaces: - name: eth1 description: DHCP without gateway or DNS on eth1 type: ethernet state: up ipv4: dhcp: true auto-gateway: false auto-dns: false enabled: true ...
11.2.6.4. DNS
다음 스니펫에서는 호스트에 DNS 구성을 설정합니다.
... interfaces: ... dns-resolver: config: search: - example.com - example.org server: - 8.8.8.8 ...
11.2.6.5. 고정 라우팅
다음 스니펫에서는 eth1
인터페이스에 고정 경로와 고정 IP를 구성합니다.
... interfaces: - name: eth1 description: Static routing on eth1 type: ethernet state: up ipv4: address: - ip: 192.0.2.251 1 prefix-length: 24 enabled: true routes: config: - destination: 198.51.100.0/24 metric: 150 next-hop-address: 192.0.2.1 2 next-hop-interface: eth1 table-id: 254 ...
11.3. 노드 네트워크 구성 문제 해결
노드 네트워크 구성에 문제가 발생하면 정책이 자동으로 롤백되고 시행이 실패로 보고됩니다. 여기에는 다음과 같은 문제가 포함됩니다.
- 호스트에 구성을 적용하지 못했습니다.
- 호스트와 기본 게이트웨이의 연결이 끊어졌습니다.
- 호스트와 API 서버의 연결이 끊어졌습니다.
11.3.1. 잘못된 노드 네트워크 구성 정책의 구성 문제 해결
노드 네트워크 구성 정책을 적용하여 전체 클러스터에 노드 네트워크 구성 변경 사항을 적용할 수 있습니다. 잘못된 구성을 적용하는 경우 다음 예제를 사용하여 실패한 노드 네트워크 정책의 문제를 해결하고 수정할 수 있습니다.
이 예제에서는 마스터 노드와 작업자 노드가 각각 3개씩 있는 예제 클러스터에 Linux 브리지 정책을 적용합니다. 이 정책은 잘못된 인터페이스를 참조하므로 적용되지 않습니다. 오류를 찾기 위해 사용 가능한 nmstate 리소스를 조사합니다. 그런 다음 올바른 구성으로 정책을 업데이트할 수 있습니다.
절차
정책을 생성하여 클러스터에 적용합니다. 다음 예제에서는
ens01
인터페이스에서 간단한 브리지를 생성합니다.apiVersion: nmstate.io/v1alpha1 kind: NodeNetworkConfigurationPolicy metadata: name: ens01-bridge-testfail spec: desiredState: interfaces: - name: br1 description: Linux bridge with the wrong port type: linux-bridge state: up ipv4: dhcp: true enabled: true bridge: options: stp: enabled: false port: - name: ens01
$ oc apply -f ens01-bridge-testfail.yaml
출력 예
nodenetworkconfigurationpolicy.nmstate.io/ens01-bridge-testfail created
다음 명령을 실행하여 정책의 상태를 확인합니다.
$ oc get nncp
출력에 정책이 실패했다는 내용이 표시됩니다.
출력 예
NAME STATUS ens01-bridge-testfail FailedToConfigure
그러나 정책 상태만으로는 모든 노드에서 실패했는지 노드 서브 세트에서 실패했는지 알 수 없습니다.
노드 네트워크 구성 시행을 나열하여 정책이 모든 노드에서 성공적인지 확인합니다. 정책이 노드 서브 세트에서만 실패한 경우 특정 노드 구성에 문제가 있음을 나타냅니다. 정책이 모든 노드에서 실패하면 정책에 문제가 있음을 나타냅니다.
$ oc get nnce
출력에 정책이 모든 노드에서 실패했다는 내용이 표시됩니다.
출력 예
NAME STATUS master-1.ens01-bridge-testfail FailedToConfigure master-2.ens01-bridge-testfail FailedToConfigure master-3.ens01-bridge-testfail FailedToConfigure worker-1.ens01-bridge-testfail FailedToConfigure worker-2.ens01-bridge-testfail FailedToConfigure worker-3.ens01-bridge-testfail FailedToConfigure
실패한 시행 중 하나에서 역추적을 살펴봅니다. 다음 명령은 출력 툴
jsonpath
를 사용하여 출력을 필터링합니다.$ oc get nnce worker-1.ens01-bridge-testfail -o jsonpath='{.status.conditions[?(@.type=="Failing")].message}'
이 명령은 간결하게 편집된 대규모 역추적 정보를 반환합니다.
출력 예
error reconciling NodeNetworkConfigurationPolicy at desired state apply: , failed to execute nmstatectl set --no-commit --timeout 480: 'exit status 1' '' ... libnmstate.error.NmstateVerificationError: desired ======= --- name: br1 type: linux-bridge state: up bridge: options: group-forward-mask: 0 mac-ageing-time: 300 multicast-snooping: true stp: enabled: false forward-delay: 15 hello-time: 2 max-age: 20 priority: 32768 port: - name: ens01 description: Linux bridge with the wrong port ipv4: address: [] auto-dns: true auto-gateway: true auto-routes: true dhcp: true enabled: true ipv6: enabled: false mac-address: 01-23-45-67-89-AB mtu: 1500 current ======= --- name: br1 type: linux-bridge state: up bridge: options: group-forward-mask: 0 mac-ageing-time: 300 multicast-snooping: true stp: enabled: false forward-delay: 15 hello-time: 2 max-age: 20 priority: 32768 port: [] description: Linux bridge with the wrong port ipv4: address: [] auto-dns: true auto-gateway: true auto-routes: true dhcp: true enabled: true ipv6: enabled: false mac-address: 01-23-45-67-89-AB mtu: 1500 difference ========== --- desired +++ current @@ -13,8 +13,7 @@ hello-time: 2 max-age: 20 priority: 32768 - port: - - name: ens01 + port: [] description: Linux bridge with the wrong port ipv4: address: [] line 651, in _assert_interfaces_equal\n current_state.interfaces[ifname],\nlibnmstate.error.NmstateVerificationError:
NmstateVerificationError
는desired
정책 구성, 노드에 있는 정책의current
구성, 일치하지 않는 매개변수를 강조하는difference
를 나열합니다. 이 예에서port
는difference
에 포함되어 있으며, 이는 정책의 포트 구성이 문제임을 나타냅니다.정책이 제대로 구성되었는지 확인하기 위해
NodeNetworkState
오브젝트를 요청하여 하나 또는 모든 노드의 네트워크 구성을 확인합니다. 다음 명령에서는master-1
노드의 네트워크 구성을 반환합니다.$ oc get nns master-1 -o yaml
출력에 노드의 인터페이스 이름이
ens1
인데 실패한 정책에서ens01
로 잘못 사용하고 있다는 내용이 표시됩니다.출력 예
- ipv4: ... name: ens1 state: up type: ethernet
기존 정책을 편집하여 오류를 수정합니다.
$ oc edit nncp ens01-bridge-testfail
... port: - name: ens1
정책을 저장하여 수정 사항을 적용합니다.
정책 상태를 확인하여 업데이트가 완료되었는지 확인합니다.
$ oc get nncp
출력 예
NAME STATUS ens01-bridge-testfail SuccessfullyConfigured
업데이트된 정책이 클러스터의 모든 노드에 성공적으로 구성되었습니다.
12장. 로깅, 이벤트, 모니터링
12.1. 가상 머신 로그 보기
12.1.1. 가상 머신 로그 이해
로그는 OpenShift Container Platform 빌드, 배포, Pod와 관련하여 수집됩니다. OpenShift Virtualization에서는 웹 콘솔 또는 CLI의 가상 머신 시작 관리자 Pod에서 가상 머신 로그를 검색할 수 있습니다.
-f
옵션은 로그 출력을 실시간으로 추적하므로 진행률을 모니터링하고 오류를 점검하는 데 유용합니다.
시작 관리자 Pod가 시작되지 않으면 --previous
옵션을 사용하여 마지막 시도의 로그를 확인하십시오.
ErrImagePull
및 ImagePullBackOff
오류는 잘못된 배포 구성이나 참조하는 이미지 문제로 인해 발생할 수 있습니다.
12.1.2. CLI에서 가상 머신 로그 보기
가상 머신 시작 관리자 Pod에서 가상 머신 로그를 가져옵니다.
절차
다음 명령을 사용합니다.
$ oc logs <virt-launcher-name>
12.1.3. 웹 콘솔에서 가상 머신 로그 보기
연결된 가상 머신 시작 관리자 Pod에서 가상 머신 로그를 가져옵니다.
절차
- OpenShift Virtualization 콘솔의 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 가상 머신을 선택하여 가상 머신 개요 화면을 엽니다.
-
세부 정보 탭의 Pod 섹션에서
virt-launcher-<name>
Pod를 클릭합니다. - 로그를 클릭합니다.
12.2. 이벤트 보기
12.2.1. 가상 머신 이벤트 이해
OpenShift Container Platform 이벤트는 네임스페이스에 있는 중요 라이프사이클 정보로 이루어진 레코드이며, 리소스 스케줄링, 생성, 삭제와 관련된 문제를 모니터링하고 해결하는 데 유용합니다.
OpenShift Virtualization에서는 가상 머신 및 가상 머신 인스턴스에 대한 이벤트를 추가합니다. 해당 이벤트는 웹 콘솔이나 CLI에서 볼 수 있습니다.
또한 다음을 참조하십시오. OpenShift Container Platform 클러스터에서 시스템 이벤트 정보 보기.
12.2.2. 웹 콘솔에서 가상 머신 이벤트 보기
웹 콘솔의 가상 머신 개요 패널에서 실행 중인 가상 머신에 대한 스트림 이벤트를 볼 수 있습니다.
▮▮ 버튼을 누르면 이벤트 스트림이 일시 중지됩니다.
▶ 버튼은 누르면 일시 정지된 이벤트 스트림이 계속됩니다.
절차
- 사이드 메뉴에서 워크로드 → 가상화를 클릭합니다.
- 가상 머신 탭을 클릭합니다.
- 가상 머신을 선택하여 가상 머신 개요 화면을 엽니다.
- 가상 머신의 모든 이벤트를 보려면 이벤트를 클릭합니다.
12.2.3. CLI에서 네임스페이스 이벤트 보기
OpenShift Container Platform 클라이언트를 사용하여 네임스페이스에 대한 이벤트를 가져옵니다.
절차
네임스페이스에서
oc get
명령을 사용합니다.$ oc get events
12.2.4. CLI에서 리소스 이벤트 보기
이벤트는 리소스 설명에 포함되어 있으며 OpenShift Container Platform 클라이언트를 사용하여 가져올 수 있습니다.
절차
네임스페이스에서
oc describe
명령을 사용합니다. 다음 예제에서는 가상 머신, 가상 머신 인스턴스, 가상 머신에 대한 virt-launcher Pod에 대한 이벤트를 가져오는 방법을 보여줍니다.$ oc describe vm <vm>
$ oc describe vmi <vmi>
$ oc describe pod virt-launcher-<name>
12.3. 이벤트 및 조건을 사용하여 데이터 볼륨 진단
oc describe
명령을 사용하여 데이터 볼륨 문제를 분석하고 해결합니다.
12.3.1. 조건 및 이벤트 정보
다음 명령으로 생성된 Conditions
및 Events
섹션의 출력을 검사하여 데이터 볼륨 문제를 진단합니다.
$ oc describe dv <DataVolume>
표시되는 Conditions
섹션에는 세 가지 Types
이 있습니다.
-
Bound
-
Running
-
Ready
Events
섹션에서는 다음과 같은 추가 정보를 제공합니다.
-
이벤트
Type
-
로깅
Reason
-
이벤트
Source
-
추가 진단 정보가 포함된
Message
oc describe
의 출력에 항상 Events
가 포함되는 것은 아닙니다.
Status
, Reason
또는 Message
가 변경되면 이벤트가 생성됩니다. 조건과 이벤트는 모두 데이터 볼륨의 상태 변화에 반응합니다.
예를 들어 가져오기 작업 중에 URL을 잘못 입력하면 가져오기 작업에서 404 메시지를 생성합니다. 이러한 메시지 변경으로 인해 원인이 포함된 이벤트가 생성됩니다. Conditions
섹션의 출력도 업데이트됩니다.
12.3.2. 조건 및 이벤트를 사용하여 데이터 볼륨 분석
describe
명령으로 생성된 Conditions
및 Events
섹션을 검사하여 PVC(영구 볼륨 클레임)와 관련된 데이터 볼륨 상태 및 작업이 활발하게 실행되고 있거나 완료되었는지의 여부를 확인합니다. 데이터 볼륨의 상태와 어떻게 해서 현재 상태가 되었는지에 대한 구체적인 정보를 제공하는 메시지가 표시될 수도 있습니다.
조건은 다양한 형태로 조합될 수 있습니다. 각각 고유의 컨텍스트에서 평가해야 합니다.
다음은 다양한 조합의 예입니다.
Bound
– 이 예제에는 성공적으로 바인딩된 PVC가 표시됩니다.Type
은Bound
이므로Status
가True
입니다. PVC가 바인딩되지 않은 경우Status
는False
입니다.PVC가 바인딩되면 PVC가 바인딩되었음을 알리는 이벤트가 생성됩니다. 이 경우
Reason
은Bound
이고Status
는True
입니다.Message
는 데이터 볼륨이 속한 PVC를 나타냅니다.Events
섹션의Message
에서는 PVC가 바인딩된 기간(Age
) 및 리소스(From
)(이 경우datavolume-controller
)를 포함한 추가 세부 정보를 제공합니다.출력 예
Status: Conditions: Last Heart Beat Time: 2020-07-15T03:58:24Z Last Transition Time: 2020-07-15T03:58:24Z Message: PVC win10-rootdisk Bound Reason: Bound Status: True Type: Bound Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Bound 24s datavolume-controller PVC example-dv Bound
Running
– 이 경우Type
은Running
이고Status
는False
입니다. 이는 시도한 작업을 실패하게 만드는 이벤트가 발생하여 상태가True
에서False
로 변경되었음을 나타냅니다.그러나
Reason
이Completed
이고Message
필드에Import Complete
라고 표시됩니다.Events
섹션의Reason
및Message
에는 실패한 작업에 대한 추가 문제 해결 정보가 포함되어 있습니다. 이 예제에서는Message
에Events
섹션의 첫 번째Warning
에 나열된404
로 인해 연결할 수 없다는 내용이 표시됩니다.이러한 정보를 통해 가져오기 작업이 실행 중이며 데이터 볼륨에 액세스하려는 다른 작업에 대한 경합이 발생한다는 것을 알 수 있습니다.
출력 예
Status: Conditions: Last Heart Beat Time: 2020-07-15T04:31:39Z Last Transition Time: 2020-07-15T04:31:39Z Message: Import Complete Reason: Completed Status: False Type: Running Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Error 12s (x2 over 14s) datavolume-controller Unable to connect to http data source: expected status code 200, got 404. Status: 404 Not Found
Ready
–Type
이Ready
이고Status
가True
이면 다음 예제와 같이 데이터 볼륨을 사용할 준비가 된 것입니다. 데이터 볼륨을 사용할 준비가 되지 않은 경우에는Status
가False
입니다.출력 예
Status: Conditions: Last Heart Beat Time: 2020-07-15T04:31:39Z Last Transition Time: 2020-07-15T04:31:39Z Status: True Type: Ready
12.4. 가상 머신 워크로드에 대한 정보 보기
OpenShift Container Platform 웹 콘솔의 가상 머신 대시보드를 사용하여 가상 머신에 대한 개괄적인 정보를 볼 수 있습니다.
12.4.1. 가상 머신 대시보드 정보
워크로드 → 가상화 페이지로 이동하여 OpenShift Container Platform 웹 콘솔에서 가상 머신에 액세스합니다. 워크로드 → 가상화 페이지에는 두 개의 탭이 있습니다.
- 가상 머신
- 가상 머신 템플릿
다음 카드에서는 각 가상 머신을 설명합니다.
세부 정보에는 다음을 포함하여 가상 머신에 대한 식별 정보가 있습니다.
- 이름
- 네임스페이스
- 작성일
- 노드 이름
- IP 주소
인벤토리에는 다음을 포함하여 가상 머신의 리소스가 나열됩니다.
- NIC(네트워크 인터페이스 컨트롤러)
- 디스크
상태에는 다음이 포함됩니다.
- 가상 머신의 현재 상태
- QEMU 게스트 에이전트가 가상 머신에 설치되어 있는지를 표시하는 참고 사항
사용률에는 다음에 대한 사용 데이터가 표시되는 차트가 포함됩니다.
- CPU
- 메모리
- 파일 시스템
- 네트워크 전송
드롭다운 목록을 사용하여 사용률 데이터의 기간을 선택합니다. 사용 가능한 옵션은 1시간, 6시간, 24시간입니다.
- 이벤트에는 지난 1시간 동안의 가상 머신 활동에 대한 메시지가 나열됩니다. 추가 이벤트를 보려면 모두 보기를 클릭합니다.
12.5. 가상 머신 상태 모니터링
VMI(가상 머신 인스턴스)는 연결 해제, 교착 상태 또는 외부 종속성 문제와 같은 일시적인 문제로 인해 VMI가 비정상 상태가 될 수 있습니다. 상태 점검은 준비 및 활성 프로브의 조합을 사용하여 VMI에서 정기적으로 진단을 수행합니다.
12.5.1. 준비 및 활성 프로브 정보
준비 및 활성 프로브를 사용하여 비정상적인 VMI(가상 머신 인스턴스)를 탐지하고 처리합니다. VMI 사양에 프로브를 하나 이상 추가하여 트래픽이 준비되지 않은 VMI에 도달하지 않고 VMI가 응답하지 않을 때 새 인스턴스가 생성되도록 할 수 있습니다.
준비 상태 프로브는 VMI가 서비스 요청을 수락할 준비가 되었는지 확인합니다. 프로브가 실패하면 VMI가 준비될 때까지 VMI가 사용 가능한 엔드포인트 목록에서 VMI가 제거됩니다.
활성 프로브는 VMI의 응답 여부를 결정합니다. 프로브가 실패하면 VMI가 삭제되고 응답을 복원하기 위해 새 인스턴스가 생성됩니다.
VirtualMachineInstance
오브젝트의 spec.readinessProbe
및 spec.livenessProbe
필드를 설정하여 준비 및 활성 프로브를 구성할 수 있습니다. 이러한 필드는 다음 테스트를 지원합니다.
- HTTP GET
- 프로브는 웹 후크를 사용하여 VMI의 상태를 결정합니다. HTTP 응답 코드가 200에서 399 사이인 경우 테스트에 성공합니다. HTTP GET 테스트는 HTTP 상태 코드를 완전히 초기화할 때 반환하는 애플리케이션에 사용할 수 있습니다.
- TCP 소켓
- 프로브는 VMI에 대한 소켓을 열려고 시도합니다. VMI는 프로브에서 연결을 설정할 수 있는 경우에만 정상으로 간주됩니다. TCP 소켓 테스트는 초기화가 완료된 후 수신 대기를 시작하는 애플리케이션에 사용할 수 있습니다.
12.5.2. HTTP 준비 상태 프로브 정의
VMI(가상 머신 인스턴스) 구성의 spec.readinessProbe.httpGet
필드를 설정하여 HTTP 준비 프로브를 정의합니다.
절차
VMI 구성 파일에 준비 프로브의 세부 정보를 포함합니다.
HTTP GET 테스트가 있는 샘플 준비 상태 프로브
# ... spec: readinessProbe: httpGet: 1 port: 1500 2 path: /healthz 3 httpHeaders: - name: Custom-Header value: Awesome initialDelaySeconds: 120 4 periodSeconds: 20 5 timeoutSeconds: 10 6 failureThreshold: 3 7 successThreshold: 3 8 # ...
- 1
- VMI 연결에 수행할 HTTP GET 요청입니다.
- 2
- 프로브에서 쿼리하는 VMI의 포트입니다. 위의 예에서 프로브는 포트 1500을 쿼리합니다.
- 3
- HTTP 서버에서 액세스할 경로입니다. 위의 예에서 서버의 /healthz 경로에 대한 핸들러가 성공 코드를 반환하면 VMI가 정상으로 간주됩니다. 핸들러에서 실패 코드를 반환하면 VMI가 사용 가능한 엔드포인트 목록에서 제거됩니다.
- 4
- 준비 프로브가 시작되기 전에 VMI가 시작된 후 시간(초)입니다.
- 5
- 프로브 수행 사이의 지연 시간(초)입니다. 기본 지연 시간은 10초입니다. 이 값은
timeoutSeconds
보다 커야 합니다. - 6
- 프로브가 시간 초과되고 VMI가 실패한 것으로 간주되는 비활성 시간(초)입니다. 기본값은 1입니다. 이 값은
periodSeconds
보다 작아야 합니다. - 7
- 프로브가 실패할 수 있는 횟수입니다. 기본값은 3입니다. 지정된 횟수의 시도 후 Pod가
Unready
로 표시됩니다. - 8
- 프로브에서 실패 후 성공한 것으로 간주하기 위해 성공으로 보고해야 하는 횟수입니다. 기본값은 1입니다.
다음 명령을 실행하여 VMI를 생성합니다.
$ oc create -f <file_name>.yaml
12.5.3. TCP 준비 프로브 정의
VMI(가상 머신 인스턴스) 구성의 spec.readinessProbe.tcpSocket
필드를 설정하여 TCP 준비 프로브를 정의합니다.
절차
VMI 구성 파일에 TCP 준비 프로브 세부 정보를 포함합니다.
TCP 소켓 테스트를 사용하는 샘플 준비 상태 프로브
... spec: readinessProbe: initialDelaySeconds: 120 1 periodSeconds: 20 2 tcpSocket: 3 port: 1500 4 timeoutSeconds: 10 5 ...
다음 명령을 실행하여 VMI를 생성합니다.
$ oc create -f <file_name>.yaml
12.5.4. HTTP 활성 프로브 정의
VMI(가상 머신 인스턴스) 구성의 spec.livenessProbe.httpGet
필드를 설정하여 HTTP 활성 프로브를 정의합니다. 준비 프로브와 동일한 방식으로 활성 프로브에 대한 HTTP 및 TCP 테스트를 모두 정의할 수 있습니다. 이 절차에서는 HTTP GET 테스트를 사용하여 샘플 활성 프로브를 구성합니다.
절차
VMI 구성 파일에 HTTP 활성 프로브의 세부 정보를 포함합니다.
HTTP GET 테스트가 포함된 샘플 활성 프로브
# ... spec: livenessProbe: initialDelaySeconds: 120 1 periodSeconds: 20 2 httpGet: 3 port: 1500 4 path: /healthz 5 httpHeaders: - name: Custom-Header value: Awesome timeoutSeconds: 10 6 # ...
- 1
- 활성 프로브가 시작되기 전에 VMI가 시작된 후 시간(초)입니다.
- 2
- 프로브 수행 사이의 지연 시간(초)입니다. 기본 지연 시간은 10초입니다. 이 값은
timeoutSeconds
보다 커야 합니다. - 3
- VMI 연결에 수행할 HTTP GET 요청입니다.
- 4
- 프로브에서 쿼리하는 VMI의 포트입니다. 위의 예에서 프로브는 포트 1500을 쿼리합니다. VMI는 cloud-init를 통해 포트 1500에 최소 HTTP 서버를 설치하고 실행합니다.
- 5
- HTTP 서버에서 액세스할 경로입니다. 위의 예에서 서버의
/healthz
경로에 대한 핸들러가 성공 코드를 반환하면 VMI가 정상으로 간주됩니다. 핸들러에서 실패 코드를 반환하면 VMI가 삭제되고 새 인스턴스가 생성됩니다. - 6
- 프로브가 시간 초과되고 VMI가 실패한 것으로 간주되는 비활성 시간(초)입니다. 기본값은 1입니다. 이 값은
periodSeconds
보다 작아야 합니다.
다음 명령을 실행하여 VMI를 생성합니다.
$ oc create -f <file_name>.yaml
12.5.5. 템플릿: 상태 점검을 정의하는 가상 머신 인스턴스 구성 파일
apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachineInstance metadata: labels: special: vmi-fedora name: vmi-fedora spec: domain: devices: disks: - disk: bus: virtio name: containerdisk - disk: bus: virtio name: cloudinitdisk resources: requests: memory: 1024M readinessProbe: httpGet: port: 1500 initialDelaySeconds: 120 periodSeconds: 20 timeoutSeconds: 10 failureThreshold: 3 successThreshold: 3 terminationGracePeriodSeconds: 0 volumes: - name: containerdisk containerDisk: image: kubevirt/fedora-cloud-registry-disk-demo - cloudInitNoCloud: userData: |- #cloud-config password: fedora chpasswd: { expire: False } bootcmd: - setenforce 0 - dnf install -y nmap-ncat - systemd-run --unit=httpserver nc -klp 1500 -e '/usr/bin/echo -e HTTP/1.1 200 OK\\n\\nHello World!' name: cloudinitdisk
12.5.6. 추가 리소스
12.6. OpenShift Container Platform 대시 보드를 사용하여 클러스터 정보 검색
OpenShift Container Platform 대시보드에는 클러스터에 대한 개괄적인 정보가 포함되어 있으며 OpenShift Container Platform 웹 콘솔에서 홈 > 대시보드 > 개요를 클릭하여 액세스합니다.
OpenShift Container Platform 대시보드는 별도의 대시보드 카드에 표시되는 다양한 클러스터 정보를 제공합니다.
12.6.1. OpenShift Container Platform 대시 보드 페이지 정보
OpenShift Container Platform 대시 보드는 다음 카드로 구성됩니다.
Details는 클러스터 정보에 대한 간략한 개요를 표시합니다.
상태에는 ok, error, warning, progress 및 unknown이 포함되어 있습니다. 리소스는 사용자 정의 상태 이름을 추가 할 수 있습니다.
- 클러스터 ID
- 공급자
- 버전
Cluster Inventory는 리소스 수 및 관련 상태를 정보를 표시합니다. 이러한 정보는 문제 해결에 개입이 필요한 경우 매우 유용하며 다음과 같은 관련 정보가 포함되어 있습니다.
- 노드 수
- Pod 수
- 영구 스토리지 볼륨 요청
- 가상 머신(OpenShift Virtualization이 설치된 경우 사용 가능)
- 상태에 따라 나열되는 클러스터의 베어 메탈 호스트 (metal3 환경에서만 사용 가능)
- 클러스터 상태에는 관련 경보 및 설명을 포함하여 클러스터의 현재 상태가 전체적으로 요약되어 있습니다. OpenShift Virtualization이 설치된 경우 OpenShift Virtualization의 전반적인 상태도 진단됩니다. 하위 시스템이 한 개 이상 있는 경우 모두 보기를 클릭하여 각 하위 시스템의 상태를 확인하십시오.
Cluster Capacity 차트는 관리자가 클러스터에 추가 리소스가 필요한 시기를 파악하는 데 도움이 됩니다. 이 차트에는 내부 링과 외부링이 포함되어 있으며 내부 링은 현재 소비를 표시하는 외부 링은 다음 정보를 포함하여 리소스에 설정된 임계 값을 표시합니다.
- CPU 시간
- 메모리 할당
- 소비된 스토리지
- 소비된 네트워크 리소스
- Cluster Utilization은 관리자가 리소스의 높은 소비 규모 및 빈도를 이해하는데 도움이 되도록 지정된 기간 동안 다양한 리소스의 용량을 표시합니다.
- Events는 Pod 생성 또는 다른 호스트로의 가상 머신 마이그레이션과 같은 클러스터의 최근 활동과 관련된 메시지를 표시합니다.
- Top Consumers 관리자가 클러스터 리소스가 소비되는 방식을 이해하는 데 도움이 됩니다. 리소스를 클릭하면 지정된 클러스터 리소스(CPU, 메모리 또는 스토리지)를 가장 많이 사용하는 Pod와 노드가 나열된 세부 정보 페이지로 이동합니다.
12.7. OpenShift Container Platform 클러스터 모니터링, 로깅, Telemetry
OpenShift Container Platform은 클러스터 수준에서 모니터링에 필요한 다양한 리소스를 제공합니다.
12.7.1. OpenShift Container Platform 모니터링 정보
OpenShift Container Platform에는 주요 플랫폼 구성 요소를 모니터링할 수 있는 사전 구성, 사전 설치, 자체 업데이트 모니터링 스택이 포함되어 있습니다. OpenShift Container Platform은 즉시 사용 가능한 모니터링 모범 사례를 제공합니다. 클러스터 관리자에게 클러스터 문제에 대해 즉시 알리는 일련의 경보가 기본적으로 포함되어 있습니다. OpenShift Container Platform 웹 콘솔의 기본 대시보드에는 클러스터 상태를 빠르게 파악할 수 있도록 클러스터 지표에 대한 그래픽 표현이 포함되어 있습니다.
OpenShift Container Platform 4.6을 설치하면 클러스터 관리자가 선택 옵션으로 사용자 정의 프로젝트에 대한 모니터링을 활성화할 수 있습니다. 이 기능을 사용하면 클러스터 관리자, 개발자, 기타 사용자가 자신의 프로젝트에서 서비스와 Pod를 모니터링하는 방법을 지정할 수 있습니다. 그런 다음 OpenShift Container Platform 웹 콘솔에서 자체 프로젝트에 대한 메트릭을 쿼리하고, 대시보드를 검토하고, 경보 규칙과 침묵을 관리할 수 있습니다.
클러스터 관리자는 개발자 및 다른 사용자에게 자신의 프로젝트를 모니터링할 수 있는 권한을 부여할 수 있습니다. 권한은 사전 정의된 모니터링 역할 중 하나를 할당하는 방식으로 부여합니다.
12.7.2. 클러스터 로깅 구성 요소 정보
클러스터 로깅 구성 요소에는 수집기가 포함되어 있습니다. 이 수집기는 OpenShift Container Platform 클러스터의 각 노드에 배포되어 모든 노드와 컨테이너 로그를 수집한 다음 로그 저장소에 씁니다. 중앙 집중식 웹 UI에서 이렇게 집계된 데이터를 사용하여 풍부한 시각화 및 대시보드를 생성할 수 있습니다.
클러스터 로깅의 주요 구성 요소는 다음과 같습니다.
- 수집 - 클러스터에서 로그를 수집하고 형식을 지정한 후 로그 저장소로 전달하는 구성 요소입니다. 최신 구현은 Fluentd입니다.
- 로그 저장소 - 로그가 저장되는 위치입니다. 기본 구현은 Elasticsearch입니다. 기본 Elasticsearch 로그 저장소를 사용하거나 외부 로그 저장소로 로그를 전달할 수 있습니다. 기본 로그 저장소는 테스트를 거쳐 단기 스토리지용으로 최적화되었습니다.
- 시각화 - 로그, 그래프, 차트 등을 보는 데 사용할 수 있는 UI 구성 요소입니다. 최신 구현은 Kibana입니다.
클러스터 로깅에 대한 자세한 내용은 OpenShift Container Platform 클러스터 로깅 설명서를 참조하십시오.
12.7.3. Telemetry 정보
Telemetry는 엄선된 클러스터 모니터링 지표의 일부를 Red Hat으로 보냅니다. Telemeter Client는 4분 30초마다 메트릭 값을 가져와 Red Hat에 데이터를 업로드합니다. 이러한 메트릭에 대한 설명은 이 설명서에서 제공됩니다.
Red Hat은 이러한 데이터 스트림을 사용하여 클러스터를 실시간으로 모니터링하고 필요에 따라 고객에게 영향을 미치는 문제에 대응합니다. 또한 Red Hat은 OpenShift Container Platform 업그레이드를 고객에게 제공하여 서비스 영향을 최소화하고 지속적으로 업그레이드 환경을 개선할 수 있습니다.
이러한 디버깅 정보는 Red Hat 지원 및 엔지니어링 팀에 제공되며, 지원 사례를 통해 보고된 데이터에 액세스하는 것과 동일한 제한 사항이 적용됩니다. Red Hat은 연결된 모든 클러스터 정보를 사용하여 OpenShift Container Platform을 개선하고 사용 편의성을 높입니다.
12.7.3.1. Telemetry에서 수집하는 정보
Telemetry에서 수집되는 정보는 다음과 같습니다.
- 설치 중 생성된 임의의 고유 식별자
- OpenShift Container Platform 클러스터 버전 및 업데이트 버전 가용성 확인에 사용되는 업데이트 세부 정보와 같은 버전 정보
- 클러스터당 사용 가능한 업데이트 수, 업데이트 진행 정보, 업데이트 진행 정보에 사용되는 채널 및 이미지 리포지터리, 업데이트에 발생하는 오류 수를 포함한 업데이트 정보
- OpenShift Container Platform이 배포된 공급자 플랫폼의 이름 및 데이터 센터 위치
- CPU 코어 수 및 각각에 사용된 RAM 용량을 포함한 클러스터, 시스템 유형 및 머신 크기에 대한 정보
- 클러스터에서 실행 중인 가상 머신 인스턴스의 수
- etcd 멤버 수 및 etcd 클러스터에 저장된 오브젝트 수
- 클러스터 및 해당 조건 및 상태에 설치된 OpenShift Container Platform 프레임워크 구성 요소
- 구성 요소, 기능 및 확장에 대한 사용 정보
- 기술 프리뷰 및 지원되지 않는 구성에 대한 사용량 세부 정보
- 성능 저하 소프트웨어에 대한 정보
-
NotReady
로 표시된 노드에 대한 정보 - 성능이 저하된 Operator에 대해 "관련 개체"로 나열된 모든 네임스페이스에 대한 이벤트
- Red Hat 지원이 고객에게 유용한 지원을 제공하기 위해 도움이 되는 구성 세부 정보. 여기에는 클라우드 인프라 수준, 호스트 이름, IP 주소, Kubernetes Pod 이름, 네임스페이스 및 서비스의 노드 구성이 포함됩니다.
- 인증서의 유효성에 대한 정보
Telemetry에서는 사용자 이름 또는 암호와 같은 식별 정보를 수집하지 않습니다. Red Hat은 개인 정보를 수집하지 않습니다. 개인 정보가 의도하지 않게 Red Hat에 수신된 경우 Red Hat은 이러한 정보를 삭제합니다. Telemetry 데이터가 개인 정보를 구성하는 범위까지, Red Hat의 개인정보 보호정책에 대한 자세한 내용은 Red Hat 개인정보처리방침을 참조하십시오.
12.7.4. CLI 문제 해결 및 디버깅 명령
oc
클라이언트 문제 해결 및 디버깅 명령 목록은 OpenShift Container Platform CLI 툴 설명서를 참조하십시오.
12.8. Red Hat 지원을 위한 데이터 수집
Red Hat 지원에 지원 케이스 를 제출할 때 다음 툴을 사용하여 OpenShift Container Platform 및 OpenShift Virtualization에 대한 디버깅 정보를 제공하는 것이 좋습니다.
- must-gather 툴
-
must-gather
툴은 리소스 정의 및 서비스 로그를 포함하여 진단 정보를 수집합니다. - Prometheus
- Prometheus는 시계열 데이터베이스이며 메트릭에 대한 규칙 평가 엔진입니다. Prometheus는 처리를 위해 Alertmanager에 경고를 보냅니다.
- Alertmanager
- Alertmanager 서비스는 Prometheus에서 수신한 경고를 처리합니다. Alertmanager는 또한 외부 알림 시스템으로 경고를 보냅니다.
12.8.1. 환경에 대한 데이터 수집
환경에 대한 데이터를 수집하면 근본 원인을 분석하고 결정하는 데 필요한 시간이 최소화됩니다.
사전 요구 사항
- Prometheus 지표 데이터의 보존 시간을 최소 7일로 설정합니다.
- 관련 경고를 캡처하고 클러스터 외부에서 보고 유지할 수 있도록 전용 메일로 전송하도록 Alertmanager를 구성합니다.
- 영향을 받는 노드 및 가상 머신의 정확한 수를 기록합니다.
절차
-
기본
must-gather
이미지를 사용하여 클러스터의must-gather
데이터를 수집합니다. -
필요한 경우 Red Hat OpenShift Container Storage의
must-gather
데이터를 수집합니다. -
OpenShift Virtualization
must-gather
이미지를 사용하여 OpenShift Virtualization의must-gather
데이터를 수집합니다. - 클러스터에 대한 Prometheus 지표를 수집합니다.
12.8.1.1. 추가 리소스
- Prometheus 메트릭 데이터의 보존 시간 구성
- 외부 시스템에 경고 알림을 전송하도록 Alertmanager 구성
-
OpenShift Container Platform의
must-gather
데이터 수집 -
OpenShift Virtualization의
must-gather
데이터 수집 - 클러스터 관리자로 모든 프로젝트의 Prometheus 지표 수집
12.8.2. 가상 머신에 대한 데이터 수집
가상 머신 장애 복구(VM)에 대한 데이터를 수집하면 근본 원인을 분석하고 결정하는 데 필요한 시간이 최소화됩니다.
사전 요구 사항
Windows VM:
- Red Hat 지원에 대한 Windows 패치 업데이트 세부 정보를 기록합니다.
- VirtIO 드라이버의 최신 버전을 설치합니다. VirtIO 드라이버에는 QEMU 게스트 에이전트가 포함되어 있습니다.
- RDP(Remote Desktop Protocol)가 활성화된 경우, RDP를 사용하여 VM에 연결하여 연결 소프트웨어에 문제가 있는지 확인합니다.
절차
-
VM 손상에 대한 자세한
must-gather
데이터를 수집합니다. - 재시작하기 전에 충돌한 VM의 스크린샷을 수집합니다.
- VM이 손상되는 요인을 기록하십시오. 예를 들어 VM에는 동일한 호스트 또는 네트워크가 있습니다.
12.8.2.1. 추가 리소스
- Windows VM에 VirtIO 드라이버 설치
- 호스트 액세스없이 Windows VM에 VirtIO 드라이버 다운로드 및 설치
- 웹 콘솔 또는 명령줄을 사용하여 RDP로 Windows VM에 연결
-
가상 머신에대한
must-gather
데이터 수집
12.8.3. OpenShift Virtualization에 must-gather 툴 사용
OpenShift Virtualization 이미지로 must-gather
명령을 실행하여 OpenShift Virtualization 리소스에 대한 데이터를 수집할 수 있습니다.
기본 데이터 컬렉션에는 다음 리소스에 대한 정보가 포함됩니다.
- 하위 오브젝트를 포함한 OpenShift Virtualization Operator 네임스페이스
- OpenShift Virtualization 사용자 정의 리소스 정의
- 가상 머신이 포함된 네임스페이스
- 기본 가상 머신 정의
절차
다음 명령을 실행하여 OpenShift Virtualization에 대한 데이터를 수집합니다.
$ oc adm must-gather --image-stream=openshift/must-gather \ --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v{HCOVersion}
12.8.3.1. must-gather 툴 옵션
다음 옵션에 대한 스크립트 및 환경 변수 조합을 지정할 수 있습니다.
- 네임스페이스에서 자세한 VM(가상 머신) 정보 수집
- 지정된 VM에 대한 세부 정보 수집
- 이미지 및 이미지 스트림 정보 수집
-
must-gather
툴에서 사용하는 최대 병렬 프로세스 수 제한
12.8.3.1.1. 매개 변수
환경 변수
호환되는 스크립트의 환경 변수를 지정할 수 있습니다.
NS=<namespace_name>
-
지정하는 네임스페이스에서
virt-launcher
Pod 세부 정보를 포함하여 가상 머신 정보를 수집합니다.VirtualMachine
및VirtualMachineInstance
CR 데이터는 모든 네임스페이스에 대해 수집됩니다. VM=<vm_name>
-
특정 가상 머신에 대한 세부 정보를 수집합니다. 이 옵션을 사용하려면
NS
환경 변수를 사용하여 네임스페이스도 지정해야 합니다. PROS=<number_of_processes>
must-gather
툴이 사용하는 최대 병렬 프로세스 수를 수정합니다. 기본값은5
입니다.중요너무 많은 병렬 프로세스를 사용하면 성능 문제가 발생할 수 있습니다. 최대 병렬 프로세스 수를 늘리는 것은 권장되지 않습니다.
scripts
각 스크립트는 특정 환경 변수 조합과만 호환됩니다.
gather_vms_details
-
OpenShift Virtualization 리소스에 속하는 VM 로그 파일, VM 정의 및 네임스페이스(및 해당 하위 오브젝트)를 수집합니다. 네임스페이스 또는 VM을 지정하지 않고 이 매개변수를 사용하는 경우
must-gather
툴은 클러스터의 모든 VM에 대해 이 데이터를 수집합니다. 이 스크립트는 모든 환경 변수와 호환되지만VM
변수를 사용하는 경우 네임스페이스를 지정해야 합니다. gather
-
모든 네임스페이스에서 클러스터 데이터를 수집하고 기본 VM 정보만 포함하는 기본
must-gather
스크립트를 사용합니다. 이 스크립트는PROS
변수와만 호환됩니다. gather_images
-
이미지 및 이미지 스트림 사용자 정의 리소스 정보를 수집합니다. 이 스크립트는
PROS
변수와만 호환됩니다.
12.8.3.1.2. 사용법 및 예
환경 변수는 선택 사항입니다. 자체적으로 또는 하나 이상의 호환 환경 변수를 사용하여 스크립트를 실행할 수 있습니다.
스크립트 | 호환 가능한 환경 변수 |
---|---|
|
|
|
|
|
|
must-gather
가 수집하는 데이터를 사용자 정의하려면 명령에 이중 대시 (--
)를 추가한 다음 공백 및 하나 이상의 호환 가능한 매개변수를 추가합니다.
구문
$ oc adm must-gather \ --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v2.5.8 \ -- <environment_variable_1> <environment_variable_2> <script_name>
VM 세부 정보
다음 명령은 mynamespace
네임스페이스에서 my-vm
VM에 대한 자세한 VM 정보를 수집합니다.
$ oc adm must-gather \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v2.5.8 \
-- NS=mynamespace VM=my-vm gather_vms_details 1
- 1
VM
환경 변수를 사용하는 경우NS
환경 변수는 필수입니다.
세 개의 병렬 프로세스로 제한되는 기본 데이터 수집
다음 명령은 최대 세 개의 병렬 프로세스를 사용하여 기본 must-gather
정보를 수집합니다.
$ oc adm must-gather \ --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v2.5.8 \ -- PROS=3 gather
이미지 및 이미지 스트림 정보
다음 명령은 클러스터에서 이미지 및 이미지 스트림 정보를 수집합니다.
$ oc adm must-gather \ --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v2.5.8 \ -- gather_images