應(yīng)用彈性管理最佳實踐

背景

生產(chǎn)環(huán)境中，業(yè)務(wù)面臨的負載壓力變化是不定的，為了保障業(yè)務(wù)的穩(wěn)定性，需要根據(jù)負載大小的變化調(diào)整應(yīng)用實例的數(shù)量或資源規(guī)格，同時從資源成本角度考慮，需要在保障業(yè)務(wù)穩(wěn)定性的同時，盡量減少不必要的資源占用。

為了滿足上述兩方面的訴求，應(yīng)用管理平臺需要提供彈性能力。下述將整體分析彈性技術(shù)以及 K8s 中的實現(xiàn)，并通過一款云產(chǎn)品做演示，從業(yè)務(wù)視角使用彈性能力。

彈性技術(shù)

對于彈性技術(shù)，一般會從兩個維度進行考慮：

• 彈性策略

• 彈性效率

彈性策略重點關(guān)注如何管理觸發(fā)彈性行為的發(fā)生，以及彈性行為作用的維度，彈性效率重點關(guān)注彈性行為觸發(fā)后多快完成彈性任務(wù)。

1. 彈性策略

彈性策略主要關(guān)注彈性觸發(fā)、彈性作用維度，常見的包括：

• 彈性觸發(fā)：定時彈性，基于資源的彈性，基于業(yè)務(wù)指標的彈性，基于事件的彈性。
• 彈性作用維度：HPA (Horizontal Pod Autoscale，水平彈性伸縮)，VPA (Vertical Pod Autoscale，垂直彈性伸縮)

1.1 應(yīng)用彈性觸發(fā)的場景

場景1：很多應(yīng)用負載與時間有關(guān)，如多媒體處理應(yīng)用、游戲、電商等，會呈現(xiàn)出有明顯規(guī)律的請求流量高峰、低谷現(xiàn)象，且高峰、低谷持續(xù)的時間相對是連續(xù)的。

對于這種場景，可以考慮定時彈性策略，在指定的時間段內(nèi)維持固定數(shù)量的應(yīng)用數(shù)量，請求高峰時段保持較多的應(yīng)用實例，請求低峰時段保持較少的應(yīng)用實例，同時避免應(yīng)用實例數(shù)量在時間段內(nèi)波動。

場景2：應(yīng)用實例處理能力是有限的，在請求量增大時，若 CPU/Memory 等資源使用量超過一定限度，會影響應(yīng)用的服務(wù)性能。

對于這種場景，可以考慮基于資源使用率的彈性策略，定時計算應(yīng)用實例的 CPU/Memory 等資源的使用率，動態(tài)調(diào)整應(yīng)用實例數(shù)量，靈敏應(yīng)對突發(fā)流量。

場景3：應(yīng)用通常會有業(yè)務(wù)指標，如 QPS/RT/消息堆積數(shù) 等，業(yè)務(wù)指標的變化會影響業(yè)務(wù)服務(wù)質(zhì)量，而資源使用率不一定能夠反映出業(yè)務(wù)指標的變化，需要考慮其他方法應(yīng)對這種情況。

對于這種場景，可以考慮基于業(yè)務(wù)指標的彈性，定時計算 QPS/RT/消息堆積數(shù) 等業(yè)務(wù)維度的指標壓力，動態(tài)調(diào)整應(yīng)用實例數(shù)量，滿足業(yè)務(wù)服務(wù)質(zhì)量的需求。

場景4：實際生產(chǎn)中，時間因素、資源使用率、業(yè)務(wù)指標 不是互斥的，通常是混合出現(xiàn)。如在業(yè)務(wù)潮汐流量階段，會出現(xiàn)資源使用率、業(yè)務(wù)指標飆升情況，此時需要更為靈敏的基于資源的彈性策略和基于業(yè)務(wù)指標的彈性策略。

對于這種場景，可以將時間、資源使用率、業(yè)務(wù)指標作為無差別的事件，根據(jù)事件做彈性行為觸發(fā)的判斷，即基于事件的彈性。

1.2 彈性作用維度

在彈性行為發(fā)生時，通常的做法是調(diào)整實例數(shù)量，做水平伸縮。在固定資源規(guī)格情況下，單個實例處理能力有限且可以預(yù)期的，通過調(diào)整實例數(shù)量來控制應(yīng)用整體的處理能力，這種做法更為普適和可控，即 HPA。

還有一種方式是調(diào)整實例規(guī)格，如調(diào)大、調(diào)小實例的 CPU/Memory 等資源的上限，提升單個實例的處理能力，即 VPA。

當(dāng)前 HPA 比 VPA 更易理解、滿足預(yù)期和更強的可控性，通常在彈性策略執(zhí)行時，會通過 HPA 的方式作用于應(yīng)用實例。

2. 彈性效率

彈性效率關(guān)注彈性策略執(zhí)行時，多長時間可以執(zhí)行完成。下述以 HPA 場景為例，分析影響彈性效率的因素和改善措施。

在容器場景下，實例的運行通常會有如下階段：

整體的流程會分為 3 個階段：

1. 鏡像構(gòu)建：對于代碼包 (如 war/jar) 形態(tài)的交付物，需要有個構(gòu)建過程，將代碼包構(gòu)建成鏡像

2. 實例調(diào)度：將應(yīng)用實例調(diào)度到適合的節(jié)點
3. 實例啟動：這個過程通常會涉及到 鏡像處理+啟動 兩個階段，先將鏡像拉取到節(jié)點上，然后啟動容器。

可以針對上述每個階段進行優(yōu)化，提升彈性效率。

鏡像構(gòu)建階段，可采用具有高效構(gòu)建的服務(wù)，如 buildkit，充分利用 build cache、concurrent dependency resolution 等能力提升鏡像構(gòu)建效率。針對 Java 類應(yīng)用，也可以采用類似 jib 等項目加速 Java 類鏡像的構(gòu)建。鏡像構(gòu)建好之后，需要將鏡像推送到指定的 registry 中，也可以考慮通過 buildkit 工具控制?是否壓縮層數(shù)據(jù)?和?推送層的并發(fā)量?來提升效率。

實例調(diào)度階段，若調(diào)度過程中涉及資源準備等，可通過 K8s Scheduler Framework 提供的插件機制進行擴展，將多個流程并行處理。也可以考慮在這個過程中實現(xiàn) 鏡像預(yù)熱，在實例調(diào)度到的節(jié)點確定后，對于目標節(jié)點發(fā)起鏡像拉取操作，可考慮使用 OpenKruise 提供的 ImagePullJob 實現(xiàn)鏡像預(yù)熱。

實例啟動階段，會涉及?鏡像處理?和?啟動?兩個階段，在鏡像處理過程中，又會有?鏡像拉取?和?鏡像解壓?兩個階段，需要分別考慮優(yōu)化措施。參考下圖，鏡像拉取時涉及到鏡像層下載和解壓。

containerd 支持調(diào)整拉取鏡像層的并發(fā)量，配置可參見 config，通過該配置調(diào)節(jié)拉取鏡像層的并發(fā)量。詳細鏈接：

https://github.com/containerd/containerd/blob/main/docs/cri/config.md

containerd 從 1.2 版本開始支持 pigz，節(jié)點上安裝 unpigz 工具后，會優(yōu)先用其進行解壓。通過這種方法，可通過節(jié)點多核能力提升鏡像解壓效率。

上述思路是?將鏡像完整拉到節(jié)點后再啟動容器，還可參考業(yè)界 《Slacker: Fast Distribution with Lazy Docker Containers》paper，采用?邊拉鏡像邊啟動容器?的方法進一步提升容器啟動效率。

社區(qū)有類似的實現(xiàn)，參見 stargz-snapshotter。目前國內(nèi)各大云廠商也有相應(yīng)的技術(shù)實現(xiàn)，如騰訊云 ImageApparate等。

容器啟動后會涉及到應(yīng)用程序的啟動，對于 Java 類應(yīng)用，可以考慮采用啟動效率優(yōu)化的 JVM Runtime，如騰訊云 KonaJDK等。

【詳細鏈接】

1. Slacker: Fast Distribution with Lazy Docker Container：https://www.usenix.org/conference/fast16/technical-sessions/presentation/harter

2. stargz-snapshotter：https://github.com/containerd/stargz-snapshotter

3. ImageApparate：https://mp.weixin.qq.com/s?__biz=Mzg5NjA1MjkxNw%3D%3D&mid=2247492105&idx=1&sn=26c2f4eabde8975e2e4974a33622dcde

4. KonaJDK：https://github.com/Tencent/TencentKona-11

K8s中的彈性能力實現(xiàn)

通過 Kubernetes monitoring architecture 可了解到 K8s HPA 的實現(xiàn)：

如上圖所示，K8s 中有 2 條 metrics 數(shù)據(jù)采集鏈路 Core Metrics Pipeline 和 Monitoring Pipeline，分別對應(yīng)基于資源的彈性策略和基于指標的彈性策略。

對于 Core Metrics Pipeline，kube-apiserver 通過 metrics-server 組件獲取 Pod 的 cpu/memory 使用情況，然后由 kube-controller-manager (簡稱 kcm) 訪問 kube-apiserver 獲取 workload 的資源利用率，根據(jù)算法判斷是否要對目標 workload 進行擴縮容操作，處理詳情可參見 Horizontal Pod Autoscaler：https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

其中 metrics-server 是 K8s 社區(qū)維護的項目，K8s 集群中部署 metrics-server 組件后，立即可以使用基于資源的彈性能力。

對于 Monitoring Pipeline，實現(xiàn)流程為：

1. 業(yè)務(wù)方實現(xiàn) metrics-adapter：metrics-adapter 提供 Custom Metrics API 或 External Metrics API，滿足外部查詢指定 metrics 的需求；metrics-adapter 從第三方獲取相應(yīng)的 metrics 數(shù)據(jù)。
2. 業(yè)務(wù)方通過 APIService 資源進行注冊：將對 kube-apiserver 的指標請求與 metrics-adapter 關(guān)聯(lián)，便于 kube-apiserver 將請求轉(zhuǎn)發(fā)到 metrics-adapter。

3. kcm 中的 HPA Controller 按照配置和 HPA 資源，請求 kube-apiserver 獲取當(dāng)前 metrics 數(shù)據(jù)，計算是否需要對指定的 workload 進行擴縮，若需要，則調(diào)用指定 workload 的?/scale 接口進行擴縮。

K8s 社區(qū)為了簡化 metrics-adapter 實現(xiàn)成本，提供了一個開發(fā)框架，將 metrics-adapter 中通用實現(xiàn)邏輯模板化，可參見custom-metrics-apiserver：https://github.com/kubernetes-sigs/custom-metrics-apiserver。

1.2 KEDA

對于彈性能力的實現(xiàn)，不得不提 KEDA 項目，它是微軟推出的基于事件的彈性伸縮項目，已捐贈給 CNCF，是 CNCF incubating 中的項目，被廣泛用于生產(chǎn)環(huán)境 (參見 keda users)。

KEDA 的概念和設(shè)計如下：

KEDA 將 K8s Core Metrics Pipeline 和 Monitoring Pipeline 處理流程統(tǒng)一化，并內(nèi)置多種 scaler ( link )，提供開箱即用的彈性策略支持，如常見的基于 CPU/Memory 的彈性策略、定時彈性等：

平臺維護者可通過實現(xiàn) scaler 來擴展彈性策略，支持更豐富的彈性策略，實現(xiàn)參見 External Scalers：https://keda.sh/docs/2.4/concepts/external-scalers/

比較推薦平臺層面使用 KEDA 來統(tǒng)一彈性能力的實現(xiàn)，將時間、CPU/Memory 等資源使用率、業(yè)務(wù)指標等作為 KEDA 的數(shù)據(jù)源，統(tǒng)一化為事件，基于事件滿足對彈性策略的需求。

2. VPA

VPA 是另一種彈性行為的實現(xiàn)，用戶可以不再顯式配置 workload 的資源申請量，由 VerticalPodAutoscaler 自動配置 workload 資源量，并自動根據(jù) Pod 資源使用情況調(diào)整 Pod 資源申請量，項目參見autoscaler/vertical-pod-autoscaler：https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler

目前該項目還處于實驗階段，生產(chǎn)環(huán)境中謹慎使用。公有云產(chǎn)品中，GKE 對 VPA 進行了支持，詳情參見：https://cloud.google.com/kubernetes-engine/docs/concepts/verticalpodautoscaler

上述 VPA 實現(xiàn)在調(diào)整 Pod 資源配置時會重建 Pod，對于一些對重建敏感的應(yīng)用，重建可能會導(dǎo)致業(yè)務(wù)異常。

業(yè)界也有一種方案是在實現(xiàn) VPA 的同時不重建 Pod，即在節(jié)點層面調(diào)整 container cgroup 配置。但這種方案會打破 K8s 的資源管理模型，導(dǎo)致實際分配的資源與 K8s 調(diào)度鏈路感知到的資源申請量不一致，會影響 K8s 集群整體的調(diào)度，同時也有可能影響節(jié)點自身的穩(wěn)定性。

目前 K8s 社區(qū)有一個 KEP 討論 In-place Update of Pod Resources，可以持續(xù)關(guān)注社區(qū)對 VPA 的標準化和支持：https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1287-in-place-update-pod-resources

小結(jié)

上述整體介紹了彈性技術(shù)和 K8s 中彈性能力的實現(xiàn)，在業(yè)務(wù)場景中，需要根據(jù)業(yè)務(wù)需求，實現(xiàn)和使用與需求匹配的彈性能力，避免過度使用高級能力影響業(yè)務(wù)穩(wěn)定性，如：

• 有明顯潮汐流量特征的業(yè)務(wù)，可以重點使用?定時彈性

• 有突發(fā)流量特征的業(yè)務(wù)，可重點使用?基于資源的彈性?或?指標彈性
• 若業(yè)務(wù)是混合流量特征，即既有潮汐流量特征，又有突發(fā)流量特征，可重點使用?基于事件的彈性，根據(jù)多種事件綜合做彈性決策

基于云產(chǎn)品實踐

彈性微服務(wù)TEM (Tencent Cloud Elastic Microservice) 是騰訊云推出的面向微服務(wù)應(yīng)用的 Serverless PaaS 平臺，實現(xiàn)資源 Serverless 與微服務(wù)架構(gòu)的完美結(jié)合，提供一整套開箱即用的微服務(wù)解決方案。

TEM 當(dāng)前提供使用率較高的定時彈性策略和基于資源的彈性策略，對應(yīng)的彈性動作行為均為?HPA，接下來會支持基于指標彈性策略和基于事件彈性策略，滿足用戶對更靈活的彈性策略的需求。

同時針對 Java 應(yīng)用，TEM 近期會支持?KonaJDK11，提升 Java 應(yīng)用的啟動效率，并計劃支持更為通用的?按需拉取的啟動策略，進一步提升彈性效率，敬請期待。

TEM 中，用戶可以在兩個流程中配置彈性策略，一種是在應(yīng)用部署過程中，一種是在應(yīng)用部署后在應(yīng)用詳情頁中配置彈性策略。推薦后者，更靈活組合應(yīng)用管理的能力。

可在應(yīng)用部署后的詳情頁中編輯彈性伸縮來配置彈性策略：

1. 定時彈性

在彈性伸縮策略中，選擇?定時策略，如下示例配置：每天 11:00~14:00 期間保持 10 個實例，14:00~18:00 期間保持 2 個實例，18:00~23:00 期間保持 10 個實例，23:00~11:00 保持 2 個實例。

配置提交后，可通過?預(yù)覽?可視化查看未來執(zhí)行效果：

2. 基于資源的彈性策略

在彈性伸縮策略中，選擇?指標彈性策略，如下示例配置：當(dāng) CPU 使用率不小于 60% 時，擴縮應(yīng)用實例數(shù)量，擴縮范圍為 2~20：

總結(jié)

通過理解彈性技術(shù)，可以在業(yè)務(wù)中更好選擇合適的彈性策略來滿足需求，并根據(jù)業(yè)務(wù)對彈性效率的訴求，選擇合適的技術(shù)優(yōu)化彈性效率，或在彈性效率限制下，優(yōu)化彈性策略的使用。

Serverless 云產(chǎn)品提供了資源池的能力，用戶不用關(guān)心資源池的準備、運維等工作，將注意力集中在業(yè)務(wù)層面對資源彈性的需求，面對潮汐流量或突發(fā)流量，在大促等活動中更好保障業(yè)務(wù)穩(wěn)定性，降低業(yè)務(wù)運行成本。

騰訊云 TEM 是一款面向微服務(wù)應(yīng)用的 Serverless PaaS 平臺，實現(xiàn)資源 Serverless 與微服務(wù)架構(gòu)的完美結(jié)合，在雙十一大促來臨之際，歡迎大家使用，滿足資源彈性的訴求。

One more thing

TEM 本周已在北京開服，目前國內(nèi)站支持 北京/上海/廣州 區(qū)域，國際站支持東京區(qū)域，歡迎大家使用，根據(jù)業(yè)務(wù)覆蓋用戶地域就近選擇區(qū)域。