요약
SUMMARY
KubeVirt VM에 붙인 secondary IP가 재기동할 때마다 바뀌는 게 문제였다. Pod 애노테이션으로 IP를 고정하려 했지만 KubeVirt가 VM을 launcher 파드로 넘길 때
ips필드를 지워버려서 먹히지 않았다. 결국 VXLAN 브리지로 노드 간 L2를 확장하고, 그 위에 Multus NAD를 VM별로 하나씩 두면서 Static IPAM으로 주소를 NAD에 박아두는 쪽으로 우회했다. IP가 파드가 아니라 선언(NAD)에 묶이니, VM을 껐다 켜거나 다른 노드로 옮겨도 같은 주소를 유지한다.
1. 개요
앞서 KubeVirt로 오프라인 테스트 환경 만들기 글 끝에 “고정 IP 할당은 실패했다, Multus 쓰면 된다는데 복잡해서 접었다”고 적어뒀다. 그 접어둔 걸 다시 폈다.
KubeVirt VM은 실제로는 특수한 파드(virt-launcher) 안에서 돌아간다. 그래서 기본 네트워크는 파드 네트워크를 그대로 받는데, 파드 IP는 파드가 다시 뜨면 바뀐다. VM 입장에서 virtctl stop 후 start를 하면 launcher 파드가 새로 뜨고, 그때마다 secondary IP도 딸려 바뀌었다. (재부팅은 좀 다르다. VM 안에서 init 6로 게스트만 재부팅하면 파드는 그대로라 IP도 안 바뀐다. 문제가 되는 건 파드 자체가 재생성되는 경우다.)
VM을 다른 VM이나 외부에서 고정된 주소로 계속 찾아야 하는 용도라면 이건 곤란하다. IP가 바뀔 때마다 붙는 쪽 설정을 고쳐야 하니까. 그래서 “재기동을 하든, VM이 다른 노드로 스케줄되든 항상 같은 IP”라는 조건을 만족시키고 싶었다.
2. 선정 배경
요구사항은 세 줄로 정리됐다.
- VM을 껐다 켜도(=launcher 파드 재생성) secondary IP가 유지될 것
- VM이 어느 노드로 스케줄되든 같은 IP가 그대로 붙을 것 (노드 위치 무관)
- 구성이 선언적이라 IaC로 그대로 재현될 것
제약도 있었다. 클러스터 CNI는 Cilium이고, secondary 네트워크는 Multus로 얹는 구조다. Cilium 위에 Multus를 태우려면 Cilium이 CNI를 독점하지 않도록 cni.exclusive: false를 꺼줘야 하고, NAD의 type으로 쓰는 플러그인 바이너리가 각 노드의 /opt/cni/bin에 실제로 있어야 한다.
NOTE
cni.exclusive를 안 끄면 Cilium이/etc/cni/net.d를 자기 것만 남기고 정리해버려서 Multus 체인이 통째로 무시된다. Multus를 얹는데 secondary 인터페이스가 아예 안 생긴다면 여기부터 의심하는 게 빠르다. 그리고bridge,static같은 플러그인은 containernetworking/plugins에서 받아/opt/cni/bin에 깔아둬야 한다.
3. 비교
고정 IP를 만드는 방법을 순서대로 시도했다. 결과부터 표로.
| 시도 | 방식 | 결과 |
|---|---|---|
| 기본 IPAM (host-local/DHCP) | NAD에 IPAM만 걸고 IP는 자동 할당 | 재기동마다 IP 변동. 애초에 고정이 목적이 아님 |
Pod 애노테이션 ips 요청 | k8s.v1.cni.cncf.io/networks에 원하는 IP를 명시 | KubeVirt가 launcher 파드로 넘길 때 ips 필드를 제거 → 무시됨 |
| NAD에 Static IPAM | 주소를 NAD 안에 직접 박고, VM별로 NAD를 하나씩 | 고정 IP 유지. 채택 |
가운데 줄이 이 글의 핵심 삽질이다. Multus로 secondary 네트워크에 특정 IP를 요청하는 정석은, 파드(여기선 VM 템플릿)에 이런 애노테이션을 다는 것이다.
# 정석대로라면 이렇게 networkName과 ips를 함께 요청한다.
# 하지만 KubeVirt VM에서는 ips가 무시된다.
annotations:
k8s.v1.cni.cncf.io/networks: |
[{ "name": "vm-fixed", "namespace": "vm", "ips": ["10.20.30.11/24"] }]일반 파드였으면 이걸로 끝이다. 그런데 VM에 걸면 요청한 IP가 안 잡혔다. 한참 헤매다 확인한 건, KubeVirt가 VM 스펙을 실제 launcher 파드 스펙으로 변환하면서 이 네트워크 요청의 ips 필드를 떼어낸다는 점이다. VM의 네트워크는 KubeVirt가 자체적으로 관리하는 영역이라, 파드 레벨에서 IP를 지정해 넣는 이 경로를 그대로 통과시켜주지 않는다. 업스트림 동작이 그래서, 내 설정이 틀린 게 아니라 이 경로 자체가 VM에는 막혀 있던 거였다. (설정을 스무 번쯤 고쳐본 뒤에야 “내 문제가 아니구나”를 받아들였다.)
그러면 IP를 파드가 아니라 NAD 자체에 박아두면 된다. 요청하는 주체가 사라지니 떼일 필드도 없다. Static IPAM이 딱 그 용도다.
4. 선정 사유
정리된 구성은 이렇다. 노드 위에 VXLAN 브리지를 깔아 L2를 확장하고, 그 브리지를 쓰는 Multus NAD를 VM마다 하나씩 만들되 IPAM은 static으로 고정한다.
1. VXLAN 브리지로 노드 간 L2 확장
노드 위치와 무관하게 같은 IP가 붙으려면, 그 IP가 사는 L2 세그먼트가 노드 하나에 갇혀 있으면 안 된다. 그래서 각 노드에 VXLAN 인터페이스를 만들고 리눅스 브리지(br-vxlan0)에 물려, 모든 노드가 같은 오버레이 L2를 공유하게 했다. VM이 어느 노드에 스케줄되든 이 브리지에 붙기만 하면 같은 대역 안에서 통신한다. (이 부분은 노드 프로비저닝 단계에서 한 번 깔아두는 밑작업이다.)
2. VM별 NAD에 Static IPAM
브리지가 준비됐으면 그 위에 NAD를 얹는다. type은 bridge로 이 VXLAN 브리지를 가리키고, ipam은 static으로 줄 주소를 직접 적는다. 고정하고 싶은 VM마다 이런 NAD를 하나씩 둔다.
# VM 한 대에 대응하는 고정 IP용 NAD.
# bridge 플러그인이 노드의 br-vxlan0(=VXLAN 오버레이)에 인터페이스를 붙이고,
# static IPAM이 이 주소를 그대로 부여한다. IP가 파드가 아니라 이 선언에 묶인다.
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
name: vm-fixed-master-01
namespace: vm
spec:
config: |
{
"cniVersion": "0.3.1",
"type": "bridge",
"bridge": "br-vxlan0",
"ipam": {
"type": "static",
"addresses": [
{ "address": "10.20.30.11/24", "gateway": "10.20.30.1" }
]
}
}Static IPAM은 NAD 하나당 주소가 고정이라, VM별로 다른 IP를 주려면 NAD도 그만큼 만들어야 한다. 파드 오토스케일 같은 데는 안 맞지만, “정해진 몇 대의 VM에 정해진 주소”라는 이 상황엔 오히려 단순해서 좋았다. NAD가 곧 IP 대장 역할을 한다.
3. VM에 secondary로 붙이기
VM 템플릿에서는 기본 파드 네트워크는 그대로 두고(외부 egress·클러스터 통신용), 위 NAD를 secondary 인터페이스로 추가한다.
# 기본(default)은 파드 네트워크, fixed가 위에서 만든 고정 IP용 secondary.
spec:
template:
spec:
domain:
devices:
interfaces:
- name: default
masquerade: {}
- name: fixed
bridge: {}
networks:
- name: default
pod: {}
- name: fixed
multus:
networkName: vm/vm-fixed-master-01이렇게 하면 IP를 결정하는 게 launcher 파드의 수명이 아니라 NAD라는 선언이 된다. virtctl stop/start로 파드가 새로 떠도, 스케줄러가 VM을 다른 노드에 올려도, 붙는 NAD가 같으면 IP도 같다. 요구했던 세 조건이 다 여기서 나온다. 처음엔 그럴듯해 보였던 Pod 애노테이션 경로를 버리고 NAD로 옮긴 게 IaC와도 잘 맞았다. VM 정의와 NAD 정의를 같이 커밋해두면 클러스터를 다시 세워도 주소 배치가 그대로 재현된다.
한계도 분명하다. VM 대수만큼 NAD가 늘고, 주소를 사람이 직접 관리해야 한다. 대수가 크게 늘면 Whereabouts 같은 IPAM으로 넘어가는 게 맞겠지만, 지금 규모에선 눈에 보이는 Static이 관리하기 편했다.