本篇內(nèi)容主要講解“kubernetes如何提升資源利用率”，感興趣的朋友不妨來看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“kubernetes如何提升資源利用率”吧!
創(chuàng)新互聯(lián)公司專注于企業(yè)營(yíng)銷型網(wǎng)站建設(shè)、網(wǎng)站重做改版、共青城網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5場(chǎng)景定制、電子商務(wù)商城網(wǎng)站建設(shè)、集團(tuán)公司官網(wǎng)建設(shè)、外貿(mào)營(yíng)銷網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性價(jià)比高，為共青城等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。
公有云的發(fā)展為業(yè)務(wù)的穩(wěn)定性、可拓展性、便利性帶來了極大幫助。這種用租代替買、并且提供完善的技術(shù)支持和保障的服務(wù)，理應(yīng)為業(yè)務(wù)帶來降本增效的效果。但實(shí)際上業(yè)務(wù)上云并不意味著成本一定較少，還需適配云上業(yè)務(wù)的應(yīng)用開發(fā)、架構(gòu)設(shè)計(jì)、管理運(yùn)維、合理使用等多方面解決方案，才能真正助力業(yè)務(wù)的降本增效。在《Kubernetes 降本增效標(biāo)準(zhǔn)指南》系列 的上一篇文章《容器化計(jì)算資源利用率現(xiàn)象剖析》中可看到，IDC 上云后資源利用率提高有限，即使已經(jīng)容器化，節(jié)點(diǎn)的平均利用率依舊僅在 13% 左右，資源利用率的提升任重道遠(yuǎn)。
本篇文章將帶你了解： 為什么 Kubernetes 集群中的 CPU 和內(nèi)存資源利用率通常都如此之低？ 現(xiàn)階段在 TKE 上面有哪些產(chǎn)品化的方法可以輕松提升資源利用率？
為何資源利用率通常都如此之低？首先可以看看幾個(gè)業(yè)務(wù)的實(shí)際使用資源場(chǎng)景：
Kubernetes 中的 Request(請(qǐng)求) 字段用于管理容器對(duì) CPU 和內(nèi)存資源預(yù)留的機(jī)制，保證容器至少可以達(dá)到的資源量，該部分資源不能被其他容器搶占，具體可查看。當(dāng) Request 設(shè)置過小，無法保證業(yè)務(wù)的資源量，當(dāng)業(yè)務(wù)的負(fù)載變高時(shí)無力承載，因此用戶通常習(xí)慣將 Request 設(shè)置得很高，以保證服務(wù)的可靠性。但實(shí)際上，業(yè)務(wù)在大多數(shù)時(shí)段時(shí)負(fù)載不會(huì)很高。以 CPU 為例，下圖是某個(gè)實(shí)際業(yè)務(wù)場(chǎng)景下容器的資源預(yù)留（Request）和實(shí)際使用量（CPU_Usage）關(guān)系圖：資源預(yù)留遠(yuǎn)大于實(shí)際使用量，兩者之間差值所對(duì)應(yīng)的資源不能被其他負(fù)載使用，因此 Request 設(shè)置過大勢(shì)必會(huì)造成較大的資源浪費(fèi)。 
如何解決這樣的問題？現(xiàn)階段需要用戶自己根據(jù)實(shí)際的負(fù)載情況設(shè)置更合理的 Request、以及限制業(yè)務(wù)對(duì)資源的無限請(qǐng)求，防止資源被某些業(yè)務(wù)過度占用。這里可以參考后文中的 Request Quota 和 Limit Ranges 的設(shè)置。 此外，TKE 將推出 Request 推薦產(chǎn)品，幫助用戶智能縮小 Request 和 Usage 之間的差值，在保障業(yè)務(wù)的穩(wěn)定性的情況下有效提升資源利用率。
大多數(shù)業(yè)務(wù)存在波峰波谷，例如公交系統(tǒng)通常在白天負(fù)載增加，夜晚負(fù)載減少；游戲業(yè)務(wù)通常在周五晚上開始出現(xiàn)波峰，在周日晚開始出現(xiàn)波谷。如下圖所示：同一業(yè)務(wù)在不同的時(shí)間段對(duì)資源的請(qǐng)求量不同，如果用戶設(shè)置的是固定的 Request，f在負(fù)載較低時(shí)利用率很低。 
這時(shí)可以通過動(dòng)態(tài)調(diào)整副本數(shù)以高資源利用率承載業(yè)務(wù)的波峰波谷，可以參考后文中的 HPA 、HPC、CA。
在線業(yè)務(wù)通常白天負(fù)載較高，對(duì)時(shí)延要求較高，必須優(yōu)先調(diào)度和運(yùn)行；而離線的計(jì)算型業(yè)務(wù)通常對(duì)運(yùn)行時(shí)段和時(shí)延要求相對(duì)較低，理論上可以在在線業(yè)務(wù)波谷時(shí)運(yùn)行。此外，有些業(yè)務(wù)屬于計(jì)算密集型，對(duì) CPU 資源消耗較多，而有些業(yè)務(wù)屬于內(nèi)存密集型，對(duì)內(nèi)存消耗較多。
如上圖所示，通過在離線混部可以動(dòng)態(tài)調(diào)度離線業(yè)務(wù)和在線業(yè)務(wù)，讓不同類型業(yè)務(wù)在不同的時(shí)間段運(yùn)行以提升資源利用率。對(duì)于計(jì)算密集型業(yè)務(wù)和內(nèi)存密集型業(yè)務(wù)，可以使用親和性調(diào)度，為業(yè)務(wù)分配更合適的節(jié)點(diǎn)，有效提升資源利用率。具體方式可參考后文中的離在線混部和親和性調(diào)度。
騰訊云容器服務(wù) TKE 基于大量的用戶實(shí)際業(yè)務(wù)，已經(jīng)產(chǎn)品化了一系列工具，幫助用戶輕松有效的提升資源利用率。主要從兩方面著手：一是利用原生的 Kubernetes 能力手動(dòng)進(jìn)行資源的劃分和限制；二是結(jié)合業(yè)務(wù)特性的自動(dòng)化方案。 
設(shè)想，你是個(gè)集群管理員，現(xiàn)在有4個(gè)業(yè)務(wù)部門使用同一個(gè)集群，你的責(zé)任是保證業(yè)務(wù)穩(wěn)定性的前提下，讓業(yè)務(wù)真正做到資源的按需使用。為了有效提升集群整體的資源利用率，這時(shí)就需要限制各業(yè)務(wù)使用資源的上限，以及通過一些默認(rèn)值防止業(yè)務(wù)過量使用。
理想情況下，業(yè)務(wù)應(yīng)該根據(jù)實(shí)際情況，設(shè)置合理的 Request 和 Limit。（Request 用于對(duì)資源的占位，表示容器至少可以獲得的資源；Limit 用于對(duì)資源的限制，表示容器至多可以獲得的資源。）這樣更利于容器的健康運(yùn)行、資源的充分使用。但實(shí)際上用戶經(jīng)常忘記設(shè)置容器對(duì)資源的 Request 和 Limit。此外，對(duì)于共享使用一個(gè)集群的團(tuán)隊(duì)/項(xiàng)目來說，他們通常都將自己容器的 Request 和 Limit 設(shè)置得很高以保證自己服務(wù)的穩(wěn)定性。如果你使用的是 TKE 的控制臺(tái)，創(chuàng)建負(fù)載時(shí)會(huì)給所有的容器設(shè)置如下默認(rèn)值。該默認(rèn)值是 TKE 根據(jù)真實(shí)業(yè)務(wù)分析預(yù)估得出，和具體的業(yè)務(wù)需求之間可能存在偏差。
| Request | Limit | |
|---|---|---|
| CPU(核) | 0.25 | 0.5 |
| Memory(MiB) | 256 | 1024 |
為了更細(xì)粒度的劃分和管理資源，可以在 TKE 上設(shè)置命名空間級(jí)別的 Resource Quota 以及 Limit Ranges。
如果你管理的某個(gè)集群有4個(gè)業(yè)務(wù)，為了實(shí)現(xiàn)業(yè)務(wù)間的隔離和資源的限制，你可以使用命名空間和 Resource Quota
Resource Quota 用于設(shè)置命名空間資源的使用配額，命名空間是 Kubernetes 集群里面的一個(gè)隔離分區(qū)，一個(gè)集群里面通常包含多個(gè)命名空間，例如 Kubernetes 用戶通常會(huì)將不同的業(yè)務(wù)放在不同的命名空間里，你可以為不同的命名空間設(shè)置不同的 Resource Quota，以限制一個(gè)命名空間對(duì)集群整體資源的使用量，達(dá)到預(yù)分配和限制的效果。Resource Quota 主要作用于如下方面，具體可查看。
計(jì)算資源：所有容器對(duì) CPU 和 內(nèi)存的 Request 以及 Limit 的總和
存儲(chǔ)資源：所有 PVC 的存儲(chǔ)資源請(qǐng)求總和
對(duì)象數(shù)量：PVC/Service/Configmap/Deployment等資源對(duì)象數(shù)量的總和
給不同的項(xiàng)目/團(tuán)隊(duì)/業(yè)務(wù)分配不同的命名空間，通過設(shè)置每個(gè)命名空間資源的 Resource Quota 以達(dá)到資源分配的目的
設(shè)置一個(gè)命名空間的資源使用數(shù)量的上限以提高集群的穩(wěn)定性，防止一個(gè)命名空間對(duì)資源的多度侵占和消耗
TKE 上已經(jīng)實(shí)現(xiàn)對(duì) Resource Quota 的產(chǎn)品化，你可以直接在控制臺(tái)利用 Resource Quota 限制一個(gè)命名空間的資源使用量，具體可參考文檔。 
用戶經(jīng)常忘記設(shè)置資源的 Request 和 Limit，或者將值設(shè)置得很大怎么辦？作為管理員，如果可以為不同的業(yè)務(wù)設(shè)置不同資源使用默認(rèn)值以及范圍，可以有效減少業(yè)務(wù)創(chuàng)建時(shí)的工作量同時(shí)，限制業(yè)務(wù)對(duì)資源的過度侵占。
與 Resource Quota 對(duì)命名空間整體的資源限制不同，Limit Ranges 適用于一個(gè)命名空間下的單個(gè)容器?？梢苑乐褂脩粼诿臻g內(nèi)創(chuàng)建對(duì)資源申請(qǐng)過小或過大容器，防止用戶忘記設(shè)置容器的 Request 和 Limit。Limit Ranges 主要作用于如下方面，具體可查看。
計(jì)算資源：對(duì)所有容器設(shè)置 CPU 和內(nèi)存使用量的范圍
存儲(chǔ)資源：對(duì)所有 PVC 能申請(qǐng)的存儲(chǔ)空間的范圍
比例設(shè)置：控制一種資源 Request 和 Limit 之間比例
默認(rèn)值：對(duì)所有容器設(shè)置默認(rèn)的 Request/Limit，如果容器未指定自己的內(nèi)存請(qǐng)求和限制，將為它指定默認(rèn)的內(nèi)存請(qǐng)求和限制
設(shè)置資源使用默認(rèn)值，以防用戶遺忘，也可以避免 QoS 驅(qū)逐重要的 Pod
不同的業(yè)務(wù)通常運(yùn)行在不同的命名空間里，不同的業(yè)務(wù)通常資源使用情況不同，為不同的命名空間設(shè)置不同的 Request/Limit 可以提升資源利用率
限制容器個(gè)對(duì)資源使用的上下限，保證容器正常運(yùn)行的情況下，限制其請(qǐng)求過多資源
TKE 上已經(jīng)實(shí)現(xiàn)對(duì) Limit Ranges 的產(chǎn)品化，你可以直接在控制臺(tái)管理命名空間的 Limit Ranges，具體可參考文檔。 
上面提到的利用 Resource Quota 和 Limit Ranges 來分配和限制資源的方法依賴經(jīng)驗(yàn)和手工，主要解決的是資源請(qǐng)求和分配不合理。如何更自動(dòng)化的動(dòng)態(tài)調(diào)整以提升資源利用率是用戶更關(guān)心的問題，接下來從彈性伸縮、調(diào)度、在離線混部三大產(chǎn)品化的方向，詳述如何提升資源利用率。
如上面資源浪費(fèi)場(chǎng)景2所說，如果你的業(yè)務(wù)是存在波峰波谷的，固定的資源 Request 注定在波谷時(shí)會(huì)造成資源浪費(fèi)，針對(duì)這樣的場(chǎng)景，如果波峰的時(shí)候可以自動(dòng)增加業(yè)務(wù)負(fù)載的副本數(shù)量，波谷的時(shí)候可以自動(dòng)減少業(yè)務(wù)負(fù)載的副本數(shù)量，將有效提升資源整體利用率。
HPA（Horizontal Pod Autoscaler）可以基于一些指標(biāo)（例如 CPU、內(nèi)存的利用率）自動(dòng)擴(kuò)縮 Deployment 和 StatefulSet 中的 Pod 副本的數(shù)量，達(dá)到工作負(fù)載穩(wěn)定的目的，真正做到按需使用。
流量突發(fā)：突然流量增加，負(fù)載過載時(shí)會(huì)自動(dòng)增加 Pod 數(shù)量以及時(shí)響應(yīng)
自動(dòng)縮容：流量較少時(shí)，負(fù)載對(duì)資源的利用率過低時(shí)會(huì)自動(dòng)減少 Pod 的數(shù)量以避免浪費(fèi)
TKE 基于 Custom Metrics API 支持許多用于彈性伸縮的指標(biāo)，涵蓋 CPU、內(nèi)存、硬盤、網(wǎng)絡(luò)以及 GPU 相關(guān)的指標(biāo)，覆蓋絕大多數(shù)的 HPA 彈性伸縮場(chǎng)景，詳細(xì)列表請(qǐng)參見 自動(dòng)伸縮指標(biāo)說明。此外，針對(duì)例如基于業(yè)務(wù)單副本 QPS 大小來進(jìn)行自動(dòng)擴(kuò)縮容等復(fù)雜場(chǎng)景，可通過安裝 prometheus-adapter 來實(shí)現(xiàn)自動(dòng)擴(kuò)縮容，具體可參考文檔。 
假設(shè)你的業(yè)務(wù)是電商平臺(tái)，雙十一要進(jìn)行促銷活動(dòng)，這時(shí)可以考慮使用 HPA 自動(dòng)擴(kuò)縮容。但是 HPA 需要先監(jiān)控各項(xiàng)指標(biāo)后，再進(jìn)行反應(yīng)，可能擴(kuò)容速度不夠快，無法及時(shí)承載高流量。針對(duì)這種有預(yù)期的流量暴增，如果能提前發(fā)生副本擴(kuò)容，將有效承載流量井噴。 HPC（HorizontalPodCronscaler）是 TKE 自研組件，旨在定時(shí)控制副本數(shù)量，以達(dá)到提前擴(kuò)縮容、和提前觸發(fā)動(dòng)態(tài)擴(kuò)容時(shí)資源不足的影響，相較社區(qū)的 CronHPA，額外支持：
與 HPA 結(jié)合：可以實(shí)現(xiàn)定時(shí)開啟和關(guān)閉 HPA，讓你的業(yè)務(wù)在高峰時(shí)更彈性
例外日期設(shè)置：業(yè)務(wù)的流量不太可能永遠(yuǎn)都是規(guī)律的，設(shè)置例外日期可以減少手工調(diào)整 HPC
單次執(zhí)行：以往的 CronHPA 都是永久執(zhí)行，類似 Cronjob，單次執(zhí)行可以更靈活的應(yīng)對(duì)大促場(chǎng)景
以游戲服務(wù)為例，從周五晚上到周日晚上，游戲玩家數(shù)量暴增。如果可以將游戲服務(wù)器在星期五晚上前擴(kuò)大規(guī)模，并在星期日晚上后縮放為原始規(guī)模，則可以為玩家提供更好的體驗(yàn)。如果使用 HPA，可能因?yàn)閿U(kuò)容速度不夠快導(dǎo)致服務(wù)受影響。
TKE 上已經(jīng)實(shí)現(xiàn)對(duì) HPC 的產(chǎn)品化，但你需要提前在”組件管理“里面安裝 HPC，HPC 使用 CronTab 語法格式。
安裝： 
使用： 
上面提到的 HPA 和 HPC，都是在業(yè)務(wù)負(fù)載層面的自動(dòng)擴(kuò)縮副本數(shù)量，以靈活應(yīng)對(duì)流量的波峰波谷，提升資源利用率。但是對(duì)于集群整體而言，資源總數(shù)是固定的，HPA 和 HPC 只是讓集群有更多空余的資源，是否有一種方法，能在集群整體較“空”時(shí)回收部分資源，能在集群整體較“滿”時(shí)擴(kuò)充集群整體資源？因?yàn)榧赫w資源的使用量直接決定了賬單費(fèi)用，這種集群級(jí)別的彈性擴(kuò)縮將真正幫助你節(jié)省使用成本。
CA（Cluster Autoscaler）用于自動(dòng)擴(kuò)縮集群節(jié)點(diǎn)數(shù)量，以真正實(shí)現(xiàn)資源利用率的提升，并直接作用于用戶的費(fèi)用，是降本增效的關(guān)鍵。
在業(yè)務(wù)波峰時(shí)，根據(jù)業(yè)務(wù)突增的負(fù)載擴(kuò)容合適的節(jié)點(diǎn)
在業(yè)務(wù)波谷時(shí)，根據(jù)資源的空閑情況釋放多余的節(jié)點(diǎn)
TKE 上的 CA 是以節(jié)點(diǎn)池的形態(tài)來讓用戶使用的，CA 推薦和 HPA 一起使用：HPA 負(fù)責(zé)應(yīng)用層的擴(kuò)縮容，CA 負(fù)責(zé)資源層（節(jié)點(diǎn)層）的擴(kuò)縮容，當(dāng) HPA 擴(kuò)容造成集群整體資源不足時(shí)，會(huì)引發(fā) Pod 的 Pending，Pod Pending 會(huì)觸發(fā) CA 擴(kuò)充節(jié)點(diǎn)池以增加集群整體資源量，整體擴(kuò)容邏輯可參考下圖：
具體的參數(shù)配置方式以及應(yīng)用場(chǎng)景可參考《像管理 Pod 一樣管理 Node》，或者可參考騰訊云容器服務(wù)官方文檔。
Kubernetes 調(diào)度機(jī)制是 Kubernetes 原生提供的一種高效優(yōu)雅的資源分配機(jī)制，它的核心功能是為每個(gè) Pod 找到最適合它的節(jié)點(diǎn)，在 TKE 場(chǎng)景下，調(diào)度機(jī)制幫助實(shí)現(xiàn)了應(yīng)用層彈性伸縮到資源層彈性伸縮的過渡。通過合理利用 Kubernetes 提供的調(diào)度能力，根據(jù)業(yè)務(wù)特性配置合理的調(diào)度策略，也能有效提高集群中的資源利用率。
倘若你的某個(gè)業(yè)務(wù)是 CPU 密集型，不小心被 Kubernetes 的調(diào)度器調(diào)度到內(nèi)存密集型的節(jié)點(diǎn)上，導(dǎo)致內(nèi)存密集型的 CPU 被占滿，但內(nèi)存幾乎沒怎么用，會(huì)造成較大的資源浪費(fèi)。如果你能為節(jié)點(diǎn)設(shè)置一個(gè)標(biāo)記，表明這是一個(gè) CPU 密集型的節(jié)點(diǎn)，然后在創(chuàng)建業(yè)務(wù)負(fù)載時(shí)也設(shè)置一個(gè)標(biāo)記，表明這個(gè)負(fù)載是一個(gè) CPU 密集型的負(fù)載，Kubernetes 的調(diào)度器會(huì)將這個(gè)負(fù)載調(diào)度到 CPU 密集型的節(jié)點(diǎn)上，這種尋找最合適的節(jié)點(diǎn)的方式，將有效提升資源利用率。
創(chuàng)建 Pod 時(shí)，可以設(shè)置節(jié)點(diǎn)親和性，即指定 Pod 想要調(diào)度到哪些節(jié)點(diǎn)上（這些節(jié)點(diǎn)是通過 K8s Label）來指定的。
節(jié)點(diǎn)親和性非常適合在一個(gè)集群中有不同資源需求的工作負(fù)載同時(shí)運(yùn)行的場(chǎng)景。比如說，騰訊云的 CVM（節(jié)點(diǎn)） 有 CPU 密集型的機(jī)器，也有內(nèi)存密集型的機(jī)器。如果某些業(yè)務(wù)對(duì) CPU 的需求遠(yuǎn)大于內(nèi)存，此時(shí)使用普通的 CVM 機(jī)器，勢(shì)必會(huì)對(duì)內(nèi)存造成較大浪費(fèi)。此時(shí)可以在集群里添加一批 CPU 密集型的 CVM，并且把這些對(duì) CPU 有較高需求的 Pod 調(diào)度到這些 CVM 上，這樣可以提升 CVM 資源的整體利用率。同理，還可以在集群中管理異構(gòu)節(jié)點(diǎn)（比如 GPU 機(jī)器），在需要 GPU 資源的工作負(fù)載中指定需要GPU資源的量，調(diào)度機(jī)制則會(huì)幫助你尋找合適的節(jié)點(diǎn)去運(yùn)行這些工作負(fù)載。
TKE 提供與原生 Kubernetes 完全一致的親和性使用方式，你可通過控制臺(tái)或配置 YAML 的方式使用此項(xiàng)功能，具體可參考。
原生的 Kubernetes 調(diào)度策略傾向于調(diào)度pod到節(jié)點(diǎn)剩余資源較多的節(jié)點(diǎn)上， 比如默認(rèn)的 LeastRequestedPriority 策略。但是原生調(diào)度策略存在一個(gè)問題：這樣的資源分配是靜態(tài)的，Request 不能代表資源真實(shí)使用情況，因此一定會(huì)存在一定程度的浪費(fèi)。因此，如果調(diào)度器可以基于節(jié)點(diǎn)的實(shí)際資源利用率進(jìn)行調(diào)度，將一定程度上解決資源浪費(fèi)的問題。
TKE 自研的動(dòng)態(tài)調(diào)度器所做的就是這樣的工作。動(dòng)態(tài)調(diào)度器的核心原理如下： 
除了降低資源浪費(fèi)，動(dòng)態(tài)調(diào)度器還可以很好的緩解集群調(diào)度熱點(diǎn)的問題。
動(dòng)態(tài)調(diào)度器會(huì)統(tǒng)計(jì)過去一段時(shí)間調(diào)度到節(jié)點(diǎn)的 Pod 數(shù)目，避免往同一節(jié)點(diǎn)上調(diào)度過多的 Pod
動(dòng)態(tài)調(diào)度器支持設(shè)置節(jié)點(diǎn)負(fù)載閾值，在調(diào)度階段過濾掉超過閾值的節(jié)點(diǎn)。
你可以在擴(kuò)展組件里面安裝和使用動(dòng)態(tài)調(diào)度器： 
更多關(guān)于動(dòng)態(tài)調(diào)度器的使用指南，可以參考 《TKE 重磅推出全鏈路調(diào)度解決方案》 和官方文檔。
如果你既有在線 Web 服務(wù)業(yè)務(wù)，又有離線的計(jì)算服務(wù)業(yè)務(wù)，借助 TKE 的在離線業(yè)務(wù)混部技術(shù)可以動(dòng)態(tài)調(diào)度和運(yùn)行不同的業(yè)務(wù)，提升資源利用率。
在傳統(tǒng)架構(gòu)中，大數(shù)據(jù)業(yè)務(wù)和在線業(yè)務(wù)往往部署在不同的資源集群中，這兩部分業(yè)務(wù)相互獨(dú)立。但大數(shù)據(jù)業(yè)務(wù)一般更多的是離線計(jì)算類業(yè)務(wù)，在夜間處于業(yè)務(wù)高峰，而在線業(yè)務(wù)恰恰相反夜間常常處于空載狀態(tài)。云原生技術(shù)借助容器完整(CPU，內(nèi)存，磁盤IO，網(wǎng)絡(luò)IO等)的隔離能力，及 Kubernetes 強(qiáng)大的編排調(diào)度能力，實(shí)現(xiàn)在線和離線業(yè)務(wù)混合部署，從而使在離線業(yè)務(wù)充分利用在線業(yè)務(wù)空閑時(shí)段的資源，以提高資源利用率。
在 Hadoop 架構(gòu)下，離線作業(yè)和在線作業(yè)往往分屬不同的集群，然而在線業(yè)務(wù)、流式作業(yè)具有明顯的波峰波谷特性，在波谷時(shí)段，會(huì)有大量的資源處于閑置狀態(tài)，造成資源的浪費(fèi)和成本的提升。在離線混部集群，通過動(dòng)態(tài)調(diào)度削峰填谷，當(dāng)在線集群的使用率處于波谷時(shí)段，將離線任務(wù)調(diào)度到在線集群，可以顯著的提高資源的利用率。然而，Hadoop Yarn 目前只能通過 NodeManager 上報(bào)的靜態(tài)資源情況進(jìn)行分配，無法基于動(dòng)態(tài)資源調(diào)度，無法很好的支持在線、離線業(yè)務(wù)混部的場(chǎng)景。
在線業(yè)務(wù)具有明顯的波峰浪谷特征，而且規(guī)律比較明顯，尤其是在夜間，資源利用率比較低，這時(shí)候大數(shù)據(jù)管控平臺(tái)向 Kubernetes 集群下發(fā)創(chuàng)建資源的請(qǐng)求，可以提高大數(shù)據(jù)應(yīng)用的算力，具體可參考。
在企業(yè)的運(yùn)維工作中，除了成本，系統(tǒng)的穩(wěn)定性也是十分重要的指標(biāo)。如何在兩者間達(dá)到平衡，可能是很多運(yùn)維人員心中的“痛點(diǎn)”。一方面，為了降低成本，資源利用率當(dāng)然是越高越好，但是資源利用率達(dá)到一定水位后，負(fù)載過高極有可能導(dǎo)致業(yè)務(wù) OOM 或 CPU 抖動(dòng)等問題。 為了減小企業(yè)成本控制之路上的顧慮，TKE 還提供了“兜底神器“ - 重調(diào)度器來保障集群負(fù)載水位在可控范圍內(nèi)。 重調(diào)度器是動(dòng)態(tài)調(diào)度器是一對(duì)好搭檔（它們的關(guān)系可以參考下圖），就像它的名字一樣，它主要負(fù)責(zé)“保護(hù)”節(jié)點(diǎn)中已經(jīng)負(fù)載比較“危險(xiǎn)”的節(jié)點(diǎn)， 優(yōu)雅驅(qū)逐這些節(jié)點(diǎn)上的業(yè)務(wù)。 
可以在擴(kuò)展組件里面安裝和使用重調(diào)度器： 
到此，相信大家對(duì)“kubernetes如何提升資源利用率”有了更深的了解，不妨來實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！
重慶分公司
重慶分公司
