Istio 아키텍처 해부: Envoy · Sidecar · Control Plane

결론 요약

Istio의 핵심은 “구성요소”가 아니라 요청이 실제로 어디를 지나가느냐다.
모든 서비스 트래픽은 Envoy sidecar를 강제 통과하며, 이 집합이 Data Plane = Envoy sidecar들의 집합이다.
Control Plane = 구성/정책을 배포하는 plane으로, 트래픽 경로에 직접 관여하지 않는다.
Sidecar injection은 파드의 네트워크 경로 자체를 바꾼다.
성능 비용은 hop 증가, L7 처리, mTLS, 정책 평가 등 경로 상의 필연적 비용에서 발생한다.
“Istio가 문제를 만든다”는 말은 대부분 경로 이해 부족 + 디버깅 미숙에서 나온다.

---

한 장으로 보는 요청 흐름 (다이어그램)

[Client]
|
v
[Service A Pod]
|
|  (iptables redirect)
v
[Envoy Sidecar A]  ---- mTLS / L7 routing / retry ----
|
v
[Envoy Sidecar B]
|
|  (iptables redirect)
v
[Service B Pod]

• 모든 인바운드/아웃바운드 트래픽은 Envoy를 통과한다.
• 애플리케이션은 “프록시가 있다”는 사실을 모른다.

---

Sidecar(Envoy)의 역할과 경계

정의

Envoy는 L7 proxy이며, 애플리케이션 코드 바깥에서 통신을 통제한다.

흐름

• 요청 수신 → 라우팅 규칙 적용
• 재시도/타임아웃/서킷 브레이커 판단
• mTLS 처리
• 메트릭/트레이스 수집

Envoy가 하는 일 (L7 기준)

• 라우팅: VirtualService 규칙 반영
• 리트라이: 실패 조건별 재시도
• 타임아웃: 서비스별 응답 제한
• 메트릭: 요청 수, 지연, 오류율
• 트레이싱: 요청 경로 추적

경계

• 비즈니스 로직은 모른다
• 트래픽 정책만 집행한다

---

Control Plane의 역할과 경계

정의

Control Plane = 구성/정책을 배포하는 plane

왜 트래픽을 직접 처리하지 않는가

• 단일 병목을 만들지 않기 위해
• 데이터 경로와 제어 경로를 분리하기 위해
• 장애 시 트래픽 영향을 최소화하기 위해

실제 역할

• Envoy 설정 생성/배포
• 인증서 발급(mTLS)
• 정책 변경 전파

Control Plane가 죽어도:

• 기존 트래픽은 흐른다
• 새 정책 반영만 안 된다

---

주입(injection) 이후 무엇이 달라지나 (네트워크 관점)

결론

파드의 네트워크 경로가 강제로 우회된다.

Sidecar injection 이후:

• iptables 규칙 추가
• 파드 내부 트래픽 → Envoy로 리다이렉트
• 애플리케이션은 localhost 통신처럼 느낀다

즉,

“코드 수정 없이 정책을 강제한다”는 말의 실체는
네트워크 레벨에서 우회로를 만든다는 뜻이다.

---

성능/비용 포인트 (체크리스트)

결론

아래 지점에서 비용이 발생한다.

1. Hop 증가: App → Envoy → Envoy → App
2. L7 파싱 비용: HTTP 헤더/라우팅 규칙 평가
3. mTLS 암복호화
4. 정책 평가 비용: RBAC, Authorization
5. 메트릭/트레이스 수집 오버헤드

이 비용은 “최적화”로 0이 되지 않는다.
구조적 비용이다.

---

디버깅에서 자주 보는 증상 → 원인 매핑

증상	원인
요청이 갑자기 느려짐	재시도 + 타임아웃 중첩
간헐적 503	mTLS 핸드셰이크 실패
특정 서비스만 통신 불가	AuthorizationPolicy 차단
배포 후 트래픽 미반영	Control Plane 설정 전파 지연
로그는 정상인데 장애	Envoy 레벨에서 드랍

---

“Istio가 문제를 만든다”는 말이 나오는 대표 상황 3개

1) 경로를 이해하지 못한 채 설정만 추가

• 원인: 요청이 몇 번 프록시를 도는지 모름

2) 재시도 정책 남용

• 원인: 실패 시 트래픽 증폭 → 지연 폭증

3) 보안 정책 일괄 적용

• 원인: 서비스 간 의존성 파악 부족

---

흔한 오해 3개 + 교정

1. 오해: Control Plane이 느려서 트래픽이 느리다
   교정: Control Plane은 데이터 경로에 없다.

2. 오해: Envoy는 단순 로드밸런서
   교정: L7 정책 엔진이다.

3. 오해: Sidecar는 선택 사항
   교정: Istio의 핵심 전제다.

---

재학습 체크리스트

• 요청이 실제로 통과하는 경로를 그릴 수 있는가?
• Envoy가 하는 일과 안 하는 일을 구분하는가?
• Control Plane 장애 시 영향 범위를 아는가?
• iptables 리다이렉트의 의미를 이해하는가?
• 성능 비용이 어디서 발생하는지 설명 가능한가?
• 디버깅 시 Envoy 로그를 먼저 보는가?
• 재시도/타임아웃을 함께 고려하는가?
• “코드 문제 vs 메시 문제”를 분리할 수 있는가?

---

• 참고: Kubernetes Istio : 완벽 실습 과정