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

01.

背景

生產(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ù)視角使用彈性能力。

02.

彈性技術(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。

當前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

03.

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

1.HPA

1.1 原生實現(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獲取當前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)用，重建可能會導致業(yè)務(wù)異常。

業(yè)界也有一種方案是在實現(xiàn)VPA的同時不重建Pod，即在節(jié)點層面調(diào)整container cgroup配置。但這種方案會打破K8s的資源管理模型，導致實際分配的資源與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ù)多種事件綜合做彈性決策

04.

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

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

TEM當前提供使用率較高的定時彈性策略和基于資源的彈性策略，對應(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.基于資源的彈性策略

在彈性伸縮策略中，選擇指標彈性策略，如下示例配置：當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é)合，在雙十二大促來臨之際，歡迎大家使用，滿足資源彈性的訴求。