Cilium?
Cilium은 클라우드 네이티브 환경에서 네트워킹, 보안, 그리고 관찰가능성(observability)을 제공하는 오픈소스 프로젝트
CNCF Graduated !
왜 쓰는가?
- 속도 (성능): 구식 기술(iptables) 대신 최신 기술(eBPF)을 써서 데이터 처리가 압도적으로 빠름.
- 보안: 단순히 주소를 막는 게 아니라, "특정 API 명령" 수준까지 세밀하게 통제 가능.
- 가시성: 네트워크가 어디서 막히는지, 누가 누구와 통신하는지 지도(Hubble)로 보여줌.
- 효율성: 복잡한 대리인(Sidecar) 설치 없이도 암호화나 트래픽 관리가 가능해 메모리 절약.
- 연결성: 서로 다른 여러 클러스터나 클라우드를 하나의 네트워크처럼 묶기 쉬움.
즉, "쿠버네티스 네트워킹을 가장 빠르고, 안전하고, 투명하게 만들기 위해서" 쓴다.
특징
Cilium eBPF 는 추가적인 App 이나 설정 변경 없이 리눅스 커널을 자유롭게 프로그래밍하여 동작 가능
eBPF? 커널 프로그램이라고 생각하라
eBPF(extended Berkeley Packet Filter)는 리눅스 커널을 프로그래밍할 수 있게 해주는 기술
💡 결국 Application or Userspace 레벨이 아닌 더 낮은 레벨인 커널 레벨에서 네트워크를 컨트롤 하는 프로그램을 할수있다.
핵심 특징
- 무변경 통합: 기존 애플리케이션이나 설정 변경 없이 커널 프로그래밍 가능
- 커널 레벨 성능: 리눅스 커널에서 직접 동작하여 최고 성능 제공
- 안전한 실행: 커널 안정성을 보장하면서 바이트코드를 안전하게 로딩
기존 Linux 네트워크 스택 문제점
주요 문제점
- 복잡성: 네트워크 스택이 너무 복잡해서 이해하기 어려움
- 변경 어려움: 작은 수정에도 많은 시간과 노력이 필요
- 제약사항: 네트워크 레이어 간 자유로운 이동이 어려움
IPtables의 한계점
기존 네트워킹의 주력인 IPtables, 하지만 현대 환경에서는 여러 한계를 드러내고 있습니다.
1️⃣ 비효율적인 업데이트 방식 -> 늘어날수록 느려지고 복잡함
# 작은 규칙 하나만 바꿔도...
iptables -D INPUT -s 192.168.1.100 -j DROP
iptables -A INPUT -s 192.168.1.101 -j DROP
# 전체 규칙 체인을 다시 구성해야 함 - 단일 트랜잭션: 모든 규칙을 처음부터 다시 만들어야 함
- 전체 재구성: 하나만 바꿔도 전체 규칙 세트를 다시 만들어야 함
2️⃣ 성능 이슈의 늪
- 연결 리스트 구조: 규칙들이 일렬로 연결되어 있음
- O(n) 복잡도: 규칙이 많아질수록 기하급수적으로 느려짐
- 순차 탐색: 첫 번째부터 하나씩 확인해야 함
규칙 1개: 1ms
규칙 100개: 100ms
규칙 1000개: 1000ms 3️⃣ 프로토콜 지원의 한계
- L3/L4 중심: IP 주소와 포트 번호만 이해
- L7 무지: HTTP, gRPC, Kafka 같은 애플리케이션 프로토콜 처리 불가
- 세밀한 제어 부족: API 엔드포인트별 제어 어려움
4️⃣ 동적 환경에서의 고통
클라우드 네이티브 환경에서는 리소스가 계속 생성/삭제되는데...
# Pod가 생성될 때마다
apiVersion: v1
kind: Pod
metadata:
name: new-pod-xyz123 # 새로운 IP 할당!- 지속적인 규칙 변경: 새 IP/포트마다 규칙 추가 필요
- 관리 복잡성: 동적 변화에 대응하기 어려움
5️⃣ Kubernetes에서의 자원 소모
# 대규모 클러스터에서...
kubectl get pods --all-namespaces | wc -l
# 결과: 1000+ pods
# iptables 규칙 수
iptables -L | wc -l
# 결과: 10000+ rules - 높은 자원 소모: CPU, 메모리 과다 사용
- 확장성 제약: 대규모에서 성능 병목
- 관리 지옥: 수많은 규칙 관리의 어려움
eBPF vs IPTables
| 항목 | IPTables | eBPF |
|---|---|---|
| 구조 | 연결 리스트 | 해시 테이블 |
| 성능 | O(n) 탐색 | O(1) 탐색 |
| 업데이트 | 전체 재구성 | 개별 업데이트 |
| 프로토콜 | L3/L4만 | L3~L7 전부 |
| 동적 환경 | 비효율적 | 최적화됨 |
| 자원 사용 | 높음 📈 | 낮음 📉 |
| 확장성 | 제한적 | 뛰어남 🚀 |
eBPF 성능 개선 이점
성능 개선
// eBPF 프로그램 예시
SEC("xdp")
int drop_packets(struct xdp_md *ctx) {
// 커널에서 직접 실행!
// 컨텍스트 스위칭 없음
return XDP_DROP;
}- 커널 레벨 처리: 사용자-커널 공간 전환 없음
- 해시 테이블: O(1) 시간에 데이터 접근
- JIT 컴파일: 네이티브 성능으로 실행
유연성과 안전성
# eBPF 맵을 통한 동적 설정
bpf_map_update_elem(policy_map, &key, &value, BPF_ANY)
# 런타임에 즉시 반영! 재시작 불필요 - 프로그래밍 가능: 커널에서 맞춤형 로직 구현
- ️ 안전성 보장: 커널 크래시 없는 안전한 실행
- 실시간 업데이트: 시스템 재시작 없이 기능 변경
풍부한 프로토콜 지원
# Cilium L7 정책 예시
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: api-access
spec:
endpointSelector:
matchLabels:
app: backend
ingress:
- fromEndpoints:
- matchLabels:
app: frontend
toPorts:
- ports:
- port: "8080"
protocol: TCP
rules:
http:
- method: "GET"
path: "/api/v1/users" # API 레벨 제어! 핵심 요약
- 성능: IPtables 대비 10배 이상 향상
- 정밀성: API 레벨까지 세밀한 제어
- 확장성: 대규모 환경에서도 선형적 성능
- 운영성: 복잡한 네트워크 정책을 간단하게
4. 동적 환경 관리 복잡성
- 규칙 추가/변경 오버헤드: 새로운 IP/포트 매칭 시 규칙 추가 및 체인 변경 필요
- 동적 변화 대응 어려움: 클라우드/컨테이너 환경의 빈번한 변화에 비효율적
5. Kubernetes 환경에서의 문제
- 높은 자원 소모: 수많은 서비스와 파드로 인한 CPU, 메모리 과다 사용
- 확장성 제약: 대규모 클러스터에서 성능 병목 현상 발생
- 관리 복잡성: 동적으로 생성/삭제되는 리소스 관리의 어려움
eBPF vs IPTables/Netfilter 비교
| 구분 | IPTables/Netfilter | eBPF |
|---|---|---|
| 구조 | 연결 리스트 기반 | 해시 테이블 기반 |
| 성능 | O(n) 탐색 | O(1) 탐색 |
| 업데이트 | 전체 재구성 필요 | 개별 규칙 업데이트 |
| 프로토콜 지원 | L3/L4 중심 | L3~L7 전 계층 지원 |
| 동적 환경 | 비효율적 | 최적화됨 |
| 자원 사용 | 높음 | 낮음 |
| 확장성 | 제한적 | 뛰어남 |
eBPF의 장점
성능 우수성
- 커널 레벨 처리: 사용자 공간-커널 공간 컨텍스트 스위칭 최소화
- 효율적 데이터 구조: 해시 테이블 등을 활용한 빠른 데이터 접근
- 최적화된 바이트코드: JIT 컴파일을 통한 네이티브 성능
유연성과 확장성
- 프로그래밍 가능: 커널 레벨에서 맞춤형 네트워킹 로직 구현
- 안전성: 커널 안정성을 해치지 않는 안전한 코드 실행
- 실시간 업데이트: 시스템 재시작 없이 동적 기능 변경 가능
bytebliss