作者 | 冬島 阿里巴巴高級技術(shù)專家

Serverless 公眾號后臺回復(fù) “knative”，即可免費下載《Knative 云原生應(yīng)用開發(fā)指南》電子書！

**導(dǎo)讀：**Serverless 如今已是萬眾期待未來可期的狀態(tài)，但一個系統(tǒng)到底具備怎樣的能力才能更好地支撐 Serverless 應(yīng)用？隨著 Kubernetes 和云原生概念的崛起，Serverless 在 Kubernetes 之上應(yīng)該怎么玩？本文就從 Serverless 應(yīng)用的核心特質(zhì)出發(fā)，討論作為 Serverless 應(yīng)用管理平臺應(yīng)該具備哪些特質(zhì)。通過本文讓您對 Knative 的 Serverless 應(yīng)用管理方式有一個深刻的了解。

為什么需要 Knative

Serverless 已經(jīng)是萬眾期待，未來可期的狀態(tài)。各種調(diào)查報告顯示企業(yè)及開發(fā)者已經(jīng)在使用 Serverless 構(gòu)建線上服務(wù)，而且這個比例還在不斷增加。

在這個大趨勢下，我們再來看 IaaS 架構(gòu)的演進方向。最初企業(yè)上云都是基于 VM 的方式在使用云資源，企業(yè)線上服務(wù)都是通過 Ansible、Saltstack、Puppet 或者 Chef 等工具裸部在 VM 中的。直接在 VM 中啟動應(yīng)用，導(dǎo)致線上服務(wù)對 VM 的環(huán)境配置有很強的依賴，而后伴隨著容器技術(shù)的崛起，大家開始通過容器的方式在 VM 中部署應(yīng)用。

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

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

• 按需使用，自動彈性

按需使用云資源，業(yè)務(wù)量上漲的時候自動擴容，業(yè)務(wù)量下降的時候自動縮容，所以需要自動彈性能力。

• 灰度發(fā)布

要能支持多版本管理，應(yīng)用升級的時候可以使用各種灰度發(fā)布策略上線新的版本。

• 流量管理

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

• 負(fù)載均衡、服務(wù)發(fā)現(xiàn)

應(yīng)用彈性過程中自動增加或者減少實例數(shù)量，流量管理需要具備負(fù)載均衡和服務(wù)發(fā)現(xiàn)的功能。

• Gateway

多個應(yīng)用部署在同一個集群中，需要一個接入層網(wǎng)關(guān)對多個應(yīng)用以及同一個應(yīng)用的不同版本進行流量的管理。

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

首先需要一個 Deployment 來管理 Workload，還需要通過 Service 對外暴露服務(wù)和實現(xiàn)服務(wù)發(fā)現(xiàn)的能力。應(yīng)用有重大變更，新版本發(fā)布時可能需要暫停觀察，待觀察確認(rèn)沒問題之后再繼續(xù)增加灰度的比例。這時就要使用兩個 Deployment 才能做到。

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

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

所以傳統(tǒng)的這種按照 Deployment 實例數(shù)發(fā)布的灰度策略和彈性配置天然是沖突的。而如果按照流量比例進行灰度就不會有這個問題，這可能就要引入 Istio 的能力。

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

• Deployment
• Service
• HPA
• Ingress
• Istio
  • VirtualService
  • Gateway

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

Serverless 應(yīng)用需要的是面向應(yīng)用的管理動作，比如應(yīng)用托管、升級、回滾、灰度發(fā)布、流量管理以及彈性等功能。而 Kubernetes 提供的是 IaaS 的使用抽象。所以 Kubernetes 和 Serverless 應(yīng)用之間少了一層應(yīng)用編排的抽象。

而 Knative 就是建立在 Kubernetes 之上的 Serverless 應(yīng)用編排框架。除了 Knative 以外，社區(qū)也有好幾款 FaaS 類的編排框架，但這些框架編排出來的應(yīng)用沒有統(tǒng)一的標(biāo)準(zhǔn)，每一個框架都有一套自己的規(guī)范，而且和 Kubernetes API 完全不兼容。不兼容的 API 就導(dǎo)致使用難度高、可復(fù)制性不強。云原生的一個核心標(biāo)準(zhǔn)就是 Kubernetes 的 API 標(biāo)準(zhǔn)，Knative 管理的 Serverless 應(yīng)用保持 Kubernetes API 語義不變。和 Kubernetes API 具有良好的兼容性，就是 Knative 的云原生特性所在。

Knative 是什么？

Knative 主要解決的問題就是在 Kubernetes 之上提供通用的 Serverless 編排、調(diào)度服務(wù)，給上層的 Serverless 應(yīng)用提供面向應(yīng)用層的原子操作。并且通過 Kubernetes 原生 API 暴露服務(wù) API，保持和 Kubernetes 生態(tài)工具鏈的完美融合。Knative 有 Eventing 和 Serving 兩個核心模塊，本文主要介紹 Serving 的核心架構(gòu)。

Knative Serving 簡介

Serving 核心是 Knative Service，Knative Controller 通過 Service 的配置自動操作 Kubernetes Service 和 Deployment，從而實現(xiàn)簡化應(yīng)用管理的目標(biāo)。

Knative Service 對應(yīng)一個叫做 Configuration 的資源，每次 Service 變化如果需要創(chuàng)建新的 Workload 就更新 Configuration，然后每次 Configuration 更新都會創(chuàng)建一個唯一的 Revision。Revision 可以認(rèn)為是 Configuration 的版本管理機制。理論上 Revision 創(chuàng)建完以后是不會修改的。

Route 主要負(fù)責(zé) Knative 的流量管理，Knative ?Route Controller 通過 Route 的配置自動生成 Knative Ingress 配置，Ingress Controller 基于 Ingress 策略實現(xiàn)路由的管理。

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

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

上圖展示了 Knative Autoscaler 的工作機制，Route 負(fù)責(zé)接入流量，Autoscaler 負(fù)責(zé)做彈性伸縮。當(dāng)沒有業(yè)務(wù)請求時會縮容到零，縮容到零后 Route 進來的請求會轉(zhuǎn)到 Activator 上。當(dāng)?shù)谝粋€請求進來之后 Activator 會保持住 http 鏈接，然后通知 Autoscaler 去做擴容。Autoscaler 把第一個 pod 擴容完成以后 Activator 就把流量轉(zhuǎn)發(fā)到 Pod，從而做到了縮容到零也不會損失流量的目的。

到此 Knative Serving 的核心模塊和基本原理已經(jīng)介紹完畢，你應(yīng)該對 Knative 已經(jīng)有了初步了解。在介紹原理的過程中你可能也感受到了，要想把 Knative 用起來其實還是需要維護很多 Controller 組件、Gateway 組件（比如 Istio)）的，并且要持續(xù)地投入 IaaS 成本和運維成本。

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

Knative 和云的完美融合

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

首先是 Gateway 和云的融合，直接使用阿里云 SLB 作為 Gateway，使用云產(chǎn)品 SLB 的好處有：

• 云產(chǎn)品級別的支撐，提供 SLA 保障；
• 按需付費，不需要出 IaaS 資源；
• 用戶無需承擔(dān)運維成本，不用考慮高可用問題，云產(chǎn)品自帶高可用能力。

除了 Gateway 組件以外，Knative Serving Controller 也需要一定的成本，所以我們把 Knative Serving Controller 和阿里云容器服務(wù)也進行了融合。用戶只需要擁有一個 Serverless Kubernetes 集群并開通 Knative 功能就可以基于 Knative API 使用云的能力，并且用戶無需為 Knative Controller 付出任何成本。

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

傳統(tǒng)應(yīng)用在沒開啟彈性配置的時候?qū)嵗龜?shù)是固定的，Knative 管理的 Serverless 應(yīng)用默認(rèn)就有彈性策略，在沒有流量的時候會縮容到零。傳統(tǒng)應(yīng)用在流量低谷時即便沒有業(yè)務(wù)請求處理，實例數(shù)還是保持不變，這其實是浪費資源的。但好處就是請求不會超時，什么時候過來的請求都可以會很好地處理。而如果縮容到零，第一個請求到達以后才會觸發(fā)擴容的過程。

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

為了解決第一個實例的冷啟動問題，我們推出了保留實例功能。保留實例是阿里云容器服務(wù) Knative 獨有的功能。社區(qū)的 Knative 默認(rèn)在沒有流量時縮容到零，但是縮容到零之后從 0 到 1 的冷啟動問題很難解決。冷啟動除了要解決 IaaS 資源的分配、Kubernetes 的調(diào)度、拉鏡像等問題以外，還涉及到應(yīng)用的啟動時長。應(yīng)用啟動時長從毫秒到分鐘級別都有。應(yīng)用啟動時間完全是業(yè)務(wù)行為，在底層平臺層面幾乎無法控制。

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

通過上圖可知突發(fā)性能實例比計算型便宜 46%，可見如果在沒有流量時，使用突發(fā)性能實例提供服務(wù)不單單解決了冷啟動的問題，還能節(jié)省很多成本。

突發(fā)性能實例除了價格優(yōu)勢以外，還有一個非常亮眼的功能就是 CPU 積分。突發(fā)性能實例可以利用 CPU 積分應(yīng)對突發(fā)性能需求。突發(fā)性能實例可以持續(xù)獲得 CPU 積分，在性能無法滿足負(fù)載要求時，可以通過消耗積累的 CPU 積分無縫提高計算性能，不會影響部署在實例上的環(huán)境和應(yīng)用。通過 CPU 積分，您可以從整體業(yè)務(wù)角度分配計算資源，將業(yè)務(wù)平峰期剩余的計算能力無縫轉(zhuǎn)移到高峰期使用（簡單的理解就是油電混動）。突發(fā)性能實例的更多細節(jié)參見這里。

所以 ASK Knative 的策略是在業(yè)務(wù)波谷時使用突發(fā)性能實例替換標(biāo)準(zhǔn)的計算型實例，當(dāng)?shù)谝粋€請求來臨時再無縫切換到標(biāo)準(zhǔn)的計算型實例。這樣可以降低流量低谷的成本，并且在低谷時獲得的 CPU 積分，還能在業(yè)務(wù)高峰到來時消費掉，用戶支付的每一分錢都不會浪費。

使用突發(fā)性能實例作為保留實例只是默認(rèn)策略，用戶可以指定自己期望的其他類型實例作為保留實例的規(guī)格。當(dāng)然用戶也可以指定最小保留一個標(biāo)準(zhǔn)實例，從而關(guān)閉保留實例的功能。

總結(jié)

Knative 是 Kubernetes 生態(tài)最流行的 Serverless 編排框架。社區(qū)原生的 Knative 需要常駐的 Controller 和常駐的網(wǎng)關(guān)才能提供服務(wù)。這些常駐實例除了需要支付 IaaS 成本以外還帶來了很多運維負(fù)擔(dān)，給應(yīng)用的 Serverless 化帶來了一定的難度，因此我們在 ASK 中完全托管了 Knative Serving，開箱即用極致的 Serverless 體驗。

課程推薦

為了更多開發(fā)者能夠享受到 Serverless 帶來的紅利，這一次，我們集結(jié)了 10+ 位阿里巴巴 Serverless 領(lǐng)域技術(shù)專家，打造出最適合開發(fā)者入門的 Serverless 公開課，讓你即學(xué)即用，輕松擁抱云計算的新范式——Serverless。

點擊即可免費觀看課程：https://developer.aliyun.com/learning/roadmap/serverless

Serverless 公眾號，發(fā)布 Serverless 技術(shù)最新資訊，匯集 Serverless 技術(shù)最全內(nèi)容，關(guān)注 Serverless 趨勢，更關(guān)注你落地實踐中的遇到的困惑和問題。

總結(jié)

以上是生活随笔為你收集整理的从零入门 Serverless | Knative 带来的极致 Serverless 体验的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。