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

EAWorld發表於2019-04-11
會話負載RPCWeb

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裡。

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

一、gRPC-Web支援

今時今日的雲服務通過大批的通訊協議進行暴露。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 0.52版本的其他改變

在新版的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 橋接等）。

四、即將到來的0.60中的重大變更

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

五、安裝Ambassador 0.52

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

quay.io/datawire/ambassador:0.52.0。

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

也可以通過Helm安裝：


helm install stable/ambassador

六、升級到Ambassador 0.52

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留言。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31562043/viewspace-2641084/，如需轉載，請註明出處，否則將追究法律責任。

相關文章