Ambient Mode란

[ 설명 ]
- Ambient mode는 Sidecar mode보다 "더 빠르고 더 적은 리소스"를 사용

- L4와 L7 기능을 분리해서, 필요한 만큼만 리소스를 사용하는 것

Architecture

ztunnel (Zero Trust Tunnel)

[ 설명 ]
- "노드"마다 DaemonSet으로 배포되는 "경량 L4 프록시"
- Rust로 작성되어 Envoy보다 휠씬 가벼움
- 같은 노드의 "모든 Pod 트래픽"을 대신 처리 -> 리소스 효율이 좋음

[ 담당 역할 ]
- mTLS 암호화/복호화 (SPIFFE 인증서 기반)
- L4 AuthorizationPolicy
- L4 텔레메트리 (TCP 메트릭)
- HBONE(HTTP-Based Overlay Network) 터널링

Waypoint Proxy

[ 설명 ]
- L7 기능이 필요할 때만 "배포"하는 Envoy 기반 프록시
- Namespace 단위로 Deployment로 배포되고, 필요에 따라 HPA로 스케일링이 가능
	=> "자신이 보호할 워크로드의 NS에 배포"

[ 담당 역할 ]
- VirtualService
- DestinationRule
- L7 AuthorizationPolicy
- L7 텔레메트리

[ 헷갈린 점. NS에 따른 설정 ]
1. 단일 NS인 경우
	order -> ztunnel -> Waypoint -> payment
	payment -> ztunnel -> Waypoint -> order
=>
	- 이 경우는 하나의 Waypoint를 사용

2. NS가 분리된 경우
	order(ns-a) -> ztunnel -> ns-b의 Waypoint -> payment(ns-b)
	payment(ns-b) -> ztunnel -> ns-a의 Waypoint -> order(ns-a)
=>
	- 이 경우는 Destination Waypoint를 거침
	- 이를 통해 Waypoint에 "자신의 정보만" 담으면 되니 리소스 효율이 좋음
		=> 상대방은 내 정보를 알 필요가 없어짐

Istiod

[ 설명 ]
- Sidecar mode와 동일하게 xDS 설정을 ztunnel과 Waypoint에 내려줌
- 인증서 발급(CA 역할)도 동일

Sidecar vs Ambient 비교

[ 리소스 측면 ]
- Sidecar는 "Pod 수 x Envoy 리소스"만큼 소비
- Ambient는 "노드 수 x ztunnel + 필요한 만큼의 Waypoint"만큼 소비

[ 운영 측면 ]
- Sidecar는 주입을 위해 "Pod 재시작"이 필요, Envoy 업그레이드 시에도 "Pod 롤링 재시작" 필요
- Ambient는 "네임스페이스 레이블"만 붙이면 되고, ztunnel이나 Waypoint 업그레이드가 영향 X

[ 정책 적용 위치 ]
- Sidecar 모드에서 VirtualService/DestinationRule은 "source측 Envoy에 적용"
- Ambient 모드에서는 "destination측 Waypoint에 측정"