12 一、背景介紹 5二、云原生成本管理模型 62.1資源利用率現狀 72.2云原生成本管理模型 122.2.1成本洞察 122.2.2成本優化 132.2.3成本運營 13三、云原生資源管理能力成熟度模型 153.1云原生成熟度模型(CNMM)等級一 153.1.1應用架構&服務治理 153.1.2應用彈性 153.1.3編排&調度 153.1.4集群彈性 163.2云原生成熟度模型(CNMM)等級二 163.2.1應用架構&服務治理 163.2.2應用彈性 163.2.3編排&調度 163.2.4集群彈性 163.3云原生成熟度模型(CNMM)等級三 163.3.1應用架構&服務治理 163.3.2應用彈性 173.3.3編排&調度 173.3.4集群彈性 173.4云原生成熟度模型(CNMM)等級四 173.4.1應用架構&服務治理 173.4.2應用彈性 173.4.3編排&調度 173.4.4集群彈性 18四、最佳實踐 194.1成本洞察 194.1.1成本采集及資源追蹤 194.1.2資源使用可視化 194.1.3費用可視化 194.1.4成本分配 204.1.5賬單管理 224.2成本優化 234.2.1設置合理的資源請求和限制 2334.2.2動態調度 264.2.3多維度彈性 284.2.4在離線混部 324.2.4GPU共享 354.2.5優化矩陣 374.3成本運營 384.3.1建立成本優化團隊 394.3.2推動成本意識文化 394.3.3數據驅動成本優化 394.3.4在流程中考慮成本 404.3.5量化成本優化交付的業務價值 40五、總結 42六、企業客戶降本案例 446.1作業幫 446.1.1當前作業幫降本增效存在的問題 446.1.2解決方案 446.1.3實踐價值 456.2QQ音樂 456.2.1QQ音樂降本增效核心痛點 456.2.2優化方案 466.2.3應用效果 466.2.4展望未來 466.3B站 476.3.1B站降本增效核心痛點 476.3.2基本方案 476.3.3典型場景 476.4更美 476.4.1云原生是什么 486.4.2云原生與更美降本增效目標的關系 486.4.3使用云原生技術降低成本最佳實踐 486.5銷售易 506.5.1云原生是什么 506.5.2云原生與銷售易降本增效目標的關系 506.5.3使用云原生技術降低成本最佳實踐 506.5.4展望未來 516.6云集 516.6.1云原生是什么 526.6.2云原生與云集增效目標的關系 526.6.3使用云原生技術降低成本最佳實踐 526.6.4展望未來 544云原生使組織能夠在現代云環境(例如公共云、私有云和混合云)中構建和運行可擴展的作出反應。計費和按使用付費模型等功能，云原生計算可幫助組織擺應用程序的一個巧妙之處在于，云原生應用程序使開發人員可以更并制降低開發過程的復雜性:開發人員可以將更多時間花在項目的細節上，而不是構建通用框模塊化設計：模塊化設計使外觀和功能的標準化更容易。擁有多個應用程序或服務的公司具有巨大的業務影響潛力——能夠快速有效地將想法轉化G抓住云原生變得特別重要,你準備好了以下了沒:于功能的結構，圍繞特定的服務或能力組的架構。云原生意味著使用微服務和反應速度更快的架構類型。上云原生開發的步伐。業務應該能夠以與技術人員相同的速度足夠大多數云原生關鍵基礎設施都是開源的，例如Kubernetes，你知道如何參與開源社區以了eithChanCNCF總監兼Linux基金會亞太區策略規劃總監、騰訊云TVP5增長的重要引擎，云計算從部分企業數字化轉型的載體，轉變為了構，云原生具備更靈活的資源管理、更敏捷的應用迭代、更高效的模業務保障能力，云原生帶動技術架構、應用效能、云化效益的全方位提深入應用，金融、政府、制造、電信、醫療等行業的云原生用戶占比較2020變，云原生技術給企業帶來的價值中，提升資源利用率節約成本連續兩簡化運維系統以及便于現有系統的功能擴展。云原生已成為企業基于度不斷加深，云上支出浪費嚴重，云原生平臺自身的成本治理成為企業按需是云原生的資源利用優勢，但如果資源配置策略設置不合理可能會導云、云數智融合等模式在幫助提升工作效率、實現應用靈活部署的同時也的新挑戰。因此，企業在應用云原生架構之后，需要考慮如何管理、優化生成位、路徑難選擇、成效難持續三大挑戰，資源成本優化是云原生降本的關實其持久性。資源成本優化從基于賬單優化的成本可視、基于資源優化式優化的成本運營從三方面幫助降低云原生平臺成本。》將基于中國信息通信研究院與騰訊云對行業發展趨勢和企業客化徑，結合行業優秀案例，幫助企業改善用云成本充分發揮云原生的效能和6成本管理模型一種思想，是技術、企業管理方法的集合，云原生追求、混合云等動態環境中構建和運行規模化應用的能力，追求的是業能力。Kubernetes云原生技術棧的核心，是眾多云原生項目的粘合劑。Kubernetes遵循聲明管控的對象都抽象成標準API，并通過多種控制器完成云原生平臺的高度自如云用戶可以通過定義Pod對象，并指定需要運行的容器鏡像，以及容器所需的CPU存等計算資源。該對象被提交至Kubernetes以后，Kubernetes會依據用戶請求運行并按需求確保該應用進程的資源配額。量，并通過自動化橫向或縱向擴縮容能力，及時調整應用的副本數量以及時回收空閑資源，提升資源使用率。生技術棧的核心目標之一，資源利用率的提升意味著以更少的計算用實例，極大的降低云用戶的資源開銷，也契合國家節能減排的政策號72.1資源利用率現狀節省成本9%率%系統上的功能擴展02%從2019年的72%增長到了82%，越來越多的企業在云上使用基礎設施資源、通過s8最主要原因。在Kubernetes集群中，資源利用率體現為運行的所有Pod消耗的資源與資源總量的比率，據麥肯錫早期報告，全球服務器資源利用率不到6%，資源利用騰訊云對1000多家云客戶進行了資源利用情況分析，抽樣超過一萬42%的節點點資源利用率低于10%資源利用率低于20%節點資源利用率在20%-30%9極大的浪費。KubernetesPod的資源需求(ResourceRequest)字段用于管理容器對CPU和內存資源需求造成下容器的資源預留(Request)和實際使用量(CPU_Usage)關系圖：資源預留遠大于實際使用值所對應的資源不能被其他負載使用，因此Request設置過大勢必會造成較資源利用率較低的另一主因。例如公交系統通常在白天負載增加，夜晚服務的特性和業務目的可分為在線業務和離線業務兩類：在線業務通求較高，必須優先調度和運行；而離線的計算型業務通常對運行以在在線業務負載波谷時段運行。此外，有些業務屬于計算密集在進而提升資源利用率。將需求不同資源的作業有效的部署在相同節源，提升總體資源利用率。Kubernetes個開放式平臺，鼓勵資源共享，但同時缺少有效的成本觀測和分配機以被動態調度在同一個計算節點上，簡單將底層云資源與應用一一映傳統手段已經失效。如何發現和觀測成本管理上的問題，比如針對資源閑置、應用閑置、以及前述資源利用率衡部分客戶做完成本優化項目后，短期內確實節省了很多成本。但是隨著時間推移，業務的統設計時，缺乏對成本的考量，這可能使業務上線后的資源2.2云原生成本管理模型：源追蹤、成本可視化、成本分配和賬單管理成本優化：提供可靠、便利、智能的優化方案成本運營：從組織、文化、流程等方面建設成本運營體系2.2.1成本洞察集及資源追蹤云環境下的資源使用和成本支出是比較復雜的，團隊或組織需要通過一定的工具或方案對各種產品進行定義、定價、計費及統計，并對各類資源的使用率、使用量等指標進行持續追蹤，能幫助團隊盡可能多地搜集到云成本情況，為后邊成本可視化以及成本分配提供數據基礎。視化和成本分配Kubernetes的成本分配比傳統的云環境面臨更多挑戰，團隊需要定義一致的標簽和命名空間來改善分配，對于任何組織、部門及職能團隊，基于多維度(如云產品、環境、業務線)的資源和成本的可視化分析，能夠幫助團隊有效地建立起相應的問責機制，并根據獲取到的實時數據快速制定優化方案及措施。賬單管理云賬單的繁冗性和復雜性給用戶帶來非常大的不便，團隊或組織需要對賬單進行統一高效的管理，一是根據實際的業務需求，將賬單按組織、部門、項目業務維度，年、月周期維度等進行詳細化的拆分。二是將各類賬單進行統一分析，包括過去一段時間的使用情況、未來使用趨勢分析、各部門成本使用情況等方面，并給出合理的規劃及更改建議。三是將分析后賬單情況按業務部門、周期、自定義等維度定期推送給團隊，方便團隊及時得到相應的賬單。2.2.2成本優化提供可靠、便利、智能的優化方案基于成本可視化和成本分配等手段，有了數據作為度量依據，團隊能夠圍繞其業務目標及業務場景制定對應的成本優化目標。針對云原生場景，云上資源成本優化不僅僅是對云資源規格、數量的調整，也包含了對業務的架構優化、以及通過彈性能力和資源混部等手段提升資源利用率。此階段的優化方案包括：正確評估應用容量，設置合適的資源請求通過動態調度解決資源碎片的問題，提高裝箱率回收業務波谷時的冗余，通過彈性和混部做到按需使用對于固定資源池，對負載峰值在不同時段的在線應用、在離線應用進行混部，做到分時復用針對GPU資源，實現資源的池化和共享2.2.3成本運營從流程、組織、文化等方面建設成本運營體系云上資源優化并非是通過一系列標準動作后得出的一個終態恒定值。如同追求系統穩定性冗余大量資源，追求極致成本而犧牲業務穩定性同樣不可取。業務本身是變化的，適合的系統架構及管理方式同樣如此，我們鼓勵從組織、文化、流程等方面建設成本運營體系，根據目標持續不斷調整和優化。此階段的優化方案包括：建立成本優化團隊推動成本優化意識數據驅動成本優化在流程中考察成本量化成本優化交付的業務價值云原生降本白皮書提出了云原生成熟度模型(CNMM,CloudNativeMaturityModel)，主要聚焦云原生領域的資源使用、管理、優化。它描述了云原生的演進過程，涵蓋一個成熟的云原生采納方所應具備的重要功能。從應用架構&服務治理、應用彈性、編排&調度、集群彈性四個維度分析云原生使用的成熟度，并分成了四個等級，具體如下圖所示：圖9云原生成熟度模型CNMM3.1云原生成熟度模型(CNMM)等級一服務治理這個時候是云原生采納的早期階段，業務還是采用傳統的單體架構的形式部署，在Kubernetes集群里面普遍采用富容器，但違反了Kubernetes容器單進程的設計初衷，不利于容器的健康檢查和彈性。業務架構耦合嚴重，研發或發布一次，可能需要數周甚至數月的周期，回滾復雜，幾乎沒有灰度的能力。幾乎沒有彈性的能力和配置，業務在開發之前，會提前預留大量的資源，預定資源固定且不會隨業務負載峰谷變化而動態調整。在這個階段里，業務在申請資源和調度的時候，沒有彈性的能力。為了讓自己的業務在波峰的時候也能平穩運行，普遍都會超配資源。業務之間也沒有優先級的劃分，當資源不足，業務之間有影響時，沒有合理的手段有效的避免業務競爭。幾乎沒有集群范圍的彈性，還是以傳統的IDC機房整機批量采購的形式，提前先購買大規模的集群，然后各個業務團隊各自使用，沒有實時靈活的集群范圍的彈性功能，集群的擴縮都需要走專門的審批流程。業務之間為了降低影響性，通常都是按照傳統IDC的運行模式，單獨節點運行單獨的3.2云原生成熟度模型(CNMM)等級二服務治理等級2的時候富容器場景少了很多，業務擁抱容器化，不斷的將業務模塊拆分，打造微服務的架構，集群內部服務之間也有了跟多的調用關系。但缺少有效的服務的管理機制以及流量的治理方式。開始做一些手工的彈性，例如：會人工的檢測工作負載的實際負載情況，然后手工調整工作負載的副本數。會利用一些工具：例如定時調整副本數，或者使用Kubernetes原生的HPA能力，手工配置參數和副本數范圍。但這些數值的設置和定義都需要大量的經驗和手工，且有時候配置無法生效。這時候在編排調度層面，會有了更多的經驗為工作負載設置更合適的數值，會根據不同的業務等級為不同的工作負載配置不同比例的Request/Limit數值，以達到不同的QoS的等級，這樣在資源調度和資源搶占時，會保證高優先級的業務的資源能夠供給充沛，低優先級的業務在面對高優先級業務的時候，資源使用被壓制。此時已經開始使用靈活的集群擴縮的機制，但還是更多的偏手工的執行，手工為集群添加、移出節點。業務之間也會共享資源池，而不是單節點運行單獨業務，資源的復用能力以及利用率有一定的提升。3.3云原生成熟度模型(CNMM)等級三服務治理此時在應用架構方面已經基本上Kubernetes化了，將Kubernetes的相關能力完全應用到了實際的業務開發、架構、部署上。服務也開始使用優雅啟動、優雅停機等高階的能力，避免長連接的服務在工作負載縮容的時候流量中斷，整個架構和服務治理已經趨近成熟。開始使用更多的彈性工具：不僅僅是基于HPA原生支持的指標，也開始對接業務自己定義的一些指標做到應用的彈性擴縮容。但此時還是需要手工定義工作負載彈性擴縮容時的副本數范圍，范圍如果沒有及時調整，就有可能造成資源浪費，或者更嚴重的是：無力處理波峰流量。資源配置有了很多經驗，不僅僅是依據CPU和內存的用量、利用率來為工作負載配置，也會結合實際的業務指標調整工作負載對CPU和內存的請求量。設置更合理的資源Request/Limit比例，進一步保證高優業務的平穩運行。也會利用一些調度工具優化集群調度能力，例如：基于節點負載情況調度作業，可以為節點調度更多作業的同事，也能保障高優業務的資源供給。充分利用集群的ClusterAutoscaler能力自動擴縮集群規模，自動添加、減少集群的節點數，節點幾乎不需要人工接入參與運維。3.4云原生成熟度模型(CNMM)等級四服務治理單容器單進程，不會有任何多余的容器，業務的無狀態服務比例上升，可以充分享受到不可變基礎設施帶來的優勢。將服務網格引入集群，服務發現和治理得到了系統化、整體化的統籌，跨集群的服務和流量管理都得到了有效的解決方案。基于預測的彈性擴縮容，解決Kubernetes原生彈性滯后的問題：充數據上報、到監控采集、到組件識別和計算、到觸發彈性、到最終運行起來一個新的副本，流程、耗時較長，基于預測的彈性能有效降低波峰流量的及時彈性。全自動化的彈性能力，用戶無需再手工配置任何彈性規則的指標，做到全自動化的彈性效果，進一步實現資源的“按需付費”。基于應用組的彈性，解決應用之間互相依賴的問題，做到整體的彈性，防止應用依賴導基于預測的能力調整資源的配置，用戶無需再手工配置任何資源。做到完全自動化的配置能力，實現資源真正的“按需付費”。業務更多維度的分級和保證的能力，保證高優業務的平穩運行的同時，使用更少資源運行更多業務，業務之間的沖突和干擾都擁有對應的解決方案。集群整體做到完全的Serverless化，讓業務和運維團隊幾乎感受不到集群和節點的存在。波峰來，業務自動擴容，波峰走，業務自動縮容，無需在思考和處理集群規模周邊相關資源的自動擴縮容：例如對日志、監控等系統的依賴，隨著集群和業務負載的提升，對應的日志、監控等系統都能做到完全的自動擴縮容，讓用戶無感，把重心完全聚焦在自己的業務之上。、成本優化、成本運營三個維度展開，結合企業實際落地情況提供4.1成本洞察的成本維度的數據。成本洞察的重點在于從成本的角度觀察集群的成4.1.1成本采集及資源追蹤跟對企業私有云進行資源的定義、定價、計費、統計，然后對私有云成本使用情況賬單進行采集對企業資源使用情況進行持續追蹤，包括資源使用量、資源使用方式、資源利用率等。4.1.2資源使用可視化Grafana成為了云原生領域監控的標準。成本的管理實際上就是資源的使用管理，展示業務的資源分配、消耗，資源使用效率分析Top10資源消耗的業務，分析Top10資源利用率低的業務展示資源消耗的走勢圖展示不同維度的資源使用情況，包含Kubernetes概念的維度：例如命名空間、工作負4.1.3費用可視化后，對接云資源計費系統獲取資源單價，即可計算出云資源的實際使化，成本視角的可視化是企業運營更關注的視角，提升資源利用率手段。分析集群的下月預估成本，分析每個資源對象的下月預估成本查看集群成本曲線查看業務增長曲線和成本曲線對比，評估成本增長是否過快節省，為執行動作做成本角度的建議算資源維度以及用戶自定義的業務維度保存歷史重要數據，定期生成報告，回顧和對比Kubernetes的成本分配比傳統的云環境面臨更多挑戰，團隊需要定義一致的標簽和命名空間來改善分配，精確分配資源成本是在Kubernetes環境中創建成本可見性和實現高效成本利用的首要步驟。下文就解決云原生架構下的費用分攤問題給出一些建議： 類型IT隊來支付云費用，公共的IT團隊再將成本分配給業務部門或分配就變得非常困難。所以，成本分配的第一步是梳理并明確共享的資源S配置就要建立可持續的公平分配的方法。基于云原生架構，用戶可標簽模型是成本分配最為關鍵配標簽設計原則的成本。對于管理著來說，想知道到底是什么業務驅動了成本的上漲，即時發現不合理的商業還有多層級的CAM(CloudAccessManagement，騰訊云訪問管理)賬戶結構、項目等功能幫本。資源標簽是云用戶分類云資源的有效手段，不同云用戶對標簽的使用語法限制、字符集和長度等合法性進行校驗。這種極大的靈活性的疑問，到底該如何定義標簽呢？鍵是：盡早且始終如一的執行某種分配策略。例如在月初創標簽，那有一個月的成本沒有分配。標簽設置的策略也應該盡早進的執行下去，否則每次標簽的改動實際上都會導致歷史數據的丟原則的標公司有很多沒有被標記的存量業務，但不必擔心，梳理業務標簽為時未的擴隊必擇正確數量的標簽隊應用太多標簽。要求過多的標簽只會導致對標準的抵觸，從而導對所需的核心元數據要求標簽。與其根據需要定義所有標簽，不如定義可使prod值，而另一個團隊使用“production”，這些標簽的分組方式會有所不準化注意的是：您可能開始使用“R&D”標記資源，但后來意識到某些服務一個成本中心/業務標簽，它清楚地定義了資源成本應在組織的位置。是屬于固定的、集的似costallocationcostcentercostallocationbusiness簽標識資源屬于哪個服務，允許組織區分團隊正在運行的服務之間的成本。是訂單服務的成business_type=logistics的標簽幫助識別負責資源的個人/團隊。例如：可以設置類似resourceownerxiaomingresource_owner=wechat的標簽insdfkjdkd了方便資源的統計，可以給這些云資源加上一個cloudresourcecomputer計算資源幫助確定開發、測試和生產之間的成本差異的環境標簽。例如：可以設置類似ironmentdevelopmentenvironmentproduction用于標識資源所屬的服務層部分的層標簽(例如，前端、網絡、后端)。例如：可以設置類servicelayerfrontendservice_layer=backend的標簽云賬單是企業獲得成本支出的第一手資料，賬單的可讀性往往影響到企業對成本開況，并能及時給到部門或組織反饋。因此對于企業的云賬單體系要提高管理水平，幫助企業提高賬單分析的效率，使賬單更好地服務于企業，以下幾個方面是賬單管理的落實步對企業賬單按云產品維度進行賬單的拆分。對企業賬單按組織、部門、項目等業務維度進行賬單的拆分。對企業賬單按包年、包月等周期維度進行賬單的拆分。對企業賬單按自定義維度進行賬單拆分。提供業務維度包括組織、部門、項目等方面的賬單推送。度包括年度、季度、月度等方面的賬單推送。4.2成本優化有了完整的成本洞察能力后，即可查看企業整體成本效率。企業進而能夠圍繞其業務目標及業務場景制定對應的優化方案，本小節將具體介紹成本優化的最佳實踐。我們再回顧下前文分析的資源浪費的常見現象：應用設置了過大的資源配額應用波峰波谷明顯，波谷時資源浪費嚴重存在不同類型的業務，對資源要求不同主要資源優化方向包括：正確評估應用容量，設置合適的資源請求通過動態調度解決資源碎片的問題，提高裝箱率回收業務波谷時的冗余，通過彈性做到按需使用對應用進行混部，做到分時復用針對GPU資源，實現資源的池化和共享4.2.1設置合理的資源請求和限制有四個業務部門使用同一個集群，你的責任是保證業務穩定資源的按需使用。為了有效提升集群整體的資源利用率，這時就理想情況下，業務應該根據實際情況，設置合理的ResourceRequest和Limit。Request的占位，表示容器至少可以獲得的資源；Limit用于對資源的限制，表示的資源。這樣的設置有利于容器的健康運行，資源的充分使用。此外，當多業務部署到同一個共享集群以后，每個團隊都傾向將自己容器的ResourceRequestesttUMemory(MiB)EResourceQuotaLimitRanges使用資源配額(ResourceQuota)劃分資源業務，為了實現業務間的隔離和資源的限制，你可以利用命Kubernetes里面的一個隔離分區，一個集群里面通常包含多個命名空設置命名空間資源的使用配額。例如Kubernetes用戶可將不同的業務部署達到預分配和限制的效果。資源配額主要作用于如下方面，詳細信息可查計算資源存儲資源對象數量配不同的命名空間，通過設置每個命名空間資源的資源配額以配的目的設置一個命名空間的資源使用數量的上限以提高集群的穩定性，防止一個命名空間對資源KubernetesPod選屬性，用戶可以不為Pod設置資源RequestLimit設置得很大。集群管理員可以為不同的業務設置不同資源使用業務對資源的過度侵占。LimitRange名空間下的單個容器，可以防止用戶在命名空間內創建對資源計算資源：對所有容器設置CPU和內存使用量的范圍存儲資源：對所有PVC能申請的存儲空間的范圍Request和Limit之間比例默認的Request/Limit，如果容器未指定自己的內存請求和限認的內存請求和限制以防用戶遺漏，也可以避免QoS驅逐重要的Pod將不同特征的業務部署在不同的命名空間中，且為不同命名空間設置不同的LimitRange資源利用率限，保證容器正常運行的情況下，限制其請求過多資源能Request推薦配額一個源搶大小空間級別，粒度較粗。U60%，即集群中所有容器的CPURequest之和占集群CPU總量的60%(CPU申請體資源的60%，而實際使用量僅占不到0.8%。Request和Usage之間存在較Request及時調整。業務部門戶的Request核。數，避免因為流量突發導致的業務不穩定性。配合上彈性集群能力 (1906-400)/1906=79%。4.2.2動態調度性么用，會造成較大的資源浪費。如果能為此類節點設置一個標記，標明運行。Kubernetes的調度器會將這個負載調度到CPU密集型的節點上，這種尋找親和性使用場景騰訊云的云虛擬機(CVM節點)有CPU密集型，也有內存密集型。如果某些業務對CPU的存，此時使用普通的CVM機器，勢必會對內存造成較大浪費。此時可以在集群CPU密集型的CVM，并且把這些對CPU有較高需求的Pod調度到這些CVM上，這樣可以提升CVM資源的整體利用率。同理，還可以在集群中管理異構節點(比如GPUGPU資源的工作負載中指定需要GPU資源的量，調度機制則會幫助你尋找合動態調度(負載感知)LeastRequestedPriority原生調度策略的資源分配是靜態的，Request不能代s差。如果調度器可以基于節點的實際資源利用率進行調度，將一定程度上KE調度器的使用場景動態調度器會統計過去一段時間調度到節點的Pod數目，避免往同一節點上調度過多的動態調度器支持設置節點負載閾值，在調度階段過濾掉超過閾值的節點維人員心中的“痛點”。一方面，為了降低成本，資源利用率當然是越高動驅4.2.3多維度彈性通過HorizontalPodAutoscaler按指標彈性擴縮容t動減HPA(HorizontalPodAutoscaler)可以基于一些指標(例如CPU、內存的利用率)自動擴縮DeploymentStatefulSet中的Pod副本的數量，達到工作負載穩定的目的，真正做到按HPA使用場景流量突發：突然流量增加，負載過載時會自動增加Pod數量以及時響應自動縮容：流量較少時，負載對資源的利用率過低時會自動減少Pod的數量以避免浪費通過HorizontalPodCronscaler定時擴縮容電商平臺，雙十一要進行促銷活動，這時可以考慮使用HPA自動擴縮的流量暴增，如果能提前發生副本擴容，將有效承載流量井噴。HPC(HorizontalPodCronscaler)是騰訊云容器服務TKE自研組件，旨在定時控制副本擴容時資源不足的影響，相較社區的CronHPA，額與HPA結合：可以實現定時開啟和關閉HPA，讓你的業務在高峰時更彈性不太可能永遠都是規律的，設置例外日期可以減少手工調整C單次執行：以往的CronHPA都是永久執行，類似Cronjob，單次執行可以更靈活的應對大HPC使用場景戲服務器在星期日晚上后縮放為原始規模，則可以為玩家提供更好的體驗。通過VerticalPodAutoscaler垂直擴縮容KubernetesPod垂直自動擴縮(VerticalPodAutoscaler，以下簡稱VPA)可以自動調PodCPU預留，幫助提高集群資源利用率并釋放CPU和內存供其它Pod使用。縮功能HPA，VPA具有以下優勢：VPA擴容不需要調整Pod副本數量，擴容速度更快。VPAHPA容。Request設置過大，使用HPA水平縮容至一個Pod時集群資源利用率仍然很低，此時可VPA使用場景VPA縮特性使容器服務具有非常靈活的自適應能力。應對業務負載急劇飆升的情縮小Request節省計算資源。整個過程自動化無須人為干預，適用于需要應用擴容等場景。此外，VPA可用于向用戶推薦更合理的Request，在保證通過ClusterAutoscaler自動調整節點數量HPAHPC，都是在業務負載層面的自動擴縮副本數量，以靈活應對流量的升資源利用率。但是對于集群整體而言，資源總數是固定的，HPA和HPC只是資源，是否有一種方法，能在集群整體較“空”時回收部分資源，能在集集群整體資源？因為集群整體資源的使用量直接決定了賬單費用，這種擴縮將真正節省使用成本。CA景突增的負載擴容合適的節點的空閑情況釋放多余的節點通過虛擬節點獲得Serverless能力資源中。騰訊云容器服務的虛擬節點會將開啟該功能的集群中，符合odPod具備云服務器一致的安全隔離性，具備與部署在集群既有節點建流程更快，有效應對流量突發場景；虛擬節點瞬時縮容，有效避免浪景減少集群資源buffer，應對長期運行服務波峰O到短期運行任務O這些O行任務運行結束Pod退出會自動退還資源并停止計費，不需要人力或程競價實例(SpotInstance)是云服務器CVM的一種新實例運作模式，它最核心的特點是制。但正如它的名字一樣，您和其他同時使用競價實例的用戶存在一定定場景下，實例可能會被回收，我們官方將這種回收定義為系統主動中斷 訊云的競價實例模型下，僅會因為競價實例資源池庫存不足而統會自動根據實時庫存變化回收這些折扣售賣的實例。當您成功購買一數據分析等具有容錯能力的業務應用，尤其是基于云原生框架構建的應用，的前提下，保證業務的穩定性。4.2.4在離線混部填充其他作業，運行更多的作業。第一種方式適合不同類型的應高。充，需要保證在線作業不受影響，保證其SLO在可接受范圍內，同時離線，當在線作業需要資源的時候，及時出讓。另外，離線運行起來之線作業和離線作業，混部要解決的問題是如何通過集群各個時段的在線空閑資源利用起來。集群每個時段的空閑資源會發生變包括行時間短、計算需求大、容錯率高、時延不敏感，允許重運行，典型的是HadoopMapReduce、Spark作業。于Kubernetes和Mesos的。離線場景主要也有兩類，分別是Hadoop類的大Kubernetes各種離線應用慮。由于場景比較多，混部也確定了兩個主要目的前提下，盡可能提升資源使用率。技術路線有幾個原則：一是通用技太多要生態。Kubernetes現了以下關鍵技術，如：任務級別標準，用于對應不同優先級資源。(2)調度增強：因離線任務量大，運行時間短，原生的Kubernetes調度器無法滿足大批量調器進行協調，防止資源被重復調度。(3)資源復用：每個Kubernetes的kubelet節點通過daemonset部署一個agent組件，置資源回收、離線資源配額分配和資源隔離等功能。(4)資源畫像：預測在線作業的各類資源使用情況，指導離線作業調度和隔離。(5)存算分離：通過Ceph或騰訊云云硬盤CBS(CloudBlockStorage，簡稱CBS)分布式解決離線作業需要大量存儲空間及磁盤IO問題。(6)任務避讓：解決節點負載不均衡問題，重新調度離線作業到低負載節點和實現負載升高功能。作業的時延數據，如本身暴露的時延指標、CPI數據或硬件指標數4.2.4GPU共享GPU的并行算力已經非常普遍。很多廠商基于費。隨著GPU卡越來越多，獨占GPU卡帶來的資源浪費會越來越嚴重。大家的訴求很自然GPU包含兩個關鍵技術點：精細調度與GPU隔離。前者在保證業務負載可被調度到GPU卡上的同時，通過諸如binpack、spread或負載感知等調度策略，保證負載按照的最大性能。而后者則保證在共享GPU資源時，業務互相之間不受干擾，這也PU的提升，你也無需擔心共享帶來的資源競爭會損害業務。4.2.5優化矩陣注釋：(EKS，騰訊云彈性容器服務ElasticKubernetesService)4.3成本運營成本優化都是項目制，做完項目后效果很好，但是很快反彈了。所以我、文化、流程等方面建設成本運營體系，這已經成為業界共識，FinOps應運而價值。”FinOps踐整理了成本運營五大關鍵步驟：建立成本優化團隊推動成本優化意識數據驅動成本優化在流程中考慮成本量化成本優化交付的業務價值4.3.1建立成本優化團隊可以是一個現有的個人或者團隊，也可以是整個組織中由財成本舉行方法，并具備項目管理、數據科學、財務分析和軟件/基礎設施開發的能力。他們可以執行成本優化(集中式方法)、影響技術團隊執行優化(分散式)或將兩者相結合(混合式)，從而推進完成成本優化的目標。可以對照成本優化目標(例如資源利用率)來衡量團隊的執行和交付能力。導者，他們會為此按組織確定的優先級開展成本優化活動。此部門及其支持者會共同確4.3.2推動成本意識文化以員的成本意識是較長時期的任務，我們需要營造有利于提高成本意在培訓中強調成本的重要性和控制成本的必要性積極倡導成本是企業的核心競爭力，成本優化能夠帶來真正意義上的商業價值。4.3.3數據驅動成本優化0的的目標。4.3.4在流程中考慮成本，需要在軟件生命周期全過程中去考慮成本，可成本優化左移(DevFinOps)，通過工具或者自動化加快成本優化，工程師在架構設計時需保證能夠和業務目標保持一致。確保變更管理包含成本度量，以量化變更對成本的影響，這樣有助于解決與成本相關的問成本優化是運維或者說運營能力的核心組成部分；例如我們可以采用目前的故障管理流程在組織中開展成本意識的培訓和認證，有助于建立自我管理成本的組織。4.3.5量化成本優化交付的業務價值概念，成本優化的最終目標是將成本追溯到業務收益，這不是在云用戶1如果我的商品訂單數在那段時間內翻了一番怎么辦？那么它是中性的。如果我的商品訂單數在那段時間內增加了三倍怎么辦？然后，我們只漲了100萬就是非常的結果。2那么波谷時資源利用率就會很低，長時間的低資源利用率也會導致資源浪業務很難實現總體資源利用率的最優化。到成本浪費的根源。定位到問題根源后，選擇成本優化的路徑需要綜合考慮成本、性能、穩定性營更關注成本，需要建立合理的計量計費方法，將資源利率可視化轉換為費用可視化，并延資源配額推薦和動態彈性伸縮，防止不同團隊為保證業務穩定性過度侵占和消耗資源。二是動態治本之法。成本運營包含五大關鍵步驟，包括建立成本優化團隊、推動成本優化意識、數據成本優化、在流程中考慮成本、量化成本優化交付的業務價值。成功的云原生成本管理非一時34客戶降本案例6.1作業幫人工智能、大數據等前沿技術，為學生提供更高效的學習解決方案。隨著業務需求的發展，作業幫平臺、提升計算資源利用率等需求迫在眉睫。企業成本管控的常規做法是將各項計算、存儲、網絡資源歸口到具體業務單元，然后由系統運。6.1.1當前作業幫降本增效存在的問題1.應用性能有待提升2.應用部署模式差，帶來計算資源的浪費a)單應用服務機器負載率低業務一般代表著公司核心業務，一方面為了穩定性的考慮，整體水位不能控制的過低。另b時間不均，且真正的最高峰只有不到一個小時。企業不得不為這一個小時的用量而付出一天的成本。c)空間不均衡量計算資源，另一方面是大數據離線計算需要大量計算資從整個公司視角來看，資源使用極不均衡。3.資源性能有待提升。受硬件帶來的成本優化紅利。6.1.2解決方案用率的最大化。1.大幅提升應用性能5d源。提升。碎片化問題也得到徹底解決。3.使用新硬件，大幅提升單位計算的性價比使用有限數量的機型，做一些機型更換時減少了業務研發適配的6.1.3實踐價值速擴縮容，服務運行態規范落地和統一的運維環境，多云的環境統一，Q時找特殊機型的機器不好找，沒有buffer。大部分都是混部多個服務，傳統的VM擴容需要涵蓋所有服務(權限/一致性)，整體的流等問題經常發生。每年甚至要花費幾個月的時間搞裁撤。費嚴重66.2.2優化方案6.2.3應用效果6.2.4展望未來有不小的提升。目前對于現有業務遷移成本來是比較高，我們在接入之前做了很多針對音樂特性的7取代掉，盡最大的可能發揮云原生的能力。上6.3.2基本方案6.3.3典型場景上。的機型做轉碼處理，Pod掛載高IOPS的SSD云盤高寫緩存；云上24000核彈性Pod助6.4更美86.4.1云原生是什么服務的部署、運行、彈性伸縮，都更加簡便、智能。使得部署、維護流程中的節點、接口都模塊化，可以通用的自動化接入譬如監控、日志、測試、發布等，而不需要過多6.4.2云原生與更美降本增效目標的關系了近乎無限數量的多需求同時開發和提測的能力，同時減少對一些基礎服務的多環境運行維無介入。6.4.3使用云原生技術降低成本最佳實踐簡單分為架構實現的資源成本、支持和人力時間成本。提測時的資源浪費測的需求。單一的測試環境難以滿，而搭建多套測試環境的架構成本會非產研測團隊，不再等待測試環境占用、釋放的排隊中浪費時間，有效提升開發迭源。各個環境的數據管理、配置管理，也難以統一。在微服務架構模式下，雖然有模塊化、易接入、易開發等諸多優點，但是在開發人員看難以支撐運行基礎開發環境。9案了滿足開發和測試團隊的多feature、多分支并行提測的需求，架構運維組人工搭建多套測試環開發人員的困境，嘗試在一套測試環境中，將所有底層微服務的接口都通過負載均衡暴露。果2.開發人員構建開發環境難度大。案、多feature并行測試的需求，在測試環境引入了ServiceMesh工具務，可以在根據命名規范切出對應分支后，部署對應分