Istio Ambient Mode 도입, Sidecar 없는 Service Mesh의 세계로!

본문은 Istio Ambient mode가 기존 Sidecar mode의 확장성 문제(Scalability Issue)를 해결하기 위해 설계되었음을 강조한다. Sidecar mode는 Pod 수에 비례하여 Envoy proxy가 증가, Control Plane 부하가 가중된다. 반면 Ambient mode는 ztunnel과 waypoint를 사용하여 Control Plane 부하를 완화(Control Plane Load Reduction)한다. 특히, Ambient mode는 Pod 수 증가에 따른 설정 전파(Configuration Propagation) 부담을 줄여 Polynomial Scaling Problem을 해결한다. 이러한 아키텍처 변화는 Istio의 자원 효율성(Resource Efficiency)을 높이는 데 기여한다.

Ambient mode는 ztunnel(L4)과 waypoint(L7)로 구성되어, 트래픽 처리 책임을 분담한다. Ztunnel은 노드당 1개씩 배치되어 mTLS 터널링(mTLS Tunneling)과 기본 정책을 처리하며, waypoint는 namespace/service 단위로 선택적으로 배치되어 L7 라우팅(L7 Routing) 및 관측 기능을 제공한다. Ztunnel은 istiod와 xDS API를 통해 통신하며, waypoint는 L7 정책 적용을 위해 트래픽을 가로챈다. 이러한 구조는 Sidecar mode 대비 유연한 트래픽 관리(Flexible Traffic Management)를 가능하게 한다.

HBONE(HTTP-Based Overlay Network Environment)은 Istio 컴포넌트 간의 안전한 통신을 위한 핵심 프로토콜(Core Protocol)이다. HTTP/2 CONNECT 메서드와 mTLS를 결합하여 L4 페이로드를 캡슐화하며, Envoy의 기존 기능을 활용한다. HBONE은 애플리케이션 트래픽의 원본 상태를 변경하지 않고 프록시 처리를 수행하여 디버깅 난이도(Debugging Difficulty)를 높이는 단점이 있다. 하지만, HBONE은 Istio 컴포넌트 간의 안전한 통신(Secure Communication)을 보장하며, 서비스 메시의 보안을 강화하는 데 기여한다.

Istio CNI는 iptables 규칙을 조작하여 Pod의 TCP 패킷을 ztunnel로 리다이렉션한다. Pod의 트래픽은 ztunnel을 거쳐 waypoint 또는 외부로 전송되며, 이 과정에서 서비스 메시 정책이 적용된다. Ztunnel은 Pod 내부의 소켓(Socket)으로 트래픽을 리다이렉션하며, istio-cni가 CNI events에 반응하여 네트워크 규칙을 변경한다. 이 구조에서 ztunnel과 istio-cni의 Running 상태 유지(Running State Maintenance)가 중요하며, istio-cni가 준비되지 않은 경우 Pod이 mesh에 불완전하게 참여할 수 있다. 이러한 트래픽 리다이렉션 메커니즘은 Ambient mode의 핵심 기능(Core Functionality)을 담당한다.

Ambient mode는 Sidecar mode에 비해 장애 영향 범위(Failure Domain)가 넓다. Ztunnel 또는 waypoint 장애는 노드 또는 namespace 전체에 영향을 미칠 수 있으며, 디버깅 난이도 또한 높다. 또한, Ambient mode는 Sidecar mode에 비해 성숙도가 낮아(Lower Maturity) 프로덕션 환경에서의 검증 사례가 부족하다. 하지만, Ambient mode는 리소스 절감 효과가 크고, Gateway API 지원 등 미래 지향적인 아키텍처(Future-Proof Architecture)를 제공한다. 따라서, 팀의 요구사항과 환경에 맞는 Service Mesh 솔루션을 신중하게 선택해야 한다.