集群/資源池/Node容量水位缺乏可視化，穩(wěn)定性難以保證
隨著云原生和K8S普及，若沒有很好的容量管理，我們就無法感知整個集群、整個資源池以及Node容量的水位變化，也無法得知是否有必要采購資源，無法察覺整體的資源風險。
容量變更根因難以追溯有時我們在做一些發(fā)版或迭代時，會發(fā)現(xiàn)原本充足的資源突然出現(xiàn)緊缺。此時，若要查探容量何時變化或追溯變化的根因，存在一定難度，也比較復雜。
【資料圖】
B站有很多活動和突發(fā)流量，但由于HPA的覆蓋率比較低，業(yè)務容量彈性往往難以保障。
2）降本增效大背景資源使用率低，迫切需要提高整體使用率資源碎片化較為嚴重，資源無法得到充分利用平臺缺乏統(tǒng)一的資源協(xié)調能力由于將物理資源分散到各個部門，如直播業(yè)務有獨立的直播物理資源池，電商有專屬物理資源，碎片化程度極高，所以平臺統(tǒng)一協(xié)調資源的能力難免存在欠缺。
資源占用大頭難以快速發(fā)現(xiàn)，治理困難降本增效遵循二八原則，即20%的業(yè)務可能占了80%的資源。我們需要快速如何找出20%的業(yè)務，并推動其進行治理，這部分業(yè)務得到治理后往往收益較大。
2、不同部門的關注點研發(fā)/部門：要有資源去做資源的擴容發(fā)布、藍綠發(fā)布和回滾。希望部門的成本不能過高，避免資源浪費。SRE：服務的穩(wěn)定性。在保證穩(wěn)定性的情況下，聚焦服務資源的使用率，以達到降本增效的目的。平臺：需要統(tǒng)籌資源buffer，控制資源的超賣率，保證底層容量的穩(wěn)定，從而實現(xiàn)降本增效的目標。成本部門：資源使用率，賬單、預算和成本。3、容量管理面臨的挑戰(zhàn)內部因素復雜，變動頻繁包括代碼變更、配置變更、壓測活動、多活切量、定時任務和緩存過期等，都可能導致容量模型發(fā)生改變。
外部場景多樣，難以預知B站活動比較多，運營也會進行不定時的推廣，一些熱門事件或話題都有可能導致容量的突增。
鏈路瓶頸點多，難以提前發(fā)現(xiàn)無論是東西向流量還是南北向流量，整個鏈路比較長，因此上游服務、下游服務和中間件都可能遇到瓶頸。
應急依賴人工，恢復時間長以上問題發(fā)生時，如果依靠人工應急，上游擴容可能會將下游直接打垮，容易引發(fā)二次故障。
4、容量管理的整體思路整個容量體系的設計，從下到上分為幾大部分，包括基礎容量、彈性資源、合池和配額管理。
首先是基礎容量，它包含平臺關注的集群容量、資源池容量、Node容量，以及應用畫像的相關數(shù)據(jù)。雖然我們將服務本身發(fā)版涉及到應用資源的容量視作基礎容量，同時業(yè)務也會關注。
在這些基礎容量之上，我們構建了一些彈性資源，包括VPA和HPA，還有我們的合池和配額管理。同時我們構建了整個容量可視化的一些頁面，用于幫助我們的業(yè)務和平臺更好地將自己的資源數(shù)據(jù)可視化，做一些資源的管理。
二、容量管理之降本增效1、降本增效通用手段2、具體方案介紹1）彈性伸縮-VPA(Vertical Pod Autoscaler)針對每一個服務，我們都有服務的軟限和硬限，這是K8S的基本概念。應用CPU Used即應用的CPU的真實使用量。B站所有的硬限和軟限都是通過我們的發(fā)布平臺caster去指定，它們可能是業(yè)務基于經驗設置的，設置的值不一定合理。隨著業(yè)務和服務越來越多，這種不合理性就會越發(fā)明顯，導致分配率非常高，但整體的使用率卻不高。
如何解決這個問題？
我們認為，研發(fā)部門無需關注軟限多少，只需關注需要多少資源。基于應用的真實CPU使用量和應用畫像，評估它的服務等級、是否多活等指標，以此判斷應動態(tài)分配多少軟限。這種方法能提高整個服務的部署密度，提高整體資源池的使用率。
進行大型活動時，如果分配率已經很高，可以應用VPA的策略，把非核心服務（如 L2/L3的后臺服務）用來降級，調低軟限，給核心服務騰讓資源。
我們通過VPA管理平臺下發(fā)VPA策略，使其經過VPA-API組件。這個組件是一個中間代理，主要實現(xiàn)對K8S集群中VPA Generator對象的增刪改查操作，負責匯總收集VPA相關的可觀測數(shù)據(jù)。
VPA Generator主要負責拆解先前下發(fā)的具有相同畫像的規(guī)則，如果下發(fā)一個L0等級的多活規(guī)則，它會拆解并創(chuàng)建很多對應VPA對象，最后通過VPA Recommender從監(jiān)控系統(tǒng)中采集一些對應的應用資源指標，計算推薦值即合適的request值，并通過VPA Updater組件調整Pod的資源。
發(fā)布服務時也可能涉及到資源改變，VPA Webhook會監(jiān)聽類似事件，再動態(tài)調整Pod值。
①策略管理包括VPA指標管理、模板管理和預估/對照組。
VPA的指標管理：基于不同的指標例如CPU的使用量max、P99等做一些調整。VPA的模板管理：基于我們的一些應用畫像，例如根據(jù)L0服務或L2服務等不同的服務畫像做一些不同的模板和管理。VPA的策略預估與對照：分清哪種指標或哪部分對我們更優(yōu)，因此我們會對不同的策略進行策略預估和對照，以便擇優(yōu)。②數(shù)據(jù)運營包括VPA的覆蓋大盤、VPA執(zhí)行記錄和VPA策略分析。
VPA覆蓋大盤：分析整個資源池的覆蓋率和執(zhí)行記錄，記錄服務軟限的調整幅度。VPA策略分析：調整后，通過可視化界面觀察是否還存在問題。③黑名單整個服務的使用量一般會在活動時劇增，或某個服務上線了新功能，進行壓測，都會導致整個容量數(shù)據(jù)變化。所以我們制作了黑名單機制，進行VPA策略避讓，保證在非預期的情況下，不會對這些服務進行相關調整。
④預警即使執(zhí)行了VPA，通常也有可能出現(xiàn)不符合預期的情況，所以我們制作了失敗率、覆蓋率和冗余度的策略預警。如果本次調整有多處不符合預期，提前預警將遞送給SRE和平臺方，然后進行治理和排障。
2）PaaS合池我們的漫畫業(yè)務、直播業(yè)務和OGV業(yè)務都是獨立的物理資源池，如下圖所示，番劇的CPU分配率很高，而漫畫跟直播的分配率相比較低。如果番劇需要資源去完成一些事情，漫畫和直播往往不能滿足，所以需要采購獨立的預算，或額外申請云上資源。
所以我們認為業(yè)務不應關注底層資源，從而完成了PaaS的合池。合池后，業(yè)務更關注邏輯的配額管理，即整個配額的使用率。如果使用率過高或出現(xiàn)問題，業(yè)務可以解決，底層資源則由平臺統(tǒng)一管控，進而平臺的統(tǒng)一管控能力提升。
合池具體如何落地？可分為以下幾步：
標準化治理基于歷史原因，不同的資源池使用不同策略，甚至配置、內核版本也各不相同，所以涉及到標準化的操作。首先，去除特殊約束，有些服務可能綁定了特殊的物理機發(fā)布。其次，不能配置nolimit相關的服務，因為合池完畢后如果某個服務壓力比較大，且配得不合理，往往會增加物理機的壓力，影響其他業(yè)務。同時，我們還進行了去cpuset化、統(tǒng)一操作系統(tǒng)內核和日志規(guī)范化的操作。
平臺支撐由于合池完畢后資源也不能無限使用，所以要基于合池后的不同組織進行邏輯配額管理，再整個大資源池覆蓋VPA。
老板的支持合池涉及到不同的部門，這一方面最重要的是需要老板的支持。自上而下進行的合池較依賴協(xié)同合作。
3）配額管理容量平臺提供了配額管理相關的策略下發(fā)能力，同時對接內部的CMDB業(yè)務樹?；诮M織業(yè)務的關系，可以設置不同的組織需要的資源數(shù)量。若使用超額，會聯(lián)動發(fā)布平臺，進而控制整體資源。如果資源不夠，可能就無法發(fā)布或擴容。
降本增效的收益
成本：通過這些手段，我們實現(xiàn)了22年H1在線業(yè)務PaaS物理機的0新增，同時整個S12的活動保障實現(xiàn)了0采購。平臺：統(tǒng)一管控能力極大提升同時，快速支撐大型活動方面，活動數(shù)量攀升了不止10倍。以往進行大型活動支撐時，直播資源不足往往需要采購預算，周期漫長。目前我們可以通過協(xié)調資源和統(tǒng)籌調度盡快交付資源，時間也從原來的一個半月縮短到現(xiàn)在的一個小時或兩個小時。PaaS的整體使用率獲得較大提升。業(yè)務：首先，對于小業(yè)務而言，由于本身資源池的資源較少，物理機不多，所以宕機對它的影響較大。合池后資源池的規(guī)模較大，服務相對分散，所以無論掛一臺機器還是兩臺機器，對小業(yè)務的影響會大大降低。第二，業(yè)務整體的容量需求得到快速滿足。資源緊張時，它也可以進行臨時的藍綠發(fā)布或者HPA超賣。三、容量管理之穩(wěn)定性1、在線業(yè)務的典型特征2、彈性伸縮-HPA(Horizontal Pod Autoscaler)HPA的設計理念與VPA相似，包括策略管理、彈性預檢、可觀測和預警。
策略管理因為HPA基于CPU使用率、內存使用率或QPS之類等指標進行管理，有些基于不同的應用畫像進行管理。例如，針對L0和L1的服務，它們的CPU使用率若達到30%就應該擴容，至于非多活的服務，達到擴容標準的最小值則可能稍高。
彈性預檢配備HPA后也并非萬無一失，因為HPA做彈性會涉及到下游及一些基礎的技術組件，比如數(shù)據(jù)庫會涉及到一些連接池，需要考慮它是否會滿，是否會導致其他風險等。所以我們進行一些彈性預檢的相關措施，包括臨近值預檢和容量風控等能力。
可觀測我們會觀測異常記錄和覆蓋率，比如對L0服務的覆蓋率如何，是否所有L0的服務都覆蓋了HPA，HPA被觸發(fā)時HPA的彈性質量如何等問題進行觀測。
預警我們設計了擴縮容的失敗預警和HPA失效的預警，如果觸發(fā)一些HPA擴容或縮容的事件，研發(fā)部門會收到相關時間通知，告知因服務壓力或流量導致HPA發(fā)生變化。
1）HPA可視化①HPA管控包括HPA 的批量開啟和禁用。保障大型活動時，往往會希望容量是穩(wěn)態(tài)的，再基于穩(wěn)態(tài)的容量進行壓測，此時需要先關閉HPA，在低峰谷區(qū)進行壓測。在資源不變的情況下，壓測穩(wěn)態(tài)能夠支撐的量的數(shù)值。后續(xù)可能分為幾輪壓測，最后一輪壓測會開啟全部HPA，觀察我們最終能支持的量，基于這些量預估容估。除此之外，還可能涉及HPA的增刪改查能力。
②可視化主要是HPA覆蓋率，要確定整個HPA在不同區(qū)域和不同等級覆蓋的應用數(shù)及覆蓋率，對比指標數(shù)據(jù)和彈性實例。
彈性實例對比表明當前服務的實例數(shù)量，并展示一個關鍵數(shù)據(jù)。這個數(shù)據(jù)幫助我們基于HPA配置策略，確定彈性實例的最終數(shù)量。彈性實例受限于HPA的最大值控制。如果純粹通過配置策略計算擴容的實例數(shù)，那么能夠通過HPA擴至15個。但如果無最大限制，可能會直接擴至20個。因此，借助可視化能直接看出HPA的設置是否合理，了解整個HPA變化的實際趨勢。
2）HPA并非可以無限擴容HPA受限于連接池或下游服務有限的承載能力，因此我們排查了整個過程需要使用消息隊列、Tidb、泰山KV、緩存以及中間件等相關組件。整體排查后，發(fā)現(xiàn)MySQL風險較大 ，因為大多數(shù)組件基本是集中式的代理，例如Tidb和泰山KV都是集中式的proxy部署，無連接池相關風險。緩存使用的redis和mc往往具有較大支持連接數(shù)，所以風險相對可控。MySQL 則不同，因此我們在彈性預檢這方面增加對MySQL和連接池的預檢。如果整個擴容導致MySql水位變高，就會進行相關提示。服務進行HPA擴容時，可能會導致下游的服務壓力、下游雪崩，導致一些底層的中間件出現(xiàn)一定的問題或壓力。
解決這個問題的整體思路：
一是HPA預檢，二是基于全鏈路的彈性，三是對超出預期的流量做一些組件的限流。
3）容量巡檢容量巡檢的作用在于，如果某些服務有風險，能夠實現(xiàn)相關數(shù)據(jù)可視化。
針對不同的場景和不同的角色，關注點也不同。
業(yè)務更關注整個業(yè)務維度，例如使用率如何、有無風險應用等應用維度，能盡快找到這些列表，進而快速完成治理。配額管理方面，則包括整個配額的使用率和配額可調度的實例數(shù)量，幫助快速判斷配額風險。
平臺方則更關注資源池的分配率，如可調度的實例數(shù)峰值、資源使用率、資源池是否為單節(jié)點，還會關注整個VPA的調整失敗率和冗余度?；谄脚_方的關注事項，我們制作了風險的巡檢大盤，用以確定哪些資源有風險、哪些資源比較空閑、哪些資源急需治理等情況。
4）超載保護即使有了這些保障，也無法保證萬無一失。因為流量突發(fā)很常見，如佩洛西事件等熱點事件導致B站的直播流量激增、超出預期，所以這方面需要依靠彈性資源。另一比較重要的手段則是依靠技術組件限流熔斷和降解。
限流目前限流主要包括分布式的全局限流和基于http、grpc、qps的限流，同時因為每個業(yè)務方基本上都會健全賬號，所以我們會對一些比較核心的業(yè)務做基于caller即調用方的限流，從而避免因某一個業(yè)務的流量突發(fā)而導致整個賬號體系出現(xiàn)問題。
另一方面，我們基于BBR進行動態(tài)限流，基于cpu使用率、成功qps和響應rt等限流，同時聯(lián)動移動端并進行流控。如果服務端超出承受極限，我們會給移動端下發(fā)策略，驅使移動端做流控的控制，避免用戶重試導致雪崩。
熔斷包括通過滑動窗口計算成功失敗率以及熔斷后需要進行的操作。
降級基于多活進行跨可能區(qū)的降級，業(yè)務對這個操作無感，這也是我們做多活的一個好處。而對于Node SSR相關的降級，支持降級至靜態(tài)頁，業(yè)務也無感，但耗時相對長些。至于數(shù)據(jù)類的降級，假若AI方面的算法服務出了問題，我們可以進行兜底數(shù)據(jù)展示，但用戶方的內容質量就有所下降。弱依賴降級時，部分服務會直接降級，不展示非核心數(shù)據(jù)。
四、容量管理之可視化運營1、基礎容量我們更關注集群、資源池、Node和應用維度的數(shù)據(jù)，所以制作一些可視化圖表，以便更快查看整個集群資源池和應用在這段時間內的變化趨勢。
以資源池和Node為例，由于要控制超賣，所以要控制資源池和Node的容量水位和超賣率（Node也有部分熱點）。
有些會觸發(fā)二次調度，把上面的部分服務調用到非熱點的服務中。應用則包括應用的資源使用量、使用率、實例數(shù)和單實例容器數(shù)，它的容器包括多少容器數(shù)，例如有一個Pod，它可能包含一個主容器和相關伴生容器，伴生有可能導致容量變化。我們基于這些數(shù)據(jù)制作趨勢圖，并在監(jiān)控上保存應用的相關容量數(shù)據(jù)。與監(jiān)控相比，因為數(shù)據(jù)點更加分散，所以保存期限更長，目前已保存了超過兩年的容量數(shù)據(jù)。
2、業(yè)務組織容量業(yè)務痛點
在進行降本增效時，如何快速找到資源占用的大頭并優(yōu)先治理；哪些業(yè)務的實用率較低使用不合理；是哪個業(yè)務擴容導致成本突增容量治理的效果如何，哪些業(yè)務的治理不符合預期解決方案
根據(jù)以上痛點，我們設計了組織業(yè)務容量，基于內部的CMDB即組織業(yè)務數(shù)，通過聚合應用指標，從下往上逐漸遞歸，算出整個組織和業(yè)務的容量，呈現(xiàn)歷史容量的變化趨勢。例如，總容量是1萬盒，1萬盒屬于整個直播業(yè)務，而直播的分支包含直播的房間、直播營收相關業(yè)務。
列出每一項所占的資源，就能清晰地感知哪些業(yè)務是資源占比的大頭和占比總量。通過圖片上的紅線和紅點，就能分析它的使用量與使用合理性。下圖右方則呈現(xiàn)了整個容量的變化趨勢，這樣就能快速定位不合理的板塊。同時，我們支持數(shù)據(jù)的一鍵下鉆，作用同上。
3、容量事件資源治理時，往往會遇到資源變少變空或不能發(fā)版的問題。以往查詢這些問題根源，我們可能要翻遍各個平臺。例如，查看是否有人在發(fā)布平臺進行擴容或縮容操作，部分服務是否因壓力過大觸發(fā)HPA，或是否有人在管理平臺中臨時添加了機器導致容量變大。
由于平臺數(shù)量多，業(yè)務SRE排查相當困難，所以我們做了容量事件相關的平臺，以消費包括發(fā)布平臺、HPA以及Node管理等整個變更平臺的變更事件。通過變更事件，把數(shù)據(jù)消費到容量事件平臺上，統(tǒng)籌觀察這段時間業(yè)務的容量變更，因此容量事件是我們快速定位容量變化根因的重要途徑。這樣做的收益很顯著，以往容量發(fā)生變化，業(yè)務必須聯(lián)系SRE和平臺。而現(xiàn)在無需這樣操作，就能快速感知容量變化的根因，處理效率提升。
4、容量周報容量周報分為部門周報和內部周報，業(yè)務部門更關注整體資源的用量以及資源使用率的變化。觀察這些數(shù)據(jù)能更好地感知容量效果。除了降本增效以外，業(yè)務還關注穩(wěn)定性，希望得知具體的風險應用有哪些，以及一周內哪些應用有怎樣的容量變化。
對于內部來說，SRE和平臺比較關注哪些部門的自營資源占量較大而使用率較低，這些部門對我們來說往往是能用于降本的組織，我們需要提前與他們溝通，所以就需要內部周報幫助完成。同時我們也列出了部門資源使用率的排名，排名越靠前說明治理得越好，反之亦然。
張鶴
嗶哩嗶哩
基礎架構部資深SRE
2020年加入B站，先后負責社區(qū)/直播/OGV/推廣搜相關的SRE工作，深度參與多活，活動保障，混沌工程，容量治理相關的建設，主導容量管理平臺，混沌平臺的架構設計和落地，負責B站S賽、跨年晚會、拜年祭等相關活動的基礎架構保障工作，目前主要負責推廣搜業(yè)務的穩(wěn)定性建設。
關鍵詞：
營業(yè)執(zhí)照公示信息
