virtbench로 KubeVirt 성능 벤치마킹

출처: CNCF Blog

2026년 6월 8일 게시
작성자: Bob Glithero, Senior Technical Product Marketing Manager, Portworx by Everpure

CNCF 프로젝트가 이 글에서 강조됨

 
 

 
 

전통적인 하이퍼바이저에서 KubeVirt로 VM 자산을 마이그레이션하는 조직은 많은 Kubernetes 가시성 도구가 컨테이너 워크로드를 위해 설계되었으며 VM 중심 운영 메트릭을 다루지 못한다는 사실을 종종 발견합니다. KubeVirt가 VM을 pod로 스케줄링하지만, 성능 변수는 근본적으로 다릅니다—Kubernetes 스케줄러 지연, CSI 프로비저너 처리량, SDN 오버레이 오버헤드가 표준 kubectl 메트릭이나 pod‑레벨 모니터링으로는 드러나지 않는 방식으로 상호 작용합니다.

플랫폼 엔지니어링 팀은 컨테이너 벤치마크가 무시하는 질문에 대해 정량적이고 재현 가능한 답이 필요합니다:

• Time‑to‑Ready: API 호출부터 게스트 OS 네트워크 접근이 확인될 때까지의 실제 경과 시간—pod/Running이 아니라.
• Burst Capacity: 동시 VM 생성 요청(부팅 폭풍) 하에서 컨트롤 플레인 및 스토리지 서브시스템의 동작.
• Live Migration Stun Time: 오버레이 네트워크를 통한 VMI 실시간 마이그레이션 중 네트워크 수준에서 발생하는 정확한 중단 창.

이러한 운영 특성을 측정하기 위해 우리는 KubeVirt Performance Benchmarking Toolkit (virtbench) 을 개발했습니다. 이는 KubeVirt가 활성화된 클러스터 전반에 걸쳐 재현 가능한 스트레스 테스트를 실행하기 위한 오픈소스 CLI 프레임워크이며, OpenShift 상의 KubeVirt와 CSI‑호환 스토리지를 사용하는 기타 환경을 모두 지원합니다.

VM 기반 워크로드에 대한 벤치마킹 고려사항

표준 Kubernetes 가시성 도구는 VM‑급 워크로드가 성능 저하를 겪고 있어도 “정상” 상태를 반환할 수 있습니다. 이는 다음 세 가지 아키텍처 불일치 때문입니다:

Pod readiness ≠ VM readiness. Kubernetes Ready 조건은 컨테이너 프로세스가 시작될 때(보통 밀리초 단위) 충족됩니다. KubeVirt VMI는 게스트 커널 부팅, 사용자 공간 서비스 초기화, 게스트 에이전트가 하트비트를 보고할 때까지 운영상 준비가 된 것이 아닙니다. pod/Running 시점에서 시계를 멈추는 벤치마크는 실제 Time‑to‑Ready를 수분 단위로 과소평가합니다. virtbench는 클러스터 내부 ssh-test-pod 를 이용해 VMI의 게스트 네트워크 스택을 지속적으로 탐색하고, SSH 접속이 확인될 때만 측정을 종료합니다.

멀티 디스크 VM에서의 CSI 프로비저너 부하. 실제 운영 환경에서는 VM당 여러 PVC가 필요합니다—부팅 볼륨, 스왑 볼륨, 고 IOPS 데이터 볼륨 등. 컨테이너 중심 벤치마크는 CSI 드라이버가 단일 VMI에 여러 블록 디바이스를 동시에 프로비저닝하고 핫‑앳치하는 능력을 검증하지 못합니다. virtbench는 이러한 구성을 시뮬레이션하여 DataVolume → PVC → 블록 디바이스 연결 파이프라인을 부하 상태에서 실행합니다.

오버레이 네트워크 기반 실시간 마이그레이션 vs. vMotion. vMotion은 전용 고대역폭 TCP 채널을 통해 실행 중인 메모리 상태를 전송합니다. KubeVirt 실시간 마이그레이션은 동일한 메모리 전송을 클러스터 SDN 오버레이(예: OVN‑Kubernetes)를 통해 수행하므로 지연이 추가되고 워크로드 트래픽과 경쟁합니다. virtbench는 순차 및 병렬 마이그레이션 시나리오 모두에 대해 VMI 네트워크 인터페이스가 사용 불가능해지는 stun time을 측정합니다.

virtbench가 VM 준비 상태를 측정하는 방식

virtbench는 클러스터 내부 헬퍼 pod을 활용하는 클라이언트‑사이드 오케스트레이션 모델을 사용합니다. 측정 파이프라인은 다음과 같이 진행됩니다:

• API 트리거: virtbench 가 VirtualMachine 객체를 Kubernetes API 서버에 제출하면, CSI 드라이버를 통해 연관된 DataVolume 및 PVC 리소스가 생성됩니다.
• 상태 머신 추적: CLI 가 VMI 상태를 폴링하면서 Pending → Scheduled → Bound → Running 전체 전이 과정을 추적합니다.
• 게스트 네트워크 탐색: 클러스터 내부에 배포된 ssh-test-pod 가 각 VMI의 할당 IP 주소에 대해 지속적인 TCP 프로브를 전송합니다.
• 측정 완료: TCP 핸드셰이크가 성공적으로 이루어져 게스트 네트워크 스택이 완전히 가동될 때만 타이머가 종료됩니다.

결과는 구조화된 JSON 및 CSV 형태로 출력된 뒤, 인터랙티브 HTML 대시보드 로 렌더링되어 분석에 활용됩니다. 이 도구는 네 개의 내부 벤치마크 엔진—DataSource Clone, Migration, Capacity, Failure Recovery—을 구동하며, 각각 KubeVirt 및 스토리지 API에 대한 별도 모듈로 구현됩니다.

Figure 1: virtbench 아키텍처

virtbench에 포함된 벤치마크 시나리오

virtbench는 다음 여섯 가지 준비된 테스트 시나리오를 제공합니다:

성능 병목 현상 시각화

결과는 자동으로 다중 차트 HTML 대시보드에 렌더링됩니다.

Figure 2: 성능 대시보드

각 차트는 별개의 측정 단계에 대응합니다:

• Creation Duration (파란색): 순차 부하 하에서 VM당 프로비저닝 지연—스토리지와 스케줄러 베이스라인을 설정합니다.
• Boot Storm (초록색): N개의 동시 요청 하에서 프로비저닝 지연—CSI 드라이버 또는 etcd 쓰기 처리량의 포화 지점을 드러냅니다.
• Live Migration (주황색): 노드 퇴거 과정에서 VMI당 마이그레이션 소요 시간 및 stun time—유지보수 창 SLA를 정의하는 데 활용됩니다.

Creation Summary 표는 전체 소요 시간을 clone_duration(CSI 복사 시간), running_time(kubelet 컨테이너 시작), ping_time(게스트 네트워크 탐색) 세 하위 단계로 분해합니다. 이를 통해 회귀가 스토리지 레이어, 컨테이너 런타임, 혹은 게스트 OS 초기화 중 어느 부분에서 발생했는지 명확히 파악할 수 있습니다.

다양한 벤치마크 접근 방식 비교

※ 참고: 향후 릴리스에서는 게스트 OS 내부에서 I/O 벤치마크를 수행할 수 있도록 VM 내 fio 툴링을 포함할 예정입니다.

첫 번째 virtbench 테스트 실행하기

virtbench는 스테이징 CI 파이프라인에 쉽게 통합되도록 설계되었습니다. 따라서 스토리지 어레이 업그레이드, CNI 교체, Kubernetes 버전 업데이트 등 인프라 변경 전후에 실행해 성능 회귀를 프로덕션에 반영되기 전에 감지할 수 있습니다.

벤치마크 데이터는 환경마다 크게 달라지므로, 공유된 방법론과 재현 가능한 테스트 접근 방식은 KubeVirt 커뮤니티 전체에 큰