Kong mesh 深度分析報告

負載均衡 Istio Lua · 發表 2019-02-13 15:29:48

摘要：春節假期結束了，歡迎回來，這是農曆新年裡 ServiceMesher 公眾號的第一篇推送，作者單家駿。 Kong是一個基於OpenResty (Nginx) 封裝的微服務中介軟體產品，在微服務架構體系中，作為API閘道器以及API中介軟體（kubernetes ingress）提供服務。由...

春節假期結束了，歡迎回來，這是農曆新年裡 ServiceMesher 公眾號的第一篇推送，作者單家駿。

Kong是一個基於OpenResty (Nginx) 封裝的微服務中介軟體產品，在微服務架構體系中，作為API閘道器以及API中介軟體（kubernetes ingress）提供服務。由於其天生具備Nginx的高效能、nginx-lua外掛的可定製性，再加上完善的社群以及齊全的文件，在中小企業使用者群非常受歡迎，擁有較好的群眾基礎。

2018年8月，kong釋出了1.0 GA版本，正式宣佈其支援service mesh，並提供社群版以及企業版2個版本。下面我們從Demo、配置、功能這3方面，對kong mesh進行體驗及分析。

Demo體驗

Kong社群提供了kong mesh的demo (https://github.com/Kong/kong-mesh-dist-kubernetes），該demo是實現的是tcp四層透明代理轉發業務。

該demo主要做的事情是：提供兩個服務servicea以及serviceb，serviceb作為服務端，通過ncat監聽8080埠，接受外部的TCP訊息；servicea作為client端，通過ncat將當前server的時間發往serviceb。Demo的執行效果如下：

在客戶端節點，每隔兩秒會發送一次時間戳到服務端。

服務端節點，每隔兩秒列印一次時間戳。

接下來，我們詳細瞭解一下該demo背後的技術原理。

首先，我們來分析一下kong-mesh業務整體組網：

從組網中可以看出，kong mesh也分控制面與資料面。

控制面為圖中kong-admin的POD，3副本例項獨立部署，對外提供Admin API供使用者設定各種規則配置。

資料面為圖中servicea及serviceb的POD，每個POD中會啟動一個kong容器作為sidecar，通過iptables規則將外發以及到達的流量劫持到kong容器中，然後kong會根據路由規則將流量轉發到對應的例項。下面我們看看POD的部署配置：

部署配置關鍵點在於流量接管的設定，POD在啟動應用前，會使用istio/proxy_init映象來初始化環境，圖中的引數的含義是，使用TProxy（透明代理）的流量接管模式，將發往8080埠（業務serviceb監聽埠）的流量通過7000埠（kong監聽埠）來進行代理。

瞭解清楚該部署配置後，我們就可以比較容易地使用kong來代理http服務了。主要改動點還是在於POD的部署配置的修改。如下圖所示：

值得注意的是，代理HTTP服務和代替TCP不一樣，屬於7層轉發，不能使用上文的透明代理方式來進行接管。因此在setup_network的啟動引數中，需要指定流量接管模式為REDIRECT，通過iptables顯式將報文匯入到kong，kong再根據報文內容進行匹配後，再路由到目標服務（大家如果需要http demo的程式碼，可以到https://github.com/andrewshan/kong-mesh-http-demo下載）。

那麼，kong又是根據什麼規則去路由的呢？下面我們會繼續體驗kong mesh的配置規則。

配置分析

kong mesh的配置集中儲存在DB中，當前僅支援Postgre以及cassandra。控制面kong-admin會把配置規則寫入到DB中，資料面的Kong會定期從資料庫讀取配置規則並更新快取。

在demo中，我們通過k8s Job向kong-admin寫入了兩條資料：

第一條語句是新增一個名字叫service-b的服務；

第二條語句是為service-b的服務新增路由規則，允許源ip在0.0.0.0/0網段的tcp包可以轉發到service-b。

規則新增後，分別在services和routes表中可以查詢到相關的記錄：

那麼問題來了，kong的規則模型具體是什麼含義？這些規則是怎麼組合工作的呢？首先，我們先看看kong的規則模型：

從圖上可見，Service是規則模型的核心，一個Service代表一個目標服務URL。

Route代表的是Service的細粒度路由規則，定義了根據不同的客戶端請求屬性來選擇目標端Service，一個Service可關聯多個Route規則。可類比istio中的VirtualService。

Upstream定義的是針對具體的目標Service，所採取的負載均衡策略，以及健康檢查相關配置，一個Service可關聯0-1個Upstream。可類比istio中的DestinationRule。

Target定義的是具體的服務節點例項，可定義權重，一個target關聯一個upstream。具體的詳細規則描述，可參考kong的官方文件：https://docs.konghq.com/?_ga=2.44328420.1762329551.1548210642-1561229614.1544407768。

在k8s環境下部署，如果直接使用k8s平臺所提供的kube-dns的域名解析能力以及ClusterIP/NodePort的負載均衡的話，那麼原則上只需要配置Service以及Route規則就可以進行工作。Upstream和Target屬於可選配置。

我們繼續看看，kong-mesh本身如何根據這些規則進行路由。

Kong的路由及負載均衡能力是構建於openresty的access by lua以及balancer by lua這2個phase之上的。Servicea傳送的請求通過iptables將流量匯入到客戶端側（servicea-kong），kong收到後，根據請求訊息進行route_match，找出匹配的目標service，然後再根據service的可用target進行負載均衡，找到目標serviceb節點例項進行傳送。

服務端serviceb-kong收到請求後，由於啟動前通過環境變數配置好了本地路由規則:

根據該規則，kong直接把target為serviceb:8080的請求直接投遞給serviceb。最終完成整個請求路由過程。

接下來，我們再看看，kong基於上述的配置模型，可以提供什麼樣的功能，以及與其他mesh產品的差異點。

功能對比

下表將kong mesh (community）與當下熱門的istio+envoy組合進行功能比較，大家可以瞭解一下相關的差異（相關資料來源於kong官網）

功能點	kong-mesh (community)	istio + envoy	分析
服務發現	通過admin api新增服務，並只能發現通過api新增的服務	支援對接k8s, consul等註冊中心進行服務發現	從平臺獨立性來看，kong mesh佔優; 從服務接管易用性來看，istio佔優
服務協議	支援http, http2, websocket, stream	支援http, http2, grpc, websocket, stream	istio+envoy佔優
服務路由	支援根據源、目標地址，method、host、path、protocol等細粒度的路由	支援除左側列舉的所有能力外，還支援按header以及subset（標籤）的路由	istio+envoy佔優
負載均衡	支援輪詢、權重、一致性hash的負載均衡模式	支援除左側列舉的所有負載均衡模式外，還支援隨機、最低負載等模式	istio+envoy佔優
健康檢查	支援主動健康檢查以及被動健康檢查（熔斷）	支援主動健康檢查以及被動健康檢查（熔斷）	基本對等
安全	支援Certificate證書管理，支援JWT+TLS加密傳輸	支援證書下發及更新，JWT+mTLS加密傳輸	基本對等
多使用者	支援按consumer授權	支援RBAC使用者-角色授權	istio+envoy佔優
故障注入	不支援	支援	istio+envoy佔優
監控統計	繼承nginx的統計能力，支援按請求、連線、健康狀態等維度的統計	支援更細粒度的比如按協議、Zone的統計	istio+envoy佔優
可擴充套件性	背靠openresty，提供強大的自定義外掛能力，使用lua進行開發	提供lua外掛開發能力，但能力比較基礎	kong mesh佔優
學習曲線	kong自身提供控制面和資料面能力，組網簡單，純lua語言上手較輕鬆	istio+envoy一起至少4個元件，跨兩種語言，上手較難	kong mesh佔優