Introduction
대표적 Service Mesh 제품인 Istio에 대한 overview로 Kubernetes를 배경으로 설명한다.
Istio overview: Architecture, Traffic Management, Istio overview: Observability 및 Istio overview: Security 에 이어, 마지막으로 Istio의 확장성과 타 Service Mesh 제품에 대해 논한다.Summary
•
Istio/Envoy에는 다수의 filter의 연결로 이루어진 Filter chain이 있어, 각 filter를 사용하여 request / response에 대한 다양한 부가적 action을 추가할 수 있다.
•
Envoy에는 다수의 configurable Built-In filters가 있어 별도 프로그래밍 없이도 다양한 요구에 대응이 가능하다.
•
Lua와 WebAssembly(WASM)을 사용하여 Built-In filters 이외의 사용자 정의 기능을 삽입 가능하다.
•
Istio 이외에도 Cilium, Linkerd, Kuma, Consul 등 Service Mesh 제품은 다양하다.
Istio의 확장성에 관하여
Istio에서의 확장은 Istio Proxy에 대한 확장을 의미하는데, 대부분의 Istio proxy 타 기능과 마찬가지로 Envoy에 크게 의존한다. Istio의 역할은 사실 상 Envoy 기능에 대한 interfaces 제공으로, EnvoyFilter 및 WasmPlugin Istio resource가 이들 interface에 해당한다.
Envoy filter chain
Istio의 feature 확장은 Envoy filter를 통해 이루어진다. Envoy에는 다수의 filter의 연결로 이루어진 Filter chain이 있어, 각 filter는 request / response에 대한 변환을 담당한다.
TLS traffic에 대한 Envoy filter chain의 구조
윗 그림은 상기 링크 - Life of a Request에 담긴 다수의 그림 중 filter chain 부분을 압축한 것으로, 각 connection 별 filter chain이 주어져 request/response (종류) 별로 서로 독립적인 처리가 이루어진다.
Envoy filter는 크게 Listener Filter, Network Filter로 나뉘고, Network Filter 중 하나인 HCM(HTTP Connection Manager)는 filter chain 마지막에 위치하여, 자체적으로 다수의 sub-filter, 즉 HTTP filter chain을 가진다. 그리고 HTTP filter chain의 마지막은 Router Filter 로 끝난다.
Built-In filters
Envoy가 자체적으로 제공하는 filter는 다양한 수준에서 filter 종류 별로 매우 많다.
Listener filter 예로는 (Global rate limiting과도 함께 사용되는) Local rate limiting이나 UDP Listener filters가 있고, Network filter에는 Redis나 Kafka와 같은 3rd party 제품 프로토콜에 대한 지원마저 보이며, HTTP filter는 별도로 논할 Lua, WASM filter 를 포함하여 사실 상 Built-in filter이 집중된 부분이다.
아래는 이들(링크) 중 특히 눈에 띈 HTTP filter 예이다.
•
범용: Cache, Echo, Header Mutation, Kill Request, Rate Limit, Stateful session, Tap
•
보안: Basic Auth, CORS, CSRF, Credential Injector, RBAC
•
gRPC: Field Extraction, HTTP/1.1 bridge, gRPC-JSON transcoder
•
AWS/GCP: AWS Lambda, AWS Request Signing, DynamoDB, GCP Authentication
Lua filter
Built-In filter만으로는 해결이 안되는 요구에 대한 두 가지 해결안 중 간편한 방법으로, Envoy는 Lua script를 지원하여 custom 로직 추가를 가능하게 한다. HTTP filter 중 하나로 LuaJIT 상에서 동작한다.
Istio EnvoyFilter via mockserver 에서 예제를 통해 좀더 상세히 다룬다.참고로 바로 아래에서 논할 WASM(WebAssembly)은 일반적으로 성능과 보안을 위해 (불편함을 감수하더라도) 사용되는데, LuaJIT 성능 역시 그리 무시할 상황은 아닌 듯 하다(하기 링크 참고).
So, Envoy will be embedding WebAssembly alongside (or instead of) Lua? Are other... | Hacker News
Are other projects moving from Lua (or other embedded scripting languages) to WebAssembly? What are the benefits of compiling an extension to WASM rather than writing it in Lua?
https://news.ycombinator.com/item?id=22582600
WASM vs Lua: Lua with JIT is very fast even compared to statically typed, compiled languages.
WASM(WebAssembly) filter
custom logic 추가를 위한 두 번째 방법으로, Envoy는 WebAssembly를 L4 대응의 Network filter와 HTTP filter로 지원하며, Istio는 WasmPlugn 을 통해 이들을 각각 지원한다(PluginType 참조).
WebAssembly 특성 상 다수의 언어(e.g. C++, Rust, AssemblyScript(TypeScript), TinyGo)를 지원하고 binary image는 OCI(Open Container Initiative) 호환 가능하기에 일반적인 Container registry에 등록 역시 가능해 보인다. WasmPlugin 은 Kubernetes처럼 container registry에서 wasm image를 받도록 고안되어 있다.
meshctl 란 도구를 사용하여 (마치 docker command 처럼) WASM Envoy filter image를 build 가능하지만, 이 도구는 특정 업체(solo.io; Istio 주요 멤버가 포진된 Istio 기반 서비스 업체)에서 운영하기에 껄끄러움이 느껴지는 것은 부인하기 어렵다.
기타 확장 방법
이외에도 Envoy filter는 Network filter, HTTP filter 모두에 대해 golang filter를 지원하여, golang으로 custom filter 구현 가능함과 동시에, Envoy가 C++로 작성된 open-source인 특성 상 C++로도 구현이 가능하다. 예제를 보면 그리 어려워 보이지도 않는다.
하지만 문제는 배포로 만든 binary를 Istio에 적용하려면, 아래 링크의 Istio proxy source code에 넣어 Istio proxy 자체를 build하고, 기존 Istio proxy를 교체해야 한다는 점이다. 물론 Istio 버전이 바뀔 때마다 함께 관리해야한다는 점은 덤이다.
Istio 이외의 Service Mesh 제품에 대해
Istio 이외에 Cilium, Linkerd, Kuma, Consul 등 Service Mesh 제품은 다양하다. 이중 Cilium은 높은 성능의 eBPF CNI로 특히 유명한데, CNI 내에 Service Mesh 기능을 포함한 sidecar-less Service Mesh임과 동시에 Istio를 포함한 다수의 Control Plane을 지원한다. 또한 Linkerd는 타 Service Mesh 제품과는 달리 Envoy가 아닌 자체 proxy를 사용함과 동시에 높은 성능으로 유명하다.
LiveWyer | Service Meshes Decoded: a performance comparison of Istio vs Linkerd vs Cilium
A performance comparison of three prominent Open Source service meshes Istio, Linkerd, and Cilium | Discovering the fastest service mesh and sharing our comparison experience
https://livewyer.io/blog/2024/05/08/comparison-of-service-meshes/
Cilium vs Linkerd vs Istio 성능 비교. 큰 차이는 없으나 어쨌건 Istio가 가장 성능이 떨어진다. 다만 Istio Sidecar mode에서의 비교라 Ambient mode 사용 시에는 좀더 나을 듯 하다.
이와 같은 상황임에도 Istio를 중심으로 Service Mesh를 분석한 이유는, 레퍼런스, 커뮤니티 및 Istio Internals: Ambient mode 를 고려했을 때, 여전히 Istio가 Service Mesh의 선두 주자로 파악되었기 때문이다.
Istio Internals: Ambient mode 를 고려했을 때, 여전히 Istio가 Service Mesh의 선두 주자로 파악되었기 때문이다.References
본 글 작성에 주로 참조한 문서이다.
