[cilium] Routing & Masquerading

Cilium 라우팅 방식

cilium 라우팅 방식을 설명하기 앞서, 쿠버네티스의 파드 IP 통신 규약을 잠시 살펴봅니다.

쿠버네티스 네트워크 모델은 아래 4가지 요구사항을 만족해야 합니다.

파드와 파드 간 통신 시 NAT 없이 통신이 가능해야함
노드의 에이전트(예. kubelet, 시스템 데몬)는 파드와 통신이 가능해야함
호스트 네트워크를 사용하는 파드는 NAT 없이 파드와 통신이 가능해야함
서비스 클러스터 IP 대역과 파드가 사용하는 IP 대역은 중복되지 않아야함

이 중 첫 번째 "NAT 없이 통신" 이라는 표현이 헷갈릴 수 있는데, 파드들은 서로의 IP 만 보고 통신할 수 있다는 의미입니다.
예를 들어, 파드 A(10.244.1.5)에서 파드 B(10.244.2.10)로 패킷을 보낼 때 파드 B가 받는 패킷의 source IP는 10.244.1.5 그대로 유지됩니다. 이렇게 하기 위해서는 CNI 가 IP 를 변환해주어야 한다는 것입니다. 이러한 방식을 지원하기 위해 cilium 라우팅은 캡슐화 방식과 네이티브 라우팅 방식이 존재합니다.

1. 캡슐화(Encapsulation) 방식

특징

기본 동작 모드로 VXLAN(8472/UDP) 또는 Geneve(6081/UDP) 사용
모든 노드가 터널 메시를 구성하여 트래픽 캡슐화
기본 네트워크가 PodCIDR 을 인식할 필요 없음

장점

단순성: 네트워크 토폴로지와 무관하게 동작
(네트워크가 podCIDR 을 인식할 필요 없고 서로 도달만 가능하다면 기본 네트워크 토폴리지는 중요하지 않음)
주소 공간: 더 큰 주소 공간 활용 가능
(새로운 IP로 캡슐화 하기 때문에 기본 네트워킹 주소 크기에 의존하지 않음)
자동 구성: 새 노드 자동 메시 통합
(Kubernetes 와 같은 오케스트레이션 시스템과 함께 실행될 때, 할당 관련 접두사를 포함한 클러스터의 모든 노드 목록이 각 에이전트에 자동으로 제공)
신원 컨텍스트: 메타데이터와 보안 관련 Identifier 전송 가능
(캡슐화 프로토콜은 네트워크 패킷과 함께 메타데이터를 전달 가능)

단점

MTU 오버헤드: 패킷당 50바이트 오버헤드로 처리량 감소 (점보 프레임으로 완화 가능)

캡슐화 방식은 Cilium 노드들이 서로 연결될 수 있고, 네트워크와 방화벽 정책에서 캡슐화된 패킷을 허용한다면 라우팅 요구사항이 충족됩니다. 하지만 IPv4 기반 터널링은 완전히 지원하지만, IPv6 기반 터널링은 아직 완전히 지원되지 않습니다. 캡슐화로 인한 성능 오버헤드도 존재합니다. 하지만 대부분의 환경에서 안정적으로 동작하며 복잡한 네트워크 토폴로지에서도 문제없이 사용할 수 있습니다.

2. 네이티브 라우팅(Native-Routing) 방식

설정

routing-mode: native
ipv4-native-routing-cidr: x.x.x.x/y

routing-mode: native 구문은 네이티브 라우팅 모드를 활성화하며, ipv4-native-routing-cidr: x.x.x.x/y 구문은 네이티브 라우팅이 수행되는 CIDR을 설정합니다.

BGP 데몬이 실행 중이지만, 클러스터 네트워크에 기본 서브넷이 있는 경우 트래픽을 항상 BGP 라우터에 라우팅할 필요는 없습니다.

각 노드에 L2 연결을 보장하기 위해 아래와 같이 옵션을 추가할 수 있습니다.

direct-routing-skip-unreachable: true (auto-direct-node-routes 옵션과 함께 사용)

네트워크 요구사항

네이티브 라우팅은 네이티브 패킷 포워딩 모드를 활성화하여 Cilium 이 직접 네트워크의 라우팅을 수행합니다. 즉, 클러스터 노드를 연결하는 네트워크는 podCIDR 를 라우팅할 수 있어야 합니다.

즉 노드의 Linux 커널은 Cilium 을 실행하는 모든 노드의 Pod 또는 기타 워크로드 패킷을 전달하는 방법을 알고 있어야 합니다. 이는 두 가지 방법으로 달성할 수 있습니다.

다른 모든 pod 에 전달할 수 있는 라우터에 위임 (Linux 노드는 해당 라우터를 가리키는 기본 경로를 포함)
=> 해당 모델은 주로 클라우드 공급자 네트워크 통합에 사용
각 노드가 다른 모든 파드의 IP 들을 인식 (Linux 커널 라우팅 테이블에 삽입) (auto-direct-node-routes: true)
모든 노드가 L2 에 존재한다면 옵션을 활성화하여 처리 가능하지만, 그렇지 않은 경우 BGP 데몬을 활용하여 경로 전파 필요

네이티브 라우팅은 캡슐화 오버헤드 없이 최고 성능을 제공하여 클라우드 환경이나 BGP를 지원하는 네트워크에서 주로 사용됩니다.

3. AWS ENI 방식

설정

ipam: eni
enable-endpoint-routes: "true"
auto-create-cilium-node-resource: "true"
egress-masquerade-interfaces: eth+

AWS ENI 방식을 사용하려면 ipam 을 eni 모드로 변경해야 합니다. (ipam: eni)

enable-endpoint-routes: "true" 옵션은 ENI veth 쌍으로 직접 라우팅 (cilium_host 인터페이스로 라우팅 불필요)

auto-create-cilium-node-resource: "true" 옵션은 모든 필수 ENI 매개변수를 세팅하는 CiliumNode 리소스를 자동 생성

(이 기능을 비활성화하고 사용자가 리소스를 수동으로 제공할 수도 있습니다.)
egress-masquerade-interfaces: eth+ 옵션은 마스커레이딩 대상을 지정할 수 있는 인터페이스 선택자
(enable-ipv4-masquerade: "false" 옵션을 통해 마스커레이딩을 완전히 비활성화할 수 있습니다)

장점

라우팅 불필요
(AWS VPC 에서 직접 라우팅 가능한 ENI IP 를 할당. VPC 내 포드 트래픽 통신이 간소화되고 SNAT 불필요)
보안 그룹 생성 가능
(pod의 보안 그룹은 노드별로 구성. 노드 풀을 생성하고 각 pod에 서로 다른 보안 그룹을 할당할 수 있음)

단점

IP 제한
(EC2 인스턴스당 ENI IP 수가 제한되어 있음)
IP 할당 지연
(ENI 및 ENI IP 할당에는 속도 제한이 적용되는 EC2 API 와 상호작용하여 속도 제한됨)

구성

ingress: ENI 인터페이스(ethN)에서 트래픽 수신 후 veth 쌍으로 전달
egress: 파드에서 기본 경로를 통해 ENI 별 라우팅 테이블 사용

AWS ENI 방식은 AWS 네이티브 네트워킹의 장점을 최대한 활용하면서 파드에 직접 VPC IP를 할당합니다. 하지만 인스턴스 타입에 따른 ENI 제한과 EC2 API 의존성을 고려해야 합니다.

4. Google Cloud 방식

설정

gke.enabled: true  # 다음 옵션들 자동 활성화:
  # ipam: kubernetes
  # routing-mode: native  
  # enable-endpoint-routes: true
ipv4-native-routing-cidr: x.x.x.x/y

gke.enabled: true 옵션으로 google cloud 방식을 사용할 수 있으며, 아래 옵션들이 자동 활성화된다.

ipam: kubernetes: Kubernetes 호스트 범위 IPAM 활성화
routing-mode: native: 네이티브 라우팅 모드 활성화
enable-endpoint-routes: true: 노드에서 엔드포인트별 라우팅 활성화(로컬 노드 경로를 자동으로 비활성화)

ipv4-native-routing-cidr: x.x.x.x/y 옵션은 네이티브 라우팅이 지원되는 CIDR을 설정합니다.

주요 특징

라우팅 불필요
(Cilium 이 특정 쿠버네티스 노드에 할당된 PodCIDR을 기반으로 파드에 별칭 IP 를 할당하면 Google Cloud 네트워크에서 라우팅)
Masquerading 지원
(Cluster CIDR 외부 영역으로 트래픽 이동 시 자동으로 라우팅 가능한 IP 주소로 Masquerading 변환)
eBPF 기반 로드밸런싱
(ClusterIP 로드 밸런싱을 eBPF 기반으로 지원. GKE v1.15 이상 또는 Linux 커널 4.19 이상을 실행하는 경우, 모든 NodePort/ExternalIP/HostPort 서비스 타입도 eBPF 기반으로 처리)
네트워크 정책 및 가시성 지원
(eBPF 기반 NetworkPolicy 및 가시성 지원)

Google Cloud에서 Cilium을 실행할 경우, 네이티브 라우팅 구성 으로 실행되는 Cilium과 함께 Google Cloud의 네트워킹 계층을 활용할 수 있습니다. Alias IP를 통해 캡슐화 오버헤드 없이 파드 간 직접 통신이 가능하며, eBPF 기반으로 모든 네트워킹 기능이 처리됩니다.

Cilium Masquerading

pod IP 들은 사설 주소이기 때문에 공개적으로 라우팅 불가합니다. 이런 상황에서 클러스터 외부로 나가려면 모든 트래픽의 출발지 IP 들을 노드의 IP 로 변경할 필요가 있습니다. (노드 IP 는 네트워크에서 라우팅이 가능한 주소이기 때문) SNAT 의 한 형태라고 볼 수 있습니다.

Q. SNAT 과 Masquerading 의 차이점은?
A. 두 가지 방식 모두 출발지 주소를 변경하는 것은 동일하지만, SNAT 은 정적으로 고정 IP 로 변경하고 Masquerading 은 인터페이스에 들어오는 패킷의 IP 를 동적으로 확인하여 변경합니다. IP 주소를 변경하는 시점이 다릅니다.
고정 IP 환경에서는 SNAT 가 더 효율적이고, 동적 IP 환경에서는 Masquerading 이 필수적입니다.

필수적으로 보이지만, pod IP 까지 라우팅이 가능한 경우 아래와 같이 Masquerading 을 비활성화 할 수 있습니다.

enable-ipv4-masquerade: false  # IPv4 마스커레이딩 비활성화
enable-ipv6-masquerade: false  # IPv6 마스커레이딩 비활성화

구성 방법

ipv4-native-routing-cidr: 10.0.0.0/8    # IPv4용
ipv6-native-routing-cidr: fd00::/100     # IPv6용

앞서 설명했듯이 "파드와 파드 간 통신 시 NAT 없이 통신이 가능해야한다" CNI 요구사항에 따라 pod 대역대는 Masquerading 하지 않습니다. 따라서 pod 대역대는 ip?-native-routing-cidr 옵션을 통해 변환 제외합니다.

예를 들어, Pod 들이 10.244.1.0/24 범위의 IP를 사용한다면, 같은 범위 내의 다른 Pod 들로 가는 트래픽은 변환하지 않습니다. 즉 Pod A(10.244.1.10)에서 Pod B(10.244.1.20)로 통신할 때는 Pod IP 주소를 그대로 유지합니다.

구현 방법

Cilium Masquerading 은 eBPF 기반 구현 방식과 iptables 구현 방식이 존재합니다.

eBPF 기반 구현

활성화 설정

bpf.masquerade: true  # eBPF 마스커레이딩 활성화

특징

고성능: 가장 효율적인 구현 방식
BPF Host-Routing: 기본적으로 BPF 호스트 라우팅 모드 활성화
NodePort 의존성: 현재 BPF NodePort 기능에 의존 (향후 제거 예정)
디바이스 감지: NodePort 디바이스 감지 메커니즘으로 자동 장치 선택

지원 프로토콜

TCP/UDP: 완전 지원
ICMP: Echo request/reply, Destination unreachable 제한 지원

상태 확인

kubectl -n kube-system exec ds/cilium -- cilium-dbg status | grep Masquerading
# 출력 예: Masquerading: BPF (ip-masq-agent) [eth0, eth1] 10.0.0.0/16

eBPF 구현은 커널 수준에서 최적화되어 최고 성능을 제공하지만, IPv6는 베타 상태입니다. masquerading 프로그램이 실행되는 디바이스에서만 동작하며, 클러스터 노드의 External IP 로의 트래픽은 masquerading 하지않는 특징이 있습니다.

ip-masq-agent 통합

활성화 설정

ipMasqAgent.enabled: true

구성 옵션

nonMasqueradeCIDRs: 마스커레이딩 제외 CIDR 목록
masqLinkLocal: 링크 로컬 주소 마스커레이딩 여부
masqLinkLocalIPv6: IPv6 링크 로컬 주소 마스커레이딩 여부

기본 제외 CIDR

10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 100.64.0.0/10
192.0.0.0/24, 192.0.2.0/24, 192.88.99.0/24, 198.18.0.0/15
198.51.100.0/24, 203.0.113.0/24, 240.0.0.0/4
169.254.0.0/16 (링크 로컬), fe80::/10 (IPv6 링크 로컬)

ConfigMap 예시

apiVersion: v1
kind: ConfigMap
metadata:
  name: ip-masq-agent
data:
  config: |
    nonMasqueradeCIDRs:
    - 10.0.0.0/8
    - 172.16.0.0/12
    - 192.168.0.0/16
    masqLinkLocal: true

ip-masq-agent 는 세밀한 masquerading 제어를 제공하며, Fsnotify 를 통해 설정 파일 변경을 실시간으로 추적합니다. 기본적으로 사설 주소와 링크 로컬 주소는 masquerading 에서 제외됩니다.

iptables 기반 구현

특징

레거시 구현: 모든 커널 버전에서 동작
기본 동작: Cilium이 아닌 네트워크 디바이스로 나가는 모든 트래픽 마스커레이딩
인터페이스 제한: egress-masquerade-interfaces 옵션으로 특정 인터페이스만 masquerading 지정 가능
인터페이스 우선순위
- egress-masquerade-interfaces 설정 시: 해당 인터페이스 우선 사용
- 미설정 시: devices 필드의 인터페이스 사용
- 접두사 매칭: eth+ ens+ 형태로 여러 인터페이스 패턴 지정 가능

iptables 기반은 레거시한 모드로 권장하지 않습니다.

'인프라 > 쿠버네티스' 카테고리의 다른 글

[cilium] cilium 의 LoadBalancer 서비스 (2)	2025.08.09
[cilium] Overlay Network (1)	2025.08.09
[cilium] IPAM (3)	2025.07.31
[cilium] Hubble Exporter (2)	2025.07.23
[cilium] Hubble 개념과 설치 (5)	2025.07.21

골드에그