做者 | 冬島 阿里巴巴高級技術專家 來源 | Serverless 公衆號html
導讀：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 語義使用雲的能力。less
既然 Kubernetes 已經很是好了，爲何還須要 Knative 呢？要回答這個問題，咱們先梳理一下 Serverless 應用都有哪些共同特質：運維
- 按需使用，自動彈性
按需使用雲資源，業務量上漲的時候自動擴容，業務量降低的時候自動縮容，因此須要自動彈性能力。工具
- 灰度發佈
要能支持多版本管理，應用升級的時候可使用各類灰度發佈策略上線新的版本。性能
- 流量管理
可以管理南北流量，能夠按照流量百分比對不一樣版本進行灰度。阿里雲
- 負載均衡、服務發現
應用彈性過程當中自動增長或者減小實例數量，流量管理須要具有負載均衡和服務發現的功能。3d
- 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
- Gateway
這些資源是每個應用維護一份，若是是多個應用就要維護多份。這些資源散落在 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 的冷啓動問題
接下來再分析一下冷啓動問題。傳統應用在沒開啓彈性配置的時候實例數是固定的，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 公衆號，發佈 Serverless 技術最新資訊，聚集 Serverless 技術最全內容，關注 Serverless 趨勢，更關注你落地實踐中的遇到的困惑和問題。