title: "Istio overview: Architecture, Traffic Management"
description: |
대표적 Service Mesh 제품인 Istio에 대한 overview로 Kubernetes를 배경으로 설명한다.
이 중 Service Mesh의 개요 및 아키텍처, 그리고 features 중 Traffic Management에 대해 논한다(이후 Istio overview: Observability, Istio overview: Security, Istio overview: Extensibility, Etc.로 이어 진다).
cleanUrl: /sw-engineer/istio-overview-1
ogImage: "<https://anyflower.notion.site/image/https%3A%2F%2Fprod-files-secure.s3.us-west-2.amazonaws.com%2F7570d2fc-66b1-4e23-bb3c-ff7b56842b0d%2Ffa3d962d-1d1d-4f77-af39-42e72bfb487b%2FUntitled.png?table=block&id=9cc519cb-511e-4610-91c6-d60dbe00329d&spaceId=7570d2fc-66b1-4e23-bb3c-ff7b56842b0d&width=1420&userId=&cache=v2>"
floatFirstTOC: right
대표적 Service Mesh 제품인 Istio에 대한 overview로 Kubernetes를 배경으로 설명한다.
이 중 Service Mesh의 개요 및 아키텍처, 그리고 features 중 Traffic Management에 대해 논한다(이후 Istio overview: Observability, Istio overview: Security, Istio overview: Extensibility, Etc. 로 이어진다).
참조한 문서는 글 내부 및 References 에 달았다.
일단, 정의는 Wikipedia에서 가져왔다.
프록시를 사용하여 서비스 또는 마이크로서비스 간 서비스 간 통신을 촉진하는 전용 인프라 계층
Service Mesh는 pod 수준의 L7 traffic 처리를 위한 일종의 overlay network이다. sidecar 등의 기법으로 각 pod에 붙은 proxy가 모든 pod에 대한 in/outbound traffic를 제어함으로, 각종 부가적 features를 추가한다. API Gateway를 cluster 전체에 대한 proxy라 한다면, Service Mesh는 pod에 대한 proxy, 그리고 이들 proxy 간의 연합이라 볼 수 있다.
윗 그림은 앞선 구조 관점의 Istio의 정의를 나타냄과 동시에 Istio가 없는 traffic 흐름과의 차이를 보여준다.
Istio가 없는 상단 traffic은 kube-proxy에 의해 L4에서 routing되는 반면(L4 load balancing), Istio 기반의 하단 traffic은 kube-proxy 없이 L7에서 routing되어(L7 load balancing), kube-proxy 의 개입 없이 destination pod로 직접 전달된다. 참고로 Istio의 default LB algorithm은 Least Request로, 일반적으로 kube-proxy의 random 방식보다 났다고.
Control plane인 istiod 는 앞선 routing에 필요한 pod IP를 포함한 cluster 정보를 각각의 Istio proxy에 동기화함과 동시에 각종 control message를 전달한다.
<aside>
💡 참고: sidecar-less Service Mesh
근래에 sidecar 없는 아키텍처의 Service Mesh가 부각되었는데, Istio는 Ambient Mesh라 하여 Daemon Set(ztunnel)과 Deployment(waypoint)로 envoy proxy의 역할을 나누고, Cilium은 eBPF 기반으로 DaemonSet을 사용한다. 하지만 sidecar만 없을 뿐 개념적으로는 기존과 동일하다.
이 아키텍처의 목적은 sidecar pattern의 리소스 과다 사용, 성능 저하, 아키텍처 복잡도 증대 등의 단점 개선으로, 24.05.13 에 alpha에서 beta로 버전 업데이트되었다.
이에 대해서는 Istio Internals: Ambient mode 에서 다루며, Istio overview 글 전체에서 특별한 언급이 없는 이상 모두 sidecar mode를 상정한다.
</aside>
Service Mesh의 부가 가치는 크게 세 영역, 즉 Traffic Management, Observability, Security로 나눌 수 있으며 이들은 모두 cross cutting concerns에 해당한다. 이들은 그간 app에서 SDK, Monkey patching, bytecode injection, 또는 agent 등을 통해서 구현하거나 아예 이루지 못한 것들이다.
이 cross cutting concerns 제공 관점에서 볼 때, Service Mesh는 이들 기존 방안에 비해 아키텍처에서 특히 우위를 점한다. 아래 그림은 이를 단적으로 표현하는데, 좌측은 Service Mesh를 사용하지 않았을 경우를 우측은 사용했을 경우의 아키텍처를 나타낸다.
Service Mesh를 사용했을 경우(우측)와 그렇지 않을 경우(좌측)의 아키텍처