Istio 2편: Envoy config로 해부하는 Ambient mode

Istio Ambient mode 도입기 2편으로, 1편에서 개념으로만 설명한 HBONE과 트래픽 리다이렉션이 실제 Envoy config에 어떻게 구현돼 있는지 들여다본다. HTTP 요청 하나가 Istio Gateway에서 Pod까지 전달되는 과정을 Listener부터 Route, Cluster, Endpoint 순으로 추적하며, 목적지 Pod의 mesh 참여 상태에 따라 같은 클러스터인데도 endpoint 설정이 완전히 달라지는 지점을 짚는다.

핵심 포인트

Istio의 Gateway·Sidecar·Waypoint는 역할로 구분되지만 실제로는 서로 다른 설정이 주입된 같은 Envoy Proxy다.
세 케이스(mesh 밖, mesh 안, waypoint 있음) 모두 같은 클러스터를 쓰지만 endpoint의 메타데이터와 transport socket 설정에 따라 트래픽 경로가 완전히 갈린다.
mesh 안 목적지의 endpoint 주소는 실제 네트워크 주소가 아니라 Envoy 내부 user space의 internal listener를 가리킨다.
HBONE의 실체는 internal listener로 넘긴 뒤 hostname을 HTTP/2 CONNECT의 대상으로 삼고 ALPN h2와 SPIFFE ID 기반 mTLS를 씌우는 조합이다.
ztunnel이 Pod 트래픽을 가로챌 수 있는 핵심은 ztunnel이 Pod의 네트워크 네임스페이스 안에 직접 소켓을 생성한다는 데 있다.

상세 정리

Envoy 처리 순서: Listener가 특정 포트에서 트래픽을 받아 어떤 Filter Chain으로 처리할지 정하고, Route가 Virtual Host 기반으로 어떤 Cluster로 보낼지 결정하며, Cluster는 같은 서비스를 제공하는 endpoint들의 논리적 그룹으로 로드밸런싱 정책을 갖고, Endpoint가 최종 목적지다.
이 설정들은 istiod가 xDS API로 각 Envoy에 전파하며, Pod 추가·삭제나 라우팅 정책 변경 등 클러스터 상태가 바뀔 때마다 갱신된다.
채널팀 구성: Public Internet 요청이 AWS ALB에서 Istio Gateway를 거쳐 Istio Waypoint를 지나 목적지 Pod에 도달한다.
이건 Ambient mode의 기본 동작이 아니다. 기본 설정에서 north-south 트래픽은 Gateway에서 목적지 Pod의 ztunnel을 통해 Pod으로 직접 가고, waypoint는 본래 in-mesh Pod 간 east-west 트래픽에 L7 정책을 적용하는 컴포넌트다.
굳이 경유시킨 이유: 기본 동작을 쓰면 public 트래픽과 in-mesh 트래픽의 routing policy가 Gateway와 Waypoint 두 곳에서 각각 적용돼, 동일 서비스의 라우팅 정책을 중복 관리하는 인지 부하가 생긴다고 판단했다.
그래서 Gateway는 hostname 매칭 같은 edge 역할만 맡고 routing policy와 L7 정책은 모두 waypoint에서 통합 관리하도록 역할을 나눴다. 이를 위해 Gateway에 명시적 레이블을 추가해야 한다.
1단계 Listener: 리스너가 HTTP 요청을 받고 Filter Chain의 HTTP connection manager가 RDS로 route config를 동적으로 받아온다. Route config의 Virtual Host 목록에서 요청 Host 헤더와 매칭되는 것을 찾아 해당 Cluster로 라우팅한다.
클러스터 이름은 Istio가 자동 생성하는 convention으로 outbound|{port}||{service}.{namespace}.svc.cluster.local 형태를 따른다.
케이스 1 mesh 밖: endpoint의 실제 주소를 그대로 써서 Pod IP로 직접 연결한다. transport socket 매칭 키가 없어 default인 RawBuffer가 적용되고, HBONE 터널링 없이 plaintext로 전달되며 internal listener를 거치지 않는다.
케이스 2 mesh 안: endpoint 주소가 envoy_internal_address 형태로 특정 internal listener를 가리킨다. 트래픽이 네트워크 밖으로 나가는 게 아니라 Envoy 내부의 다른 listener로 전달된다는 뜻이다.
이때 특별한 transport socket이 선택돼 tunnel 네임스페이스의 메타데이터를 internal listener로 전달하고, 그 덕에 실제 destination 주소가 internal listener까지 도달한다.
케이스 3 waypoint 있음: 기본 구조는 mesh 안과 같지만 메타데이터에 waypoint 정보가 더해진다. 최종 Pod 선택은 waypoint가 담당하므로 Gateway는 목적지를 특정하지 않고, 결과적으로 Gateway → HBONE → waypoint → HBONE → 목적지 Pod 순으로 흐른다.
internal listener의 정체: 일반 listener와 달리 네트워크 포트를 열지 않고 Envoy 내부 user space에서만 동작한다. 앞에서 전달된 메타데이터를 읽어 hostname을 HTTP/2 CONNECT 요청의 대상으로 삼는다.
이 클러스터는 EDS를 쓰지 않고 다운스트림 connection 메타데이터로부터 upstream host를 동적으로 결정하며, 포트를 ztunnel의 HBONE 수신 포트로 override한다. transport socket에는 ALPN h2와 SPIFFE ID 기반 mTLS가 적용된다.
waypoint 경유 시에는 필터가 추가로 붙어 endpoint에서 전달한 메타데이터를 읽고 destination address를 waypoint 주소로 동적 override한다. 이때 CONNECT 대상에는 원래 의도한 목적지가 설정돼 waypoint가 이를 보고 최종 Pod으로 라우팅한다.
결론적으로 1편에서 "HBONE은 Envoy의 기존 기능들을 조합한 것"이라 한 그 조합의 정체가 internal listener 전달, HTTP/2 CONNECT 터널, ALPN h2와 SPIFFE mTLS 세 가지임을 config로 확인한 셈이다.
리다이렉션 메커니즘: ztunnel은 Pod와 별개의 DaemonSet인데 Pod의 트래픽을 가로챌 수 있는 이유는 Pod의 네트워크 네임스페이스 안에 직접 소켓을 생성하기 때문이다.
세 컴포넌트가 협력한다. istio-cni 바이너리가 체인드 CNI 플러그인으로 설치돼 Pod 생성 이벤트를 감지해 node agent로 전달하고, node agent가 Pod 네트워크 네임스페이스에 진입해 iptables 규칙을 설정한 뒤, Unix Domain Socket으로 ztunnel에게 Pod 정보와 네트워크 네임스페이스 파일 디스크립터를 넘긴다.