Serverless 如今已是萬衆期待未來可期的狀态，但一個系統到底具備怎樣的能力才能更好地支撐 Serverless 應用？随着 Kubernetes 和雲原生概念的崛起，Serverless 在 Kubernetes 之上應該怎麼玩？本文就從 Serverless 應用的核心特質出發，讨論作為 Serverless 應用管理平台應該具備哪些特質。通過本文讓您對 Knative 的 Serverless 應用管理方式有一個深刻的了解。
作者 | 冬島 阿裡巴巴進階技術專家
Serverless 公衆号背景回複 “knative”，即可免費下載下傳《Knative 雲原生應用開發指南》電子書！
導讀：Serverless 如今已是萬衆期待未來可期的狀态，但一個系統到底具備怎樣的能力才能更好地支撐 Serverless 應用？随着 Kubernetes 和雲原生概念的崛起，Serverless 在 Kubernetes 之上應該怎麼玩？本文就從 Serverless 應用的核心特質出發，讨論作為 Serverless 應用管理平台應該具備哪些特質。通過本文讓您對 Knative 的 Serverless 應用管理方式有一個深刻的了解。
為什麼需要 Knative
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 應用我們可能會怎麼做？
首先需要一個 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 的能力。
引入 Istio 作為 Gateway 元件，Istio 除了管理同一個應用的流量灰階，還能對不同的應用進行流量管理。看起來很好，但是我們再仔細分析一下存在什麼問題。先梳理一下在原生 K8s 之上手動管理 Serverless 應用都需要做什麼：
- Deployment
- Service
- HPA
- Ingress
- Istio
- VirtualService
這些資源是每一個應用維護一份，如果是多個應用就要維護多份。這些資源散落在 K8s 内，根本看不出來應用的概念，另外管理起來也非常繁瑣。
Serverless 應用需要的是面向應用的管理動作，比如應用托管、更新、復原、灰階釋出、流量管理以及彈性等功能。而 Kubernetes 提供的是 IaaS 的使用抽象。是以 Kubernetes 和 Serverless 應用之間少了一層應用編排的抽象。
而 Knative 就是建立在 Kubernetes 之上的 Serverless 應用編排架構。除了 Knative 以外，社群也有好幾款 FaaS 類的編排架構，但這些架構編排出來的應用沒有統一的标準，每一個架構都有一套自己的規範，而且和 Kubernetes API 完全不相容。不相容的 API 就導緻使用難度高、可複制性不強。雲原生的一個核心标準就是 Kubernetes 的 API 标準，Knative 管理的 Serverless 應用保持 Kubernetes API 語義不變。和 Kubernetes API 具有良好的相容性，就是 Knative 的雲原生特性所在。
Knative 是什麼？
Knative 主要解決的問題就是在 Kubernetes 之上提供通用的 Serverless 編排、排程服務，給上層的 Serverless 應用提供面向應用層的原子操作。并且通過 Kubernetes 原生 API 暴露服務 API，保持和 Kubernetes 生态工具鍊的完美融合。Knative 有 Eventing 和 Serving 兩個核心子產品，本文主要介紹 Serving 的核心架構。
Knative Serving 簡介
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 細節。
上圖展示了 Knative Autoscaler 的工作機制，Route 負責接入流量，Autoscaler 負責做彈性伸縮。當沒有業務請求時會縮容到零，縮容到零後 Route 進來的請求會轉到 Activator 上。當第一個請求進來之後 Activator 會保持住 http 連結，然後通知 Autoscaler 去做擴容。Autoscaler 把第一個 pod 擴容完成以後 Activator 就把流量轉發到 Pod，進而做到了縮容到零也不會損失流量的目的。
到此 Knative Serving 的核心子產品和基本原理已經介紹完畢，你應該對 Knative 已經有了初步了解。在介紹原理的過程中你可能也感受到了，要想把 Knative 用起來其實還是需要維護很多 Controller 元件、Gateway 元件（比如 Istio)）的，并且要持續地投入 IaaS 成本和運維成本。
Gateway 元件假設使用 istio 實作的話，Istio 本身就需要十幾個 Controller，如果要做高可用可能就需要二十幾個 Controller。Knative Serving Controller 全都高可用部署也需要十幾個。這些 Controller 的 IaaS 成本和運維成本都比較多。另外冷啟動問題也很明顯，雖然縮容到零可以降低業務波谷的成本，但是第一批流量也可能會逾時。
Knative 和雲的完美融合
為了解決上述問題，我們把 Knative 和阿裡雲做了深度的融合。使用者還是按照 Knative 的原生語義使用，但底層的 Controller 、Gateway 都深度嵌入到阿裡雲體系内。這樣既保證了使用者可以無廠商鎖定風險地以 Knative API 使用雲資源，還能享受到阿裡雲基礎設施的已有優勢。
首先是 Gateway 和雲的融合，直接使用阿裡雲 SLB 作為 Gateway，使用雲産品 SLB 的好處有：
- 雲産品級别的支撐，提供 SLA 保障；
- 按需付費，不需要出 IaaS 資源；
- 使用者無需承擔運維成本，不用考慮高可用問題，雲産品自帶高可用能力。
除了 Gateway 元件以外，Knative Serving Controller 也需要一定的成本，是以我們把 Knative Serving Controller 和阿裡雲容器服務也進行了融合。使用者隻需要擁有一個 Serverless Kubernetes 叢集并開通 Knative 功能就可以基于 Knative API 使用雲的能力，并且使用者無需為 Knative Controller 付出任何成本。
接下來再分析一下冷啟動問題。
傳統應用在沒開啟彈性配置的時候執行個體數是固定的，Knative 管理的 Serverless 應用預設就有彈性政策，在沒有流量的時候會縮容到零。傳統應用在流量低谷時即便沒有業務請求處理，執行個體數還是保持不變，這其實是浪費資源的。但好處就是請求不會逾時，什麼時候過來的請求都可以會很好地處理。而如果縮容到零，第一個請求到達以後才會觸發擴容的過程。
Knative 的模型中從 0 到 1 擴容需要 5 個步驟串行進行，這 5 個步驟都完成以後才能開始處理第一個請求，而此時往往都會逾時。是以 Knative 縮容到零雖然降低了常駐資源的成本，但第一批請求的冷啟動問題也非常明顯。可見彈性其實就是在尋找成本和效率的一個平衡點。
為了解決第一個執行個體的冷啟動問題，我們推出了保留執行個體功能。保留執行個體是阿裡雲容器服務 Knative 獨有的功能。社群的 Knative 預設在沒有流量時縮容到零，但是縮容到零之後從 0 到 1 的冷啟動問題很難解決。冷啟動除了要解決 IaaS 資源的配置設定、Kubernetes 的排程、拉鏡像等問題以外，還涉及到應用的啟動時長。應用啟動時長從毫秒到分鐘級别都有。應用啟動時間完全是業務行為，在底層平台層面幾乎無法控制。
ASK Knative 對這個問題的解法是通過低價格的保留執行個體，來平衡成本和冷啟動問題。阿裡雲 ECI 有很多規格，不同規格的計算能力不一樣，價格也不一樣。如下所示是對 2c4G 配置的計算型執行個體和突發性能型執行個體的價格對比。
通過上圖可知突發性能執行個體比計算型便宜 46%，可見如果在沒有流量時，使用突發性能執行個體提供服務不單單解決了冷啟動的問題，還能節省很多成本。
突發性能執行個體除了價格優勢以外，還有一個非常亮眼的功能就是 CPU 積分。突發性能執行個體可以利用 CPU 積分應對突發性能需求。突發性能執行個體可以持續獲得 CPU 積分，在性能無法滿足負載要求時，可以通過消耗積累的 CPU 積分無縫提高計算性能，不會影響部署在執行個體上的環境和應用。通過 CPU 積分，您可以從整體業務角度配置設定計算資源，将業務平峰期剩餘的計算能力無縫轉移到高峰期使用（簡單的了解就是油電混動）。突發性能執行個體的更多細節參見這裡。
是以 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
Serverless 公衆号，釋出 Serverless 技術最新資訊，彙集 Serverless 技術最全内容，關注 Serverless 趨勢，更關注你落地實踐中的遇到的困惑和問題。