基於Kubernetes和Istio的Serverless框架Knative解析之Autoscaler

咱們都是知道Kubernetes中個資源對象叫 autoscaler，該對象在serverless架構中更是不可或缺，有了它能夠負責應用的自動水平伸縮，用戶不再用關心示例的個數和資源消耗，本文是來自阿里巴巴UC事業羣基礎研發部的陳有坤同窗對Knative的解析之autoscaler部分，還有大量的解析等待放出，起關注本站的後續內容。

Knative是一款基於Kubernetes的平臺，用來構建、部署和管理現代serverless應用的框架。該框架試圖將雲原生應用開發的如下三個領域的最佳實踐結合起來：

• 構建容器（和函數）
• 爲工做負載提供服務（和動態擴展）
• 事件

Knative是由谷歌與Pivotal、IBM、Red Hat 和SAP緊密協做開發的。

Knative構建在Kubernetes和Istio之上，它的設計考慮到了多種角色經過該框架進行交互，包括開發人員、運維人員和平臺提供者。

Knative所涉及的角色（圖片來源於Knative GitHub倉庫）

Knative致力於提供可重用的「通用模式和最佳實踐組合」實現，目前可用的組件包括：

• Build：從源到容器的構建編排；
• Eventing：管理和交付事件；
• Serving：請求驅動的計算，能夠縮放到零。

以上內容引用自： InfoQ | 谷歌發佈Knative：用於構建、部署和管理Serverless工做負載的Kubernetes框架

以上是對Knative的基本介紹，關於Knative的更多信息你們能夠關注其GitHub：github.com/knative，咱們都…

下面首先解析的是Serving中的Autoscaling組件，該組件的功能是根據網絡流量來自動伸縮應用實例的個數。

Knative是如何作伸縮容的？

處理伸縮容問題，首先要解決的問題是根據什麼指標判斷伸縮容？cpu、內存、請求數？這裏knative使用的是請求數。

其次是伸縮多少的問題。

Knative的伸縮是依賴修改deployment的replica數實現的。

如何採集請求數？

啓動revision的pod時，也會啓動一個autoscaler（一個knative revision只啓動一個autoscaler），autoscaler本身自己也會scale到0，用於接收請求數統計和處理伸縮容。

業務pod中，會注入queue-proxy sidecar，用於接收請求，在這裏會統計併發數，每秒向autoscaler彙報，接收到的請求會轉發給業務container。

注：單租戶模式下一個revision啓動一個autoscaler，多租戶共用一個autoscaler

計算須要pod的個數？

autoscaler接收到併發統計的時候，會根據算法計算須要的pod個數。

算法中有兩種模式，分別是panic和stable模式，一個是短期，一個是長時間，爲了解決短期內請求突增的場景，須要快速擴容。

文檔中描述的算法是，默認的target concurrency是1，若是一個revision 35QPS，每一個請求花費0.25秒，Knative Serving 以爲須要 9 個 pod。

ceil(35 * .25) = ceil(8.75) = 9
複製代碼

Stable Mode（穩定模式）

在穩定模式下，Autoscaler 根據每一個pod指望的併發來調整Deployment的副本個數。根據每一個pod在60秒窗口內的平均併發來計算，而不是根據現有副本個數計算，由於pod的數量增長和pod變爲可服務和提供指標數據有必定時間間隔。

Panic Mode （恐慌模式）

Panic時間窗口默認是6秒，若是在6秒內達到2倍指望的併發，則轉換到恐慌模式下。在恐慌模式下，Autoscaler根據這6秒的時間窗口計算，這樣更能及時的響應突發的流量請求。每2秒調整Deployment的副本數達到想要的pod個數（或者最大10倍當前pod的數量），爲了不pod數量頻繁變更，在恐慌模式下只能增長，不會減小。60秒後會恢復回穩定模式。

autoscaler單租戶圖

上圖基於 github.com/knative/ser… 繪製。

模式

const (
   // 每一個pod實例同時只處理一個請求
   RevisionRequestConcurrencyModelSingle RevisionRequestConcurrencyModelType = "Single"
   // 每一個pod實例同時處理多個請求
   RevisionRequestConcurrencyModelMulti RevisionRequestConcurrencyModelType = "Multi"
)
複製代碼

配置

apiVersion: v1
kind: ConfigMap
metadata:
 name: config-autoscaler
 namespace: knative-serving
data:
  # Static parameters:

  # 指望每一個pod併發請求數
 multi-concurrency-target: "1.0"
  # 若是是單個併發，值要接近1.0
 single-concurrency-target: "0.9"

  # stable窗口時間，計算平均併發會用到。若是進入panic模式後，通過stable窗口時間也會恢復stable
 stable-window: "60s"

  # 若是平均併發在panic窗口時間內達到2倍目標併發，autoscaler進入panic模式。
  # 在panic模式下，自動伸縮按在panic窗口時間的平均併發來操做。
 panic-window: "6s"

  # 最大增加比例，每次調整會根據併發計算增加比例，最大增加不超過這個值
 max-scale-up-rate: "10"

  # 計算併發值的參數，每一段時間獲得最大併發，做爲一個bucket，最後彙報的時候，
  # 平均併發 = 各個bucket最大併發之和 / 總bucket數，彙報間隔是1秒（hard coded）
 concurrency-quantum-of-time: "100ms"

  # 是否開啓縮容到0
 enable-scale-to-zero: "true"

  # 實驗性：開啓垂直擴容
  # Requires a VPA installation (e.g. ./third_party/vpa/install-vpa.sh)
 enable-vertical-pod-autoscaling: "false"
 
  # 若是開啓了enable-vertical-pod-autoscaling，這個值就會替代multi-concurrency-target，
  # 若是成熟了後期會變成默認值
 vpa-multi-concurrency-target: "10.0"

  # 多長時間調整一次
 tick-interval: "2s"
  
  # Dynamic parameters (take effect when config map is updated):

  # 空閒多長時間縮容到0
 scale-to-zero-threshold: "5m"複製代碼

本文轉載自：www.servicemesher.com/blog/knativ…

ServiceMesher社區信息

社區官網：www.servicemesher.com

Slack：servicemesher.slack.com 須要邀請才能加入，有志於加入ServiceMesher社區爲Service Mesh做出貢獻的同窗能夠聯繫我。

Twitter: twitter.com/servicemesh…

更多Service Mesh諮詢請掃碼關注微信公衆號ServiceMesher。

做者：ServiceMesher 連接：https://juejin.im/post/5b69003df265da0f7c4fea96 來源：掘金 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。