서비스 메시 비교: Istio vs Linkerd vs Cilium

서비스 메시가 필요한 순간

마이크로서비스가 10개를 넘어서면 서비스 간 통신 관리가 복잡해집니다. 재시도, 서킷 브레이커, mTLS, 트레이싱을 각 서비스 코드에 구현하는 것은 중복이고 비효율적입니다.

핵심 기능

Istio 설치 및 카나리 배포

istioctl install --set profile=production -y
kubectl label namespace my-app istio-injection=enabled

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app
spec:
  http:
  - route:
    - destination:
        host: my-app
        subset: v1
      weight: 90
    - destination:
        host: my-app
        subset: v2
      weight: 10

mTLS 전체 적용

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

Linkerd - 경량화

linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
kubectl annotate namespace my-app linkerd.io/inject=enabled

Istio vs Linkerd 비교

Cilium - eBPF 기반 (사이드카 없음)

helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set kubeProxyReplacement=true

# L7 HTTP 정책
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
spec:
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
      rules:
        http:
        - method: GET
          path: "/api/.*"

선택 가이드

서비스 메시는 복잡성을 추가합니다. 필요성을 먼저 검증하고 도입하세요.

규모·요구별 의사결정표

도입 전 체크리스트

• 목적을 한 문장으로 — "mTLS 의무화"인지 "카나리 배포"인지 "관측"인지 (목적별로 최소 도구가 다름)
• 사이드카 리소스 예산 — 파드당 추가 CPU/메모리 × 파드 수를 미리 계산
• 업그레이드 경로 — 컨트롤플레인 버전 업 시 데이터플레인 재기동 절차 리허설
• 장애 격리 계획 — 메시 컨트롤플레인 장애 시 트래픽 영향 범위 확인 (fail-open 여부)
• 제거 시나리오 — 6개월 후 메시를 걷어낼 수 있는 구성인지

메시 도입 후 503·연결 끊김이 생길 때

서비스 메시를 도입한 직후 가장 흔한 증상은 간헐적인 503과 연결 재설정입니다. 대부분 메시 자체의 결함보다 설정 순서와 기본값에서 옵니다.

원인

• 앱 컨테이너가 사이드카 프록시보다 먼저 시작해 초기 외부 호출이 실패
• mTLS를 STRICT로 바꿨는데 사이드카가 없는 워크로드가 호출함
• 프록시와 앱의 유휴 연결 타임아웃 차이로, 재사용하려던 연결이 이미 닫혀 있음

진단 명령

# Istio: 설정 동기화 상태와 문제 분석
istioctl proxy-status
istioctl analyze -n app
# 특정 Pod 프록시 로그에서 응답 플래그 확인 (UF, UC, NR 등)
kubectl logs deploy/checkout -c istio-proxy --tail=200 | grep ' 503 '
# Linkerd: 컨트롤 플레인·데이터 플레인 점검
linkerd check
linkerd check --proxy -n app

Envoy 접근 로그의 응답 플래그는 원인 분류에 유용합니다. 예를 들어 UC는 업스트림 연결 종료, UF는 업스트림 연결 실패, NR은 일치하는 라우트 없음입니다.

해결

• Istio는 holdApplicationUntilProxyStarts 설정으로 앱이 프록시 준비 후 시작하게 할 수 있습니다.
• mTLS는 PERMISSIVE로 시작해 모든 호출자가 메시에 들어온 것을 확인한 뒤 STRICT로 바꿉니다.
• 앱의 keep-alive 타임아웃을 프록시보다 짧게 맞추거나 재시도 정책을 명시합니다.

재발 방지

• istioctl analyze나 linkerd check를 배포 파이프라인에 넣어 설정 오류를 사전에 잡습니다.

참고: 공식 문서

이 글에서 다루는 동작·설정·에러의 1차 출처는 다음 공식 문서입니다. 버전별 옵션과 정확한 동작은 여기서 확인하세요.

• Istio 공식 문서

자주 묻는 질문 (FAQ)

Q. Cilium과 Istio는 뭐가 다른가요? A. Istio는 사이드카(Envoy) 기반 L7 서비스 메시로 트래픽 관리·mTLS·관측성이 풍부하지만 사이드카 오버헤드가 있습니다. Cilium은 eBPF 기반으로 커널 레벨에서 네트워킹·보안을 처리해 오버헤드가 낮고, Cilium Service Mesh는 사이드카 없는(sidecarless) 모드를 지원합니다. 성능·저지연이 우선이면 Cilium, 성숙한 L7 트래픽 제어와 생태계가 우선이면 Istio입니다.

Q. Cilium과 Istio를 함께 쓸 수 있나요? A. 가능합니다. CNI는 Cilium(고성능 네트워킹·NetworkPolicy)으로, 서비스 메시 L7 기능은 Istio로 두는 조합이 흔합니다. 단 mTLS·트래픽 관리 기능이 겹치므로 역할을 명확히 분리해야 합니다.

비교 요약

도입 전제

• 서비스 수·팀 SR 여력 확인
• 관측(메트릭/트레이스) 먼저 정리
• 카나리·타임아웃 기본값부터

참고 자료

• Istio docs
• Linkerd docs
• Cilium Service Mesh

검증 환경·편집자 주

• 2026-09. “메시=만능”이 아니라 운영 인력과 트레이드오프입니다.

자주 묻는 질문 (FAQ)

Q. 10개 미만 서비스에도 메시가 필요한가요?
대개 아니요. Ingress+재시도 라이브러리로 충분한 경우가 많습니다.