開箱即用，Knative 給您極緻的容器 Serverless 體驗

托管 Knative 開箱即用，您不需要為這些常駐執行個體付出任何成本。結合 SLB 雲産品提供 Gateway 的能力以及基于突發性能型執行個體的保留規格功能，極大的節省您的 IaaS 開支，您支付的每一分錢都沒有浪費。

作者 | 冬島  阿裡巴巴技術專家

導讀：托管 Knative 開箱即用，您不需要為這些常駐執行個體付出任何成本。結合 SLB 雲産品提供 Gateway 的能力以及基于突發性能型執行個體的保留規格功能，極大的節省您的 IaaS 開支，您支付的每一分錢都沒有浪費。

<關注阿裡巴巴雲原生公衆号，回複 報告 即可下載下傳完整調查報告>

CNCF 釋出的年度調查報告顯示 2019 年 Serverless 技術進一步獲得了更大的認可。其中 41% 的受訪者表示已經在使用 Serverless，另外 20% 的受訪者表示計劃在未來 12-18 個月内會采用 Serverless 技術。而在衆多開源的 Serverless 項目中 Knative 是最受歡迎的一個。如下圖所示， Knative 占據了 34% 的份額，遙遙領先于第二名 OpenFaaS，Knative 是自己搭建 Serverless 平台的首選。

Knative 之是以這麼受歡迎和容器的生态不無關系。和 FaaS 模式不同的是 Knative 不要求使用者對應用做非常大的改造，隻要使用者的應用完成了容器化就能部署在 Knative 中。并且 Knative 在 Kubernetes 之上提供了更聚焦的應用模型，讓使用者無需為應用的更新、流量灰階花費精力，這一切都是自動完成的。

雲主機的發展曆程

在雲計算出現之前，企業想要在網際網路上對外提供服務需要先在 IDC 租賃實體機，然後再把應用部署在 IDC 的實體機上。而實體機的性能在過去十幾年裡始終保持着摩爾定律的速度在增長。這就導緻單個應用根本無法充分利用整個實體機的資源。是以就需要有一種技術解決資源使用率的問題。簡單的想如果一個應用不夠就多部署幾個。但在同一個實體機下多個應用混合部署會帶來很多問題，比如：

• 端口沖突
• 資源隔離
• 系統依賴以及運維困難

虛拟機的出現就很好的解決了上述問題，通過虛拟機技術可以在同一個實體機上虛拟出多個主機，每一個主機隻部署一個應用，這樣一台實體機不但可以部署多個應用，還能保證應用之間的獨立性。

随着企業的發展，一家企業可能會維護很多應用。而每一個應用需要很多的釋出、更新、復原等操作，同時這些應用可能還需要在不同的地域分别部署一套。這就帶來了很多運維負擔，這些運維難題首當其沖的就是應用的運作環境。是以後來出現了容器技術，容器技術通過核心級别的輕量級隔離能力不但具備與 VM 幾乎同等的隔離體驗，還帶來了一個巨大的創新就是容器鏡像。通過容器鏡像可以非常容易的複制應用的運作環境，開發人員隻需要把應用的依賴都做到鏡像中，當鏡像運作的時候直接使用自帶的依賴提供服務。這就解決了應用釋出、更新和復原以及多地域部署等過程中的運作環境問題。

當人們開始大規模使用容器技術之後發現大大減輕了維護執行個體運作環境的負擔，此時最大的問題就是應用多執行個體的協調以及多個應用之間的協調。是以容器技術普及不久 Kubernetes 就出現了，和以往的 VM、容器技術不同，Kubernetes 天然就是一個分布式面向終态的設計，不是單機上的能力。Kubernetes 對 IaaS 的資源配置設定抽象了更友好的 API，使用者無需關心具體的配置設定細節，Kubernetes Controller 會根據面向終态的生命自動完成配置設定和故障轉移以及負載均衡等。這使得應用開發人員無需關心具體的執行個體是運作在哪裡，隻要在需要的時候 Kubernetes 能夠配置設定出資源即可。

無論是早期的實體機模式，還是現在的 Kubernetes 模式，應用開發者本身其實并不想管理什麼底層資源，應用開發者隻是想要把應用跑起來而已。在實體機模式中人們需要獨占實體機，在 Kubernetes 模式中其實人們并不關心自己的業務程序是跑在哪個實體機上，事實上也無法提前預知。隻要應用能夠跑起來就好，至于是在哪兒運作的其實已不重要。實體機 -> 虛拟機 -> 容器 -> Kubernetes ，整個過程其實都是在簡化應用使用 IaaS 資源的門檻。在這個演進過程可以發現一個清晰的脈絡，IaaS 和應用之間的耦合越來越低，基礎平台隻要做到在應用需要運作的時候給應用配置設定相應的 IaaS 資源即可，應用管理者隻是 IaaS 的使用者，并不需要感覺 IaaS 配置設定的細節。

Knative Serving

在介紹 Knative 之前咱們先通過一個 web 應用看一下通過 Kubernetes 做流量接入、應用釋出和 Knative 做流量接入、應用釋出的差别。如下圖所示，在左側是 Kubernetes 模式，右側是 Knative 模式。

• 在 Kubernetes 模式下：1. 使用者需要自己管理 Ingress Controller；2. 要對外暴露服務需要維護 Ingress 和 Service 的關系；3. 釋出時如果想要做灰階觀察需要使用多個 Deployment 輪轉才能完成更新；
• 在 Knative 模式下：使用者隻需要維護一個 Knative Service 資源即可。

當然 Knative 并不能完全替代 Kubernetes ，Knative 是建立在 Kubernetes 能力之上的。Kubernetes 和 Knative 除了使用者需要直接管理的資源不同，其實還有一個巨大的理念差異:

Kubernetes 的作用是解耦 IaaS 和應用，降低 IaaS 資源配置設定的成本，Kubernetes 主要聚焦于 IaaS 資源的編排。而 Knative 是更偏向應用層，是以彈性為核心的應用編排。

Knative 是一款基于 Kubernetes 的 Serverless 編排引擎，其目标是制定雲原生、跨平台的 Serverless 編排标準。Knative 通過整合容器建構、工作負載管理（動态擴縮）以及事件模型這三者來實作的這一 Serverless 标準。Serving 正是運作 Serverless 工作負載的核心子產品。

• 應用托管
  • Kubernetes 是面向 IaaS 管理的抽象，通過 Kubernetes 直接部署應用需要維護的資源比較多
  • 通過 Knative Service 一個資源就能定義應用的托管
• 流量管理
  • Knative 通過 Gateway 結果應用流量，然後可以對流量按百分比進行分割，這為彈性、灰階等基礎能力做好了基礎
• 灰階釋出
  • 支援多版本管理，應用同時有多個版本線上提供服務很容易實作
  • 不同版本可以設定不同的流量百分比，對灰階釋出等功能實作起來很容易
• 彈性
  • Knative 幫助應用節省成本的核心能力是彈性，在流量增加的時候自動擴容，流量下降的時候自動縮容
  • 每一個灰階的版本都有自己的彈性政策，并且彈性政策和配置設定到目前版本的流量是相關聯的。Knative 會根據配置設定過來的流量多少進行擴容或者縮容的決策

Knative 更多介紹請移步這裡或這裡了解更多。

為什麼是 ASK

社群的 Kubernetes 需要您提前購買主機并注冊成 Kubernetes 節點才能排程 Pod，提前購買主機這其實不符合應用的使用邏輯，應用開發人員隻是想在需要運作應用執行個體的時候配置設定出 IaaS 資源即可，并不想維護繁雜的 IaaS 資源。是以如果存在一種 Kubernetes 和社群的 Kubernetes API 完全相容，但是不需要自己運維管理複雜的 IaaS 資源，在需要的時候可以自動配置設定出資源，這更符合應用的對資源的使用理念。ASK 就是秉持這樣的理念給您帶來 Serverless Kubernetes 的使用體驗。

ASK 的全稱是 Serverless Kubernetes，是一種無伺服器的 Kubernetes 叢集，使用者無需購買節點即可直接部署容器應用，無需對叢集進行節點維護和容量規劃，并且根據應用配置的 CPU 和記憶體資源量進行按需付費。ASK 叢集提供完善的 Kubernetes 相容能力，同時極大降低了 Kubernetes 使用門檻，讓使用者更專注于應用程式，而不是管理底層基礎設施。

也就是說您無需提前準備 ECS 資源，即可直接建立一個 Kubernetes 叢集，然後就能部署自己的服務了。關于 ASK 更詳細的介紹參見這裡。

前面分析 Serverless 曆程的時候咱們總結出來的 Serverless 發展主脈絡其實就是 IaaS 和應用之間的耦合越來越低，基礎平台隻要做到在應用需要運作的時候給應用配置設定相應的 IaaS 資源即可，應用管理者隻是 IaaS 的使用者，并不需要感覺 IaaS 配置設定的細節。ASK 就是這個随時配置設定 IaaS 資源的平台，Knative 負責感覺應用的實時狀态，在需要的時候自動從 ASK 中“申請”IaaS 資源(Pod)。Knative 和 ASK 的結合可以給您帶來更極緻的 Serverless 體驗。

關于 ASK 更深入的介紹請參見 《Serverless Kubernetes - 理想，現實與未來》。

亮點介紹

基于 SLB 的 Gateway

Knative 社群預設支援 Istio、Gloo、Contour、Kourier 和 ambassador 等多種 Gateway 實作。在這些衆多的實作中 Istio 當然是最流行的一個，因為 Istio 除了可以充當 Gateway 的角色還能做 ServiceMesh 服務使用。這些 Gateway 雖然功能完備但是作為 Serverless 服務的 Gateway 就有點兒違背初衷。首先需要有 Gateway 執行個體常駐運作，而為了保證高可用至少要有兩個執行個體互為備份。其次這些 Gateway 的管控端也需要常駐運作，這些常駐執行個體的 IaaS 費用和運維都是業務需要支付的成本。

為了給使用者提供極緻的 Serverless 體驗，我們通過阿裡雲 SLB 實作了 Knative  Gateway，所有需要的功能都具備而且是雲産品級别的支撐。不需要常駐資源不但節省了您的 IaaS 成本還省去了很多運維負擔。

低成本的保留執行個體

保留執行個體是 ASK Knative 獨有的功能。社群的 Knative 預設在沒有流量的時候可以縮容到零，但是縮容到零之後從零到一的冷啟動問題很難解決。冷啟動除了要解決 IaaS 資源的配置設定、Kubernetes 的排程、拉鏡像等問題以外還涉及到應用的啟動時長。應用啟動時長從毫秒到分鐘級别都有，這在通用的平台層面幾乎無法控制。當然這些問題在所有的 serverless 産品中都存在。傳統 FaaS 産品大多都是通過維護一個公共的 IaaS 池子運作不同的函數，為了保護這個池子不會被打滿、和極低的冷啟動時間，FaaS 産品的解法大多是對使用者的函數做各種限制。比如：

• 處理請求的逾時時間：如果超過這個時間沒起來就認為失敗；
• 突增并發：預設所有函數都有一個并發上限，請求量超過這個上限就會被限流；
• CPU 以及記憶體：不能超過 CPU 和記憶體的上限。

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

通過上面的對比可知突發性能執行個體比計算型便宜 46%，可見如果在沒有流量的時候使用突發性能執行個體提供服務不單單解決了冷啟動的問題還能節省很多成本。

突發性能執行個體除了價格優勢以外還有一個非常亮眼的功能就是 CPU 積分。突發性能執行個體可以利用 CPU 積分應對突發性能需求。突發性能執行個體可以持續獲得 CPU 積分，在性能無法滿足負載要求時，可以通過消耗積累的 CPU 積分無縫提高計算性能，不會影響部署在執行個體上的環境和應用。通過 CPU 積分，您可以從整體業務角度配置設定計算資源，将業務平峰期剩餘的計算能力無縫轉移到高峰期使用(簡單的了解就是油電混動啦☺️☺️)。突發性能執行個體的更多細節參見這裡。

是以 ASK Knative 的政策是在業務波谷時使用突發性能執行個體替換标準的計算型執行個體，當第一個請求來臨時再無縫切換到标準的計算型執行個體。這樣可以幫助您降低流量低谷的成本，并且在低谷時獲得的 CPU 積分還能在業務高峰到來時消費掉，您支付的每一分錢都沒有浪費。

使用突發性能執行個體作為保留執行個體隻是預設政策，您可以指定自己期望的其他類型執行個體作為保留執行個體的規格。當然您也可以指定最小保留一個标準執行個體，進而關閉保留執行個體的功能。

Demo 展示

Serverless Kubernetes(ASK) 叢集建立好以後可以通過以下釘釘群申請開通 Knative 功能。然後您就可以在 ASK 叢集中直接使用 Knative 提供的能力了。

Knative 功能打開後會在 knative-serving namespace 中建立一個叫做 ingress-gateway 的 service，這是一個 loadbalance 類型的 service，會通過 ccm 自動建立一個 SLB 出來。如下所示 47.102.220.35 就是 SLB 的公網 IP，接下來就可以通過此公網 IP 通路 Knative 服務了。

# kubectl -n knative-serving get svc
NAME              TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)        AGE
ingress-gateway   LoadBalancer   172.19.8.35   47.102.220.35   80:30695/TCP   26h
           

咱們後續的一系列操作就從一家咖啡店 (cafe) 開始談起。假設這家咖啡店有兩個品類：咖啡(coffee)和茶(tea)。咱們先部署 coffee 服務，然後再部署 tea 服務。同時還會包含版本更新、流量灰階、自定義 Ingress 以及自動彈性等特性的示範。

部署 coffee 服務

把如下内容儲存到 coffee.yaml 檔案中，然後通過 kubectl 部署到叢集：

# cat coffee.yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: coffee
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: "10"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:160e4dc8
          env:
            - name: TARGET
              value: "coffee"
           

執行

kubectl apply -f coffee.yaml

部署 coffee 服務，稍等一會兒應該可以看到 coffee 服務已經部署好了。

# kubectl get ksvc
NAME     URL                                 LATESTCREATED   LATESTREADY    READY   REASON
coffee   http://coffee.default.example.com   coffee-fh85b    coffee-fh85b   True
           

上面這個指令的執行結果中

coffee.default.example.com

就是 Knative 為每一個 ksvc 生成的唯一子域名。現在通過 curl 指令指定 host 和前面的 SLB 公網 IP 就能通路部署的這個服務了, 如下所示

Hello coffee!

就是 coffee 服務傳回的内容。

# curl -H "Host: coffee.default.example.com" http://47.102.220.35
Hello coffee!
           

自動彈性

Autoscaler 是 Knative 的一等公民，這是 Knative 幫助使用者節省成本的核心能力。Knative 預設的 KPA 彈性政策可以根據實時的流量請求自動調整 Pod 的數量。現在咱們就來感受一下 Knative 的彈性能力，先看一下目前的 pod 資訊：

# kubectl get pod
NAME                                       READY   STATUS    RESTARTS   AGE
coffee-bwl9z-deployment-765d98766b-nvwmw   2/2     Running   0          42s
           

可以看到現在有 1 個 pod 在運作，接下來開始準備壓測。在開始壓測之前咱們先回顧一下 coffee 應用的配置，前面的 yaml 中有一個這樣的配置, 如下所示，其中 autoscaling.knative.dev/target: "10" 意思就是每一個 Pod 的并發上限是 10 ，如果并發請求多餘 10 就應該擴容新的 Pod 接受請求。關于 Knative Autoscaler 更詳細的介紹請參見這裡。

# cat coffee-v2.yaml
... ...
      name: coffee-v2
      annotations:
        autoscaling.knative.dev/target: "10"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:160e4dc8
... ...
           

好咱們現在開始壓測一下試試。使用 hey 指令發起壓測請求， hey 指令下載下傳連結：

• macOS
• Linux
• Windows

hey -z 30s -c 90 --host "coffee.default.example.com" "http://47.100.6.39/?sleep=100"
           

上面這條指令的含義：

• -z 30s 表示連續壓測 30 秒；
• -c 90 表示使用 90 個并發請求發起壓測；
• --host "coffee.default.example.com" 表示綁定 host；
• "http://47.100.6.39/?sleep=100" 就是請求 url，其中 sleep=100 在測試鏡像中表示 sleep 100 毫秒，模拟真實的線上服務。

執行上述指令進行壓測，然後觀察 Pod 數量的變化情況。可以使用 watch -n 1 'kubectl  get pod' 這條指令檢視 Pod 監測 Pod 數量。如下所示做半邊是 Pod 數量的變化，右半邊是壓測指令執行的過程。可以通過這個 gif 圖觀察一下壓測的過程中 pod 的變化情況。當壓力上來之後 Knative 就會自動擴容，是以 Pod 數量就會變多。當壓測結束之後 Knative 監測到流量變少就會自動縮容，這是一個完全自動化的擴容和縮容的過程。

保留執行個體

前面亮點一節中介紹了 ASK Knative 會使用保留執行個體解決冷啟動和成本問題。接下來咱們就看一下保留執行個體和标準執行個體的切換過程。

前面的壓測結束以後多過一會兒，再使用 kubectl get pod 檢視一下 Pod 的數量可能會發現隻有一個 Pod 了，并且 Pod  名字是 xxx-reserve-xx  這種，reserve 的含義就是保留執行個體。這時候其實已經在使用保留執行個體提供服務了。當線上長時間沒有請求之後 Knative 就會自動擴容保留執行個體，并且把标準執行個體縮容到零，進而達到節約成本的目的。

# kubectl get pod
NAME                                               READY   STATUS    RESTARTS   AGE
coffee-bwl9z-deployment-reserve-85fd89b567-vpwqc   2/2     Running   0          5m24s
           

如果此時有流量進來會發生什麼呢？咱們就來驗證一下。通過下面的 gif 可以看出此時如果有流量進來就會自動擴容标準執行個體，待标準執行個體 ready 之後保留執行個體就會被縮容。

保留執行個體預設會使用 ecs.t5-lc1m2.small(1c2g) 這個規格。當然有些應用預設啟動的時候就要配置設定好記憶體(比如 JVM)，假設有一個應用需要 4G 的記憶體，則可能需要把 ecs.t5-c1m2.large(2c4g) 作為保留執行個體的規格。是以我們也提供了使用者指定保留執行個體規格的方法，使用者在送出 Knative Service 時可以通過 Annotation 的方式指定保留執行個體的規格, 比如

knative.aliyun.com/reserve-instance-eci-use-specs: ecs.t5-lc2m1.nano

這個配置的意思是使用

ecs.t5-lc2m1.nano

作為保留執行個體規格。 把下面内容儲存到

coffee-set-reserve.yaml

檔案：

# cat coffee-set-reserve.yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: coffee
spec:
  template:
    metadata:
      annotations:
        knative.aliyun.com/reserve-instance-eci-use-specs: "ecs.t5-c1m2.large"
        autoscaling.knative.dev/target: "10"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:160e4dc8
          env:
            - name: TARGET
              value: "coffee-set-reserve"
           

kubectl apply -f coffee-set-reserve.yaml

送出到 Kubernetes 叢集。稍微等待一會兒，待新版本縮容到保留執行個體之後檢視一下 Pod 清單：

# kubectl get pod
NAME                                               READY   STATUS    RESTARTS   AGE
coffee-vvfd8-deployment-reserve-845f79b494-lkmh9   2/2     Running   0          2m37s
           

檢視

set-reserve

的保留執行個體規格， 可以看到已經設定成 2c4g 的

ecs.t5-c1m2.large

規格：

# kubectl get pod coffee-vvfd8-deployment-reserve-845f79b494-lkmh9 -oyaml |head -20
apiVersion: v1
kind: Pod
metadata:
  annotations:
    ... ...
    k8s.aliyun.com/eci-instance-cpu: "2.000"
    k8s.aliyun.com/eci-instance-mem: "4.00"
    k8s.aliyun.com/eci-instance-spec: ecs.t5-c1m2.large
    ... ...
           

更新 coffee 服務

在更新之前咱們先看一下現在的 Pod 執行個體：

# kubectl get pod
NAME                                               READY   STATUS    RESTARTS   AGE
coffee-fh85b-deployment-8589564f7b-4lsnf           1/2     Running   0          26s
           

現在咱們來對 coffee 服務做一次更新。把下面的内容儲存到

coffee-v1.yaml

檔案中：

# cat coffee-v1.yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: coffee
spec:
  template:
    metadata:
      name: coffee-v1
      annotations:
        autoscaling.knative.dev/target: "10"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:160e4dc8
          env:
            - name: TARGET
              value: "coffee-v1"
           

目前部署的這個版本中添加了兩點：

• 給目前部署的 revision 設定了一個名字 coffee-v1 (如果不設定就自動生成)；

• 環境變量中設定了 v1 字樣，這樣可以通過 http 傳回的内容中判斷目前提供服務的是 v1 版本

  執行  

  kubectl apply -f coffee-v1.yaml

  指令部署 v1 版本。部署完以後繼續使用

  curl -H "Host: coffee.default.example.com" [http://47.102.220.35](http://47.102.220.35)

  進行驗證。

過幾秒鐘可以發現傳回的内容是

Hello coffee-v1!

,在這個過程中服務沒有中斷，也不需要手動做任何切換，修改完以後直接送出即可自動完成新版本和老版本執行個體的切換。

# curl -H "Host: coffee.default.example.com" http://47.102.220.35
Hello coffee-v1!
           

現在咱們再來看一下 pod 執行個體的狀态, 可以見 Pod 執行個體發生了切換。老版本的 Pod 自動被新版本替換掉了。

# kubectl get pod
NAME                                    READY   STATUS    RESTARTS   AGE
coffee-v1-deployment-5c5b59b484-z48gm   2/2     Running   0          54s
           

還有更多複雜功能的 Demo 示範，請移步這裡。

總結

Knative 是 Kubernetes 生态最流行的 Serverless 編排架構。社群原生的 Knative 需要常駐的 Controller 和常駐的網關才能提供服務。這些常駐執行個體除了需要支付 IaaS 成本以外還帶來了很多運維負擔，給應用的 Serverless 化帶來了一定的難度。是以我們在 ASK 中完全托管了 Knative Serving。開箱即用，您不需要為這些常駐執行個體付出任何成本。除了通過 SLB 雲産品提供 Gateway 的能力以外我們還提供了基于突發性能型執行個體的保留規格功能，這樣可以讓您的服務在流量波谷時期大大的減少 IaaS 開支，并且流量波谷時期積攢的 CPU 積分可以在流量高峰時期消費，您支付的每一分錢都沒有浪費。

更多 Knative 的資料請參見這裡或者這裡。

參考資料

• Knative 官方文檔
• Knative samples
• Knative Autoscaler 配置詳解
• Knative on ASK demo 示範
• ECS 突發性能執行個體，切換性能模式文檔
• 阿裡雲 Serverless Kubernetes（ASK）叢集簡介
• 雲伺服器 ECS 突發性能執行個體概述
• 《Serverless Kubernetes - 理想，現實與未來》

特别放送

Knative on ASK 底層使用 ECI 承載，目前可以免費領券100代金券進行試用。

試用位址：https://www.aliyun.com/daily-act/ecs/eci_freetry

課程推薦

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

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

“阿裡巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公衆号。”