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

01.

背景

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

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

02.

彈性技術(shù)

對(duì)于彈性技術(shù)，一般會(huì)從兩個(gè)維度進(jìn)行考慮：

·彈性策略

·彈性效率

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

1.彈性策略

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

·彈性觸發(fā)：定時(shí)彈性，基于資源的彈性，基于業(yè)務(wù)指標(biāo)的彈性，基于事件的彈性。

·彈性作用維度：HPA(Horizontal Pod Autoscale，水平彈性伸縮)，VPA(Vertical Pod Autoscale，垂直彈性伸縮)

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

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

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

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

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

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

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

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

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

1.2 彈性作用維度

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

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

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

2.彈性效率

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

在容器場(chǎng)景下，實(shí)例的運(yùn)行通常會(huì)有如下階段：

整體的流程會(huì)分為3個(gè)階段：

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

2.實(shí)例調(diào)度：將應(yīng)用實(shí)例調(diào)度到適合的節(jié)點(diǎn)

3.實(shí)例啟動(dòng)：這個(gè)過(guò)程通常會(huì)涉及到鏡像處理+啟動(dòng)兩個(gè)階段，先將鏡像拉取到節(jié)點(diǎn)上，然后啟動(dòng)容器。

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

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

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

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

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

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

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

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

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

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

【詳細(xì)鏈接】

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中的彈性能力實(shí)現(xiàn)

1.HPA

1.1 原生實(shí)現(xiàn)

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

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

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

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

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

1.業(yè)務(wù)方實(shí)現(xiàn)metrics-adapter：metrics-adapter提供Custom Metrics API或External Metrics API，滿足外部查詢指定metrics的需求；metrics-adapter從第三方獲取相應(yīng)的metrics數(shù)據(jù)。

2.業(yè)務(wù)方通過(guò)APIService資源進(jìn)行注冊(cè)：將對(duì)kube-apiserver的指標(biāo)請(qǐng)求與metrics-adapter關(guān)聯(lián)，便于kube-apiserver將請(qǐng)求轉(zhuǎn)發(fā)到metrics-adapter。

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

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

1.2 KEDA

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

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

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

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

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

2.VPA

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

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

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

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

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

小結(jié)

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

·有明顯潮汐流量特征的業(yè)務(wù)，可以重點(diǎn)使用定時(shí)彈性

·有突發(fā)流量特征的業(yè)務(wù)，可重點(diǎn)使用基于資源的彈性或指標(biāo)彈性

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

04.

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

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

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

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

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

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

1.定時(shí)彈性

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

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

2.基于資源的彈性策略

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

小結(jié)

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

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

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