[Cilium Study] Cilium Service mesh 1

Service mesh?

K8s 같은 환경에서 마이크로 서비스 간 통신을 제어, 보안, 모니터링 관리하는 인프라 계층이다.

즉 서비스와 서비스 사이 네트워크 트래픽을 "투명하게" 제어할 수 있는 기능을 제공한다.

핵심기능

1. 서비스 간 통신 제어
   1. 라우팅 : A 서비스 -> B 서비스 호출 시 Canary, Blue/Green 배포 가능
   2. retry / timeout : 요청 실패 시 재시도, 응답 지연 시 타임아웃 처리
   3. 부하 분산 : 여러 pod 간에 트래픽 분산
2. 보안 (Security)
   1. mTLS (Mutual TLS)로 서비스 간 통신 암호화
   2. 인증/인가(Authorization) : 서비스 단위 RBAC (Role-Based Access Control) 적용
   3. 네트워크 보안 정책 강화
3. 관측성 (Observability)
   1. 서비스 간 호출관계 (서비스 맵) 시각화
   2. 요청 지연(latency), 오류율(error rate) 모니터링
   3. 분산 트레이싱(Jaeger, Zipkin 등)
4. 정책 관리 (Policy Enforcement)
   1. Rate limiting (요청 제한)
   2. Circuit breaker (장애 전파 방지)
   3. QoS 정책 적용

Service mesh 동작 방식

• Sidecar  proxy 를 각 pod 옆에 붙여서 모든 서비스 간 트래픽을 이 프록시가 가로채고 관리한다.
• 개발자는 애플리케이션 코드에 네트워크 제어 로직을 넣을 필요가 없음.
• 대표적으로 Envoy 프록시가 많이 사용된다.

대표적인 구현체

• Istio : 가장 많이 쓰이는 오픈소스 Service Mesh
• Linkerd : 가벼운 경량 서비스 메시
• Consul Connect (Hashicorp) : 멀티플랫폼 지원
• Cilium Service Mesh : eBPF 기반, 커널 레벨에서 구현

Service vs Ingress vs Service Mesh

항목	Service	Ingress	Service Mesh
주요 목적	Pod <-> Pod Pod <-> 외부 통신 연결	외부 트래픽 -> 내부 서비스 라우팅	마이크로 서비스 간 통신 제어/보안/관측
L4/L7	주로 L4 (IP/Port)	주로 L7 (HTTP Host/Path)	L4 + L7 모두
보안	기본 네트워크 통신만	TLS(HTTPS) 종단	mTLS,
관측성	없음	일부 (Access Log)	전체 트래픽 관측, 분산 트레이싱
트래픽 제어	단순 로드 밸런싱	도메인/경로 기반 라우팅	Canary, Blue/Gree, Circuit Breaker, Rate limiting

 

Cilium Service Mesh vs 전통적인 Service Mesh (Istio, Linkerd 등)

구분	전통적인 Service Mesh (Istio, Linkerd 등)	Cilium Service Mesh
아키텍처 방식	Sidecar 프록시 기반 (Envoy 등) 각 Pod 옆에 사이드카 컨테이너를 붙여서 트래픽을 가로챔	사이드카리스(Sidecar-less) eBPF 기반으로 커널 레벨에서 트래픽을 직접 제어
프록시 부담	Pod 수만큼 프록시가 늘어나 → 리소스 오버헤드 ↑ (CPU/메모리/네트워크 지연)	별도 프록시 없음 → 오버헤드 ↓ (커널 레벨에서 직접 처리)
성능	L7 로직은 유연하지만, 성능은 사이드카로 인해 다소 손실 발생	eBPF 기반 패킷 필터링으로 고성능/저지연
보안 (mTLS)	기본 제공 (Istio: 강력한 인증/인가, PKI 관리 포함)	mTLS 지원은 점차 확장 중 (초기엔 L3/L4 보안 중심, 현재는 L7도 강화됨)
트래픽 제어	매우 풍부: Canary, Blue/Green, Fault injection, Rate limiting 등	현재 점진적 확장 중. 기본 라우팅/부하분산 → 고급 기능 계속 추가되는 중
관측성	Envoy metrics, Jaeger, Prometheus, Grafana 등 풍부	Hubble (eBPF 기반 관측) 사용. 커널 레벨에서 흐름 추적, L3~L7까지 가시성 제공
구성 복잡도	사이드카 배포 필요 → 설치/운영 복잡 (Istio는 특히 무겁다)	사이드카 없음 → 설치 단순, CNI와 통합 (Cilium만 있으면 됨)
리소스 효율성	사이드카 개수만큼 리소스 소비 (큰 규모일수록 부담)	eBPF 기반 → 훨씬 가벼움
클라우드 네이티브 친화성	CNCF 생태계에서 표준화가 잘 되어 있음 (Istio, Linkerd는 오래됨)	비교적 신생 기능. 하지만 eBPF + CNI 기반이라 네트워크/보안/서비스 메시를 올인원으로 제공

Cilium Service mesh는

• L3/L4 수준 프로토콜은 eBPF 처리
• L7 수준 어플리케이션 : cilium-envoy 가 처리

정리

• Istio / Linkerd 
  • 장점 : 기능이 풍부하고, Service Mesh 생태계에서 성숙, 보안/정책/관측 다 완비
  • 단점 : 무겁고 복잡함. 사이드카 때문에 리소스와 성능 손실 있음.
• Cilium Service Mesh 
  • 장점 : eBPF 기반 -> 고성능, 저지연, 사이드카리스 구조라 단순/효율적
  • 단점 : 기능 면에서는 아직 Istio보다 제한적 (점진적으로 추가되는 중)