![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/141a2aa145a44cb3929e258077181644.png)

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

> **導讀**：託管 Knative 開箱即用，您不需要為這些常駐例項付出任何成本。結合 SLB 雲產品提供 Gateway 的能力以及基於突發效能型例項的保留規格功能，極大的節省您的 IaaS 開支，您支付的每一分錢都沒有浪費。

****

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

![1.png](https://ucc.alicdn.com/pic/developer-ecology/0be0ca1a015d49ab91e1deef67d024a5.png)

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 模式。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/e8630485ba4e4d36a6f9661a903efc3a.png)

- 在 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 工作負載的核心模組。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/2b78dfa3647844eea6dac2689c14596c.png)

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

Knative 更多介紹請移步[這裡](https://knative.dev/)或[這裡](http://knative-sample.com/)瞭解更多。

# 為什麼是 ASK

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

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

![4.png](https://ucc.alicdn.com/pic/developer-ecology/63b73963363448ba934afd95db809d67.png)

也就是說您無需提前準備 ECS 資源，即可直接建立一個 Kubernetes 叢集，然後就能部署自己的服務了。關於 ASK 更詳細的介紹參見[這裡](https://help.aliyun.com/document_detail/86366.html?spm=a2c4g.11186623.6.935.6c874c07fK0OkT)。

前面分析 Serverless 歷程的時候我們們總結出來的 Serverless 發展主脈絡其實就是 **IaaS 和應用之間的耦合越來越低，基礎平臺只要做到在應用需要執行的時候給應用分配相應的 IaaS 資源即可，應用管理者只是 IaaS 的使用者，並不需要感知 IaaS 分配的細節**。ASK 就是這個隨時分配 IaaS 資源的平臺，Knative 負責感知應用的實時狀態，在需要的時候自動從 ASK 中“申請”IaaS 資源(Pod)。Knative 和 ASK 的結合可以給您帶來更極致的 Serverless 體驗。

關於 ASK 更深入的介紹請參見 [《Serverless Kubernetes - 理想，現實與未來》](https://yq.aliyun.com/articles/754302?spm=a2c4e.11153940.0.0.48363639twHNwd)。

# 亮點介紹

## 基於 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 配置的計算型例項和突發效能型例項的價格對比。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/ae9a4fcd97974de6a2f77aa24694aab9.png)

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

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

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

使用突發效能例項作為保留例項只是預設策略，您可以指定自己期望的其他型別例項作為保留例項的規格。當然您也可以指定最小保留一個標準例項，從而關閉保留例項的功能。

# Demo 展示

[Serverless Kubernetes(ASK)](https://help.aliyun.com/document_detail/86366.html?spm=a2c4g.11186623.6.935.6c874c07RylkXG) 叢集建立好以後可以透過以下釘釘群申請開通 Knative 功能。然後您就可以在 ASK 叢集中直接使用 Knative 提供的能力了。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/dbba36dc222f44aebeeffec27798e5e8.png)

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

```bash
# 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 部署到叢集：

```yaml
# 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 服務已經部署好了。

```bash
# 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 服務返回的內容。

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

## 自動彈性

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

```bash
# 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 更詳細的介紹請參見[這裡](https://knative-sample.com/20-serving/10-autoscaler-kpa/)。

```yaml
# 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](https://knative-samples.oss-cn-shanghai.aliyuncs.com/hey/darwin/hey)
- [Linux](https://knative-samples.oss-cn-shanghai.aliyuncs.com/hey/linux/hey)
- [Windows](https://knative-samples.oss-cn-shanghai.aliyuncs.com/hey/windows/hey.exe)

```bash
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](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 監測到流量變少就會自動縮容，這是一個完全自動化的擴容和縮容的過程。

![7.gif](https://ucc.alicdn.com/pic/developer-ecology/ad8e9dc457524c6884fbafe234afbd0e.gif)

## 保留例項

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

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

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

如果此時有流量進來會發生什麼呢？我們們就來驗證一下。透過下面的 gif 可以看出此時如果有流量進來就會自動擴容標準例項，待標準例項 ready 之後保留例項就會被縮容。

![8.gif](https://ucc.alicdn.com/pic/developer-ecology/e1da80fae5cd49a984695d07f9f35bdd.gif)

保留例項預設會使用 [ecs.t5-lc1m2.small(1c2g)](https://help.aliyun.com/document_detail/59977.html#section-mq2-x7y-0jl) 這個規格。當然有些應用預設啟動的時候就要分配好記憶體(比如 JVM)，假設有一個應用需要 4G 的記憶體，則可能需要把 [ecs.t5-c1m2.large(2c4g)](https://help.aliyun.com/document_detail/59977.html#section-mq2-x7y-0jl) 作為保留例項的規格。所以我們也提供了使用者指定保留例項規格的方法，使用者在提交 Knative Service 時可以透過 Annotation 的方式指定保留例項的規格, 比如 `knative.aliyun.com/reserve-instance-eci-use-specs: ecs.t5-lc2m1.nano` 這個配置的意思是使用 `ecs.t5-lc2m1.nano` 作為保留例項規格。 把下面內容儲存到 `coffee-set-reserve.yaml` 檔案：

```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 列表：

```bash
# 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` 規格：

```yaml
# 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 例項：

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

現在我們們來對 coffee 服務做一次升級。把下面的內容儲存到 `coffee-v1.yaml` 檔案中：

```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!` ,在這個過程中服務沒有中斷，也不需要手動做任何切換，修改完以後直接提交即可自動完成新版本和老版本例項的切換。

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

現在我們們再來看一下 pod 例項的狀態, 可以見 Pod 例項發生了切換。老版本的 Pod 自動被新版本替換掉了。

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

還有更多複雜功能的 Demo 演示，請移步[這裡](https://knative-sample.com//50-knative-on-ask/20-introduce-demo/)。

# 總結

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

更多 Knative 的資料請參見[這裡](https://knative.dev/)或者[這裡](https://knative-sample.com/)。

## 參考資料

- [Knative 官方文件](https://knative.dev/)
- [Knative samples](http://knative-sample.com/)
- [Knative Autoscaler 配置詳解](https://knative-sample.com/20-serving/10-autoscaler-kpa/)
- [Knative on ASK demo 演示](https://knative-sample.com//50-knative-on-ask/20-introduce-demo/)
- [ECS 突發效能例項，切換效能模式文件](https://help.aliyun.com/document_detail/90634.html?spm=a2c4g.11186623.2.30.7f7f61a1qMhXB1#section-cds-zh0-eh7)
- [阿里雲 Serverless Kubernetes（ASK）叢集簡介](https://help.aliyun.com/document_detail/86366.html)
- [雲伺服器 ECS 突發效能例項概述](https://help.aliyun.com/document_detail/59977.html)
- [《Serverless Kubernetes - 理想，現實與未來》](https://yq.aliyun.com/articles/754302?spm=a2c4e.11153940.0.0.48363639twHNwd)

## 特別放送

![9.png](https://ucc.alicdn.com/pic/developer-ecology/580f9bd2027742cabec52956cf2c3305.png)

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

試用地址：[https://www.aliyun.com/daily-act/ecs/eci_freetry](https://www.aliyun.com/daily-act/ecs/eci_freetry)

# 課程推薦

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

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

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247490639&idx=1&sn=0b80e352ef54681056de881d9736bf65&chksm=fae51780cd929e9697fc06401327e5ab8f507b7ff7424e3af36877630e668e2b11898213a478&token=1461674199&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

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

相關文章