Knativa 基於流量的灰度發佈和自動彈性實踐

簡介：Knative 提供了基於流量的自動擴縮容能力，能夠根據應用的請求量，在高峯時自動擴容實例數；當請求量減小之後，自動縮容實例，作到自動化地節省資源成本。此外，Knative 還提供了基於流量的灰度發佈能力，能夠將流量的百分比進行灰度發佈。

做者 | 李鵬（元毅）
來源 | Serverless 公衆號

1、Knative

Knative 提供了基於流量的自動擴縮容能力，能夠根據應用的請求量，在高峯時自動擴容實例數；當請求量減小之後，自動縮容實例，作到自動化地節省資源成本。此外，Knative 還提供了基於流量的灰度發佈能力，能夠將流量的百分比進行灰度發佈。

在介紹 Knative 灰度發佈和自動彈性以前，先帶你們瞭解一下 ASK Knative 中的流量請求機制。

如上圖所示，總體的流量請求機制分爲如下部分：

• 左側是 Knative Service 的版本信息，能夠對流量設置百分比；下面是路由策略，在路由策略裏，經過 Ingress controller 將相應的路由規則設置到阿里雲 SLB；
• 右側是對應建立的服務版本 Revision，在版本里對應有 Deployment 的資源，當流量經過 SLB 進來以後，直接根據相應的轉發規則，轉到後端服務器 Pod 上。

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

2、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 資源裏面，能夠直接地看到配置的鏡像信息。

3、基於流量的灰度發佈

如上圖所示，假如一開始咱們建立了 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 咱們能夠直接把相應的流量打到當前的某一個版本上去，這樣能夠實現對某個版本的調試。

4、自動彈性

在 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 實例數，實現這兩部分後就能夠很容易地實現自定義擴縮容插件。

5、實操演示

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

• 基於流量的灰度發佈
• 基於流量的自動擴縮容

演示過程觀看連接：https://developer.aliyun.com/live/246127

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

本文內容由阿里雲實名註冊用戶自發貢獻，版權歸原做者全部，阿里雲開發者社區不擁有其著做權，亦不承擔相應法律責任。具體規則請查看《阿里雲開發者社區用戶服務協議》和《阿里雲開發者社區知識產權保護指引》。若是您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將馬上刪除涉嫌侵權內容。