Envoy with Istio
1. Envoy as Sidecar Proxy with Istio
![[Figure 1] Sidecar Proxy with Istio](/blog-software/docs/theory-analysis/envoy-istio/images/envoy-istio-sidecar.png)
[Figure 1] Sidecar Proxy with Istio
[Figure 1]은 Istio 환경에서 Envoy가 Sidecar Proxy로 동작할 때 App Pod 내부의 구성 요소와 Traffic 흐름을 나타내고 있다. App Pod에는 App Container와 함께 istio-proxy Container가 배치되며, istio-proxy Container 안에서는 pilot-agent와 Envoy 두 Process가 동작한다. Pod 시작 시 istio-init Container가 설정한 iptables Rule에 의해 App Container의 모든 Traffic은 Envoy를 경유한다. 주요 흐름은 다음과 같다.
- xDS 설정 전달 (하늘색) : istiod의
15012Port xDS Server는 LDS, RDS, CDS, EDS, SDS, NDS 설정을 하나의 ADS Stream으로 pilot-agent에 전달한다. pilot-agent는 받은 설정을unix:///etc/istio/proxy/XDSSocket을 통해 다시 ADS로 Envoy에 중계하며, Workload 인증서는unix:///var/run/secrets/workload-spiffe-uds/socketSocket을 통해 SDS로 전달한다. 인증서를 별도의 SDS Socket으로 분리하여 전달하는 이유는 Private Key와 같은 민감 정보를 일반 설정과 분리하기 위함이다. 즉 Envoy는 istiod와 직접 통신하지 않으며, pilot-agent가 xDS Proxy 역할을 수행한다. - Outbound Traffic (주황색) : App Container가 외부로 보내는 요청은 iptables에 의해 Envoy의
15001Port로 Redirect된 뒤, Envoy의 라우팅을 거쳐 상대 App Pod로 전달된다. - Inbound Traffic (노란색) : 다른 App Pod로부터 들어오는 요청은 iptables에 의해 Envoy의
15006Port로 Redirect된 뒤, App Container의8080Port로 전달된다. - DNS Lookup (초록색) : DNS Capture가 활성화된 경우 App Container의 DNS 질의는 pilot-agent의
15053Port DNS Proxy로 Redirect되어 처리된다. 이때 DNS Proxy가 사용하는 Hostname 정보가 istiod로부터 NDS를 통해 전달되며, NDS가 Envoy로 중계되지 않고 pilot-agent에서 소비되는 이유이다. - Metrics 수집 (파란색) : Prometheus Server는 pilot-agent의
15020Port/stats/prometheus하나만 Scrape한다. pilot-agent는 Envoy의15090Port/stats/prometheus와 App Container의8080Port/metrics를 함께 수집하여 병합된 Metrics를 제공한다. - Health Check (빨간색) : kubelet은 Envoy의
15021Port/healthz/ready로 istio-proxy Container의 Health Check를 수행하며, Envoy는 이 요청을 pilot-agent의15020Port/healthz/ready로 전달한다. - Envoy Admin (검정색) : istioctl은 Envoy의
15000Port Admin Interface에 접근하여 Envoy에 적용된 설정과 상태를 확인한다.istioctl proxy-config명령어가 이 경로를 통해 Listener, Route, Cluster 등의 설정을 조회하는 대표적인 예이다.
이처럼 Envoy가 istiod와 직접 통신하지 않고 pilot-agent를 xDS Proxy로 경유하는 이유는 다음과 같다.
- 인증 위임 : Envoy가 istiod와 mTLS로 통신하려면 인증서가 필요하지만, 그 인증서는 다시 istiod로부터 발급받아야 하는 순환 문제가 존재한다. pilot-agent가 Pod의 Service Account Token을 이용해 CSR (Certificate Signing Request)을 생성하고 istiod CA로부터 인증서를 발급받은 뒤 SDS Socket으로 Envoy에 공급하는 방식으로 이 문제를 해결하며, 인증서 갱신도 pilot-agent가 담당하므로 Envoy는 인증서 수명 주기를 신경 쓰지 않아도 된다.
- xDS 변조 : pilot-agent는 istiod가 내려준 xDS 설정을 단순히 중계하는 것이 아니라 중간에서 변조할 수 있다. 예를 들어 istiod가 “원격 저장소에서 Wasm 필터 모듈을 다운로드해서 사용하라"는 설정을 내려주면, pilot-agent가 모듈을 대신 다운로드해 두고 설정 안의 원격 주소를 로컬 파일 경로로 바꿔서 Envoy에 전달한다. Envoy는 로컬 파일만 읽으면 되므로, 저장소 인증이나 다운로드 실패 처리 같은 복잡한 일은 모두 pilot-agent가 담당한다.
- istiod 장애 대응 : pilot-agent는 istiod로부터 받은 마지막 설정을 캐시하고 있어, istiod 장애 중에도 Envoy가 재연결하면 캐시된 설정으로 응답할 수 있다. Envoy 입장에서 xDS Server는 항상 로컬의 pilot-agent이므로, Control Plane 장애가 Data Plane의 동작에 바로 전파되지 않는다.