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

作者 | 元毅
 
**導讀：**Knative 是基於 Kubernetes 的開源 Serverless 應用編排框架。阿里雲 Knative 在社群 Knative 基礎之上，與阿里雲產品進行了深度的融合，給你帶來最純粹的容器化 Serverless 體驗。

# 關於 Knative

Knative 是基於 Kubernetes 的開源 Serverless 應用編排框架。實際上 Knative 包含的不單單是 Workload，它還有 Kubernetes 原生的流程編排引擎和完備的事件系統。Knative 目標是基於 Kubernetes 提供應用 Serverless 工作負載編排的標準化。Knative 核心模組主要包括事件驅動框架 Eventing 和部署工作負載的 Serving。

## 1. Serverless 服務引擎 - Serving

Knative Serving 核心能力就是其簡潔、高效的應用託管服務，這也是其支撐 Serverless 能力的基礎。當然作為 Serverless Framework 就離不開按需分配資源的能力，Knative 可以根據應用的請求量在高峰時期自動擴容例項數，當請求量減少以後自動縮容例項數，可以非常自動化地幫助您節省成本。

Serving 還提供了流量管理能力和靈活的灰度釋出能力。流量管理能力可以根據百分比切分流量，灰度釋出能力可以根據流量百分比進行灰度。

### 1）簡單的應用模型

提供了極簡的應用模型 - Knative Service ，同時滿足服務部署、服務訪問以及灰度釋出的能力。可以用下面的公式表述：Knative Service = 工作負載（Deployment）+ 服務訪問（ Service ）+ 灰度流量（ Ingress ）。

應用模型如下圖

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

- Service：對 Serverless 應用模型的抽象，透過 Service 管理應用的生命週期；
- Configuration：用於配置應用期望的資訊。每次更新 Service 就會更新 Configuration；
- Revision：Configuration 的每次更新都會建立一個快照，用來做版本管理；
- Route：將請求路由到 Revision，並可以向不同的 Revision 轉發不同比例的流量。

- 應用託管
   - Kubernetes 是面向 IaaS 管理的抽象，透過 Kubernetes 直接部署應用需要維護的資源比較多；
   - 透過 Knative Service 一個資源就能定義應用的託管。

- 流量管理
   - Knative 透過 Gateway 結果應用流量，然後可以對流量按百分比進行分割，這為這為彈性、灰度等基礎能力做好了基礎。

- 灰度釋出
   - 支援多版本管理，應用同時有多個版本線上提供服務很容易實現；
   - 不同版本可以設定不同的流量百分比，對灰度釋出等功能實現起來很容易。

- 彈性
   - Knative 幫助應用節省成本的核心能力是彈性，在流量增加的時候自動擴容，容，流量下降的時候自動縮容；
   - 每一個灰度的版本都有自己的彈性策略，並且彈性策略和分配到當前版本的流量流量是相關聯的。Knative 會根據分配過來的流量多少進行擴容或者縮容的決策。

### 2）豐富的彈性策略

作為 Serverless 框架，其核心能力就是自動彈性，Knative 中提供了豐富的彈性策略：

- 基於流量請求的自動擴縮容 - KPA
- 基於 CPU、Memory 的自動擴縮容 - HPA
- 支援定時 + HPA 的自動擴縮容策略
- 事件閘道器，提供請求與 Pod 1 對 1 處理能力
###

## 2. Serverless 事件驅動框架 - Eventing

事件驅動是 Serverless 的標配，在 Knative 中同樣提供了事件驅動框架 - Eventing。

Knative 的 Eventing 提供了完整的事件模型，可以很容易地接入各個外部系統的事件。事件接入以後透過 CloudEvent 標準在內部流轉。

在 Knative Eventing 提供兩種事件轉發方式：

- 事件源直接轉發到服務；
- 事件源轉發到 Broker / Trigger ，然後透過過濾轉發到服務。

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

對於在使用過程中究竟應該使用哪種方式進行轉發呢？其實很簡單，Broker / Trigger 模型是基於底層訊息系統實現的，對於像 Github、Gitlab、K8s APIserver 這樣的事件源來說，需要對訊息事件進行緩衝處理、保證訊息傳輸可靠性，那麼我們建議透過事件源轉發到 Broker / Trigger 進行事件流轉。

對於事件源本身就是訊息系統來說，像 MNS、Kafka、RocketMQ來說，使用事件源直接轉發到服務更為高效。

講到這裡，就不得不提 Knative 的事件源。我把它比喻成事件驅動引擎，Knative Eventing 正是透過這些事件源驅動事件流轉。

Knative 社群提供了豐富的事件源，如 Kafka、GitHub 等。此外還接入訊息雲產品事件源，如 MNS、RocketMQ 等。

# 阿里雲 Knative

阿里雲 Knative 在社群原生的 Knative 之上，與阿里雲資源體系進行了全方位的整合，提供了更為豐富的能力以及雲產品級別的支援。

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

## 1. 與阿里雲產品融合

- 豐富的訊息雲產品事件源：Kafka 、MNS 、RocketMQ
- 服務訪問：SLB
- 儲存：NAS 、雲盤等
- 可觀測性：日誌服務、ARMS
- IaaS 資源：ECS 、ECI

## 2. 天然整合阿里雲  K8s  生態

- 支援阿里雲標準版 Kubernetes，專有版 Kubernetes；
- 支援阿里雲 Serverless Kubernetes（ASK）， 並且在 ASK 中將 Knative 管控元件全託管，為使用者節省了資源以及運維成本。

# 一個例子

接下來以一個傳送彈幕的示例來介紹一下如何玩轉阿里雲 Knative。先看一下效果：

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

架構示意圖：

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

流程說明：

- 使用者透過彈幕 Web 服務傳送彈幕到阿里雲 Kafka；
- Kafka Source 事件源監聽到彈幕訊息，然後傳送到彈幕訊息處理服務；
- 彈幕訊息處理服務接收到訊息，然後自動彈性擴容例項進行訊息處理，並將處理完成的訊息傳送給彈幕服務；
- 最後彈幕透過 Web 服務介面展示給使用者；

# 總結

最後我們總結一下阿里雲 Knative 能給我們帶來哪些能力：

- 服務部署低門檻、易上手
- Serverless 按需使用資源
- 事件驅動與訊息雲產品無縫對接
- 天然整合阿里雲 K8s 生態
- 與阿里雲產品打通

希望這些能力能給你帶來真正的按需使用，降低運維、資源使用成本的訴求，這也是 Serverless 思想理念所追求的目標。

春色滿園關不住，帶你體驗阿里雲 Knative

相關文章