사이드카를 걷어낸 뒤 마주한 것들 — Cilium Service Mesh에서 mTLS와 L7 정책의 부하는 어디로 옮겨가는가

Cilium Service Mesh를 검토하기 시작했을 때 가장 먼저 확인하고 싶었던 건 "그래서 Envoy가 진짜 사라지는가"였습니다. 결론부터 정리하면, 파드마다 붙던 사이드카는 사라지지만 Envoy 자체는 노드당 하나로 남고, mTLS 데이터 평면은 여전히 IPsec/WireGuard가 담당합니다. "제로 프록시"라기보다는 프록시가 파드 → 노드 레벨로 이동한 아키텍처로 이해하는 편이 실제 동작과 가깝습니다.

이 글은 Istio 사이드카 모델로 몇백 개 규모의 서비스를 운영한 경험을 바탕으로, Cilium Service Mesh로 옮겼을 때 무엇이 어디로 움직이는지를 짚어보는 데 목적이 있습니다. 특히 L7 정책 밀도가 노드 Envoy 부하로 어떻게 전이되는지, mTLS는 어느 레이어에서 처리되는지, 커널·정책 조합에서 자주 놓치는 지점은 무엇인지를 중심으로 이야기하려 합니다.

2026년 8월 현재 Cilium은 1.1x 계열이 안정 트랙에서 릴리스되고 있고(정확한 릴리스 태그는 GitHub Releases에서 확인), Mutual Authentication은 공식 문서 기준 여전히 Beta입니다. Istio Ambient 진영의 ztunnel 컴포넌트를 Cilium이 수용할지에 대해서는 Issue #38548에서 지원 요청·논의 단계에 머물러 있으므로, 이 글에서도 "채택"이 아니라 "실험·논의"로 표기했습니다.

먼저 확인해두고 시작할 사실들

초안을 다시 검토하는 과정에서 흔히 잘못 인용되는 지점을 정리해뒀습니다. 아래는 이 글 전체의 전제입니다.

• Cilium의 mTLS 데이터 평면 암호화는 IPsec 또는 WireGuard가 담당하고, Mutual Authentication은 SPIFFE/SPIRE 기반의 아이덴티티 검증을 out-of-band로 수행합니다(공식 문서). "TLS 1.3을 파드-투-파드로 인라인 종단한다"는 서술은 Cilium이 정식으로 채택한 표준이 아니라, Ambient/ztunnel 계열의 접근입니다.
• ztunnel은 Istio Ambient의 컴포넌트이며, Cilium 코어에 편입된 상태가 아닙니다. 관련 논의는 Issue #38548에서 이어지고 있고, "실험적 통합" 정도로 읽는 편이 안전합니다.
• 최소 커널 요구사항은 기능별로 다릅니다. Cilium 자체는 4.19+를 요구하고, XDP·BPF LSM·특정 세션 어피니티 등은 5.x~6.x가 요구됩니다(System Requirements). "mTLS 상호 인증은 커널 5.4+"라는 단순화는 근거가 없어 이 글에서는 쓰지 않습니다.

L7 정책과 mTLS가 실제로 어디에서 처리되는가

정책 유형별로 처리 경로가 갈립니다

Cilium은 세 가지 레이어를 분리해서 다룹니다.

• L3/L4 정책과 로드밸런싱: eBPF 프로그램이 커널에서 처리
• L7 정책(HTTP/gRPC/Kafka): 커널이 노드당 임베디드 Envoy로 리디렉트
• 암호화·아이덴티티: 전송 암호화는 IPsec/WireGuard, 아이덴티티 검증은 SPIFFE SVID

이 분기가 중요한 이유는, L7 정책이 붙은 서비스가 몰린 노드일수록 Envoy 리소스 소비가 커지고, 반대로 L4 지배적 트래픽이라면 Envoy 경로 자체가 존재하지 않기 때문입니다. 즉 "Cilium이 빠르다/느리다"는 판단은 클러스터의 L7 정책 밀도에 종속됩니다.

워크로드 아이덴티티는 SPIFFE로 이어집니다

Cilium은 spiffe://<trust-domain>/ns/<namespace>/sa/<service-account> 형식의 SVID를 자체 Security Identity에 매핑합니다. ServiceAccount를 아이덴티티의 뿌리로 삼기 때문에 기존 RBAC 모델과 자연스럽게 이어지고, 애플리케이션 코드 수정 없이 SPIRE 서버가 발급을 담당합니다(Mutual Authentication 문서).

여기서 다시 강조해두자면, 이 Mutual Authentication은 Beta 상태입니다. 프로덕션 SLA가 걸린 서비스라면 이 부분만은 신중하게 검증해야 합니다.

L7 정책·mTLS·Gateway API를 실제로 얹어보기

HTTP 메서드·경로 필터링

frontend가 backend의 GET /api/v1/...만 호출할 수 있게 제한하는 예시입니다. Cilium HTTP 규칙의 path는 정규식으로 평가되므로, 아래는 /api/v1/ 이하 모든 경로를 허용합니다(HTTP 필터링 참고).

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

이 정책이 적용되는 순간, 대상 트래픽은 eBPF 프로그램이 노드 Envoy로 리디렉트합니다. L3/L4 정책만 있는 경우엔 Envoy를 거치지 않고 커널에서 종료됩니다. 정책 문법 한 줄이 데이터 평면 홉 수를 바꾸는 구조라는 점이 사이드카 모델과 결정적으로 다른 지점입니다.

mTLS를 요구하는 정책

Mutual Authentication은 CNP의 ingress rule 하위에 authentication 블록을 붙여 켭니다. 스키마의 정확한 배치는 사용 중인 Cilium 버전의 CRD를 기준으로 확인하는 것이 안전합니다(상세 예시는 공식 문서 참고).

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: backend-mtls-required
  namespace: shop
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      authentication:
        mode: "required"
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP

authentication.mode: required가 붙으면 Cilium 에이전트가 SPIRE에서 발급받은 SVID로 out-of-band 핸드셰이크를 수행한 뒤에야 페이로드가 흐릅니다. 트래픽 자체의 암호화는 별도로 활성화된 IPsec/WireGuard 계층이 담당한다는 점을 기억해두면 좋습니다.

L7 정책이 걸린 트래픽의 개념적 흐름

아래 시퀀스는 "L7 정책과 Mutual Authentication이 동시에 걸린 요청이 개념적으로 어떤 순서를 거치는지"를 단순화한 그림입니다. 실제 구현에서는 CiliumEnvoyConfig 재지향 순서와 정책 조합에 따라 세부 단계가 달라질 수 있습니다.

Gateway API를 인그레스 컨트롤러로

별도 Ingress NGINX 없이 Gateway API를 그대로 사용할 수 있는 것도 최근 도입이 늘어난 배경 중 하나입니다. 아래 예시에서 parentRefs의 게이트웨이가 다른 네임스페이스에 있다면 namespace 필드를 명시해야 합니다.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop-route
  namespace: shop
spec:
  parentRefs:
    - name: cilium-gateway
      # 게이트웨이가 다른 네임스페이스라면 아래 필드 추가
      # namespace: infra
  hostnames:
    - "shop.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: backend
          port: 8080

Cilium은 이 라우팅을 CiliumEnvoyConfig로 노드 Envoy에 반영합니다. 별도 Envoy Gateway를 얹지 않고도 L7 게이트웨이가 성립하는 구조입니다.

레이턴시·메모리가 달라지는 지점을 다시 읽기

숫자를 인용하기 전에 조건을 먼저 봅니다

서비스 메시 벤치마크는 워크로드·RPS·페이로드·튜닝 여부에 따라 결과가 크게 흔들립니다. 특정 수치를 옮겨 적기보다는 원문의 측정 조건을 함께 확인하는 편이 낫습니다.

즉 표에서 "Cilium이 빠르다"는 결론을 뽑기 전에, 본인 클러스터의 L7 정책 비율·평균 페이로드·gRPC 스트리밍 유무를 먼저 파악해야 합니다. 사이드카 모델의 오버헤드가 파드 수에 선형이라면, Cilium 모드의 오버헤드는 "정책 밀도 × 노드당 트래픽 집중도"에 가까운 곡선을 그립니다.

L7 정책이 몰릴 때 노드 Envoy가 겪는 것

가장 조심해야 할 지점입니다. L7 정책이 특정 노드에 집중되면, 사이드카 시절에는 파드마다 분산되던 부하가 노드 Envoy 한 프로세스로 응축됩니다. 다음 항목은 도입 전 캡슐레벨에서 반드시 그려봐야 하는 곡선입니다.

• 정책 개수 × 활성 커넥션 수에 따른 Envoy RSS/CPU
• HTTP 필터 체인 길이에 따른 P99 지연
• 노드 재시작 시 Envoy 콜드 스타트로 인한 커넥션 재수립

이 곡선을 미리 그려보지 않으면, 사이드카 모델에서 잘 안 보이던 노드 단위 핫스팟이 프로덕션에서 뒤늦게 관측됩니다.

도입을 재검토하게 만드는 실무 이슈

커널 요구사항을 먼저 확인해야 합니다. Cilium은 4.19+를 최소로 요구하지만, XDP 가속·BPF LSM·특정 세션 어피니티 기능은 5.x 이후를 전제합니다(System Requirements). 온프렘에서 오래된 노드 이미지를 쓰고 있다면 도입 결정 이전에 커널 정책부터 정리해야 합니다.

"완전한 사이드카리스"라는 표현은 구현 세부와 결이 다릅니다. L7 처리와 TLS 종단은 커널만으로 완결되지 않고, 노드 Envoy라는 사용자 공간 컴포넌트가 남아 있습니다. 파드에서 사라진 프록시가 노드 레벨로 이동한 것이므로, L7 정책·TLS 종단이 몰리는 노드에서는 CPU 스파이크와 eBPF 맵 크기 관리가 새 숙제로 넘어옵니다.

디버깅 도구 스택이 바뀝니다. tcpdump·iptables만 붙잡고 있으면 eBPF 레벨에서 드롭된 패킷의 원인을 좇기 어렵습니다. 대체로 Hubble과 Tetragon 조합이 사실상 필수로 따라오고, 조직 규모에 따라 상용 옵저버빌리티 스택까지 검토하게 됩니다.

CVE·어드바이저리는 반드시 릴리스 노트에서 재확인하세요. eBPF 데이터 평면은 정책 표현식과 별개로 데이터 평면 설정 조합에 따라 정책 강제성이 달라질 수 있는 지점이 있습니다. 특정 어드바이저리 ID를 인용하기 전에 Cilium Security Advisories 페이지에서 영향 버전 범위·CVSS·완화 방법을 직접 확인하는 절차를 습관화해두는 편이 좋습니다.

언제 사이드카 모델을 유지하는 편이 나은가

의사결정은 커널 요건이 선행 조건입니다. 그 다음이 L7 정책 밀도, 그 다음이 노드 밀도 순서입니다.

정리하면, 파드가 많고 L4 트래픽이 지배적인 환경일수록 eBPF 모드의 이득이 크고, 반대로 L7 정책이 특정 노드에 집중되는 워크로드일수록 노드 Envoy가 새 병목이 될 수 있다는 결이 반복해서 관측됩니다.

마무리

이 글에서 유일하게 강하게 주장하고 싶은 지점은 하나입니다. 서비스 메시의 부하는 없어지지 않고 옮겨간다. 사이드카를 걷어냈다는 표현은 "파드에서 사라졌다"는 뜻이지, 클러스터 전체에서 사라졌다는 뜻이 아닙니다. 도입 결정의 초점을 "Envoy를 없앤다"에서 "L7 처리와 TLS 종단을 어느 레이어로 옮기고, 그 레이어의 용량을 어떻게 산정할 것인가"로 옮기는 것만으로도 사후 사고의 절반은 예방됩니다.

500 서비스 규모에서 L7 정책 비중이 낮고 L4가 지배적이었던 환경 기준으로, 필자는 다음 클러스터에서도 Cilium 모드를 우선 검토할 것 같습니다. 다만 워크로드 특성이 다르다면 결론도 달라져야 합니다. 판단의 순서는 커널 요건 → L7 정책 밀도 → 노드 집중도 → 관측/디버깅 스택 준비도의 4단계로 밟는 것을 권합니다.

참고 자료

• Cilium Releases (GitHub)
• Mutual Authentication (Beta) — Cilium Docs, stable
• Gateway API Support — Cilium Docs, stable
• System Requirements — Cilium Docs, stable
• HTTP Policy Language — Cilium Docs, stable
• Cilium Security Advisories (GitHub)
• Add support for ztunnel · Issue #38548 — cilium/cilium
• Hubble — Cilium Observability
• Tetragon 공식 사이트
• Buoyant 블로그
• Istio Ambient Mesh 소개