title: "Istio Internals: Ambient mode"
description: "Istio Ambient mode에 대한 요약이다. (비공식적으로) Sidecar-less mode로도 불리는 Istio Ambient mode는 [최근](<https://istio.io/latest/news/releases/1.22.x/announcing-1.22/>)에 와서야 베타 버전이 된 기능이지만, Istio 전반의 구조 변경과 함께 상당한 성능 향상을 이끄는 중요 업데이트이다."
cleanUrl: /sw-engineer/istio-ambient-mode
ogImage: "<https://anyflower.notion.site/image/https%3A%2F%2Fprod-files-secure.s3.us-west-2.amazonaws.com%2F7570d2fc-66b1-4e23-bb3c-ff7b56842b0d%2F682a2b35-2f10-48fe-94bf-4faa05d320c5%2FUntitled.png?table=block&id=7d82192b-6c20-4549-942d-26eb590ad07c&spaceId=7570d2fc-66b1-4e23-bb3c-ff7b56842b0d&width=1420&userId=&cache=v2>"
floatFirstTOC: right
Ambient mode에서의 Istio 구조. Ambient mode에서의 Istio 구조 에서 자세히 논한다.
Istio Ambient mode에 대한 요약이다. (비공식적으로) Sidecar-less mode로도 불리는 Istio Ambient mode는 최근에 와서야 베타 버전이 된 기능이지만, Istio 전반의 구조 변경과 함께 상당한 성능 향상을 이끄는 중요 업데이트이다.
참조한 문서는 글 내부 및 References 에 달았다.
DaemonSet 인 Ztunnel(L4 대응)과 Deployment 인 Waypoint (L7 대응)가 Istio-proxy sidecar를 대신한다.Waypoint 는 Kubernetes Gateway API의 Gateway 를 통해 Namespace 단위로 생성하는 것이 기본이다. 이는 Waypoint 가 특정 workload 군에 대한 gateway 역할도 함께함을 의미한다.Ambient mode의 목표는 Sidecar mode 하의 Istio 기능 계승과 함께(공식 문서의 두 번째 단락 참조. “mixed mode에 대한 seamless interoperation”은 이를 암시한다), 전체적 구조 변경을 통한 전반의 성능 개선으로 보인다.
왜 Ambient란 이름이 붙었는지는 모르겠는데 어쨌건 Sidecar-less란 비공식 명칭에서 이를 더 유추하기가 좋다. Sidecar mode의 단점(app과의 lifecycle coupling, 중복 및 사전 예약 resource 요구 등)을 제거한 무엇이겠다는 생각으로 자연스럽게 이어지기 때문이다.
아래 링크는 Sidecar mode에 비해 더 작은 duration, 더 적은 리소스로 동작한다는 제 3자의 테스트 결과로, 특히 메모리 사용량 개선은 극적이다.
LiveWyer | Service Meshes Decoded Part Two: Is Istio Ambient worth it?
<aside> 💡 24.08.09 업데이트: No Istio 모드보다 더 작은 latency의 Ambient mode(?)
아래는 Istio 전체에 대한 단일 blog 페이지(!)로의 요약인데, Ambient mode에서 Istio가 없는 환경에서보다도 latency이 작았다는 결과도 포함한다(해당 글 저자와 Istio의 Lin Sun 모두 이를 이해 못하고 있다고는 한다).
24.08.21 업데이트: latency가 더 작은 이유는 최적화 효과 때문
Latency가 더 작은 이유에 대한 Istio의 Lin Sun의 분석. 대강 hop 추가로 인한 비용보다, 추가된 hop(ztunnel)으로 인한 connection 관리 최적화 및 app의 syscall 감소 효과가 크기 때문으로 정리되는 듯.
Ambient Mesh: Can Sidecar-less Istio Make Applications Faster?
</aside>
이는 무엇보다 (sidecar로 인해) app pod 마다 운용되던 xDS config가, Istio 전용 components에서 각 namespace 별로만 운용되는 최적화 효과 때문으로 보인다. 아래 링크는 이에 대한 상세 설명이고, Appendix: Istio sidecar의 memory 과다 사용 이슈에 관하여 는 관련 내용이다.
Istio Ambient Waypoint Proxy Made Simple
맨 앞의 그림은 Ambient mode에서의 Istio 구조로 푸른 색 box가 Istio component이다. 이중 짙은 푸른색이 Sidecar mode의 Istio proxy 를 대체하는 components로, 둘(Ztunnel, Waypoint)로 나뉘어 hop이 하나 더 늘어난 점에 주목해야 한다. 나뉜 이유에 대해서는 Gateway로서의 Waypoint 에서 별도로 논한다.