[Kubernetes] Service Mesh (Istio, Linkerd, Cilium)

Service Mesh, Kubernetes Service Mesh, Istio, Linkerd, Cilium Service Mesh, Ambient Mesh, sidecarless mesh, Envoy sidecar, mTLS, 서비스 메시

정의

Service Mesh 는 마이크로서비스 간 통신에 L7 정책, mTLS 암호화, 트래픽 관리, 관측성 을 제공하는 인프라 계층입니다. 앱 코드를 바꾸지 않고 프록시 (sidecar 또는 데이터 플레인) 가 모든 트래픽을 가로챕니다.

세 대표 프로젝트: Istio, Linkerd, Cilium Service Mesh.

왜 필요한가

Kubernetes 내장 Service + Ingress 만으로는 부족한 것들:

• mTLS: Pod 간 자동 암호화 + 상호 인증
• L7 라우팅: HTTP path / header 기반, canary, mirroring
• Retry / timeout / circuit breaking: 앱 코드 없이 정책으로
• 관측성: 자동 metric (RPS, latency, error rate), 분산 트레이스
• 인증/인가: 서비스 identity, JWT 검증
• Rate limiting: 서비스별 한도

두 가지 데이터 플레인 모델

1. Sidecar

각 Pod 에 프록시 (Envoy 등) sidecar 추가. Istio 전통, Linkerd 기본.

장점: 격리, per-pod 정책 세밀 단점: 리소스 오버헤드 (Pod 당 프록시), 시작 지연

2. Sidecarless (Node-level / eBPF)

프록시가 노드 레벨 (DaemonSet, eBPF program). Cilium Service Mesh, Istio Ambient.

장점: 리소스 절감, 지연 감소 단점: 격리 감소, 새로운 개념

Istio

가장 기능 풍부. Google 발원, IBM/Red Hat/Solo.io 등 광범 참여.

아키텍처

• Envoy (data plane): Sidecar 프록시 (또는 Ambient 의 ztunnel + waypoint)
• Istiod (control plane): pilot (트래픽 관리), citadel (mTLS 인증서), galley (config)

주요 리소스

# VirtualService: 라우팅
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: web-vs
spec:
  hosts: [web]
  http:
    - match:
        - headers:
            x-version:
              exact: v2
      route:
        - destination:
            host: web
            subset: v2
    - route:
        - destination:
            host: web
            subset: v1
          weight: 90
        - destination:
            host: web
            subset: v2
          weight: 10
    - retries:
        attempts: 3
        perTryTimeout: 2s
    - timeout: 10s
---
# DestinationRule: 로드밸런싱, TLS
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: web-dr
spec:
  host: web
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http2MaxRequests: 1000
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 30s
  subsets:
    - name: v1
      labels: {version: v1}
    - name: v2
      labels: {version: v2}

Istio Ambient Mesh

Sidecar 없는 새 데이터 플레인 (v1.22+ GA):

• ztunnel: 노드마다 DaemonSet. L4 mTLS + tunneling.
• waypoint: L7 정책 필요 시 별도 Envoy proxy.

계층 분리: L4 는 ztunnel (모든 트래픽 자동), L7 는 waypoint (필요한 곳만). 점진 도입.

Linkerd

Buoyant 개발. “가장 단순한 mesh” 지향.

아키텍처

• linkerd-proxy (Rust, 매우 가벼움): sidecar
• linkerd control plane: destination, identity, proxy-injector

특징

• Rust 프록시: Envoy 보다 훨씬 가벼움 (< 10 MB memory)
• mTLS default: 옵션 아닌 기본
• Zero-config: 대부분 자동
• CNCF Graduated (2021)

사용

linkerd install | kubectl apply -f -
linkerd inject deployment.yaml | kubectl apply -f -

linkerd inject 는 pod template 에 sidecar 주석 자동 추가.

리소스

apiVersion: policy.linkerd.io/v1alpha1
kind: Server
metadata:
  name: web-server
spec:
  podSelector:
    matchLabels:
      app: web
  port: 8080
  proxyProtocol: HTTP/1
---
apiVersion: policy.linkerd.io/v1alpha1
kind: ServerAuthorization
metadata:
  name: web-clients
spec:
  server:
    name: web-server
  client:
    meshTLS:
      identities:
        - "gateway.default.serviceaccount.identity.linkerd.cluster.local"

Istio 보다 정책 문법 단순.

Cilium Service Mesh

eBPF 기반. CNI + service mesh 통합.

아키텍처

• Cilium DaemonSet: eBPF program 을 kernel 에 로드. L3-L7 처리.
• Envoy 통합: L7 정책 필요 시 노드에 Envoy 실행.

장점

• Sidecarless: 리소스 절감
• CNI 통합: 별도 mesh 설치 불필요
• Hubble: 관측 UI + CLI (자체)
• kube-proxy replacement: eBPF 로 대체 성능 향상

리소스

Gateway API 및 자체 CiliumEnvoyConfig 등 지원.

기능 비교

기능	Istio	Linkerd	Cilium
mTLS	✓ (선택/강제)	✓ (기본)	✓
L7 라우팅	매우 풍부	기본	풍부 (Envoy)
Traffic split	✓	✓	✓
Retry / Timeout	✓	✓	✓
Circuit breaking	✓	✗ (부재)	✓
Rate limiting	✓ (with Envoy)	✗	✓
JWT auth	✓	✗	✓
관측성	매우 풍부 (Kiali, Jaeger)	좋음 (자체 dashboard)	좋음 (Hubble)
Multi-cluster	✓	✓	✓ (Cluster Mesh)
리소스 부담	큼 (Envoy)	작음 (Rust)	작음 (eBPF)
학습 곡선	가파름	완만	중간
Ambient/Sidecarless	✓ (Ambient)	✗	✓ (native)

결론:

• Simple + 최소 오버헤드: Linkerd
• 최대 기능 + 다양한 정책: Istio
• CNI + Mesh 통합, 성능: Cilium

Gateway API

Ingress 의 후속 표준. 3-role 모델 (Infrastructure Provider, Cluster Operator, Application Developer). Istio/Cilium/Linkerd 모두 지원 (Linkerd 2.15+).

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main
spec:
  gatewayClassName: istio
  listeners:
    - name: https
      port: 443
      protocol: HTTPS
      tls:
        mode: Terminate
        certificateRefs:
          - name: tls-secret
      allowedRoutes:
        namespaces:
          from: All
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web
spec:
  parentRefs:
    - name: main
  hostnames: [web.example.com]
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: web
          port: 80
          weight: 90
        - name: web-canary
          port: 80
          weight: 10

VirtualService/DestinationRule 을 대체하는 방향. Long-term 표준.

도입 결정

Service Mesh 가 필요한가

필요 신호:

• 여러 팀이 마이크로서비스 배포
• mTLS 요구
• Canary / traffic mirroring 필요
• Retry / timeout 정책이 앱 코드에 산재
• 관측성이 부족

불필요 신호:

• 단일 앱 / 소수 서비스
• 통신이 단순
• 이미 API Gateway 하나로 충분
• 팀이 mesh 운영 여력 없음

Mesh 는 운영 부담 이 큽니다. 잘 몰라서 mesh 설치 후 유령 지연이 생기는 흔한 실패.

도입 단계

1. 관측만: mTLS + 자동 metrics 만 (traffic policy 없음)
2. 정책 도입: retry, timeout, circuit breaker
3. Canary: VirtualService 로 weight-based
4. Zero-trust: AuthorizationPolicy 로 서비스 인증

함정

관련 위키

• Kubernetes - 상위 개요
• Service - Mesh 로 확장
• Ingress - Mesh gateway 대비
• Init & Sidecar Containers - Sidecar 패턴
• NetworkPolicy - L3/L4 (mesh 는 L7)
• RBAC - 대비되는 인증
• OpenTelemetry - 관측 통합
• Prometheus - Metric 소비