Cilium이란?

Cilium은 eBPF 기술을 활용하여 쿠버네티스 같은 클라우드 네이티브 환경에서 고성능 네트워킹, 강력한 보안 정책, 그리고 정밀한 가시성을 통합적으로 제공하는 오프소스 솔루션이며, kube-proxy를 대신하여 서비스 메시로 많이 사용된다. 가장 먼저 들어가기 전에, 왜 kube-proxy가 한계를 가지는지 알아보자.

Kubernetes 서비스 가용성

Kubernetes 환경에서 Service는 동적으로 변하는 Pod들의 IP를 추상화하여 안정적인 엔드포인트를 제공하는 핵심 객체이다. 하지만 클러스터의 규모가 커지고, 마이크로서비스의 개수가 수백, 수천개로 늘어나면 우리가 당연하게 여겼던 서비스 통신은 무시할 수 없는 오버헤드를 가져오게 된다.

이는 오랜 기간 쿠버네티스의 기본 패킷 전달 모델로 사용되어 온 kube-proxy와 iptables의 특성 때문이다.

그럼 무슨 특성을 가지고 있길래?

kube-proxy의 iptables모드는 리눅스 커널의 방화벽 Netfilter를 활용한다. 특정 서비스로 향하는 트래픽을 실제 파드의 IP로 변환(NAT)하기 위해, kube-proxy는 커널 내 iptables 규칙 테이블을 지속적으로 업데이트한다.

여기서 핵심은 iptables가 패킷을 처리하는 방식인데, iptables는 규칙(Rule)들을 하나의 긴 연결 리스트 형태로 관리하기 때문이다. 이 형태는 패킷이 노드에 도착하면 커널은 해당 패킷의 목적지에 맞는 규칙을 찾을 때까지 리스트의 최상단부터 최하단까지 순차적으로 대조 작업을 수행할 수 밖에 없다.

이러한 순차적 평가 방식은 알고리즘 관점에서 $O(n)$의 시간 복잡도를 가지며, 여기서 $n$은 클러스터 내의 서비스 및 엔드포인트의 총 개수를 의미한다. 다음은 순차 대조 방식이 가져오는 문제점들이다.

1. 지연 시간: 서비스 개수가 적을 때는 대조 과정이 매우 빠르게 수행되어 차이를 느끼기 어렵다. 하지만 서비스가 늘어날수록 패킷 하나마다 대조해야 하는 Rule이 많아지며, 특히 리스트 하단에 위치한 서비스 규칙에 매칭되어야 하는 패킷은 더 큰 지연 시간을 겪게 된다.

2. CPU 부하: 모든 패킷에 대해 이 선형 탐색을 반복해야 하므로, 네트워크 트래픽이 높은 상황에서 서비스 개수까지 많아지면 커널의 CPU 사용량이 급격히 상승하고, 이는 곧 애플리케이션이 사용할 자원을 네트워크 오버헤드가 점유하게 된다.

3. 업데이트 성능 저하: 서비스가 추가되거나 파드가 재시작될 때마다 수천 개의 iptables 규칙 전체를 다시 계산하고 커널에 적용해야 한다. iptables 방식은 증분 업데이트가 아니라 전체 교체 방식이기 때문이며, 이 또한 클러스터 규모가 커질수록 지연이 길어진다.

그럼 eBPF는 뭐고 어떤게 좋냐?

eBPF(extended Berkeley Packet Filter)는 리눅스 커널의 소스 코드를 수정하거나 별도의 커널 모듈을 로드하지 않고도 커널 내에서 안전하게 사용자 정의 프로그램을 실행할 수 있게 하는 기술이다. 커널 이벤트에 훅(Hook)을 걸어 실시간으로 패킷을 처리하거나 데이터를 수집할 수 있다.

eBPF는 이름만 봤을 때 패킷 필터의 역할을 할 것 같지만 세월이 흐르면서 역할이 많이 다양해졌고, 이제 이름은 거의 의미가 없다. eBPF에 대해 더 알고싶다면 이 페이지를 참고하자.

Cilium은 eBPF를 활용하여 쿠버네티스의 네트워킹, 보안, 로드밸런싱을 재정의한다. 기존의 iptables가 Netfilter라는 고정된 프레임워크 안에서만 동작했다면, Cilium은 eBPF를 통해 커널 네트워크 스택의 가장 깊은 곳에서 직접 패킷 경로를 제어한다.

Cilium은 Hash Table 기반으로 $O(1)$의 시간복잡도를 달성하는데, 그 원리를 알아보자.

Cilium이 iptables의 선형 탐색 비효율을 극복하는 핵심은 BPF Maps를 이용한 해시 테이블 룩업 방식이다. 여기서 BPF Maps는 커널 공간에서 실행되는 eBPF 프로그램이 데이터를 저장 또는 공유하기 위해 사용하는 커널 내 키-값 저장소이다.

이러한 방식은 다음 장점을 가진다.

1. 데이터 구조: 리스트 형태의 규칙 대신, Cilium은 서비스의 가상 IP를 키로 하고 목적지 파드의 정보를 값으로 하는 해시 맵을 커널 메모리에 유지한다. 이 형태를 가짐으로써 해시연산 한번에 바로 목적지를 찾을 수 있게 된다.

2. 컨텍스트 스위칭 최소화: eBPF는 커널 공간 내에서 실행되므로, 패킷 처리를 위해 사용자 공간과 커널 공간을 오가는 오버헤드를 최소화하며 데이터 플레인 레벨에서 즉각적인 포워딩을 수행한다.

3. eBPF-based Load Balancing: 서비스로 들어오는 트래픽에 대해 커널 내부에서 eBPF 프로그램이 직접 로드밸런싱을 수행한다. 이는 Netfilter의 복잡한 체인을 거치지 않고 패킷의 헤더를 수정하여 백엔드 파드로 직접 전달하도록 한다.

Hubble이란?

그럼 이제 Cilium 프로젝트의 일부로 개발된 네트워크 가시성 및 보안 분석 도구 Hubble에 대해 알아보자.

마이크로서비스 아키텍처가 복잡해질수록 서비스 간 통신 흐름을 파악하는 것은 매우 어려워지며, 기존에 네트워크 문제를 진단하기 위해 주로 사용되던 방식들은 다음과 같은 단점이 있다.

1. 성능 부하
   tcpdump와 같은 도구는 패킷을 캡처하기 위해 커널 공간에서 사용자 공간으로 대량의 데이터를 복사해야 하며, 트래픽이 몰리는 운영 환경에서 이를 실행하는 것은 시스템 전체의 성능 저하를 유발할 수 있다.

2. 데이터의 파편화
   여러 노드에 흩어져 있는 로그를 수집하여 하나의 흐름으로 재구성하는 과정이 복잡하며, 특정 서비스에서 발생한 패킷 드랍이 네트워크 계층의 문제인지 애플리케이션의 설정 문제인지 즉각적으로 판별하기 어렵다.

하지만 Hubble은 Cilium 위에서 동작하며, eBPF를 활용해 커널 수준에서 네트워크 트래픽과 보안 정책의 흐름을 관찰하기 때문에 다음 장점을 가진다.

1. 데이터를 커널 내에서 직접 수집한다.
   패킷이 커널 네트워크 스택을 통과할 때 eBPF 프로그램을 통해 필요한 메타데이터만 추출하며, 데이터를 사용자 공간으로 복사하는 과정을 최소화하므로 매우 낮은 부하로 실시간 모니터링이 가능해진다.

2. 쿠버네티스 컨텍스트 통합
   단순한 IP 정보가 아닌, 파드 라벨(Labels), 서비스 이름, 네임스페이스 등 쿠버네티스의 객체 정보를 기반으로 트래픽을 식별하며, 이는 트러블 슈팅시 데이터 가독성을 높여준다.

Hubble을 통해 볼 수 있는 가시성 기능

1. 서비스 간 종속성 맵
   서비스들이 서로 어떻게 통신하고 있는지 그래픽으로 시각화해주며 어떤 서비스가 병목의 원인인지, 혹은 예상치 못한 외부 도메인과 통신하고 있지는 않은지 한눈에 확인할 수 있다.

2. 실시간 패킷 드랍 모니터링
   커널 레벨에서 패킷이 왜 드랍되었는지에 대한 구체적인 이유와 함께 실시간 흐름을 제공해주며, 이는 NetworkPolicy 설정 오류를 잡아내는 데 활용 가능하다.

3. L4/L7 계층 분석
   TCP 재전송, 커넥션 타임아웃과 같은 L4 지표뿐만 아니라, HTTP 상태 코드나 gRPC 메서드 호출과 같은 L7 계층까지 수집하여 애플리케이션 성능 관리까지 할수있다.