CNI - flannel

최근 업데이트일 2024-12-10

Github: flannel 공식

Jetson에서 배포를 성공한 CNI인 Flannel에 대해서 알아보자.

Flannel

기본적이고 간단한 오버레이 네트워크 솔루션으로, 주로 간단한 네트워크 구성과 기본적인 통신을 제공하는 데 중점을 둔다.

개요

• CoreOS에서 개발한 오픈소스 CNI로, Kubernetes 클러스터 내의 각 노드에 서브넷을 할당하여 Pod 간 통신을 가능하게 한다.
• Calico와 달리 Network Policy(방화벽 규칙)를 지원하지 않으며, 오직 패킷을 전달하는 연결성에 집중한다.
• 구조가 단순하여 바이너리 크기가 작고 리소스를 적게 소모한다.

아키텍처 및 동작 원리

• Flat Network 구성: 클러스터 전체에 걸친 거대한 오버레이 네트워크(e.g., 10.244.0.0/16)를 만들고, 각 노드에는 이 대역 중 일부(e.g., /24)를 서브넷으로 할당한다.
  • 더 작은 서브넷을 사용하려면, /run/flannel/subnet.env의 FLANNEL_SUBNET 을 조정한다.
• flanneld: 각 노드에서 실행되는 데몬 프로세스로, 사전에 정의된 백엔드 방식(VXLAN 등)에 따라 패킷을 캡슐화하고 전달한다.
• etcd 연동: 각 노드에 할당된 서브넷 정보와 위치 정보를 etcd에 저장하고 공유하여 라우팅 테이블을 관리한다.

flannel은 패킷을 어떻게 운반할지 결정하는 Backend Mode 설정이 핵심이다. 과거에는 UDP 모드가 있었으나 성능 문제로 현재는 잘 사용되지 않으며, VXLAN이 사실상의 표준이다.

Backend Modes

1. VXLAN (Virtual Extensible LAN)
   • 특징
     • 리눅스 커널 자체에서 지원하는 VXLAN 기능을 사용하여 패킷을 캡슐화한다.
     • Calico의 VXLAN 모드와 유사하게 동작하며, 하드웨어 Offload 기능을 활용할 수 있어 성능이 준수하다.
   • 동작 방식
     • flannel.1이라는 가상 인터페이스를 통해 L2 프레임을 UDP 패킷에 감싸서 전송한다.
     • Kernel Space에서 패킷 처리가 이루어지므로, 아래 설명할 UDP 모드보다 오버헤드가 훨씬 적다.

2. Host-GW (Host Gateway)
   • 특징
     • 캡슐화를 전혀 하지 않고, 노드의 라우팅 테이블만을 조작하여 패킷을 전달한다.
     • 오버헤드가 없어 성능이 가장 뛰어나다. (Calico의 Direct 모드와 유사)
   • 제약 사항
     • 모든 노드가 동일한 L2 서브넷(같은 네트워크 대역) 안에 있어야만 한다. 클라우드 환경이나 네트워크가 분리된 환경에서는 사용할 수 없다.

3. UDP (Legacy) - Not Recommended
   • 특징
     • 초기에 사용되던 방식으로, 커널이 아닌 유저 공간(User Space)에서 패킷을 캡슐화한다.
     • TUN 디바이스 (flannel0, 리눅스 커널에서 구현된 소프트웨어 인터페이스)를 사용하여 커널과 flanneld 프로세스 사이에서 패킷을 복사한다.
   • 단점
     • 패킷 하나를 보낼 때마다 User Space ↔ Kernel Space 간의 컨텍스트 스위칭과 데이터 복사가 빈번하게 발생하여 네트워크 성능 저하가 심각하다.
     • 현재는 디버깅 용도나 커널이 VXLAN을 지원하지 않는 아주 오래된 시스템 외에는 사용을 권장하지 않는다.

Flannel이 권장하는 VXLAN 모드에서의 패킷 흐름을 살펴보자. 과거 UDP 모드와 달리 커널 공간에서 캡슐화가 이루어져 성능이 우수하다.

다른 Host 사이의 Container 통신 패킷 흐름

1. 패킷 생성
   • 출발지 컨테이너(Pod)가 목적지 IP를 가진 패킷을 생성하여 전송한다.
2. cni0 브리지 도달
   • 패킷은 먼저 노드의 cni0 (또는 docker0) 브리지를 통과한다.
3. 라우팅 및 캡슐화 (Kernel Space)
   • 커널 라우팅 테이블은 목적지 Pod IP가 다른 노드에 있음을 확인하고, 해당 패킷을 flannel.1 인터페이스로 보낸다.
   • flannel.1은 VTEP(VXLAN Tunnel End Point) 역할을 하는 가상 장치다.
   • 여기서 flanneld 프로세스를 거치지 않고, 커널이 직접 ARP 요청을 통해 상대방 VTEP의 MAC 주소를 확인하고 L2 프레임을 UDP 패킷으로 캡슐화한다.
4. 전송
   • 캡슐화된 패킷(UDP Port 8472)은 실제 물리 네트워크 인터페이스(eth0 등)를 통해 목적지 노드로 전송된다.
5. 수신 및 역캡슐화
   • 목적지 노드의 커널은 UDP 8472 포트로 들어온 패킷을 감지하고, VXLAN 드라이버가 헤더를 벗겨낸다. (Decapsulation)
   • 원본 패킷이 추출되어 flannel.1 인터페이스를 통해 다시 내부 네트워크로 들어온다.
6. 전달
   • 라우팅 테이블에 따라 cni0 브리지를 거쳐 최종 목적지인 컨테이너(Pod)로 전달된다.

Calico vs Flannel

앞서 살펴본 Calico의 강력한 기능에도 불구하고, Jetson 환경에서는 Flannel을 선택했다. 그 이유는 명확하다.

1. 간결함과 호환성
   • Calico는 BGP, IPIP, Network Policy 등 방대한 기능을 제공하지만, 그만큼 설정이 복잡하고 호스트 OS의 네트워크 스택(iptables, Kernel modules)에 민감하다.
   • 반면 Flannel은 구조가 단순하며, 범용적인 VXLAN을 기본으로 사용하기 때문에 Jetson의 L4T 커널에서도 별도의 모듈 설정 없이 즉시 동작했다.

2. 리소스 효율성
   • Jetson Orin Nano와 같은 엣지 디바이스는 리소스가 한정적이다.
   • 보안을 위한 Network Policy가 굳이 필요하지 않은 내부망 환경이라면, 가볍고 빠른 Flannel이 리소스 관리 측면에서 유리하다.

3. 트러블슈팅의 용이성
   • Flannel은 NetworkManager와의 충돌 가능성이 낮고, 문제 발생 시 확인해야 할 포인트(flanneld 로그, 인터페이스)가 적어 빠른 구축이 필요한 테스트베드에 적합했다.

복잡한 네트워크 정책이 필요한 대규모 상용 클러스터라면 Calico, 빠르고 간편한 구축이 필요하거나 리소스가 제한된 엣지 환경이라면 Flannel이 합리적인 선택이 될 수 있다.