[Cilium] (1) Cilium 소개 및 개념 정리

Cilium을 이해 하기 위한 개념 정리

목표: Cilium을 보다 깊이 이해하기 위해 관련 개념들을 정리합니다.
특히 기존 CNI들과의 차이, Linux 네트워크 스택, 그리고 핵심 기술인 XDP, TC 등에 집중합니다.

---

1. Cilium이란? 

Cilium은 eBPF 기반의 네트워크, 보안, 가시성 기능을 제공하는 Kubernetes CNI 플러그인입니다. 전통적인 iptables 또는 오버레이 네트워킹 기반이 아닌, Linux 커널 레벨의 eBPF 기술을 활용하여 고성능/고확장성 네트워킹을 가능하게 합니다.

 

---

2. Native Routing vs Overlay

기존에 사용했던 CNI들은 온프렘 환경에서 항시 워커노드의 eth0인터페이스의 IP로 NAT를 해서 통신을 하는 형태로 사용해 왔다.

 nginx ingress controller를 사용하더라도 워커노드의 ip로 nat하여 통신하는 방식으로 사용하였다. 

 

overlay 방식을 사용하면 encapsulation 오버헤드 발생과 NAT로 인하여 명확한 분석이 가끔 어려울때가 있었다.

하지만 vpc cni와 cilium의 native routing을 이용하면 이러한 한계를 극복할수 있다.

📌 오버레이 vs 네이티브 (Overlay vs Native Routing)

항목	기존 CNI (Flannel, Calico 등)	Cilium
네트워크 방식	오버레이(VxLAN, IP-in-IP)	네이티브 라우팅 or eBPF
데이터 경로	사용자 공간(User Space) 일부 사용	커널 공간(Kernel Space) 내 eBPF
성능	encapsulation 오버헤드 발생	높은 성능 (no encapsulation)
복잡도	네트워크 디버깅 어려움	투명한 트래픽 추적(eBPF tracepoints 등)

📌 Pod 통신 방식 비교:

기존 Overlay CNI vs Amazon VPC CNI / Cilium (Native Routing)

Kubernetes에서 Pod 간 통신은 CNI 플러그인의 방식에 따라 크게 두 가지로 나뉩니다.

• 오버레이 + NAT 기반 방식 (Flannel, Calico 등)
• 네이티브 라우팅 기반 방식 (Amazon VPC CNI, Cilium native routing)

이 문서에서는 두 방식의 구조와 특징을 비교합니다.

---

🌐 기존 CNI (Flannel, Calico 등 Overlay 모드)

📌 NAT + Overlay 기반 통신 구조

• Pod 간 통신 시 VxLAN 또는 IP-in-IP 터널링을 사용합니다.
• 트래픽은 노드의 eth0 IP로 NAT 되어 전달됩니다.
• Pod IP는 클러스터 내부에서만 유효합니다.

📌  통신 흐름 예시

Pod A (10.244.0.2)
  → Overlay 터널 (VxLAN)
  → Node A eth0 IP (192.168.1.10)로 NAT
  → Node B eth0 IP
  → Node B의 터널 인터페이스에서 decapsulation
  → Pod B (10.244.1.3)

📌  특징

• encapsulation 오버헤드 존재
• NAT으로 인해 Pod IP 추적 어려움
• 클라우드 네트워크와의 통합이 까다로움

---

🌐 Amazon VPC CNI / Cilium (Native Routing)

📌 Pod IP가 직접 라우팅되는 구조

• Pod에 VPC CIDR 내 IP를 직접 할당하거나, 라우팅 테이블로 Pod IP를 직접 통신하게 합니다.
• NAT 및 encapsulation 없이 통신합니다.

📌 통신 흐름 예시

Pod A (10.0.1.25 in VPC)
  → ENI를 통한 네이티브 라우팅
  → Pod B (10.0.2.14 in VPC)

📌  특징

• NAT 없음 → Pod IP 그대로 통신
• 높은 성능
• VPC/Subnet과 자연스럽게 통합 가능
• 디버깅 및 모니터링 용이

---

📌  차이점 요약

항목	Overlay CNI	VPC CNI / Cilium (Native)
방식	Overlay (VxLAN/IP-in-IP) + NAT	Native Routing
NAT 사용	Node eth0 IP로 NAT	없음
라우팅	터널 기반	VPC 라우팅 테이블 기반
성능	오버헤드 존재	고성능
MTU 문제	있음	없음
Pod IP 노출	외부에 노출 안 됨	그대로 노출
VPC 통합	복잡	자연스러움

---

📌  결론

• 기존 CNI는 간단하게 시작하기는 쉽지만, 성능/운영 면에서 한계가 있습니다.
• VPC CNI나 Cilium은 클라우드 친화적인 구조로, 고성능과 디버깅 편의성을 동시에 제공합니다.

특히 Cilium은 eBPF 기반으로, NAT 없이도 정책 제어와 관찰 기능을 고성능으로 제공할 수 있는 장점이 있습니다.

---

Cilium의 특장점

 

• eBPF 기반
  → 사용자 공간 전환 없이 커널 레벨에서 고성능 네트워크 처리를 가능하게 합니다. 효율적인 네트워킹, 가시성, 추적, 보안을 위해 커널을 동적으로 프로그래밍한다.

eBPF는 커널 소스 코드를 변경하거나 커널 모듈을 로드하지 않고도 리눅스 커널에서 샌드박스된 프로그램을 실행할 수 있는 혁신적인 기술입니다.

• 투명한 보안 정책
  → Kubernetes NetworkPolicy뿐 아니라 L7 레벨까지 세밀한 정책 제어 가능 (예: HTTP method/hostname 기반 제어)
• 강력한 가시성
  → Hubble을 통해 실시간 네트워크 흐름을 시각화 가능 (Pod 간 통신, Drop된 패킷 등)
• Service Mesh 대체 가능
  → Proxy 없는 Istio 기능 일부 제공 (L4-L7 observability, 정책 등)

---

 Linux Network Stack

 

Cilium을 제대로 이해하기 위해선 Linux Networking Stack을 알아야 합니다.

흐름 요약:

NIC → XDP → TC (clsact/qdisc) → Netfilter/iptables → Socket → Application

• XDP (eXpress Data Path)
  NIC에서 들어오는 패킷을 가장 빠르게 처리할 수 있는 hook. 커널에 진입하기 전에 실행됨.
• TC (Traffic Control)
  주로 트래픽 shaping/qos 용도로 사용되며, ingress/egress 트래픽을 필터링하거나 큐잉 가능.
• Netfilter/iptables
  기존 네트워크 정책 처리 방식. 커널 공간에서 일어나지만 상대적으로 느리고 복잡함.

Cilium은 이 구조 중에서 XDP 또는 TC를 사용해 트래픽을 빠르게 처리하고, 기존 iptables 경로를 우회합니다.

📌  XDP와 TC는 왜 Hook이라고 불릴까?

Linux 네트워크에서 흔히 XDP hook, TC hook이라는 표현을 접하게 됩니다. 이 글에서는 "왜 이들을 hook이라고 부르는지", 그리고 네트워크 스택 내에서 어떤 역할을 하는지를 정리해봅니다.

---

📌 Hook이란?

Hook은 소프트웨어 시스템에서 "특정 이벤트 지점에 외부 코드나 기능을 연결해 실행할 수 있도록 하는 메커니즘"입니다.

예시: 마우스 클릭 이벤트가 발생했을 때 사용자가 정의한 함수가 호출되는 것 → 이 함수가 hook된 상태입니다.

---

📌  Linux Network Stack에서의 Hook ?

Linux 커널의 네트워크 흐름은 패킷이 NIC로 들어오고 사용자 공간까지 도달하는 여러 단계를 거칩니다. 이 중에서 패킷 처리 흐름 중간에 사용자 정의 동작(eBPF 프로그램 등)을 주입할 수 있는 지점들이 바로 hook point입니다.

---

📌  대표적인 Hook: XDP와 TC

XDP (eXpress Data Path)

• 위치: NIC → 커널 진입 이전
• 특징: 가장 빠른 위치에서 패킷을 처리 가능
• 용도: 패킷 Drop, Redirect, Load Balancer 등

TC (Traffic Control)

• 위치: 커널 내부, ingress 또는 egress 시점
• 특징: 다양한 네트워크 정책 적용 가능
• 용도: shaping, filtering, mirroring, QoS 등

---

📌  네트워크 패킷 처리 흐름과 Hook 위치

[ NIC ]
   ↓        ← XDP Hook (Driver or Native mode)
[ Kernel Ingress Queue ]
   ↓        ← TC Ingress Hook (clsact qdisc)
[ Netfilter / iptables ]
   ↓
[ Socket Buffer ]
   ↓
[ Application ]

(반대 방향)
[ Application ]
   ↓
[ TC Egress Hook ]
   ↓
[ NIC ]

---

📌 요약 비교

항목	XDP Hook	TC Hook
위치	NIC → 커널 진입 전	커널 내부 ingress/egress
성능	매우 빠름 (low-level)	중간 정도
주요 목적	Drop, Redirect, LB	QoS, shaping, 정책 적용
실행 방식	eBPF 직접 실행	eBPF + qdisc/class 구조
장점	성능 최우선	유연한 정책 처리

---

📌  왜 중요한가?

• Cilium 같은 현대적 CNI는 XDP/TC hook을 적극 활용해, 기존 iptables보다 빠르고 유연한 패킷 처리를 가능하게 합니다.
• 디버깅이나 성능 튜닝 시 어느 hook에 어떤 eBPF가 attach되어 있는지 아는 것이 매우 중요합니다.

---

📌  마무리

XDP와 TC는 단순한 기능이 아니라, 패킷 흐름 중 특정 위치에 '코드를 삽입할 수 있는 연결점(hook)'입니다. 이 구조를 이해하면 Cilium 같은 네트워크 시스템의 작동 원리를 훨씬 깊이 있게 이해할 수 있습니다.

---

TC : Linux 네트워크 스택의 트래픽 제어 도구 ( Queing, Filtering )

🧠 TC (Traffic Control)

TC(Traffic Control)는 Linux 커널의 네트워크 트래픽을 제어하는 주요 도구 중 하나입니다. TC는 주로 트래픽을 큐잉하고 필터링하는 데 사용되며, 네트워크 인터페이스별로 다양한 트래픽 제어 규칙을 설정할 수 있습니다. 이를 통해 TC는 다음과 같은 작업을 수행할 수 있습니다.

• 커널 네트워크 스택 내부에서 ingress/egress 시에 실행, 위에 구조도 참고
• 네트워크 shaping, QoS, 큐잉 등 가능

Linux TC (Traffic Control) - Shaping과 Queuing 실습 

Linux 커널의 tc (Traffic Control)는 네트워크 인터페이스의 트래픽 제어를 위한 강력한 도구입니다. 이 문서에서는 tc를 이용해 shaping과 queuing을 실습 형태로 설명합니다.

---

🚦 기본 개념 정리

용어	설명
qdisc (queueing discipline)	패킷을 큐에 넣고 빼는 정책 (FIFO, TBF, HTB 등)
shaping	네트워크 대역폭을 제한하거나 지연시키는 행위
queuing	패킷을 어떻게 스케줄링하여 보낼지 결정하는 행위
class	qdisc 내부에서 패킷을 분류하는 단위 (HTB 등에서 사용)

---

🧪 실습: tc를 이용한 트래픽 제어

✅ 예제 1: tbf로 송신 속도 제한

# eth0 인터페이스의 송신 대역폭을 1Mbps로 제한
sudo tc qdisc add dev eth0 root tbf rate 1mbit burst 32kbit latency 400ms
sudo tc qdisc show dev eth0

## 확인 ##
# qdisc tbf 8001: root refcnt 2 rate 1Mbit burst 4Kb lat 400ms


# Tab 하나 더 켜서 ssh 접속 (k8s-w1)
vagrant ssh k8s-w1
sudo apt install -y iperf3
iperf3 -c <server-ip> -t 10


# 1번 Tab ssh 접속 (k8s-ctr)
iperf3 -c <k8s-w1-server-ip> -t 10

• rate: 최대 전송 속도
• burst: 순간 허용량 (버킷 크기)
• latency: 최대 대기 시간

왼쪽이 Transfer 1MB로 대역폭 제한

---

✅ 예제 2: netem으로 지연/손실 시뮬레이션

# 100ms 지연, 10% 패킷 손실 적용
sudo tc qdisc add dev eth0 root netem delay 100ms loss 10%

• 테스트 환경에서 지연, 손실, 재전송 등을 시뮬레이션할 수 있음

---

✅ 예제 3: htb로 클래스 기반 대역폭 제어

# 루트 qdisc 추가
sudo tc qdisc add dev eth0 root handle 1: htb default 30

# 전체 대역폭 제한 (10mbit)
sudo tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit

# 서브 클래스 1:10 → 3mbit, 1:20 → 7mbit
sudo tc class add dev eth0 parent 1:1 classid 1:10 htb rate 3mbit ceil 5mbit
sudo tc class add dev eth0 parent 1:1 classid 1:20 htb rate 7mbit ceil 10mbit

# 특정 IP 트래픽을 1:10에 할당
sudo tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.1.100 flowid 1:10

• class와 filter를 조합하면 복잡한 QoS 정책 구현 가능

---

🔧 설정 확인 및 삭제

# 설정 확인
sudo tc qdisc show dev eth0
sudo tc class show dev eth0
sudo tc filter show dev eth0

# 설정 초기화
sudo tc qdisc del dev eth0 root

---

📘 TC 기능 요약

기능	qdisc 종류	용도
속도 제한	TBF	간단한 대역폭 shaping
지연/손실 시뮬레이션	netem	테스트 환경
클래스 기반 정책	HTB	다중 흐름 제어, 우선순위 설정

tc는 DevOps, 클라우드 네트워크, CI/CD 테스트 환경 등에서 매우 유용한 도구입니다.

실제 운영 환경에서는 iproute2 패키지의 tc 명령어를 활용하며, Cilium 같은 현대적인 네트워크 솔루션에서도 내부적으로 TC hook을 사용하는 경우가 많습니다.

 

---

📌  전체 마무리

Cilium은 단순한 CNI 그 이상입니다. eBPF라는 최신 커널 기술을 활용해 Kubernetes 네트워킹, 보안, 가시성 영역을 혁신적으로 향상시킵니다. 기존 CNI 대비 성능과 운영 편의성 측면에서 많은 장점을 가지며, 특히 고성능 클러스터나 보안 민감 환경에서는 매우 유용합니다.

다음 포스팅에서는 Cilium의 특징에 좀 더 구체적으로 다뤄보겠습니다.