![](http://img.blog.itpub.net/blog/2021/03/30/8fa9c7219dedac74.png?x-oss-process=style/bb)

作者 | 李鵬（元毅）

# 一、為什麼需要 Knative

![1.jpg](https://ucc.alicdn.com/pic/developer-ecology/3fa2defe6d354670b727c27ba64520ed.jpg)

K8s 目前已成為雲原生市場上的主流作業系統，K8s **對上**透過資料抽象暴露基礎設施能力，比如 Service、Ingress、Pod、Deployment 等，這些都是透過 K8s 原生 API 給使用者暴露出來的能力；而**對下** K8s 提供了基礎設施接入的一些標準介面，比如 CNI、CRI、CRD，讓雲資源以一個標準化的方式進入到 K8s 的體系中。

K8s 處在一個承上啟下的位置，雲原生使用者使用 K8s 的目的是為了交付和管理應用，也包括灰度釋出、擴容縮容等。但是對使用者來說，實現這些能力，透過直接操作 K8s API 難免有些複雜。另外節省資源成本和彈性對於使用者來說也越來越重要。

那麼，如何才能簡單地使用 K8s 的技術，並且實現按需使用，最終實現降本增效的目的呢？**答案就是 Knative**。

# 二、Knative簡介

## 1. Knative 是什麼

- **定義**

![2.jpg](https://ucc.alicdn.com/pic/developer-ecology/04870dea4888443ab118955c3a333d9e.jpg)

Knative 是一款基於 Kubernetes 的 Serverless 編排引擎，Knative 一個很重要的目標是制定雲原生跨平臺的編排標準，它透過整合容器構建、工作負載以及事件驅動來實現這一目的。

Knative 社群當前貢獻者主要有 Google、Pivotal、IBM、Red Hat，可見其陣容強大，另外還有 CloudFoundry、OpenShift 這些 PAAS 提供商也都在積極地參與 Knative 的建設。

- **核心模組**

![3.jpg](https://ucc.alicdn.com/pic/developer-ecology/0a46ed5ab27e49f58937fe9558b8e318.jpg)

Knative 核心模組主要包括兩部分：事件驅動框架 Eventing 和提供工作負載的 Serving，接下來本文主要介紹 Serving 相關的一些內容。

## 2. 流量灰度釋出

以一個簡單的場景為例：

- **在 K8s 中實現基於流量的灰度釋出**

![4.jpg](https://ucc.alicdn.com/pic/developer-ecology/ab68c1f1057646208676b54f6f0d0ca7.jpg)

如果要在 K8s 中實現基於流量的灰度釋出，需要建立對應的 Service 與 Deployment，彈性相關的需要 HPA 來做，然後在流量灰度釋出時，要建立新的版本。

以上圖為例，創始版本是 v1，要想實現流量灰度釋出，我們需要建立一個新的版本 v2。建立 v2 時，要建立對應的 Service、Deployment、HPA。建立完之後透過 Ingress 設定對應的流量比例，最終實現流量灰度釋出的功能。
 
- **在 Knative 中實現基於流量的灰度釋出**

![5.jpg](https://ucc.alicdn.com/pic/developer-ecology/88d9dafd0ddb48c89c2e94b222adf89f.jpg)

如上圖所示，在 Knative 中想要實現基於流量的灰度釋出，只需要建立一個 Knative Service，然後基於不同的版本進行灰度流量，可以用 Revision1 和 Revision2 來表示。在不同的版本里面，已經包含了自動彈性。
 
從上面簡單的兩個圖例，我們可以看到在 Knative 中實現流量灰度釋出時，需要直接操作的資源明顯較少。

## 3. Knative Serving 架構

![6.jpg](https://ucc.alicdn.com/pic/developer-ecology/0fcf6470f08c438e92c1b05243d8d966.jpg)

- **Service **

Service 對應 Serverless 編排的抽象，透過 Service 管理應用的生命週期。Service 下又包含兩大部分：Route 和 Configuration。

- **Route**

Route 對應路由策略。將請求路由到 Revision，並可以向不同的 Revision 轉發不同比例的流量。

- **Configuration**

Configuration 配置的是相應的資源資訊。當前期望狀態的配置。每次更新 Service 就會更新 Configuration。

- **Revision**

每次更新 Configuration 都會相應得到一個快照，這個快照就是 Revision，透過 Revision 實現多版本管理以及灰度釋出。

我們可以這樣理解：Knative Service ≈ Ingress + Service + Deployment + 彈性（HPA）。

## 4. 豐富的彈性策略

當然，Serverless 框架離不開彈性， Knative 中提供了以下豐富的彈性策略：

- 基於流量請求的自動擴縮容：KPA；
- 基於 CPU、Memory 的自動擴縮容：HPA；
- 支援定時 + HPA 的自動擴縮容策略；
- 事件閘道器（基於流量請求的精準彈性）。

# 三、Knative 和 ASK 融合

## 1. ASK：Serverless Kubernetes

![7.jpg](https://ucc.alicdn.com/pic/developer-ecology/9a816b235ae54635b87cb231800c2303.jpg)

如果要準備 ECI 資源的話，需要提前進行容量規劃，這無疑違背了 Serverless 的初衷。為擺脫 ECI 資源的束縛，不必提前進行 ECI 資源規劃，阿里雲提出了無伺服器 Serverless——ASK。使用者無需購買節點，即可直接部署容器應用，無需對節點進行維護和容量規劃。ASK 提供了 K8s 相容的能力，同時極大地降低了 K8s 的使用門檻，讓使用者專注於應用程式，而不是底層基礎設施。

ASK 提供了以下能力：

- **免運維**

開箱即用，無節點管理和運維，無節點安全維護，無節點 NotReady，簡化 K8s 叢集管理。

- **極致的彈性擴容**

無容量規劃，秒級擴容，30s 500pod。

- **低成本**

按需建立 Pod，支援 Spot，預留例項券。

- **相容 K8s**

支援 Deployment/statfulset/job/service/ingress/crd 等。

- **儲存掛載**

支援掛載雲盤、NAS、OSS 儲存券。

- **Knative on ASK**

基於應用流量的自動彈性，開箱即用，縮容到最小規格。

- **Elastic Workload**

支援 ECI 按量和 Spot 混合排程。

- **整合 ARMS/SLS 等雲產品**

## 2. Knative 運維複雜度

Knative 運維主要存在三個方面的問題：Gateway、Knative 管控元件和冷啟動問題。

![8.jpg](https://ucc.alicdn.com/pic/developer-ecology/19978cef66764eba85074bcadf12ad00.jpg)

如上圖所示，在 Knative 中管控元件會涉及到相應的 Activator，它是從 0 到 1 的一個元件；Autoscaler 是擴縮容相關的元件；Controller 是自身的管控元件以及閘道器。對於這些元件的運維，如果放在使用者層面做，無疑會加重負擔，同時這些元件還會佔用成本。

![9.jpg](https://ucc.alicdn.com/pic/developer-ecology/ea98e18484274034a5417205faf345be.jpg)

除此之外，從 0 到 1 的冷啟動問題也需要考慮。當應用請求過來時，第一個資源從開始到啟動完成需要一段時間，這段時間內的請求如果響應不及時的話，會造成請求超時，進而帶來冷啟動問題。

對於上面說到的這些問題，我們可以透過 ASK 來解決。下面看下 ASK 是如何做的？

## 3. Gateway 和 SLB 融合

![10.jpg](https://ucc.alicdn.com/pic/developer-ecology/18f70e8bc4354ae9852b687cd6b1e6eb.jpg)

相比於之前 Istio 提供的能力，我們需要運營管控 Istio 相關的元件，這無疑加大了管控成本。實際上對於大部分場景來說，我們更關心閘道器的能力，Istio 本身的一些服務（比如服務網格）我們其實並不需要。

在 ASK 中，我們將閘道器這一層透過 SLB 進行了替換：
 
- **降成本**：減少了十幾個元件，大大降低運維成本和 IaaS 成本；
- **更穩定**：SLB 雲產品服務更穩定，可靠性更高，易用性也更好。

## 4. 管控元件下沉

![11.jpg](https://ucc.alicdn.com/pic/developer-ecology/45a6a861761e4d88a6df792a66fc6f31.jpg)

對於 Knative 管控元件，ASK 做了一些託管：

- **開箱即用**：使用者直接使用 Serverless Framework，不需要自己安裝；
- **免運維、低成本**：Knative 元件和 K8s 叢集進行融合，使用者沒有運維負擔，也無需承擔額外的資源成本；
- **高管控**：所有元件都在管控端部署，升級和迭代更容易。

## 5. 優雅的保留例項

在 ASK 平臺中，我們提供了優雅保留例項的能力，其作用是**免冷啟動**。透過保留例項，消除了從 0 到 1 的冷啟動時間。當我們縮容到 0 的時候，並沒有把例項真正縮容到 0，而是縮容到一個低規格的保留例項上，目的是降低成本。

- **免冷啟動**：透過保留規格消除了從 0 到 1 的 30 秒冷啟動時間；
- **成本可控**：突發效能例項成本比標準規格例項降低 40% 的成本，如果和 Spot 例項結合還能再進一步降低成本。

# 四、實操演示

最後進行動手實踐演示，以一家咖啡店（cafe）為例，演示內容主要有：

- 在 ASK 叢集中安裝 Knative；
- 部署 coffee 服務；
- 訪問 coffee 服務；
- 保留例項。

演示過程觀看連結：[https://developer.aliyun.com/live/246126](https://developer.aliyun.com/live/246126)

**作者簡介：**
李鵬，花名：元毅，阿里雲容器平臺高階開發工程師，2016 年加入阿里， 深度參與了阿里巴巴全面容器化、連續多年支援雙十一容器化鏈路。專注於容器、Kubernetes、Service Mesh 和 Serverless 等雲原生領域，致力於構建新一代 Serverless 平臺。當前負責阿里雲容器服務 Knative 相關工作。

K8s 原生 Serverless 實踐：ASK 與 Knative

相關文章