CNI - Calico 모드와 Jetson에서의 실패 분석

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

AhnLab CloudMate: K8s Network - Calico's Modes

Calico가 지원하는 네트워크 모드에 대해서 알아보고, Jetson에 배포했을 때 실패했던 이유를 확인해보자.

Calico 네트워크 모드

Calico는 네 가지 네트워크 모드를 지원하며 크게 원본 패킷을 다른 패킷 안에 감싸는 캡슐화 방식과 비캡슐화 방식으로 나눌 수 있다. 각각에 대해서 알아보자.

1. Overlay - 캡슐화 네트워크

캡슐화 방식은 물리적인 네트워크 인프라(Router 등)의 설정 변경 없이도 Pod 간 통신을 가능하게 한다. 즉, Pod의 네트워크 정보를 Node에서 다시 한 번 IP 헤더를 덧붙이는 캡슐화 과정을 거쳐 목적지 Node로 전달한다.

• 물리적인 네트워크 구간의 최대 MTU(Maximum Transmission Unit, 네트워크에 연결된 장치가 받아들일 수 있는 최대 데이터 패킷 크기)에서 캡슐화되는 프로토콜에 따라 MTU 사이즈의 일부 축소가 필요하다.
• 크게 IPIP 방식과 VXLAN 방식으로 나뉜다.

• IP-in-IP (IPIP)
  • IP 패킷을 또 다른 IP 패킷에 넣어 캡슐화하는 방식
  • 특징:
    • 외부 IP 헤더를 덧붙여 라우팅하므로, 물리 네트워크는 Pod IP를 알 필요가 없다.
    • VXLAN에 비해 헤더 오버헤드가 적어 성능상 유리할 수 있다.
    • 일반적으로 BGP를 통해 노드 간 경로 정보를 교환한다.
    • 터널링 인터페이스 이름은 주로 tunl0로 나타난다.
    • ECMP를 통한 대역폭과 경로 확장이 지원되지 못하는 확장의 단점이 존재
  • 옵션:
    • Always: 모든 트래픽을 캡슐화합니다.
    • CrossSubnet: 같은 서브넷(L2)에 있는 노드 간 통신은 캡슐화 없이(Direct) 통신하고, 다른 서브넷으로 나갈 때만 IPIP 캡슐화를 사용한다. (성능 최적화에 유리)

• VXLAN (Virtual Extensible LAN)
  • L2 프레임(Ethernet Frame)을 UDP 패킷에 담아 전송하는 표준 터널링 프로토콜이다.
  • 특징:
    • 동작 원리: 네트워크 패킷 앞에 VNI를 붙이고 VTEP의 정보를 기반으로 헤더를 하나 더 덧붙여 통신하는 방식이다.
      • VNI(Virtual Network Identifier): Tenant를 식별하여 통신하는 식별자
      • VTEP(VXLAN Tunnel End-Point): 패킷의 캡슐화와 역캡슐화가 발생하는 위치
        • Local LAN Segment와 통신하기 위한 인터페이스와 IP Network 통신을 위한 인터페이스를 가지고 있다.
        • 라우팅 테이블에서 보이는 vxlan.calico 인터페이스가 VTEP 역할을 담당한다.
      • NVE(Network Virtual Interface): VTEP 장비가 사용하는 가상의 인터페이스, 다른 VTEP 장비들과 Tunnel을 맺고 VXLAN 캡슐화 및 역캡슐화를 수행한다.
    • BGP 미사용 (Felix 활용): VXLAN 모드에서는 BGP(BIRD 프로세스)가 동작하지 않고 .
      • 각 노드의 에이전트인 Felix가 etcd에서 네트워크 정보를 가져와 라우팅 테이블을 직접 업데이트한다.
      • 이로 인해 잦은 BGP 업데이트로 인한 시스템 부하를 줄일 수 있다.
    • 확장성 및 성능:
      • ECMP(Equal-Cost Multi-Path)를 지원하여 대역폭과 경로의 확장에 유연함을 가진다. (IPIP의 단점 보완)
      • 하드웨어 NIC을 통한 Offload 기능을 지원하여 패킷 처리 성능을 높일 수 있다.
    • AWS, Azure 등 IPIP 트래픽을 차단하는 퍼블릭 클라우드 환경에서 주로 사용된다.

2. Non-Overlay - 비캡슐화 네트워크

캡슐화를 하지 않고 원본 패킷 그대로 물리 네트워크 인터페이스로 전송하는 방식이다.

• Direct (BGP)
  • Pod의 네트워크 정보를 Node의 위치와 상관없이 그대로 물리적인 네트워크 인터페이스로 전송하는 방식이다.
  • 특징:
    • BGP(Border Gateway Protocol)를 사용하여 통신한다.
    • 캡슐화/비캡슐화 과정이 없고 오버헤드가 적어 네트워크 성능이 가장 우수하다.
    • MTU도 물리적 네트워크의 구성에 따라 확장 가능하며 축소가 필요 없다.
    • 클라이언트의 소스 IP가 보존되어 트래픽 가시성이 좋다.
  • 제약 사항:
    • 물리 네트워크 장비가 BGP를 지원하고 설정을 변경할 수 있어야 하거나, 모든 노드가 동일한 L2 네트워크 대역에 존재해야 한다.
    • 즉, 하나의 통일된 네트워크를 쓰거나, 구조가 단순하여 네트워크 변경이 없는 경우 또는 네트워크 장비 구성에 대한 자동화를 통해 Pod 네트워크에 대한 자동 업데이트가 가능한 경우에 사용한다.

어떤 네트워크 모드를 선택하든, 결국 통신의 주체가 되는 Pod에 고유한 IP를 할당하고 관리하는 과정이 선행되어야 한다. 이를 처리하는 IPAM에 대해서 간단히 알아보자.

IPAM (IP Address Management)

Kubernetes는 직접 Pod에 IP 주소를 할당하고 관리하는 대신 IPAM 플러그인을 사용하도록 설계되었다. 대게 CNI에서 같이 제공하며, Calico도 자체 IPAM 플러그인 calico-ipam을 가지고 있다.

• Kubernetes의 기본 방식인 Host-local IPAM은 Node마다 사전에 고정된 크기의 CIDR을 할당하여 자원이 비효율적으로 사용되었고, Calico IPAM은 이를 해결하고자 하였다.

• IP Block과 동적 할당
  • Calico IPAM은 클러스터 전체의 IP 대역(CIDR)을 IP Pool로 관리하며, 이를 효율적으로 사용하기 위해 Block이라는 작은 단위로 쪼개어 운용한다.
  • Block 단위 할당
    • 기본적으로 하나의 Block은 /26 서브넷(64개의 IP) 크기를 가진다.
    • Node가 처음 실행되거나 IP가 부족해지면, Calico IPAM은 전체 Pool에서 사용 가능한 Block 하나를 해당 Node에 동적으로 할당한다.
  • 동적 확장성
    • Node에 Pod가 많이 생성되어 할당받은 Block의 IP를 모두 소진하면, 자동으로 새로운 Block을 추가로 할당받는다.
    • 반대로 Node에 Pod가 적다면 불필요하게 많은 IP를 점유하지 않으므로, 클러스터 전체의 IP 낭비를 줄일 수 있다.

• Route Aggregation을 통한 성능 최적화
  • Calico가 Block 단위를 사용하는 가장 큰 기술적 이유는 라우팅 테이블의 크기를 줄이기 위함이다.
  • 만약 Pod 하나하나마다 /32 경로를 전파한다면, 대규모 클러스터에서는 라우팅 테이블이 폭발적으로 커져 네트워크 성능 저하를 유발한다.
  • Calico는 Block 단위로 경로를 묶어서 전파하기 때문에, 수십 개의 Pod IP 정보를 단 하나의 라우팅 규칙으로 압축하여 관리할 수 있다.

Calico에 대해서 어느 정도 알아보았다. 그렇다면 Jetson(NVIDIA Orin Nano)에서는 왜 Calico를 CNI로 사용하는 것이 불가했을까?

Jetson에서의 실패 분석

Jetson의 아키텍처(ARM64)와 OS 환경(L4T), 그리고 Calico와 Flannel의 동작 방식 차이를 통해 실패 원인을 다음과 같이 합리적으로 추론해 볼 수 있다.

1. NetworkManager와의 충돌
   • Jetson은 서버용 OS가 아닌, Ubuntu Desktop 기반의 환경(L4T)을 사용하며, 이는 NetworkManager가 기본적으로 모든 네트워크 인터페이스를 관리한다.
   • Calico는 Pod 통신을 위해 호스트에 cali*로 시작하는 다수의 가상 인터페이스(veth)를 생성한다.
   • NetworkManager는 이 새로운 인터페이스들을 감지하고 자신이 관리하려고 시도하거나, 관리되지 않는 인터페이스로 간주하여 연결을 끊어버리는 등 간섭을 일으킨다.
   • Calico가 생성한 인터페이스가 준비되지 않거나, 라우팅 테이블이 꼬이면서 노드 간 통신이 두절된다.
   • Flannel 역시 가상 인터페이스(cni0, flannel.1)를 생성하지만, 구성이 상대적으로 단순하고 NetworkManager의 간섭에 덜 민감하게 동작하거나 기본 설정이 Jetson 환경과 충돌이 적었을 가능성이 크다.

2. 커널 모듈 호환성 및 IPIP 모듈 부재
   • Calico의 기본 모드인 IPIP는 리눅스 커널의 특정 모듈(ipip, tunnel4 등)에 강하게 의존한다.
   • NVIDIA Jetson에 탑재된 커널은 일반적인 x86 Ubuntu Server 커널과 달리, 엣지 AI 목적에 맞게 커스터마이징되어 있다. 이 과정에서 네트워킹 관련 일부 커널 모듈이 기본적으로 비활성화되어 있거나 포함되지 않았을 수 있다.
   • Calico 노드 에이전트(Felix)가 실행될 때 IPIP 터널링을 위한 커널 모듈을 로드하지 못하면, tunl0 인터페이스 생성에 실패하며 Pod 네트워크가 구성되지 않는다.
   • 반면 Flannel이 사용하는 VXLAN은 UDP 패킷으로 감싸는 방식이므로, IPIP보다 커널 의존성이 상대적으로 낮고 범용적인 네트워크 스택 위에서 잘 동작한다.

이와 같은 이유로 Jetson에서 Calico를 CNI로 사용하는 것을 실패했기 때문에 Flannel로 변경하여 클러스터 배포를 시도하여 성공했다. Calico의 VXLAN 모드를 사용했다면 성공했을 확률이 매우 높았을 것이다.