Knative：從新定義 Serverless | GIAC 實錄

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組件的職責是運行應用以對外提供服務，即提供服務、函數的運行時支撐。

注意定義中的三個關鍵：

1. Kubernetes-based：基於k8s，也僅支持k8s，好處是能夠充分利用k8s平臺的能力
2. scale-to-zero：serverless 最重要的賣點之一，固然要強調
3. 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 的設計，如圖所示：

1. Istio Route 控制流量走向，正常狀況下規則設置爲將流量切到工做負載所在的pod
2. 當沒有流量，須要收縮到0時，規則修改成將流量切到 Activator ，若是一直沒有流量，則什麼都不發生。此時Autoscaler 經過 deployment 將 replicas 設置爲0。
3. 當新的流量到來時，流量被 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 目前存在的問題也很明顯，細節不說，總體上我的感受有：

• 成熟度：目前才 0.2 版本，實在太早期，太多東西還在開發甚至規劃中。但願隨着時間的推移和版本演進，Knative 能儘快走向成熟。
• 複雜度：成熟度的問題還好說，總能一步一步改善的，無非是時間問題。可是 Knative 的系統複雜度太高的問題，目前看來幾乎是不可避免的。

最後，對 Knative 的總結，就一句話： 前途不可限量，可是成長鬚要時間。讓咱們拭目以待。

歡迎你們加入 servicemesher 社區，也能夠經過關注 servicemesher 微信公衆號來及時瞭解 service mesh 技術的最新動態。

PPT 地址：www.sofastack.tech/posts/2019-…

長按關注，獲取分佈式架構乾貨

歡迎你們共同打造 SOFAStack https://github.com/alipay