Istio overview: Extensibility, Etc.

Introduction

대표적 Service Mesh 제품인 Istio에 대한 overview로 Kubernetes를 배경으로 설명한다.

Istio overview: Architecture, Traffic Management, Istio overview: Observability 및 Istio overview: Security 에 이어, 마지막으로 Istio의 확장성과 타 Service Mesh 제품에 대해 논한다.

참조한 문서는 글 내부 및 References 에 달았다.

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 FilterCustomizing Envoy configuration generated by Istio.

https://istio.io/latest/docs/reference/config/networking/envoy-filter/

Envoy filter chain

Life of a Request — envoy 1.31.0-dev-b8d86c documentationBelow we describe the events in the life of a request passing through an Envoy proxy. We first describe how Envoy fits into the request path for a request and then the internal events that take place following the arrival of a request at the Envoy proxy from downstream. We follow the request until the corresponding dispatch upstream and the response path.

https://www.envoyproxy.io/docs/envoy/latest/intro/life_of_a_request

Istio의 feature 확장은 Envoy filter를 통해 이루어진다. Envoy에는 다수의 filter의 연결로 이루어진 Filter chain이 있어, 각 filter는 request / response에 대한 변환을 담당한다.

TLS traffic에 대한 Envoy filter chain의 구조. 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 예이다.

HTTP filters — envoy 1.31.0-dev-39093b documentation

https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/http_filters

범용: 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

Lua — envoy 1.31.0-dev-d19462 documentationThe HTTP Lua filter allows Lua scripts to be run during both the request and response flows. LuaJIT is used as the runtime. Because of this, the supported Lua version is mostly 5.1 with some 5.2 features. See the LuaJIT documentation for more details.

https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/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 NewsAre 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 참조).

Wasm PluginExtend the functionality provided by the Istio proxy through WebAssembly filters.

https://istio.io/latest/docs/reference/config/proxy_extensions/wasm-plugin/

WebAssembly 특성 상 다수의 언어(C++, Rust, Go, TypeScript)를 지원하고 binary image는 OCI(Open Container Initiative) 호환 가능하기에 일반적인 Container registry에 등록 역시 가능하다. WasmPlugin 은 Kubernetes처럼 container registry에서 wasm image를 받도록 고안되어 있다.

Proxy-Wasm overview 에서 상세히 논한다.

기타 확장 방법

이외에도 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 버전이 바뀔 때마다 함께 관리해야한다는 점은 덤이다.