Envoy as a gRPC Load Balancer in Kubernetes

背景

繼前一篇的文章 In-cluster gRPC Load Balancing? 我們提到在 Kubernetes 上做 gRPC 負載均衡的不便之處及提供 4 個可行的方案之後，文末提出 方案3.(加一個 load balance HTTP/2 Protocol 的反向代理) 為最小引入成本可行方案，今天就來談下如何優雅的使用 Envoy 配置一個 gRPC 反向代理所需要做的配置。

Envoy

Envoy 是一個高性能的代理由C++所實作，相比於目前幾套常見的代理 (NGINX, HAProxy, Linkerd) 具有更佳的彈性配置方式及自定義流量控制平面(xDS)，除此之外Envoy 支持的協定也十分廣泛，已具備支援 HTTP/2 的 LB 功能 (現代主流代理必備)也有代理 TCP 協定的能力 (早期的代理常見設計為 L7 HTTP 代理) 。

Envoy 設計之初就提供 expose metrics/traces 讓 Prometheus/Jaeger 來搜集相關指標，在可觀測性(observability)方面又是一大優勢。

In-cluster 代理

假設我們需要為在集群內部的 gRPC 服務端做反向代理，理想的架構圖會像是這個樣子

兩步驟完成 gRPC or HTTP/2 代理負載均衡

1. 首先要為 gRPC 服務端造一個 Headless Service 理由是我們會在 Envoy 的靜態配置文件上配上 STRICT_DNS 這能夠讓 Envoy 解析出這些 Pods 的 A records 作為 LB 的上游(upstream)目標。
2. 造一個 Envoy Deployment 通常配置 2 副本做高可用互相備份即可, 其關聯的 Service 設為 Cluser IP 給 gRPC Clients 作為 Virtual IP 的訪問地址。

範例 YAMLs

總結

本篇文章透過靜態配置 Envoy 完成反向代理並對 gRPC 做負載均衡，可以看到 Envoy 靜態配置其實並不複雜，而作為一個輕量的反向代理可以見到引入的成本並不高，可以在短時間內達到集群內 gRPC 應用的負載均衡。

如果想要有更進階的代理方式以及訂製流量工程，可以透過撰寫自定義的控制平面使用 xDS 與 Envoy 溝通，做動態配置可以參考 go-control-plane 。沒錯，知名的 Istio 專案就是結合了 Envoy 作為自家的數據平面(Data plane)透過自定義控制平面(Control plane)在 Service Mesh 當紅的現今這樣被造出來的。

下集預告

Service Proxy, Edge Proxy 傻傻分不清楚？