Cilium Service Mesh 정리 - eBPF 기반 사이드카 없는 쿠버네티스 네트워킹

KubeCon EU 2026에서 발표된 Cilium 1.19의 사이드카 없는 네이티브 mTLS가 화제가 되면서, 서비스 메시의 기본값으로 떠오른 eBPF 기반 Cilium Service Mesh의 개념, 동작 원리, mTLS 처리 방식, 설치, 관측성 도구까지 정리합니다.

Cilium이란

Cilium은 리눅스 커널의 eBPF(extended Berkeley Packet Filter) 기술을 활용해 네트워킹·보안·관측성을 처리하는 오픈소스 프로젝트로, 2023년 CNCF를 졸업했습니다. 원래는 쿠버네티스 CNI(컨테이너 네트워크 인터페이스) 플러그인으로 출발했지만, 최근에는 사이드카 프록시 없이 동작하는 서비스 메시로도 널리 쓰이고 있습니다. 참고로 Cilium은 쿠버네티스에서 Ingress를 대체하는 표준 트래픽 라우팅 API인 Gateway API의 구현체 중 하나(NGINX, Istio 등과 함께)이기도 한데, 이 글에서는 Gateway API 구현체가 아니라 사이드카 없는 서비스 메시로서의 Cilium에 초점을 맞춥니다.

왜 주목받는가 - 사이드카 기반과의 차이

Istio 같은 전통적인 서비스 메시는 파드마다 Envoy 사이드카 컨테이너를 주입해 트래픽을 가로챕니다. 파드 수가 많아질수록 사이드카 개수도 비례해서 늘어나고, 각 사이드카가 50~100MB의 메모리를 점유하면서 리소스 오버헤드와 네트워크 홉(하나 더 거치는 구간)이 늘어나는 구조적 문제가 있습니다. Cilium은 L3/L4 계층 처리를 커널 안의 eBPF 프로그램이 직접 수행해 프록시 자체를 없애고, 꼭 필요한 L7(HTTP 등) 처리만 노드당 하나의 공유 Envoy로 위임합니다.

구분	Istio (사이드카 방식)	Cilium Service Mesh
프록시 배치	파드마다 주입 (N개)	노드당 1개 공유 (L7만)
L3/L4 처리	Envoy 사이드카	eBPF (커널)
리소스 사용량	파드 수에 비례해 증가	노드 수 기준으로 고정적
지연 시간	사이드카 경유로 홉 증가	커널 내 처리로 최소화
측정치(사례)	기준	지연 40%↓ · CPU 60%↓

mTLS는 어떻게 처리하나 - SPIFFE·ztunnel·HBONE

2026년 3월 Cilium은 사이드카 없이 동작하는 네이티브 mTLS를 발표했습니다. 핵심은 세 가지 조합입니다.

• SPIFFE/SPIRE 신원: 각 워크로드에 spiffe://<trust-domain>/ns/<namespace>/sa/<service-account> 형태의 신원을 부여하고 인증서에 담아 양쪽에서 검증합니다. Cilium의 보안 아이덴티티를 기반으로 애플리케이션 코드 변경 없이 SPIRE에 자동 등록됩니다.
• ztunnel + HBONE 터널: mTLS 터널이 완전히 수립될 때까지 연결을 인라인으로 붙잡아둬서, 평문(암호화 안 된) 구간이나 첫 패킷 드롭 없이 HTTP/2 CONNECT 기반 HBONE 터널로 양방향 트래픽을 흘려보냅니다.
• WireGuard/IPsec 투명 암호화: TCP·mTLS는 ztunnel이 담당하고, TCP가 아닌 트래픽이나 무중단 업그레이드 구간은 기존 WireGuard/IPsec 투명 암호화가 보완합니다.

즉 애플리케이션이나 사이드카를 건드리지 않고도, 클러스터 내부 트래픽 전체에 상호 인증 및 암호화를 적용할 수 있게 된 것이 이번 발표의 핵심입니다.

관측성 - Hubble

Cilium은 Hubble이라는 관측성 도구를 함께 제공합니다. eBPF가 커널에서 모든 트래픽을 이미 들여다보고 있기 때문에, 별도 에이전트 없이도 L3/L4는 물론 L7(HTTP 메서드, 경로 등)까지 실시간으로 확인할 수 있습니다.

# 네임스페이스 default의 L7 트래픽 실시간 관측
hubble observe --namespace default -t l7

설치

# Cilium CLI 설치 후 클러스터에 배포
cilium install 1.20.2

# 설치 상태 확인
cilium status --wait

# 클러스터 연결성 테스트
cilium connectivity test

쿠버네티스가 CNI를 사용하도록 구성돼 있어야 하며, 리눅스 커널 5.10 이상이 필요합니다. GKE/AKS/EKS 등 클라우드별로 노드 taint나 네트워크 플러그인 옵션이 조금씩 다르므로 설치 전 공식 문서의 클러스터별 사전조건을 확인하는 것이 좋습니다.

CiliumNetworkPolicy 예시

L7 HTTP 경로 단위로 세밀하게 트래픽을 제어하는 예시입니다.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-read-only
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api/.*"

frontend 파드에서 backend 파드로 가는 트래픽 중, GET 메서드로 /api/ 경로에 접근하는 요청만 허용하는 정책입니다.

참고사항

• Cilium 공식 문서 - Service Mesh
• Cilium 블로그 - Native mTLS for Cilium
• Cilium 공식 문서 - Kubernetes 설치 가이드
• cilium/cilium GitHub