Knative：重新定義 Serverless | GIAC 實錄

螞蟻金服分散式架構發表於2018-12-29

Knative 是Google 發起的 Serverless 專案，希望通過提供一套簡單易用的 Serverless 開源方案，將 Serverless 標準化。
本文根據敖小劍在 2018 年上海 GIAC 演講內容整理，文末有PPT獲取地址。

前言

大家好，今天給大家來的演講專題是“Knative：重新定義Serverless”, 我是來自螞蟻金服中介軟體的敖小劍。

這是我的個人資料，有興趣的同學可以關注的我的個人技術部落格網站 skyao.io。

這次演講的內容將會有這些，首先給大家介紹一下 Knative 是什麼，然後是 Knative 的主要元件，讓大家對 Knative 有一個基本的瞭解。之後我會簡單的對 Knative 做一些分析和探討，以及介紹一下 Knative 後續的發展。希望本次的內容讓大家能夠對Knative有一個基本的認知。

什麼是Knative？

Knative 是 Google 牽頭髮起的 Serverless 專案。

這是Knative的專案定義，注意這句話裡面幾個關鍵字：Kubernetes，Serverless，Workload。

這是最近幾年 Google 做大型專案的常態：產品剛出來，陣營就已經很強大了，所謂先聲奪人。

這是目前Knative專案的進展，可以看到這是一個非常新的專案，剛剛起步。

備註：這是截至2018-11-24演講當天的情況，到2018年12月底，Knative已經發布了v0.2.2和v0.2.3兩個bugfix版本。但也還只是 0.2 ……

我們來看一下，在Knative出來前， Serverless 領域已有的實現，包括雲端提供的產品和各種開源專案。

這幅圖片摘自The New Stack的一個Serverless 調查，我們忽略調查內容，僅僅看看這裡列出來的Serverless產品的數量——感受是什麼？好多Serverless專案，好多選擇！

那問題來了：到底該怎麼選？

這就是目前 Serverless 的問題：由於缺乏標準，市場呈現碎片化。不同廠商，不同專案，各不相同，因此無論怎麼選擇，都面臨一個風險：供應商繫結！

這段話來自 Knative 的官方介紹，Google 推出 Knative 的理由和動機。其中第一條和第二條針對的是當前 Serverless 市場碎片的現狀。而第四條多雲戰略，則是針對供應商繫結的風險。

Google描述Knative的動機之一，是將雲原生中三個領域的最佳實踐結合起來。

小結：

當前 Serverless 市場產品眾多導致碎片化嚴重，存在廠商繫結風險，而 Google 推出 Knative，希望能提供一套簡單易用的 Serverless 方案，實現 Serverless 的標準化和規範化。

Knative的主要元件

第二部分，來介紹一下Knative的主要元件。

前面提到，Google 推出 Knative ，試圖將雲原生中三個領域的最佳實踐結合起來。反應到 Knative 產品中，就是這三大主要元件：Build，Serving，Eventing。

Knative Build 元件，實現從程式碼到容器的目標。為什麼不直接使用 dockfile 來完成這個事情？

Knative Build 在實現時，是表現為 Kubernetes 的 CRD，通過 yaml 檔案來定義構建過程。這裡引入了很多概念如：Build，Builder，Step，Template，Source等。另外支援用 Service Account 做身份驗證。

Knative Serving元件的職責是執行應用以對外提供服務，即提供服務、函式的執行時支撐。

注意定義中的三個關鍵：

Kubernetes-based：基於k8s，也僅支援k8s，好處是可以充分利用k8s平臺的能力
scale-to-zero：serverless 最重要的賣點之一，當然要強調
request-driven compute：請求驅動的計算

值得注意的是，除了k8s之外，還有另外一個重要基礎：istio！後面會詳細聊這個。

Knative Serving專案同樣也提供了自己的中介軟體原語，以支援如圖所示的幾個重要特性。

Knative中有大量的概念抽象，而在這之後的背景，說起來有些意思：Knative 覺得 kubernetes 和 istio 本身的概念非常多，多到難於理解和管理，因此 Knative 決定要自己提供更高一層的抽象。至於這個做法，會是釜底抽薪解決問題，還是雪上加霜讓問題更麻煩……

Knative的這些抽象都是基於 kubernetes 的 CRD 來實現，具體抽象概念有：Service、Route、Configuration 和 Revision。特別提醒的是，右邊圖中的 Service 是 Knative 中的 Service 概念，service.serving.knative.dev，而不是大家通常最熟悉的 k8s 的 service。

對於Knative Serving 元件，最重要的特性就是自動伸縮的能力。目前伸縮邊界支援從0到無限，容許通過配置設定。

Knative 目前是自己實現的 Autoscaler ，原來比較簡單：Revision 對應的pod由 k8s deployment 管理，pod上的工作負載上報 metrics，彙總到 Autoscaler 分析判斷做決策，在需要時修改 replicas 數量來實現自動伸縮（後面會再講這塊存在的問題）。

當收縮到0，或者從0擴充套件到1時，情況會特別一些。Knative在這裡提供了名為 Activator 的設計，如圖所示：

Istio Route 控制流量走向，正常情況下規則設定為將流量切到工作負載所在的pod
當沒有流量，需要收縮到0時，規則修改為將流量切到 Activator ，如果一直沒有流量，則什麼都不發生。此時Autoscaler 通過 deployment 將 replicas 設定為0。
當新的流量到來時，流量被 Activator 接收，Activator 隨即拉起 pod，在 pod 和工作負載準備好之後，再將流量轉發過去

Knative Eventing 元件負責事件繫結和傳送，同樣提供多個抽象概念：Flow，Source，Bus，以幫助開發人員擺脫概念太多的負擔（關於這一點，我保留意見）。

Bus 是對訊息匯流排的抽象。

Source 是事件資料來源的抽象。

Knative 在事件定義方面遵循了 Cloudevents 規範。

小結：

簡單介紹了一下 Knative 中的三大元件，讓大家對 Knative 的大體架構和功能有個基本的認知。這次就不再繼續深入 Knative 的實現細節，以後有機會再展開。

Knative分析和探討

在第三部分，我們來分析探討一下 Knative 的產品定位，順便也聊一下為什麼我們會看好 Knative。

首先，最重要的一點是：Knative 不是一個 Serverless 實現，而是一個 Serviceless 平臺。

也就是說，Knative 不是在現有市場上的20多個 Serverless 產品和開源專案的基礎上簡單再增加一個新的競爭者，而是通過建立一個標準而規範的 Serverless 平臺，容許其他 Serverless 產品在 Knative 上執行。

Knative 在產品規劃和設計理念上也帶來了新的東西，和傳統 Serverless 不同。工作負載和平臺支撐是 Knative 最吸引我們的地方。

要不要Istio？這是 Knative 一出來就被人詬病和挑戰的點：因為 Istio 的確是複雜度有點高。而 k8s 的複雜度，還有 Knative 自身的複雜度都不低，再加上 Istio……

關於這一點，個人的建議是：

如果原有系統中沒有規劃 Istio/Service mesh 的位置，那麼為了 Knative 而引入 Istio 的確是代價偏高。可以考慮用其他方式替代，最新版本的 Knative 已經實現了對 Istio 的解耦，容許替換。
如果本來就有規劃使用 Istio/Service mesh ，比如像我們螞蟻這種，那麼 Knative 對 Istio 的依賴就不是問題了，反而可以組合使用。

而 Kubernetes + Servicemesh + Serverless 的組合，我們非常看好。

當然，Knative 體系的複雜度問題是無法迴避的：Kubernetes，Istio，Knative 三者都是複雜度很高的產品，加在一起整體複雜度就非常可觀了，挑戰非常大。

Knative後續發展

第四個部分，我們來展望一下 Knative 的後續發展，包括如何解決一些現有問題。

第一個問題就是效能問題。

Queue Proxy也是一個現存的需要替換的模組。

前面講過 Knative 的 Autoscaler 是自行實現的，而 k8s 目前已經有比較健全原生能力： HPA 和 Custom Metrics。目前 Knative 已經有計劃要轉而使用 k8s 的原生能力。這也符合 Cloud Native 的玩法：將基礎能力下沉到 k8s 這樣的基礎設施，上層減負。

除了下沉到 k8s 之外，Autoscaler還有很多細節需要在後續版本中完善。

對事件源和訊息系統的支援也遠不夠完善，當然考慮到目前才 0.2.0 版本，可以理解。

目前 Knative 還沒有規劃 Workflow 類的產品。

在網路路由能力方面也有很多欠缺，上面是 Knative 在文件中列出來的需求列表。

最後聊聊 Knative 的可拔插設計，這是 Knative 在架構設計上的一個基本原則：頂層鬆耦合，底層可拔插。

最頂層是 Build / Serving / Eventing 三大元件，中間是各種能力，通過 k8s 的 CRD 方式來進行宣告，然後底層是各種實現，按照 CRD 的要求進行具體的實現。

在這個體系中，使用者接觸的是 Build / Serving / Eventing 通用元件，通過通過標準的 CRD 進行行為控制，而和底層具體的實現解耦。理論上，之後在實現層做適配，Knative 就可以執行在不同的底層 Serverless 實現上。從而實現 Knative 的戰略目標：提供 Serverless 的通用平臺，實現 Serverless 的標準化和規範化。

總結

最後，我們對 Knative 做一個簡單總結。

先談一下 Knative 的優勢，首先是 Knative 自身的幾點：

產品定位準確：針對市場現狀，不做競爭者而是做平臺
技術方向明確：基於 k8s，走 Cloud Native 方向
推出時機精準：k8s 大勢已成，istio 接近成熟

然後，再次強調：Kubernetes + Service mesh + Serverless 的組合，在用好的前提下，應該威力不凡。

此外，Knative 在負載的支撐上，不拘泥於傳統的FaaS，可以支援 BaaS 和傳統應用，在落地時適用性會更好，使用場景會更廣泛。（備註：在這裡我個人有個猜測，Knative 名字中 native 可能指的是 native workload，即在 k8s 和 Cloud Native 語義下的原生工作負載，如果是這樣，那麼 Google 和 Knative 的這盤棋就下的有點大了。）

最後，考慮到目前 Serverless 的市場現狀，對 Serverless 做標準化和規範化，出現一個 Serverless 平臺，似乎也是一個不錯的選擇。再考慮到 Google 拉攏大佬和社群一起幹的一貫風格，攜 k8s 和 Cloud Native 的大勢很有可能實現這個目標。

當然，Knative 目前存在的問題也很明顯，細節不說，整體上個人感覺有：