[Cilium] Cilium CNI과 eBPF 소개

Cloudnet Cilium 1주차 스터디를 진행하며 정리한 글입니다.

이번 포스팅에서는 Cilium CNI와 eBPF 대해 소개하는 포스팅해보겠습니다.

 

Cilium CNI

Cilium은 eBPF (Berkeley Packet Filter)를 기반으로 Pod Network 환경 + 보안 을 제공하는 CNI Plugin 입니다.

원래는 패킷 필터링용으로 만들어졌지만, 현재는 네트워크, 보안, 성능 측정, 관찰 가능성(Observability) 등 다양한 영역에서 사용됩니다.

eBPF는 커널 모듈을 직접 수정하거나 재컴파일하지 않고도 커널 레벨에서 동작할 수 있습니다.

 

 

https://isovalent.com/blog/post/migrating-from-metallb-to-cilium/

 

 

eBPF

cilium의 기본이 되는 eBPF에 대해 이해하고 넘어가도록 하겠습니다.

https://ebpf.io/what-is-ebpf/

 

리눅스에서 네트워크 패킷이 들어오면 기본적으로 커널을 거쳐 사용자 영역(Userspace)으로 오가며 처리됩니다.
예를 들어 iptables도 커널-유저스페이스를 오가며 작동하는 구조입니다. iptables는 사용자는 유저스페이스에서 명령어를 실행하지만,
실제로는 커널에 있는 netfilter라는 시스템에 규칙을 등록해서 동작합니다.

ex) sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

이건 유저스페이스에서 실행되지만, 이 명령은 커널 내부의 Netfilter라는 커널 모듈에 규칙을 전달해서 저장됩니다. 그러면 실제 패킷이 들어올 때마다 커널은 등록된 Netfilter 규칙 체인을 따라가며 검사합니다.

하지만 이런 방식은 패킷 하나 처리하는 데도 여러 단계와 오버헤드가 생기고, 규칙이 많아지면 성능이 떨어지게 됩니다.

 

이러한 문제를 해결할 수 있는 기술이 eBPF입니다. eBPF는 리눅스 커널에서 사용자 정의 코드를 실행할 수 있게 해주는 기술입니다. 

기존 커널 코드를 변경하지 않고도 커널의 기능, 성능, 보안을 확장할 수 있도록 네트워크 트래픽을 실시간으로 필터링하거나, 모니터링하거나, 심지어 보안 정책을 적용할 수도 있습니다. 기존에는 이런 걸 하려면 커널 코드를 직접 고치거나 모듈을 다시 컴파일해야 했는데, eBPF는 그냥 커널 안에 샌드박스를 만들어놓고 그 안에 코드를 심는 것처럼 동작해서 훨씬 유연하고 안전합니다.

 

 

일반적인 Linux 네트워킹과 eBPF 기반 Linux 네트워킹 비교

 

 

 

 

실제 프로세스에서 호출 시 일반적인 리눅스 네트워킹 구조를 사용한 경우와 eBPF를 사용한 경우의 호출 흐름을 비교해보겠습니다.

 

왼쪽 그림인 기존 리눅스 네트워킹 구조에서는 (유저스페이스 네트워킹) 커널과 유저스페이스간 왕복이 자주 발생하여, 규칙이 많아지면 iptables를 전부 검사해야해서 느려집니다.

1. 프로세스가 sendmsg() / recvmsg() 같은 시스템 콜을 호출해 소켓 I/O를 요청
2. 이 호출은 Syscall을거쳐 커널로 들어감
3. 커널의 소켓 계층과 네트워크 디바이스 드라이버를 통해 실제 패킷이 송수신
4. 어떤 기능(필터링, 로깅, 캡처, 가속 등)을 추가로 하려면 유저스페이스 네트워킹 스택쪽으로 패킷을 끌어올려 추가 처리 후 다시 내려보내는 경우가 있음
5. 이렇게 유저스페이스와 커널을 왕복하는 경우 컨텍스트 스위칭 비용 + 패킷 복사 비용이 발생

오른 쪽 그림인 eBPF 모드에서는 (Cilium) eBPF는 유저스페이스로 나오지 않고 커널 안에서 모든 것을 다 처리합니다.

1. 동일하게 프로세스는 시스템 콜을 통해 커널로 진입
2. 커널 내부의 여러 지점(소켓, TCP/IP 스택, NIC 드라이버 앞단 등)에 eBPF 프로그램이 Hook되어 있음
3. 필요 기능(필터링, 통계, 정책 검사 등)을 커널을 벗어나지 않고 곧바로 처리
4. 유저스페이스 왕복이 줄어들고, 복사/컨텍스트 스위치 비용이 크게 감소

 

eBPF를 활용한 시스템콜 동작 방식

 

 

 

다음 그림은 eBPF를 사용한 시스템콜 모니터링의 동작 방식을 구체적으로 이해해보겠습니다. 해당 eBPF 프로그램은 execve() 시스템 콜이 완료될 때마다 어떤 프로세스가 실행되었는지 모니터링하고 로깅하는 역할을 합니다. 보안 모니터링이나 시스템 분석에 유용합니다.

 

 

1. 유저 프로세스가 새로운 프로그램을 실행하려고 execve() 호출
2. Syscall을 통해 커널로 들어감
3. 커널 내부에서 execve 처리 루틴이 실행되는 도중, eBPF 프로그램이 Hook된 지점이 호출됨
4. eBPF 프로그램은 현재 프로세스 정보(예: PID, comm = 실행된 커맨드)를 읽어 이벤트 구조체에 담음
5. bpf_perf_event_output() 같은 Helper를 써서 유저스페이스로 이벤트 전송
6. 유저 공간의 bcc/bpftrace/Cilium 등 수집 프로그램이 이 이벤트를 읽어 로그/모니터링/정책에 사용

 

eBPF Hook은 커널의 특정 지점에 eBPF 프로그램을 연결하는 지점을 의미합니다. 이를 통해 커널을 수정하지 않고도 다양한 커널 이벤트를 모니터링하고 처리할 수 있습니다.

Hook 종류	실행 환경	활용 예시
Syscall Hook	execve(), open(), connect() 등 시스템 콜 호출/리턴 시	프로세스 실행 추적, 보안 감사
Kprobe / Kretprobe	커널 함수 진입/리턴 시	커널 동작 디버깅, 성능 분석
Uprobe	유저 프로그램 함수 위치 Hook	특정 앱 동작 관찰
Tracepoint	커널이 노출한 측정 포인트	스케줄링, 블록 I/O 추적
Socket / TC / XDP	네트워크 경로 상에서	패킷 필터링, 정책, 로드밸런싱
Cgroup Hook	cgroup별 리소스 경계에서	컨테이너별 네트워크 제어

 

 

 

 

참고할만한 기본 개념)

 

++) Kernel(커널)이란?

커널은 운영체제의 가장 핵심적인 부분으로, 하드웨어와 소프트웨어 사이에서 중개자 역할을 하며, 시스템 자원을 안전하게 관리합니다.

 

• CPU, 메모리, 디스크, 네트워크, 장치(I/O) 등 하드웨어 제어
• 파일 시스템, 프로세스, 스레드, 권한 등 기본 자원 관리
• 유저 프로그램과 하드웨어를 이어주는 인터페이스 제공

 

++) Userspace(유저스페이스)란?

유저 스페이스는 사용자 프로그램이 실행되는 공간입니다.

• bash, vim, chrome, python, nginx, kubectl … 전부 유저 스페이스에서 실행
• 유저 스페이스에서는 직접 하드웨어를 건드릴 수 없고, 필요할 땐 항상 커널에게 요청 -> 시스템 콜(system call)

-> 사용자 코드가 실수하거나 악의적으로 행동해도 커널 전체가 망가지지 않게 커널-유저 모드를 분리하였습니다.

 

 

++) Sandbox(샌드박스)란?

제한된 공간 안에서 실행되는 코드나 프로그램을 의미합니다.

eBPF는 리눅스 커널 안에서 실행됩니다. 그 말은 곧 시스템의 가장 민감하고 중요한 부분에서 동작한다는 뜻으로, eBPF는 커널에서 실행되지만, 그 코드가 커널 자체를 건드리거나 망가뜨리지 못하게 철저히 통제됩니다.

 

 

보통은 유저 프로그램이 커널에 명령을 요청하고 커널이 처리하는 구조인데, eBPF는 그 요청을 직접 처리하는 코드를 커널 안에 넣는 방식이면 위험하지 않을까?

→ 그래서 샌드박스 구조를 사용하여 커널 안에 넣더라도 시스템을 해치지 않도록 제한을 걸어둡니다.

 

참고)

eBPF - Superpowers for Networking, Observability & Security - Liz Rice - Swiss Cloud Native Day 2021

https://www.youtube.com/watch?v=qsnR-s4XuGo&t=1059s

 

 

• 커널에서 직접 안전하게 사용자 정의 코드 실행 가능
  eBPF는 커널 이벤트(예: 시스템 호출, 네트워크 패킷)에 반응하는 코드를 커널에 안전하게 주입해 실행할 수 있도록 해줍니다. 이 코드는 검증 과정을 거쳐 커널을 불안정하게 만들지 않으면서도 강력한 확장성을 제공합니다.
• 모든 컨테이너에 대한 커널 수준 가시성 제공
  Kubernetes의 모든 파드는 하나의 커널을 공유하기 때문에, eBPF 기반 도구(Cilium, Falco, Pixie 등)는 애플리케이션 변경이나 사이드카 없이도 시스템 호출, 네트워크 트래픽, 프로세스 실행 등을 관찰할 수 있습니다.
• 전통적 방식보다 뛰어난 네트워크 성능
  Cilium, Calico(eBPF 모드) 같은 CNI는 eBPF를 활용해 불필요한 네트워크 스택을 우회하고, 거의 네이티브 성능 수준의 패킷 처리 속도를 제공합니다. 전통적인 iptables 기반 방식보다 성능이 월등합니다.
• 애플리케이션 수정 없이 보안 및 관측 가능성 강화
  eBPF는 PID, 프로세스 정보, 네트워크 흐름 등 실행 맥락을 포착해 사이드카나 에이전트 없이도 보안 위협(예: 암호화폐 채굴, C2 서버 연결)을 탐지하고, 이를 기반으로 SIEM 등에 연동된 경고 시스템을 만들 수 있습니다.
• 다양한 플랫폼으로 확장 중, 강력한 생태계 형성
  eBPF는 리눅스에서 시작되었지만 현재는 Windows와 임베디드 시스템으로 확장되고 있으며, Meta, Google, Microsoft, Netflix 등이 참여한 eBPF 재단이 안전성과 생태계 성장을 주도하고 있습니다.

 

 

 

 

 

Cilium 구성 요소

• Cilium Operator : 클러스터 전체를 관리하는 컨트롤러
  • CRD (Custom Resource Definition) 관리
  • IP 주소 관리 (IPAM)
  • 노드간 연결 관리
  • 클러스터 메시 구성
• Cilium Agent : 각 노드에서 실행되는 핵심 데몬
  • eBPF 프로그램 컴파일 및 로드
  • 네트워크 정책 적용
  • 로드 밸런싱 구현
  • 서비스 디스커버리
  • 메트릭 수집
• Cilium Client (CLI) : Cilium 커멘드툴, eBPF maps 에 직접 접속하여 상태를 확인
• Hubble : 네트워크와 보안 모니터링 플랫폼 역할을 하여, 'Server, Relay, Client, Graphical UI' 로 구성
• Data Store : Cilium Agent 간의 상태를 저장하고 전파하는 데이터 저장소, 2가지 종류 중 선택 (K8S CRDs, Key-Value Store)

 

 

Cilium 동작 흐름

 

 

1. Pod 생성

• kubelet이 CNI 플러그인을 호출 → cilium-cni 실행
• cilium-cni는 해당 Pod용 veth 인터페이스, routing 설정, IP 할당을 처리
• 동시에 이 Pod에 연결된 eBPF 프로그램 및 정책을 준비

2. Cilium Agent 역할

• Kubernetes API로부터 다음 정보를 수신:
  • Pod의 IP, Label
  • 서비스 정보 (ClusterIP, Endpoints 등)
  • 네트워크 정책(CiliumNetworkPolicy)
• 그 정보를 기반으로 eBPF 맵을 업데이트하고, 적절한 위치에 eBPF 프로그램 attach

3. eBPF 처리 Hook

• 다음 커널 Hook에 eBPF 프로그램이 붙음

Hoo 위치	기능
XDP	수신 패킷을 가장 먼저 처리 (DDoS 차단, 드롭)
TC (Traffic Control)	송수신 시 L3/L4 수준 정책, NAT, 로드밸런싱
Socket Layer	L7 프로토콜 확인 (HTTP path 등), CIDR 검사
Syscall Hook	exec, open 등 시스템 콜 추적 (audit 용도)

 

4. 서비스 접근

• 클러스터 IP에 접근하면, iptables 없이도 eBPF 기반 로드밸런싱 수행
• Cilium이 bpf lb 맵을 통해 ClusterIP를 Endpoints로 NAT 처리

5. 정책 적용

• CiliumNetworkPolicy 리소스를 기반으로, 어떤 Pod가 어떤 포트를 사용할 수 있는지 판단
• eBPF를 통해 L3~L7까지 정책을 강제 적용

6. Hubble 관측

• 위의 eBPF 프로그램들이 수집한 통계/추적 정보를 Hubble이 읽고, CLI나 UI로 확인 가능