Ambassador 0.52 新特性：會話親和性、負載均衡控制、gRPC-Web

本文由公眾號EAWorld翻譯發表，轉載需注明出處。

作者：Richard Li 

譯者：白小白 

原文：http://t.cn/E6cZoyG

現時的云原生應用由多種異構的服務或者微服務組成，服務間、服務與客戶端之間的通信需要跨越浩繁的通信協議和拓撲結構。Ambassador就是部署在這樣不斷增長的異構的工作負載環境之下，也因此我們對于這種境況有著直接的認知。

我們著力于將Ambassador打造成全球最棒的云原生API網關。為此，我們很興奮可以發布Ambassador的0.52版本，并在新版中新增了如下的新能力：

• 支持gRPC-Web協議。gRPC-Web基于原生的gRPC，其設計主旨服務于瀏覽器/服務器通信。在此要對 Gert van Dijk 和 Rotem Tamir 的工作表示感謝。

• 支持先進的負載均衡控制。現在的Ambassador可以原生支持向物理IP地址的流量路由，而非DNS主機名稱。

• 支持會話親和性（即粘滯會話）。Ambassador可以基于Cookie、HTTP頭或者來源IP地址，將來自同一個終端用戶的HTTP請求歸集到一個特定的Kubernetes Pod里。

由于實施了一些架構遷移的工作，對會話親和性和先進的負載均衡控制的支持還屬于搶先版本狀態，稍后將會介紹。

今時今日的云服務通過大批的通信協議進行暴露。Ambassador幾乎支持流行的7層協議的每一層，包括HTTP，HTTP/2，gRPC，WebSocket，以及最新支持的gRPC-Web。并且，即使開發者所使用的協議并不被直接支持，Ambassador也支持原生的TCP路由方式。

gRPC-Web協議面向前端開發者提供了很多的便利：高性能，雙向的流式通信以及廣泛的類庫支持。由于瀏覽器的限制 ，gRPC-Web并不與gRPC直接兼容。但可以設置服務端代理來解決在gRPC-Web請求和gRPC HTTP/2響應之間的翻譯轉換問題。

感謝Envoy對于gRPC-Web的支持，Ambassador現在可以通過設置 enable_grpc_web: True注解來支持gRPC-Web。需要注意的是，這是一個全局設定。

Ambassador一直提供廣泛的路由選項，可以基于主機、HTTP方法、HTTP頭，可以采用正則表達式等等。我們知道，對路由施加靈活的細粒度的控制 對適應廣泛的使用場景至關重要。但目前Ambassador僅為運維人員提供了有限的控制，來將請求路由到不同的endpoint。過去，Ambassador直接將請求路由到Kubernetes service，由后者將請求分發到不同的Pod。這種方案工作良好，便于推理和測試。對Kubernetes service的Curl請求遵循與Ambassador請求同樣的路由路徑。

Kubernetes網絡

在一個典型的Kubernetes集群中，由kube-proxy路由Kubernetes service請求。稍顯困擾的是，kube-proxy并不是典型形態的代理，只是基于iptables規則為service實現虛擬IP的一個進程。這種架構為路由帶來了額外的復雜性：不僅引入了少量的延遲，而且iptables并不是為路由設計的，因此負載均衡策略受限于輪詢的調度模型。

盡管存在實現的復雜性，這樣的方案仍舊為Ambassador使用者提供了壓倒性的優勢：簡便性。服務發現和負載均衡都交給Kubernetes解決，可以很直接的使用類似Curl這樣的常規工具進行路由的測試。

Ambassador 0.52的負載均衡

在Ambassador 0.52版本中，我們引入了一套新的負載均衡控制機制。相關的控制選項是可選的，所以如果不做任何設置的變動，將以原本行之有效的方式來實施負載均衡控制。如果設置了AMBASSADOR_ENABLE_ENDPOINTS環境變量，將會啟用新的控制機制：

• Ambassador會監視所有Kubernetes endpoint的狀態變更，而不僅僅關注Kubernetes service本身。

• 有了這些狀態信息，Ambassador可以基于設置來使用不同的負載均衡算法，繞過Kube-proxy將請求直接路由到Kubernetes endpoint。

以下的示例映射表展現了我們如何添加load_balancer注解：

apiVersion: ambassador/v1
kind: Mappingname: qotm_mapping
prefix: /qotm/
service: qotm
load_balancer:
policy: round_robin

需要注意的是，可以在Ambassador模塊中添加注解，來使默認的負載均衡策略全局有效。

會話親和性

除了默認的round_robin策略，Ambassador 0.52還可以基于ringhash策略支持會話親和性（即“粘滯會話”）。在此過程中需要為路由指定客戶端的唯一標識。可以支持任意的HTTP頭，Cookie或者實際的來源IP地址。

搶先版本

我們在0.52中將先進的負載均衡控制機制作為搶先版本發布，以進行更廣泛的測試并收集反饋。我們尤其感興趣的是，在不同的工作負載和Kubernetes集群環境下，啟用這一特性有怎樣的效果。我們希望 endpoint數多于service數，這樣就可以對Kubernetes的API服務器產生持續增長的工作負載。我們熱切的期待你的反饋，無論是積極的或者是負面的都可以，只要是關于這一特性的。

在新版的Ambassador中，我們還提供了對大量的用戶反饋Bug的修復，并提供了諸多的加強。

• Ambassador現在支持HTTP/1.1請求和gRPC后端服務之間的橋接。

• 在使用HTTP API的時候，為extauth過濾器添加了一個tracing header。（在使用gRPC API的時候，已經添加了這樣的tracing header）

• 允許extauth建立原本不存在的header（#1313）。

• 可以使用Lua過濾器，在映射中嵌入簡單的腳本。鳴謝Liam Costello的貢獻。

• 啟動性能改進。

• 使用C YAML解析器代替Python實現以改進解析性能（#1294，#1318）

• 加入xff_num_trusted_hops設置。如果用戶使用了如CloudFlare這樣的CDN服務，并且依賴X-Forwarded-For header來應對流量限速的使用場景，提供這樣的設置將十分重要。

更新的核心設置文檔覆蓋了上面提到的新的選項（如Lua，gRPC HTTP/1.1 橋接等）。

Ambassador 0.60將默認在8080端口偵聽明文HTTP請求（取代原來的80端口），在8443端口偵聽HTTPS請求（取代原來的443端口），以便在沒有Root權限的情況下簡化Ambassador的運行。如果你的現存服務依賴上述默認端口，需要修改相關的配置文件，Ambassador 0.52會在診斷服務中提出警報。

可以通過下面的Docker標簽獲得Ambassador 0.52版本：

quay.io/datawire/ambassador:0.52.0。

通過標簽更新現有的部署清單，kubectl會將0.52版本安裝到集群中。

也可以通過Helm安裝：

helm install stable/ambassador

Ambassador的更新依賴Kubernetes的部署。在更新Ambassador之前，需要將Kubernetes部署清單指向quay.io/datawire/ambassador:0.52.0然后基于更新后的清單運行kubectl。Kubernetes會以滾動更新的方式將Ambassador更新到0.52版本。

如果你在更新過程中遇到任何問題，可以發issue或者加入我們的Slack求助。

提交Issue的地址：https://github.com/datawire/ambassador/ 加入Slack的地址：http://d6e.co/slack

如果Ambassador工作良好，我們也很樂于得到這樣的消息。可以在文末或者在我們的推特賬號@getambassadorio留言。