서비스 메시

학습 목표

서비스 메시가 K8s Service·Ingress와 다른 문제(L4/L7 내부 통신·보안·관측)를 해결하는지 설명할 수 있다.

sidecar 프록시와 control plane·data plane 역할을 구분할 수 있다.

mTLS(PeerAuthentication)로 서비스 간 암호화·신원을 적용하는 방식을 설명할 수 있다.

VirtualService·DestinationRule로 traffic split·retry·timeout을 코드 없이 정책화할 수 있다.

canary 배포와 mesh 트래픽 분할을 연계하고 도입 트레이드오프를 평가할 수 있다.

문제 상황

• 서비스 20개 — 각 팀이 retry·timeout·circuit breaker 라이브러리 제각각
• 평문 ClusterIP 통신 — Pod 탈취 시 내부 API 전부 노출
• 분산 트레이싱 불가 — 요청 ID 전파 누락·로그 상관 실패
• canary 10% — Ingress weight만 조정·내부 서비스→서비스 호출은 구버전 고정
• gRPC·TCP 장기 연결 — Ingress 한계·L7 정책 부재
• Well-Architected Security — 전송 암호화·최소 권한 미충족

앞서 Service·Ingress·배포 전략 — 클러스터 안 라우팅과 릴리스 패턴은 다뤘다. Part 5 첫 편은 MSA 서비스 간 통신을 인프라 레이어로 일원화하는 서비스 메시다.

1. 서비스 메시란

Service mesh — 마이크로서비스 간 통신을 전담하는 인프라 레이어. 애플리케이션 코드 변경 없이 프록시(sidecar)가 트래픽을 가로채 정책을 적용.

	K8s Service	Ingress	Service mesh
범위	클러스터 내부 L4	클러스터 경계 L7 HTTP	서비스 간 L4/L7
로드밸런싱	kube-proxy	Ingress controller	envoy sidecar
mTLS	없음	TLS 종료(edge)	서비스 간 양방향
canary	selector 교체	annotation weight	VirtualService subset weight
관측	kubelet·cAdvisor	access log	분산 trace·metric 표준

대표 구현 — Istio(envoy), Linkerd, Cilium Service Mesh. 본문은 Istio 용어·CRD 기준.

평면	구성	역할
Control plane	istiod	설정 배포·인증서 발급·서비스 디스커버리
Data plane	envoy sidecar	실제 프록시·mTLS·라우팅·메트릭

sidecar 주입 — namespace label istio-injection=enabled 또는 Pod annotation. 새 Pod마다 envoy 컨테이너 자동 추가.

2. Sidecar Pod

Pod 안 애플리케이션 컨테이너 옆에 envoy — 모든 inbound/outbound 트래픽이 sidecar 경유.

경로	동작
Inbound	다른 Pod → envoy → app localhost
Outbound	app → envoy → 대상 서비스 envoy
iptables	init container가 트래픽 리다이렉트 (istio-proxy)

리소스 — sidecar CPU·memory requests 필수. 소규모 Pod에도 고정 오버헤드 → 노드 용량 계획 필요.

앱 변경 없음 — HTTP 헤더 전파(x-request-id)·retry는 mesh 정책으로.

3. mTLS

Mutual TLS — 클라이언트·서버 양쪽 인증서 검증. Istio는 SPIFFE 형식 워크로드 ID로 서비스 신원 부여.

모드	PeerAuthentication
DISABLE	mTLS 끔	마이그레이션 초기
PERMISSIVE	평문·mTLS 혼용	기본(레거시 호환)
STRICT	mTLS 만	프로덕션 권장

# code/peerauthentication-strict.yaml
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

범위
Mesh-wide	istio-system default PeerAuthentication
Namespace	팀·환경 별 분리
Workload	selector로 특정 Deployment 만

인증서 — istiod가 짧은 TTL 인증서 자동 로테이션. 앱 코드·Secret 수동 관리 불필요.

AuthorizationPolicy — mTLS 이후 L7 허용 규칙 (예: order 만 payment 호출).

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payment-from-order
  namespace: production
spec:
  selector:
    matchLabels:
      app: payment
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/production/sa/order"]

4. 트래픽 관리

VirtualService — 라우팅 규칙(host·subset·weight·fault).

DestinationRule — subset 정의(version label), loadBalancer, connectionPool, outlierDetection.

# code/virtualservice-canary.yaml
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: api
  namespace: production
spec:
  host: api.production.svc.cluster.local
  subsets:
    - name: stable
      labels:
        version: v1.3
    - name: canary
      labels:
        version: v1.4
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api
  namespace: production
spec:
  hosts:
    - api.production.svc.cluster.local
  http:
    - route:
        - destination:
            host: api.production.svc.cluster.local
            subset: stable
          weight: 90
        - destination:
            host: api.production.svc.cluster.local
            subset: canary
          weight: 10

배포 전략 연계	mesh 이점
Canary	내부 호출도 동일 weight — BFF→API 일관
Blue-green	subset 전환 한 CR
Fault injection	chaos 테스트 without 앱 코드

retry·timeout — DestinationRule·VirtualService 공통.

# code/destinationrule-retry.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: catalog
spec:
  hosts:
    - catalog
  http:
    - timeout: 2s
      retries:
        attempts: 3
        perTryTimeout: 500ms
        retryOn: 5xx,reset,connect-failure
      route:
        - destination:
            host: catalog

주의
멱등 아닌 POST	retry 위험 — idempotency-key 또는 retry 제외
retry 폭주	max attempts·budget 제한
타임아웃 중첩	앱 timeout < mesh timeout 정렬

5. 관측성 연동

envoy가 표준 메트릭·액세스 로그·trace span 생성.

신호	활용
Prometheus	istio_requests_total, latency histogram
Jaeger / Tempo	분산 트레이스 — 서비스 그래프
Kiali	topology·mTLS 상태·VirtualService 시각화
Grafana	SLO 대시보드 — canary gate

Well-Architected Operational Excellence — 배포 후 error rate·p99를 mesh 메트릭으로 canary 판단 (13편 Argo Rollouts 대안·보완).

# sidecar 메트릭 (요지)
kubectl exec deploy/api -c istio-proxy -- \
  curl -s localhost:15000/stats/prometheus | head

6. 도입 트레이드오프

도입 할 때	보류 검토
서비스 10+·팀 분산	모놀리스 1~2 서비스
mTLS·정책 일원화 필수	NetworkPolicy·Ingress로 충분
canary·내부 트래픽 제어	단순 rolling 만
플랫폼 팀 운영 역량	sidecar 장애 대응 인력 없음

대안
Linkerd	경량 Rust proxy·단순 UX
Cilium	eBPF·sidecar less 옵션
앱 SDK	Resilience4j 등 — 언어 별 중복
Gateway API	경계 L7 — 내부 mTLS 별도

비용 — 노드 CPU 10~15% sidecar 오버헤드(워크로드 따라 상이). istiod HA 3 replica 권장.

7. 실무 체크리스트

항목	권장
주입	프로덕션 namespace 만 선택 주입
mTLS	PERMISSIVE → 검증 → STRICT 단계 전환
리소스	sidecar limits 명시 — OOM 시 Pod 전체 영향
canary	VirtualService weight + Prometheus SLO gate
디버깅	istioctl proxy-config·analyze 습관화
업그레이드	Istio 버전 = 클러스터 minor 호환 표 확인

# 설치·검증 (개발 클러스터)
istioctl install --set profile=demo -y
kubectl label namespace production istio-injection=enabled
istioctl analyze -n production

8. 정리

• 서비스 메시 — MSA 통신·보안·관측을 sidecar로 분리
• istiod + envoy — control / data plane
• mTLS STRICT + AuthorizationPolicy — Well-Architected Security 보완
• VirtualService weight — canary·내부 호출 일관
• 오버헤드·운영 복잡도 — 규모·요구 맞을 때 도입

다음에 다룰 것

• 멀티클러스터 — 페더레이션·cluster mesh·DR
• GitOps 다중 클러스터 배포

---

해당 내용은 Istio Documentation 의 내용을 기반으로 합니다.