KubeVirt 라이브 마이그레이션을 위한 BGP 라우팅

원문 보기 위키 갱신 2026.10.11

KubeVirt VM을 새 호스트로 라이브 마이그레이션할 때 Calico는 route priority를 이용해 트래픽을 새 호스트로 유도해요. iBGP를 쓰는 단일 랙 배포에서는 이것이 자동으로 동작하지만, 랙 사이에 eBGP를 쓰는 멀티 랙 토폴로지나 AS 풀링 구성에서는 BGPFilter 리소스를 구성해 route priority 정보가 AS 경계를 넘어 전파되도록 해야 해요. 이 가이드는 BGP 토폴로지와 무관하게 라이브 마이그레이션이 매끄럽게 이어지도록 만드는 방법을 설명해요.

출처: 문서

본문

큰 그림

KubeVirt VM을 새 호스트로 라이브 마이그레이션하면, Calico는 route priority를 사용해 트래픽을 새 호스트로 유도해요. iBGP를 쓰는 단일 랙 배포에서는 자동으로 동작해요. 랙 간에 eBGP를 쓰는 멀티 랙 토폴로지나 AS 풀링 구성에서는 BGPFilter 리소스를 구성해 route priority 정보가 AS 경계를 넘어 전파되도록 해야 해요.

가치

적절한 BGP 라우트 엔지니어링이 없으면 랙 경계를 넘는 라이브 마이그레이션 중에 트래픽 블랙홀이나 스플릿 브레인 라우팅이 생길 수 있어요. 이 가이드는 대상 호스트의 높은 우선순위 라우트가 클러스터의 모든 노드에 올바르게 전파되도록 BGP를 구성하는 방법을 설명해요. 이렇게 하면 BGP 토폴로지와 무관하게 매끄러운 라이브 마이그레이션을 보장할 수 있어요.

개념

Route priority와 BGP

라이브 마이그레이션 중 Calico는 소스 호스트의 기본 우선순위(기본값 1024)보다 높은 우선순위(더 낮은 커널 메트릭, 기본값 512)로 대상 호스트에 라우트를 프로그래밍해요. Linux 커널에서 라우트 메트릭이 낮을수록 우선순위가 높기 때문에, 트래픽이 대상 호스트로 향하게 돼요.

이것이 클러스터 전체에서 동작하려면 route priority 정보가 BGP로 전파되어야 해요.

AS 내부(iBGP): Calico는 커널 라우트 메트릭(krt_metric)을 BGP local_pref로 자동 매핑해요. 공식은 local_pref = 2147483647 - krt_metric이에요. 이 매핑은 하드코딩되어 있고 노드 간 풀 메시와 명시적 BGPPeer 리소스 모두에서 동작해요. 사용자 구성이 필요 없어요.
AS 경계를 넘을 때(eBGP): BGP local_pref는 AS 경계를 넘어 전달되지 않아요. BGP 커뮤니티 같은, AS 경계를 넘을 수 있는 속성으로 우선순위 정보를 담도록 BGPFilter 리소스를 구성해야 해요.

예외를 둔 Downward default 모델 지원

downward default 모델은 일반 라우트에 대해서는 지원되지만, ToR이 라이브 마이그레이션용 높은 우선순위 /32 라우트도 함께 통과시켜야 해요. 라이브 마이그레이션에서는 높은 우선순위의 특정 /32 라우트가 랙을 넘어 전파되어 모든 노드가 트래픽을 새 호스트로 라우팅할 수 있어야 해요. 기본 라우트만 아래로 광고하는 순수 downward default 구성은 라이브 마이그레이션과 호환되지 않아요.

라우트 집계

정상 상태에서 Calico는 개별 /32 워크로드 라우트를 더 큰 CIDR 블록으로 집계해 BGP 광고에 들어가는 라우트 수를 줄여요. 라이브 마이그레이션 중에는 높은 우선순위 /32 라우트가 집계를 우회해서 라우트별 우선순위 정보가 보존돼요. 이것은 Calico가 자동으로 처리해요.

시작하기 전에

KubeVirt VM IP 주소 지속성이 활성화되어 있어야 해요.
Calico가 BGP 네트워킹으로 구성되어 있어야 해요.
BGPFilter와 BGPPeer 리소스에 익숙해야 해요.

방법

단일 랙 또는 iBGP 메시

모든 노드가 같은 AS 안에 있다면(노드 간 풀 메시든 명시적 iBGP 피어링이든) 추가 구성이 필요 없어요. Calico가 자동으로:

export 시 krt_metric을 bgp_local_pref로 매핑해요.
import 시 bgp_local_pref를 다시 krt_metric으로 매핑해요.
높은 우선순위 /32 라우트의 라우트 집계를 우회해요.
import된 높은 우선순위 라우트에 더 높은 BIRD route preference를 부여해 기존 커널 라우트를 덮어쓰게 해요.

ToR과 eBGP로 연결되는 멀티 랙

컴퓨트 노드가 자기 랙의 ToR 스위치와 eBGP로 피어링하는 멀티 랙 토폴로지에서는, BGPFilter 리소스를 구성해 route priority 정보가 AS 경계를 넘어 전달되도록 해야 해요.

AS 경계를 넘는 route priority 시그널링

local_pref를 쓸 수 없는 eBGP 경계에서 route priority 정보를 전달하는 일반적인 기법은 두 가지예요.

BGP 커뮤니티: 커뮤니티는 라우트에 붙는 태그로, 그 자체로 라우팅 의미는 없어요. 해석 방식은 네트워크 운영자 간의 합의로 정의돼요. 높은 우선순위를 나타내는 커뮤니티 값(예: 65000:100)을 부여하면 export하는 노드가 어느 라우트가 선호되는지 표시해요. 수신 노드는 그 커뮤니티를 매칭해 적절한 커널 라우트 메트릭을 복원해요. 커뮤니티는 양쪽이 동일하게 해석하는 임의의 신호를 담기 때문에 가장 명시적이고 유연한 접근이에요.
AS path prepending: BGP의 기본 best-path 선택은 AS path가 더 짧은 라우트를 선호해요. export 시 낮은 우선순위 라우트에 AS 번호를 추가로 덧붙이면 그 라우트가 더 길어 보이고, 따라서 덜 선호돼요. 이 기법은 중간 라우터에 아무 설정 없이도 동작해요. 중간 라우터가 자연스럽게 더 짧은 경로를 선호하기 때문이에요. 다만 표준 BGP 결정 프로세스에 의존하기 때문에(MED, weight 같은 다른 속성이 우선할 수 있어요) 커뮤니티보다 정밀하지는 않아요.

두 기법 중 하나를 쓰거나 조합할 수도 있어요. 아래 예제는 커뮤니티만 사용하는데, 대부분의 배포에 권장되는 방식이에요.

1단계: ToR 피어링용 BGPFilter 만들기

priority와 operations 필드를 사용해, export 시 라우트에 BGP 커뮤니티 태그를 붙이고 import 시 커뮤니티에서 우선순위를 복원하는 BGPFilter를 만들어요. 정확한 커뮤니티 값은 여러분의 네트워크 인프라에 따라 달라지니 네트워크 팀과 조율하세요.

다음 예제는 커뮤니티 65000:100을 사용해 높은 우선순위 라우트(마이그레이션 대상)를 표시해요. 일반 우선순위 라우트는 이 커뮤니티가 없다는 것으로 나타내요.

apiVersion: projectcalico.org/v3
kind: BGPFilter
metadata:
  name: kubevirt-live-migration
spec:
  exportV4:
    # Elevated-priority route (target pod): tag with community 65000:100
    - action: Accept
      peerType: eBGP
      priority: 512
      operations:
        - addCommunity:
            value: "65000:100"
  importV4:
    # Match elevated-priority community: restore priority 512
    - action: Accept
      communities:
        values: ["65000:100"]
      operations:
        - setPriority:
            value: 512
  exportV6:
    - action: Accept
      peerType: eBGP
      priority: 512
      operations:
        - addCommunity:
            value: "65000:100"
  importV6:
    - action: Accept
      communities:
        values: ["65000:100"]
      operations:
        - setPriority:
            value: 512

이 필터에서 사용하는 핵심 필드는 다음과 같아요.

priority (export 규칙): 커널 라우트 메트릭으로 라우트를 매칭해요. 지정된 우선순위 값을 가진 라우트만 이 규칙에 매칭돼요.
peerType: eBGP (export 규칙): 커뮤니티 태깅이 eBGP 피어에만 적용되도록 해요. iBGP 피어는 자동 local_pref 매핑을 사용해요.
communities (import 규칙): 지정된 BGP 커뮤니티를 실은 라우트를 매칭해요.
operations: 매칭된 라우트에 적용되는 순서 있는 라우트 수정 목록이에요.
- addCommunity: 라우트에 BGP 커뮤니티를 추가해요.
- setPriority: 라우트의 커널 메트릭(우선순위)을 설정해요.

SECONDARY: BGPFilter의 priority 값(512)은 FelixConfiguration의 ipv4ElevatedRoutePriority 및 ipv4NormalRoutePriority 값과 일치해야 해요. 이 값을 커스터마이즈했다면 BGPFilter도 그에 맞게 갱신하세요.

2단계: ToR BGPPeer에 BGPFilter 붙이기

ToR의 기존 BGPPeer 리소스에 필터를 추가해요.

apiVersion: projectcalico.org/v3
kind: BGPPeer
metadata:
  name: node-tor-peer
spec:
  peerIP: <ToR IP>
  asNumber: <ToR AS number>
  filters:
    - kubevirt-live-migration

3단계: ToR이 높은 우선순위 라우트를 선택하도록 구성

ToR은 Calico의 BGPFilter가 붙인 BGP 커뮤니티(65000:100)를 읽고, 일반 우선순위 라우트보다 그 라우트들을 선호하도록 구성되어야 해요. 그렇지 않으면 ToR이 소스와 대상 라우트를 동등하게 취급해 ECMP로 설치할 수 있고, 라이브 마이그레이션 중 스플릿 브레인 라우팅이 생겨요.

다음 BIRD 1.x import 필터 예제는 커뮤니티를 매칭해 높은 우선순위 라우트에 더 높은 선호도를 부여하는 방법을 보여줘요.

filter import_community_priority {
  if ((65000, 100) ~ bgp_community) then {
    preference = 200;
  }
  accept;
}

커뮤니티 (65000, 100)을 실은 라우트는 BIRD preference = 200(기본값은 100)을 받아서, 라이브 마이그레이션 중 대상 라우트가 소스 라우트보다 선호되도록 보장해요.

3단계 (대안): 하드웨어 ToR이 커뮤니티와 함께 라우트를 전파하도록 구성

ToR이 하드웨어 스위치라면(BIRD를 실행하지 않는다면) BGPFilter에 사용된 BGP 커뮤니티(예: 65000:100)를 통과시키도록 구성되어 있는지 확인해요. ToR은 이 /32 라우트들을 커뮤니티를 그대로 유지한 채 다른 랙의 컴퓨트 노드로 재광고해야 하고, 그래야 수신 노드의 import 필터가 올바른 route priority를 복원할 수 있어요. 이 구성은 스위치 벤더와 네트워크 OS에 따라 달라져요.

추가 리소스

더 알아보기 (Learn more)

핵심은 iBGP에서는 krt_metric ↔ local_pref 매핑이 자동이라는 점, eBGP 경계에서는 커뮤니티 같은 속성으로 우선순위를 실어 보내야 한다는 점이에요. BGPFilter의 priority 값이 FelixConfiguration의 라우트 우선순위 설정과 일치하는지 꼭 확인하세요.