- 들어가며
- binding은 정확히 무엇을 의미하는가
- 1. masquerade binding
- 2. bridge binding
- 3. passt binding
- 4. SR-IOV binding
- plugin binding은 왜 필요한가
- binding별로 IP 모델은 어떻게 다른가
- migration과의 관계
- 자주 하는 오해
- 선택 기준을 실무적으로 정리하면
- 마무리
들어가며
KubeVirt 네트워크를 이해할 때 가장 중요한 선택지는 binding이다. 같은 VMI라도 어떤 binding을 쓰느냐에 따라 guest가 네트워크를 보는 방식, 서비스 노출 방식, 성능, live migration 적합성이 달라진다.
staging/src/kubevirt.io/api/core/v1/schema.go를 보면 주요 interface binding 종류가 드러난다.
BridgeMasqueradeSRIOVPasstBindingBindingplugin
즉 KubeVirt는 하나의 정답 네트워크 모델만 강요하지 않는다. 대신 여러 wiring 방식을 제공한다.
binding은 정확히 무엇을 의미하는가
공식 developer guide인 docs/network/network-binding-plugin.md가 잘 정리하듯, binding은 "도메인 VM NIC를 Pod 안에서 어떻게 guest에 연결할 것인가"를 정의하는 계층이다.
여기에는 다음이 포함된다.
- domain vNIC 구성
- Pod 내부 네트워크 구성
- 필요하면 DHCP 같은 guest 전달 서비스
즉 binding은 단순 API 옵션이 아니라 guest NIC wiring 전략이다.
1. masquerade binding
가장 무난하고 Kubernetes 친화적인 기본 선택지다.
어떻게 동작하는가
- Pod는 CNI로 primary IP를 받는다
- guest는 내부 CIDR의 별도 IP를 받는다
- KubeVirt가 DHCP와 NAT를 구성한다
- 외부 통신은 Pod IP를 통해 나간다
장점
- Pod 네트워크와 충돌이 적다
- 서비스 노출과 port forwarding 모델이 익숙하다
- migration과 일반 운영에서 다루기 쉽다
단점
- guest가 네트워크에 직접 노출되는 구조는 아니다
- NAT 오버헤드와 포트 설계 고려가 필요하다
운영 편의성과 범용성 때문에 가장 먼저 떠올릴 선택지다.
2. bridge binding
bridge binding은 guest를 네트워크에 더 직접 연결하려는 모델이다.
어떻게 동작하는가
- Pod 인터페이스와 bridge, TAP을 묶어 guest를 직접 연결한다
- guest가 Pod 네트워크에 더 직접적인 endpoint처럼 동작한다
- DHCP와 bridge wiring이 중요하다
장점
- guest가 더 직접적인 네트워크 연결성을 가질 수 있다
- NAT를 피할 수 있는 시나리오가 있다
단점
- Pod 쪽 네트워크 구조가 더 민감하게 재배선된다
- 운영자가 Pod IP와 guest reachability를 더 신경 써야 한다
bridge는 "컨테이너처럼 안전한 기본값"보다 "guest를 더 직접 노출"하는 쪽에 가깝다.
3. passt binding
schema.go는 PasstBinding을 별도 core binding으로 둔다. passt는 user-mode networking 기반의 접근으로 이해하면 좋다.
장점
- 비교적 간결한 연결 모델을 제공한다
- 일부 환경에서 bridge보다 구성 부담이 적을 수 있다
단점
- 성능과 기능 면에서 직접 커널 datapath를 쓰는 모델과 trade-off가 있다
- feature gate, 지원 범위, 운영 호환성을 확인해야 한다
pkg/network/passt와 binding plugin 문서를 같이 읽으면, passt는 "고성능 L2 직결"보다 유저모드 친화적 네트워킹에 더 가깝다는 점이 보인다.
4. SR-IOV binding
SR-IOV는 가장 성능 지향적인 선택지다. 대신 Kubernetes와 호스트, NIC, IOMMU, VFIO 구성이 함께 맞아야 한다.
docs/network/sriov.md를 보면 관련 컴포넌트가 꽤 많다.
- SR-IOV device plugin
- SR-IOV CNI plugin
- Multus
- 필요하면 SR-IOV operator
- KubeVirt의 libvirt domain 구성 로직
어떻게 동작하는가
- device plugin이 VF 자원을 Kubernetes 자원으로 광고
- Multus와 CNI가 Pod namespace 쪽 준비 수행
- KubeVirt는 할당된 PCI 정보를 바탕으로 domain을 VFIO passthrough 형태로 구성
장점
- 높은 성능
- 직접 장치 passthrough에 가까운 네트워크 경로
단점
- 하드웨어와 커널 요구사항이 높다
- migration과 hotplug 제약이 커진다
- 운영 복잡도가 높다
즉 SR-IOV는 범용 기본값이 아니라, 성능을 위해 단순성과 유연성을 일부 포기하는 선택지다.
plugin binding은 왜 필요한가
KubeVirt는 내장 binding만으로 모든 네트워크를 감당하려 하지 않는다. network-binding-plugin.md는 다음 두 방향을 설명한다.
- zero-code plugin
- sidecar 또는 CNI가 포함된 plugin
핵심은 plugin이 domain attachment type, sidecar, custom CNI를 조합해 새로운 binding을 확장 가능하게 만든다는 점이다.
이 설계는 KubeVirt가 네트워크 실험과 확장을 core code에 모두 넣지 않으려는 의도를 보여준다.
binding별로 IP 모델은 어떻게 다른가
이건 운영자가 자주 헷갈리는 포인트다.
masquerade
- Pod IP와 guest IP가 다를 수 있음
- guest IP는 KubeVirt DHCP와 내부 CIDR 기반
bridge
- guest가 네트워크에 더 직접 붙음
- Pod 네트워크를 재배선하는 효과가 큼
passt
- user-mode forwarding 모델에 더 가까움
SR-IOV
- VF passthrough 성격이 강함
- guest가 보다 직접적인 장치 접근을 가짐
즉 "IP를 누가 주는가"의 답도 binding별로 달라진다.
migration과의 관계
binding은 단순 연결성 선택이 아니라 migration 전략에도 큰 영향을 준다.
- masquerade는 가장 migration 친화적이다
- bridge는 구현과 환경에 따라 더 조심해야 한다
- SR-IOV는 device passthrough 특성 때문에 제약이 크다
- plugin binding은 문서화된 migration method 지원 여부를 꼭 확인해야 한다
network-binding-plugin.md도 binding plugin이 migration을 지원하려면 별도의 migration method 선언이 필요하다고 설명한다.
자주 하는 오해
오해 1: bridge가 항상 masquerade보다 낫다
아니다. 더 직접적인 연결성이 장점일 수 있지만, 운영 단순성과 migration 친화성은 masquerade가 더 나을 수 있다.
오해 2: SR-IOV는 그냥 빠른 NIC 옵션일 뿐이다
아니다. 장치 광고, CNI, VFIO, IOMMU, libvirt domain 구성까지 모두 엮인 복합 선택지다.
오해 3: plugin binding은 core binding의 장식이다
아니다. KubeVirt가 네트워크 확장을 모듈식으로 다루기 위한 중요한 설계다.
선택 기준을 실무적으로 정리하면
- 가장 안전한 기본값이 필요하면
masquerade - guest의 직접 연결성이 중요하면
bridge - 특정 user-mode 네트워킹 특성이 필요하면
passt - 최대 성능과 직접 장치 접근이 필요하면
SR-IOV
결국 binding은 성능 문제이면서 동시에 운영성과 migration 가능성 문제다.
마무리
KubeVirt의 네트워크 binding은 guest NIC를 Pod 안에서 어떻게 wiring할지를 결정하는 핵심 축이다. masquerade는 범용성과 운영 편의, bridge는 더 직접적인 연결성, passt는 user-mode 성격, SR-IOV는 고성능 장치 passthrough라는 뚜렷한 성격을 가진다. 따라서 binding 선택은 단순한 API 옵션이 아니라 네트워크 모델과 운영 전략 전체를 결정하는 아키텍처 선택이다.
다음 글에서는 primary network를 넘어서, Multus와 secondary network가 KubeVirt에 어떻게 연결되는지 살펴보겠다.