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 執行原理,接下來介紹如何配置 KPA 或 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 http://test.default.172.31.162.220.sslip.io test-00001 test-00001 True
說明: 這裡使用的是 magicDNS,使用其他的地址可能會不一樣,請以實際使用為準。
-
訪問 service 。
curl http://test.default.172.31.162.220.sslip.io
a. pod 存在:執行並返回結果。
b. pod 不存在:autoscaler 擴容(冷啟動)到 1,然後執行並返回結果。
說明: 冷啟動時長從毫秒到分鐘級別,第一批流量可能會超時。
總結
以上就是 Knative Autoscale 的內容,通過 KPA 技術實現真正意義上的 Severless。
下期將為大家帶來 API 編排的應用及痛點,請大家持續關注。
引用連結
[1] Knavtive Serving:http://knative.dev/docs/serving
[2] Horizontal Pod Autoscaler:http://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale
[3] Kubernete Autoscaler:http://v1-17.docs.kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
作者
唐磊 青雲科技全象平臺部
本文由部落格一文多發平臺 OpenWrite 釋出!
- Kubernetes CRI 分析 - kubelet 建立 Pod 分析
- 終於有人把 ZFS 檔案系統講明白了
- KVSSD: 結合 LSM 與 FTL 以實現寫入優化的 KV 儲存
- 雲戰略現狀調查: 歡迎來到多雲時代!
- 雲戰略現狀調查: 歡迎來到多雲時代!
- 以 Serverless 的方式實現 Kubernetes 日誌告警
- Knative Autoscaler 自定義彈性伸縮
- 科技熱點週刊|Zoom 1 億美元、Docker 收費、380 億美元 Databricks
- 科技熱點週刊|Linux 30 週年、Horizon Workroom 釋出、Humanoid Robot、元宇宙
- KubeSphere 核心架構淺析
- Go 語言實現 WebSocket 推送
- 基於 SDN 編排的雲安全服務
- 複雜應用開發測試的 ChatOps 實踐
- 基於 Formily 的表單設計器實現原理分析
- SegmentFault 基於 Kubernetes 的容器化與持續交付實踐
- 基於 Kubernetes 的雲原生 AI 平臺建設
- 雲原生|新東方在有狀態服務 In K8s 的實踐
- 線上教育平臺青椒課堂:使用 KubeSphere QKE 輕鬆實現容器多叢集管理
- 人均雲原生2.0,容器的圈子內卷嗎?
- 儲存大師班:NFS 的誕生與成長