[KubeVirt Ep.2] 🚀 kubevirt 아키텍처 이해하기 | 주요 구성요소와 동작 흐름
이 글에서는 KubeVirt의 내부 아키텍처와 주요 구성요소들을 자세히 살펴보겠습니다. KubeVirt가 쿠버네티스 상에서 어떻게 가상 머신을 실행하는지, 각 컴포넌트들이 어떤 역할을 하는지, 그리고 VM이 어떤 흐름으로 Pod로 변환되어 실행되는지 이해하는 시간을 갖겠습니다.
📌 KubeVirt 아키텍처 개요
✅ KubeVirt의 설계 철학
KubeVirt는 쿠버네티스의 확장성을 활용하여 가상화 기능을 통합하는 아키텍처를 가지고 있습니다. 이는 다음과 같은 설계 철학을 바탕으로 합니다:
- 쿠버네티스 네이티브 통합: 가상 머신을 쿠버네티스 리소스로 정의하고 관리
- 선언적 설계: 모든 VM 구성은 YAML로 정의되며 원하는 상태를 선언
- 컨트롤러 기반 조정: 현재 상태와 원하는 상태 간의 차이를 지속적으로 조정
- 확장 가능한 구조: 플러그인 기반 구조로 새로운 기능 확장 가능
- 최소 권한 원칙: 각 컴포넌트는 필요한 최소한의 권한만 가짐
✅ 전체 아키텍처 구성
KubeVirt의 아키텍처는 크게 다음과 같은 레이어로 구성됩니다:
- API 레이어: VM 관련 커스텀 리소스 정의(CRD)와 API 서버
- 컨트롤 플레인 레이어: 클러스터 수준의 컨트롤러들
- 노드 레이어: 각 노드에서 실행되는 에이전트
- 런타임 레이어: 실제 VM을 실행하는 컴포넌트
이러한 계층적 구조는 쿠버네티스의 분산 아키텍처와 자연스럽게 통합됩니다.
📌 KubeVirt의 주요 구성 요소
KubeVirt는 여러 핵심 컴포넌트로 구성되어 있으며, 각각 특정 역할을 담당합니다.
✅ virt-api: API 확장 서버
virt-api는 KubeVirt의 REST API 엔드포인트로, 다음과 같은 역할을 합니다:
- VM 관련 API 요청 처리 (CRD 기반)
- 웹훅을 통한 VM 리소스 검증 및 변경
- VM 콘솔 프록시 제공 (VNC/콘솔 접속)
- kubectl 확장 명령(subresource API) 지원
# virt-api 배포 구성 예시 (간략화됨)
apiVersion: apps/v1
kind: Deployment
metadata:
name: virt-api
namespace: kubevirt
spec:
replicas: 2 # 고가용성을 위한 다중 복제본
selector:
matchLabels:
kubevirt.io: virt-api
template:
metadata:
labels:
kubevirt.io: virt-api
spec:
containers:
- name: virt-api
image: kubevirt/virt-api:latest
# 중요: 클러스터 역할 바인딩을 통해 필요한 권한 부여
▶️ API 서버의 역할: "virt-api는 쿠버네티스 API 서버의 확장으로 작동하며, 모든 VM 관련 작업이 쿠버네티스의 일관된 방식으로 처리될 수 있게 합니다. 웹훅을 통해 VM 리소스가 생성되거나 수정될 때마다 유효성 검사를 수행합니다."
✅ virt-controller: 클러스터 수준 컨트롤러
virt-controller는 KubeVirt의 중앙 제어 컴포넌트로, 다음과 같은 기능을 담당합니다:
- VM 리소스 감시 및 상태 관리
- VM을 실행하기 위한 Pod 생성 및 관리
- VM 라이프사이클 오케스트레이션
- 클러스터 수준의 VM 관련 결정 처리
# virt-controller가 관찰하는 VM 리소스 예시
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: example-vm
spec:
running: true # VM의 원하는 상태 (실행 중)
template:
metadata:
labels:
kubevirt.io/vm: example-vm
spec:
domain:
# VM 스펙 정의 (CPU, 메모리, 디스크 등)
▶️ 컨트롤러의 역할: "virt-controller는 항상 VM 리소스를 모니터링하고 있다가 새로운 VM이 생성되거나 변경되면, 해당 VM을 실행하기 위한 Pod를 생성합니다. 이 과정에서 클러스터의 상태를 지속적으로 확인하고 VM이 원하는 상태가 되도록 조정합니다."
✅ virt-handler: 노드 에이전트
virt-handler는 각 쿠버네티스 노드에서 실행되는 에이전트로, 다음과 같은 역할을 합니다:
- 로컬 VM 감시 및 상태 보고
- libvirt 도메인 라이프사이클 관리
- VM 마이그레이션 처리
- 노드 수준의 VM 관련 작업 수행
virt-handler는 DaemonSet으로 배포되어 모든 노드에서 실행됩니다.
# virt-handler DaemonSet 구성 예시 (간략화됨)
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: virt-handler
namespace: kubevirt
spec:
selector:
matchLabels:
kubevirt.io: virt-handler
template:
metadata:
labels:
kubevirt.io: virt-handler
spec:
containers:
- name: virt-handler
image: kubevirt/virt-handler:latest
volumeMounts:
- name: libvirt-runtime
mountPath: /var/run/libvirt
# 호스트 경로 마운트 필요
volumes:
- name: libvirt-runtime
hostPath:
path: /var/run/libvirt
# 특권 컨테이너로 실행 (가상화 접근 필요)
▶️ 노드 에이전트의 역할: "virt-handler는 각 노드에서 실행되며, 실제 VM 인스턴스를 관리합니다. libvirt와 직접 통신하여 VM 라이프사이클을 제어하고, 노드 수준에서 VM 상태를 모니터링하여 클러스터 상태와 동기화합니다."
✅ virt-launcher: VM 실행 컨테이너
virt-launcher는 실제 VM을 실행하는 Pod 내의 컨테이너로, 다음과 같은 기능을 수행합니다:
- libvirt와 QEMU/KVM을 사용하여 VM 실행
- VM 프로세스 격리 및 관리
- VM의 입출력 및 콘솔 연결 처리
- VM의 종료 신호 처리 및 그레이스풀 셧다운
virt-controller가 VM마다 virt-launcher Pod를 생성합니다.
# virt-launcher Pod 구성 예시 (자동 생성됨)
apiVersion: v1
kind: Pod
metadata:
name: virt-launcher-example-vm-abc123
namespace: default
labels:
kubevirt.io/created-by: virt-controller
kubevirt.io/domain: example-vm
spec:
containers:
- name: compute
image: kubevirt/virt-launcher:latest
# VM 실행에 필요한 리소스 요청 및 제한
resources:
requests:
memory: "1024Mi"
cpu: "500m"
volumeMounts:
- name: containerdisk
mountPath: /var/run/kubevirt-private/vmi-disks/containerdisk
# VM 디스크 및 설정 볼륨 마운트
volumes:
# VM 이미지 및 구성 볼륨
▶️ 런처의 역할: "virt-launcher는 VM 당 하나씩 생성되는 Pod로, 실제 VM 프로세스를 실행하고 관리합니다. 이 Pod이 종료되면 VM도 함께 종료되므로, 쿠버네티스의 Pod 라이프사이클이 VM 라이프사이클에 직접 연결됩니다."
📌 KubeVirt CRD 리소스 구조
KubeVirt는 쿠버네티스의 CRD(Custom Resource Definition) 메커니즘을 통해 VM 관련 리소스를 정의합니다. 이러한 커스텀 리소스는 VM의 라이프사이클과 구성을 관리하는 핵심 요소입니다.
✅ VirtualMachineInstance (VMI)
VMI는 실행 중인 VM 인스턴스를 나타내는 리소스입니다:
- VM의 하드웨어 스펙 정의 (CPU, 메모리, 디스크 등)
- 항상 실행 중인 상태를 나타냄
- 직접 생성하거나 VirtualMachine 리소스에 의해 관리될 수 있음
apiVersion: kubevirt.io/v1
kind: VirtualMachineInstance
metadata:
name: example-vmi
spec:
domain:
devices:
disks:
- name: containerdisk
disk: {}
- name: cloudinitdisk
disk: {}
resources:
requests:
memory: 1024M # VM에 할당할 메모리
volumes:
- name: containerdisk
containerDisk: # 컨테이너 이미지에 포함된 VM 디스크
image: kubevirt/cirros-container-disk-demo:latest
- name: cloudinitdisk
cloudInitNoCloud: # cloud-init 설정
userData: |
#cloud-config
password: password
chpasswd: { expire: False }
✅ VirtualMachine (VM)
VM은 VMI의 상위 리소스로, VM의 라이프사이클을 관리합니다:
- VMI 템플릿 포함
- VM의 실행/중지 상태 관리
- 재시작 정책 설정
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: example-vm
spec:
running: true # VM 실행 여부
template: # VMI 템플릿
metadata:
labels:
kubevirt.io/vm: example-vm
spec:
# VMI 스펙과 동일한 구조
domain:
devices:
# 장치 구성
volumes:
# 볼륨 구성
runStrategy: RerunOnFailure # 재시작 정책
▶️ VM과 VMI의 관계: "VirtualMachine은 VMI의 소유자(owner)로, VM 리소스가 running: true로 설정되면 컨트롤러가 해당 VM 템플릿을 기반으로 VMI를 생성합니다. 이는 쿠버네티스의 Deployment와 Pod의 관계와 유사합니다."
✅ VirtualMachineInstanceReplicaSet (VMIRS)
VMIRS는 동일한 VMI의 복제본을 관리하는 리소스입니다:
- 여러 동일한 VM 인스턴스 실행
- 레플리카 수 조정
- 쿠버네티스 ReplicaSet과 유사한 개념
apiVersion: kubevirt.io/v1
kind: VirtualMachineInstanceReplicaSet
metadata:
name: example-vmirs
spec:
replicas: 3 # 유지할 VMI 개수
selector:
matchLabels:
app: example-vm
template: # VMI 템플릿
metadata:
labels:
app: example-vm
spec:
# VMI 스펙
✅ VirtualMachineInstanceMigration (VMIM)
VMIM은 실행 중인 VMI를 한 노드에서 다른 노드로 마이그레이션하기 위한 리소스입니다:
- 라이브 마이그레이션 요청 정의
- 마이그레이션 상태 추적
- 마이그레이션 정책 설정
apiVersion: kubevirt.io/v1
kind: VirtualMachineInstanceMigration
metadata:
name: example-migration
spec:
vmiName: example-vmi # 마이그레이션할 VMI 이름
📌 VM이 Pod로 실행되는 흐름 분석
이제 VM이 어떤 과정을 통해 쿠버네티스 Pod으로 변환되어 실행되는지 자세히 살펴보겠습니다.
✅ VM 생성 및 실행 흐름
- VM 리소스 생성:
- 사용자가 VirtualMachine 리소스를 생성 (YAML 적용)
- virt-api가 요청을 검증하고 처리
- 컨트롤러 처리:
- virt-controller가 VM 리소스 생성을 감지
- running: true 상태 확인
- VM 템플릿을 기반으로 VMI 리소스 생성
- VMI 처리:
- virt-controller가 VMI 리소스 생성 감지
- virt-launcher Pod 생성 (VM을 실행할 Pod)
- 필요한 볼륨, 네트워크 인터페이스 구성
- 노드 레벨 처리:
- virt-launcher Pod이 특정 노드에 스케줄링됨
- 해당 노드의 virt-handler가 VMI와 Pod 감지
- libvirt 도메인 정의 생성 및 VM 시작
- VM 상태 모니터링 및 보고
- VM 실행 상태:
- virt-launcher가 libvirt/QEMU를 사용해 실제 VM 프로세스 시작
- VM 콘솔 및 VNC 서비스 활성화
- VM 상태가 'Running'으로 업데이트
# 실제 VM 생성 및 실행 과정을 CLI로 관찰
# 1. VM 리소스 생성
$ kubectl apply -f my-vm.yaml
# 2. VM 상태 확인
$ kubectl get vm my-vm
NAME AGE STATUS READY
my-vm 10s Running True
# 3. VMI 리소스 확인
$ kubectl get vmi my-vm
NAME AGE PHASE IP NODENAME
my-vm 8s Running 10.244.0.15 worker-1
# 4. virt-launcher Pod 확인
$ kubectl get pods | grep virt-launcher-my-vm
virt-launcher-my-vm-abc123 1/1 Running 0 7s
# 5. 이벤트 확인
$ kubectl get events | grep my-vm
▶️ 실제 동작 과정: "VM을 생성하면 virt-controller가 이를 감지하고 VMI를 생성합니다. 그런 다음 VMI를 실행하기 위한 virt-launcher Pod를 생성하고, 이 Pod 내에서 libvirt/QEMU가 실제 VM을 실행합니다. 이 모든 과정은 선언적 방식으로 자동화되어 있습니다."
✅ VM 라이프사이클 관리 흐름
VM의 라이프사이클 상태 변경은 다음과 같은 흐름으로 처리됩니다:
- VM 시작:
- spec.running: true 설정
- 컨트롤러가 VMI 생성
- virt-launcher Pod 생성 및 VM 실행
- VM 정지:
- spec.running: false 설정
- 컨트롤러가 연결된 VMI 삭제
- virt-launcher Pod 종료
- VM 구성은 유지되어 나중에 다시 시작 가능
- VM 재시작:
- spec.running: true로 다시 설정
- 새로운 VMI 및 virt-launcher Pod 생성
- 동일한 구성으로 VM 재시작
- VM 마이그레이션:
- VMIM 리소스 생성
- virt-handler가 마이그레이션 조정
- 대상 노드에 새 virt-launcher Pod 생성
- VM 메모리 및 상태 이전
- 원래 virt-launcher Pod 종료
# VM 라이프사이클 관리 명령어
# VM 중지
$ kubectl patch vm my-vm --type merge -p '{"spec":{"running":false}}'
# 또는
$ virtctl stop my-vm
# VM 시작
$ kubectl patch vm my-vm --type merge -p '{"spec":{"running":true}}'
# 또는
$ virtctl start my-vm
# VM 재시작
$ virtctl restart my-vm
# VM 마이그레이션
$ virtctl migrate my-vm
▶️ 라이프사이클 관리 방식: "VM의 라이프사이클은 VM 리소스의 spec.running 필드나 runStrategy 설정을 통해 선언적으로 관리됩니다. virtctl 명령어는 이러한 리소스 변경을 더 쉽게 수행할 수 있게 해주는 도구입니다."
📌 VM 스토리지 아키텍처
KubeVirt에서 VM의 스토리지는 여러 방식으로 구성될 수 있으며, 기본적으로 쿠버네티스의 볼륨 시스템을 활용합니다.
✅ VM 볼륨 타입
- containerDisk:
- VM 디스크 이미지를 컨테이너 이미지로 패키징
- 이미지 레지스트리를 통해 배포
- 읽기 전용, 불변 이미지에 적합
- persistentVolumeClaim (PVC):
- 쿠버네티스 PVC를 VM 디스크로 사용
- 영구 스토리지 제공
- 데이터 보존 필요 시 적합
- dataVolume:
- CDI(Containerized Data Importer)와 통합
- VM 이미지 임포트 및 클론 기능
- PVC의 프로비저닝과 VM 생성을 단일 단계로 통합
- cloudInitNoCloud:
- cloud-init 설정을 위한 특수 볼륨
- VM 초기화 및 사용자 정의
- emptyDisk:
- 임시 디스크 생성
- VM 실행 중에만 존재
# 다양한 볼륨 타입을 사용한 VM 예시
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: example-vm-storage
spec:
running: true
template:
spec:
domain:
devices:
disks:
- name: rootdisk
disk: {}
- name: cloudinitdisk
disk: {}
- name: emptydisk
disk: {}
- name: pvcdisk
disk: {}
volumes:
- name: rootdisk
containerDisk: # 컨테이너 디스크
image: kubevirt/fedora-cloud-container-disk-demo:latest
- name: cloudinitdisk
cloudInitNoCloud: # cloud-init 설정
userData: |
#cloud-config
password: fedora
chpasswd: { expire: False }
- name: emptydisk
emptyDisk: # 빈 디스크
capacity: "2Gi"
- name: pvcdisk
persistentVolumeClaim: # PVC 디스크
claimName: my-vm-disk
▶️ 스토리지 활용 팁: "ContainerDisk는 OS 이미지와 같은 읽기 전용 데이터에 적합하고, 애플리케이션 데이터나 변경되는 데이터는 PVC를 사용하는 것이 좋습니다. DataVolume은 기존 VM 이미지를 클라우드 스토리지에서 가져오거나 다른 VM에서 클론할 때 유용합니다."
📌 VM 네트워킹 아키텍처
KubeVirt의 VM 네트워킹은 쿠버네티스 네트워킹 스택과 통합되어 있으며, 다양한 네트워크 구성이 가능합니다.
✅ 기본 네트워크 구조
- Pod 네트워크:
- 기본적으로 VM은 Pod 네트워크 인터페이스를 사용
- 쿠버네티스 CNI 플러그인을 통해 네트워크 연결
- 다른 Pod이나 서비스와 동일한 방식으로 통신
- 네트워크 인터페이스 구성:
- 여러 네트워크 인터페이스 추가 가능
- 다양한 네트워크 모델 지원 (virtio, e1000 등)
- MAC 주소 지정 가능
- Service 통합:
- VM을 쿠버네티스 Service로 노출 가능
- ClusterIP, NodePort, LoadBalancer 지원
- 서비스 디스커버리 및 로드 밸런싱 활용
# 네트워크 구성 예시
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: example-vm-network
spec:
running: true
template:
spec:
domain:
devices:
interfaces:
- name: default
masquerade: {} # NAT 모드
- name: secondary
bridge: {} # 브릿지 모드
networks:
- name: default
pod: {} # 기본 Pod 네트워크
- name: secondary
multus: # Multus CNI 사용 (추가 네트워크)
networkName: secondary-network
✅ 고급 네트워킹 옵션
- Multus CNI 통합:
- 다중 네트워크 인터페이스 지원
- SR-IOV, 브릿지, MACVLAN 등 특수 네트워킹 옵션
- 네트워크 격리 및 성능 최적화 가능
- 네트워크 인터페이스 모델:
- virtio: 기본 모델, 최적의 성능 (반가상화)
- e1000: 인텔 기가비트 이더넷 카드 에뮬레이션
- rtl8139: 레거시 OS 지원
- 네트워크 바인딩 방식:
- bridge: L2 브릿지 모드
- masquerade: NAT 모드
- SRIOV: 하드웨어 패스스루
- slirp: 사용자 공간 네트워킹
▶️ 네트워킹 팁: "기본 Pod 네트워크는 대부분의 경우 잘 작동하지만, 네트워크 성능이 중요한 워크로드의 경우 Multus와 SR-IOV를 통한 직접 하드웨어 접근이 유용합니다. Windows VM을 실행할 때는 virtio 드라이버 설치나 e1000 같은 에뮬레이션 모드를 고려하세요."
📌 동작 시나리오 분석: VM 생성부터 실행까지
실제 VM 생성부터 실행까지의 과정을 단계별로 자세히 살펴보겠습니다. 이 시나리오는 KubeVirt 컴포넌트 간의 상호 작용을 이해하는 데 도움이 됩니다.
✅ 시나리오: VM 생성 및 실행
- VM YAML 정의 및 적용
- $ kubectl apply -f example-vm.yaml
- virt-api 처리
- 웹훅을 통한 YAML 유효성 검사
- API 요청 처리 및 etcd에 VM 객체 저장
- virt-controller 작업
- VM 객체 감지 및 상태 확인
- VMI 객체 생성 (running: true인 경우)
- virt-launcher Pod 템플릿 생성
- 쿠버네티스 스케줄러 작업
- virt-launcher Pod 노드 할당
- 리소스 할당 및 볼륨 준비
- 노드의 virt-handler 작업
- VMI 객체와 virt-launcher Pod 감지
- libvirt 도메인 XML 생성
- VM 시작 준비 (디스크, 네트워크 설정)
- virt-launcher 작업
- libvirt 및 QEMU 프로세스 시작
- VM 프로세스 실행 및 모니터링
- 콘솔 및 VNC 서비스 설정
- VM 실행 상태 도달
- VM 상태가 'Running'으로 업데이트
- 상태 정보가 VMI 객체에 반영
- VM이 완전히 부팅되고 사용 가능
VM 실행 상태 도달 이후 부분을 이어서 작성하겠습니다.
# 전체 과정에서 발생하는 이벤트 흐름
$ kubectl get events | grep example-vm
1m Normal SuccessfulCreate virtualmachine/example-vm
1m Normal Created virtualmachineinstance/example-vm
58s Normal SuccessfulCreate pod/virt-launcher-example-vm-abc123
45s Normal Started virtualmachineinstance/example-vm
▶️ 중요 흐름 설명: "KubeVirt의 아키텍처는 쿠버네티스의 컨트롤러 패턴을 활용합니다. 사용자가 선언적으로 정의한 VM 상태를 virt-controller가 관찰하고, virt-launcher 파드를 생성하여 실제 VM을 구동합니다. 이 과정에서 virt-handler는 노드 수준에서 VM과 libvirt를 연결하는 역할을 합니다."
📌 실제 디버깅과 문제 해결
KubeVirt의 아키텍처를 이해하면 문제 발생 시 효과적으로 디버깅할 수 있습니다. 주요 디버깅 포인트와 방법을 살펴보겠습니다.
✅ 컴포넌트별 로그 확인
각 컴포넌트의 로그는 문제 해결에 중요한 정보를 제공합니다:
# virt-api 로그 확인
$ kubectl logs -n kubevirt -l kubevirt.io=virt-api
# virt-controller 로그 확인
$ kubectl logs -n kubevirt -l kubevirt.io=virt-controller
# virt-handler 로그 확인 (특정 노드)
$ kubectl logs -n kubevirt -l kubevirt.io=virt-handler -o=custom-columns=NODE:.spec.nodeName,NAME:.metadata.name
# virt-launcher 로그 확인 (특정 VM)
$ kubectl logs -n <namespace> virt-launcher-<vm-name>-<random>
✅ VM 상태 및 이벤트 확인
# VM 상태 확인
$ kubectl get vm <vm-name> -o yaml
# VMI 상태 확인
$ kubectl get vmi <vm-name> -o yaml
# VM 관련 이벤트 확인
$ kubectl get events | grep <vm-name>
✅ 일반적인 문제 및 해결 방법
- VM이 시작되지 않는 경우:
- virt-controller 로그 확인 (VMI 생성 실패 원인)
- 리소스 제약 조건 확인 (메모리, CPU 할당량)
- 스토리지 문제 확인 (PVC 상태, 접근 권한)
- 네트워크 연결 문제:
- 네트워크 정책 확인
- CNI 플러그인 구성 확인
- VM 내부 네트워크 설정 확인
- 성능 이슈:
- 하드웨어 가상화 확인 (KVM 가속)
- 리소스 할당 및 QoS 설정 검토
- 노드 오버커밋 상태 확인
▶️ 디버깅 팁: "VM 문제 해결 시 먼저 VM과 VMI 상태를 확인하고, virt-launcher Pod의 로그를 살펴보세요. 그래도 해결되지 않으면 virt-handler와 virt-controller의 로그를 차례로 확인하는 것이 효율적입니다. 대부분의 문제는 이 컴포넌트들 중 하나에서 발생한 오류나 설정 이슈입니다."
📌 kubevirt-operator: 설치 및 업그레이드 관리자
KubeVirt 생태계의 또 다른 중요한 컴포넌트인 kubevirt-operator에 대해 알아보겠습니다.
✅ Operator 패턴과 역할
kubevirt-operator는 쿠버네티스 Operator 패턴을 사용하여 KubeVirt의 설치, 업그레이드, 구성을 관리합니다:
- 전체 KubeVirt 스택의 라이프사이클 관리
- 버전 호환성 및 업그레이드 경로 관리
- 클러스터 수준 설정 및 기능 플래그 제어
- 노드 준비 기능 (예: KVM 모듈 로딩)
# KubeVirt CR 예시 (Operator가 관리)
apiVersion: kubevirt.io/v1
kind: KubeVirt
metadata:
name: kubevirt
namespace: kubevirt
spec:
certificateRotationStrategy: {}
configuration:
developerConfiguration:
featureGates: ["DataVolumes"] # 기능 활성화
networkConfiguration:
permitBridgeInterfaceOnPodNetwork: true
customizeComponents: {}
imagePullPolicy: IfNotPresent
✅ 버전 관리 및 업그레이드
kubevirt-operator는 KubeVirt 컴포넌트의 버전을 관리하고 안전한 업그레이드를 조정합니다:
- 롤링 업데이트 방식의 컴포넌트 업그레이드
- 버전 간 호환성 검증
- 업그레이드 실패 시 롤백 기능
# KubeVirt 버전 업그레이드 예시
$ kubectl apply -f https://github.com/kubevirt/kubevirt/releases/download/v0.58.0/kubevirt-operator.yaml
$ kubectl patch -n kubevirt kv kubevirt --type=merge -p '{"spec":{"imageTag":"v0.58.0"}}'
▶️ Operator 활용 팁: "KubeVirt Operator는 전체 KubeVirt 스택의 구성을 중앙화하여 관리합니다. 특정 기능을 활성화하거나 네트워크 설정을 변경할 때는 KubeVirt CR을 수정하면 Operator가 이를 감지하고 모든 컴포넌트에 적용합니다."
📌 KubeVirt 확장 생태계와의 통합
KubeVirt는 독립적으로 작동할 수 있지만, 보다 완전한 VM 관리 환경을 구축하기 위해 다양한 확장 프로젝트와 통합됩니다.
✅ CDI(Containerized Data Importer)
CDI는 KubeVirt를 위한 데이터 가져오기 및 관리 플랫폼입니다:
- VM 이미지(QCOW2, ISO 등)를 PVC로 임포트
- DataVolume CRD를 통한 스토리지 프로비저닝 자동화
- VM 이미지 클론 및 관리 기능
# DataVolume 사용 예시
apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
name: example-dv
spec:
source:
http:
url: "https://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2"
pvc:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
✅ Cluster API Provider KubeVirt
Cluster API와의 통합을 통해 KubeVirt 기반 인프라에서 쿠버네티스 클러스터 배포 자동화:
- 선언적 방식의 클러스터 배포
- VM 기반 쿠버네티스 노드 관리
- 클러스터 라이프사이클 자동화
✅ KubeVirt UI 및 가시성 도구
다양한 웹 인터페이스 및 대시보드를 통해 KubeVirt VM 관리:
- OpenShift Virtualization (콘솔 통합)
- KubeVirt Web UI
- Kubernetes Dashboard 플러그인
▶️ 생태계 활용 팁: "KubeVirt만으로도 기본적인 VM 관리가 가능하지만, CDI를 함께 설치하면 VM 이미지 관리와 라이프사이클이 크게 향상됩니다. 특히 기존 VM 이미지를 임포트하거나 여러 VM에서 동일한 이미지를 사용할 때 유용합니다."
📌 Summary
이 글에서는 KubeVirt의 아키텍처와 주요 구성 요소를 자세히 살펴보았습니다. 핵심 내용을 정리하면:
- KubeVirt는 virt-api, virt-controller, virt-handler, virt-launcher로 구성된 계층적 아키텍처를 가집니다.
- VM 관련 커스텀 리소스(VirtualMachine, VirtualMachineInstance 등)를 통해 VM 라이프사이클을 선언적으로 관리합니다.
- VM은 Pod로 변환되어 실행되며, virt-launcher 컨테이너 내에서 libvirt와 QEMU를 통해 VM 프로세스가 실행됩니다.
- KubeVirt의 스토리지 시스템은 컨테이너 디스크, PVC, 데이터 볼륨 등 다양한 옵션을 제공합니다.
- 네트워킹은 기본 Pod 네트워크와 Multus CNI를 통한 고급 네트워킹 옵션을 지원합니다.
- kubevirt-operator는 전체 KubeVirt 스택의 설치, 업그레이드, 구성을 관리합니다.
- CDI, Cluster API 등의 확장 프로젝트와 통합되어 보다 완전한 VM 관리 환경을 제공합니다.