1. 程式人生 > 程式設計 >Kong 開源的服務網格Kuma爬過了K8S這座大山

Kong 開源的服務網格Kuma爬過了K8S這座大山

作者:Dan Meyer

譯者:羅廣明

審校:馬若飛

英文原文地址: www.sdxcentral.com/articles/ne…

轉載自:www.servicemesher.com/blog/kong-o…

編者按

2019年9月10日,Kong正式宣佈開源一款Service Mesh:Kuma。此訊息一出,立即在雲原生社群引起反響,各大媒體爭相報道。讓我們跟隨SDxCentral的總編輯,一起來看看Kong的CTO如何介紹Kuma這款Service Mesh產品以及對於SMI的看法。關於Kuma的具體功能介紹可以閱讀官網部落格以及Github

翻譯一下其Github關於Kuma功能特性的簡介如下,方便讀者瞭解:

  • 通用的控制平面: 易於使用,分散式,可以在任何平臺執行。
  • 輕量的資料平面: 基於Envoy,可處理任意型別流量。
  • 自動化: 在K8s平臺上部署無需任何程式碼改動,也可在虛擬機器器上靈活部署。
  • 多租戶: 可在一個叢集與同一個控制平面上部署多套服務網格。
  • 網路安全: 自動mTLS加密。
  • 流量分割: 靈活的ACL規則。
  • 流量追蹤: 與Zipkin和Jaeger自動整合。
  • 流量指標: 與Prometheus/Splunk/ELK自動整合。
  • 代理配置模版: 方便進階(收費)使用者配置Envoy。
  • 標籤選擇器: 可應用不同地域的、特定於雲的和麵向團隊的策略。
  • 平臺中立: 支援K8s,虛擬機器器和裸機。
  • 強大的APIM Ingress: 與Kong閘道器整合。

kuma-architecture

簡介

Kong正在將其服務網格平臺Kuma打造成一個日益複雜的生態系統,在過去幾個月裡,許多新加入者和選擇湧現出來。

該公司聲稱Kuma是“一個通用的服務網格”。Kong CTO和聯合創始人Marco Palladino解釋說,這意味著Kuma不同於市場上的大多數服務網格專案,它的設計初衷是在Kubernetes生態系統內部和外部都能工作,這包括虛擬機器器(VMs)、容器、legacy環境以及Kubernetes。

Kuma包括一個基於Envoy服務代理的通用控制平面。它結合了資料平面和進階的控制平面,允許使用者使用本地自定義資源定義(CRDs)或RESTful API設定許可權、獲取指標和設定路由規則。Palladino解釋說,早期第一代的服務網格產品大多缺乏成熟的控制平面,需要大量的二次開發或手工定製。

他解釋說:“我們希望90%的用例都易於使用,並且能夠快速升級。對於另外10%用例的使用者,我們有一個允許使用者深入使用的策略,”他補充說,儘管Kuma的設計是為了方便使用,“但Kuma是為企業設計的,而不是業餘愛好者。”

Kuma的特性包括software-defined security,它支援所有四層通訊流的mTLS身份驗證;能夠實現追蹤(trace)和日誌(log)記錄,從而更好地分析指標;提供流量控制能力,如斷路器和健康檢查,以增強四層路由。

Palladino說,Kuma保護底層網路的能力提供了可靠性和更深層次的可觀察性,並且無需修改任何程式碼。

Palladino說:“我們努力為Kuma構建一個非常平滑漸進的學習曲線。它的複雜度不會在早期壓垮開發人員,並且也不會阻止開發人員走得更遠。我們確實為高階使用者提供了一個策略來配置底層代理資料平面。”

Kuma還利用了Kong同名的開源API閘道器。該閘道器管理組織與部署現代微服務的各種方法之間的資訊流。

Kuma加入服務網格競爭行列

Kuma加入了服務網格競爭行列,這個群體與日俱增,聲稱可以更容易地支援微服務的部署。

Palladino說:“每個人都告訴我們,他們想要使用服務網格,但實際上沒有一種服務網格易於使用,而且真正適用企業生產環境。許多企業專注於Kubernetes,但對他們來說,這成為了雲原生探索之旅的終點。我們提供了一個產品,允許他們擁有一個可以更早實現並支援他們遷移的服務網格。”

一個已經引起廣泛注意的服務網格平臺是Istio。它定位於網路層,使用底層進行微服務開發和維護。這允許將管理運維與應用程式開發分離開來。

Palladino說,Istio幫助照亮了這片天空,但它仍然“非常複雜,有很多活躍的部件”。它在Kubernetes上執行得很好,但並不是所有人都在執行Kubernetes。”

他說,這種關注還會影響Linkerd和Containous等其他服務網格的選擇,比如最近推出的Maesh平臺

“Maesh、Linkerd和其它控制平面網格都高度關注Kubernetes,”Palladino解釋說。“只有當企業採用Kubernetes時,它們才會被採用。我們通過在這一過程的早期建立安全和可觀察性,實現了向Kubernetes的過渡。”

還需要努力協調服務網格平臺之間的互操作性。其中之一由微軟牽頭,它在今年早些時候率先推出了服務網格介面SMI規範。它的目標是為開發人員提供執行在Kubernetes上的不同服務網格技術的互操作性。

Palladino將這種努力淡化為邊緣化服務網格功能。

“我們根本不相信SMI,”他說。“這是將介面標準化的另一種嘗試,讓它變得平庸而不優秀。它採用整個社群所有服務網格的公分母,從而降低了它們對終端使用者的價值。它界限很寬,但並不深入。”

Palladino認為Kuma才真正實現了可以在所有平臺進行互操作。

Kong以Mashape的名字成立於2009年。2015年,它將Kong平臺釋出到開源社群,並於去年對旗下所有業務產品正式啟用了該平臺的名稱。該公司已通過5輪融資籌集了6,910萬美元資金,最近一次是在3月份的C輪融資,總額4,300萬美元。

編者後記

當Istio因其效能表現疲軟之際,會湧現一個又一個的新玩家,給市場帶來競爭與多樣性,這也是使用者喜聞樂見的。Kong涉足服務網格並不算太意外,我們可以瞭解到除了市面上的傳統雲廠商打造的和開源的各項服務網格產品,Consul Service Mesh的出現也讓人眼前一亮。Consul Service Mesh與Kuma背後的廠商均有其成熟的開源產品做強力支撐:Consul的服務發現與註冊產品,Kong的閘道器產品。他們各自在開源社群擁有一片天下,此時推出服務網格產品自然會有一大批“擁躉”。

Kuma的效能較之Istio以及其它服務網格產品的優劣尚未可知,但是其平臺中立的思想還是值得借鑑。當前市場上,K8s並未完全普及,很多公司的產品都是部署在虛機甚至裸機上,如果此時又想嘗試下服務網格技術,Kuma的出現不失為一種驚喜。


ServiceMesher 社群是由一群擁有相同價值觀和理念的志願者們共同發起,於 2018 年 4 月正式成立。

社群關注領域有:容器、微服務、Service Mesh、Serverless,擁抱開源和雲原生,致力於推動 Service Mesh 在中國的蓬勃發展。

ServiceMesher 社群官網:www.servicemesher.com