Release: – v1.1.0: Alpha – v1.3.0: Beta
KubeVirt는 실행 중인 Virtual Machine(VM)에 네트워크 인터페이스를 핫플러그 및 언플러그하는 기능을 지원합니다.
핫플러그는 브리지 바인딩(bridge binding) 또는 SR-IOV 바인딩을 통해 연결된 virtio 모델을 사용하는 인터페이스에 대해 지원됩니다.
핫-언플러그는 브리지 바인딩을 통해 연결된 인터페이스에 대해서만 지원됩니다.
요구 사항
KubeVirt Virtual Machine에 인터페이스를 추가하려면 먼저 실행 중인 파드에 인터페이스를 추가해야 합니다. 이 작업은 간단하지 않으며 몇 가지 요구사항이 있습니다:
- Multus Dynamic Networks Controller: 이 데몬은 어노테이션 변경 사항을 수신하고 Multus를 트리거하여 이 파드에 대한 새 어태치먼트를 구성합니다.
- 씩(thick) 플러그인으로 실행되는 Multus CNI: 이 Multus 버전은 필요에 따라 특정 파드에 대한 어태치먼트를 생성할 수 있는 엔드포인트를 노출합니다.
네트워크 인터페이스 핫플러그 지원 활성화
네트워크 인터페이스 핫플러그 지원은 기능 게이트(feature gate)를 통해 활성화해야 합니다. KubeVirt CR의 기능 게이트 어레이에는 HotplugNICs가 있어야 합니다.
실행 중인 VM에 인터페이스 추가하기
먼저 VM을 시작합니다. 다음 예제를 참조할 수 있습니다:
---
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: vm-fedora
spec:
running: true
template:
spec:
domain:
devices:
disks:
- disk:
bus: virtio
name: containerdisk
interfaces:
- masquerade: {}
name: defaultnetwork
rng: {}
resources:
requests:
memory: 1024M
networks:
- name: defaultnetwork
pod: {}
terminationGracePeriodSeconds: 0
volumes:
- containerDisk:
image: quay.io/kubevirt/fedora-with-test-tooling-container-disk:devel
name: containerdisk
파드 인터페이스 구성이 보관되는 네트워크 어트리뷰션 정의를 구성해야 합니다. 아래 스니펫은 매우 간단한 예시를 보여줍니다:
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
name: new-fancy-net
spec:
config: '{
"cniVersion": "0.3.1",
"type": "bridge",
"mtu": 1300,
"name":"new-fancy-net"
}'
자세한 내용은 Multus documentation를 참조하세요.
가상 머신이 실행되고 연결 구성이 프로비저닝되면 사용자는 VM 사양 템플릿을 편집하고 원하는 인터페이스와 네트워크를 추가하여 인터페이스 핫플러그 작업을 요청할 수 있습니다:
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: vm-fedora
template:
spec:
domain:
devices:
interfaces:
- name: defaultnetwork
masquerade: {}
# new interface
- name: dyniface1
bridge: {}
networks:
- name: defaultnetwork
pod: {}
# new network
- name: dyniface1
multus:
networkName: new-fancy-net
...
참고: 가상 머신 사양 템플릿을 편집하여 핫플러그/플러그 인터페이스를 추가하고 제거할 수 있습니다.
인터페이스와 네트워크는 Kubevirt에 의해 해당 VMI 오브젝트에도 추가됩니다.
이제 이 새 인터페이스의 존재 여부에 대한 VMI 상태를 확인할 수 있습니다:
kubectl get vmi vm-fedora -ojsonpath="{ @.status.interfaces }"
실행 중인 VM에서 인터페이스 제거하기
위의 예에 따라 사용자는 VM 사양 템플릿을 편집하여 인터페이스 분리 작업을 요청하고 원하는 인터페이스 상태를 absent로 설정할 수 있습니다:
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: vm-fedora
template:
spec:
domain:
devices:
interfaces:
- name: defaultnetwork
masquerade: {}
# set the interface state to absent
- name: dyniface1
state: absent
bridge: {}
networks:
- name: defaultnetwork
pod: {}
- name: dyniface1
multus:
networkName: new-fancy-net
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: vm-fedora
template:
spec:
domain:
devices:
interfaces:
- name: defaultnetwork
masquerade: {}
# new interface
- name: dyniface1
bridge: {}
networks:
- name: defaultnetwork
pod: {}
# new network
- name: dyniface1
multus:
networkName: new-fancy-net
...
해당 VMI 오브젝트의 인터페이스도 Kubevirt에 의해 ‘absent’ 상태로 설정됩니다.
참고: 버전 v0.59.0 이하의 기존 VM은 핫-언플러그 인터페이스를 지원하지 않습니다.
마이그레이션 기반 핫플러그
클러스터에서 Multus를 씩 플러그(thick plugin)인 및 Multus Dynamic Networks 컨트롤러로 실행하지 않는 경우, VM을 마이그레이션하여 인터페이스를 핫플러그할 수 있습니다.
실제 연결은 즉시 이루어지지 않으며 마이그레이션이 완료되면 게스트에서 새 인터페이스를 사용할 수 있습니다.
새 인터페이스 추가
원하는 인터페이스와 네트워크를 VM 사양 템플릿에 추가합니다:
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: vm-fedora
template:
spec:
domain:
devices:
interfaces:
- name: defaultnetwork
masquerade: {}
# new interface
- name: dyniface1
bridge: {}
networks:
- name: defaultnetwork
pod: {}
# new network
- name: dyniface1
multus:
networkName: new-fancy-net
...
이 시점에서 인터페이스와 네트워크는 해당 VMI 객체에도 추가되지만 게스트에는 연결되지 않습니다.
VM 마이그레이션
cat <<EOF kubectl apply -f -
apiVersion: kubevirt.io/v1
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: vmi-fedora
EOF
자세한 내용은 Live Migration 설명서를 참조하세요.
마이그레이션이 완료되면 VM에 새 인터페이스가 연결됩니다.
참고: 핫플러그 작업과 병행하여 마이그레이션을 수행하지 않는 것이 좋습니다. 마이그레이션을 수행하기 전에 핫플러그가 성공했거나 최소한 VMI 사양에 도달했는지 확인하는 것이 더 안전합니다.
인터페이스 제거
VM 사양 템플릿에서 원하는 인터페이스 상태를 없음으로 설정합니다:
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: vm-fedora
template:
spec:
domain:
devices:
interfaces:
- name: defaultnetwork
masquerade: {}
# set the interface state to absent
- name: dyniface1
state: absent
bridge: {}
networks:
- name: defaultnetwork
pod: {}
- name: dyniface1
multus:
networkName: new-fancy-net
이 시점에서 주체 인터페이스는 게스트에서 분리되어야 하지만 포드에는 존재해야 합니다.
참고: 버전 v0.59.0 이하의 기존 VM은 핫-언플러그 인터페이스를 지원하지 않습니다.
VM 마이그레이션
cat <<EOF kubectl apply -f -
apiVersion: kubevirt.io/v1
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: vmi-fedora
EOF
자세한 내용은 Live Migration 설명서를 참조하세요.
VM이 마이그레이션되면 마이그레이션 대상 포드에 인터페이스가 존재하지 않습니다.
참고: 플러그 분리 작업과 병행하여 마이그레이션을 수행하지 않는 것이 좋습니다. 마이그레이션을 실행하기 전에 플러그 뽑기가 성공했거나 최소한 VMI 사양에 도달했는지 확인하는 것이 더 안전합니다.
SR-IOV 인터페이스
Kubevirt는 실행 중인 VM에 대한 SR-IOV 인터페이스의 핫 플러깅을 지원한다.
브리지 바인딩 인터페이스와 유사하게, VM 사양 템플릿을 편집하고 원하는 SR-IOV 인터페이스와 네트워크를 추가한다:
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: vm-fedora
template:
spec:
domain:
devices:
interfaces:
- name: defaultnetwork
masquerade: {}
# new interface
- name: sriov-net
sriov: {}
networks:
- name: defaultnetwork
pod: {}
# new network
- name: sriov-net
multus:
networkName: sriov-net-1
...
SR-IOV 네트워킹에 대한 자세한 내용은 Interface and Networks 설명서를 참조하세요.
이 시점에서 인터페이스 및 네트워크는 해당 VMI 객체에도 추가되지만 게스트에는 연결되지 않습니다.
VM 마이그레이션
cat <<EOF kubectl apply -f -
apiVersion: kubevirt.io/v1
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: vmi-fedora
EOF
자세한 내용은 Live Migration 설명서를 참조하세요.
VM이 마이그레이션되면 마이그레이션 대상 파드에 인터페이스가 존재하지 않습니다. 리소스를 동적으로 할당하는 쿠버네티스 디바이스 플러그인 API의 제한으로 인해, SR-IOV 디바이스 플러그인은 핫플러그할 Kubevirt에 대한 추가 SR-IOV 리소스를 할당할 수 없습니다. 따라서 SR-IOV 인터페이스 핫플러그는 Multus “thick 버전에 관계없이 마이그레이션 기반 핫플러그로만 제한됩니다.
Virtio 제한 사항
핫플러그 인터페이스는 model: virtio입니다. 각 인터페이스는 VM의 PCI 슬롯을 사용하며 총 최대 32개까지 사용할 수 있다는 몇 가지 제한이 있습니다. 또한 다른 디바이스(예: 디스크, 게스트 에이전트 등)도 이러한 PCI 슬롯을 사용하게 됩니다.
Kubevirt는 추후 핫플러그 작업을 위해 4개의 인터페이스를 위한 리소스를 예약합니다. 실제 사용 가능한 최대 리소스 양은 머신 유형에 따라 달라진다(예: q35는 다른 PCI 슬롯을 추가함). 최대 제한에 대한 자세한 내용은 libvirt 설명서를 참조하십시오.
그러나 VM을 다시 시작하면 핫플러그 인터페이스가 표준 네트워크의 일부가 되므로 최대 핫플러그 인터페이스(머신 유형별) 제한이 완화됩니다.
참고: 사용자는 중지된 VM(즉, 연결된 VMI가 없는 VM)에 대해 이 명령을 실행할 수 있습니다. 이 경우 KubeVirt는 사용자를 대신하여 VM 사양 템플릿을 변경합니다.