基於流量請求數實現Knative服務自動擴縮容 - Alibaba Cloud Service Mesh

Knative on ASM中提供開箱即用、基於流量請求的自動擴縮容KPA（Knative Pod Autoscaler）功能。當您遇到因業務流量波動導致的服務效能不穩定或資源浪費問題時，可以基於流量請求數實現服務自動擴縮容。通過監控和分析即時資料流量資料動態調整服務執行個體數，既能保障高峰期的服務品質和使用者體驗，又能有效節約閑置資源，在降低成本的同時提高系統整體效能。

前提條件

已使用Knative on ASM建立Knative服務。具體操作，請參見使用Knative on ASM部署Serverless應用。

說明

本樣本以預設網域名稱example.com為例為您示範功能。如需使用自訂網域名, 請參見在Knative on ASM中使用自訂網域名。

自動擴縮容介紹

Knative Serving為每個Pod注入QUEUE代理容器（queue-proxy）。該容器負責向Autoscaler報告業務容器的並髮指標。接收到這些指標之後，Autoscaler會根據並發請求數及縮放演算法，調整Deployment的Pod數量，從而實現自動擴縮容。

擴縮容

並發數和QPS

並發數指同一時刻Pod的接收的請求數；QPS指Pod每秒響應的請求數，即最大吞吐能力。

並發數的增加並不一定會導致QPS增加。應用在訪問壓力較大的情況下，如果並發數增加，可能導致系統超負荷工作，CPU、記憶體等其他消耗導致系統效能下降，從而導致響應延遲，QPS反而會下降。

演算法

Knative Pod Autoscaler（KPA）基於每個Pod的平均請求數（或並發數）進行自動擴縮容，Knative預設使用基於並發數的自動彈性，每個Pod的最大並發數為100。此外，Knative還提供了目標使用率（target-utilization-percentage）的概念，用於指定自動擴縮容的目標使用率。

基於並發數彈性為例，Pod數計算方式如為：Pod數=並發請求總數/（Pod最大並發數*目標使用率）

例如，如果服務中Pod最大並發數設定為10，目標使用率設定為0.7，此時如果接收到了100個並發請求，則Autoscaler就會建立15個Pod（即100/(0.7*10)≈15）。

KPA基於每個Pod的平均請求數（或並發數）來進行自動擴縮容，並結合了Stable穩定模式和Panic恐慌模式兩個概念，以實現精細化的彈性。

Stable穩定模式
在穩定模式中，KPA會在預設的穩定視窗期（預設為60秒）內計算Pod的平均並發數。根據這個平均並發數，KPA會調整Pod的數量，以保持穩定的負載水平。
Panic恐慌模式
在恐慌模式中，KPA會在恐慌視窗期（預設為6秒）內計算Pod的平均並發數。恐慌視窗期=穩定視窗期*panic-window-percentage（panic-window-percentage取值是0～1，預設是0.1）。當請求突然增加導致當前Pod的使用率超過恐慌視窗百分比時，KPA會快速增加Pod的數量以滿足負載需求。

在KPA中，彈性生效的判斷是基於恐慌模式下計算得出的Pod數量是否超過恐慌閾值（PanicThreshold）。恐慌閾值=panic-threshold-percentage/100，panic-threshold-percentage預設為200，即恐慌閾值預設為2。

綜上所述，如果在恐慌模式下計算得出的Pod數量大於或等於當前Ready Pod數量的兩倍，那麼KPA將使用恐慌模式下計算得出的Pod數量進行彈性生效；否則，將使用穩定模式下計算得出的Pod數量。

KPA配置介紹

KPA的全域預設配置位於kantive-serving命名空間下ConfigMap的config-autoscaler中。您可以執行以下命令，查看config-autoscaler的預設配置。下文介紹重點參數。

kubectl -n knative-serving get cm config-autoscaler -o yaml

預期輸出（已忽略代碼中的注釋部分）：

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  _example:
    container-concurrency-target-default: "100"
    container-concurrency-target-percentage: "0.7"
    enable-scale-to-zero: "true"
    max-scale-up-rate: "1000"
    max-scale-down-rate: "2"
    panic-window-percentage: "10"
    panic-threshold-percentage: "200"
    scale-to-zero-grace-period: "30s"
    scale-to-zero-pod-retention-period: "0s"
    stable-window: "60s"
    target-burst-capacity: "200"
    requests-per-second-target-default: "200"

_example欄位下展示的參數配置為預設值。如需修改，請將_example欄位下相應的欄位複製到data欄位下進行修改。

說明

對config-autoscaler所做的修改對全域的Knative service生效。如需單獨對某個Knative service進行修改，您可以通過Annotation註解的方式。具體操作，請參考下文情境一：設定並發請求數實現自動擴縮容、情境二：設定擴縮容邊界實現自動擴縮容。

為KPA配置縮容至0

欄位	描述	樣本值
scale-to-zero-grace-period	在縮容至0之前，inactive revision保留的已耗用時間（最小時間為30s）。	30s
stable-window	Stable模式運行時，Autoscaler在穩定視窗期下平均並發數下的操作。此外, stable-window也可以在Revision注釋中配置，例如`autoscaling.knative.dev/window: 60s`。	60s
enable-scale-to-zero	設定欄位為`true`。	true

配置Autoscaler的並發數

欄位	描述	樣本值
container-concurrency-target-default	定義在指定時間（軟式節流）需要多少並發請求，為Knative中Autoscaler的推薦配置。ConfigMap中預設配置的並發target為100。此外, 此欄位值可以通過Revision中的`autoscaling.knative.dev/target`注釋進行修改，例如`autoscaling.knative.dev/target: 50`。	100
containerConcurrency	限制在給定時間內允許並發請求的數量。 1：確保一次只有1個請求由Revision給定的容器執行個體處理。 2-N：請求的並發值限制為2或更多。 0：不作限制，由系統自身決定。	0
container-concurrency-target-percentage	並發百分比，即並發因子，會直接參与擴縮容並發數計算。*實際擴縮容並發數=target（或者containerConcurrency）container-concurrency-target-percentage。*例如，如果並發數target或者containerConcurrency設定值為`100`，並發因子container-concurrency-target-percentage為`0.7`，那麼實際擔當並發數達到70（1000.7）時就會觸發擴容操作。	0.7

配置擴縮容邊界

通過minScale和maxScale，可以配置應用程式提供服務的最小和最大Pod數量，以控制服務冷啟動或者控制計算成本。

說明

如果未設定minScale注釋，Pod將縮放至0。
如果未設定maxScale注釋，建立的Pod數量將沒有上限。
如果設定config-autoscaler的enable-scale-to-zero為false，Pod將縮放至1。

minScale和maxScale可以在Revision模板中按照以下方式進行配置。

spec:
  template:
    metadata:
      autoscaling.knative.dev/minScale: "2"
      autoscaling.knative.dev/maxScale: "10"

情境一：設定並發請求數實現自動擴縮容

本情境將在叢集中部署autoscale-go應用，通過設定並發請求數，基於KPA實現自動擴縮容。

說明

關於如何使用Knative on ASM建立Knative服務，請參見使用Knative on ASM部署Serverless應用。

建立autoscale-go.yaml，設定並發目標數為10，即autoscaling.knative.dev/target取值為10。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: autoscale-go
  namespace: default
spec:
  template:
    metadata:
      labels:
        app: autoscale-go
      annotations:
        autoscaling.knative.dev/target: "10"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1

使用kubectl串連到叢集，在命令列執行以下命令部署autoscale-go。
```
kubectl apply -f autoscale-go.yaml
```
登入ASM控制台，單擊目標執行個體名稱，然後選擇ASM網關 > 入口網關，在服務地址地區，擷取IP。
使用Hey壓測工具，執行30s內保持50個並發請求。
關於Hey壓測工具的安裝步驟和詳細資料，請參見Hey。
說明
請將xxx.xxx.xxx.xxx替換為您實際的訪問網關地址。關於如何擷取訪問網關地址的具體操作，請參見擷取訪問網關地址。
```
hey -z 30s -c 50   -host "autoscale-go.default.example.com"   "http://xxx.xxx.xxx.xxx?sleep=100&prime=10000&bloat=5"
```
預期輸出：
預期輸出表明，整個過程中共擴容7個Pod。這是由於當容器並發量大於目標並發量的一定百分比後（預設為70%），Knative會提前建立更多的Pod備用，避免並發量進一步增加的情況下目標值被突破。

情境二：設定擴縮容邊界實現自動擴縮容

擴縮容邊界指應用程式提供服務的最小和最大Pod數量。本情境將在叢集中部署autoscale-go應用，通過設定應用程式提供服務的最小和最大Pod數量實現自動擴縮容。

說明