Knative Autoscaler 自定義彈性伸縮

本文分享自天翼雲開發者社群@《 Knative Autoscaler 自定義彈性伸縮 》，作者: 我是小朋友

 

背景

如今各大雲廠商都開始提供 Serverless Kubernetes 服務，簡化叢集管理，降低運維管理負擔，讓 Kubernetes 更加簡單。那麼問題來了，一個系統到底需要具備怎樣的能力才能更好地支撐 Serverless 應用呢？

Serverless 應用需要的是面向應用的管理功能，比如：升級、回滾、灰度釋出、流量管理以及彈性伸縮等功能。

Knative 就是建立在 Kubernetes 之上的 Serverless 應用編排框架。Knative 的主要功能之一是自動縮放應用程式的副本，包括在沒有收到流量時將應用程式縮放為 0。預設 Autoscaler 元件監視流向應用程式的流量，並根據配置的指標向上或向下擴充套件副本。本期主要講解 Knative Autoscaler 的原理和使用。

說明：

如需實踐 Knative Autoscaler 的使用，您可以先了解以下內容。

Kubernetes：需要準備一個 Kubernetes 的叢集，並學習相關的命令。

Knative Serving：您可以按照入門指南安裝 Knative 。

Autoscaler 原理

Autoscaler 根據監控到的指標（concurrency、rps、cpu等），並根據配置的指標來放大或縮小副本，從而實現自動擴縮容。

 

(來源：Kubernetes Autoscaler)

KPA VS HPA

Knative Serving 支援 Knative Pod Autoscaler（KPA）和 Kubernetes 的 Horizontal Pod Autoscaler（HPA）。以下是不同 scaler 的功能和侷限性。

KPA

Knative Serving 核心的一部分，並且在安裝 Knative Serving 後預設啟用；

支援從 0 擴充套件功能；

不支援基於 CPU 的自動縮放。

HPA

不是 Knative Serving 核心的一部分，安裝 Kubernetes 後預設啟動；

不支援從 0 擴充套件功能；

支援基於 CPU 的自動縮放。

scaling 配置

透過以上介紹，我們初步瞭解了 Autoscaler執行原理，接下來介紹如何配置KP A 或 HPA。

scaling 配置用於指定放大和縮小的行為，可以為兩個方向指定一個穩定視窗，以防止縮放目標中的副本數量波動。類似地，指定擴充套件策略可以控制擴充套件時副本的變化率。

可以使用 annotations 配置 Autoscaler 實現的型別（KPA 或 HPA）；

Global settings key：pod-autoscaler-class；

Per-revision annotation key：autoscaling.knative.dev/class；

Possible values：“kpa.autoscaling.knative.dev” or “hpa.autoscaling.knative.dev”；

Default：“kpa.autoscaling.knative.dev”；

 

配置示例：

apiVersion: serving.knative.dev/v1

kind: Service

metadata:

name: helloworld-go

namespace: default

spec:

template:

metadata:

annotations:

autoscaling.knative.dev/class: "kpa.autoscaling.knative.dev"

spec:

containers:

- image: gcr.io/knative-samples/helloworld-go

 

配置指標說明

度量標準配置定義自動定標器監視哪種度量標準型別，配置引數說明如下：

·  Setting metrics per revision: 對於 per-revision 配置，這是使用 autoscaling.knative.dev/metric 註解確定的。可以 per-revision 配置的可能的度量標準型別取決於使用的 Autoscaler 實現的型別：

·  預設的 KPA Autoscaler 支援併發和 rps 指標；

·  HPA Autoscaler 支援 cpu 指標。

·  Targets：配置 Targets 會為 Autoscaler 提供一個值，它會嘗試為 revision 的配置指標維護該值。

·  Configuring scale to zero：只有在使用 Knative Pod Autoscaler(KPA) 時才能啟用縮放為零，並且只能全域性配置。

·  Enable scale to zero：scale to zero 值控制 Knative 是否允許副本縮小到零（如果設定為 true），或者如果設定為 false 則停止在 1 個副本。

·  Scale to zero grace period：指定一個上限時間限制，系統將在內部等待從零開始縮放的機器在刪除最後一個副本之前就位。

·  Configuring concurrency：併發性決定了應用程式的每個副本在任何給定時間可以處理的併發請求數。

·  Soft versus hard concurrency limits：可以設定軟或硬併發限制。如果同時指定了軟限制和硬限制，則將使用兩個值中較小的一個。這可以防止 Autoscaler 具有硬限制值不允許的目標值。

·  Target utilization：指定 Autoscaler 實際應針對的先前指定目標的百分比。這也稱為指定副本執行的熱度，這會導致 Autoscaler 在達到定義的硬限制之前擴充套件。

·  Configuring scale bounds：配置上限和下限以控制自動縮放行為。還可以指定在建立後立即將 revision 縮放到的初始比例。

·  Lower bound：每個修訂版應具有的最小副本數。

·  Upper bound：每個修訂版應具有的最大副本數。

·  Initial scale：revision 在建立後必須立即達到的初始目標比例，然後再將其標記為就緒。

·  Scale Down Delay：縮減延遲指定了一個時間視窗，在應用縮減決策之前，該時間視窗必須以降低的併發性透過。

 

配置示例

在使用預設配置情況下的 Knative Serving (KPA)。

建立一個 demo 服務。

  cat <<-EOF | kubectl apply -f -

 apiVersion: serving.knative.dev/v1

 kind: Service

 metadata:

 name: test

 spec:

 template:

 metadata:

 annotations:

 initial-scale: "1"

 allow-zero-initial-scale: "false"

 enable-scale-to-zero: "false"

 spec:

 containers:

 - image: wentevill/demo:latest

 EOF

 

檢視 pod 狀態，在一段時間沒有流量的情況下，scale 到 0。

 kubectl get pods

 

 NAME                                                       READY   STATUS    RESTARTS   AGE

 test-00001-deployment-c4546964-mjwqm   2/2     Running   0          15s

 

檢視 ksvc 狀態。

 kubectl get ksvc

 

 NAME   URL                                           LATESTCREATED          LATESTREADY            READY   REASON

 test     test-00001             test-00001             True

 

說明：

這裡使用的是 magicDNS，使用其他的地址可能會不一樣，請以實際使用為準。

訪問 service 。

 curl

 

a. pod 存在：執行並返回結果。

b. pod 不存在：autoscaler 擴容(冷啟動)到 1，然後執行並返回結果。

說明：

冷啟動時長從毫秒到分鐘級別，第一批流量可能會超時。

 

總結

以上就是 Knative Autoscale 的內容，透過 KPA 技術實現真正意義上的 Severless。

引用連結

[1] Knavtive Serving：https://knative.dev/docs/serving

[2] Horizontal Pod Autoscaler：

[3] Kubernete Autoscaler：

 

原文連結： https://blog.csdn.net/Qingcloudedu/article/details/120292685