作者| 李鵬（元毅）
來源 | 阿里巴巴云原生公眾號

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

總結

以上是生活随笔為你收集整理的Knative 基于流量的灰度发布和自动弹性实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。