文章目錄

• • （一）基礎
  • • （1）認識
    • （2）Knative Serving對象模型
    • （3）knative-serving
    • （4）Knative的擴縮容流程原理
  • （二）彈性擴縮容實踐
  • • （1）自動擴縮容類型選擇
    • • 1. 介紹
      • 2.配置示例
    • （2）縮容至0和冷啟動問題
    • （3）Knative Service的彈性伸縮配置
    • （4）Knative Service灰度發布實踐
  • （三）參考命令
  • （四）參考

（一）基礎

（1）認識

Knative的服務管理組件Serving是管理應用服務的理想選擇，它通過自動縮容為零和基于HTTP負載自動擴展的方式簡化了部署流程。Knative平臺可管理應用服務的部署、版本、網絡、擴縮容。

（2）Knative Serving對象模型

【1】服務（Service）：service.serving.knative.dev資源自動管理用戶工作負載的整個生命周期。它控制路由和配置對象的創建，在服務更新時確保應用有對應的服務路由、配置和新的修訂版。服務可以被定義為總是把流量路由到最新的修訂版或特定修訂版。
【2】路由（Route）：route.serving.knative.dev資源用于映射一個網絡端點到一個或更多修訂版。你可以用多種方式來管理流量，包括分流和命名路由。
【3】配置（configuration）：configuration.serving.knative.dev資源維護了部署應用的最終狀態。它遵循云原生應用12要素原則，提供了代碼和配置分離的機制。每次修改配置會創建一個新的修訂版。
【4】修訂版（Revision）：revision.serving.knative.dev資源是在每次變更工作負載時生成的代碼和配置的時間點快照。修訂版是不可變對象。系統會保留有用的修訂版本，刪除不再使用的修訂版。修訂版對應的Pod實例數量會根據流量的大小自動進行伸縮。

（3）knative-serving

Knative Serving組件在啟動時會自動創建如上所示的一些pod工作負載，這些pod構成了Serving的整體管理能力。(備注：并非所有場景默認都是如上組件)
【1】activator（Service）：負責為不活躍狀態的修訂版接收并緩存請求，同時報告指標數據給Autoscaler。在Autoscaler擴展修訂版之后，它還負責將請求重試到修訂版
【2】autoscaler（Service）：接收請求指標數據并調整需要的Pod 數量以處理流量負載。
【3】autoscaler-hpa ：接收請求指標數據并調整需要的Pod 數量以處理流量負載。針對于 Horizontal Pod Autoscaler (HPA) 擴縮容類型實現。
【4】Controller（Service）：協調所有公共Knative對象，自動擴展CRD。當用戶請求一個Knative Service給Kubernetes API時，Controller將創建對應配置和路由，并將配置轉換為revision，同時將revision轉化為Deployment和KPA。
【5】default-domain：默認域名設置。默認情況下，路由的完全限定域名是{route}.{namespace}.{default-domain}. Knative Serving 路由example.com用作默認域。
【6】domain-mapping：自定義域名設置
【7】domainmapping-webhook：域名映射攔截處理模塊
【8】net-kourier-controller：Knative Kourier 網關控制器；
【9】webhook ：Webhook（Service）：攔截所有Kubernetes API調用以及所有CRD的插入和更新操作，用來設置默認值，拒絕不一致和無效的對象，驗證和修改Kubernetes API調用。

（4）Knative的擴縮容流程原理

【1】默認情況下，創建后的Pod副本在沒有請求后會變成0，縮容到0。當新的請求過來時，首先通過入口網關轉發給Activator組件，并報告數據給Autoscaler組件。
【2】接著Autoscaler會創建修訂版的Deployment對象，構建相應的Pod副本。
【3】Activator會將緩存的客戶端請求轉發給對應的Pod副本。Gateway然后會將新的請求直接轉發給相應的Pod副本，不再轉發給Activator。
【4】Autoscaler創建的pod中默認都有倆個容器，一個是User Container即對應的業務服務，一個是Queue Proxy是系統容器，以Sidecar方式存在，該容器負責向Autoscaler報告用戶容器流量指標。Autoscaler接收到這些指標之后，會根據流量指標及相應的算法調整Deployment的Pod副本數量，從而實現自動擴縮容，如果一段周期內沒有請求，Autoscaler會將Pod副本數設置為零，回收Pod所占資源。
【5】Autoscaler默認基于Pod接收到的并發請求數擴縮容資源。計算公式是：Pod數=并發請求總數/Pod并發請求數的目標值。

（二）彈性擴縮容實踐

（1）自動擴縮容類型選擇

1. 介紹

Knative Serving 支持 Knative Pod Autoscaler (KPA) 和 Kubernetes 的 Horizontal Pod Autoscaler (HPA) 的實現。
KPA：Knative Serving 核心的一部分，安裝 Knative Serving 后默認啟用。支持縮放到零功能。不支持基于 CPU 的自動縮放。
HPA：不是 Knative Serving 核心的一部分，需要單獨安裝。不支持縮放到零功能。支持基于 CPU 的自動縮放。
如果想要支持KPA，需要單獨安裝，安裝方式如下：

kubectl apply -f serving-hpa.yaml

yaml配置文件下載地址：https://github.com/knative/serving/releases，注意保持版本統一

修改自動擴縮容類型選擇可以有倆種設置方式，一個是Global (ConfigMap)全局設置，一個是Per Revision特定的修訂版本設置

2.配置示例

apiVersion: serving.knative.dev/v1 kind: Service metadata:name: helloworld-nodejs spec:template:metadata:labels:app: helloworld-nodejsannotations:autoscaling.knative.dev/class: "hpa.autoscaling.knative.dev"autoscaling.knative.dev/metric: "cpu"autoscaling.knative.dev/target: "75"autoscaling.knative.dev/minScale: "1"autoscaling.knative.dev/maxScale: "10"spec:containers:- image: registry.cn-hangzhou.aliyuncs.com/knative-samples/helloworld-go:160e4dc8resources:requests:cpu: '200m'

1：通過autoscaling.knative.dev/class: "hpa.autoscaling.knative.dev"指定HPA彈性插件。
2:通過autoscaling.knative.dev/metric設置HPA CPU指標。
3:通過autoscaling.knative.dev/target設置HPA CPU指標的閾值。
4:通過autoscaling.knative.dev/minScale: "1"設置彈性策略實例數的最小值。
5:通過autoscaling.knative.dev/maxScale: "10"設置彈性策略實例數的最大值。

上面的配置信息是針對Per Revision構建方式。構建命令通過kubectl apply 即可

上面的autoscaling.knative.dev/metric屬性設置了監控指標類型。指標可以是"concurrency", “rps” or “cpu” 。即并發數、每秒請求數、CPU使用率。
默認的設置是Default: “concurrency”

（2）縮容至0和冷啟動問題

縮容至0可以被啟用在設置KnativePodAutoscaler (KPA)類型下，且僅可以設置為全局配置。縮放到零值控制 Knative 是否允許副本縮小到零（如果設置為 true），或者如果設置為 false，則停止在 1 個副本。
屬性配置鍵為：enable-scale-to-zero。默認是true，即支持縮容至0個pod，設置為false,會保留一個副本

注意：這里著重說明下這個屬性，這個屬性是config-autoscaler的ConfigMap，我們可以通過下面命令查看其屬性信息

kubectl -n knative-serving describe cm config-autoscaler

默認是true代表可以縮容至0。雖然縮容至0可以有效的節省服務器資源的消耗，但是也帶來了一個很關鍵的問題，即Serverless中的冷啟動問題，就拿自己參與項目為例，一個應用鏡像打包后超過900M，如果縮容至0，那么在空閑后第一批請求過來了冷啟動的時間可能需要至少30s的時間才能啟動鏡像，而這對于用戶使用無疑是不友好的，所以我們對于一些核心，啟動耗時的應用需要進行預留實例，保留至少一個實例，這樣在新的請求過來可以立馬響應，對用戶使用沒有影響。

Tips：除了enable-scale-to-zero方式之外，還可以通過設置annotations的autoscaling.knative.dev/minScale來限制當前服務至少有一個負載存活

如果需要設置的話，可以將config-autoscaler組件的configMap的enable-scale-to-zero設置為false

kubectl -n knative-serving edit cm config-autoscaler

enable-scale-to-zero屬性值控制Knative修訂版縮容到零或保留1個副本。scale-to-zero-grace-period屬性值控制的是縮容到零的寬限周期。縮容到零的寬限周期是指系統在刪除最后一個副本之前等待的時間上限。默認值：30s。
參考配置如下

apiVersion: v1 kind: ConfigMap metadata:name: config-autoscalernamespace: knative-serving data:scale-to-zero-grace-period: "40s"

scale-to-zero-pod-retention-period屬性控制的是縮容到零時最后一個Pod的保留期。scale-to-zero-pod-retention-period定義了當Autoscaler決定要縮容到零時，最后一個Pod保留的最小時長。該設置主要針對那些啟動代價高、流量突發性高的場景。默認值：0s。

apiVersion: serving.knative.dev/v1 kind: Service metadata:name: helloworld-gonamespace: default spec:template:metadata:annotations:autoscaling.knative.dev/scaleToZeroPodRetentionPeriod: "1m5s"spec:containers:- image: gcr.io/knative-samples/helloworld-go

（3）Knative Service的彈性伸縮配置

Knative Serving為我們提供了一些擴縮容配置項，包括副本的初始大小，pod副本最小數量，最大數量限制。下面通過簡單的實例去分析下這些彈性伸縮配置
【1】準備測試服務配置文件，參考如下

apiVersion: serving.knative.dev/v1 kind: Service metadata:name: helloworld-go # Service名稱namespace: default spec:template:metadata:annotations:autoscaling.knative.dev/class: "kpa.autoscaling.knative.dev" # Autoscaler的實現方式,可選值有"kpa.autoscaling.knative.dev" 或 "hpa.autoscaling.knative.dev"autoscaling.knative.dev/metric: "concurrency" # 設置度量指標為concurrency（默認值），還可以根據業務情況選擇rps或cpu。autoscaling.knative.dev/target: "10" # 設置單個Pod最大并發數為10，默認值為100。autoscaling.knative.dev/minScale: "1" # minScale表示最小保留實例數為1autoscaling.knative.dev/maxScale: "100" # maxScale表示最大擴容實例數為3spec:containerConcurrency: 10 # 并發請求數的硬性限制。containers:- image: cnlab/helloworld-go

在上述配置中，revision中配置了修訂版的彈性伸縮策略。各個屬性代表的意義如下。
·autoscaling.knative.dev/class：表示Autoscaler的實現方式，這個屬
性的可選值有kpa.autoscaling.knative.dev或hpa.autoscaling.knative.dev。 KPA支持縮容到零，HPA支持基于CPU的擴展機制。
·autoscaling.knative.dev/metric：度量指標默認為并發數，該屬性
還可以根據業務情況選擇每秒請求數或CPU使用率。
·autoscaling.knative.dev/target：自動縮放的目標值是Autoscaler維
護應用的每個副本度量指標的目標值。
·autoscaling.knative.dev/minScale：表示每個修訂版副本需要保留
的最小數量。在任何時間點，副本不會少于這個數量。通過該設置，
我們可以有效地減少服務的冷啟動時間。
·autoscaling.knative.dev/maxScale：表示每個修訂版副本所能達到
的最大數量。在任何時間點，副本都不會超過指定的最大值，從而避
免資源被過度使用。

上面的配置僅使用了一部分，具體的可以參考官方文檔：
https://knative.dev/v1.0-docs/serving/autoscaling/scale-bounds/

【2】創建應用服務

kubectl apply -f service.yaml

可以通過rancher看到已經創建了pod，也可以通過下面的命令查看

kubectl get pod -l serving.knative.dev/service=helloworld-go

【3】因為設置了 autoscaling.knative.dev/minScale: “1” ，其中 minScale表示最小保留實例數為1，通過上圖可以觀察到存在一個pod

【4】Autoscaler基于每個Pod的平均請求數（并發數）進行自動擴縮容，默認并發數為100。Pod數=并發請求總數/容器并發數。如果服務中并發數設置為10，并且加載了50個并發請求的服務，則Autoscaler就會創建5個Pod。

【5】下面通過hey壓測工具進行測試
備注：下面的壓測工具使用的是hey,為了方便建議這里直接使用二進制包的方式
二進制包地址：
https://hey-release.s3.us-east-2.amazonaws.com/hey_linux_amd64

查看該pod分配的域名地址

kubectl get ksvc --namespace default

執行壓力測試，發起50個并發請求，持續30秒對hellowrold-go服務進行壓測。

./hey_linux_amd64 -c 50 -z 30s -host "helloworld-go.default.127.0.0.1.nip.io" "http://ip:30218"

執行壓測結束后，查看工作負載情況，執行命令

kubectl get pod -l serving.knative.dev/service=helloworld-go

正常情況下當發起的并發請求數是50個，服務自動縮放的目標值是10，按照“副本數=并發數/目標值”算法，那么pod數量就是5。但是在某些情況下，由于Knative Serving還有一個控制參數叫目標使用率，一旦并發數達到預設目標的70%（默認值），Autoscaler就會繼續擴容。引入目標使用率的主要目的是在擴容時減小由Pod啟動時間帶來的延遲，使負載到達前就將Pod實例啟動起來。

【6】在等待幾分鐘后，再次查詢就會發現pod數有降成1了，僅保留一個實例

（4）Knative Service灰度發布實踐

灰度部署是指逐漸將生產環境流量從老版本切換到新版本。通常流量是按比例分配的。例如 90% 的請求流向老版本，10% 的請求流向新版本。然后沒有發現問題，就逐步擴大新版本上的流量，減少老版本上的流量。
除了切流量外，對于多租戶的平臺，例如云計算平臺，灰度部署也可以將一些新的版本先部署到一些用戶上，如果沒有問題，擴大部署，直到全部用戶。一般的策略是，從內部用戶開始，然后是一般用戶，最后是大客戶。
這個技術大多數用于缺少足夠測試，或者缺少可靠測試，或者對新版本的穩定性缺乏信心的情況下。
把一部分用戶切到新版上來，然后看一下有沒有問題。如果沒有問題就繼續擴大升級，直到全部升級完成。
這里準備實例，當前所使用的是一個單體化項目，演示的場景如下：
【1】構建倆個版本的應用，這倆個版本一個作為舊版本，一個作為升級后的版本。通過不斷變更的流量比例來實現應用服務灰度發布，當前設置倆個revision各占50%的流量，即切換一半用戶訪問至新版本。
【2】倆個版本應用的鏡像通過docker push推送到私庫中：
【3】構建工作負載配置文件如下

apiVersion: serving.knative.dev/v1 kind: Service metadata:name: tag-headernamespace: serving-test spec:template:metadata:name: tag-header-revision-1spec:containers:- image: #鏡像1env:- name: TARGETvalue: "First Revision" --- apiVersion: serving.knative.dev/v1 kind: Service metadata:name: tag-headernamespace: serving-test spec:template:metadata:name: tag-header-revision-2spec:containers:- image: #鏡像2env:- name: TARGETvalue: "Second Revision"traffic:- tag: v1revisionName: tag-header-revision-1percent: 50 # 流量切分的百分比值- tag: v2revisionName: tag-header-revision-2percent: 50 # 流量切分的百分比值

【5】通過瀏覽器進行測試，由于是在內網自動分配的域名需修改本地的hosts文件

192.168.XXX.XXX tag-header.serving-test.127.0.0.1.nip.io

【6】Knative默認使用的是kourier網關，現在需要看下該網關暴露的端口入口信息，當前我們使用30218端口測試

kubectl --namespace kourier-system get service kourier

【7】測試tag-header.serving-test，觀察下面可以看到多次訪問時返回數據不同
測試地址：http://tag-header.serving-test.127.0.0.1.nip.io:30218/

通過多次訪問該地址可以發現結果不同，對應的流量被劃分到不同的應用服務中去了

（三）參考命令

【1】根據描述文件創建應用

kubectl apply -f service.yaml

【2】查看 Knative 工作負載

# 查詢命名空間serving-test下的工作負載 kubectl get ksvc --namespace serving-test

【3】查看應用詳細信息

# 查看knative-serving命名空間下configMap名稱config-autoscaler的詳細信息 kubectl -n knative-serving describe cm config-autoscaler# 查詢命名空間knative-serving下pod名稱為activator-645854dc69-b9ds9的詳細信息 kubectl describe pod activator-645854dc69-b9ds9 --namespace knative-serving

【4】編輯配置

# 編輯knative-serving命名空間下configMap名稱config-autoscaler的詳細信息 kubectl -n knative-serving edit cm config-autoscaler

【5】查詢pod信息

kubectl get pod -l serving.knative.dev/service=helloworld-go

【6】查看pod日志

kubectl logs輸出pod中一個容器的日志。輸出pod中一個容器的日志。如果pod只包含一個容器則可以省略容器名。

kubectl logs [-f] [-p] POD [-c CONTAINER]# 查看knative-serving命名空間中pod名稱autoscaler-78cd799dcc-zwk9l的日志信息 kubectl logs -f autoscaler-78cd799dcc-zwk9l --namespace knative-serving

（四）參考

【1】基于流量請求數實現服務自動擴縮容
https://knative.club/02serving/zi-dong-kuo-suo-rong-kpa-pei-zhi/ji-yu-liu-liang-qing-qiu-shu-shi-xian-fu-wu-zi-dong-kuo-suo-rong

【2】《Knative實戰：基于Kubernetes的無服務器架構實踐》Knative的服務管理組件Serving

【3】詳解 Knative Serving
https://www.jianshu.com/p/10b5b68e8cb1

【4】knative官方文檔彈性伸縮模塊
https://knative.dev/v1.0-docs/serving/autoscaling/

【5】阿里云開發者社區knative Serving
https://www.aliyun.com/search?k=Knative%20Serving&page=1&scm=

總結

以上是生活随笔為你收集整理的Serverless Knative Serving弹性扩缩容实践整理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。