이 게시물은 채널팀이 Istio를 프로덕션에 도입하면서 Sidecar mode 대신 GA된 Ambient mode를 선택한 이유와 동작 원리를 정리한 내용입니다. Service mesh 도입 목적은 네트워크 가시성, 정교한 카나리 배포, 분산 트레이싱, 트래픽 매니지먼트, 서킷 브레이킹, (선택적) mTLS를 통합 제공하는 데 있음 Ambient mode는 ztunnel(노드당 1개, L4)과 waypoint(네임스페이스/서비스 단위, L7)로 구성되며 sidecar 방식과 달리 선택적으로 L7 라우팅과 정책 처리를 수행함 Sidecar 방식의 control plane 확장성 문제, Pod마다 Envoy 리소스가 누적되는 data plane 낭비 문제를 Ambient가 완화하는 설계를 채택함 Ambient mode는 ztunnel·waypoint·HBONE을 통해 mTLS 기반의 안전한 통신과 트래픽 캡슐화(HBONE) 및 iptables 기반 traffic redirection으로 서비스 메시 정책을 적용함 단점으로는 ztunnel/waypoint 장애 시 영향 범위 확대, 새로운 구성요소 학습과 디버깅 난이도 상승, GA 직후 성숙도 낮음 등 운영 부담이 존재함