降本之源云原生成本管理白皮書

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