Knative Serving如何自動擴縮容Autoscaler

這篇文章將為大家詳細講解有關Knative Serving如何自動擴縮容Autoscaler，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

Knative Serving 默認情況下，提供了開箱即用的快速、基于請求的自動擴縮容功能 - Knative Pod Autoscaler（KPA）。下面帶你體驗如何在 Knative 中玩轉 Autoscaler。

Autoscaler 機制

Knative Serving 為每個 POD 注入 QUEUE 代理容器 (queue-proxy)，該容器負責向 Autoscaler 報告用戶容器并發指標。Autoscaler 接收到這些指標之后，會根據并發請求數及相應的算法，調整 Deployment 的 POD 數量，從而實現自動擴縮容。

算法

Autoscaler 基于每個 POD 的平均請求數（并發數）進行擴所容處理。默認并發數為 100。<br />POD 數=并發請求總數/容器并發數

如果服務中并發數設置了 10，這時候如果加載了 50 個并發請求的服務，Autoscaler 就會創建了 5 個 POD （50 個并發請求/10=POD）。

Autoscaler 實現了兩種操作模式的縮放算法：Stable（穩定模式）和 Panic（恐慌模式）。

穩定模式

在穩定模式下，Autoscaler 調整 Deployment 的大小，以實現每個 POD 所需的平均并發數。 POD 的并發數是根據 60 秒窗口內接收所有數據請求的平均數來計算得出。

恐慌模式

Autoscaler 計算 60 秒窗口內的平均并發數，系統需要 1 分鐘穩定在所需的并發級別。但是，Autoscaler 也會計算 6 秒的恐慌窗口，如果該窗口達到目標并發的 2 倍，則會進入恐慌模式。在恐慌模式下，Autoscaler 在更短、更敏感的緊急窗口上工作。一旦緊急情況持續 60 秒后，Autoscaler 將返回初始的 60 秒穩定窗口。

|
                                  Panic Target--->  +--| 20
                                                    |  |
                                                    | <------Panic Window
                                                    |  |
       Stable Target--->  +-------------------------|--| 10   CONCURRENCY
                          |                         |  |
                          |                      <-----------Stable Window
                          |                         |  |
--------------------------+-------------------------+--+ 0
120                       60                           0
                     TIME

配置 KPA

通過上面的介紹，我們對 Knative Pod Autoscaler 工作機制有了初步的了解，那么接下來介紹如何配置 KPA。在 Knative 中配置 KPA 信息，需要修改 k8s 中的 ConfigMap：config-autoscaler，該 ConfigMap 在 knative-serving 命名空間下。查看 config-autoscaler 使用如下命令：

kubectl -n knative-serving get cm config-autoscaler

默認的 ConfigMap 如下：

apiVersion: v1
kind: ConfigMap
metadata:
 name: config-autoscaler
 namespace: knative-serving
data:
 container-concurrency-target-default: 100
 container-concurrency-target-percentage: 1.0
 enable-scale-to-zero: true
 enable-vertical-pod-autoscaling: false
 max-scale-up-rate: 10
 panic-window: 6s
 scale-to-zero-grace-period: 30s
 stable-window: 60s
 tick-interval: 2s

為 KPA 配置縮容至 0

為了正確配置使 Revision 縮容為 0，需要修改 ConfigMap 中的如下參數。

scale-to-zero-grace-period

scale-to-zero-grace-period 表示在縮為 0 之前，inactive revison 保留的運行時間（最小是3 0s）。

scale-to-zero-grace-period: 30s

stable-window

當在 stable mode 模式運行中，autoscaler 在穩定窗口期下平均并發數下的操作。

stable-window: 60s

stable-window 同樣可以配置在 Revision 注釋中。

autoscaling.knative.dev/window: 60s

enable-scale-to-zero

保證 enable-scale-to-zero 參數設置為 true<br />

Termination period

Termination period（終止時間）是 POD 在最后一個請求完成后關閉的時間。POD 的終止周期等于穩定窗口值和縮放至零寬限期參數的總和。在本例中，Termination period 為 90 秒。<br />

配置并發數

可以使用以下方法配置 Autoscaler 的并發數：

target

target 定義在給定時間（軟限制）需要多少并發請求，是 Knative 中 Autoscaler 的推薦配置。

在 ConfigMap 中默認配置的并發 target 為 100。

`container-concurrency-target-default: 100`

這個值可以通過 Revision 中的 autoscaling.knative.dev/target 注釋進行修改：

autoscaling.knative.dev/target: 50

containerConcurrency

注意：只有在明確需要限制在給定時間有多少請求到達應用程序時，才應該使用 containerConcurrency (容器并發)。只有當應用程序需要強制的并發約束時，才建議使用 containerConcurrency。

containerConcurrency 限制在給定時間允許并發請求的數量（硬限制），并在 Revision 模板中配置。

containerConcurrency: 0 | 1 | 2-N

• 1: 將確保一次只有一個請求由 Revision 給定的容器實例處理；

• 2-N: 請求的并發值限制為2或更多；

• 0: 表示不作限制，有系統自身決定。

配置擴縮容邊界（minScale 和 maxScale）

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

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

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

通過在 Revision 模板中修改這些參數，將會影響到 PodAutoscaler 對象，這也表明在無需修改 Knative Serving 系統配置的情況下，PodAutoscaler 對象是可被修改的。

edit podautoscaler <revision-name>

注意：這些注釋適用于 Revision 的整個生命周期。即使 Revision 沒有被任何 route 引用，minscale 指定的最小 POD 計數仍將提供。請記住，不可路由的 Revision 可能被垃圾收集掉。

默認情況

如果未設置 minscale 注釋，pods 將縮放為零（如果根據上面提到的 configmap，enable-scale-to-zero 為 false，則縮放為 1）。

如果未設置 maxscale 注釋，則創建的 Pod 數量將沒有上限。

基于 KPA 配置的示例

Knative 0.7 版本部署安裝可以參考：阿里云部署 Knative

我們使用官方提供的 autoscale-go 示例來進行演示，示例 service.yaml 如下：

apiVersion: serving.knative.dev/v1alpha1
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 get svc istio-ingressgateway --namespace istio-system --output jsonpath="{.status.loadBalancer.ingress[*]['ip']}"
121.199.194.150

Knative 0.7 版本中獲取域名信息：

$ kubectl get route autoscale-go --output jsonpath="{.status.url}"| awk -F/ '{print $3}'
autoscale-go.default.example.com

場景1：并發請求示例

如上配置，當前最大并發請求數 10。 我們執行 30s 內保持 50 個并發請求，看一下執行情況：

hey -z 30s -c 50   -host "autoscale-go.default.example.com"   "http://121.199.194.150?sleep=100&prime=10000&bloat=5"

結果正如我們所預期的：擴容出來了 5 個 POD。

場景2：擴縮容邊界示例

修改一下 servcie.yaml 配置如下：

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

當前最大并發請求數 10，minScale 最小保留實例數為 1，maxScale 最大擴容實例數為 3。

我們依然執行 30s 內保持 50 個并發請求，看一下執行情況：

hey -z 30s -c 50   -host "autoscale-go.default.example.com"   "http://121.199.194.150?sleep=100&prime=10000&bloat=5"

結果如我們所預期：最多擴容出來了 3 個POD，并且即使在無訪問請求流量的情況下，保持了 1 個運行的 POD。

看了上面的介紹，是不是感覺在 Knative 中配置應用擴縮容是如此簡單？其實 Knative 中除了支持 KPA 之外，也支持K8s HPA。你可以通過如下配置基于 CPU 的 Horizontal POD Autoscaler（HPA）。

通過在修訂模板中添加或修改 autoscaling.knative.dev/class 和 autoscaling.knative.dev/metric 值作為注釋，可以將Knative 配置為使用基于 CPU 的自動縮放，而不是默認的基于請求的度量。配置如下：

spec:
  template:
    metadata:
      autoscaling.knative.dev/metric: concurrency
      autoscaling.knative.dev/class: hpa.autoscaling.knative.dev

你可以自由的將 Knative Autoscaling 配置為使用默認的 KPA 或 Horizontal POD Autoscaler（HPA）。

關于Knative Serving如何自動擴縮容Autoscaler就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。