Introduction
Istio Ambient mode에 대한 요약이다. (비공식적으로) Sidecar-less mode로도 불리는 Istio Ambient mode는 최근에 와서야 베타 버전이 된 기능이지만, Istio 전반의 구조 변경과 함께 상당한 성능 향상을 이끄는 중요 업데이트이다.
Summary
•
Ambient mode는 Sidecar mode 하의 Istio 기능을 계승하면서, 더 빠르고 더 적은 리소스를 사용한다. 특히 메모리 사용량 개선은 극적이다.
•
Ambient mode에서는 DaemonSet 인 Ztunnel(L4 대응)과 Deployment 인 Waypoint (L7 대응)가 Istio-proxy sidecar를 대신한다.
•
Waypoint 는 Kubernetes Gateway API의 Gateway 를 통해 Namespace 단위로 생성하는 것이 기본이다. 이는 Waypoint 가 특정 workload 군에 대한 gateway 역할도 함께함을 의미한다.
Why Ambient mode? (over Sidecar mode)
Ambient mode의 목표는 Sidecar mode 하의 Istio 기능 계승과 함께(공식 문서의 두 번째 단락 참조. “mixed mode에 대한 seamless interoperation”은 이를 암시한다), 전체적 구조 변경을 통한 전반의 성능 개선으로 보인다.
왜 Ambient란 이름이 붙었는지는 모르겠는데 어쨌건 Sidecar-less란 비공식 명칭에서 이를 더 유추하기가 좋다. Sidecar mode의 단점(app과의 lifecycle coupling, 중복 및 사전 예약 resource 요구 등)을 제거한 무엇이겠다는 생각으로 자연스럽게 이어지기 때문이다.
아래 링크는 Sidecar mode에 비해 더 작은 duration, 더 적은 리소스로 동작한다는 제 3자의 테스트 결과로, 특히 메모리 사용량 개선은 극적이다.
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 감소 효과가 크기 때문으로 정리되는 듯.
이는 무엇보다 (sidecar로 인해) app pod 마다 운용되던 xDS config가, Istio 전용 components에서 각 namespace 별로만 운용되는 최적화 효과 때문으로 보인다. 아래 링크는 이에 대한 상세 설명이고, Appendix: Istio sidecar의 memory 과다 사용 이슈에 관하여 는 관련 내용이다.
Ambient mode에서의 Istio 구조
맨 앞의 그림은 Ambient mode에서의 Istio 구조로 푸른 색 box가 Istio component이다. 이중 짙은 푸른색이 Sidecar mode의 Istio proxy 를 대체하는 components로, 둘(Ztunnel, Waypoint)로 나뉘어 hop이 하나 더 늘어난 점에 주목해야 한다. 나뉜 이유에 대해서는 Gateway로서의 Waypoint 에서 별도로 논한다.
모든 pod 간 통신은 Ztunnel 을 통하고(node 내외 불문), L7 기반 로직 처리 필요 시 Waypoint 를 경유한다.
Ztunnel , Waypoint 공통
•
xDS config, X.509 인증서 sync: Sidecar mode의 Istio-proxy 와 동일하게 istiod 로부터 sync.
•
Policy / telemetry 적용 지점: Ztunnel 은 L4에서, Waypoint는 L7에서.
Ztunnel : L4 proxy in Node level
•
DaemonSet으로 동작.
•
•
Waypoint : L7 proxy in Namespace level
•
Deployment 으로 동작
•
Workload 측에서 등록(enroll): workload에 istio.io/use-waypoint label을 적용하여 Waypoint 를 등록한다. 적용 가능한 workload는 Namespace , Service 또는 Pod 이다(참조).
•
Traffic Management: Sidecar mode와 동일. 참고로 LB의 경우 source 측 Ztunnel 에 의해 Waypoint pod를 찾기 위해서도 발생하므로, Waypoint 사용 시 LB는 2번 발생한다(참조).
•
Destination 기반 정책: 모든 정책은 destination Waypoint 에 적용된다(source Waypoint 란 것은 없음).
◦
참고로, Sidecar mode에서는 타 정책과는 달리 VirtualService, DestinationRule 이 source Istio-proxy 에 적용한다.
•
Envoy(C++) 기반: Sidecar mode와 동일
Gateway로서의 Waypoint
사실 Waypoint 의 의미는 sidecar mode의 단점 제거보다는 “동종 workload에 대한 Gateway 계층 추가”란 아키텍처링이 더 커보인다.
이는 두 가지 사실에 근거하는데, Waypoint 생성에 Kubernetes Gateway API의 Gateway resource가 사용된다는 점과, Istio의 주요 설계자 중 하나이자 (나도 주요 참조 문서로 본) Istio in Action 저자인 Chistian Posta의 아래 글 때문이다. 이들이 아니라면 굳이 hop을 늘릴 필요가 없어 보이는 점은 덤.
여기서 그는 waypoint란 용어 소개와 함께 Ambient mode와 매우 유사한 아키텍처를 이미 제시했다(I’ve started calling this the “waypoints” architecture; 이 포스트는 2019년 10월에 쓰였으니, Ambient Mesh가 공표되기 3여년 전이다). 그리고 이 아키텍처의 목적은 소위 “Death Star Architecture” 방지임을 밝힌다.
Death Star Architecture가 구체적으로 무슨 문제?
Death star architecture가 복잡해 보인다는 것 이외에 무슨 무슨 문제냐 싶어 보이는데, 아마도 관리적 관점에서의 이슈인 듯 싶다. 복잡한 만큼 (다양한 층위에서) 정책 적용이 어려워진다.
이 관점에서 보면 Ambient mode는 이 architecture의 해결안인 도메인 분리, 특히 도메인 수준의 PEP(Policy Enforcement Point)를 명시화한다는 부가 가치를 지닌다.
아래는 이 관점에서의 Waypoint 운용 구조와 설명이다.
다층 Gateway 구조를 보이기 위해 (North-South) Gateway를 추가했다.
•
Gateway Kubernetes API로 Waypiont 생성
◦
기존 North-South Gateway와 마찬가지로, GWAPI(Kubernetes Gateway API)의 Gateway resource를 사용하여 Waypoint 를 생성한다.
•
Multi-tier Gateway 구조
◦
1차는 North-South Gateway, 2차는 Waypoint Gateway (for East-West traffic)
◦
동종 workloads(e.g. Namespace) 별 단일 Waypoint 를 운용하며, 모든 서비스 간 호출은 Waypoint 를 통한다.
◦
각 도메인 별 traffic 분리가 자동으로 발생(sidecar mode의 namespace isolation 불필요). Death Star architecture 사전 방지한다.
Istio의 North-South Gateway의 traffic 전달에 관하여
24.06.10 현재, 위 그림과는 달리 Istio의 North-South Gateway는 Waypoint 가 아닌 service pod로 traffic을 직접 전달한다(istiod 에 의해 모든 pod에 대한 xDS config가 sync됨을 의미).
이는 아마도 Sidecar mode와의 호환성 때문인 것으로 보이는데, 이 경우 이 Gateway는 또다시 namespace isolation이 필요하다는 뜻임과 동시에 multi-tier Gateway 구조에도 맞지 않는다.
다행히도 본 동작은 초기 버전에 한정한다고 한다.
본 건 관련한 Istio 관리자(John Howard)와의 Q&A
Waypoint as a North-South Gateway
24.06.10 현재, Waypoint 자체로 mesh 외부 traffic 수신의 North-South Gateway 역할은 불가능한데, Multi-tier Gateway가 불필요하거나 North-South Gateway 역할을 다른 router(e.g. AWS ALB)에 맞기는 경우 난감해진다. 나아가 Waypoint 는 타 namespace pod 관점에서 보면 (East-West)가 아닌 North-South Gateway로도 볼 수 있다.
다행히 이 기능 역시 앞으로 넣을 예정으로, 나아가 Ingress controller로도 동작하게 할 예정이라고 한다. 현재 안되고 있는 이유는 타 ingress controller와는 달리 AWS ALB는 Istio mTLS가 동작하지 않기 때문이라고.
본 건 관련한 Istio 관리자(John Howard)와의 Q&A
기타
•
eBPF 사용 여부 무관(?): 알파 버전에는 eBPF 모드가 있어, 이를 통해 istio-cni app pod와 Ztunnel pod 간 traffic 중계를 담당했으나(via host network namespace, 참조), 구조 변경(host network namespace 경유 없음)을 통해 본 과정이 사라졌다. 구조 변경 목적은 광범위한 CNI 지원이라고.
•
References
IstioCon 2023
https://www.youtube.com/playlist?list=PL7wB27eZmdffVBMSaXzXz02mZb3gZWlsi
여럿이 있지만 역시나 Ambient Mesh에 많은 초점이.
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and Istio - Download as a PDF or view online for free
https://www.slideshare.net/slideshow/comparing-sidecarless-service-mesh-from-cilium-and-istio/266921590
또다른 Sidecar-less Service Mesh인 Cilium과의 구조적 비교. Linkerd로 시작되는 Service Mesh 역사(?)도 함께
Sidecarless eBPF service mesh sparks debate | TechTarget
Cilium proposes a sidecarless eBPF-based service mesh, while Linkerd maintainers question its security, and Istio's Ambient Mesh charts a middle course.
https://www.techtarget.com/searchitoperations/news/365535362/Sidecarless-eBPF-service-mesh-sparks-debate
service mesh 방식 논쟁(cilium vs istio vs Linkerd, Ambient Mesh 포함).. 한줄 결론 - 각자 자기가 짱이다.
- Cilium: eBPF 사용, sidecar 없애므로 내가 짱이다.
- Linkerd: sidecar 없애면 격리에 문제가 있다.
- Istio: Ambient Mesh도 sidecar 없고 eBPF 사용한다.