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

導讀：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
• 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 管理的 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 趨勢，更關注你落地實踐中的遇到的困惑和問題。

總結

以上是生活随笔為你收集整理的基于 Knative 低成本部署在线应用，灵活自动伸缩的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。