一、彈性伸縮技術實踐
1.全網容器化後一線研發的使用問題
全網容器化後一線研發會面臨一系列使用問題，包括時機、容量、效率和成本問題，彈性伸縮是雲原生容器化後的必然技術選擇。
2.使用原生彈性HPA遇到的問題
當時第一時間考慮用原生HPA元件，但在實際調研和小規模使用的時候發現了很多問題。一方面是內建的問題，如原生不支持自訂指標和定時擴縮容，使用率計算基於resources.requests，使用單個Goroutine執行。更大的痛點在業務場景上，微服務線上例項拉出狀態，特殊業務Job任務例項不能中斷，要考慮下遊DB層可用性。
3.基於業務例項實際水位、有效負載的彈效能力
我們基於業務例項實際水位、有效負載構建彈效能力。
高低雙閾值控制，像一些有浮動的業務，可以盡量把底層的穩定性去做有效的約束；
最大可用原則，擴容用Ceil向上取整，縮容使用Floor向下取整；
數據降噪，去除例項狀態不ready的，去除強業務關系的例項計算，套用啟動毛刺問題緩解，metrics空值、獲取不到值；
效能增強，按業務namespace監聽，實作並行度控制。
4.水位閾值彈性和定時彈性的融合實作
這裏同時做了水位閾值彈性和定時彈性的融合，保證單個的套用能夠同時使用閾值和定時彈性。基本原則是擴容時大者取大，縮容時不能低於定時副本數。
5.業務使用彈性後的生產效果
業務使用彈性後產生了一定的效果，如圖是高低閾值和定時的區間。這裏解決了一些問題：
程式碼預熱，在高峰前準備就緒；
周期性波動型套用變更明顯減少；
套用冗余減少，業務「初見原型」；
突發流量應對，穩定性提升；
告警、套用狀態可控性。
最終彈性接入90%以上，擴縮容訊息觸達率100%，業務可用算力增加了 30%以上。
6.混合雲模式下的 ClusterAutoScale
集群可用資源變多，不等於整體開支降低，因此我們考慮去做混合雲模式下的ClusterAutoScale。這裏有一些關註點，包括映像即服務、CloudProvider 適配、節點初始化和節點回收。
右圖是基本流程，有兩個觸發策略，一是基於不可排程事件，二是基於資源池水位閾值。這裏我們也解決了一些問題，包括 CloudProvider 對接私有雲資源API，Pod網段分配域路由宣告，私有雲可用容量評估及資源打散，以及資源灰度回收邏輯。
7.註意事項
在實際業務時生產使用的時候，有很多關註點，包括業務池的容量、套用維度的例項波動率標準、存活探測和就緒探測的介面區別、指標閾值和彈性規則的合理性巡檢、不做過多filter、不強依賴其他系統平台。
二、中介軟體容器化及混部填谷
1.業務獨立池水位與混部預期
針對業務特性，將redis和flink資源池進行融合，達到分時復用的效果。之前的形態會帶來很多問題：
每種業務獨占一個資源池或集群，產生大量資源碎片，造成成本浪費；
多個集群多個對外API，數據需要多次聚合計算；
各業務池伺服器規格不一致，運維管理復雜。
2.混部的總體思路
混部裏面這裏做了一些思考，考慮了套用分級、資源需求、潮汐分布等等。將這些因子抽象歸納，分為套用分級、混部排程、資源QOS三層。我們也確定了幾個總體方向，包括服務資源保障的策略實作和資源分配決策的演算法實作。
在服務資源保障上，主要是對套用分級打標。我們把所有的業務做了S1-S4的分級，並落到了CMDB裏，最終落到K8S的優先級標簽裏面。第二部份是資源池化，優先去考慮以底層的業務為重保，把一些優先級較低的套用分別打散到各個資源池。
在資源分配決策上， 第一部份是Request推薦。主要基於VPA Histogram計算百分位演算法，透過獲取7x24小時周期的套用資源量，根據P95百分位數據，再乘以水位系數放大後得到最終推薦值，並結合彈性、coolhealth狀態機最佳化毛刺問題。
第二部份是實際負載排程，主要基於集群理想值權重演算法和BinPacking裝箱打分演算法。過濾掉高水位節點，避免單node資源打爆；水位偏離度縮小，pod排程盡可能靠近理想水位；歷史閾值計算套用負載，對節點未來水位預測；兼顧單node最大pod數限制。
第三部份是資源打散，透過問題推導，完全打散是不可能的，我們希望盡可能打散，在私有雲IDC加入MDU策略。常用的策略有宿主機打散、可用區打散和MDU打散。
3.成效和問題
最終資源使用率有明顯提高，成本賬單同比持續降低。這裏也帶來了一個無法回避的問題：物理機宕機。爆炸半徑增大，穩定性怎麽保障，是我們基礎設施的同學都需要去思考的問題。二是對根因下鉆和故障定位帶來挑戰，如何觀測和評估影響。
三、K8S觀測與穩定性
1.基於Prometheus的容器監控平台
基於Prometheus構建了監控體系，核心元件包括Thanos + Prometheus 持久化儲存、Vertex Exporter 指標采集資料來源、SentryD 配置管理、CheckD 告警檢測和Alerts 告警系統。
2.監控高級模式
我們自研了vertex采集工具，實作了快速生成metrics指標的能力，支持使用者自訂指標名稱，方便按業務、按分組區分。和exporter算力共享，每個例項 limit 2C/4G就可滿足一個物理機的采集任務。
3.event 事件流持久化
實作了事件收集器，K8S全資源型別listwatch收集，同時把所有的event全量打印，針對特別的一些探針做了Response資訊返回的打印。
4.logs 日誌平台
把系統日誌和業務日誌等透過一些消費和采集的收集器，推播到kafka，最終聚合成一個平台。
5.trace鏈路
我們透過traceid查詢，tags過濾進行數據檢索分析；鏈路拓撲過濾，只看有錯誤的鏈路；采樣鏈路搜尋，鏈路分析。
6.K8S穩定性關註的指標
這裏把K8S穩定性關註的指標分為五類，原生元件可用性、集群容量水位、集群資源負載、業務異常例項和雲平台可用性。
7.穩定性大盤
雲原生系統內維護的元件系統較多，一個原子管理單元發生問題後可能會影響多個上遊鏈路系統。快速論證回答元件域當前是否正常，對於故障分析、問題定位有重要意義。
四、未來的展望規劃
未來規劃主要分為四部份，一是在離線的深度混部與調優，下一階段還要持續推進哈啰內部雲化中介軟體的混部行程，聚焦大算力套用的資源編排和成本最佳化。
二是數據儲存容器化，資料庫、NoSQL的容器化工作，基於容器Cgroup隔離、以及類K8S資源編排模型的落地。目前哈啰內部已有部份業務開始生產化，還在持續建設中。
三是Serverless業務場景模式探索，中後台的演算法模型、數據任務job場景有一定的實踐，業務大前端BFF層、無程式碼工程建設上在持續探索。
四是基於AIOPS&可觀測性的智慧故障預測，基於時序預測模型能力，探索metrics異常指標提前發現，收斂告警系統誤報、漏報問題，提升故障發現、故障定位能力。
作者丨羅濤
來源丨公眾號：哈啰技術（ID：gh_426073316492）
dbaplus社群歡迎廣大技術人員投稿，投稿信箱： [email protected]
