超大規(guī)模商用 K8s 場(chǎng)景下，阿里巴巴如何動(dòng)態(tài)解決容器資源的按需分配問(wèn)題？

作者 |?張曉宇（衷源）? 阿里云容器平臺(tái)技術(shù)專家

導(dǎo)讀：資源利用率一直是很多平臺(tái)管理和研發(fā)人員關(guān)心的話題。本文作者通過(guò)阿里巴巴容器平臺(tái)團(tuán)隊(duì)在這一領(lǐng)域的工作實(shí)踐，整理出了一套資源利用提升的方案，希望能夠帶給大家?guī)?lái)一些討論和思考。

引言

不知道大家有沒(méi)有過(guò)這樣的經(jīng)歷：當(dāng)我們擁有了一套 Kubernetes 集群，然后開(kāi)始部署應(yīng)用的時(shí)候，我們應(yīng)該給容器分配多少資源呢？

這很難說(shuō)。由于 Kubernetes 自己的機(jī)制，我們可以理解容器的資源實(shí)質(zhì)上是一個(gè)靜態(tài)的配置。

• 如果我發(fā)現(xiàn)資源不足，為了分配給容器更多資源，我們需要重建 Pod；
• 如果分配冗余的資源，那么我們的 worker node 節(jié)點(diǎn)似乎又部署不了多少容器。

試問(wèn)，我們能做到容器資源的按需分配嗎？接下來(lái)，我們將在本次分享中和大家一起進(jìn)行探討這個(gè)問(wèn)題的答案。

生產(chǎn)環(huán)境中的真實(shí)挑戰(zhàn)

首先請(qǐng)?jiān)试S我們根據(jù)我們的實(shí)際情況拋出我們實(shí)際生產(chǎn)環(huán)境的挑戰(zhàn)?；蛟S大家還記得 2018 年的天貓雙 11，這一天的總成交額達(dá)到了 2135 億。由此一斑可窺全豹，能夠支撐如此龐大規(guī)模的交易量背后的系統(tǒng)，其應(yīng)用種類和數(shù)量應(yīng)該是怎樣的一種規(guī)模。

在這種規(guī)模下，我們常常聽(tīng)到的容器調(diào)度，如：容器編排，負(fù)載均衡，集群擴(kuò)縮容，集群升級(jí)，應(yīng)用發(fā)布，應(yīng)用灰度等等這些詞，在被“超大規(guī)模集群”這個(gè)詞修飾后，都不再是件容易處理的事情。規(guī)模本身也就是我們最大的挑戰(zhàn)。如何運(yùn)營(yíng)和管理好這么一個(gè)龐大的系統(tǒng)，并遵循業(yè)界 dev-ops 宣傳的那樣效果，猶如讓大象去跳舞。但是馬老師曾說(shuō)過(guò)，大象就該干大象該干的事情，為什么要去跳舞呢。

Kubernetes 的幫助

cdn.com/a20c0dfb35bf47b45d1f7791daa53c7531222775.png">

大象是否可以跳舞，帶著這個(gè)問(wèn)題，我們需要從淘寶、天貓等 APP 背后系統(tǒng)說(shuō)起。

這套互聯(lián)網(wǎng)系統(tǒng)應(yīng)用部署大致可分為三個(gè)階段，傳統(tǒng)部署，虛擬機(jī)部署和容器部署。相比于傳統(tǒng)部署，虛擬機(jī)部署有了更好的隔離性和安全性，但是在性能上不可避免的產(chǎn)生了大量損耗。而容器部署又在虛擬機(jī)部署實(shí)現(xiàn)隔離和安全的背景下，提出了更輕量化的解決方案。我們的系統(tǒng)也是沿著這么一條主航道上運(yùn)行的。假設(shè)底層系統(tǒng)好比一艘巨輪，面對(duì)巨量的集裝箱---容器，我們需要一個(gè)優(yōu)秀的船長(zhǎng)，對(duì)它們進(jìn)行調(diào)度編排，讓系統(tǒng)這艘大船可以避開(kāi)層層險(xiǎn)阻，操作難度降低，且具備更多靈活性，最終達(dá)成航行的目的。

理想與現(xiàn)實(shí)

在開(kāi)始之初，想到容器化和 Kubernetes 的各種美好場(chǎng)景，我們理想中的容器編排效果應(yīng)該是這樣的：

• 從容：我們的工程師更加從容的面對(duì)復(fù)雜的挑戰(zhàn)，不再眉頭緊鎖而是更多笑容和自信；
• 優(yōu)雅：每一次線上變更操作都可以像品著紅酒一樣氣定神閑，優(yōu)雅地按下執(zhí)行的回車鍵；
• 有序：從開(kāi)發(fā)到測(cè)試，再到灰度發(fā)布，一氣呵成，行云流水；
• 穩(wěn)定：系統(tǒng)健壯性良好，任爾東西南北風(fēng)，我們系統(tǒng)巋然不動(dòng)。全年系統(tǒng)可用性 N 多個(gè) 9；
• 高效：節(jié)約出更多人力，實(shí)現(xiàn)“快樂(lè)工作，認(rèn)真生活”。

然而理想很豐滿，現(xiàn)實(shí)很骨感。迎接我們的卻是雜亂和形態(tài)各異的窘迫。

雜亂，是因?yàn)樽鳛橐粋€(gè)異軍突起的新型技術(shù)棧，很多配套工具和工作流的建設(shè)處于初級(jí)階段。Demo 版本中運(yùn)行良好的工具，在真實(shí)場(chǎng)景下大規(guī)模鋪開(kāi)，各種隱藏的問(wèn)題就會(huì)暴露無(wú)遺，層出不窮。從開(kāi)發(fā)到運(yùn)維，所有的工作人員都在各種被動(dòng)地疲于奔命。另外，“大規(guī)模鋪開(kāi)”還意味著，要直接面對(duì)形態(tài)各異的生產(chǎn)環(huán)境：異構(gòu)配置的機(jī)器、復(fù)雜的需求，甚至是適配用戶的既往的使用習(xí)慣等等。

除了讓人心力交瘁的混亂，系統(tǒng)還面臨著應(yīng)用容器的各種崩潰問(wèn)題：內(nèi)存不足導(dǎo)致的 OOM，CPU quota 分配太少，導(dǎo)致進(jìn)程被 throttle，還有帶寬不足，響應(yīng)時(shí)延大幅上升...甚至是交易量在面對(duì)訪問(wèn)高峰時(shí)候由于系統(tǒng)不給力導(dǎo)致的斷崖式下跌等等。這些都使我們?cè)诖笠?guī)模商用 Kubernetes 場(chǎng)景中積累非常多的經(jīng)驗(yàn)。

直面問(wèn)題

穩(wěn)定性

問(wèn)題總要進(jìn)行面對(duì)的。正如某位高人說(shuō)過(guò)：如果感覺(jué)哪里不太對(duì)，那么肯定有些地方出問(wèn)題了。于是我們就要剖析，問(wèn)題究竟出在哪里。針對(duì)于內(nèi)存的 OOM，CPU 資源被 throttle，我們可以推斷我們給與容器分配的初始資源不足。

資源不足就勢(shì)必造成整個(gè)應(yīng)用服務(wù)穩(wěn)定性下降。例如上圖的場(chǎng)景：雖然是同一種應(yīng)用的副本，或許是由于負(fù)載均衡不夠強(qiáng)大，或者是由于應(yīng)用自身的原因，甚至是由于機(jī)器本身是異構(gòu)的，相同數(shù)值的資源，可能對(duì)于同一種應(yīng)用的不同副本并具有相等的價(jià)值和意義。在數(shù)值上他們看似分配了相同的資源，然而在實(shí)際負(fù)載工作時(shí)，極有可能出現(xiàn)的現(xiàn)象是肥瘦不均的。

而在資源 overcommit 的場(chǎng)景下，應(yīng)用在整個(gè)節(jié)點(diǎn)資源不足，或是在所在的 CPU share pool 資源不足時(shí)，也會(huì)出現(xiàn)嚴(yán)重的資源競(jìng)爭(zhēng)關(guān)系。資源競(jìng)爭(zhēng)是對(duì)應(yīng)用穩(wěn)定性最大的威脅之一。所以我們要盡力在生產(chǎn)環(huán)境中清除所有的威脅。

我們都知道穩(wěn)定性是件很重要的事情，尤其對(duì)于掌控上百萬(wàn)容器生殺大權(quán)的一線研發(fā)人員?；蛟S不經(jīng)心的一個(gè)操作就有可能造成影響面巨大的生產(chǎn)事故。

因此，我們也按照一般流程做了系統(tǒng)預(yù)防和兜底工作。

• 在預(yù)防維度，我們可以進(jìn)行全鏈路的壓力測(cè)試，并且提前通過(guò)科學(xué)的手段預(yù)判應(yīng)用需要的副本數(shù)和資源量。如果沒(méi)法準(zhǔn)確預(yù)算資源，那就只采用冗余分配資源的方式了。
• 在兜底維度，我們可以在大規(guī)模訪問(wèn)流量抵達(dá)后，對(duì)不緊要的業(yè)務(wù)做服務(wù)降級(jí)并同時(shí)對(duì)主要應(yīng)用進(jìn)行臨時(shí)擴(kuò)容。

但是對(duì)于陡然增加幾分鐘的突增流量，這么多組合拳的花費(fèi)不菲，似乎有些不劃算?；蛟S我們可以提出一些解決方案，達(dá)到我們的預(yù)期。

資源利用率

回顧一下我們的應(yīng)用部署情況：節(jié)點(diǎn)上的容器一般分屬多種應(yīng)用，這些應(yīng)用本身不一定，也一般不會(huì)同時(shí)處于訪問(wèn)的高峰。對(duì)于混合部署應(yīng)用的宿主機(jī)，如果能都錯(cuò)峰分配上面運(yùn)行容器的資源或許更科學(xué)。

應(yīng)用的資源需求可能就像月亮一樣有陰晴圓缺，有周期變化。例如在線業(yè)務(wù)，尤其是交易業(yè)務(wù)，它們?cè)谫Y源使用上呈現(xiàn)一定的周期性，例如：在凌晨、上午時(shí)，它的使用量并不是很高，而在午間、下午時(shí)會(huì)比較高。

打個(gè)比方：對(duì)于 A 應(yīng)用的重要時(shí)刻，對(duì)于 B 應(yīng)用可能不那么重要，適當(dāng)打壓 B 應(yīng)用，騰挪出資源給 A 應(yīng)用，這是個(gè)不錯(cuò)的選擇。這聽(tīng)起來(lái)有點(diǎn)像是分時(shí)復(fù)用的感覺(jué)。但是如果我們按照流量峰值時(shí)的需求配置資源就會(huì)產(chǎn)生大量的浪費(fèi)。

除了對(duì)于實(shí)時(shí)性要求很高的在線應(yīng)用外，我們還有離線應(yīng)用和實(shí)時(shí)計(jì)算應(yīng)用等：離線計(jì)算對(duì)于 CPU 、Memory 或網(wǎng)絡(luò)資源的使用以及時(shí)間不那么敏感，所以在任何時(shí)間段它都可以運(yùn)行；實(shí)時(shí)計(jì)算，可能對(duì)于時(shí)間敏感性就會(huì)很高。

早期，我們業(yè)務(wù)是在不同的節(jié)點(diǎn)按照應(yīng)用的類型獨(dú)立進(jìn)行部署。從上面這張圖來(lái)看，如果它們進(jìn)行分時(shí)復(fù)用資源，針對(duì)實(shí)時(shí)性這個(gè)需求層面，我們會(huì)發(fā)現(xiàn)它實(shí)際的最大使用量不是 2+2+1=5，而是某一時(shí)刻重要緊急應(yīng)用需求量的最大值，也就是 3 。如果我們能夠數(shù)據(jù)監(jiān)測(cè)到每個(gè)應(yīng)用的真實(shí)使用量，給它分配合理值，那么就能產(chǎn)生資源利用率提升的實(shí)際效果。

對(duì)于電商應(yīng)用，對(duì)于采用了重量級(jí) Java 框架和相關(guān)技術(shù)棧的 Web 應(yīng)用，短時(shí)間內(nèi) HPA 或者 VPA 都不是件容易的事情。

先說(shuō) HPA，我們或許可以秒級(jí)拉起了 Pod，創(chuàng)建新的容器，然而拉起的容器是否真的可用呢。從創(chuàng)建到可用，可能需要比較久的時(shí)間，對(duì)于大促和搶購(gòu)秒殺-這種訪問(wèn)量“洪峰”可能僅維持幾分鐘或者十幾分鐘的實(shí)際場(chǎng)景，如果我們等到 HPA 的副本全部可用，可能市場(chǎng)活動(dòng)早已經(jīng)結(jié)束了。

至于社區(qū)目前的 VPA 場(chǎng)景，刪掉舊 Pod，創(chuàng)建新 Pod，這樣的邏輯更難接受。所以綜合考慮，我們需要一個(gè)更實(shí)際的解決方案彌補(bǔ) HPA 和 VPA 的在這一單機(jī)資源調(diào)度的空缺。

解決方案

交付標(biāo)準(zhǔn)

我們首先要對(duì)解決方案設(shè)定一個(gè)可以交付的標(biāo)準(zhǔn)那就是—— “既要穩(wěn)定性，也要利用率，還要自動(dòng)化實(shí)施，當(dāng)然如果能夠智能化那就更好”，然后再交付標(biāo)準(zhǔn)進(jìn)行細(xì)化：

• 安全穩(wěn)定：工具本身高可用。所用的算法和實(shí)施手段必須做到可控；
• 業(yè)務(wù)容器按需分配資源：可以及時(shí)根據(jù)業(yè)務(wù)實(shí)時(shí)資源消耗對(duì)不太久遠(yuǎn)的將來(lái)進(jìn)行資源消耗預(yù)測(cè)，讓用戶明白業(yè)務(wù)接下來(lái)對(duì)于資源的真實(shí)需求；
• 工具本身資源開(kāi)銷小：工具本身資源的消耗要盡可能小，不要成為運(yùn)維的負(fù)擔(dān)；
• 操作方便，擴(kuò)展性強(qiáng)：能做到無(wú)需接受培訓(xùn)即可玩轉(zhuǎn)這個(gè)工具，當(dāng)然工具還要具有良好擴(kuò)展性，供用戶 DIY；
• 快速發(fā)現(xiàn) & 及時(shí)響應(yīng)：實(shí)時(shí)性，也就是最重要的特質(zhì)，這也是和HPA或者VPA在解決資源調(diào)度問(wèn)題方式不同的地方。

設(shè)計(jì)與實(shí)現(xiàn)

上圖是我們最初的工具流程設(shè)計(jì)：當(dāng)一個(gè)應(yīng)用面臨很高的業(yè)務(wù)訪問(wèn)需求時(shí)，體現(xiàn)在 CPU、Memory 或其他資源類型需求量變大，我們根據(jù) Data Collector 采集的實(shí)時(shí)基礎(chǔ)數(shù)據(jù)，利用 Data Aggregator 生成某個(gè)容器或整個(gè)應(yīng)用的畫(huà)像，再將畫(huà)像反饋給 Policy engine。 Policy engine 會(huì)瞬時(shí)快速修改容器 Cgroup 文件目錄下的的參數(shù)。

我們最早的架構(gòu)和我們的想法一樣樸實(shí)，在 kubelet 進(jìn)行了侵入式的修改。雖然我們只是加了幾個(gè)接口，但是這種方式確實(shí)不夠優(yōu)雅。每次 kubenrnetes 升級(jí)，對(duì)于 Policy engine 相關(guān)組件升級(jí)也有一定的挑戰(zhàn)。

為了做到快速迭代并和 Kubelet 解耦，我們對(duì)于實(shí)現(xiàn)方式進(jìn)行了新的演進(jìn)。那就是將關(guān)鍵應(yīng)用容器化。這樣可以達(dá)到以下功效：

• 不侵入修改 K8s 核心組件；
• 方便迭代&發(fā)布；
• 借助于 Kubernetes 相關(guān)的 QoS Class 機(jī)制，容器的資源配置，資源開(kāi)銷可控。

當(dāng)然在后續(xù)演進(jìn)中，我們也在嘗試和 HPA，VPA 進(jìn)行打通，畢竟這些和 Policy engine 存在著互補(bǔ)的關(guān)系。因此我們架構(gòu)進(jìn)一步演進(jìn)成如下情形。當(dāng) Policy engine 在處理一些更多復(fù)雜場(chǎng)景搞到無(wú)力時(shí)，上報(bào)事件讓中心端做出更全局的決策。水平擴(kuò)容或是垂直增加資源。

下面我們具體討論一下 Policy engine 的設(shè)計(jì)。Policy engine 是單機(jī)節(jié)點(diǎn)上進(jìn)行智能調(diào)度并執(zhí)行 Pod 資源調(diào)整的核心組件。它主要包括 api server，指揮中心 command center 和執(zhí)行層 executor。

• 其中 api server 用于服務(wù)外界對(duì)于 policy engine 運(yùn)行狀態(tài)的查詢和設(shè)置的請(qǐng)求；
• command center 根據(jù)實(shí)時(shí)的容器畫(huà)像和物理機(jī)本身的負(fù)載以及資源使用情況，作出 Pod 資源調(diào)整的決策；
• Executor 再根據(jù) command center 的決策，對(duì)容器的資源限制進(jìn)行調(diào)整。同時(shí)，executor 也把每次調(diào)整的 revision info 持久化，以便發(fā)生故障時(shí)可以回滾。

指揮中心定期從 data aggregator 獲取容器的實(shí)時(shí)畫(huà)像，包括聚合的統(tǒng)計(jì)數(shù)據(jù)和預(yù)測(cè)數(shù)據(jù)，首先判斷節(jié)點(diǎn)狀態(tài)，例如節(jié)點(diǎn)磁盤異常，或者網(wǎng)絡(luò)不通，表示該節(jié)點(diǎn)已經(jīng)發(fā)生異常，需要保護(hù)現(xiàn)場(chǎng)，不再對(duì)Pod進(jìn)行資源調(diào)整，以免造成系統(tǒng)震蕩，影響運(yùn)維和調(diào)試。如果節(jié)點(diǎn)狀態(tài)正常，指揮中心會(huì)策略規(guī)則，對(duì)容器數(shù)據(jù)進(jìn)行再次過(guò)濾。比如容器 CPU 率飆高，或者容器的響應(yīng)時(shí)間超過(guò)安全閾值。如果條件滿足，則對(duì)滿足條件的容器集合給出資源調(diào)整建議，傳遞給executor。

在架構(gòu)設(shè)計(jì)上，我們遵循了以下原則：

• 插件化：所有的規(guī)則和策略被設(shè)計(jì)為可以通過(guò)配置文件來(lái)修改，盡量與核心控制流程的代碼解耦，與 data collector 和 data aggregator 等其他組件的更新和發(fā)布解耦，提升可擴(kuò)展性；

• 穩(wěn)定，這包括以下幾個(gè)方面：

  • 控制器穩(wěn)定性。指揮中心的決策以不影響單機(jī)乃至全局穩(wěn)定性為前提，包括容器的性能穩(wěn)定和資源分配穩(wěn)定。例如，目前每個(gè)控制器僅負(fù)責(zé)一種 cgroup 資源的控制，即在同一時(shí)間窗口內(nèi)，Policy engine 不同時(shí)調(diào)整多種資源，以免造成資源分配震蕩，干擾調(diào)整效果；
  • 觸發(fā)規(guī)則穩(wěn)定性。例如，某一條規(guī)則的原始觸發(fā)條件為容器的性能指標(biāo)超出安全閾值，但是為避免控制動(dòng)作被某一突發(fā)峰值觸發(fā)而導(dǎo)致震蕩，我們把觸發(fā)規(guī)則定制為：過(guò)去一段時(shí)間窗口內(nèi)性能指標(biāo)的低百分位超出安全閾值；如果規(guī)則滿足，說(shuō)明這段時(shí)間內(nèi)絕大部分的性能指標(biāo)值都已經(jīng)超出了安全閾值，就需要觸發(fā)控制動(dòng)作了；
  • 另外，與社區(qū)版? Vertical-Pod-Autoscaler 不同，Policy engine 不主動(dòng)驅(qū)逐騰挪容器，而是直接修改容器的 cgroup 文件；

• 自愈：資源調(diào)整等動(dòng)作的執(zhí)行可能會(huì)產(chǎn)生一些異常，我們?cè)诿總€(gè)控制器內(nèi)都加入了自愈回滾機(jī)制，保證整個(gè)系統(tǒng)的穩(wěn)定性；

• 不依賴應(yīng)用先驗(yàn)知識(shí)：為所有不同的應(yīng)用分別進(jìn)行壓測(cè)、定制策略，或者提前對(duì)可能排部在一起的應(yīng)用進(jìn)行壓測(cè)，會(huì)導(dǎo)致巨大開(kāi)銷，可擴(kuò)展性降低。我們的策略在設(shè)計(jì)上盡可能通用，盡量采用不依賴于具體平臺(tái)、操作系統(tǒng)、應(yīng)用的指標(biāo)和控制策略。

在資源調(diào)整方面，Cgroup 支持我們對(duì)各個(gè)容器的 CPU、內(nèi)存、網(wǎng)絡(luò)和磁盤 IO 帶寬資源進(jìn)行隔離和限制，目前我們主要對(duì)容器的 CPU 資源進(jìn)行調(diào)整，同時(shí)在測(cè)試中探索在時(shí)分復(fù)用的場(chǎng)景下動(dòng)態(tài)調(diào)整 memory limit 和 swap usage 而避免 OOM 的可行性；在未來(lái)我們將支持對(duì)容器的網(wǎng)絡(luò)和磁盤 IO 的動(dòng)態(tài)調(diào)整。

調(diào)整效果

上圖展示了我們?cè)跍y(cè)試集群得到的一些實(shí)驗(yàn)結(jié)果。我們把高優(yōu)先級(jí)的在線應(yīng)用和低優(yōu)先級(jí)的離線應(yīng)用混合部署在測(cè)試集群里。SLO 是 250ms，我們希望在線應(yīng)用的 latency 的 95 百分位值低于閾值 250ms。

在實(shí)驗(yàn)結(jié)果中可以看到：

• 在大約90s前，在線應(yīng)用的負(fù)載很低；latency 的均值和百分位都在 250ms 以下；
• 到了? 90s后，我們給在線應(yīng)用加壓，流量增加，負(fù)載也升高，導(dǎo)致在線應(yīng)用 latency 的 95 百分位值超過(guò)了 SLO；
• 在大約 150s 左右，我們的小步快跑控制策略被觸發(fā)，漸進(jìn)式地 throttle 與在線應(yīng)用發(fā)生資源競(jìng)爭(zhēng)的離線應(yīng)用；
• 到了大約 200s 左右，在線應(yīng)用的性能恢復(fù)正常，latency 的 95 百分位回落到 SLO 以下。

這說(shuō)明了我們的控制策略的有效性。

經(jīng)驗(yàn)和教訓(xùn)

下面我們總結(jié)一下在整個(gè)項(xiàng)目的進(jìn)行過(guò)程中，我們收獲的一些經(jīng)驗(yàn)和教訓(xùn)，希望這些經(jīng)驗(yàn)教訓(xùn)能夠?qū)τ龅筋愃茊?wèn)題和場(chǎng)景的人有所幫助。

1. 避開(kāi)硬編碼，組件微服務(wù)化，不僅便于快速演進(jìn)和迭代，還有利于熔斷異常服務(wù)。
2. 盡可能不要調(diào)用類庫(kù)中還是 alpha 或者 beta 特性的接口。 例如我們?cè)?jīng)直接調(diào)用 CRI 接口讀取容器的一些信息，或者做一些更新操作，但是隨著接口字段或者方法的修改，共建有些功能就會(huì)變得不可用，或許有時(shí)候，調(diào)用不穩(wěn)定的接口還不如直接獲取某個(gè)應(yīng)用的打印信息可能更靠譜。
3. 基于 QoS 的資源動(dòng)態(tài)調(diào)整方面：如我們之前所講，阿里集團(tuán)內(nèi)部有上萬(wàn)個(gè)應(yīng)用，應(yīng)用之間的調(diào)用鏈相當(dāng)復(fù)雜。應(yīng)用 A 的容器性能發(fā)生異常，不一定都是在單機(jī)節(jié)點(diǎn)上的資源不足或者資源競(jìng)爭(zhēng)導(dǎo)致，而很有可能是它下游的應(yīng)用 B、應(yīng)用 C，或者數(shù)據(jù)庫(kù)、cache 的訪問(wèn)延遲導(dǎo)致的。由于單機(jī)節(jié)點(diǎn)上這種信息的局限性，基于單機(jī)節(jié)點(diǎn)信息的資源調(diào)整，只能采用“盡力而為”，也就是 best effort 的策略了。在未來(lái)，我們計(jì)劃打通單機(jī)節(jié)點(diǎn)和中心端的資源調(diào)控鏈路，由中心端綜合單機(jī)節(jié)點(diǎn)上報(bào)的性能信息和資源調(diào)整請(qǐng)求，統(tǒng)一進(jìn)行資源的重新分配，或者容器的重新編排，或者觸發(fā) HPA，從而形成一個(gè)集群級(jí)別的閉環(huán)的智能資源調(diào)控鏈路，這將會(huì)大大提高整個(gè)集群維度的穩(wěn)定性和綜合資源利用率。
4. 資源v.s.性能模型：可能有人已經(jīng)注意到，我們的調(diào)整策略里，并沒(méi)有明顯地提出為容器建立“資源v.s.性能”的模型。這種模型在學(xué)術(shù)論文里非常常見(jiàn)，一般是對(duì)被測(cè)的幾種應(yīng)用進(jìn)行了離線壓測(cè)或者在線壓測(cè)，改變應(yīng)用的資源分配，測(cè)量應(yīng)用的性能指標(biāo)，得到性能隨資源變化的曲線，最終用在實(shí)時(shí)的資源調(diào)控算法中。在應(yīng)用數(shù)量比較少，調(diào)用鏈比較簡(jiǎn)單，集群里的物理機(jī)硬件配置也比較少的情況下，這種基于壓測(cè)的方法可以窮舉到所有可能的情況，找到最優(yōu)或者次優(yōu)的資源調(diào)整方案，從而得到比較好的性能。但是在阿里集團(tuán)的場(chǎng)景下，我們有上萬(wàn)個(gè)應(yīng)用，很多重點(diǎn)應(yīng)用的版本發(fā)布也非常頻繁，往往新版本發(fā)布后，舊的壓測(cè)數(shù)據(jù)，或者說(shuō)資源性能模型，就不適用了。另外，我們的集群很多是異構(gòu)集群，在某一種物理機(jī)上測(cè)試得到的性能數(shù)據(jù)，在另一臺(tái)不同型號(hào)的物理機(jī)上就不會(huì)復(fù)現(xiàn)。這些都對(duì)我們直接應(yīng)用學(xué)術(shù)論文里的資源調(diào)控算法帶來(lái)了障礙。所以，針對(duì)阿里集團(tuán)內(nèi)部的場(chǎng)景，我們采用了這樣的策略：不對(duì)應(yīng)用進(jìn)行離線壓測(cè)，獲取顯示的資源性能模型。而是建立實(shí)時(shí)的動(dòng)態(tài)容器畫(huà)像，用過(guò)去一段時(shí)間窗口內(nèi)容器資源使用情況的統(tǒng)計(jì)數(shù)據(jù)作為對(duì)未來(lái)一小段時(shí)間內(nèi)的預(yù)測(cè)，并且動(dòng)態(tài)更新；最后基于這個(gè)動(dòng)態(tài)的容器畫(huà)像，執(zhí)行小步快跑的資源調(diào)整策略，邊走邊看，盡力而為。

總結(jié)與展望

總結(jié)起來(lái)，我們的工作主要實(shí)現(xiàn)了以下幾方面的收益：

• 通過(guò)分時(shí)復(fù)用以及將不同優(yōu)先級(jí)的容器（也就是在線和離線任務(wù)）混合部署，并且通過(guò)對(duì)容器資源限制的動(dòng)態(tài)調(diào)整，保證了在線應(yīng)用在不同負(fù)載情況下都能得到足夠的資源，從而提高集群的綜合資源利用率。
• 通過(guò)對(duì)單機(jī)節(jié)點(diǎn)上的容器資源的智能動(dòng)態(tài)調(diào)整，降低了應(yīng)用之間的性能干擾，保障高優(yōu)先級(jí)應(yīng)用的性能穩(wěn)定性
• 各種資源調(diào)整策略通過(guò) Daemonset 部署，可以自動(dòng)地、智能地在節(jié)點(diǎn)上運(yùn)行，減少人工干預(yù)，降低了運(yùn)維的人力成本。

展望未來(lái)，我們希望在以下幾個(gè)方面加強(qiáng)和擴(kuò)展我們的工作：

• 閉環(huán)控制鏈路：前面已經(jīng)提到，單機(jī)節(jié)點(diǎn)上由于缺乏全局信息，對(duì)于資源的調(diào)整有其局限性，只能盡力而為。未來(lái)，我們希望能夠打通與 HPA 和 VPA 的通路，使單機(jī)節(jié)點(diǎn)和中心端聯(lián)動(dòng)進(jìn)行資源調(diào)整，最大化彈性伸縮的收益。
• 容器重新編排：即使是同一個(gè)應(yīng)用，不同容器的負(fù)載和所處的物理環(huán)境也是動(dòng)態(tài)變化的，單機(jī)上調(diào)整 pod 的資源，不一定能夠滿足動(dòng)態(tài)的需求。我們希望單機(jī)上實(shí)時(shí)容器畫(huà)像，能夠?yàn)橹行亩颂峁└嗟挠行畔?，幫助中心端的調(diào)度器作出更加智能的容器重編排決策。
• 策略智能化：我們現(xiàn)在的資源調(diào)整策略仍然比較粗粒度，可以調(diào)整的資源也比較有限；后續(xù)我們希望讓資源調(diào)整策略更加智能化，并且考慮到更多的資源，比如對(duì)磁盤和網(wǎng)絡(luò)IO帶寬的調(diào)整，提高資源調(diào)整的有效性。
• 容器畫(huà)像精細(xì)化：目前的容器畫(huà)像也比較粗糙，僅僅依靠統(tǒng)計(jì)數(shù)據(jù)和線性預(yù)測(cè)；刻畫(huà)容器性能的指標(biāo)種類也比較局限。我們希望找到更加精確的、通用的、反映容器性能的指標(biāo)，以便更加精細(xì)地刻畫(huà)容器當(dāng)前的狀態(tài)和對(duì)不同資源的需求程度。
• 查找干擾源：我們希望能找到在單機(jī)節(jié)點(diǎn)上找到行之有效的方案，來(lái)精準(zhǔn)定位應(yīng)用性能受損時(shí)的干擾源；這對(duì)策略智能化也有很大意義。

Q & A

Q1：直接修改 cgroup 容器一定會(huì)獲得資源嗎？
A1：容器技術(shù)隔離的技術(shù)基礎(chǔ)就是 cgroup 層面。在宿主機(jī)騰出足夠資源的情況下，給 cgroup 設(shè)置更大的值可以獲取更多的資源。同理，對(duì)于一般優(yōu)先級(jí)不高的應(yīng)用，設(shè)置較低的 cgroup 資源值就會(huì)達(dá)到抑制容器運(yùn)行的效果。

Q2：底層是如何區(qū)分在線和離線優(yōu)先級(jí)的？
A2：底層是無(wú)法自動(dòng)獲取誰(shuí)是在線，誰(shuí)是離線，或者誰(shuí)的優(yōu)先級(jí)高，誰(shuí)的優(yōu)先級(jí)低的。這個(gè)我們可以通過(guò)各種 Kubernetes 提供的擴(kuò)展實(shí)現(xiàn)。最簡(jiǎn)單的是通過(guò) label，Annotation 標(biāo)識(shí)。當(dāng)然通過(guò)擴(kuò)展 QoS class 也是一種思路。社區(qū)版本的 QoS class設(shè)置太過(guò)于保守，給予用戶發(fā)揮的空間不大。我們通過(guò)這些方面也進(jìn)行了增強(qiáng)。在合適的時(shí)候或許會(huì)推向社區(qū)。自動(dòng)感知是個(gè)方向，感知誰(shuí)是干擾源，感知誰(shuí)是某種資源型應(yīng)用，這塊我們還在研發(fā)中。做到真正的動(dòng)態(tài)，肯定是具備自動(dòng)感知的智能系統(tǒng)。

Q3：“與社區(qū)版? Vertical-Pod-Autoscaler 不同，Policy engine 不主動(dòng)驅(qū)逐騰挪容器，而是直接修改容器的 cgroup 文件”，想問(wèn)一下，不主動(dòng)驅(qū)逐的話，如果 Node 的資源達(dá)到上線了會(huì)怎么處理？
A3：這是一個(gè)好問(wèn)題。首先這里要先區(qū)分是哪種資源，如果是 CPU 型的，我們可以調(diào)整低優(yōu)先級(jí)容器的 cgroup 下 cpu quota 的值，首先抑制低優(yōu)先級(jí)的容器對(duì)于 CPU 的爭(zhēng)搶。然后再適當(dāng)上調(diào)高優(yōu)先級(jí)容器的相關(guān)資源值。如果是內(nèi)存型資源，這個(gè)不能直接去縮小低優(yōu)先級(jí)容器的 cgroup 值，否則會(huì)造成 OOM，對(duì)于學(xué)習(xí)內(nèi)存型資源的調(diào)整，我們會(huì)在其他分享中繼續(xù)討論。這個(gè)技術(shù)比較特殊。

Q4：只修改 cgroup，怎么保證 K8s 對(duì)單個(gè)物理機(jī)能夠分配更多的容器？
A4：文字直播有了一定說(shuō)明，容器的資源消耗并非是一成不變的，很多時(shí)候它們的資源消耗呈現(xiàn)潮汐現(xiàn)象，相同的資源條件下部署更多應(yīng)用，完成更多作業(yè)就是達(dá)到資源利用的最大化的效果。資源出現(xiàn)超賣才是我們這個(gè)主題討論的最大價(jià)值。

Q5：也就是說(shuō)，低優(yōu)先級(jí)的容器，request 設(shè)置的比 limit 小很多，然后你們?cè)賱?dòng)態(tài)的調(diào)整 cgroup？
A5：在現(xiàn)有 QoS 場(chǎng)景下，你可以理解被調(diào)整的 Pod 都是 burstable 的。但是我們并不是直接調(diào)整 Pod 元數(shù)據(jù)的 limit 的值，而是調(diào)整 limit 在 cgroup 反映的值，這個(gè)值在資源競(jìng)爭(zhēng)緩和的時(shí)候還會(huì)被調(diào)整回去的。我們并不建議單機(jī)的 cgroup 數(shù)據(jù)和 etcd 的中心數(shù)據(jù)割裂太久。如果長(zhǎng)期偏離，我們會(huì)像 VPA 發(fā)出警報(bào)，聯(lián)動(dòng) VPA 做調(diào)整。當(dāng)然在容器運(yùn)行的高峰期，任何重建容器的操作都是不明智的。

Q6：整體的理解就是你們開(kāi)始就讓物理機(jī)超配了一定比例的 pod，然后通過(guò)策略動(dòng)態(tài)調(diào)整容器的 cgroup 值？
A6：如果資源完全是富足冗余的，這個(gè)動(dòng)態(tài)調(diào)整也有一定意義。就是并非資源用滿場(chǎng)景下，高優(yōu)先級(jí)應(yīng)用會(huì)被干擾，實(shí)際上，當(dāng)主機(jī)的 CPU 達(dá)到一定比例，打個(gè)比方例如 50%，應(yīng)用的時(shí)延就變大。為了完全確保高優(yōu)先級(jí)應(yīng)用的 SLO，犧牲低優(yōu)先級(jí)的 CPU 正常運(yùn)行也是有價(jià)值的。

Q7:Policy engine 有沒(méi)有考慮開(kāi)源？
A7：有計(jì)劃進(jìn)行開(kāi)源，Policy engine 更多的是和自身的應(yīng)用屬性相關(guān)，電商應(yīng)用或者大數(shù)據(jù)處理應(yīng)用的策略都是不相同的，我們開(kāi)源會(huì)首先開(kāi)源框架和附帶一些簡(jiǎn)單的策略，更多的策略可以用戶自定義。

Q8：我之前遇到的大部分應(yīng)用都無(wú)法正確感知 cgroup 的配置，因此很多情況都需要在啟動(dòng)參數(shù)里面根據(jù) cpu 或者 mem 設(shè)置參數(shù)，那么也就是說(shuō)即使改變了 cgroup 對(duì)于他們來(lái)說(shuō)都無(wú)效，那么使用場(chǎng)景也就有限了
A8：限制容器的資源使用這個(gè)還是有價(jià)值的。限制低優(yōu)先級(jí)應(yīng)用本身也可以提升高優(yōu)先級(jí)應(yīng)用的 SLO，雖然效果沒(méi)有那么明顯。穩(wěn)定性的考量同樣也很重要。

Q9:Policy engine 目前在阿里的使用如何？在生產(chǎn)上有多上的規(guī)模使用這種方式進(jìn)行動(dòng)態(tài)調(diào)整？是否和社區(qū)的 HPA VPA 配合使用？
A9:?Policy engine 在阿里某些集群已經(jīng)使用。至于規(guī)模暫時(shí)無(wú)法透漏。涉及到很多組件之間的聯(lián)動(dòng)，社區(qū)的 HPA 和 VPA 目前都不太能滿足我們的需求。因此阿里的 HPA 和 VPA 都是我們自行開(kāi)發(fā)的，但是和社區(qū)的原理是一致的。阿里 HPA 的開(kāi)源可以關(guān)注 Openkruise 社區(qū)。VPA 開(kāi)源計(jì)劃我這里還沒(méi)有確切消息。

Q10：當(dāng)單機(jī)節(jié)點(diǎn)資源不足以提供容器擴(kuò)容時(shí)，目前是否可以進(jìn)行 HPA 或 VPA 擴(kuò)容呢？
A10：單機(jī)節(jié)點(diǎn)不足的時(shí)候，應(yīng)用可以通過(guò) HPA 進(jìn)行增加副本應(yīng)對(duì)。但是 VPA 如果選擇原節(jié)點(diǎn)進(jìn)行更新的話，是失敗的。只能調(diào)度到其他資源豐富的節(jié)點(diǎn)。在流量陡升的場(chǎng)景下，重建容器未必能滿足需求，很可能導(dǎo)致雪崩，即重建過(guò)程中，整個(gè)應(yīng)用其他未升級(jí)的副本接受更多流量，OOM 掉，新啟動(dòng)的容器再瞬間被 OOM，所以重啟容器需要慎重?？焖贁U(kuò)容（HPA）或者快速提升高優(yōu)先級(jí)資源，抑制低優(yōu)先級(jí)容器資源的方式效果更明顯。

關(guān)注『阿里巴巴云原生』公眾號(hào)，回復(fù)關(guān)鍵詞“1010”，可獲取本文 PPT。

“ 阿里巴巴云原生微信公眾號(hào)（ID：Alicloudnative）關(guān)注微服務(wù)、Serverless、容器、Service Mesh等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開(kāi)發(fā)者的技術(shù)公眾號(hào)。”