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

EAWorld發表於2019-04-11

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

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

作者:Richard Li 

譯者:白小白 

原文:

現時的雲原生應用由多種異構的服務或者微服務組成,服務間、服務與客戶端之間的通訊需要跨越浩繁的通訊協議和拓撲結構。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的地址: 加入Slack的地址:

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

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

相關文章