2024云原生成本管理白皮書(shū)

云原生成本管理白皮書(shū)2023PAGEPAGE10目錄一、背景介紹 5二、云原生成本管理模型 6資源利用率現(xiàn)狀 7云原生成本管理模型 12成本洞察 12成本優(yōu)化 13成本運(yùn)營(yíng) 13三、云原生資源管理能力成熟度模型 15云原生成熟度模型(CNMM)等級(jí)一 15應(yīng)用架構(gòu)&服務(wù)治理 15應(yīng)用彈性 15編排&調(diào)度 15集群彈性 16云原生成熟度模型(CNMM)等級(jí)二 16應(yīng)用架構(gòu)&服務(wù)治理 16應(yīng)用彈性 16編排&調(diào)度 16集群彈性 16云原生成熟度模型(CNMM)等級(jí)三 16應(yīng)用架構(gòu)&服務(wù)治理 16應(yīng)用彈性 17編排&調(diào)度 17集群彈性 17云原生成熟度模型(CNMM)等級(jí)四 17應(yīng)用架構(gòu)&服務(wù)治理 17應(yīng)用彈性 17編排&調(diào)度 17集群彈性 18四、最佳實(shí)踐 19成本洞察 19成本采集及資源追蹤 19資源使用可視化 19費(fèi)用可視化 19成本分配 20賬單管理 22成本優(yōu)化 23設(shè)置合理的資源請(qǐng)求和限制 23動(dòng)態(tài)調(diào)度 26多維度彈性 28在離線混部 32GPU共享 35優(yōu)化矩陣 37成本運(yùn)營(yíng) 38建立成本優(yōu)化團(tuán)隊(duì) 39推動(dòng)成本意識(shí)文化 39數(shù)據(jù)驅(qū)動(dòng)成本優(yōu)化 39在流程中考慮成本 40量化成本優(yōu)化交付的業(yè)務(wù)價(jià)值 40五、總結(jié) 42六、企業(yè)客戶(hù)降本案例 446.1作業(yè)幫 44當(dāng)前作業(yè)幫降本增效存在的問(wèn)題 44解決方案 44實(shí)踐價(jià)值 45QQ音樂(lè) 45QQ音樂(lè)降本增效核心痛點(diǎn) 45優(yōu)化方案 46應(yīng)用效果 46展望未來(lái) 466.3B站 47B站降本增效核心痛點(diǎn) 47基本方案 47典型場(chǎng)景 476.4更美 47云原生是什么 48云原生與更美降本增效目標(biāo)的關(guān)系 48使用云原生技術(shù)降低成本最佳實(shí)踐 486.5銷(xiāo)售易 50云原生是什么 50云原生與銷(xiāo)售易降本增效目標(biāo)的關(guān)系 50使用云原生技術(shù)降低成本最佳實(shí)踐 50展望未來(lái) 516.6云集 51云原生是什么 52云原生與云集增效目標(biāo)的關(guān)系 52使用云原生技術(shù)降低成本最佳實(shí)踐 52展望未來(lái) 54 前言云原生使組織能夠在現(xiàn)代云環(huán)境（例如公共云、私有云和混合云）中構(gòu)建和運(yùn)行可擴(kuò)展的應(yīng)用程序,更快地創(chuàng)新并使企業(yè)能夠更敏捷地對(duì)市場(chǎng)作出反應(yīng)。云原生是應(yīng)用程序開(kāi)發(fā)的未來(lái)，具有巨大的業(yè)務(wù)影響潛力——能夠快速有效地將想法轉(zhuǎn)化為生產(chǎn)。云原生已賦能許多其他技術(shù)，例如邊緣計(jì)算、人工智能、區(qū)塊鏈、5G應(yīng)用等。抓住云原生變得特別重要,你準(zhǔn)備好了以下了沒(méi):快地生成需求。Kubernetes，一、背景介紹數(shù)字經(jīng)濟(jì)已成為我國(guó)經(jīng)濟(jì)增長(zhǎng)的重要引擎，云計(jì)算從部分企業(yè)數(shù)字化轉(zhuǎn)型的載體，轉(zhuǎn)變?yōu)檎麄€(gè)經(jīng)濟(jì)社會(huì)發(fā)展的基石與樞紐。萬(wàn)千企業(yè)數(shù)字化轉(zhuǎn)型提速換擋，對(duì)云計(jì)算的使用效能提出了更高的要求，云計(jì)算迎來(lái)了全新的發(fā)展機(jī)遇。20202021云原生成本管理一是需要掌握成本支出態(tài)勢(shì)，準(zhǔn)確定位資源浪費(fèi)的根源；二是需要選擇適合平臺(tái)架構(gòu)和業(yè)務(wù)特點(diǎn)的資源優(yōu)化策略，并規(guī)避因資源優(yōu)化導(dǎo)致對(duì)業(yè)務(wù)穩(wěn)定性的影響；三是實(shí)現(xiàn)成本優(yōu)化后還需要保證其持久性。資源成本優(yōu)化從基于賬單優(yōu)化的成本可視、基于資源優(yōu)化的成本節(jié)約以及基于模式優(yōu)化的成本運(yùn)營(yíng)從三方面幫助降低云原生平臺(tái)成本。 二、云原生成本管理模型云原生并非一項(xiàng)單純的技術(shù)，更是一種思想，是技術(shù)、企業(yè)管理方法的集合，云原生追求的是在包括公有云、私有云、混合云等動(dòng)態(tài)環(huán)境中構(gòu)建和運(yùn)行規(guī)模化應(yīng)用的能力，追求的是業(yè)務(wù)持續(xù)平滑的變更能力。KubernetesKubernetes遵循聲明API，PodKubernetes以后，KubernetesKubernetesKubernetes自動(dòng)化機(jī)Kubernetes資源利用率現(xiàn)狀根據(jù)中國(guó)信息通信研究院調(diào)查數(shù)據(jù)顯示，云原生技術(shù)給企業(yè)帶來(lái)的價(jià)值中，提升資源利用率以節(jié)約成本連續(xù)兩年排名第一，2021年，已有九成用戶(hù)認(rèn)可該項(xiàng)價(jià)值。選項(xiàng)2020年2021年提升資源利用率以節(jié)省成本76%90.59%提升彈性伸縮效率63%76.98%提升交付效率38%66.83%簡(jiǎn)化運(yùn)維系統(tǒng)30%67.57%開(kāi)放架構(gòu)方便現(xiàn)有系統(tǒng)上的功能擴(kuò)展25%48.02%12020CNCFKubernetes2019年的72%增長(zhǎng)到了82，Kubernetes圖1Kubernetes近年部署率但是，隨著企業(yè)用云程度加深，越來(lái)越多的應(yīng)用遷移到云原生架構(gòu)上，原本天然具備降本增效特點(diǎn)的云原生架構(gòu)如果資源配置不當(dāng)也會(huì)引起大量云上資源閑置、云支出浪費(fèi)。2021年CNCF《FinOpsKubernetesReport》調(diào)研報(bào)告顯示，遷移至Kubernetes平臺(tái)后，68%的受訪者表示所在企業(yè)計(jì)算資源成本有所增加，36%的受訪者表示成本飆升超過(guò)20%，調(diào)查結(jié)果如圖3所示。這都說(shuō)明即使是資源利用率更高的云原生架構(gòu)也需要合理的資源成本管理。圖3遷移至Kubernetes平臺(tái)后成本變化調(diào)查結(jié)果KubernetesKubernetes集群中，資源行Pod量6%，針對(duì)相同統(tǒng)計(jì)口徑，騰訊云對(duì)1000多家云客戶(hù)進(jìn)行了資源利用情況分析，抽樣超過(guò)一萬(wàn)計(jì)算節(jié)點(diǎn)，實(shí)際使用率如圖3所示：42%10%72%20%15%20%-30%13%30%圖3資源利用率調(diào)查將統(tǒng)計(jì)數(shù)據(jù)匯總，我們可以看到，計(jì)算節(jié)點(diǎn)的平均資源利用率在10%左右，這意味著云用戶(hù)90%的計(jì)算資源成本是閑置的，這造成了高企的云成本，形成了極大的浪費(fèi)。針對(duì)此種狀況，下文分析了主要原因：資源預(yù)留過(guò)多，普遍存在50%以上的浪費(fèi)KubernetesPod的資源需求（ResourceRequest）字段用于管理容器對(duì)CPU和內(nèi)存資源預(yù)留，保證容器至少可以達(dá)到的資源量，該部分資源不能被其他容器搶占。如何設(shè)置資源需求是一個(gè)難題，若設(shè)置過(guò)小，當(dāng)業(yè)務(wù)負(fù)載變高時(shí)，業(yè)務(wù)所需的計(jì)算資源無(wú)法被確保，可能會(huì)造成計(jì)算變慢、延遲過(guò)高等影響業(yè)務(wù)指標(biāo)的情況。為避免此情況發(fā)生的可能性，用戶(hù)通常會(huì)將Request設(shè)置得很高，以保證服務(wù)的可靠CPU4（Request）（CPU_Usage）Request圖4CPU資源利用率業(yè)務(wù)資源使用率波峰波谷現(xiàn)象普遍，低峰時(shí)資源浪費(fèi)嚴(yán)重5CPUCPUCPU圖5資源利用率的波動(dòng)現(xiàn)象不同類(lèi)型的業(yè)務(wù)，對(duì)資源的需求不同CPU6圖6負(fù)載峰值在不同時(shí)段的業(yè)務(wù)混部針對(duì)資源利用率低的現(xiàn)狀，我們對(duì)數(shù)十個(gè)客戶(hù)進(jìn)行了訪談，了解到他們?cè)诔杀竟芾頃r(shí)的挑戰(zhàn)：Kubernetes7圖7優(yōu)化方案的決策平衡開(kāi)銷(xiāo)較大。客戶(hù)需要從組織、文化、流程等多維度提升對(duì)云成本的認(rèn)知，在系統(tǒng)設(shè)計(jì)之初就將云成本納入考量范圍之內(nèi)。云原生成本管理模型基于資源利用率的現(xiàn)狀和挑戰(zhàn)，我們整理了三階段云原生成本管理模型，如圖8所示：圖8云原生成本管理模型成本采集及資源追蹤云環(huán)境下的資源使用和成本支出是比較復(fù)雜的，團(tuán)隊(duì)或組織需要通過(guò)一定的工具或方案對(duì)各種產(chǎn)品進(jìn)行定義、定價(jià)、計(jì)費(fèi)及統(tǒng)計(jì)，并對(duì)各類(lèi)資源的使用率、使用量等指標(biāo)進(jìn)行持續(xù)追蹤，能幫助團(tuán)隊(duì)盡可能多地搜集到云成本情況，為后邊成本可視化以及成本分配提供數(shù)據(jù)基礎(chǔ)。成本可視化和成本分配Kubernetes的成本分配比傳統(tǒng)的云環(huán)境面臨更多挑戰(zhàn)，團(tuán)隊(duì)需要定義一致的標(biāo)簽和命名空間來(lái)改善分配，對(duì)于任何組織、部門(mén)及職能團(tuán)隊(duì)，基于多維度（如云產(chǎn)品、環(huán)境、業(yè)務(wù)線）的資源和成本的可視化分析，能夠幫助團(tuán)隊(duì)有效地建立起相應(yīng)的問(wèn)責(zé)機(jī)制，并根據(jù)獲取到的實(shí)時(shí)數(shù)據(jù)快速制定優(yōu)化方案及措施。賬單管理云賬單的繁冗性和復(fù)雜性給用戶(hù)帶來(lái)非常大的不便，團(tuán)隊(duì)或組織需要對(duì)賬單進(jìn)行統(tǒng)一高效的管理，一是根據(jù)實(shí)際的業(yè)務(wù)需求，將賬單按組織、部門(mén)、項(xiàng)目業(yè)務(wù)維度，年、月周期維度等進(jìn)行詳細(xì)化的拆分。二是將各類(lèi)賬單進(jìn)行統(tǒng)一分析，包括過(guò)去一段時(shí)間的使用情況、未來(lái)使用趨勢(shì)分析、各部門(mén)成本使用情況等方面，并給出合理的規(guī)劃及更改建議。三是將分析后賬單情況按業(yè)務(wù)部門(mén)、周期、自定義等維度定期推送給團(tuán)隊(duì)，方便團(tuán)隊(duì)及時(shí)得到相應(yīng)的賬單。提供可靠、便利、智能的優(yōu)化方案基于成本可視化和成本分配等手段，有了數(shù)據(jù)作為度量依據(jù)，團(tuán)隊(duì)能夠圍繞其業(yè)務(wù)目標(biāo)及業(yè)務(wù)場(chǎng)景制定對(duì)應(yīng)的成本優(yōu)化目標(biāo)。針對(duì)云原生場(chǎng)景，云上資源成本優(yōu)化不僅僅是對(duì)云資源規(guī)格、數(shù)量的調(diào)整，也包含了對(duì)業(yè)務(wù)的架構(gòu)優(yōu)化、以及通過(guò)彈性能力和資源混部等手段提升資源利用率。此階段的優(yōu)化方案包括：正確評(píng)估應(yīng)用容量，設(shè)置合適的資源請(qǐng)求通過(guò)動(dòng)態(tài)調(diào)度解決資源碎片的問(wèn)題，提高裝箱率回收業(yè)務(wù)波谷時(shí)的冗余，通過(guò)彈性和混部做到按需使用對(duì)于固定資源池，對(duì)負(fù)載峰值在不同時(shí)段的在線應(yīng)用、在離線應(yīng)用進(jìn)行混部，做到分時(shí)復(fù)用GPU資源，實(shí)現(xiàn)資源的池化和共享從流程、組織、文化等方面建設(shè)成本運(yùn)營(yíng)體系云上資源優(yōu)化并非是通過(guò)一系列標(biāo)準(zhǔn)動(dòng)作后得出的一個(gè)終態(tài)恒定值。如同追求系統(tǒng)穩(wěn)定性冗余大量資源，追求極致成本而犧牲業(yè)務(wù)穩(wěn)定性同樣不可取。業(yè)務(wù)本身是變化的，適合的系統(tǒng)架構(gòu)及管理方式同樣如此，我們鼓勵(lì)從組織、文化、流程等方面建設(shè)成本運(yùn)營(yíng)體系，根據(jù)目標(biāo)持續(xù)不斷調(diào)整和優(yōu)化。此階段的優(yōu)化方案包括：建立成本優(yōu)化團(tuán)隊(duì)推動(dòng)成本優(yōu)化意識(shí)數(shù)據(jù)驅(qū)動(dòng)成本優(yōu)化在流程中考察成本量化成本優(yōu)化交付的業(yè)務(wù)價(jià)值 三、云原生資源管理能力成熟度模型云原生降本白皮書(shū)提出了云原生成熟度模型（CNMM,CloudNativeMaturityModel，主要聚焦云原生領(lǐng)域的資源使用、管理、優(yōu)化。它描述了云原生的演進(jìn)過(guò)程，涵蓋一個(gè)成熟的云原生采納方所應(yīng)具備的重要功能。從應(yīng)用架構(gòu)&服務(wù)治理、應(yīng)用彈性、編排&調(diào)度、集群彈性四個(gè)維度分析云原生使用的成熟度，并分成了四個(gè)等級(jí)，具體如下圖所示：圖9云原生成熟度模型CNMM云原生成熟度模型等級(jí)一&服務(wù)治理這個(gè)時(shí)候是云原生采納的早期階段，業(yè)務(wù)還是采用傳統(tǒng)的單體架構(gòu)的形式部署，在Kubernetes集群里面普遍采用富容器，但違反了Kubernetes容器單進(jìn)程的設(shè)計(jì)初衷，不利于容器的健康檢查和彈性。業(yè)務(wù)架構(gòu)耦合嚴(yán)重，研發(fā)或發(fā)布一次，可能需要數(shù)周甚至數(shù)月的周期，回滾復(fù)雜，幾乎沒(méi)有灰度的能力。應(yīng)用彈性幾乎沒(méi)有彈性的能力和配置，業(yè)務(wù)在開(kāi)發(fā)之前，會(huì)提前預(yù)留大量的資源，預(yù)定資源固定且不會(huì)隨業(yè)務(wù)負(fù)載峰谷變化而動(dòng)態(tài)調(diào)整。編排調(diào)度在這個(gè)階段里，業(yè)務(wù)在申請(qǐng)資源和調(diào)度的時(shí)候，沒(méi)有彈性的能力。為了讓自己的業(yè)務(wù)在波峰的時(shí)候也能平穩(wěn)運(yùn)行，普遍都會(huì)超配資源。業(yè)務(wù)之間也沒(méi)有優(yōu)先級(jí)的劃分，當(dāng)資源不足，業(yè)務(wù)之間有影響時(shí)，沒(méi)有合理的手段有效的避免業(yè)務(wù)競(jìng)爭(zhēng)。集群彈性幾乎沒(méi)有集群范圍的彈性，還是以傳統(tǒng)的IDC機(jī)房整機(jī)批量采購(gòu)的形式，提前先購(gòu)買(mǎi)大規(guī)模的集群，然后各個(gè)業(yè)務(wù)團(tuán)隊(duì)各自使用，沒(méi)有實(shí)時(shí)靈活的集群范圍的彈性功能，集群的擴(kuò)縮都需要走專(zhuān)門(mén)的審批流程。業(yè)務(wù)之間為了降低影響性，通常都是按照傳統(tǒng)IDC的運(yùn)行模式，單獨(dú)節(jié)點(diǎn)運(yùn)行單獨(dú)的業(yè)務(wù)。云原生成熟度模型等級(jí)二應(yīng)用架構(gòu)&服務(wù)治理等級(jí)2的時(shí)候富容器場(chǎng)景少了很多，業(yè)務(wù)擁抱容器化，不斷的將業(yè)務(wù)模塊拆分，打造微服務(wù)的架構(gòu)，集群內(nèi)部服務(wù)之間也有了跟多的調(diào)用關(guān)系。但缺少有效的服務(wù)的管理機(jī)制以及流量的治理方式。應(yīng)用彈性開(kāi)始做一些手工的彈性，例如：會(huì)人工的檢測(cè)工作負(fù)載的實(shí)際負(fù)載情況，然后手工調(diào)整工作負(fù)載的副本數(shù)。會(huì)利用一些工具：例如定時(shí)調(diào)整副本數(shù)，或者使用Kubernetes原生的HPA能力，手工配置參數(shù)和副本數(shù)范圍。但這些數(shù)值的設(shè)置和定義都需要大量的經(jīng)驗(yàn)和手工，且有時(shí)候配置無(wú)法生效。編排調(diào)度這時(shí)候在編排調(diào)度層面，會(huì)有了更多的經(jīng)驗(yàn)為工作負(fù)載設(shè)置更合適的數(shù)值，會(huì)根據(jù)不同的業(yè)務(wù)等級(jí)為不同的工作負(fù)載配置不同比例的Request/Limit數(shù)值，以達(dá)到不同的QoS的等級(jí)，這樣在資源調(diào)度和資源搶占時(shí)，會(huì)保證高優(yōu)先級(jí)的業(yè)務(wù)的資源能夠供給充沛，低優(yōu)先級(jí)的業(yè)務(wù)在面對(duì)高優(yōu)先級(jí)業(yè)務(wù)的時(shí)候，資源使用被壓制。集群彈性此時(shí)已經(jīng)開(kāi)始使用靈活的集群擴(kuò)縮的機(jī)制，但還是更多的偏手工的執(zhí)行，手工為集群添加、移出節(jié)點(diǎn)。業(yè)務(wù)之間也會(huì)共享資源池，而不是單節(jié)點(diǎn)運(yùn)行單獨(dú)業(yè)務(wù)，資源的復(fù)用能力以及利用率有一定的提升。云原生成熟度模型等級(jí)三應(yīng)用架構(gòu)&服務(wù)治理此時(shí)在應(yīng)用架構(gòu)方面已經(jīng)基本上Kubernetes化了，將Kubernetes的相關(guān)能力完全應(yīng)用到了實(shí)際的業(yè)務(wù)開(kāi)發(fā)、架構(gòu)、部署上。服務(wù)也開(kāi)始使用優(yōu)雅啟動(dòng)、優(yōu)雅停機(jī)等高階的能力，避免長(zhǎng)連接的服務(wù)在工作負(fù)載縮容的時(shí)候流量中斷，整個(gè)架構(gòu)和服務(wù)治理已經(jīng)趨近成熟。應(yīng)用彈性開(kāi)始使用更多的彈性工具：不僅僅是基于HPA原生支持的指標(biāo)，也開(kāi)始對(duì)接業(yè)務(wù)自己定義的一些指標(biāo)做到應(yīng)用的彈性擴(kuò)縮容。但此時(shí)還是需要手工定義工作負(fù)載彈性擴(kuò)縮容時(shí)的副本數(shù)范圍，范圍如果沒(méi)有及時(shí)調(diào)整，就有可能造成資源浪費(fèi)，或者更嚴(yán)重的是：無(wú)力處理波峰流量。編排調(diào)度資源配置有了很多經(jīng)驗(yàn)，不僅僅是依據(jù)CPU和內(nèi)存的用量、利用率來(lái)為工作負(fù)載配置，也會(huì)結(jié)合實(shí)際的業(yè)務(wù)指標(biāo)調(diào)整工作負(fù)載對(duì)CPU和內(nèi)存的請(qǐng)求量。設(shè)置更合理的資源Request/Limit比例，進(jìn)一步保證高優(yōu)業(yè)務(wù)的平穩(wěn)運(yùn)行。也會(huì)利用一些調(diào)度工具優(yōu)化集群調(diào)度能力，例如：基于節(jié)點(diǎn)負(fù)載情況調(diào)度作業(yè)，可以為節(jié)點(diǎn)調(diào)度更多作業(yè)的同事，也能保障高優(yōu)業(yè)務(wù)的資源供給。集群彈性充分利用集群的ClusterAutoscaler能力自動(dòng)擴(kuò)縮集群規(guī)模，自動(dòng)添加、減少集群的節(jié)點(diǎn)數(shù)，節(jié)點(diǎn)幾乎不需要人工接入?yún)⑴c運(yùn)維。云原生成熟度模型等級(jí)四應(yīng)用架構(gòu)&服務(wù)治理單容器單進(jìn)程，不會(huì)有任何多余的容器，業(yè)務(wù)的無(wú)狀態(tài)服務(wù)比例上升，可以充分享受到不可變基礎(chǔ)設(shè)施帶來(lái)的優(yōu)勢(shì)。將服務(wù)網(wǎng)格引入集群，服務(wù)發(fā)現(xiàn)和治理得到了系統(tǒng)化、整體化的統(tǒng)籌，跨集群的服務(wù)和流量管理都得到了有效的解決方案。應(yīng)用彈性基于預(yù)測(cè)的彈性擴(kuò)縮容，解決Kubernetes原生彈性滯后的問(wèn)題：充數(shù)據(jù)上報(bào)、到監(jiān)控采集、到組件識(shí)別和計(jì)算、到觸發(fā)彈性、到最終運(yùn)行起來(lái)一個(gè)新的副本，流程、耗時(shí)較長(zhǎng)，基于預(yù)測(cè)的彈性能有效降低波峰流量的及時(shí)彈性。全自動(dòng)化的彈性能力，用戶(hù)無(wú)需再手工配置任何彈性規(guī)則的指標(biāo)，做到全自動(dòng)化的彈性效果，進(jìn)一步實(shí)現(xiàn)資源的“按需付費(fèi)”。編排調(diào)度基于預(yù)測(cè)的能力調(diào)整資源的配置，用戶(hù)無(wú)需再手工配置任何資源。做到完全自動(dòng)化的配置能力，實(shí)現(xiàn)資源真正的“按需付費(fèi)”。業(yè)務(wù)更多維度的分級(jí)和保證的能力，保證高優(yōu)業(yè)務(wù)的平穩(wěn)運(yùn)行的同時(shí)，使用更少資源運(yùn)行更多業(yè)務(wù)，業(yè)務(wù)之間的沖突和干擾都擁有對(duì)應(yīng)的解決方案。集群彈性集群整體做到完全的Serverless化，讓業(yè)務(wù)和運(yùn)維團(tuán)隊(duì)幾乎感受不到集群和節(jié)點(diǎn)的存在。波峰來(lái)，業(yè)務(wù)自動(dòng)擴(kuò)容，波峰走，業(yè)務(wù)自動(dòng)縮容，無(wú)需在思考和處理集群規(guī)模的問(wèn)題。周邊相關(guān)資源的自動(dòng)擴(kuò)縮容：例如對(duì)日志、監(jiān)控等系統(tǒng)的依賴(lài)，隨著集群和業(yè)務(wù)負(fù)載的提升，對(duì)應(yīng)的日志、監(jiān)控等系統(tǒng)都能做到完全的自動(dòng)擴(kuò)縮容，讓用戶(hù)無(wú)感，把重心完全聚焦在自己的業(yè)務(wù)之上。 四、最佳實(shí)踐成本洞察KubernetesKubernetesPrometheus和Grafana分析Top10Top10Kubernetes在獲取資源實(shí)際用量后，對(duì)接云資源計(jì)費(fèi)系統(tǒng)獲取資源單價(jià)，即可計(jì)算出云資源的實(shí)際使用費(fèi)用。相比資源用量可視化，成本視角的可視化是企業(yè)運(yùn)營(yíng)更關(guān)注的視角，提升資源利用率只是降低云成本的手段。下面展示費(fèi)用可視化的日常應(yīng)用場(chǎng)景：成本分配Kubernetes的成本分配比傳統(tǒng)的云環(huán)境面臨更多挑戰(zhàn)，團(tuán)隊(duì)需要定義一致的標(biāo)簽和命名空間來(lái)改善分配，精確分配資源成本是在Kubernetes環(huán)境中創(chuàng)建成本可見(jiàn)性和實(shí)現(xiàn)高效成本利用的首要步驟。下文就解決云原生架構(gòu)下的費(fèi)用分?jǐn)倖?wèn)題給出一些建議：企業(yè)往往選擇公共的IT團(tuán)隊(duì)來(lái)支付云費(fèi)用，公共的IT團(tuán)隊(duì)再將成本分配給業(yè)務(wù)部門(mén)或業(yè)務(wù)應(yīng)用的所有者。假如在共享Kubernetes集群上運(yùn)行不同業(yè)務(wù)團(tuán)隊(duì)的工作負(fù)載，通過(guò)云廠商本身的費(fèi)用賬單再分配就變得非常困難。所以，成本分配的第一步是梳理并明確共享的資源有哪些，如計(jì)算資源、存儲(chǔ)資源、網(wǎng)絡(luò)資源、云廠商的PaaS服務(wù)如日志等等。理清楚共享成本類(lèi)型之后，就要建立可持續(xù)的公平分配的方法?；谠圃軜?gòu)，用戶(hù)可以為云上運(yùn)行的應(yīng)用添加標(biāo)簽來(lái)標(biāo)識(shí)資源的所有者。建立合理的標(biāo)簽?zāi)Ｐ褪浅杀痉峙渥顬殛P(guān)鍵的一個(gè)步驟。云原生成本分配標(biāo)簽設(shè)計(jì)原則成本分配是一件很有挑戰(zhàn)的事情，不同的團(tuán)隊(duì)關(guān)心的成本角度是不一樣的，比如：成本的標(biāo)記也有多種方式，例如騰訊云提供標(biāo)簽幫助云用戶(hù)有效分隔不同的云資源，此外還有多層級(jí)的CAM（CloudAccessManagement，騰訊云訪問(wèn)管理）賬戶(hù)結(jié)構(gòu)、項(xiàng)目等功能幫助有效分類(lèi)不同的成本。資源標(biāo)簽是云用戶(hù)分類(lèi)云資源的有效手段，不同云用戶(hù)對(duì)標(biāo)簽的使用不盡相同，云服務(wù)商對(duì)標(biāo)簽的語(yǔ)法限制、字符集和長(zhǎng)度等合法性進(jìn)行校驗(yàn)。這種極大的靈活性會(huì)讓云用戶(hù)有相同的疑問(wèn)，到底該如何定義標(biāo)簽?zāi)?？越早越好?biāo)簽定義原則選擇正確數(shù)量的標(biāo)簽標(biāo)簽原則不應(yīng)該強(qiáng)迫團(tuán)隊(duì)?wèi)?yīng)用太多標(biāo)簽。要求過(guò)多的標(biāo)簽只會(huì)導(dǎo)致對(duì)標(biāo)準(zhǔn)的抵觸，從而導(dǎo)致不合規(guī)。最好只針對(duì)所需的核心元數(shù)據(jù)要求標(biāo)簽。與其根據(jù)需要定義所有標(biāo)簽，不如定義可選標(biāo)簽，明確描述團(tuán)隊(duì)在選擇這樣做時(shí)應(yīng)如何實(shí)施它們。易讀簡(jiǎn)化且一致標(biāo)簽的設(shè)計(jì)盡量易讀，并且要保證簡(jiǎn)化，滿(mǎn)足業(yè)務(wù)訴求即可。用戶(hù)應(yīng)該能直接從標(biāo)簽讀懂其含義，但又不能設(shè)計(jì)得過(guò)于冗長(zhǎng)。另外，簡(jiǎn)化的同時(shí)也要保證標(biāo)簽一致性，如果一個(gè)團(tuán)隊(duì)使用“prod”的標(biāo)簽值，而另一個(gè)團(tuán)隊(duì)使用“production”，這些標(biāo)簽的分組方式會(huì)有所不同。命名標(biāo)準(zhǔn)化采用標(biāo)準(zhǔn)化命名格式，使后續(xù)的API集成更加便捷。例如：統(tǒng)一用英文小寫(xiě)，單詞之間用下劃線隔開(kāi)。值得注意的是：您可能開(kāi)始使用“R&D”標(biāo)記資源，但后來(lái)意識(shí)到某些服務(wù)不支持&字符，因此命名盡量考慮使用最通用標(biāo)準(zhǔn)的方式，例如此時(shí)應(yīng)該使用r_and_d。最佳實(shí)踐如果還是不確定如何設(shè)置標(biāo)簽，這里有一個(gè)使用標(biāo)簽的最佳實(shí)踐：/成本中心？還是單獨(dú)計(jì)算某種業(yè)務(wù)的具體成本？例如：可以設(shè)置類(lèi)似cost_allocation=cost_center或cost_allocation=business的標(biāo)簽business_type=orderbusiness_type=logisticsCVM，ins-dfkjdkd，（service_layer=frontend或service_layer=backend賬單管理云賬單是企業(yè)獲得成本支出的第一手資料，賬單的可讀性往往影響到企業(yè)對(duì)成本開(kāi)業(yè)提高賬單分析的效率，使賬單更好地服務(wù)于企業(yè)，以下幾個(gè)方面是賬單管理的落實(shí)步驟：成本優(yōu)化有了完整的成本洞察能力后，即可查看企業(yè)整體成本效率。企業(yè)進(jìn)而能夠圍繞其業(yè)務(wù)目標(biāo)及業(yè)務(wù)場(chǎng)景制定對(duì)應(yīng)的優(yōu)化方案，本小節(jié)將具體介紹成本優(yōu)化的最佳實(shí)踐。我們?cè)倩仡櫹虑拔姆治龅馁Y源浪費(fèi)的常見(jiàn)現(xiàn)象：應(yīng)用設(shè)置了過(guò)大的資源配額應(yīng)用波峰波谷明顯，波谷時(shí)資源浪費(fèi)嚴(yán)重存在不同類(lèi)型的業(yè)務(wù)，對(duì)資源要求不同主要資源優(yōu)化方向包括：正確評(píng)估應(yīng)用容量，設(shè)置合適的資源請(qǐng)求通過(guò)動(dòng)態(tài)調(diào)度解決資源碎片的問(wèn)題，提高裝箱率回收業(yè)務(wù)波谷時(shí)的冗余，通過(guò)彈性做到按需使用對(duì)應(yīng)用進(jìn)行混部，做到分時(shí)復(fù)用針對(duì)GPU資源，實(shí)現(xiàn)資源的池化和共享設(shè)想你是個(gè)集群管理員，現(xiàn)在有四個(gè)業(yè)務(wù)部門(mén)使用同一個(gè)集群，你的責(zé)任是保證業(yè)務(wù)穩(wěn)定性的前提下，讓業(yè)務(wù)真正做到資源的按需使用。為了有效提升集群整體的資源利用率，這時(shí)就需要限制各業(yè)務(wù)使用資源的上限，以及通過(guò)一些默認(rèn)值防止業(yè)務(wù)過(guò)量使用。ResourceRequest和Limit。RequestLimitResourceRequest和Limit（TencentKubernetesEngineTKE）RequestLimitCPU(核)0.250.5Memory(MiB)2561024為了更細(xì)粒度的劃分和管理資源，可以在騰訊云容器服務(wù)TKE上設(shè)置命名空間級(jí)別的ResourceQuota以及LimitRanges。使用資源配額（ResourceQuota）劃分資源如果你管理的某個(gè)集群有四個(gè)業(yè)務(wù)，為了實(shí)現(xiàn)業(yè)務(wù)間的隔離和資源的限制，你可以利用命名空間和資源配額。命名空間是Kubernetes集群里面的一個(gè)隔離分區(qū)，一個(gè)集群里面通常包含多個(gè)命名空間，資源配額用于設(shè)置命名空間資源的使用配額。例如Kubernetes用戶(hù)可將不同的業(yè)務(wù)部署在不同的命名空間里，再為不同的命名空間設(shè)置不同的資源配額，以限制一個(gè)命名空間對(duì)集群整體資源的使用量，達(dá)到預(yù)分配和限制的效果。資源配額主要作用于如下方面，詳細(xì)信息可查看[2]。CPURequestLimit所有PVCPVC/Service/Configmap/Deployment資源配額使用場(chǎng)景//使用LimitRange限制資源資源需求是KubernetesPod中容器定義的可選屬性，用戶(hù)可以不為Pod設(shè)置資源Request和Limit，也可以將值設(shè)置得很大。集群管理員可以為不同的業(yè)務(wù)設(shè)置不同資源使用默認(rèn)值以及范圍，這可以有效減少業(yè)務(wù)創(chuàng)建時(shí)的工作量同時(shí)，限制業(yè)務(wù)對(duì)資源的過(guò)度侵占。LimitRange適用于一個(gè)命名空間下的單個(gè)容器，可以防止用戶(hù)在命名空間內(nèi)創(chuàng)建對(duì)資源申請(qǐng)過(guò)小或過(guò)大容器；當(dāng)用戶(hù)不設(shè)置容器資源需求時(shí)，LimitRange可為容器添加默認(rèn)資源。LimitRanges主要作用于如下方面：CPUPVCRequestLimitRequest/LimitLimitRange使用場(chǎng)景QoSPodLimitRange可在一定程度上提升資源利用率Request推薦即使有了資源配額和LimitRange設(shè)置，多業(yè)務(wù)視角的資源調(diào)配依然無(wú)法做到靈活多變。例如，當(dāng)用戶(hù)的業(yè)務(wù)負(fù)載提升，確實(shí)需要較多資源時(shí)，配額的限制會(huì)阻止快速擴(kuò)容。配額的分配通常需要申請(qǐng)和審批流程，這限制了彈性和創(chuàng)新速度。并且，資源配額限制的是同一個(gè)命名空間的應(yīng)用實(shí)例，當(dāng)一個(gè)命名空間里存在多個(gè)工作負(fù)載時(shí)，工作負(fù)載之間也會(huì)發(fā)生資源搶占，導(dǎo)致某些負(fù)載資源使用受限。LimitRange的作用范圍也是針對(duì)一個(gè)命名空間下的所有業(yè)務(wù)實(shí)例，而同一命名空間里可能存在主業(yè)務(wù)容器也會(huì)存在輔助容器，如果都設(shè)置成固定的大小值也會(huì)造成資源浪費(fèi)或不夠的現(xiàn)象。因此不管是資源配額，還是LimitRanges，它們的限制范圍都是命名空間級(jí)別，粒度較粗。10CPU總量為1906核，CPU的分配率接近60%CPURequestCPU總量的60%（CPU申請(qǐng)量CPU13.4核，CPU0.8%，CPURequest設(shè)置不合理，Request60%，0.8%。Request和Usage圖10某生產(chǎn)集群的資源分配和實(shí)際用量Request的設(shè)置基于云用戶(hù)對(duì)業(yè)務(wù)負(fù)載的深刻理解，不同業(yè)務(wù)的Request設(shè)置各不相RequestRequest81341906*60%=1143智能Request推薦基于業(yè)務(wù)的實(shí)際資源使用情況，給用戶(hù)推薦更合理的Requst數(shù)值，且可以自定義冗余倍數(shù)，避免因?yàn)榱髁客话l(fā)導(dǎo)致的業(yè)務(wù)不穩(wěn)定性。配合上彈性集群能力（ClusteAutocale10，CPU11404001906Request將節(jié)?。?906-400）/1906=79%圖11某生產(chǎn)集群的CPU實(shí)際用量細(xì)節(jié)節(jié)點(diǎn)親和性CPUCPU被CPUCPUKubernetesCPU節(jié)點(diǎn)親和性使用場(chǎng)景（CVM）有CPUCPU的CVMCPUCVMCPUPodCVM上，這樣可以提升CVM資源的整體利用率。同理，還可以在集群中管理異構(gòu)節(jié)點(diǎn)（比如GPU機(jī)器PUPU（負(fù)載感知）原生的KubernetesPod的LeastRequestedPriority，Request不能代KubernetesTKE12圖12動(dòng)態(tài)調(diào)度器動(dòng)態(tài)調(diào)度器的使用場(chǎng)景除了降低資源浪費(fèi)，動(dòng)態(tài)調(diào)度器還可以很好的緩解集群調(diào)度熱點(diǎn)的問(wèn)題。Pod重調(diào)度CPUTKE13

圖13重調(diào)度器和動(dòng)態(tài)調(diào)度器的關(guān)系通過(guò)HorizontalPodAutoscaler按指標(biāo)彈性擴(kuò)縮容RequestHPA（HorizontalPodAutoscaler）可以基于一些指標(biāo)（例如CPU、內(nèi)存的利用率）自動(dòng)擴(kuò)縮Deployment和StatefulSet中的Pod副本的數(shù)量，達(dá)到工作負(fù)載穩(wěn)定的目的，真正做到按需使用。HPA使用場(chǎng)景PodPodHorizontalPodCronscalerHPA自動(dòng)擴(kuò)縮容。但是HPAHPC（HorizontalPodCronscaler）是騰訊云容器服務(wù)TKE自研組件，旨在定時(shí)控制副本數(shù)量，以達(dá)到提前擴(kuò)縮容、和提前觸發(fā)動(dòng)態(tài)擴(kuò)容時(shí)資源不足的影響，相較社區(qū)的CronHPA，額外支持：與HPAHPACronHPACronjobHPC使用場(chǎng)景以游戲服務(wù)為例，從周五晚上到周日晚上，游戲玩家數(shù)量暴增。如果可以將游戲服務(wù)器在星期五晚上前擴(kuò)大規(guī)模，并在星期日晚上后縮放為原始規(guī)模，則可以為玩家提供更好的體驗(yàn)。如果使用HPA，可能因?yàn)閿U(kuò)容速度不夠快導(dǎo)致服務(wù)受影響。通過(guò)VerticalPodAutoscaler垂直擴(kuò)縮容KubernetesPod垂直自動(dòng)擴(kuò)縮（VerticalPodAutoscaler，以下簡(jiǎn)稱(chēng)VPA）可以自動(dòng)調(diào)整Pod的CPU和內(nèi)存預(yù)留，幫助提高集群資源利用率并釋放CPU和內(nèi)存供其它Pod使用。相較于水平自動(dòng)伸縮功能HPA，VPA具有以下優(yōu)勢(shì)：VPAPodVPA，HPARequestHPAPodVPA使用場(chǎng)景VPA自動(dòng)伸縮特性使容器服務(wù)具有非常靈活的自適應(yīng)能力。應(yīng)對(duì)業(yè)務(wù)負(fù)載急劇飆升的情況，VPA能夠在用戶(hù)設(shè)定范圍內(nèi)快速擴(kuò)大容器的Request。在業(yè)務(wù)負(fù)載變小的情況下，VPA可根據(jù)實(shí)際情況適當(dāng)縮小Request節(jié)省計(jì)算資源。整個(gè)過(guò)程自動(dòng)化無(wú)須人為干預(yù)，適用于需要快速擴(kuò)容、有狀態(tài)應(yīng)用擴(kuò)容等場(chǎng)景。此外，VPA可用于向用戶(hù)推薦更合理的Request，在保證容器有足夠使用的資源的情況下，提升容器的資源利用率。通過(guò)ClusterAutoscaler自動(dòng)調(diào)整節(jié)點(diǎn)數(shù)量上面提到的HPA和HPC，都是在業(yè)務(wù)負(fù)載層面的自動(dòng)擴(kuò)縮副本數(shù)量，以靈活應(yīng)對(duì)流量的波峰波谷，提升資源利用率。但是對(duì)于集群整體而言，資源總數(shù)是固定的，HPA和HPC只是讓集群有更多空余的資源，是否有一種方法，能在集群整體較“空”時(shí)回收部分資源，能在集群整體較“滿(mǎn)”時(shí)擴(kuò)充集群整體資源？因?yàn)榧赫w資源的使用量直接決定了賬單費(fèi)用，這種集群級(jí)別的彈性擴(kuò)縮將真正節(jié)省使用成本。14，CA（ClusterAutoscaler）圖14ClusterAutoscaler原理CA使用場(chǎng)景Serverless虛擬節(jié)點(diǎn)并不是節(jié)點(diǎn)，而是一種調(diào)度能力，支持將標(biāo)準(zhǔn)Kubernetes集群中的Pod調(diào)度到集群服務(wù)器節(jié)點(diǎn)之外的資源中。騰訊云容器服務(wù)的虛擬節(jié)點(diǎn)會(huì)將開(kāi)啟該功能的集群中，符合調(diào)度條件的Pod調(diào)度到由彈性容器服務(wù)維護(hù)的云上計(jì)算資源中。部署在虛擬節(jié)點(diǎn)上的Pod具備云服務(wù)器一致的安全隔離性，具備與部署在集群既有節(jié)點(diǎn)上的Pod一致的網(wǎng)絡(luò)隔離性、網(wǎng)絡(luò)連通性，如圖15所示。圖15在虛擬節(jié)點(diǎn)部署業(yè)務(wù)16Kubernetes圖16普通Kubernetes集群與支持虛擬節(jié)點(diǎn)的Kubernetes集群擴(kuò)縮容對(duì)比虛擬節(jié)點(diǎn)使用場(chǎng)景bufferPodbufferPodPod競(jìng)價(jià)實(shí)例競(jìng)價(jià)實(shí)例（SpotInstance）是云服務(wù)器CVM的一種新實(shí)例運(yùn)作模式，它最核心的特點(diǎn)是折扣售賣(mài)和系統(tǒng)中斷機(jī)制。但正如它的名字一樣，您和其他同時(shí)使用競(jìng)價(jià)實(shí)例的用戶(hù)存在一定的競(jìng)爭(zhēng)關(guān)系。在特定場(chǎng)景下，實(shí)例可能會(huì)被回收，我們官方將這種回收定義為系統(tǒng)主動(dòng)中斷（個(gè)競(jìng)價(jià)實(shí)例后，它的使用和按量計(jì)費(fèi)的CVMVPC等。競(jìng)價(jià)實(shí)例使用場(chǎng)景在豐富的實(shí)踐與探索中，我們發(fā)現(xiàn)，Spot非常適合容器、無(wú)狀態(tài)服務(wù)、CI/CD、強(qiáng)化學(xué)習(xí)、離線轉(zhuǎn)碼、大數(shù)據(jù)分析等具有容錯(cuò)能力的業(yè)務(wù)應(yīng)用，尤其是基于云原生框架構(gòu)建的應(yīng)用，在這些場(chǎng)景下可以在巨幅降低成本（80%以上）的前提下，保證業(yè)務(wù)的穩(wěn)定性?；觳扛拍钐岣呒嘿Y源利用率有幾種方式，一是集群本身合理配置應(yīng)用申請(qǐng)資源，盡量運(yùn)行更多的作業(yè)。二是在波谷時(shí)段填充其他作業(yè)，運(yùn)行更多的作業(yè)。第一種方式適合不同類(lèi)型的應(yīng)用混部，應(yīng)用之間資源互補(bǔ)，高峰時(shí)段錯(cuò)開(kāi)。若是同種類(lèi)型的應(yīng)用，應(yīng)用都在同一時(shí)段處于高峰，這種情況適合第二種方式。本節(jié)主要闡述基于方式二的混部，即在線離線混部。SLO混部場(chǎng)景HadoopMapReduce、SparkKubernetes和MesosHadoopKubernetes圖17混部場(chǎng)景混部架構(gòu)18圖18在在離線混部架構(gòu)設(shè)計(jì)以Kubernetes為依托，實(shí)現(xiàn)了以下關(guān)鍵技術(shù)，如：KubernetesgangschedulingKubernetes的kubeletdaemonsetagentCephCBS（CloudBlockStorageCBS）IOCPI數(shù)據(jù)或硬件指標(biāo)數(shù)GPUGPUGPUGPUKubernetesPodGPUGPUGPUGPU19圖19GPU共享GPUGPUGPUbinpack、spreadGPUGPUGPUGPUGPU18TKEqGPUTKE集群上創(chuàng)建qGPU節(jié)點(diǎn)池，并在創(chuàng)建負(fù)載時(shí)指定qGPU算力與顯存。TKEqGPUGPUGPU利用率

圖20TKEqGPU上面的章節(jié)概述了成本優(yōu)化的各種手段，那么在何種場(chǎng)景下應(yīng)該用何種技術(shù)手段，每種手段的效果和實(shí)現(xiàn)難度如何評(píng)估呢？我們將這些能力歸入四個(gè)象限，橫坐標(biāo)為成本，縱坐標(biāo)為難度，如圖21所示。圖21優(yōu)化方案的難度和效果注釋?zhuān)?EKS，騰訊云彈性容器服務(wù)ElasticKubernetesService)成本運(yùn)營(yíng)云成本優(yōu)化并非是通過(guò)一系列標(biāo)準(zhǔn)動(dòng)作后得出的一個(gè)終態(tài)恒定值，而是一個(gè)持續(xù)迭代和優(yōu)化的過(guò)程。很多企業(yè)做成本優(yōu)化都是項(xiàng)目制，做完項(xiàng)目后效果很好，但是很快反彈了。所以我們需要從組織、文化、流程等方面建設(shè)成本運(yùn)營(yíng)體系，這已經(jīng)成為業(yè)界共識(shí)，F(xiàn)inOps應(yīng)運(yùn)而生。FinOps基金會(huì)的定義很好的涵蓋了它的本質(zhì)：“FinOps是云的運(yùn)營(yíng)模式。FinOps實(shí)現(xiàn)了一種轉(zhuǎn)變——系統(tǒng)、最佳實(shí)踐和文化的組合—DevOpsFinOps我們結(jié)合FinOps和客戶(hù)實(shí)踐整理了成本運(yùn)營(yíng)五大關(guān)鍵步驟：建立成本優(yōu)化團(tuán)隊(duì)推動(dòng)成本優(yōu)化意識(shí)數(shù)據(jù)驅(qū)動(dòng)成本優(yōu)化在流程中考慮成本量化成本優(yōu)化交付的業(yè)務(wù)價(jià)值/（（）（（同時(shí)必須確保團(tuán)隊(duì)獲得高級(jí)管理層的支持。支持者即成本優(yōu)化理念的倡導(dǎo)者，他們會(huì)為此部門(mén)提供升級(jí)支持，確保按組織確定的優(yōu)先級(jí)開(kāi)展成本優(yōu)化活動(dòng)。此部門(mén)及其支持者會(huì)共同確保組織在有效利用云資源并繼續(xù)創(chuàng)造業(yè)務(wù)價(jià)值。成本意識(shí)是指節(jié)約成本和控制成本的觀念，成本管理需要大家共同參與，只有團(tuán)隊(duì)具備了良好的成本意識(shí)，才能建立降低成本的主動(dòng)性，才能讓各種成本優(yōu)化的舉措、方法和要求得以很好的貫徹和執(zhí)行。提高全員的成本意識(shí)是較長(zhǎng)時(shí)期的任務(wù)，我們需要營(yíng)造有利于提高成本意識(shí)的氛圍和推動(dòng)成本意識(shí)的管理?？梢杂腥缦路绞酵苿?dòng)成本意識(shí)文化：所有成本優(yōu)化都是由指標(biāo)驅(qū)動(dòng)的，所有指標(biāo)都需要可實(shí)現(xiàn)的目標(biāo)。數(shù)據(jù)驅(qū)動(dòng)是指將采集的數(shù)據(jù)有效組織，并對(duì)相關(guān)的信息進(jìn)行整合和提煉，在數(shù)據(jù)的基礎(chǔ)上經(jīng)過(guò)訓(xùn)練和擬合形成自動(dòng)化的決策模型。ITCPU/IP需要注意的是：目標(biāo)是可衡量的，能夠驅(qū)動(dòng)團(tuán)隊(duì)采取下一步行動(dòng)的，目標(biāo)會(huì)受多方面的因素影響，明確目標(biāo)之后就是要建立能夠準(zhǔn)確獲取當(dāng)前值與目標(biāo)值的差距的途徑，并能夠持續(xù)的觀察當(dāng)前值的變化，通過(guò)不斷優(yōu)化問(wèn)題，做出正向的反饋，逐步靠近并達(dá)到目標(biāo)值，進(jìn)而制定下一階段的目標(biāo)。具體的落地可以借助云廠商或開(kāi)源社區(qū)提供的各種可觀測(cè)性?xún)x表盤(pán)，目前行業(yè)內(nèi)的儀表盤(pán)的能力能夠覆蓋90%以上的場(chǎng)景，如果需要更精細(xì)化且結(jié)合業(yè)務(wù)的數(shù)據(jù)，則需要企業(yè)自身投入研發(fā)。在新的和現(xiàn)有的組織流程中建立成本意識(shí)，需要在軟件生命周期全過(guò)程中去考慮成本，可以包括以下方案：evFins由于成本優(yōu)化是一項(xiàng)必要的投資，因此量化業(yè)務(wù)價(jià)值之后，您就可以向利益相關(guān)者說(shuō)明投資回報(bào)。如果能夠量化業(yè)務(wù)價(jià)值，在未來(lái)的成本優(yōu)化投資中，就可以從利益相關(guān)者那里得到更多支持，并獲得一個(gè)框架來(lái)衡量組織成本優(yōu)化活動(dòng)的成果。這里有個(gè)單位經(jīng)濟(jì)學(xué)的概念，成本優(yōu)化的最終目標(biāo)是將成本追溯到業(yè)務(wù)收益，這不是在云上花費(fèi)的美元，而是每次預(yù)訂、每可用座位里程、每張機(jī)票、每筆客戶(hù)交易、每百萬(wàn)活躍用戶(hù)所花費(fèi)的美元。如果云成本在6個(gè)月內(nèi)從100萬(wàn)上升到200萬(wàn)是不是很糟糕？100萬(wàn)就是非常 五、總結(jié)資源配置不當(dāng)是引起云原生成本浪費(fèi)的主要原因。Kubernetes成本洞察是定位云原生成本管理問(wèn)題的基礎(chǔ)。一是成本采集及資源追蹤，需要針對(duì)復(fù)雜的云上資源提出統(tǒng)一的成本定量、定價(jià)和采集標(biāo)準(zhǔn)，并對(duì)資源進(jìn)行持續(xù)跟蹤。二是資源使用可視化，基于完善的云原生監(jiān)測(cè)工具建立多維細(xì)粒度的資源利用率觀測(cè)體系。三是費(fèi)用可視化，相比資源利用率企業(yè)運(yùn)營(yíng)更關(guān)注成本，需要建立合理的計(jì)量計(jì)費(fèi)方法，將資源利率可視化轉(zhuǎn)換為費(fèi)用可視化，并延展到費(fèi)用歷史分析、趨勢(shì)預(yù)測(cè)等。四是成本分配，合理的資源標(biāo)簽?zāi)Ｐ褪墙⒖沙掷m(xù)的公平的成本分配方法的關(guān)鍵。五是賬單管理，完備的云賬單體系應(yīng)滿(mǎn)足各部門(mén)精細(xì)化的需求，能摸清各種云產(chǎn)品的支出情況，并能及時(shí)給到部門(mén)或組織反饋。GPUGPUGPUGPU成本運(yùn)營(yíng)是實(shí)現(xiàn)云原生成本持續(xù)優(yōu)化的長(zhǎng)遠(yuǎn)之道。云原生成優(yōu)化并不是成本管理的重點(diǎn)，因?yàn)槌杀緝?yōu)化的成效并不是恒定的，而是需要持續(xù)的迭代和優(yōu)化。所以建立成熟的成運(yùn)營(yíng)體系才是成本管理的治本之法。成本運(yùn)營(yíng)包含五大關(guān)鍵步驟，包括建立成本優(yōu)化團(tuán)隊(duì)、推動(dòng)成本優(yōu)化意識(shí)、數(shù)據(jù)驅(qū)動(dòng)成本優(yōu)化、在流程中考慮成本、量化成本優(yōu)化交付的業(yè)務(wù)價(jià)值。成功的云原生成本管理非一時(shí)之功，需要從組織、文化、流程等多個(gè)方面來(lái)共同推動(dòng)。 六、企業(yè)客戶(hù)降本案例作業(yè)幫2015IT2019TKE。當(dāng)前作業(yè)幫降本增效存在的問(wèn)題PHPGolang能往往有很大10%-20%30%-40%一方面是在線集群波谷空閑了大量計(jì)算資源，另一方面是大數(shù)據(jù)離線計(jì)算需要大量計(jì)算資源。從整個(gè)公司視角來(lái)看，資源使用極不均衡。1-2解決方案SRE關(guān)注KubernetesKubernetes原PHP43%通過(guò)使用fluid，完成檢索服務(wù)計(jì)算和存儲(chǔ)的分離，極大提升了運(yùn)維效率。過(guò)程中對(duì)內(nèi)存基帶的使用進(jìn)行了優(yōu)化，帶來(lái)30%性能提升，節(jié)省萬(wàn)核級(jí)別計(jì)算資源。容器服務(wù)使用統(tǒng)一的集群，常態(tài)在40%左右，在保障業(yè)務(wù)穩(wěn)定的情況下極限可達(dá)60%。機(jī)器利用率大幅度提升。碎片化問(wèn)題也得到徹底解決。容器環(huán)境下集群底層計(jì)算資源使用有限數(shù)量的機(jī)型，做一些機(jī)型更換時(shí)減少了業(yè)務(wù)研發(fā)適配的成本，更換效率大幅度提升。10%QQQQ2005為了滿(mǎn)足業(yè)務(wù)上云需求，及業(yè)務(wù)不斷發(fā)展，質(zhì)量、效率的提升，QQ音樂(lè)上云的需求越來(lái)越迫切。QQIDCbuffer/IDC節(jié)點(diǎn)M（IDCIDC的設(shè)備，每年的裁撤是必然的，對(duì)于服務(wù)來(lái)說(shuō)裁一次傷一次。老舊服務(wù)找不到負(fù)責(zé)人，相關(guān)源碼丟失等問(wèn)題經(jīng)常發(fā)生。每年甚至要花費(fèi)幾個(gè)月的時(shí)間搞裁撤。音樂(lè)目前VM420優(yōu)化方案圖22QQ音樂(lè)降本增效優(yōu)化方案pkg，復(fù)用GitlabTKEPodNodeNodeTKE應(yīng)用效果目前音樂(lè)從TKE版本上線以來(lái)，開(kāi)發(fā)自主遷移了2000+Pod，幾十個(gè)服務(wù)穩(wěn)定運(yùn)行。業(yè)務(wù)擴(kuò)容更加方便及時(shí)，有效應(yīng)對(duì)流量高峰。與此同時(shí)，資源碎片率降低，資源利用率上升。展望未來(lái)BBbilibiliB3282021329B站主站業(yè)務(wù)在IDC機(jī)房，暑假期間業(yè)務(wù)規(guī)?？焖僭鲩L(zhǎng)，IDC服務(wù)器算力不足?；痉桨覆捎没旌显频姆桨?，結(jié)合IDC和騰訊云上資源。優(yōu)先使用線下IDC算力，業(yè)務(wù)高峰期溢出的計(jì)算資源使用騰訊云EKS彈性集群方案，調(diào)度到云上。圖23B站降本增效基本方案典型場(chǎng)景612IDC機(jī)房與PodAMD高計(jì)PodIOPS的SSD24000Pod助更美更美App提供整形、微整形、齒科、眼科、抗衰老等消費(fèi)醫(yī)療服務(wù)。更美App已入駐數(shù)千家正300更美認(rèn)為：云原生，首先定義的是環(huán)境。云——為一切程序運(yùn)行的基本環(huán)境。云原生——原生為云而設(shè)計(jì)，能充分發(fā)揮云平臺(tái)的優(yōu)勢(shì)與特點(diǎn)。DevOps和CICD基于云原生搭建的開(kāi)發(fā)、測(cè)試環(huán)境，使得多功能同時(shí)開(kāi)發(fā)提測(cè)時(shí)，不再受限于測(cè)試環(huán)境的承載性。實(shí)現(xiàn)了近乎無(wú)限數(shù)量的多需求同時(shí)開(kāi)發(fā)和提測(cè)的能力，同時(shí)減少對(duì)一些基礎(chǔ)服務(wù)的多環(huán)境運(yùn)行的依賴(lài)。實(shí)現(xiàn)隨用隨建，用完即銷(xiāo)的模式。大大提高企業(yè)的開(kāi)發(fā)迭代效率，降低測(cè)試環(huán)境搭建、運(yùn)行和維護(hù)的支出。云產(chǎn)生架構(gòu)的實(shí)現(xiàn)，大大提升多環(huán)境的自動(dòng)化能力，基本實(shí)現(xiàn)整個(gè)開(kāi)發(fā)、測(cè)試、生產(chǎn)多發(fā)經(jīng)發(fā)布流程的運(yùn)維無(wú)介入。成本洞察核心痛點(diǎn)成本可以簡(jiǎn)單分為架構(gòu)實(shí)現(xiàn)的資源成本、支持和人力時(shí)間成本。開(kāi)發(fā)任務(wù)緊，多任務(wù)并行開(kāi)發(fā)，同一個(gè)微服務(wù)可能會(huì)有不同的團(tuán)隊(duì)開(kāi)發(fā)不同的需求，會(huì)有多多分支同時(shí)提測(cè)的需求。單一的測(cè)試環(huán)境難以滿(mǎn)，而搭建多套測(cè)試環(huán)境的架構(gòu)成本會(huì)非常的高。3所以，多需求并行開(kāi)發(fā)和并行提測(cè)是之前的開(kāi)發(fā)架構(gòu)中，造成資源成本浪費(fèi)的一個(gè)主要原因。基本方案了滿(mǎn)足開(kāi)發(fā)和測(cè)試團(tuán)隊(duì)的多feature面對(duì)開(kāi)發(fā)人員的困境，嘗試在一套測(cè)試環(huán)境中，將所有底層微服務(wù)的接口都通過(guò)負(fù)載均衡暴露出來(lái)。使得開(kāi)發(fā)人員在開(kāi)發(fā)調(diào)試時(shí)，可以訪問(wèn)到測(cè)試集群中的微服務(wù)接口。但是這也僅僅只能保障一些最底層的服務(wù)接口可以不需要在本地運(yùn)行，其他請(qǐng)求鏈路中間環(huán)境的微服務(wù)，還是都需要在跑服務(wù)才可以。應(yīng)用效果在這套測(cè)試環(huán)境的架構(gòu)形式下，只能基本滿(mǎn)足多分支并行提測(cè)的需求。但是還是有個(gè)別階段，需求或者h(yuǎn)otfix數(shù)量過(guò)多時(shí)，還是出顯現(xiàn)因?yàn)樘釡y(cè)環(huán)境占用導(dǎo)致上線需求排隊(duì)的情況。成本優(yōu)化核心痛點(diǎn)基本方案featureServiceMesh工具IstiobasebaseIstio、IngressGatewayfeature構(gòu)建基于ServiceMesh實(shí)現(xiàn)的流量分發(fā)的多分支測(cè)試環(huán)境。實(shí)現(xiàn)以下功能：基礎(chǔ)環(huán)境同步當(dāng)前線上最新代碼，自動(dòng)觸發(fā)部署。確保base環(huán)境永遠(yuǎn)與生產(chǎn)環(huán)境相同。feature環(huán)境feature各featurefeaturebase環(huán)境。實(shí)現(xiàn)code只需要運(yùn)行一下當(dāng)前開(kāi)發(fā)中服務(wù)的代碼即可。整體的接口測(cè)試，都可以在云端，在自己專(zhuān)屬的獨(dú)立測(cè)試環(huán)境中完成。當(dāng)然我們也通過(guò)一系列的webhook、crontab等工具，來(lái)清理一些沒(méi)有實(shí)際使用的環(huán)境，保障集群資源不浪費(fèi)。成本運(yùn)營(yíng)CICDCICD體系中，所有feature銷(xiāo)售易銷(xiāo)售易是唯一一家連續(xù)五年入選GartnerSFA全球魔力象限的中國(guó)CRM企業(yè)。銷(xiāo)售易認(rèn)為云原生是指業(yè)務(wù)能夠依靠云的能力，如：高性能、高可用、彈性伸縮、即開(kāi)即用等特性，滿(mǎn)足業(yè)務(wù)個(gè)性化需求或快速增長(zhǎng)的特性。廣義上的云原生是指能夠滿(mǎn)足相關(guān)云原生特性的基礎(chǔ)設(shè)施和相關(guān)技術(shù)規(guī)范；狹義上的云原生是指云廠商提供的云相關(guān)基礎(chǔ)設(shè)施或產(chǎn)品能力（云廠商在這方面有天然優(yōu)勢(shì)，另外大多數(shù)企業(yè)也逐漸習(xí)慣使用云產(chǎn)品）云原生的技術(shù)思想對(duì)企業(yè)信息化建設(shè)有很大幫助，首先云原生可以在很大程度上幫助企業(yè)，降低在某些技術(shù)方向的研發(fā)成本，通過(guò)現(xiàn)有的、成熟的、面向未來(lái)化的云原生方案，能夠讓企業(yè)信息化走的更穩(wěn)健。（總的來(lái)說(shuō)，云原生可以為企業(yè)帶來(lái)效率上的提升和降低信息化建設(shè)成本。成本洞察核心痛點(diǎn)基本方案企業(yè)銷(xiāo)售云、平臺(tái)等產(chǎn)品線，所包含的資源可清晰的進(jìn)行匯總。成本優(yōu)化核心痛點(diǎn)應(yīng)用效果企業(yè)可以根據(jù)業(yè)務(wù)線、項(xiàng)目、環(huán)境等維度對(duì)資源成本進(jìn)行核算，并能及時(shí)了解到相對(duì)空閑的資源，進(jìn)行資源合并或回收。成本運(yùn)營(yíng)核心痛點(diǎn)項(xiàng)目上線運(yùn)營(yíng)后，項(xiàng)目年收入和成本如何核算?基本架構(gòu)方案通過(guò)對(duì)項(xiàng)目的資源標(biāo)簽，來(lái)對(duì)資源成本進(jìn)行匯總。應(yīng)用效果企業(yè)CDP業(yè)務(wù)已經(jīng)上線運(yùn)營(yíng)了2年，每年或每季度都可以對(duì)資源的消耗情況進(jìn)行清晰統(tǒng)計(jì)。云原生是一種技術(shù)形態(tài)，也是一種技術(shù)思想。企業(yè)引入云原生會(huì)對(duì)研發(fā)效率、系統(tǒng)穩(wěn)定性、成本管理等