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

ServiceMesher發表於2019-03-04

我們都是知道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"複製程式碼