![頭圖.jpg](https://ucc.alicdn.com/pic/developer-ecology/1af0a71a9ff844b8a015afa190e739bc.jpg)

作者 | 李鵬（元毅）
來源 | [Serverless 公眾號](https://mp.weixin.qq.com/s/ocGQ3F36lvYLwnV8rmNdTA)

# 一、Knative

Knative 提供了基於流量的**自動擴縮容能力**，可以根據應用的請求量，在高峰時自動擴容例項數；當請求量減少以後，自動縮容例項，做到自動化地節省資源成本。此外，Knative 還提供了基於流量的**灰度釋出能力**，可以將流量的百分比進行灰度釋出。

在介紹 Knative 灰度釋出和自動彈性之前，先帶大家瞭解一下 ASK Knative 中的流量請求機制。

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

如上圖所示，整體的流量請求機制分為以下部分：

- 左側是 Knative Service 的版本資訊，可以對流量設定百分比；下面是路由策略，在路由策略裡，透過 Ingress controller 將相應的路由規則設定到阿里雲 SLB；

- 右側是對應建立的服務版本 Revision，在版本里對應有 Deployment 的資源，當流量透過 SLB 進來之後，直接根據相應的轉發規則，轉到後端伺服器 Pod 上。

除了流量請求機制外，上圖還展示了相應的彈性策略，如 KPA、HPA 等。

# 二、Service 生命週期

Service 是直接面向開發者操作的資源物件，包含兩部分的資源：Route 和 Configuration。

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

如上圖所示，使用者可以透過配置 Configuration 裡面的資訊，設定相應的映象、內容以及環境變數資訊。

## 1. Configuration

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

Configuration 是：

- 管理容器期望的狀態；
- 類似版本控制器，每次更新 Configuration 都會建立新的版本（Revision）。

如上圖所示，與 Knative Service 相比較，Configuration 和它的配置很接近，Configuration 裡配置的就是容器期望的資源資訊。

## 2. Route

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

Route 可以：

- 控制流量分發到不同的版本（Revision）；
- 支援按照百分比進行流量分發。

如上圖所示，一個 Route 資源，下面包括一個 traffic 資訊，traffic 裡面可以設定對應的版本和每個版本對應的流量比例。

## 3. Revision

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

- 一個 Configuration 的快照；
- 版本追蹤、回滾。

Knative Service 中版本管理的資源：Revision，它是 Configuration 的快照，每次更新 Configuration 就會建立一個新的 Revision，可以透過 Revision 實現版本追蹤、灰度釋出以及回滾。在 Revision 資源裡面，可以直接地看到配置的映象資訊。
 
# 三、基於流量的灰度釋出

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

如上圖所示，假如一開始我們建立了 V1 版本的 Revision，這時如果有新的版本變更，那麼我們只需要更新 Service 中的 Configuration，就會相應的建立出 V2 版本。然後透過 Route 對 V1 和 V2 設定不同的流量比例，上圖中 V1 是 70%，V2 是 30%，流量會按照 7:3 的比例分別分發到兩個版本上。一旦 V2 版本驗證沒有問題，接下來就可以透過調整流量比例的方式進行繼續灰度，直到新的版本 V2 達到 100%。

在灰度的過程中，一旦發現新版本有異常，隨時可以調整流量比例進行回滾。假設灰度到 30% 的時候，發現 V2 版本有問題，我們就可以把比例調回去，在原來的 V1 版本上設定流量 100%，實現回滾操作。

除此之外，我們還可以在 Route 中透過 traffic 對 Revision 打上一個 Tag，打完 Tag 之後，在 Knative 中會自動對當前的 Revision 生成一個可直接訪問的 URL，透過這個 URL 我們可以直接把相應的流量打到當前的某一個版本上去，這樣可以實現對某個版本的除錯。

# 四、自動彈性

在 Knative 中提供了豐富的彈性策略，除此之外，ASK Knative 中還擴充套件了一些相應的彈性機制，接下來分別介紹以下幾個彈性策略：

- Knative Pod 自動擴縮容 （KPA）；
- Pod 水平自動擴縮容 （HPA）；
- 支援定時 + HPA 的自動擴縮容策略；
- 事件閘道器（基於流量請求的精準彈性）；
- 擴充套件自定義擴縮容外掛。

## 1. 自動擴縮容-KPA

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

圖：Knative Pod 自動擴縮容（KPA）

如上圖所示，Route 可以理解成流量閘道器；Activator 在 Knative 中承載著 0~1 的職責，當沒有請求流量時， Knative 會把相應的服務掛到 Activator Pod 上面，一旦有第一個流量進來，首先會進入到 Activator，Activator 收到流量之後，會透過 Autoscaler 擴容 Pod，擴容完成之後 Activator 把請求轉發到相應的 Pod 上去。一旦 Pod ready 之後，那麼接下來相應的服務會透過 Route 直接打到 Pod 上面去，這時 Activator 已經結束了它的使命。

在 1~N 的過程中，Pod 透過 kube-proxy 容器可以採集每個 Pod 裡面的請求併發指數，也就是請求指標。Autoscaler 根據這些請求指標進行匯聚，計算相應的需要的擴容數，實現基於流量的最終擴縮容。 
 
## 2. 水平擴縮容-HPA

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

圖：Pod 水平自動擴縮容（HPA）

它其實是將 K8s 中原生的 HPA 做了封裝，透過 Revision 配置相應的指標以及策略，使用 K8s 原生的 HPA，支援 CPU、Memory 的自動擴縮容。

## 3. 定時+HPA 融合

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

- 提前規劃容量進行資源預熱；
- 與 CPU、Memory 進行結合。

在 Knative 之上，我們將定時與 HPA 進行融合，實現提前規劃容量進行資源預熱。我們在使用 K8s 時可以體會到，透過 HPA 進行擴容時，等指標閾值上來之後再進行擴容的話，有時滿足不了實際的突發場景。對於一些有規律性的彈性任務，可以透過定時的方式，提前規劃好某個時間段需要擴容的量。

我們還與 CPU、Memory 進行結合。比如某個時間段定時設定為 10 個 Pod，但是當前 CPU 對閾值計算出來需要 20 個 Pod，這時會取二者的最大值，也就是 20 個 Pod 進行擴容，這是服務穩定性的最基本保障。

## 4. 事件閘道器

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

- 基於請求數自動彈性；
- 1 對 1 任務分發。

事件閘道器是基於流量請求的精準彈性。當事件進來之後，會先進入到事件閘道器裡面，我們會根據當前進來的請求數去擴容 Pod，擴容完成之後，會產生將任務和 Pod 一對一轉發的訴求。因為有時某個 Pod 同一時間只能處理一個請求，這時候我們就要對這種情況進行處理，也就是事件閘道器所解決的場景。

## 5. 自定義擴縮容外掛

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

自定義擴縮容外掛有 2 個關鍵點：

- 採集指標；
- 調整 Pod 例項數。

指標從哪來？像 Knative 社群提供的基於流量的 KPA，它的指標是透過一個定時的任務去每個 Pod 的 queue-proxy 容器中拉取 Metric 指標。透過 controller 對獲取這些指標進行處理，做匯聚並計算需要擴容多少 Pod。
怎麼執行擴縮容？其實透過調整相應的 Deployment 裡面的 Pod 數即可。

調整採集指標和調整 Pod 例項數，實現這兩部分後就可以很容易地實現自定義擴縮容外掛。

# 五、實操演示

下面進行示例演示，演示內容主要有：

- 基於流量的灰度釋出
- 基於流量的自動擴縮容

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

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

Knativa 基於流量的灰度釋出和自動彈性實踐

相關文章