KubeVirt: Kubernetes 환경에서 가상머신을 관리하는 차세대 가상화 플랫폼

 

KubeVirt: Kubernetes 환경에서 가상머신을 관리하는 차세대 가상화 플랫폼

1. 서론: 가상화와 컨테이너 오케스트레이션의 융합

현대 기업의 IT 인프라는 컨테이너화된 애플리케이션과 전통적인 가상머신(VM) 기반 워크로드가 공존하는 하이브리드 환경으로 진화하고 있습니다. Kubernetes는 컨테이너 오케스트레이션의 사실상 표준(de facto standard)으로 자리매김했지만, 레거시 애플리케이션이나 특수한 요구사항을 가진 워크로드는 여전히 가상머신 환경을 필요로 합니다. 이러한 인프라 이원화는 운영 복잡성을 증가시키고, 관리 도구의 파편화를 초래하며, DevOps 팀에게 상당한 부담을 안겨줍니다.

KubeVirt는 이러한 문제를 해결하기 위해 등장한 Kubernetes의 확장 프로젝트로, Kubernetes 클러스터 내에서 가상머신과 컨테이너를 동시에 실행하고 관리할 수 있게 해주는 가상화 API 및 런타임입니다. Red Hat이 2016년에 시작한 이 오픈소스 프로젝트는 2019년 Cloud Native Computing Foundation(CNCF)에 합류했으며, Amadeus, Apple, CloudFlare, IBM, NEC, Nvidia, SAP, SUSE 등 주요 기술 기업들의 기여를 받고 있습니다.

2025년 State of Production Kubernetes 보고서에 따르면, 조사 대상 Kubernetes 사용 조직의 86%가 KubeVirt를 인지하고 있으며, 26%가 프로덕션 환경에서 실제로 사용하고 있고, 추가로 5%가 실험을 진행한 것으로 나타났습니다. 특히 5,000명 이상의 대기업에서는 52%가 KubeVirt를 활발히 사용하고 있어, 엔터프라이즈 채택률이 급격히 증가하고 있음을 보여줍니다.

2. KubeVirt의 아키텍처 및 핵심 구성요소

2.1 아키텍처 개요

KubeVirt는 Kubernetes를 확장하여 Custom Resource Definition(CRD)과 컨트롤러를 도입함으로써 가상머신을 Kubernetes 네이티브 객체로 정의하고 관리할 수 있게 합니다. 내부적으로는 신뢰할 수 있는 가상화 계층인 libvirt와 QEMU를 활용하여 가상머신을 프로비저닝하고 관리합니다.

2.2 핵심 구성요소

KubeVirt 시스템은 다음과 같은 주요 컴포넌트들로 구성됩니다:

1. virt-api: Kubernetes API 서버와 상호작용하며 가상머신 관련 API 요청을 처리하는 서비스입니다.
2. virt-controller: virt-api를 통해 생성되거나 업데이트된 새로운 객체를 감시하고, 객체 상태가 요청된 상태와 일치하도록 보장하는 컨트롤러입니다.
3. virt-handler: DaemonSet으로 배포되는 노드 컴포넌트로, 클러스터 레벨의 가상머신 객체를 virt-launcher에서 실행되는 libvirtd 도메인과 동기화합니다. 네트워킹 및 스토리지 구성과 같은 노드 중심 작업을 수행합니다.
4. virt-launcher: libvirt와 QEMU를 실행하여 가상머신 환경을 제공하는 노드 컴포넌트입니다.
5. virt-operator: KubeVirt 애플리케이션 관리를 위한 Kubernetes Operator 패턴을 구현합니다.
6. virtctl: KubeVirt 전용 CLI 도구로, kubectl이 Kubernetes에 대해 수행하는 역할과 유사하게 가상머신 관리를 위한 주요 커맨드라인 인터페이스입니다.

2.3 주요 Custom Resource Definitions

KubeVirt는 다음과 같은 CRD를 도입합니다:

• VirtualMachine(VM): 가상머신의 정의와 생명주기를 관리
• VirtualMachineInstance(VMI): 실행 중인 가상머신 인스턴스를 나타냄
• VirtualMachineInstanceMigration: 가상머신의 라이브 마이그레이션을 관리
• VirtualMachineInstanceReplicaSet: 여러 VM 인스턴스를 관리하는 복제 세트

3. KubeVirt의 주요 특장점

3.1 통합 관리 및 운영 효율성

KubeVirt는 VM과 컨테이너를 Kubernetes 생태계에 통합함으로써 단일 인터페이스를 통해 양쪽 워크로드를 관리할 수 있게 합니다. 이는 운영을 단순화하고 별도 환경 유지에 따른 복잡성을 감소시킵니다.

3.2 리소스 최적화 및 비용 효율성

KubeVirt는 특수 가상화 인프라에 의존하는 대신 범용 하드웨어에서 VM을 실행할 수 있게 함으로써 하드웨어 비용을 절감할 수 있습니다. Kubernetes의 리소스 스케줄링 기능은 컨테이너와 VM 모두에 리소스를 효율적으로 할당하여 운영 효율성을 더욱 향상시킵니다.

3.3 라이브 마이그레이션 지원

KubeVirt는 가상머신의 라이브 마이그레이션을 지원하여 다운타임 없이 노드 간 VM 이동이 가능합니다. 이는 고가용성 유지와 서비스 중단 최소화에 필수적입니다.

3.4 최신 기능 강화 (v1.5 및 v1.6)

2025년 3월 출시된 KubeVirt v1.5는 Kubernetes v1.32와 정렬되며, CPU, 메모리, 볼륨 리소스의 핫플러깅을 지원하는 VM Live Update 기능, Network Binding Plugin, IOThreads 지정을 통한 CPU 성능 개선, 네트워크 인터페이스의 링크 상태 동적 제어 등의 기능을 제공합니다.

2025년 7월 출시된 v1.6.0은 ImageVolume을 사용한 컨테이너 디스크 기능 구현, passt 네트워크 바인딩 플러그인의 vhost-user 모드 지원, ARM64 클러스터에 대한 노드 레이블러 활성화, 핫플러그 가능한 디스크에서 부팅 기능, panic device 지원 등을 추가했습니다.

3.5 Kubernetes 생태계와의 긴밀한 통합

KubeVirt는 VM 스토리지를 위한 Persistent Volume Claims(PVCs), VM 배포를 위한 Kubernetes 파드 등 Kubernetes의 네이티브 기능을 활용합니다. 이를 통해 VM과 컨테이너 전반에 걸쳐 통합된 관리 경험을 제공합니다.

3.6 확장성 및 유연성

KubeVirt는 Kubernetes의 강력한 오케스트레이션 기능을 활용하여 동적 스케일링과 유연한 리소스 할당을 가능하게 합니다. 이를 통해 변화하는 워크로드 수요와 비즈니스 요구사항에 쉽게 적응할 수 있습니다.

3.7 레거시 애플리케이션 현대화 경로

KubeVirt는 레거시 애플리케이션의 점진적 현대화를 촉진합니다. 조직은 새로운 애플리케이션을 컨테이너화하면서 기존 VM을 계속 실행할 수 있어, 클라우드 네이티브 아키텍처로의 원활한 전환을 제공합니다.

4. KubeVirt 설치 및 사용법

4.1 사전 요구사항

KubeVirt 설치를 위한 주요 요구사항은 다음과 같습니다:

• 최신 3개 Kubernetes 릴리스 중 하나를 기반으로 한 Kubernetes 클러스터 또는 파생 버전(예: OpenShift)
• KubeVirt의 특권 DaemonSet 실행을 위해 Kubernetes apiserver에서 --allow-privileged=true 설정
• 컨테이너 런타임(containerd, cri-o 등)
• SELinux가 활성화된 노드의 경우 container-selinux 설치 (최소 버전 2.170.0 권장)

4.2 기본 설치 절차

단계 1: 최신 버전 확인 및 환경 변수 설정

export VERSION=$(curl -s https://api.github.com/repos/kubevirt/kubevirt/releases/latest | awk -F '[ \t":]+' '/tag_name/ {print $3}')
echo $VERSION

단계 2: KubeVirt Operator 설치

다음 명령어를 실행하여 "kubevirt" 네임스페이스를 생성하고, KubeVirt용 Custom Resource Definitions를 설치하며, KubeVirt 설치를 관리할 Operator를 배포합니다:

kubectl create -f https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/kubevirt-operator.yaml

단계 3: KubeVirt Custom Resource 생성

KubeVirt Custom Resource를 추가하여 Operator가 KubeVirt의 나머지 구성 요소를 설치하도록 트리거합니다:

kubectl create -f https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/kubevirt-cr.yaml

단계 4: 에뮬레이션 모드 활성화 (필요한 경우)

Minikube와 같은 테스트 환경에서 VM 내에서 실행해야 하는 경우, 로컬 가상화 하드웨어에 직접 액세스할 수 없을 수 있으므로 에뮬레이션 모드를 활성화해야 합니다:

kubectl -n kubevirt patch kubevirt kubevirt --type=merge --patch '{"spec":{"configuration":{"developerConfiguration":{"useEmulation":true}}}}'

단계 5: 설치 확인

kubectl get pods -n kubevirt

7개의 파드(virt-api, virt-controller, virt-handler, virt-operator), 3개의 서비스, 1개의 DaemonSet, 3개의 Deployment, 3개의 ReplicaSet이 실행 중이어야 합니다.

4.3 virtctl CLI 도구 설치

virtctl은 가상머신과 상호작용하기 위한 필수 CLI 도구입니다:

VERSION=$(kubectl get kubevirt.kubevirt.io/kubevirt -n kubevirt -o=jsonpath="{.status.observedKubeVirtVersion}")
ARCH=$(uname -s | tr A-Z a-z)-$(uname -m | sed 's/x86_64/amd64/')
curl -L -o virtctl https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/virtctl-${VERSION}-${ARCH}
chmod +x virtctl
sudo install virtctl /usr/local/bin

또는 krew 플러그인 매니저를 통해 설치할 수 있습니다:

kubectl krew install virt

4.4 가상머신 생성 및 관리

가상머신 정의 생성 예시

간단한 30MB Linux VM을 생성하는 YAML 예시입니다:

kubectl apply -f https://kubevirt.io/labs/manifests/vm.yaml

가상머신 시작 및 상태 확인

# VM 시작
virtctl start testvm

# VM 상태 확인
kubectl get vm,vmi,pod

# VM 콘솔 접속
virtctl console testvm

4.5 Containerized Data Importer (CDI) 설치

KubeVirt VM 디스크를 Kubernetes Persistent Volume으로 정의하기 위해서는 KubeVirt Containerized Data Importer(CDI)를 설치해야 합니다. CDI는 VM 이미지를 PVC로 가져오는 기능을 제공합니다.

5. 개발 시 주의사항 및 모범 사례

5.1 네트워킹 구성 관련 주의사항

네트워킹은 대규모로 KubeVirt를 관리하는 팀에게 가장 중요한 문제점 중 하나입니다. Kubernetes는 Container Network Interface(CNI) 플러그인에 크게 의존하며, VM을 도입하면 복잡성과 충돌이 증가할 수 있습니다.

라이브 마이그레이션 네트워크 제약

KubeVirt는 기본적으로 bridge 네트워크 인터페이스를 사용하는 가상머신의 라이브 마이그레이션을 지원하지 않습니다. KubeVirt는 메모리와 디스크 마이그레이션만 잘 처리하며, 마이그레이션 중 VM의 IP가 변경되거나 네트워크가 중단되면 원활한 라이브 마이그레이션을 달성할 수 없습니다.

해결 방법: Kube-OVN과 같은 CNI를 활용하면 IP 보존과 0.5초 미만의 네트워크 다운타임으로 네트워크 투명 라이브 마이그레이션이 가능합니다. VM Spec에 kubevirt.io/allow-pod-bridge-network-live-migration: "true" 어노테이션을 추가하면 됩니다.

5.2 스토리지 구성

사용자의 거의 절반(45%)이 영구 스토리지 설정의 어려움을 언급하고 있습니다. KubeVirt는 스토리지 시스템과의 통합이 기본 구현 기능이 아닙니다. KubeVirt에 연결되거나 표준화된 스토리지 요소가 없으면, 다양한 스토리지 벤더가 쉽게 작동하거나 지원을 제공하지 못할 수 있습니다.

모범 사례:

• Container Storage Interface(CSI)를 지원하는 스토리지 벤더 선택
• 스냅샷, 확장 등의 일반적인 기능을 지원하는 CSI 드라이버 사용
• Persistent Volume Claims(PVCs)를 활용한 VM 스토리지 관리

5.3 권한 관리

v1.5에서는 보안 강화 조치(최소 권한 원칙)로 인해 라이브 마이그레이션 트리거 권한이 변경되었습니다. VirtualMachineInstanceMigrations 생성, 편집, 삭제 권한이 더 이상 기본적으로 네임스페이스 관리자에게 할당되지 않습니다.

5.4 성능 최적화

Nested Virtualization 활성화

베어메탈이 아닌 환경에서 KubeVirt를 실행할 경우, nested virtualization을 활성화해야 합니다. 이것이 불가능할 경우 소프트웨어 에뮬레이션을 허용할 수 있지만, nested virtualization 활성화가 선호됩니다.

리소스 할당

v1.5에서는 virtqueue 매핑을 통해 사용할 IOThreads 수를 지정할 수 있어 CPU 성능을 향상시킬 수 있습니다.

5.5 마이그레이션 전략

대규모 환경에서는 단계적 마이그레이션 접근 방식을 사용하는 것이 좋습니다. Red Hat의 Migration Toolkit for Virtualization(커뮤니티 Forklift 프로젝트 기반)을 활용하여 가상화 환경을 인벤토리하고 cold 또는 warm 마이그레이션을 수행할 수 있습니다.

5.6 베어메탈 배포 권장

KubeVirt를 다른 VM이나 퍼블릭 클라우드 인스턴스 위에 중첩하여 실행하는 것은 기술적으로 가능하지만 소프트웨어 에뮬레이션이 필요하여 워크로드 성능에 영향을 미칩니다. 베어메탈 Kubernetes에서 KubeVirt를 실행하는 것이 훨씬 합리적입니다.

5.7 테스트 및 검증

기능 테스트 실행

개발 환경에서 다음 명령으로 기능 테스트를 실행할 수 있습니다:

make cluster-sync  # 코드 동기화
make functest      # 기능 테스트 실행

특정 테스트만 실행하려면:

FUNC_TEST_ARGS='--focus-file=vmi_networking' make functest

5.8 프로덕션 배포 시 고려사항

프로덕션 환경으로 이전하기 전에 다음을 고려해야 합니다:

• AlmaLinux와 같은 안정적인 OS를 가상화 기반으로 선택
• cgroup v2를 리소스 격리 메커니즘으로 사용
• Kubernetes, containerd 및 KubeVirt 내의 특정 문제에 대비

6. KubeVirt의 단점 및 한계

6.1 기술적 복잡성 및 학습 곡선

2025년 State of Production Kubernetes 연구에 따르면 가장 일반적으로 보고된 문제점은 기술적 복잡성과 전환에 필요한 노력입니다. 사용자의 거의 절반(45%)이 영구 스토리지 설정의 어려움을 언급했으며, 43%는 기존 VM을 Kubernetes 오케스트레이션과 호환되는 형식으로 변환하는 데 필요한 수동 작업에 어려움을 겪고 있습니다.

주목할 만한 장애물은 다음과 같습니다:

• CRD 및 가상화 내부에 익숙하지 않은 팀의 가파른 학습 곡선
• 성숙한 하이퍼바이저에 비해 제한된 문서
• 기존 스토리지 및 네트워킹 스택과의 통합 복잡성
• 베어메탈 하이퍼바이저에 비해 성능 트레이드오프

6.2 문화적 저항

문화적 저항도 요인입니다. 특히 VMware에 대한 깊은 전문 지식을 가진 팀의 경우 38%가 KubeVirt로 전환할 때 내부 반발을 언급했습니다. 비슷한 수의 사용자가 엔터프라이즈급 지원 부족과 KubeVirt 자체 설치 및 구성의 어려움을 지적했습니다.

6.3 제한적인 기능성

KubeVirt는 Custom Resource Definition(CRD) 구현이므로 VM을 관리하고 조정하는 데 더 많은 유연성을 제공하지만, VM이 Virtlet만큼 Kubernetes에 잘 통합되지 않음을 의미합니다. 관리자는 다른 Kubernetes 구성 요소와 별도로 VM을 관리해야 하며, 이는 추가 학습 곡선을 요구합니다.

6.4 UI 부재

KubeVirt는 기본적으로 UI와 함께 제공되지 않습니다. 모든 것이 CLI 또는 API입니다. 이는 Kubernetes와 컨테이너 운영에 익숙한 클러스터 관리자에게는 완벽히 괜찮을 수 있지만, GUI에서 작동하는 데 익숙한 가상화 관리자에게는 도전적인 격차가 될 수 있습니다. VM을 시작하거나 중지하는 것과 같은 간단한 작업조차도 VM 매니페스트를 패치하거나 virtctl 명령줄을 사용해야 합니다.

6.5 인프라 재구성 요구

KubeVirt 도입에는 스토리지, 컴퓨팅, 네트워크를 포함한 기존 IT 인프라에 대한 상당한 변경이 필요합니다. Kubernetes와 비교하여 기존 VM 관리 방식에서 벗어나 Kubernetes 중심 접근 방식으로 전환해야 하므로 상당한 마찰이 발생합니다. 가상 인프라 관리자는 재교육이 필요하며, 조직은 새로운 제어 플레인을 통해 기존 VM 워크로드를 관리하기 위해 전체 팀을 재교육해야 합니다.

6.6 고가용성 및 재해복구의 복잡성

고가용성 및 재해복구(HA/DR) 요구사항과 비용의 균형을 맞춰야 합니다. 두 개의 별도 Kubernetes 클러스터를 실행하고 Portworx MetroDR과 같은 것을 사용하여 두 클러스터 간 복제를 실행하는 옵션이 있지만, 이는 Portworx와 MetroDR의 비용을 추가하면 소규모 애플리케이션에는 비싼 솔루션입니다.

6.7 프로덕션 준비 기간

Gartner의 부사장 겸 애널리스트인 Michael Warrilow에 따르면, "대부분의 기업은 적어도 2028년까지 기존 프로덕션 가상 워크로드의 재가상화가 기술적으로 가장 도전적이고 위험하며 정당화하기 어렵다는 것을 발견할 가능성이 높습니다".

7. 2025년 최신 동향 및 실제 도입 현황

7.1 급격한 채택률 증가

Portworx의 2024 Voice of Kubernetes Experts 보고서에 따르면, 조사 대상 조직의 58%가 KubeVirt와 같은 기술을 사용하여 일부 가상머신을 Kubernetes 관리로 마이그레이션할 계획이며, 그 중 65%는 향후 2년 내에 그렇게 할 계획입니다. 이는 단순한 트렌드가 아니라 운영 통합과 비용 효율성을 향한 전략적 전환입니다.

2025년 State of Production Kubernetes 보고서에서는 레거시 앱이 뒤처지지 않고 있으며, 31%가 클러스터에서 VM을 재배치하기 위해 KubeVirt에 베팅하고 있다고 밝혔습니다.

7.2 AI 워크로드와의 통합

2025년 Kubernetes의 가장 중요한 트렌드 중 하나는 Kubernetes가 단순히 컨테이너 오케스트레이션을 위한 것이 아니라 VM, 서버리스 함수, AI 파이프라인, 엣지 디바이스를 포함한 다양한 워크로드를 관리하기 위한 범용 제어 플레인으로 부상하고 있다는 것입니다. KubeVirt와 같은 프로젝트는 전통적인 워크로드와 클라우드 네이티브 환경을 연결하며 지속적으로 주목을 받고 있습니다.

7.3 주요 기업의 후원 및 커뮤니티 성장

KubeVirt는 초기 단계에서 arm, ByteDance, CloudFlare, Nvidia와 같은 대형 기술 기업들의 지원을 받는 안정적인 플랫폼으로 성숙했습니다.

7.4 상용 솔루션의 등장

Red Hat의 OpenShift Virtualization 선임 관리자인 Sachin Mullick은 "지난 1년 동안 KubeVirt와 그 생태계의 채택 및 사용이 여러 배 증가했으며, 2025년에도 관심 수준이 계속되고 있습니다. 많은 고객이 현재 가상화 하이퍼바이저에 대한 대안을 찾고 있으며, KubeVirt는 그들에게 실행 가능한 전진 경로를 제공합니다"라고 말했습니다.

7.5 KubeVirt Summit 2025

KubeVirt Summit은 5년째를 맞이한 연례 온라인 컨퍼런스로, 2025년 10월 16일에 개최됩니다. 전체 커뮤니티가 만나 KubeVirt의 모든 것을 선보이며, 새로운 기능 소개, 프로덕션 배포, 아키텍처 변경 제안, 심층 튜토리얼 제공 등이 이루어집니다.

8. 결론

KubeVirt는 가상머신과 컨테이너 워크로드를 단일 Kubernetes 플랫폼에서 관리할 수 있게 하는 혁신적인 솔루션입니다. Kubernetes가 2014년 Google에 의해 출시된 이후 10년 이상 동안 조직이 애플리케이션을 구축, 배포, 관리하는 방식을 극적으로 변화시켰습니다. KubeVirt는 이러한 진화의 자연스러운 연장선상에 있으며, 전통적인 가상화와 현대적인 컨테이너 오케스트레이션 사이의 간극을 메우는 역할을 합니다.

KubeVirt v1.0의 출시는 커뮤니티의 놀라운 성과와 광범위한 채택을 의미하는 중요한 이정표였으며, 프로덕션 준비가 완료된 가상머신 관리 프로젝트로서 Kubernetes 네이티브 API로 원활하게 작동합니다. 2025년 현재 v1.5와 v1.6이 출시되면서 기능과 안정성이 지속적으로 개선되고 있습니다.

그러나 KubeVirt의 채택에는 여전히 도전 과제가 존재합니다. 기술적 복잡성, 학습 곡선, 네트워킹 및 스토리지 구성의 어려움, 문화적 저항 등이 주요 장애물입니다. 현재 KubeVirt는 Kubernetes에 이미 깊이 투자하고 패러다임 혼합의 트레이드오프를 이해하는 고급 팀에게 가장 적합합니다. 프로젝트가 성숙하고 더 나은 도구를 확보하며 생태계가 확장됨에 따라, 하이브리드 인프라 관리의 주요 기둥이 될 수 있습니다.

KubeVirt는 전통적인 가상화와 현대적인 컨테이너화된 인프라 사이의 중요한 가교입니다. VM 관리를 Kubernetes로 가져옴으로써, 조직이 기존 애플리케이션과 지식을 활용하면서 점차적으로 더 컨테이너 중심적인 미래로 나아갈 수 있게 합니다.

마이그레이션 전략을 계획하거나, 레거시 애플리케이션을 관리하거나, 단순히 인프라를 통합하려는 경우, KubeVirt는 클라우드 네이티브 툴킷에서 고려할 가치가 있는 솔루션입니다. 2025년 현재 엔터프라이즈 채택률이 급격히 증가하고 있으며, 주요 기술 기업들의 지원과 활발한 커뮤니티를 통해 KubeVirt는 가상화의 미래를 형성하는 중요한 역할을 하고 있습니다.

---

Ponder...

Q1: KubeVirt를 기존 VMware 환경에서 프로덕션으로 마이그레이션할 때 가장 먼저 고려해야 할 기술적 위험 요소는 무엇이며, 이를 완화하기 위한 단계적 전환 전략을 어떻게 수립해야 할까요?

Q2: 2025년 현재 KubeVirt의 네트워킹 제약사항(특히 bridge 모드에서의 라이브 마이그레이션 제한)이 엔터프라이즈 환경에서 미치는 영향은 무엇이며, Kube-OVN이나 Cilium과 같은 고급 CNI 솔루션을 활용하여 이러한 한계를 극복할 수 있는 구체적인 아키텍처 패턴은 무엇일까요?

Q3: KubeVirt와 전통적인 하이퍼바이저(예: VMware vSphere, Hyper-V) 간의 성능, TCO(Total Cost of Ownership), 그리고 운영 복잡성을 비교했을 때, 어떤 워크로드 특성과 조직 성숙도 수준에서 KubeVirt로의 전환이 가장 정당화될 수 있을까요?