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자의 테스트 결과로, 특히 메모리 사용량 개선은 극적이다.
이는 무엇보다 (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 에서 별도로 논한다.
Ambient mode에서의 Istio 구조
모든 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 사용한다.