Knative：重新定義 Serverless | GIAC 實錄

Knative 是Google 發起的 Serverless 項目，希望通過提供一套簡單易用的 Serverless 開源方案，将 Serverless 标準化。

本文根據敖小劍在 2018 年上海 GIAC 演講内容整理，文末有PPT擷取位址。

前言

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

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

https://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 位址：

http://www.sofastack.tech/posts/2019-01-02-01

長按關注，擷取分布式架構幹貨

歡迎大家共同打造 SOFAStack

https://github.com/alipay