導讀：Knative是Google在2018的Google Cloud Next大會上發布的一款基于Kubernetes的Serverless框架。

作者：劉宇

來源：華章科技

其基本信息如表2-2所示。

表2-2 Knative基本信息

Knative一個很重要的目标就是制定雲原生、跨平台的Serverless編排标準。Knative是通過整合容器構建（或者函數）、工作負載管理（和動态擴縮）以及事件模型來實現Serverless标準的。Knative社區的主要貢獻者有Google、Pivotal、IBM、Red Hat。CloudFoundry、OpenShift這些PaaS提供商都在積極地參與Knative的建設。

如圖2-14所示，Knative是建立在Kubernetes和Istio平台之上的，使用了Kubernetes提供的容器管理組件（deployment、replicaset和pod等），以及Istio提供的網絡管理組件（ingress、LB、dynamic route等）。

Knative中有兩個重要的組件，分别是為其提供流量的Serving（服務）組件以及确保應用程序能夠輕松地生産和消費事件的Event（事件）組件。

其中，Serving組件基于負載自動伸縮，包括在沒有負載時縮減到零，允許使用者為多個修訂版本應用創建流量策略，從而通過URL輕松路由到目标應用程序；而Event組件的作用是使生産和消費事件變得容易，允許操作人員使用自己選擇的消息傳遞層。

除了Serving和Event組件之外，Build也是Kantive的組件之一。其提供“運行至完成”的顯示功能，這對創建CI/CD工作流程很有用，通過靈活的插件化的構建系統将用戶源代碼構建成容器。

目前，其已經支持多個構建系統，比如Google的Kaniko，它無須運行Docker Daemon就可以在Kubernetes集群上構建容器鏡像。Serving使用它将源存儲庫轉換為包含應用程序的容器鏡像。

在諸多Serverless開源項目中，Knative的優勢也是較為明顯的。一方面，Knative以Kubernetes為底層框架，與Kubernetes生态結合得更緊密。無論是雲上Kubernetes服務還是自建Kubernetes集群，都能通過安裝Knative插件快速地搭建Serverless平台。

另一方面，Knative聯合CNCF，把所有事件标準化為CloudEvent，提供事件的跨平台運行，同時讓函數和具體的調用方法解耦。在彈性層面，Knative可以監控應用的請求，并自動擴縮容，借助于Istio（Ambassador、Gloo等）支持藍綠發布、回滾的功能，方便應用發布。

同時，Knative支持日志的收集、查找和分析，并支持VAmetrics數據展示、調用關系跟蹤等。

Knative工作原理如圖2-14所示。

▲圖2-14 Knative工作原理

1. Serving（服務）

Serving模塊定義了一組特定的對象，包括Revision（修訂版本）、Configuration（配置）、Route（路由）和Service（服務）。Knative通過Kubernetes CRD（自定義資源）的方式實現這些Kubernetes對象。所有Serving組件對象間的關系可以參考圖2-15。

▲圖2-15 Serving組件對象間的關系

Knative Serving始于Configuration。使用者在Configuration中為部署容器定義所需的狀态。最小化Configuration至少包括一個配置名稱和一個要部署容器鏡像的引用。

在Knative中，定義的引用為Revision。Revision代表一個不變的、某一時刻的代碼和Configuration的快照。每個Revision引用一個特定的容器鏡像和運行它所需要的特定對象（例如環境變量和卷）。然而，使用者不必顯式創建Revision。Revision是不變的，它們從不會被改變和删除。

相反，當使用者修改Configuration的時候，Knative會創建一個Revision。這使得一個Configuration既可以反映工作負載的當前狀态，也可以用于維護一個曆史的Revision列表。

Knative中的Route提供了一種将流量路由到正在運行的代碼的機制。它将一個HTTP可尋址端點映射到一個或者多個Revision。Configuration本身并不定義Route。

2. 彈性伸縮

Serverless架構的一個關鍵原則是可以按需擴容，以滿足需要和節省資源。Serverless負載應當可以一直縮容至零。這意味着如果沒有請求進入，則不會運行容器實例。如圖2-16所示，Knative使用兩個關鍵組件實現該功能。它将Autoscaler和Activator實現為集群中的Pod。

▲圖2-16 Knative彈性伸縮原理簡圖

用戶可以看到它們伴随其他Serving組件一起運行在knative-serving命名空間中。Autoscaler收集達到Revision并發請求數量的有關信息。為了做到這一點，它在Revision Pod内運行一個名為queue-proxy的容器。該Pod中也運行用戶提供的鏡像。

queue-proxy檢測該Revision上觀察到的并發量，然後每隔一秒将此數據發送到Autoscaler。Autoscaler每隔兩秒對這些指标進行評估，并基于評估的結果增加或者減少Revision部署的規模。默認情況下，Autoscaler嘗試維持每Pod每秒平均接收100個并發請求。這些并發目标和平均并發窗口均可以變化。

Autoscaler也可以利用Kubernetes HPA（Horizontal Pod Autoscaler）來替代該默認配置。這将基于CPU使用率實現自動伸縮，但不支持縮容至零。這些設定都能夠通過Revision元數據注解（Annotation）定制。

Autoscaler采用的伸縮算法針對兩個獨立的時間間隔計算所有數據點的平均值。它維護兩個時間窗，分别是60秒和6秒。Autoscaler以兩種模式運作：Stable Mode（穩定模式）和Panic Mode（恐慌模式）。在穩定模式下，它使用60秒時間窗的平均值決定如何伸縮部署以滿足期望的并發量。

如果6秒時間窗的平均并發量兩次達到期望目标，Autoscaler轉換為恐慌模式并使用6秒時間窗。這讓它更加快捷地響應瞬間流量的增長。它也僅僅在恐慌模式下擴容以防止Pod數量快速波動。如果超過60秒沒有發生擴容，Autoscaler會轉換回穩定模式。

3. Build（構建）

Knative的Serving（服務）組件是解決如何從容器到URL的，而Build組件是解決如何從源代碼到容器的。Build資源允許用戶定義如何編譯代碼和構建容器。這确保了在将代碼發送到容器鏡像庫之前以一種一緻的方式編譯和打包代碼。下面介紹一些新的組件。

• Build：驅動構建過程的自定義Kubernetes資源。在定義構建時，用戶需要定義如何
• 獲取源代碼以及如何創建容器鏡像來運行代碼。
• Build Template：封裝可重複構建步驟以及允許對構建進行參數化的模闆。
• Service Account：允許對私有資源（如Git倉庫或容器鏡像庫）進行身份驗證。

4. Event（事件）

到目前為止，向應用程序發送基本的HTTP請求是一種有效使用Knative函數的方式。無服務器的松耦合特性同時也适用于事件驅動架構。也就是說，可能在文件上傳到FTP服務器時需要調用一個函數；或者任何時間發生一筆物品銷售時需要調用一個函數來處理支付和庫存更新的操作。

與其讓應用程序或函數考慮監聽事件的邏輯，不如當那些被關注的事件發生時，讓Knative去處理并通知我們。

自己實現這些功能則需要做很多工作并要編寫實現特定功能的代碼。幸運的是，Knative提供了一個抽象層使消費事件處理變得更容易。

Knative直接提供了一個“事件”，而不需要編寫特定的代碼來選擇消息代理。當事件發生時，應用程序無須關心它來自哪裡或發到哪裡，隻需要知道事件發生了即可。如圖2-17所示，為實現這一目标，Knative引入了三個新的概念：Source（源）、Channel（通道）和Subscription（訂閱）。

• Source（源）：事件的來源，用于定義事件在何處生成以及如何将事件傳遞給關注對象的方式。
• Channel（通道）：通道處理緩沖和持久性，即使該服務已被關閉，也可确保将事件傳遞到預期的服務。另外，通道是代碼和底層消息傳遞解決方案之間的一個抽象層。這意味着可以像Kafka和RabbitMQ一樣在某些服務之間進行消息交換，但在這兩種情況下都不需要編寫特定的實現代碼。
• Subscription（訂閱）：将事件源發送到通道，并準備好處理它們的服務，但目前沒有辦法獲取從通道發送到服務的事件。為此，Knative設計了訂閱功能。訂閱是通道和服務之間的紐帶，指示Knative如何在整個系統中管理事件。

▲圖2-17 Knative事件處理模型簡圖

Knative中的服務不關心事件和請求是如何獲取的。它可以獲取來自入口網關的HTTP請求，也可以獲取從通道發送來的事件。無論通過何種方式獲取，服務僅接收HTTP請求。這是Knative中一個重要的解耦方式。它确保将代碼編寫到架構中，而不是在底層創建訂閱、通道向服務發送事件。

關于作者：劉宇（花名：江昱），國防科技大學電子信息專業博士，阿裡雲Serverless産品體驗側負責人，從事Serverless相關的工作多年，負責阿裡雲函數計算（FC）、Serverless工作流（FNF）等産品的體驗工作，有豐富的實踐經驗。阿裡雲戰略級開源項目Serverless Devs發起人和負責人，Serverless Framework、Kubevela等開源項目貢獻者，社區項目Anycodes在線編程負責人。

本文摘編自《Serverless工程實踐：從入門到進階》，經出版方授權發布。

延伸閱讀《Serverless工程實踐：從入門到進階》

推薦語：從産品、開發和工程實踐3個維度全面講解Serverless架構。阿裡雲Serverless産品專家和技術專家撰寫。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!