01 · 왜 Istio Ambient mode인가 — 사이드카를 건너뛴 선택 (2026-03)

이 챕터의 01 서비스 메시와 Istio 기초부터 09 istiod 스케일링과 xDS 커넥션 재분배까지는 전부 Sidecar mode를 전제로 쓰인 문서입니다. 파드마다 Envoy가 붙고 istiod가 그 프록시 전부에 xDS를 밀어 넣는 구조를 깔고 갑니다. 이 ambient/ 하위 섹션은 그 전제 자체를 바꾼 팀의 기록입니다.

채널코퍼레이션 DevOps팀은 서비스 메시를 처음 도입하면서 이미 검증된 Sidecar mode 대신 Ambient mode를 택했습니다. 4,000개 파드라는 확정된 규모 앞에서 사이드카의 단가 계산이 맞지 않았기 때문입니다. 이 문서는 그 의사결정의 근거를 정리합니다. 결정 이후 팀이 새로 배워야 했던 Ambient의 구성요소(ztunnel · waypoint · istio-cni)와 프로토콜(HBONE), 트래픽 리다이렉션이 걸리는 방식도 함께 다룹니다.

시리즈는 세 편으로 나뉩니다. 1편(이 문서)이 도입 배경과 선택 이유, 2편이 Envoy config로 들어가는 기술 상세, 3편이 프로덕션 운영 중 만난 문제와 해결입니다.

1. 왜 서비스 메시였나

채널팀이 서비스 메시에서 얻으려던 핵심 목표는 이렇습니다.

여기에 덤으로 기대한 것이 Distributed Tracing, Traffic Management, Circuit Breaking, mTLS·상호 인증입니다.

원문이 스스로 인정하듯 개별 기능만 놓고 보면 서비스 메시가 필수는 아닙니다. 트레이싱은 라이브러리로, 카나리는 배포 도구로, mTLS는 애플리케이션 레벨로도 어느 정도 됩니다. 서비스 규모가 늘고 인프라도 계속 커지는 상황을 보면 이 기능들을 한 레이어에서 묶어 제공하는 쪽에 투자하는 편이 길게 봐서 맞다고 판단했습니다. 메시가 무엇을 대신 해주고 그 대가가 무엇인지는 01 서비스 메시와 Istio 기초에 있습니다.

2. 왜 Istio였나 — Linkerd와 Cilium을 놓은 이유

Istio 외에 Linkerd와 Cilium도 검토했습니다.

Cilium을 뺀 것은 기능 문제가 아니었습니다. 이미 다른 CNI를 쓰고 있었고 메시 하나 때문에 CNI를 갈아엎는 결정은 메시 도입보다 훨씬 큰 변경입니다.

3. Sidecar를 건너뛴 세 가지 이유

Istio를 고른 뒤 남은 질문은 “Sidecar냐 Ambient냐"였습니다. 채널팀은 이런 근거로 Ambient를 골랐습니다.

3.1 컨트롤 플레인 — polynomial scaling problem

Sidecar mode에서는 모든 사이드카가 메시 안 다른 모든 destination의 정보를 알아야 합니다. 그래서 destination 하나의 설정이 바뀌면 그 변경을 모든 사이드카에 전파해야 합니다. 설정의 크기와 전파 대상의 수가 함께 커지면서 부하가 비선형으로 증가합니다. 원문은 이를 polynomial scaling problem이라 부릅니다.

Ambient mode에서 전파 대상은 ztunnel과 waypoint입니다. ztunnel은 노드당 1개, waypoint는 필요한 namespace·service에만 있으므로 전파 대상 자체가 몇 자릿수 줄어듭니다.

istiod가 CPU를 먹는 메커니즘은 02 컨트롤 플레인 해부: istiod가, 스케일아웃해도 xDS 커넥션이 재분배되지 않는 문제는 09 istiod 스케일링과 xDS 커넥션 재분배가 다룹니다. Ambient는 그 부하에서 프록시 수라는 항을 직접 줄이는 접근입니다.

3.2 데이터 플레인 — 4,000 파드에 붙는 프록시의 단가

채널팀은 약 4,000개 Pod을 운영 중입니다. Istio 공식 성능 문서 기준과 채널팀 자체 측정값은 이렇습니다.

같은 1,000 RPS를 처리할 때 ztunnel의 CPU는 사이드카의 약 1/3, 메모리는 약 1/5입니다. 그런데 차이를 더 크게 벌리는 건 개수 쪽입니다. 4,000개 파드에 모두 사이드카를 붙이면 idle 상태에서만 수십~수백 vCPU와 약 240Gi 메모리가 순수하게 프록시에 소모됩니다(60Mi × 4,000 ≒ 240Gi). RPS가 낮은 파드에도 idle 오버헤드는 붙기 때문에 파드가 수천 개 단위면 이 고정비가 전체를 지배합니다.

Ambient mode에서는 ztunnel이 노드당 1개, waypoint가 namespace·service 단위입니다. 파드가 늘어도 프록시 수가 그만큼 늘지 않습니다.

3.3 Kubernetes Gateway API 지원

Kubernetes의 Ingress 리소스는 freeze되었고 Gateway API가 새로운 표준으로 자리잡는 중입니다. Istio 팀도 이 흐름에 맞춰 Gateway API를 기본 옵션으로 채택하는 쪽으로 움직였습니다. 공식 문서도 Gateway API 기준으로 쓰이기 시작했습니다.

Gateway API 자체는 Sidecar mode에서도 쓸 수 있습니다. 그런데 Ambient mode의 공식 문서가 처음부터 Gateway API 기준으로 작성되어 있어서 Ambient와 함께 도입하는 편이 자연스러웠다고 채널팀은 판단했습니다.

4. 그래도 Ambient는 비싸다 — 인정한 세 가지 단점

채널팀은 Ambient의 단점을 빠짐없이 나열한 뒤 선택했습니다.

• Sidecar mode에서는 프록시가 파드와 lifecycle을 같이 해 장애 범위가 각 파드에 그칩니다. Ambient는 ztunnel(노드 단위)과 waypoint(namespace·service 단위)에 의존하므로 장애 시 노드 전체 혹은 namespace 전체로 영향이 번집니다. Sidecar mode에는 없던 SPoF(Single Point of Failure)가 생깁니다.
• ztunnel · waypoint · HBONE 같은 새 개념을 익혀야 하고 프록시와 hop이 늘어난 만큼 문제 원인 추적이 까다롭습니다.
• GA 직후라 프로덕션에서 검증된 사례가 적었고 Sidecar mode와 기존 Istio API(예: VirtualService)에 비해 덜 성숙합니다.

팀 내 의사결정

원문은 팀 논의에서 나온 발언을 싣습니다.

“2~3년 동안은 건드리지 않을 걸 선택하고 싶음. 차라리 시간을 들이고 깊게 고민해서 결정했으면 좋겠음.”

“네트워크 트래픽에 대한 조작과 가시성이 핵심임. 그것만 잘 되면 Ambient mode도 상관없음. 대신 버그나 안정성이 걸리긴 함.”

“리소스 측면 제외하고는 Sidecar 장점이 많아 보이는데, 다양한 기능을 사용하지 않을 거면 Ambient. 문제 발생 빈도보다는 장애 복구 속도에 집중해야 함.”

세 발언을 관통하는 기준은 “장애가 안 나는 쪽"이 아니라 “나중에 다시 갈아엎지 않아도 되는 쪽” 입니다. 채널팀은 Sidecar mode로 도입한 뒤 다시 Ambient로 마이그레이션하는 상황을 피하고 싶었습니다. 팀 내 Istio·Envoy 이해도를 높이면서 리서치를 이어 가는 쪽으로 Ambient를 택했습니다.

이 결정이 성립한 전제는 세 번째 발언에 드러난 “다양한 기능을 다 쓰지는 않는다” 였습니다. 필요한 것이 L7 가시성과 트래픽 통제 정도라면 Ambient의 기능 공백이 크게 문제되지 않습니다. 반대로 기존 Istio API의 세밀한 기능(예: EnvoyFilter 기반 확장)에 이미 깊게 의존하는 조직이라면 같은 계산이 나오지 않습니다. 이 단서는 원문에 없는 보충입니다.

5. Ambient mode의 구성요소

5.1 컨트롤 플레인 — istiod가 내려보내는 것

istiod가 xDS API로 설정을 전파한다는 구조는 Sidecar mode와 같습니다. 다른 것은 전파 대상입니다. 파드마다 실행되는 사이드카 프록시 대신 ztunnel과 waypoint가 xDS 클라이언트입니다.

istiod가 내려보내는 것은 이렇습니다.

5.2 데이터 플레인 — ztunnel과 waypoint의 역할 분담

Ambient의 데이터 플레인은 L4와 L7을 두 컴포넌트로 쪼갭니다.

waypoint가 처리하는 L7 정책으로 원문이 명시한 것은 AuthorizationPolicy · RequestAuthentication · WasmPlugin · Telemetry입니다. waypoint를 enable하면 그 범위에 해당하는 트래픽은 모두 waypoint를 거쳐갑니다.

waypoint는 source·destination 파드와 같은 노드에 있을 필요가 없습니다. 사이드카가 파드와 같은 네트워크 네임스페이스에 있던 것과 달리 waypoint는 위치가 자유로운 별도 배포입니다. hop이 하나 더 늘고 그 hop은 노드 경계를 넘을 수 있습니다. 디버깅 난이도가 올라가는 이유 중 하나입니다.

L7을 켠 곳에만 두므로 L4 mTLS만 필요한 대다수 워크로드는 waypoint 비용을 내지 않습니다. 사이드카 모드에서는 모든 파드가 L7 프록시 기능 전체를 짊어졌습니다.

5.3 워크로드의 세 가지 상태

Ambient에서 워크로드가 놓일 수 있는 상태마다 트래픽 경로가 다릅니다.

**메시 미참여(out-mesh)**는 기존 쿠버네티스 네트워크(kube-proxy) 동작 방식과 동일합니다. 서비스 디스커버리를 거쳐 엔드포인트로 직접 연결됩니다.

메시 참여 · waypoint 없음에서는 파드에서 나가는 트래픽이 ztunnel로 투명하게 리다이렉트되고 destination이 메시 안에 있으면 ztunnel이 암호화된 HBONE 채널로 실어 보냅니다. 들어오는 트래픽도 해당 노드의 ztunnel을 거치며 AuthorizationPolicy에 위배되지 않는 한 파드로 전달됩니다.

메시 참여 · waypoint 설정에서는 ztunnel과 destination 사이에 waypoint가 끼어 L7 정책을 적용합니다.

메시 미참여 상태는 kube-proxy 경로 그대로라서 점진적 도입의 근거가 됩니다. namespace 단위로 하나씩 메시에 넣어도 나머지는 그대로입니다.

6. HBONE — 표준 세 개의 조합

HBONE은 HTTP-Based Overlay Network Environment의 약자입니다. 원문은 이미 검증된 표준을 Envoy config로 조립했다는 점을 강조합니다.

HTTP CONNECT 메서드로 터널을 열고 그 위에 TLS를 씌운 것이 HBONE입니다. L4 페이로드를 이 조합으로 캡슐화하므로 애플리케이션 트래픽의 원본을 바꾸지 않으면서 프록시가 처리할 수 있습니다.

HBONE 터널링과 traffic redirection이 Envoy listener·cluster 수준에서 어떻게 구현돼 있는지는 2편 — Envoy config로 해부하는 Ambient mode가 이어 다룹니다.

7. Traffic redirection — 15001 · 15006 · 15008

Ambient에서 “투명하게 리다이렉트된다"는 것은 istio-cni가 삽입한 iptables 규칙을 말합니다. 리다이렉트는 모두 파드 네트워크 안에서 일어나고 host(node) side에서는 일어나지 않습니다.

리다이렉트 규칙은 세 갈래입니다.

아웃바운드 트래픽은 egress 처리를 받도록 ztunnel의 port 15001로 리다이렉트되고 그다음 ztunnel이 HBONE으로 캡슐화해 목적지로 보냅니다.

인바운드 분기는 source port로 나뉩니다. 상대 ztunnel이 HBONE으로 보낸 트래픽은 source port가 15008이므로 이 조건 하나로 “이미 메시 안에서 감싸여 온 트래픽"과 “메시 밖에서 온 평문"을 구분합니다.

7.1 “in-pod ztunnel"이라는 이름

Istio 공식 문서는 이 구조를 in-pod ztunnel이라 부르는데, 이 이름 탓에 ztunnel이 파드 안에 들어 있는 것처럼 읽힙니다. ztunnel은 워크로드 파드와 별개의 DaemonSet 컨테이너입니다. istio-cni가 iptables에 주입하는 규칙은 트래픽을 ztunnel 컨테이너로 보내지 않습니다. 파드의 container network namespace 안에 생성된 TCP socket(localhost의 port 15001 · 15006 · 15008)으로 REDIRECT합니다.

7.2 우회하면 정책도 함께 사라진다

리다이렉트 규칙을 어떤 이유로든 우회하면 트래픽은 그냥 나갑니다. ztunnel을 우회하면 메시에서 설정한 모든 Authorization policy 또한 무시됩니다. mTLS만 빠지는 게 아니라 AuthorizationPolicy가 걸어 둔 접근 통제까지 빠진 상태로 요청이 목적지에 도착합니다. 그래서 ztunnel과 istio-cni는 항상 Running 상태여야 합니다.

7.3 partially enrolled pod와 untaint controller

순서 문제가 하나 남습니다. istio-cni가 아직 준비되지 않은 상태에서 파드가 스케줄되면 그 파드는 메시에 불완전(partially)하게 참여하는 상태가 될 수 있습니다.

원문은 이 문제를 방지하는 수단으로 untaint-controller를 언급하고 상세는 3편으로 넘깁니다. 이 섹션에서는 3-2편 — Partially Enrolled Pod와 Untaint Controller로 이어집니다.

Ambient를 실제로 운영하면서 만난 문제들은 3편 시리즈에 나뉘어 있습니다.

이 문서에서 가져갈 것

• 사이드카 비용은 프록시 개수가 파드 개수와 1:1로 묶여 있다는 데서 나옵니다. ztunnel의 1,000 RPS 기준 CPU 1/3·메모리 1/5보다, 프록시 개수가 파드 개수에서 노드 개수로 바뀌는 쪽이 훨씬 크게 작용합니다. 4,000 파드 × 60Mi ≒ 240Gi가 idle에서 그냥 나갑니다.
• Ambient는 파드 단위 장애 격리를 노드·namespace 단위 SPoF와 맞바꾸는 선택입니다. 채널팀의 판단 기준은 “문제 발생 빈도보다 장애 복구 속도"였습니다. 이 기준에 동의하지 않는 조직에는 같은 결론이 나오지 않습니다.
• “투명한 리다이렉트"는 파드 netns 안의 iptables 규칙과 세 개의 localhost socket입니다. 인바운드는 source port가 15008인지로 HBONE(15008)과 plaintext(15006)를 구분하고 아웃바운드는 전량 15001로 갑니다. 진단은 이 동작이 host side가 아니라 파드 안에서 일어난다는 데서 출발합니다.
• ztunnel을 우회하면 암호화와 함께 인가 정책 전체가 빠집니다. ztunnel과 istio-cni를 항상 Running으로 유지해야 하는 이유는 성능이 아닙니다. 보안입니다. istio-cni 준비 전에 스케줄된 파드(partially enrolled)가 대표적 발생 경로입니다.
• HBONE은 HTTP/2 + HTTP CONNECT + mTLS의 조립입니다. 대신 구간이 암호화되어 tcpdump로 안이 안 보이고 destination 측 전체 인터페이스를 캡처해야 합니다.

소스

• 원문: Istio 1편: 왜 Istio Ambient mode인가? (채널코퍼레이션 기술 블로그, 2026-03-20)
• Istio Ambient Mode Reaches General Availability — Istio 1.24 GA 공지
• Istio Performance and Scalability — 사이드카·ztunnel 리소스 기준값
• Ambient Mode Architecture — 구성요소와 동작 원리
• Ambient Data Plane — ztunnel·waypoint 역할 분담
• HBONE — HTTP/2 CONNECT + mTLS 터널
• Traffic Redirection in Ambient Mode — 15001 · 15006 · 15008 리다이렉션
• Istio Architecture (Sidecar) — 비교 대상인 사이드카 구조
• istio/istio — architecture 문서
• Waypoint Proxy Made Simple · CNCF 게재본
• Kubernetes Gateway API
• Untaint Controller — partially enrolled pod 방지