eBPF 기술을 활용한 Cilium Service Mesh의 아키텍처, 커널 수준 네트워킹의 성능 이점, Hubble 관측 가능성, 그리고 실전 활용법을 분석합니다.
Cilium은 서비스 메시에 대한 근본적으로 다른 접근 방식을 제시합니다. Envoy나 전용 프록시에 의존하는 대신, 리눅스 커널의 eBPF(extended Berkeley Packet Filter) 기술을 활용하여 네트워킹, 보안, 관측 가능성을 커널 수준에서 처리합니다. 2026년 현재 Amazon EKS, Google GKE, Azure AKS의 기본 네트워킹 레이어로 채택되며 사실상의 표준 CNI로 자리 잡았습니다.
eBPF를 이해하지 못하면 Cilium의 아키텍처를 이해할 수 없습니다.
eBPF는 리눅스 커널 내에서 샌드박스된 프로그램을 실행할 수 있게 해주는 기술입니다. 커널을 수정하거나 모듈을 로드하지 않고도 커널의 동작을 확장할 수 있습니다.
전통적 접근 (유저스페이스 프록시):
[App] → [커널 네트워크 스택] → [유저스페이스 프록시] → [커널] → [네트워크]
4번의 컨텍스트 스위칭
eBPF 접근:
[App] → [커널 네트워크 스택 + eBPF 프로그램] → [네트워크]
컨텍스트 스위칭 없음
연결 지점(Hook Points): eBPF 프로그램은 커널의 특정 지점에 연결됩니다. 네트워크 패킷이 도착하거나 나갈 때, 시스템 호출이 발생할 때 등 다양한 이벤트에 반응할 수 있습니다.
검증기(Verifier): eBPF 프로그램은 커널에 로드되기 전에 검증기를 통과해야 합니다. 무한 루프, 범위 밖 메모리 접근, 검증되지 않은 포인터 사용 등이 감지되면 프로그램이 거부됩니다.
맵(Maps): eBPF 프로그램 간 또는 eBPF와 유저스페이스 간 데이터를 공유하는 키-값 저장소입니다. Cilium은 이를 활용하여 서비스 엔드포인트 목록, 네트워크 정책, 연결 추적 테이블 등을 관리합니다.
유저스페이스 프록시 대비 eBPF의 구조적 이점은 명확합니다.
| 비교 항목 | 유저스페이스 프록시 | eBPF |
|---|---|---|
| 컨텍스트 스위칭 | 패킷당 2~4회 | 없음 |
| 메모리 복사 | 커널↔유저스페이스 왕복 | 커널 내 처리 |
| Pod당 오버헤드 | 50~100MB (프록시) | 0 (커널 공유) |
| 시작 지연 | 프록시 부팅 시간 | 없음 |
| TCP 처리 | 프록시가 TCP 종료/재시작 | 커널이 직접 처리 |
벤치마크에 따르면 eBPF 기반 접근은 iptables 기반 대비 40% 낮은 지연 시간과 60% 적은 CPU 사용량을 달성합니다.
Cilium은 CNI(Container Network Interface)와 서비스 메시를 하나의 컴포넌트로 통합합니다.
Cilium 아키텍처
┌─────────────────────────────────────────────────┐
│ Kubernetes 클러스터 │
│ │
│ ┌─────────────────────────────────────────────┐ │
│ │ Cilium Operator (Deployment) │ │
│ │ - CiliumNetworkPolicy 감시 │ │
│ │ - IP 할당 관리 (IPAM) │ │
│ │ - 클러스터 범위 작업 조율 │ │
│ └─────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────── Node ─────────────┐│
│ │ ││
│ │ ┌──────────────────────────────────────────┐││
│ │ │ Cilium Agent (DaemonSet) │││
│ │ │ - eBPF 프로그램 컴파일/로드 │││
│ │ │ - 엔드포인트 관리 │││
│ │ │ - 정책 적용 │││
│ │ └──────────────────────────────────────────┘││
│ │ ││
│ │ ┌──────────────┐ ┌──────────────────────┐ ││
│ │ │ Linux Kernel │ │ Envoy (L7 전용) │ ││
│ │ │ ┌──────────┐ │ │ 필요 시에만 사용 │ ││
│ │ │ │eBPF 프로그│ │ └──────────────────────┘ ││
│ │ │ │램 (L3/L4) │ │ ││
│ │ │ └──────────┘ │ ││
│ │ └──────────────┘ ││
│ │ ││
│ │ [Pod A] [Pod B] [Pod C] ... ││
│ └───────────────────────────────────────────────┘│
└─────────────────────────────────────────────────┘
각 노드에 DaemonSet으로 배포되는 핵심 컴포넌트입니다.
Cilium의 데이터 경로는 계층별로 다른 처리 방식을 사용합니다.
L3/L4 (eBPF): IP 라우팅, TCP/UDP 로드 밸런싱, 네트워크 정책, 암호화가 커널 내 eBPF 프로그램으로 처리됩니다. 프록시 없이 직접 패킷을 조작합니다.
L7 (Envoy): HTTP 라우팅, 헤더 기반 정책, gRPC 로드 밸런싱 등 프로토콜 파싱이 필요한 기능은 노드당 공유 Envoy 프록시로 위임합니다.
L3/L4 트래픽 경로 (eBPF만):
[Pod A] → [TC eBPF] → [커널 라우팅] → [TC eBPF] → [Pod B]
L7 트래픽 경로 (Envoy 경유):
[Pod A] → [TC eBPF] → [Envoy] → [TC eBPF] → [Pod B]
Cilium은 kube-proxy를 완전히 대체할 수 있습니다. Kubernetes Service의 ClusterIP, NodePort, LoadBalancer를 eBPF로 처리합니다.
# kube-proxy 없이 Cilium 설치
helm install cilium cilium/cilium \
--namespace kube-system \
--set kubeProxy.enabled=false \
--set k8sServiceHost=<API_SERVER_IP> \
--set k8sServicePort=6443kube-proxy가 iptables 규칙으로 처리하던 서비스 로드 밸런싱을 eBPF가 대신합니다. 서비스 수가 많아질수록 iptables의 O(n) 규칙 탐색 대비 eBPF 맵의 O(1) 룩업이 성능 차이를 만듭니다.
Cilium은 Kubernetes 표준 NetworkPolicy를 지원하면서도, 더 강력한 CiliumNetworkPolicy를 제공합니다.
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: allow-frontend-to-backend
spec:
endpointSelector:
matchLabels:
app: backend
ingress:
- fromEndpoints:
- matchLabels:
app: frontend
toPorts:
- ports:
- port: "8080"
protocol: TCPHTTP 메서드와 경로 수준의 세밀한 정책도 가능합니다.
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: api-access-control
spec:
endpointSelector:
matchLabels:
app: backend
ingress:
- fromEndpoints:
- matchLabels:
app: frontend
toPorts:
- ports:
- port: "8080"
protocol: TCP
rules:
http:
- method: GET
path: "/api/v1/products"
- method: POST
path: "/api/v1/orders"Cilium은 두 가지 투명 암호화 방식을 제공합니다.
노드 간 모든 트래픽을 WireGuard 터널로 암호화합니다. IPsec보다 성능이 뛰어나고 설정이 간단합니다.
# WireGuard 암호화 활성화
helm upgrade cilium cilium/cilium \
--set encryption.enabled=true \
--set encryption.type=wireguardCilium 1.19부터 Istio의 ztunnel을 채택하여 Pod 수준의 mTLS 암호화를 지원합니다. WireGuard가 노드 간 암호화라면, ztunnel은 Pod 간 인증과 암호화를 제공합니다.
# ztunnel mTLS 활성화
helm upgrade cilium cilium/cilium \
--set authentication.mutual.spiffe.enabled=true \
--set encryption.type=ztunnelztunnel은 원래 Istio Ambient Mesh를 위해 개발되었지만, Cilium이 이를 채택하면서 두 프로젝트가 공통 컴포넌트를 공유하게 되었습니다. 이는 서비스 메시 생태계의 수렴을 보여주는 흥미로운 사례입니다.
Hubble은 Cilium에 내장된 관측 가능성 플랫폼입니다. eBPF를 통해 커널에서 직접 네트워크 이벤트를 수집하므로, 프록시 없이도 깊은 수준의 가시성을 제공합니다.
서비스 맵: 서비스 간 통신 흐름을 시각화합니다. 어떤 서비스가 어떤 서비스를 호출하는지, 프로토콜은 무엇인지, 성공률은 어떤지를 실시간으로 보여줍니다.
플로우 로그: 모든 네트워크 흐름(flow)을 기록합니다. 소스/목적지 Pod, 포트, 프로토콜, 정책 판정(허용/거부) 등의 상세 정보를 포함합니다.
메트릭 내보내기: Prometheus 호환 메트릭을 자동 생성합니다. Grafana 대시보드와 연동하여 네트워크 성능을 모니터링할 수 있습니다.
# Hubble 활성화
helm upgrade cilium cilium/cilium \
--set hubble.enabled=true \
--set hubble.relay.enabled=true \
--set hubble.ui.enabled=true
# 실시간 플로우 관찰
hubble observe --namespace my-app
# 특정 서비스의 트래픽 필터링
hubble observe --to-label app=reviews --protocol http웹 기반 인터페이스에서 서비스 디펜던시 그래프를 시각적으로 확인할 수 있습니다. 각 엣지에 요청 수, 에러율, 지연 시간이 표시됩니다.
| 비교 항목 | Cilium | Istio | Linkerd |
|---|---|---|---|
| 데이터 플레인 | eBPF + 공유 Envoy | ztunnel + Waypoint | linkerd2-proxy 사이드카 |
| L3/L4 성능 | 최고 (커널 직접) | 좋음 (ztunnel) | 좋음 (Rust 사이드카) |
| L7 기능 | Envoy 위임 (제한적) | 풀 Envoy 기능 | 기본 HTTP만 |
| CNI 통합 | 자체 CNI 포함 | 별도 CNI 필요 | 별도 CNI 필요 |
| 관측 가능성 | Hubble (커널 수준) | Kiali, Prometheus | Linkerd Viz |
| 암호화 | WireGuard + ztunnel | mTLS (ztunnel) | mTLS (자동) |
| 라이선스 | Apache 2.0 | Apache 2.0 | Apache 2.0 (제한적) |
반면, 풍부한 L7 트래픽 관리(세밀한 HTTP 라우팅, 폴트 인젝션, 트래픽 미러링)가 핵심 요구사항이라면 Istio가 더 적합합니다.
다음 장에서는 서비스 메시의 보안 기반인 mTLS와 제로 트러스트 네트워킹을 깊이 있게 다루겠습니다.
이 글이 도움이 되셨나요?
서비스 메시의 보안 기반인 mTLS의 작동 원리, SPIFFE 워크로드 아이덴티티, 인증서 관리, 그리고 제로 트러스트 아키텍처 구현 전략을 다룹니다.
Linkerd의 설계 철학, Rust 기반 마이크로 프록시 아키텍처, 설치와 운영, 그리고 Istio와의 비교를 통해 Linkerd의 강점을 분석합니다.
서비스 메시가 제공하는 관측 가능성의 세 기둥을 분석합니다. 분산 추적, 골든 시그널 메트릭, 액세스 로그, 그리고 Kiali/Grafana 연동까지.