VPP 데이터 플레인 구현 세부 사항

Calico의 VPP 데이터 플레인이 내부에서 어떻게 동작하는지 설명하는 기술 참고 문서예요. vpp-manager와 calico-vpp-agent 두 구성 요소의 역할과 네트워크 아키텍처, 컨테이너 인터페이스 구성 방식을 다뤄요. VPP 데이터 플레인을 깊이 이해하거나 디버깅할 때 참고하면 좋아요.

출처: 문서

본문

소프트웨어 아키텍처

VPP 데이터 플레인 통합은 두 구성 요소로 나뉘어요. VPP 시작 구성과 수명 주기를 담당하는 vpp-manager, 그리고 Calico를 위한 VPP 런타임 구성 전체를 담당하는 calico-vpp-agent예요. 두 프로세스는 호스트의 루트 네트워크 네임스페이스에서 실행되는 calico-vpp-node pod 안에서 각각 별도 컨테이너로 동작해요.

vpp-manager

VPP Manager는 VPP를 부트스트랩하는 아주 가벼운 프로세스예요. 업링크 인터페이스 주소 설정과 라우팅 구성을 포함하고, 종료 시에는 Linux 구성을 복원해요. 코드는 이 디렉터리에서 확인할 수 있어요: https://github.com/projectcalico/vpp-dataplane/tree/v3.32.0/vpp-manager.

시작할 때 vpp-manager는 Linux에서의 구성(주소와 라우트 포함)을 확인하면서 VPP 업링크에 어떤 구성이 필요한지 파악해요. 그다음 VPP에 맞는 구성 파일을 만들고 VPP 프로세스를 시작해요.

VPP가 실행되면 vpp-manager는 API로 VPP에 연결해 Linux에서 설정됐던 그대로 업링크 인터페이스를 구성해요. 이 작업이 끝나면 호스트에 tap 인터페이스를 구성해서 호스트 연결을 복원해요.

실행 중에는 vpp-manager가 받은 모든 Unix 시그널을 VPP에 전달해 우아하게 멈추도록 처리해요.

VPP가 시그널에 반응하거나 크래시로 멈추면, vpp-manager는 Linux 인터페이스 구성을 복원해서 호스트가 원래 업링크 인터페이스를 통해 외부 연결을 회복하도록 해요.

버그로 인해 호스트가 연결을 잃고 재부팅이 필요한 상황을 막기 위해, vpp-manager는 의도적으로 최대한 단순하게 유지돼요.

calico-vpp-agent

Calico VPP 에이전트는 VPP에서 Calico 관련 구성 전체를 담당하는 프로세스예요. 코드는 이 디렉터리에 있어요: https://github.com/projectcalico/vpp-dataplane/tree/v3.32.0/calico-vpp-agent.

이 에이전트는 k8s와 Calico API를 사용해 VPP를 구성하는 네 가지 주요 구성 요소로 나뉘어요. 라우팅 매니저, CNI 서버, 서비스 매니저, 정책 매니저예요.

라우팅 매니저(Routing manager)

Calico VPP 에이전트는 GoBGP 데몬을 내장하고, Calico 구성에 따라 피어, ASN 등 설정을 동적으로 갱신해요. calico-vpp-node pod가 호스트 네트워크 네임스페이스에서 실행되기 때문에 BGP 데몬은 호스트의 TCP 스택을 사용하고, 호스트의 vpptap0 인터페이스를 통해 트래픽을 주고받아요.

BGP에서 라우트가 추가되거나 삭제되면 라우팅 매니저가 그 변화를 VPP에 반영해요. 라우트 설치 방식은 Calico 구성에 따라 달라져요. IPIP나 VXLAN 터널을 사용하도록 설정되어 있다면 VPP에서 필요할 때 터널 인터페이스를 만들고 터널을 통해 라우트를 추가해요. 그렇지 않으면 라우트를 VPP에 그대로 추가해요.

CNI 서버(CNI server)

이 구성 요소는 호스트에 마운트된 Unix 소켓을 통해 Calico CNI(gRPC 데이터 플레인으로 구성됨)가 보내는 gRPC 요청을 받는 서버를 구현해요.

ADD 요청을 받으면 CNI 서버는 컨테이너 네임스페이스에 tap 인터페이스를 만들고, Calico가 선택한 IP 주소와 라우트로 설정해요. 라우트의 next hop은 IPv4와 IPv6 모두에서 별도로 사용되지 않는 링크 로컬 주소예요. VPP에도 tap을 통해 컨테이너 주소를 위한 /32 또는 /128 라우트를 추가해요. DEL 요청을 받으면 CNI 서버는 VPP와 컨테이너 네임스페이스에서 tap을 정리해요.

서비스 매니저(Services manager)

이 구성 요소는 VPP용 kube-proxy에 해당해요. 쿠버네티스 서비스를 VPP에서 구현하도록 NAT 로드 밸런싱 규칙을 구성하죠. 쿠버네티스 Services와 Endpoints API를 지켜보다가 변경이 있을 때마다 VPP 구성을 갱신해요. 서비스 로드 밸런싱은 VPP의 Calico 전용 DNAT 플러그인으로 구현돼요.

정책 매니저(Policies manager)

이 구성 요소는 VPP에서 Calico 정책을 구현해요. Felix(Calico의 정책 에이전트)는 경량 프록시를 데이터 플레인으로 사용하도록 설정돼요. 이 프록시는 Felix가 보내는 모든 구성 메시지를 calico-vpp-agent로 중계하고, 상태 업데이트는 반대 방향으로 전달해요. 그러면 VPP 에이전트가 VPP의 커스텀 플러그인으로 정책을 구현해요.

네트워크 아키텍처

기본 인터페이스 구성

컨테이너를 대신해 패킷을 주고받으려면 VPP가 호스트의 네트워크 인터페이스 중 하나를 사용해야 해요. 방법은 여러 가지이고, 성능과 구성 복잡도가 서로 달라요:

• AF_PACKET: 가장 느린 옵션이지만 모든 Linux 네트워크 장치에서 동작하는 가장 범용적인 방법이에요. VPP가 구성한 호스트 연결을 방해하지 않도록 인터페이스는 전용 네트워크 네임스페이스에 들어가요.
• AF_XDP: AF_PACKET보다 훨씬 성능이 좋지만 최신 커널 버전(5.4+)이 필요해요. 인터페이스는 전용 네트워크 네임스페이스에 들어가서 VPP가 구성한 호스트 연결을 방해하지 않아요.
• DPDK: VPP는 DPDK로 인터페이스를 구동할 수 있어요. AF_XDP보다 성능이 좋고 많은 인터페이스를 지원하지만, 동작하려면 호스트에 hugepages 구성이 필요해요. 인터페이스는 시작 시 특정 PCI 드라이버에 바인딩되기 때문에 호스트의 커널 네트워크 장치에서 사라져요.
• VPP 네이티브 드라이버: 가장 성능이 좋은 옵션이지만 지원하는 인터페이스가 제한적이에요. Intel AVF, Mellanox Connect-X 시리즈, vmxnet3(VMware), virtio(Qemu/KVM과 GCE에서 사용) 인터페이스가 지원돼요. DPDK처럼 시작 시 특정 PCI 드라이버에 바인딩되기 때문에 호스트에서 사라져요. 네이티브 드라이버는 vpp-manager가 지원하는 virtio와 Intel AVF 인터페이스를 제외하면 커스텀 구성이 필요해요.

호스트 네트워크 구성

전용 페이지를 참고하세요.

컨테이너 인터페이스

Pod가 호스트에 스케줄되면 kubelet 서비스가 새 pod의 네트워크 네임스페이스를 만들고, CNI를 통해 이 네임스페이스에 인터페이스를 구성해 달라고 Calico에 요청해요. Calico는 먼저 호스트의 IP 구성(주소와 라우트)을 계산한 뒤 VPP 에이전트에 전달해요. 그러면 VPP가 원하는 네임스페이스에 컨테이너용 tun 인터페이스를 만들고 필요한 주소와 라우트를 설정해요. 덕분에 컨테이너 트래픽은 모두 VPP를 통과해요.

컨테이너 라우팅과 서비스 로드 밸런싱

각 pod가 어느 호스트에서 실행 중인지 알아내기 위해 Calico는 BGP를 사용해요. BGP로 학습한 라우트는 VPP에 설치되어 다른 노드에서 실행 중인 컨테이너에 도달하는 데 쓰여요. Calico 구성에 따라 라우트는 직접 연결된 호스트를 가리키거나, 캡슐화가 필요하면 터널 인터페이스를 거쳐요.

서비스 로드 밸런싱은 VPP의 NAT 규칙으로 구현되고, kube-proxy가 하는 방식과 매우 비슷해요. 외부 연결에서는 가능한 한 소스 주소를 유지해요.

최종적인 논리 네트워크 토폴로지는 다음과 같아요:

더 알아보기 (Learn more)

vpp-manager는 VPP 부트스트랩과 종료 시 Linux 구성 복원을 담당하고, calico-vpp-agent는 라우팅·CNI·서비스·정책을 처리해요. 인터페이스 연결 방식은 AF_PACKET부터 VPP 네이티브 드라이버까지 선택지가 다양하고, 성능이 좋을수록 구성 요건도 높아져요.