"Sidecar는 트래픽을 가로채고, 컨트롤 플레인은 그것을 원격으로 조종한다"
"메시를 설치하는 것과, Sidecar가 트래픽을 가로채고 컨트롤 플레인이 데이터 플레인을 어떻게 제어하는지 아는 것은 다르다"
Envoy의 Listener·Filter·xDS부터 iptables 투명 가로채기, mTLS와 워크로드 신원, 트래픽 정책의 eventual consistency까지 왜 통신을 앱 밖으로 빼냈는가 라는 질문으로 서비스 메시의 내부를 끝까지 파헤칩니다
서비스 메시 자료는 넘쳐납니다. 하지만 대부분은 "어떻게 설치하나" 에서 멈춥니다.
| 일반 자료 | 이 레포 |
|---|---|
| "Istio를 깔면 mTLS가 자동입니다" | istio-init 컨테이너가 iptables REDIRECT 규칙을 박아 Pod의 모든 in/out을 15001/15006으로 돌리고, 그 안에서 Envoy가 mTLS 핸드셰이크를 수행하는 흐름을 직접 본다 |
| "Sidecar 패턴을 씁니다" | Pod에 컨테이너 2개(앱 + istio-proxy)가 뜨고, 앱은 자기 트래픽이 가로채진 줄 모른 채 평문 HTTP를 던지는 모습을 iptables -t nat -L로 확인 |
| "컨트롤 플레인이 정책을 배포합니다" | VirtualService(CRD)가 istiod에서 xDS(LDS/RDS/CDS/EDS)로 변환되어 Envoy에 푸시되는 과정, istioctl proxy-config로 현재 살아있는 설정을 dump |
| "서킷브레이커는 메시에서 처리합니다" | Spring Cloud의 @HystrixCommand(코드) vs Istio의 DestinationRule.outlierDetection(설정)을 같은 시나리오로 대조 — 라이브러리 vs 인프라 |
| "mTLS로 안전합니다" | 워크로드별 인증서가 SPIFFE ID(spiffe://cluster.local/ns/default/sa/x)로 발급·회전되는 메커니즘, PeerAuthentication STRICT로 평문 거부 확인 |
| "관측성도 자동입니다" | Envoy가 RED(요청률·에러율·지연)를 통계로 노출하고 Prometheus가 긁어가는 흐름, 메시가 볼 수 없는 것(앱 내부 상태)의 한계 |
| 이론 나열 | 실행 가능한 K8s+Istio + Envoy config_dump + Kiali 그래프 + 메시 유무 지연 실측 |
선행 학습 권장: Kubernetes Deep Dive — Sidecar 컨테이너·Pod·CRD의 토대. Network Deep Dive — L4/L7·TLS·HTTP/2 기초가 Envoy를 이해하는 전제입니다.
각 챕터의 첫 문서부터 바로 학습을 시작하세요!
💡 각 섹션을 클릭하면 상세 문서 목록이 펼쳐집니다
핵심 질문: 통신을 앱 코드 밖으로 빼낸다는 것이 정확히 무엇을 의미하는가?
메시가 등장한 이유, 라이브러리 vs 인프라, Sidecar 패턴, 데이터/컨트롤 플레인 분리, 메시 지형까지 (5개 문서)
| 문서 | 다루는 내용 |
|---|---|
| 01. 왜 메시인가 | MSA의 횡단 관심사(재시도·타임아웃·보안·관측)를 어디서 처리하는가, 라이브러리로 풀던 문제를 플랫폼으로 옮긴 동기 |
| 02. 라이브러리 vs 메시 | Spring Cloud(코드)와 Istio(인프라)가 같은 문제를 다루는 방식 비교, 폴리글랏·운영 일관성 vs 단순함·저지연의 트레이드오프 |
| 03. Sidecar 패턴 | Pod에 앱과 함께 사는 프록시 컨테이너, 앱은 자기 트래픽이 가로채진 줄 모른 채 평범한 HTTP를 던지는 구조 |
| 04. 데이터 vs 컨트롤 플레인 | Envoy(트래픽 처리)와 istiod(정책 배포)의 분리, 왜 같은 컴포넌트로 합치지 않았는가 |
| 05. 메시 지형 | Istio·Linkerd·Cilium의 아키텍처 차이, Sidecar vs Sidecar-less·eBPF vs 유저 공간 프록시 |
핵심 질문: Envoy는 어떻게 모든 트래픽을 가로채고 L7에서 처리하는가?
Envoy 구조, iptables 투명 가로채기, L7 라우팅, 필터 체인, xDS 동적 설정까지 (6개 문서)
| 문서 | 다루는 내용 |
|---|---|
| 01. Envoy 개요 | C++로 작성된 L7 프록시, 비동기 이벤트 루프, 메시가 Nginx가 아닌 Envoy를 택한 이유(동적 설정·관측·확장성) |
| 02. Envoy 구조 | Listener(포트) → Filter Chain(처리 파이프라인) → Route → Cluster(업스트림 그룹) → Endpoint(실제 IP)의 흐름 |
| 03. 트래픽 가로채기 | istio-init이 박는 iptables NAT 규칙(아웃바운드 15001·인바운드 15006), 앱이 모르는 사이 모든 in/out이 Envoy로 리다이렉트되는 메커니즘 |
| 04. L7 처리 | HTTP/2·gRPC 디멀티플렉싱, 헤더 기반 라우팅, 로드밸런싱 알고리즘, 연결 단위가 아닌 요청 단위 분산 |
| 05. 필터 체인 | HTTPConnectionManager 내부 필터들 — router/fault/cors/jwt_authn, 필터 순서가 만들어내는 처리 흐름 |
| 06. xDS API | 컨트롤 플레인이 Envoy를 동적으로 설정하는 gRPC 프로토콜 — LDS/RDS/CDS/EDS, ADS로 일관성 보장 |
핵심 질문: CRD 한 줄이 어떻게 수백 개 Envoy 설정으로 변환되어 배포되는가?
istiod 역할, 설정 변환·전파, 서비스 디스커버리, 인증서 발급까지 (5개 문서)
| 문서 | 다루는 내용 |
|---|---|
| 01. 컨트롤 플레인의 역할 | "트래픽을 보지 않는" 컴포넌트의 책임 — 정책 변환·디스커버리·신원 발급, 데이터 플레인과 왜 분리되어야 하는가 |
| 02. istiod | Pilot(설정)·Citadel(인증서)·Galley(검증)를 단일 바이너리로 합친 Istio 컨트롤 플레인의 구조 |
| 03. 설정 전파 | VirtualService(CRD) → 내부 모델 → xDS(gRPC stream) → Envoy의 흐름, eventual consistency가 만드는 일시적 불일치 |
| 04. 서비스 디스커버리 | K8s Service·Endpoints 변경을 watch하고 EDS로 Envoy에 푸시, ServiceEntry로 외부 서비스 등록 |
| 05. 인증서 관리 | 워크로드별 SPIFFE ID 발급, 24시간 회전, Envoy의 SDS(Secret Discovery Service)로 디스크 없이 인증서 받기 |
핵심 질문: 코드 변경 없이 카나리·서킷브레이커·결함 주입을 어떻게 실현하는가?
VirtualService 라우팅, 점진 배포, 레질리언스, 결함 주입, 미러링까지 (6개 문서)
| 문서 | 다루는 내용 |
|---|---|
| 01. 라우팅 | VirtualService의 match·route 규칙, 헤더·경로·가중치 기반 분산이 Envoy의 RDS로 어떻게 표현되는가 |
| 02. 카나리와 블루그린 | 가중치 90/10으로 시작해 점진 증가, 코드 한 줄도 안 바꾸고 배포 전략을 정책으로 표현 |
| 03. 로드밸런싱 | Round Robin·Least Request·Ring Hash, 지역 인식(locality-aware), gRPC L7 분산의 이점 |
| 04. 레질리언스 | 재시도·타임아웃·서킷브레이커를 메시에서 — Spring Cloud의 라이브러리 구현과 같은 시나리오로 대조 |
| 05. 결함 주입 | 의도적 지연/에러로 클라이언트의 복원력 테스트, 카오스 엔지니어링을 메시 정책으로 |
| 06. 트래픽 미러링 | 프로덕션 트래픽을 복제해 새 버전에 흘려보내기, 응답은 무시하고 동작만 검증 |
핵심 질문: "네트워크 안이라도 신뢰하지 않는다"가 어떻게 자동으로 구현되는가?
mTLS 자동화, SPIFFE 신원, 인증/인가 정책, Zero Trust 모델까지 (5개 문서)
| 문서 | 다루는 내용 |
|---|---|
| 01. mTLS | 양방향 TLS — 서버뿐 아니라 클라이언트도 인증서로 자신을 증명, Envoy가 핸드셰이크를 대신 수행해 앱은 평문만 다루는 구조 |
| 02. 워크로드 신원 | SPIFFE/SVID — IP가 아닌 논리적 신원(spiffe://...)으로 워크로드 식별, ServiceAccount와의 매핑 |
| 03. 인증 정책 | PeerAuthentication(mTLS 모드)·RequestAuthentication(JWT), STRICT 모드로 평문 트래픽 거부 |
| 04. 인가 정책 | AuthorizationPolicy로 누가 누구를 호출 가능한가, 신원·경로·메서드 기반 세밀 제어 |
| 05. Zero Trust 모델 | "네트워크 경계 너머"의 의미, 메시가 만드는 기본 거부 보안 모델과 한계 |
핵심 질문: 코드 변경 없이 어떻게 모든 서비스의 메트릭·트레이스·그래프를 얻는가?
자동 텔레메트리, RED 메트릭, 분산 추적, 서비스 그래프, 한계까지 (5개 문서)
| 문서 | 다루는 내용 |
|---|---|
| 01. 자동 텔레메트리 | Sidecar가 모든 트래픽을 보므로 메트릭 수집에 앱 변경이 0이 되는 이유, 메시가 제공하는 일관된 라벨 체계 |
| 02. 메트릭 | RED — Rate·Errors·Duration, Envoy의 /stats가 노출하는 카운터·게이지·히스토그램, Prometheus 통합 |
| 03. 분산 추적 | x-request-id·B3 헤더 전파는 메시가 자동, 그러나 생성은 앱이 — 자주 오해되는 책임 분담 |
| 04. 서비스 그래프 | Kiali가 메시 텔레메트리에서 의존성을 역추적하는 방식, 그래프가 보여주는 것과 못 보는 것 |
| 05. 한계 | 메시는 통신만 본다 — DB 쿼리, 비즈니스 로직, 내부 상태는 보이지 않음, 앱 레벨 관측의 필요성 |
핵심 질문: 메시는 공짜가 아니다 — 언제 가치가 비용을 넘는가?
Sidecar의 비용, Sidecar-less 진화, 도입 전략, 종합 실습까지 (4개 문서)
| 문서 | 다루는 내용 |
|---|---|
| 01. 메시의 비용 | Sidecar의 추가 hop 지연(p99 +1~5ms), CPU·메모리 오버헤드, 컨트롤 플레인 운영 복잡도의 정량 측정 |
| 02. Sidecar-less | Istio Ambient Mesh(ztunnel·waypoint)·Cilium(eBPF) — Sidecar 비용을 커널 레벨에서 줄이는 접근 |
| 03. 도입 전략 | 네임스페이스 단위 점진 도입, 메시가 과한 규모와 필요한 규모의 경계 |
| 04. 종합 | kind+Istio에 샘플 앱 배포, mTLS·카나리·결함 주입·텔레메트리를 한 시나리오로 — 지금까지의 모든 개념을 한 클러스터에 모음 |
🟢 "Istio를 깔았는데 Sidecar가 뭘 하는지 모른다" — 빠른 이해 (2주)
Week 1 — 가로채기와 Envoy의 정체
Ch1-03 Sidecar 패턴
Ch1-04 데이터 vs 컨트롤 플레인
Ch2-01 Envoy 개요
Ch2-03 트래픽 가로채기 (iptables 직접 확인)
Week 2 — 설정이 흘러가는 길
Ch2-02 Envoy 구조 (Listener/Cluster)
Ch2-06 xDS API
Ch3-01 컨트롤 플레인의 역할
Ch3-03 설정 전파 (CRD → xDS → Envoy)
🔵 라이브러리(Spring Cloud)에서 메시로 옮기는 개발자 (집중 코스)
같은 문제를 코드에서 인프라로 옮기는 흐름
Step 1 Ch1-02 라이브러리 vs 메시 — 같은 문제, 다른 위치
Step 2 Ch2-01~02 Envoy의 정체와 구조
Step 3 Ch3-01 컨트롤 플레인 — 왜 설정 변환이 필요한가
Step 4 Ch4-04 레질리언스 — @HystrixCommand vs DestinationRule
Step 5 Ch4-01~02 라우팅과 카나리 — Spring Cloud Gateway와 대조
Step 6 Ch5-01 mTLS — 라이브러리(Spring Security) vs 자동 인증
Step 7 Ch7-03 도입 전략 — 두 모델이 공존하는 시기
각 문서의 "🔬 내부 동작 원리"에서 *Envoy config_dump를 직접* 확인합니다
🔴 서비스 메시 내부를 원리로 이해하고 싶은 개발자 (7주)
Week 1 Chapter 1 전체 — 서비스 메시의 개념
Week 2 Chapter 2 전체 — Envoy 데이터 플레인
Week 3 Chapter 3 전체 — 컨트롤 플레인
Week 4 Chapter 4 전체 — 트래픽 관리
Week 5 Chapter 5 전체 — 보안과 Zero Trust
Week 6 Chapter 6 전체 — 관측성
Week 7 Chapter 7 전체 — 비용·실전·종합 실습
모든 문서는 동일한 구조로 작성됩니다.
| 섹션 | 설명 |
|---|---|
| 🎯 핵심 질문 | 이 문서를 읽고 나면 답할 수 있는 질문 |
| 🔍 왜 이게 존재하는가 | 문제 상황과 설계 배경 |
| 😱 흔한 오해 또는 잘못된 사용 | Before — 많은 개발자가 틀리는 방식 |
| ✨ 올바른 이해와 사용 | After — 원리를 알고 난 후의 올바른 접근 |
| 🔬 내부 동작 원리 | Envoy config_dump + xDS gRPC 스트림 + iptables 규칙 + mTLS 핸드셰이크 추적 |
| 💻 실전 실험 | kind+Istio에 배포 + istioctl proxy-config + 트래픽 정책 변경 후 관찰 |
| 📊 측정 | 메시 유무 지연 비교 / 라이브러리 vs 메시 / Sidecar 리소스 오버헤드 |
| 🤔 트레이드오프 | 이 설계의 장단점, 언제 다른 방법을 택할 것인가 |
| 📌 핵심 정리 | 한 화면 요약 |
| 🤔 생각해볼 문제 | 개념을 더 깊이 이해하기 위한 질문 + 해설 |
핵심은 kind(로컬 K8s) + Istio +
istioctl proxy-config로 Envoy 동적 설정을 직접 까보기 입니다.
# 1) 로컬 K8s 클러스터
kind create cluster --name mesh
# 2) Istio 설치 + Sidecar 자동 주입
istioctl install --set profile=demo -y
kubectl label namespace default istio-injection=enabled
# 3) Sidecar 주입 확인 — 컨테이너 2개 (앱 + istio-proxy)
kubectl get pod
kubectl describe pod <pod> # init container: istio-init 확인
# 4) iptables 가로채기 규칙 확인
kubectl exec <pod> -c istio-proxy -- iptables -t nat -L
# PREROUTING/OUTPUT 체인이 ISTIO_REDIRECT(15001)·ISTIO_IN_REDIRECT(15006)로 점프
# 5) Envoy 동적 설정 dump — 이 레포의 핵심 실험
istioctl proxy-config listeners <pod> # LDS — 어떤 포트를 듣는가
istioctl proxy-config routes <pod> # RDS — 라우팅 규칙
istioctl proxy-config cluster <pod> # CDS — 업스트림 그룹
istioctl proxy-config endpoints <pod> # EDS — 실제 IP들
kubectl exec <pod> -c istio-proxy -- curl localhost:15000/config_dump | jq
# 6) mTLS STRICT — 평문 거부 확인
kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata: { name: default }
spec: { mtls: { mode: STRICT } }
EOF
# 메시 밖에서 호출 시 연결 거부 관찰
# 7) 카나리 — 가중치 90/10 분할
# VirtualService 변경 후 트래픽 분포 측정
# 8) 결함 주입 — 30% 지연 5초
# 클라이언트의 timeout/retry 동작 관찰
# 9) Kiali — 서비스 그래프 시각화
istioctl dashboard kiali⬆️ 선행 학습
kubernetes-deep-dive → Sidecar 컨테이너·Pod·CRD·watch 메커니즘
network-deep-dive → L4/L7·TLS·HTTP/2 (Envoy의 토대)
🤝 시너지
grpc-deep-dive → xDS는 gRPC 스트리밍 위에서 동작
spring-cloud-deep-dive → 같은 문제를 라이브러리로 — 직접 대조
cryptography-deep-dive → mTLS·인증서 발급·X.509의 기반
observability-deep-dive → 메시 텔레메트리와 앱 레벨 관측의 결합
🧬 수렴 (같은 문제를 다른 위치에서)
spring-cloud → 코드 레벨 분산 패턴
iac → 클라우드 네이티브 인프라 자동화
→ 메시는 "코드가 아닌 인프라가" 통신을 다루는 접근의 정점
- Istio 공식 문서
- Envoy 공식 문서
- xDS API 명세 (envoyproxy/data-plane-api)
- SPIFFE/SPIRE 문서 (워크로드 신원)
- Istio in Action — Christian Posta, Rinor Maloku
- Mastering Service Mesh — Anjali Khatri, Vikram Khatri
- Linkerd 문서 · Cilium Service Mesh (대조 학습)
⭐️ 도움이 되셨다면 Star를 눌러주세요!
Made with ❤️ by Dev Book Lab
"메시를 설치하는 것과, Sidecar가 트래픽을 가로채고 컨트롤 플레인이 데이터 플레인을 어떻게 제어하는지 아는 것은 다르다"