![頭圖.jpg](https://ucc.alicdn.com/pic/developer-ecology/cdb15f3c60de4511b9dee85491d4debc.jpg)

作者 | 冬島  阿里巴巴高階技術專家

**Serverless 公眾號後臺回覆 “knative”，即可免費下載《Knative 雲原生應用開發指南》電子書！**

> **導讀：**Serverless 如今已是萬眾期待未來可期的狀態，但一個系統到底具備怎樣的能力才能更好地支撐 Serverless 應用？隨著 Kubernetes 和雲原生概念的崛起，Serverless 在 Kubernetes 之上應該怎麼玩？本文就從 Serverless 應用的核心特質出發，討論作為 Serverless 應用管理平臺應該具備哪些特質。透過本文讓您對 Knative 的 Serverless 應用管理方式有一個深刻的瞭解。

### 為什麼需要 Knative

![1.png](https://ucc.alicdn.com/pic/developer-ecology/f948f806b40e4ed7b2f8e1ef82872fa0.png)

Serverless 已經是萬眾期待，未來可期的狀態。各種調查報告顯示企業及開發者已經在使用 Serverless 構建線上服務，而且這個比例還在不斷增加。

在這個大趨勢下，我們再來看 IaaS 架構的演進方向。最初企業上雲都是基於 VM 的方式在使用雲資源，企業線上服務都是透過 Ansible、Saltstack、Puppet 或者 Chef 等工具裸部在 VM 中的。直接在 VM 中啟動應用，導致線上服務對 VM 的環境配置有很強的依賴，而後伴隨著容器技術的崛起，大家開始透過容器的方式在 VM 中部署應用。

但如果有十幾個甚至幾十個應用需要部署，就需要在成百上千的 VM 快速部署、升級應用，這是一件非常令人頭疼的事情。而 Kubernetes 很好地解決了這些問題，所以現在大家開始透過 Kubernetes 方式使用雲資源。隨著 Kubernetes 的流行，各大雲廠商都開始提供 Serverless Kubernetes 服務，使用者無需維護 Kubernetes 叢集，即可直接透過 Kubernetes 語義使用雲的能力。

既然 Kubernetes 已經非常好了，為什麼還需要 Knative 呢？要回答這個問題，我們先梳理一下 Serverless 應用都有哪些共同特質：

- 按需使用，自動彈性

按需使用雲資源，業務量上漲的時候自動擴容，業務量下降的時候自動縮容，所以需要自動彈效能力。

- 灰度釋出

要能支援多版本管理，應用升級的時候可以使用各種灰度釋出策略上線新的版本。

- 流量管理

能夠管理南北流量，可以按照流量百分比對不同版本進行灰度。

- 負載均衡、服務發現

應用彈性過程中自動增加或者減少例項數量，流量管理需要具備負載均衡和服務發現的功能。

- Gateway

多個應用部署在同一個叢集中，需要一個接入層閘道器對多個應用以及同一個應用的不同版本進行流量的管理。

隨著 Kubernetes 和雲原生概念的崛起，第一直覺可能是直接在 Kubernetes 之上部署 Serverless 應用。那麼，如果要在原生的 Kubernetes 上部署 Serverless 應用我們可能會怎麼做？

![2.png](https://ucc.alicdn.com/pic/developer-ecology/cd76c3cb9356481e907cd2d1fd6a0093.png)

首先需要一個 Deployment 來管理 Workload，還需要透過 Service 對外暴露服務和實現服務發現的能力。應用有重大變更，新版本釋出時可能需要暫停觀察，待觀察確認沒問題之後再繼續增加灰度的比例。這時就要使用兩個 Deployment 才能做到。

v1 Deployment 代表舊版本，灰度的時候逐一減少例項數；v2 Deployment 代表新版本，灰度的時候逐一增加例項數。hpa 代表彈效能力，每一個 Deployment 都有一個 hpa 管理彈性配置。

這其中其實是有衝突的：假設 v1 Deploymen 原本有三個 pod，灰度的時候升級一個 pod 到 v2，此時其實是 1/3 的流量會打到 v2 版本上。但當業務高峰到來後，因為兩個版本都配置了 hpa，所以 v2 和 v1 會同時擴容，最終 v1 和 v2 的 pod 數量就不是最初設定的 1/3 的比例了。

所以傳統的這種按照 Deployment 例項數釋出的灰度策略和彈性配置天然是衝突的。而如果按照流量比例進行灰度就不會有這個問題，這可能就要引入 Istio 的能力。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/f7b3ff9fd26e4e0a91d92e663946e770.png)

引入 Istio 作為 Gateway 元件，Istio 除了管理同一個應用的流量灰度，還能對不同的應用進行流量管理。看起來很好，但是我們再仔細分析一下存在什麼問題。先梳理一下在原生 K8s 之上手動管理 Serverless 應用都需要做什麼：

- Deployment
- Service
- HPA
- Ingress
- Istio
   - VirtualService
   - Gateway

這些資源是每一個應用維護一份，如果是多個應用就要維護多份。這些資源散落在 K8s 內，根本看不出來應用的概念，另外管理起來也非常繁瑣。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/0773d8bf2c4f44b58753ea435e0e1d63.png)

Serverless 應用需要的是面向應用的管理動作，比如應用託管、升級、回滾、灰度釋出、流量管理以及彈性等功能。而 Kubernetes 提供的是 IaaS 的使用抽象。所以 Kubernetes 和 Serverless 應用之間少了一層應用編排的抽象。

而 Knative 就是建立在 Kubernetes 之上的 Serverless 應用編排框架。除了 Knative 以外，社群也有好幾款 FaaS 類的編排框架，但這些框架編排出來的應用沒有統一的標準，每一個框架都有一套自己的規範，而且和 Kubernetes API 完全不相容。不相容的 API 就導致使用難度高、可複製性不強。雲原生的一個核心標準就是 Kubernetes 的 API 標準，Knative 管理的 Serverless 應用保持 Kubernetes API 語義不變。和 Kubernetes API 具有良好的相容性，就是 Knative 的雲原生特性所在。

### Knative 是什麼？

![5.png](https://ucc.alicdn.com/pic/developer-ecology/99b552fc8d404b5983a44eb98863102e.png)

Knative 主要解決的問題就是在 Kubernetes 之上提供通用的 Serverless 編排、排程服務，給上層的 Serverless 應用提供面向應用層的原子操作。並且透過 Kubernetes 原生 API 暴露服務 API，保持和 Kubernetes 生態工具鏈的完美融合。Knative 有 Eventing 和 Serving 兩個核心模組，本文主要介紹 Serving 的核心架構。

#### Knative Serving 簡介

![6.png](https://ucc.alicdn.com/pic/developer-ecology/d17f48294cbb4e3e991dd63f2b37f82f.png)

Serving 核心是 Knative Service，Knative Controller 透過 Service 的配置自動操作 Kubernetes Service 和 Deployment，從而實現簡化應用管理的目標。

Knative Service 對應一個叫做 Configuration 的資源，每次 Service 變化如果需要建立新的 Workload 就更新 Configuration，然後每次 Configuration 更新都會建立一個唯一的 Revision。Revision 可以認為是 Configuration 的版本管理機制。理論上 Revision 建立完以後是不會修改的。

Route 主要負責 Knative 的流量管理，Knative  Route Controller 透過 Route 的配置自動生成 Knative Ingress 配置，Ingress Controller 基於 Ingress 策略實現路由的管理。

Knative Serving 對應用 Workload 的 Serverless 編排是從流量開始的。流量首先達到 Knative 的 Gateway，Gateway 根據 Route 的配置自動把流量根據百分比拆分到不同的 Revision 上，然後每一個 Revision 都有一個自己獨立的彈性策略。當過來的流量請求變多時，當前 Revision 就開始自動擴容。每一個 Revision 的擴容策略都是獨立的，相互不影響。

基於流量百分比對不同的 Revision 進行灰度，每一個 Revision 都有一個獨立的彈性策略。Knative Serving 透過對流量的控制實現了流量管理、彈性和灰度三者的完美結合。接下來具體介紹一下 Knative Serving API 細節。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/091629c81aaf4ef6b4ea991bf0d0d846.png)

上圖展示了 Knative Autoscaler 的工作機制，Route 負責接入流量，Autoscaler 負責做彈性伸縮。當沒有業務請求時會縮容到零，縮容到零後 Route 進來的請求會轉到 Activator 上。當第一個請求進來之後 Activator 會保持住 http 連結，然後通知 Autoscaler 去做擴容。Autoscaler 把第一個 pod 擴容完成以後 Activator 就把流量轉發到 Pod，從而做到了縮容到零也不會損失流量的目的。

到此 [Knative Serving 的核心模組和基本原理](https://knative-sample.com/20-serving/)已經介紹完畢，你應該對 Knative 已經有了初步瞭解。在介紹原理的過程中你可能也感受到了，要想把 Knative 用起來其實還是需要維護很多 Controller 元件、Gateway 元件（比如 Istio)）的，並且要持續地投入 IaaS 成本和運維成本。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/62de9026165d45d5983e272705bf72ac.png)

Gateway 元件假設使用 istio 實現的話，Istio 本身就需要十幾個 Controller，如果要做高可用可能就需要二十幾個 Controller。Knative Serving Controller 全都高可用部署也需要十幾個。這些 Controller 的 IaaS 成本和運維成本都比較多。另外冷啟動問題也很明顯，雖然縮容到零可以降低業務波谷的成本，但是第一批流量也可能會超時。

### Knative 和雲的完美融合

為了解決上述問題，我們把 Knative 和阿里雲做了深度的融合。使用者還是按照 Knative 的原生語義使用，但底層的 Controller 、Gateway 都深度嵌入到阿里雲體系內。這樣既保證了使用者可以無廠商鎖定風險地以 Knative API 使用雲資源，還能享受到阿里雲基礎設施的已有優勢。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/44acf2c99c7245228cb19d01090ad663.png)

首先是 Gateway 和雲的融合，直接使用阿里雲 SLB 作為 Gateway，使用雲產品 SLB 的好處有：

- 雲產品級別的支撐，提供 SLA 保障；
- 按需付費，不需要出 IaaS 資源；
- 使用者無需承擔運維成本，不用考慮高可用問題，雲產品自帶高可用能力。

![10.png](https://ucc.alicdn.com/pic/developer-ecology/2b2e855052314bfb9d45a86c888f2f2c.png)

除了 Gateway 元件以外，Knative Serving Controller 也需要一定的成本，所以我們把 Knative Serving Controller 和阿里雲容器服務也進行了融合。使用者只需要擁有一個 Serverless Kubernetes 叢集並開通 Knative 功能就可以基於 Knative API 使用雲的能力，並且使用者無需為 Knative Controller 付出任何成本。

![11.png](https://ucc.alicdn.com/pic/developer-ecology/6e571e8b85c945e68209c660c7f4e916.png)

接下來再分析一下冷啟動問題。

傳統應用在沒開啟彈性配置的時候例項數是固定的，Knative 管理的 Serverless 應用預設就有彈性策略，在沒有流量的時候會縮容到零。傳統應用在流量低谷時即便沒有業務請求處理，例項數還是保持不變，這其實是浪費資源的。但好處就是請求不會超時，什麼時候過來的請求都可以會很好地處理。而如果縮容到零，第一個請求到達以後才會觸發擴容的過程。

Knative 的模型中從 0 到 1 擴容需要 5 個步驟序列進行，這 5 個步驟都完成以後才能開始處理第一個請求，而此時往往都會超時。所以 Knative 縮容到零雖然降低了常駐資源的成本，但第一批請求的冷啟動問題也非常明顯。可見彈性其實就是在尋找成本和效率的一個平衡點。

![12.png](https://ucc.alicdn.com/pic/developer-ecology/3a66e3664b5b4e20957a74b7dbb232a5.png)

為了解決第一個例項的冷啟動問題，我們推出了保留例項功能。保留例項是阿里雲容器服務 Knative 獨有的功能。社群的 Knative 預設在沒有流量時縮容到零，但是縮容到零之後從 0 到 1 的冷啟動問題很難解決。冷啟動除了要解決 IaaS 資源的分配、Kubernetes 的排程、拉映象等問題以外，還涉及到應用的啟動時長。應用啟動時長從毫秒到分鐘級別都有。應用啟動時間完全是業務行為，在底層平臺層面幾乎無法控制。

ASK Knative 對這個問題的解法是透過低價格的保留例項，來平衡成本和冷啟動問題。阿里雲 ECI 有很多規格，不同規格的計算能力不一樣，價格也不一樣。如下所示是對 2c4G 配置的計算型例項和突發效能型例項的價格對比。

![13.png](https://ucc.alicdn.com/pic/developer-ecology/6ac7e315373f4e79914a3a1656346924.png)

透過上圖可知突發效能例項比計算型便宜 46%，可見如果在沒有流量時，使用突發效能例項提供服務不單單解決了冷啟動的問題，還能節省很多成本。

突發效能例項除了價格優勢以外，還有一個非常亮眼的功能就是 CPU 積分。突發效能例項可以利用 CPU 積分應對突發效能需求。突發效能例項可以持續獲得 CPU 積分，在效能無法滿足負載要求時，可以透過消耗積累的 CPU 積分無縫提高計算效能，不會影響部署在例項上的環境和應用。透過 CPU 積分，您可以從整體業務角度分配計算資源，將業務平峰期剩餘的計算能力無縫轉移到高峰期使用（簡單的理解就是油電混動）。突發效能例項的更多細節參見[這裡](https://help.aliyun.com/document_detail/59977.html)。

所以 ASK Knative 的策略是在業務波谷時使用突發效能例項替換標準的計算型例項，當第一個請求來臨時再無縫切換到標準的計算型例項。這樣可以降低流量低谷的成本，並且在低谷時獲得的 CPU 積分，還能在業務高峰到來時消費掉，使用者支付的每一分錢都不會浪費。

使用突發效能例項作為保留例項只是預設策略，使用者可以指定自己期望的其他型別例項作為保留例項的規格。當然使用者也可以指定最小保留一個標準例項，從而關閉保留例項的功能。

### 總結

Knative 是 Kubernetes 生態最流行的 Serverless 編排框架。社群原生的 Knative 需要常駐的 Controller 和常駐的閘道器才能提供服務。這些常駐例項除了需要支付 IaaS 成本以外還帶來了很多運維負擔，給應用的 Serverless 化帶來了一定的難度，因此我們在 ASK 中完全託管了 Knative Serving，開箱即用極致的 Serverless 體驗。

### 課程推薦

為了更多開發者能夠享受到 Serverless 帶來的紅利，這一次，我們集結了 10+ 位阿里巴巴 Serverless 領域技術專家，打造出最適合開發者入門的 Serverless 公開課，讓你即學即用，輕鬆擁抱雲端計算的新正規化——Serverless。

[點選即可免費觀看課程：https://developer.aliyun.com/learning/roadmap/serverless](https://developer.aliyun.com/learning/roadmap/serverless)

> [Serverless 公眾號](https://mp.weixin.qq.com/s/CQvsc-PfgGtUjKEBfee_IA)，釋出 Serverless 技術最新資訊，彙集 Serverless 技術最全內容，關注 Serverless 趨勢，更關注你落地實踐中的遇到的困惑和問題。

從零入門 Serverless | Knative 帶來的極致 Serverless 體驗

相關文章