K8s Networking - 12. cilium-service-mesh

사이드카 없는 메시가 가능한 이유 — Cilium이 eBPF로 지운 계층

한 클러스터에 Pod가 3000개였다. Istio 사이드카를 넣으려 하니 — Envoy 인스턴스 3000개, 자원 오버헤드가 어마어마했다. 메모리만 수십 기가. 팀은 물었다: "Pod마다 프록시를 넣지 않고 메시를 할 수 없나?" Cilium Service Mesh가 그 질문에 답한다 — eBPF가 커널 단에서 메시 기능을 처리해 사이드카를 없앤다.

이 글이 푸는 것은: 왜 사이드카 없는 메시가 가능한가, Cilium이 eBPF로 사이드카의 어떤 역할을 흡수하는가, 그리고 Istio/Linkerd와 어떻게 다른가다.

사이드카 메시의 비용 — 왜 "없애고" 싶은가

10장에서 사이드카 메시(Istio 등)의 비용을 봤다:

• Pod마다 Envoy 컨테이너 추가 → CPU/메모리가 Pod 수에 비례.
• 트래픽이 사이드카를 두 번 거치는 지연.
• Pod 재생성 없이는 메시 적용/해제가 어려움.

Pod 수가 많아지면 이 비용이 선형으로 커진다. 3000개 Pod면 3000개 Envoy. 도입의 팀이 부딪힌 벽이 바로 이것. 그래서 "이 계층을 없앨 수 없나"가 자연스러운 질문이 된다.

Cilium의 답 — eBPF가 커널 단에서 처리한다

사이드카(Envoy)가 하던 일 — 트래픽 가로채기, mTLS, 라우팅, 메트릭 — 을 eBPF가 커널 안에서 직접 처리한다. Pod에 추가 컨테이너 없이. (Cilium docs - Service Mesh)

flowchart LR
    APP1["Pod1<br/>(사이드카 없음)"] -->|"패킷"| KERNEL1["노드 커널<br/>eBPF가 처리"]
    KERNEL1 -. mTLS/라우팅 .-> KERNEL2["노드2 커널"]
    KERNEL2 --> APP2["Pod2<br/>(사이드카 없음)"]

왜 가능한가? eBPF는 커널의 패킷 처리 경로 자체에 후크를 걸 수 있다. 그래서 패킷이 Pod를 떠나기 전/후에 커널 단에서 mTLS 암호화, 라우팅 규칙, 메트릭 수집을 끼워 넣을 수 있다. 별도 프로세스(사이드카)를 거칠 필요가 없다.

핵심 통찰: 사이드카 메시는 사용자 공간 프록시로 트래픽을 우회시켜 처리. Cilium은 커널 공간에서 같은 처리를 한다. 커널이 이미 지나가는 길에 후크를 거니까 추가 경로(사이드카)가 필요 없다.

Cilium 메시의 이점

• 사이드카 없음: Pod에 컨테이너 추가 없음. 자원 오버헤드 크게 감소.
• Pod 재생성 없이 적용: 메시 기능을 켜도/꺼도 Pod를 다시 띄울 필요 없음(eBPF 프로그램만 교체).
• Cilium 데이터플레인 일관성: 이미 Cilium을 CNI로 쓰면, 추가 컴포넌트로 통합.

L4/L7 분리 — 사이드카를 완전히 없앨 수 없는 지점

완전히 사이드카가 없는 건 아니다. Cilium은 트래픽을 두 층으로 나눠 처리:

층	담당	위치	예시
L4 (전송)	eBPF (커널)	노드 커널 — Pod 컨테이너 없음	mTLS 암호화, L4 연결 라우팅, TCP 메트릭
L7 (응용)	Envoy (선택)	노드당 1개 Envoy DaemonSet	HTTP 경로 라우팅, 헤더 조작, HTTP 메트릭

flowchart TD
    P1["Pod1 요청"] -->|"L4만 필요"| EBPF["eBPF (커널)<br/>mTLS + 라우팅"]
    EBPF --> P2["Pod2"]
    P1 -->|"L7 정책 필요(헤더/경로)"| ND["노드 Envoy DaemonSet"]
    ND --> EBPF2["eBPF로 최종 전송"]
    EBPF2 --> P2

이 분리의 핵심 통찰: 대부분의 메시 트래픽은 L4면 충분하다. mTLS·기본 라우팅·TCP 메트릭은 L4 수준에서 처리 가능. Istio는 모든 Pod에 Envoy 사이드카를 두지만, Cilium은 L4는 eBPF(사이드카 없음), L7만 노드 Envoy 1개. 노드가 Pod보다 훨씬 적으니 자원 절약이다.

Pod 1000개에서:

• Istio: Envoy 인스턴스 1000개(Pod마다 1개).
• Cilium: 노드당 Envoy 1개(노드 50개면 50개) + eBPF(컨테이너 없음). Envoy 수가 1/20.

L7 정책이 필요한 정확한 순간 — 노드 Envoy를 켜야 할 때

L7 Envoy 없이 eBPF만으로는 안 되는 것들 — 이때만 노드 Envoy를 활성화:

• HTTP 경로 라우팅: "/api/*는 v2로" — L4(TCP)는 경로를 못 본다.
• HTTP 헤더 기반 카나리: "X-Canary: true 헤더만 v2로" — L4는 헤더를 못 본다.
• HTTP 메트릭(응답 코드별): "5xx 비율 추적" — L4는 응답 코드를 모른다.
• gRPC 메서드 라우팅: "/package.Service/Method별로" — gRPC도 HTTP/2 위라 L7.

이런 L7 정보*가 필요한 서비스에만 노드 Envoy를 거친다. 나머지는 eBPF L4로 충분 — mTLS, TCP 메트릭, 기본 로드밸런싱. "전부 L7로"가 아니라 *필요한 곳만 — 이것이 Cilium 메시의 자원 효율 전략.

Cilium identity와 메시 정책의 결합

05장에서 Cilium의 identity 기반 정책을 언급했다. 메시에서 이것이 진가를 발휘한다:

• 사이드카 메시(Istio)는 서비스 신원(SPIFFE ID)으로 정책을 평가 — mTLS 인증서에서 신원 추출(사용자 공간에서).
• Cilium은 eBPF가 패킷에 Cilium identity를 직접 태그 — 커널 단에서 "이 패킷은 identity=42(web 서비스)에서 왔다"를 해시 조회로 평가.

차이: Istio는 사용자 공간에서 신원 추출, Cilium은 커널 단에서 identity 직접 조회. 성능·안정성 면에서 Cilium이 더 근접(커널 안). 단 표현력(Istio VirtualService의 풍부한 L7 규칙)은 Istio가 여전히 앞선다 — "성능 vs 표현력"의 trade-off.

Linkerd/Istio/Cilium 메시 비교 — 세 방향

	Cilium 메시	Linkerd	Istio
L4	eBPF(사이드카 없음)	경량 사이드카	Envoy 사이드카
L7	노드 Envoy(선택)	경량 사이드카	Envoy 사이드카
자원	가장 적음	적음	많음
복잡성	중(eBPF 숙련)	낮음	높음

Linkerd도 "경량 메시"를 표방하지만 사이드카 모델을 유지한다 — 단 Envoy 대신 자체 경량 Rust 프록시(Linkerd2-proxy). 사이드카는 있지만 Istio보다 가볍다. (Linkerd docs)

세 방향의 trade-off:

• Istio: 풍부한 L7 + 성숙 + 검증. 단 복잡·사이드카 자원.
• Linkerd: 단순·경량·빠른 도입. 단 사이드카 있음, 기능은 Istio보다 적음.
• Cilium: 사이드카리스 + Hubble 시너지. 단 eBPF 숙련도·최신 커널 필요.

waypoint의 위치 — Cilium 노드 Envoy vs Istio Ambient waypoint

11장에서 Istio Ambient의 waypoint가 namespace당 1개라고 했다. Cilium의 L7 Envoy는 노드당 1개(DaemonSet). 위치가 다르다:

• Cilium 노드 Envoy: 모든 노드에. L7 트래픽이 그 노드의 Envoy를 경유. 트래픽이 자연스럽게 분산.
• Istio waypoint: namespace에 1개. 그 namespace의 L7 트래픽이 한 곳을 경유. 집중형.

두 접근의 trade-off: 분산(Cilium, 자원 분산) vs 집중(Istio waypoint, 한 곳 관리). 둘 다 "사이드카리스 L7"을 추구하되 경로가 다르다.

Gateway API와의 통합

Cilium은 CNI + Service Mesh + Gateway API 구현체를 모두 갖춘다. eBPF 데이터플레인 하나가 세 역할을 — 03장 CNI, 09장 Gateway, 10~12장 메시 — 일관되게 처리. 이것이 "Cilium이 단순 CNI가 아니다"의 세 번째 근거다.

실무 도입 의사결정 — 세 메시 중 어느 것

요구	추천	이유
풍부한 L7 + 성숙 + 검증	Istio	VirtualService/DestinationRule 생태계
단순함 + 경량 + 빠른 도입	Linkerd	Rust 경량 프록시, 낮은 복잡성
이미 Cilium CNI + 대규모 자원 절약	Cilium 메시	eBPF 사이드카리스, Hubble 시너지
사이드카리스이되 Istio 생태	Istio Ambient	ztunnel(L4) + waypoint(L7), 11장

선택은 "기존 스택(Istio/Cilium 쓰는가) + 요구(L7 풍부 vs 자원 절약) + 숙련도"로. 정답이 하나가 아니다.

직접 확인하기 (Cilium 클러스터 필요)

# Cilium Service Mesh 활성화 (L7 관측 등)
cilium install --set kubeProxyReplacement=true
cilium hubble enable --ui
cilium status

정확한 설치 파라미터/버전은 Cilium docs에서 실측.

# 사이드카 없이 mTLS/메시 관측 (L4)
cilium hubble observe --type drop    # 드롭된 패킷(정책)

확인할 것: Pod에 추가 컨테이너 없이(사이드카 없음) Hubble이 트래픽 플로우를 관측.

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"Cilium 메시는 사이드카가 아예 없다"	L4는 없음. L7은 노드 단 Envoy(선택)
"사이드카 없으면 mTLS가 안 된다"	eBPF가 커널 단에서 mTLS 처리. 가능
"Cilium 메시는 Istio의 단순 복제다"	접근이 다름(eBPF vs 사이드카). 복제 아님
"eBPF 메시는 어떤 커널이나 된다"	최신 커널 필요. 구형 환경 제약
"사이드카 메시보다 항상 낫다"	규모·환경 따라. 소규모·검증 우선이면 Istio/Linkerd
"Cilium은 CNI만 한다"	CNI+메시+Gateway API 통합

요약 — 이 글의 결론

• Cilium Service Mesh가 eBPF로 사이드카를 없앤다 — 커널 단에서 L4(mTLS 등) 처리. Pod에 추가 컨테이너 없음.
• 왜 가능: eBPF가 커널 패킷 처리 경로에 후크. 사이드카(사용자 공간 프록시)로 우회할 필요 없이 커널 안에서 처리.
• L4/L7 분리: L4는 eBPF(사이드카 없음), L7(HTTP 경로/헤더)은 노드 Envoy(선택). 대부분의 메시 트래픽은 L4면 충분 — 필요한 곳만 L7.
• 자원 차이의 근원: Istio는 Pod마다 Envoy(N개), Cilium은 노드마다 Envoy 1개 + eBPF. 노드가 Pod보다 적으니 Envoy 수가 1/N로 줄어듦.
• Cilium identity가 커널 단에서 정책 평가 — Istio(사용자 공간 신원 추출)보다 근접. 단 L7 표현력은 Istio가 앞섬.
• Linkerd vs Istio vs Cilium: 경량 사이드카(Linkerd) / 풍부 사이드카(Istio) / 사이드카리스 eBPF(Cilium). 규모·숙련도·기존 스택으로 선택.
• Cilium = CNI + 메시 + Gateway API 통합 — eBPF 데이터플레인 하나가 세 역할. 05장에서 시작된 "Cilium은 단순 CNI가 아니다"의 귀결.

생각해 볼 문제

1. 사이드카 없이 mTLS가 되는 기술적 이유를 "커널 경로 후크"로 설명하라.
2. L7 정책이 필요해졌다. Cilium 메시에서 무엇을 추가로 켜야 하나? 자원은?
3. Pod 5000개 클러스터에서 Istio 사이드카 vs Cilium 메시 자원 차이를 정량화해 보라.
4. Cilium 메시가 구형 커널(3.x)에서 안 되는 이유는? eBPF 기능 의존성.
5. Cilium이 CNI+메시+Gateway를 하나로 통합하는 것이 장점인 이유와, 단점(vendor lock-in?)을 각각.
6. 사이드카 없는 메시에서 "특정 Pod만 정책 예외"를 어떻게 구현하나? (eBPF identity 관점)

---

참고

• Cilium docs - Service Mesh - 접근 2026-07-13
• Cilium docs - L7 정책과 노드 Envoy - 접근 2026-07-13
• Cilium docs - mTLS (sidecarless) - 접근 2026-07-13
• Linkerd docs - 접근 2026-07-13 (경량 사이드카 비교)
• Istio Ambient mesh - 접근 2026-07-13
• eBPF와 사이드카 비교 - Isovalent/Cilium 블로그 - 접근 2026-07-13