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