作者| 李鵬（元毅）
來源 |
阿裡巴巴雲原生公衆号Knative
Knative 提供了基于流量的自動擴縮容能力，可以根據應用的請求量，在高峰時自動擴容執行個體數；當請求量減少以後，自動縮容執行個體，做到自動化地節省資源成本。此外，Knative 還提供了基于流量的灰階釋出能力，可以将流量的百分比進行灰階釋出。
在介紹 Knative 灰階釋出和自動彈性之前，先帶大家了解一下 ASK Knative 中的流量請求機制。
如上圖所示，整體的流量請求機制分為以下部分：
- 左側是 Knative Service 的版本資訊，可以對流量設定百分比；下面是路由政策，在路由政策裡，通過 Ingress controller 将相應的路由規則設定到阿裡雲 SLB；
- 右側是對應建立的服務版本 Revision，在版本裡對應有 Deployment 的資源，當流量通過 SLB 進來之後，直接根據相應的轉發規則，轉到後端伺服器 Pod 上。
除了流量請求機制外，上圖還展示了相應的彈性政策，如 KPA、HPA 等。
Service 生命周期
Service 是直接面向開發者操作的資源對象，包含兩部分的資源：Route 和 Configuration。
如上圖所示，使用者可以通過配置 Configuration 裡面的資訊，設定相應的鏡像、内容以及環境變量資訊。
1. Configuration
Configuration 是：
- 管理容器期望的狀态；
- 類似版本控制器，每次更新 Configuration 都會建立新的版本（Revision）。
如上圖所示，與 Knative Service 相比較，Configuration 和它的配置很接近，Configuration 裡配置的就是容器期望的資源資訊。
2. Route
Route 可以：
- 控制流量分發到不同的版本（Revision）；
- 支援按照百分比進行流量分發。
如上圖所示，一個 Route 資源，下面包括一個 traffic 資訊，traffic 裡面可以設定對應的版本和每個版本對應的流量比例。
3. Revision
- 一個 Configuration 的快照；
- 版本追蹤、復原。
Knative Service 中版本管理的資源：Revision，它是 Configuration 的快照，每次更新 Configuration 就會建立一個新的 Revision，可以通過 Revision 實作版本追蹤、灰階釋出以及復原。在 Revision 資源裡面，可以直接地看到配置的鏡像資訊。
基于流量的灰階釋出
如上圖所示，假如一開始我們建立了 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
▲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
▲Pod 水準自動擴縮容（HPA）
它其實是将 K8s 中原生的 HPA 做了封裝，通過 Revision 配置相應的名額以及政策，使用 K8s 原生的 HPA，支援 CPU、Memory 的自動擴縮容。
3. 定時+HPA 融合
- 提前規劃容量進行資源預熱；
- 與 CPU、Memory 進行結合。
在 Knative 之上，我們将定時與 HPA 進行融合，實作提前規劃容量進行資源預熱。我們在使用 K8s 時可以體會到，通過 HPA 進行擴容時，等名額門檻值上來之後再進行擴容的話，有時滿足不了實際的突發場景。對于一些有規律性的彈性任務，可以通過定時的方式，提前規劃好某個時間段需要擴容的量。
我們還與 CPU、Memory 進行結合。比如某個時間段定時設定為 10 個 Pod，但是目前 CPU 對門檻值計算出來需要 20 個 Pod，這時會取二者的最大值，也就是 20 個 Pod 進行擴容，這是服務穩定性的最基本保障。
4. 事件網關
- 基于請求數自動彈性；
- 1 對 1 任務分發。
事件網關是基于流量請求的精準彈性。當事件進來之後，會先進入到事件網關裡面，我們會根據目前進來的請求數去擴容 Pod，擴容完成之後，會産生将任務和 Pod 一對一轉發的訴求。因為有時某個 Pod 同一時間隻能處理一個請求，這時候我們就要對這種情況進行處理，也就是事件網關所解決的場景。
5. 自定義擴縮容插件
自定義擴縮容插件有 2 個關鍵點：
- 采集名額；
- 調整 Pod 執行個體數。
名額從哪來？像 Knative 社群提供的基于流量的 KPA，它的名額是通過一個定時的任務去每個 Pod 的 queue-proxy 容器中拉取 Metric 名額。通過 controller 對擷取這些名額進行處理，做彙聚并計算需要擴容多少 Pod。
怎麼執行擴縮容？其實通過調整相應的 Deployment 裡面的 Pod 數即可。
調整采集名額和調整 Pod 執行個體數，實作這兩部分後就可以很容易地實作自定義擴縮容插件。
實操示範
下面進行示例示範，示範内容主要有：
- 基于流量的灰階釋出；
- 基于流量的自動擴縮容。
示範過程觀看方式：_
https://developer.aliyun.com/live/246127_作者簡介
李鵬，花名：元毅，阿裡雲容器平台進階開發工程師，2016 年加入阿裡， 深度參與了阿裡巴巴全面容器化、連續多年支援雙十一容器化鍊路。專注于容器、Kubernetes、Service Mesh 和 Serverless 等雲原生領域，緻力于建構新一代 Serverless 平台。目前負責阿裡雲容器服務 Knative 相關工作。
Serverless 電子書下載下傳
本書亮點：
- 從架構演進開始，介紹 Serverless 架構及技術選型建構 Serverless 思維；
- 了解業界流行的 Serverless 架構運作原理；
- 掌握 10 大 Serverless 真實落地案例，活學活用。
下載下傳連結：
https://developer.aliyun.com/topic/download?id=1128