[Cilium Study] Routing

 

Routing이란?

라우팅은 네트워크 패밋이 출발지에서 목적지까지 가는 경로를 결정하고 전달하는 과정이다.

쉽게 말해

• 주소확인 : 목적지 IP를 확인
• 경로 결정 : 어느 네트워크 인터페이스로 내보낼지 선택
• 전달 : 다음 홉(next hop)으로 패킷을 전송

예를 들어:

• PC(192.168.1.10) -> 인터넷(8.8.8.8)
  • 목적지가 내 로컬 네트워크(192.168.1.0/24)에 없으면
  • 게이트웨이(192.168.1.1)로 보냄
  • 이후 라우터들이 목적지까지 전달

Kubernetes 같은 환경에서는 이 경로 결정이 Pod -> Node -> 다른 노드의 Pod 로 확장된다.

 

Cilium 네트워크에서 Routing의 역할

Pod 간 통신, Service, Ingress/egress 모두 패킷 라우팅이 필요하다.

Cilium에서 라우팅의 핵심 역할은

1. Pod to Pod (cross-node) 통신 경로 결정
   •   내 Node에 없는 Pod로 패킷을 보낼 때 어떤 경로로 전달할지
2. Service Load Balancing
   •   ClusterIP나 NodePort를 통해 들어온 트래픽을 어떤 Pod로 보낼지
3. 정책 기반 라우팅
   •   NetworkPolicy나 eBPF 정책 적용 후 최종 경로 선택

 

Cilium에서 제공하는 Routing 모드

Encapsulation (터널링)

• Cilium 기본 네트워킹 인프라에서 요구 사항이 가장 적은 모드이기 때문에 Encapsulation 모드에서 자동으로 실행된다.
• 이 모드에서는 모든 클러스터 노드가 UDP 기반 캡슐화 프로토콜 VXLAN 또는 Geneve를 사용하여 터널의 메시를 형성한다.
• Cilium 노드 간의 모든 트래픽이 캡슐화된다.
• 캡슐화는 일반 노드 간 연결에 의존한다. 이는 Cilium 노드가 이미 서로 연결될 수 있다면 모든 라우팅 요구 사항이 이미 충족됐다는 것을 의미한다.
• 기본 네트워크는 IPv4를 지원해야 한다. 기본 네트워크와 방화벽은 캡슐화된 패킷을 허용해야 한다.
  • VXLAN (default) : UDP 8472
  • Geneve : UDP 6081

장점

• 단순성 (Simplicity)
  • 클러스터 노드를 연결하는 네트워크는 PodCIDR을 인식할 필요가 없다.
  • 클러스터 노드는 여러 라우팅 또는 링크 계층 도메인을 생성할 수 있다.
  • 클러스터 노드가 IP/UDP를 사용하여 서로 연결할 수 있는 한 기본 네트워크의 토폴로지는 중요하지 않다.
• 정체성 맥락 (Identity context)
  • 캡슐화 프로토콜은 네트워크 패킷과 함께 메타데이터를 전송할 수 있게 해준다.
  • Cilium은 소스 보안 ID와 같은 메타데이터를 전송하는 이 기능을 활용한다.
  • The identity transfer is an optimization designed to avoid one identity lookup on the remote node

단점

• MTU 오버헤드
  • 캡슐화 헤더를 추가하면 페이로드에 사용할 수 있는 유효 MTU가 네이티브 라우팅(VXLAN의 경우 네트워크 패킷당 50바이트)보다 낮아진다.
  • 이로 인해 특정 네트워크 연결에 대한 최대 처리량이 낮아진다.
  • 점보 프레임을 활성화함으로써 크게 완화될 수 있다.

점보프레임 : 일반 이더넷보다 훨씬 큰 MTU (Maximum Trnasmission Unit)를 사용하는 네트워크 프레임
- 일반 이더넷 MTU : 1500 바이트 당 오버헤드 50 바이트
- 점보 프레임 MTU : 9000바이트 당 오버헤드 50 바이트

 

Native-Routing

• 네이티브 라우팅 데이터 경로는 라우팅 모드에서 네이티브로 활성화되며, 네이티브 패킷 전달 모드를 활성화 한다.
• 네이티브 패킷 전달 모드는 캡슐화를 수행하는 대신 Cilium이 실행되는 네트워크의 라우팅 기능을 활용한다.
• 네이티브 라우팅 모드에서는 Cilium이 다른 로컬 엔드포인트로 주소 지정되지 않은 모든 패킷을 Linux 커널의 라우팅 하위 시스템에 위임한다.
• 이는 패킷이 로컬 프로세스가 패킷을 방출한 것처럼 라우팅된다는 것을 의미한다.
• 따라서 클러스터 노드를 연결하는 네트워크는 PodCIDR을 라우팅할 수 있어야 한다.

PodCIDR 라우팅 방안 1

• 각 개별 노드는 다른 모든 노드의 모든 Pod IP를 인식하고 이를 표현하기 위해 Linux 커널 라우팅 테이블에 삽입된다.
• 모든 노드가 단일 L2 네트워크를 공유하는 경우 auto-direct-node-routes: true 로 설정하여 이 문제를 해결할 수 있다.
• 그렇지 않으면 BGP 데몬과 같은 추가 시스템 구성요소를 실행하여 경로를 배포해야 한다.

PodCIDR 라우팅 방안 2

• 노드 자체는 모든 포드 IP를 라우팅하는 방법을 모르지만 다른 모든 포드에 도달하는 방법을 아는 라우터가 네트워크에 존재한다.
• 이 시나리오에서는 Linux 노드가 이러한 라우터를 가리키는 기본 경로를 포함하도록 구성된다.
• 이 모델은 클라우드 제공자 네트워크 통합에 사용된다.

설정

• routing-mode: native : Enable native routing mode.
• ipv4-native-routing-cidr: x.x.x.x/y : Set the CIDR in which native routing can be performed
• auto-direct-node-routes: true : 동일 L2 네트워크 공유 시, 각 노드의 PodCIDR에 대한 Linux 커널 라우팅 테이블 삽입