kubernetes如何提升資源利用率

本篇內容主要講解“kubernetes如何提升資源利用率”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“kubernetes如何提升資源利用率”吧!

背景

公有云的發(fā)展為業(yè)務的穩(wěn)定性、可拓展性、便利性帶來了極大幫助。這種用租代替買、并且提供完善的技術支持和保障的服務，理應為業(yè)務帶來降本增效的效果。但實際上業(yè)務上云并不意味著成本一定較少，還需適配云上業(yè)務的應用開發(fā)、架構設計、管理運維、合理使用等多方面解決方案，才能真正助力業(yè)務的降本增效。在《Kubernetes 降本增效標準指南》系列 的上一篇文章《容器化計算資源利用率現象剖析》中可看到，IDC 上云后資源利用率提高有限，即使已經容器化，節(jié)點的平均利用率依舊僅在 13% 左右，資源利用率的提升任重道遠。

本篇文章將帶你了解： 為什么 Kubernetes 集群中的 CPU 和內存資源利用率 通常都如此之低？ 現階段在 TKE 上面有哪些產品化的方法可以輕松提升資源利用率？

資源浪費場景

為何資源利用率通常都如此之低？首先可以看看幾個業(yè)務的實際使用資源場景：

1. 資源預留普遍存在 50% 以上的浪費

Kubernetes 中的 Request(請求) 字段用于管理容器對 CPU 和內存資源預留的機制，保證容器至少可以達到的資源量，該部分資源不能被其他容器搶占，具體可查看。當 Request 設置過小，無法保證業(yè)務的資源量，當業(yè)務的負載變高時無力承載，因此用戶通常習慣將 Request 設置得很高，以保證服務的可靠性。但實際上，業(yè)務在大多數時段時負載不會很高。以 CPU 為例，下圖是某個實際業(yè)務場景下容器的資源預留（Request）和實際使用量（CPU_Usage）關系圖：資源預留遠大于實際使用量，兩者之間差值所對應的資源不能被其他負載使用，因此 Request 設置過大勢必會造成較大的資源浪費。

如何解決這樣的問題？現階段需要用戶自己根據實際的負載情況設置更合理的 Request、以及限制業(yè)務對資源的無限請求，防止資源被某些業(yè)務過度占用。這里可以參考后文中的 Request Quota 和 Limit Ranges 的設置。 此外，TKE 將推出 Request 推薦產品，幫助用戶智能縮小 Request 和 Usage 之間的差值，在保障業(yè)務的穩(wěn)定性的情況下有效提升資源利用率。

2. 業(yè)務資源波峰波谷現象普遍，通常波谷時間大于波峰時間，資源浪費明顯

大多數業(yè)務存在波峰波谷，例如公交系統通常在白天負載增加，夜晚負載減少；游戲業(yè)務通常在周五晚上開始出現波峰，在周日晚開始出現波谷。如下圖所示：同一業(yè)務在不同的時間段對資源的請求量不同，如果用戶設置的是固定的 Request，f在負載較低時利用率很低。

這時可以通過動態(tài)調整副本數以高資源利用率承載業(yè)務的波峰波谷，可以參考后文中的 HPA 、HPC、CA。

3. 不同類型的業(yè)務，導致資源利用率有較大差異

在線業(yè)務通常白天負載較高，對時延要求較高，必須優(yōu)先調度和運行；而離線的計算型業(yè)務通常對運行時段和時延要求相對較低，理論上可以在在線業(yè)務波谷時運行。此外，有些業(yè)務屬于計算密集型，對 CPU 資源消耗較多，而有些業(yè)務屬于內存密集型，對內存消耗較多。

如上圖所示，通過在離線混部可以動態(tài)調度離線業(yè)務和在線業(yè)務，讓不同類型業(yè)務在不同的時間段運行以提升資源利用率。對于計算密集型業(yè)務和內存密集型業(yè)務，可以使用親和性調度，為業(yè)務分配更合適的節(jié)點，有效提升資源利用率。具體方式可參考后文中的離在線混部和親和性調度。

在 Kubernetes 上提升資源利用率的方法

騰訊云容器服務 TKE 基于大量的用戶實際業(yè)務，已經產品化了一系列工具，幫助用戶輕松有效的提升資源利用率。主要從兩方面著手：一是利用原生的 Kubernetes 能力手動進行資源的劃分和限制；二是結合業(yè)務特性的自動化方案。

1. 如何資源劃分和限制

設想，你是個集群管理員，現在有4個業(yè)務部門使用同一個集群，你的責任是保證業(yè)務穩(wěn)定性的前提下，讓業(yè)務真正做到資源的按需使用。為了有效提升集群整體的資源利用率，這時就需要限制各業(yè)務使用資源的上限，以及通過一些默認值防止業(yè)務過量使用。

理想情況下，業(yè)務應該根據實際情況，設置合理的 Request 和 Limit。（Request 用于對資源的占位，表示容器至少可以獲得的資源；Limit 用于對資源的限制，表示容器至多可以獲得的資源。）這樣更利于容器的健康運行、資源的充分使用。但實際上用戶經常忘記設置容器對資源的 Request 和 Limit。此外，對于共享使用一個集群的團隊/項目來說，他們通常都將自己容器的 Request 和 Limit 設置得很高以保證自己服務的穩(wěn)定性。如果你使用的是 TKE 的控制臺，創(chuàng)建負載時會給所有的容器設置如下默認值。該默認值是 TKE 根據真實業(yè)務分析預估得出，和具體的業(yè)務需求之間可能存在偏差。

為了更細粒度的劃分和管理資源，可以在 TKE 上設置命名空間級別的 Resource Quota 以及 Limit Ranges。

1.1 使用 Resource Quota 劃分資源

如果你管理的某個集群有4個業(yè)務，為了實現業(yè)務間的隔離和資源的限制，你可以使用命名空間和 Resource Quota

Resource Quota 用于設置命名空間資源的使用配額，命名空間是 Kubernetes 集群里面的一個隔離分區(qū)，一個集群里面通常包含多個命名空間，例如 Kubernetes 用戶通常會將不同的業(yè)務放在不同的命名空間里，你可以為不同的命名空間設置不同的 Resource Quota，以限制一個命名空間對集群整體資源的使用量，達到預分配和限制的效果。Resource Quota 主要作用于如下方面，具體可查看。

1. 計算資源：所有容器對 CPU 和 內存的 Request 以及 Limit 的總和

2. 存儲資源：所有 PVC 的存儲資源請求總和

3. 對象數量：PVC/Service/Configmap/Deployment等資源對象數量的總和

Resource Quota 使用場景

• 給不同的項目/團隊/業(yè)務分配不同的命名空間，通過設置每個命名空間資源的 Resource Quota 以達到資源分配的目的

• 設置一個命名空間的資源使用數量的上限以提高集群的穩(wěn)定性，防止一個命名空間對資源的多度侵占和消耗

TKE 上的 Resource Quota

TKE 上已經實現對 Resource Quota 的產品化，你可以直接在控制臺利用 Resource Quota 限制一個命名空間的資源使用量，具體可參考文檔。

1.2 使用 Limit Ranges 限制資源

用戶經常忘記設置資源的 Request 和 Limit，或者將值設置得很大怎么辦？作為管理員，如果可以為不同的業(yè)務設置不同資源使用默認值以及范圍，可以有效減少業(yè)務創(chuàng)建時的工作量同時，限制業(yè)務對資源的過度侵占。

與 Resource Quota 對命名空間整體的資源限制不同，Limit Ranges 適用于一個命名空間下的單個容器。可以防止用戶在命名空間內創(chuàng)建對資源申請過小或過大容器，防止用戶忘記設置容器的 Request 和 Limit。Limit Ranges 主要作用于如下方面，具體可查看。

1. 計算資源：對所有容器設置 CPU 和內存使用量的范圍

2. 存儲資源：對所有 PVC 能申請的存儲空間的范圍

3. 比例設置：控制一種資源 Request 和 Limit 之間比例

4. 默認值：對所有容器設置默認的 Request/Limit，如果容器未指定自己的內存請求和限制，將為它指定默認的內存請求和限制

Limit Ranges 使用場景

1. 設置資源使用默認值，以防用戶遺忘，也可以避免 QoS 驅逐重要的 Pod

2. 不同的業(yè)務通常運行在不同的命名空間里，不同的業(yè)務通常資源使用情況不同，為不同的命名空間設置不同的 Request/Limit 可以提升資源利用率

3. 限制容器個對資源使用的上下限，保證容器正常運行的情況下，限制其請求過多資源

TKE 上的 Limit Ranges

TKE 上已經實現對 Limit Ranges 的產品化，你可以直接在控制臺管理命名空間的 Limit Ranges，具體可參考文檔。

2. 自動化提升資源利用率的方法

上面提到的利用 Resource Quota 和 Limit Ranges 來分配和限制資源的方法依賴經驗和手工，主要解決的是資源請求和分配不合理。如何更自動化的動態(tài)調整以提升資源利用率是用戶更關心的問題，接下來從彈性伸縮、調度、在離線混部三大產品化的方向，詳述如何提升資源利用率。

2.1 彈性伸縮

2.1.1 通過 HPA 按指標彈性擴縮容

如上面資源浪費場景2所說，如果你的業(yè)務是存在波峰波谷的，固定的資源 Request 注定在波谷時會造成資源浪費，針對這樣的場景，如果波峰的時候可以自動增加業(yè)務負載的副本數量，波谷的時候可以自動減少業(yè)務負載的副本數量，將有效提升資源整體利用率。

HPA（Horizontal Pod Autoscaler）可以基于一些指標（例如 CPU、內存的利用率）自動擴縮 Deployment 和 StatefulSet 中的 Pod 副本的數量，達到工作負載穩(wěn)定的目的，真正做到按需使用。

HPA 使用場景

1. 流量突發(fā)：突然流量增加，負載過載時會自動增加 Pod 數量以及時響應

2. 自動縮容：流量較少時，負載對資源的利用率過低時會自動減少 Pod 的數量以避免浪費

TKE 上的 HPA

TKE 基于 Custom Metrics API 支持許多用于彈性伸縮的指標，涵蓋 CPU、內存、硬盤、網絡以及 GPU 相關的指標，覆蓋絕大多數的 HPA 彈性伸縮場景，詳細列表請參見 自動伸縮指標說明。此外，針對例如基于業(yè)務單副本 QPS 大小來進行自動擴縮容等復雜場景，可通過安裝 prometheus-adapter 來實現自動擴縮容，具體可參考文檔。

2.1.2 通過 HPC 定時擴縮容

假設你的業(yè)務是電商平臺，雙十一要進行促銷活動，這時可以考慮使用 HPA 自動擴縮容。但是 HPA 需要先監(jiān)控各項指標后，再進行反應，可能擴容速度不夠快，無法及時承載高流量。針對這種有預期的流量暴增，如果能提前發(fā)生副本擴容，將有效承載流量井噴。 HPC（HorizontalPodCronscaler）是 TKE 自研組件，旨在定時控制副本數量，以達到提前擴縮容、和提前觸發(fā)動態(tài)擴容時資源不足的影響，相較社區(qū)的 CronHPA，額外支持：

1. 與 HPA 結合：可以實現定時開啟和關閉 HPA，讓你的業(yè)務在高峰時更彈性

2. 例外日期設置：業(yè)務的流量不太可能永遠都是規(guī)律的，設置例外日期可以減少手工調整 HPC

3. 單次執(zhí)行：以往的 CronHPA 都是永久執(zhí)行，類似 Cronjob，單次執(zhí)行可以更靈活的應對大促場景

HPC 使用場景

以游戲服務為例，從周五晚上到周日晚上，游戲玩家數量暴增。如果可以將游戲服務器在星期五晚上前擴大規(guī)模，并在星期日晚上后縮放為原始規(guī)模，則可以為玩家提供更好的體驗。如果使用 HPA，可能因為擴容速度不夠快導致服務受影響。

TKE 上的 HPC

TKE 上已經實現對 HPC 的產品化，但你需要提前在”組件管理“里面安裝 HPC，HPC 使用 CronTab 語法格式。

安裝：

使用：

2.1.3 通過 CA 自動調整節(jié)點數量

上面提到的 HPA 和 HPC，都是在業(yè)務負載層面的自動擴縮副本數量，以靈活應對流量的波峰波谷，提升資源利用率。但是對于集群整體而言，資源總數是固定的，HPA 和 HPC 只是讓集群有更多空余的資源，是否有一種方法，能在集群整體較“空”時回收部分資源，能在集群整體較“滿”時擴充集群整體資源？因為集群整體資源的使用量直接決定了賬單費用，這種集群級別的彈性擴縮將真正幫助你節(jié)省使用成本。

CA（Cluster Autoscaler）用于自動擴縮集群節(jié)點數量，以真正實現資源利用率的提升，并直接作用于用戶的費用，是降本增效的關鍵。

CA 使用場景

1. 在業(yè)務波峰時，根據業(yè)務突增的負載擴容合適的節(jié)點

2. 在業(yè)務波谷時，根據資源的空閑情況釋放多余的節(jié)點

TKE 上的 CA

TKE 上的 CA 是以節(jié)點池的形態(tài)來讓用戶使用的，CA 推薦和 HPA 一起使用：HPA 負責應用層的擴縮容，CA 負責資源層（節(jié)點層）的擴縮容，當 HPA 擴容造成集群整體資源不足時，會引發(fā) Pod 的 Pending，Pod Pending 會觸發(fā) CA 擴充節(jié)點池以增加集群整體資源量，整體擴容邏輯可參考下圖：

具體的參數配置方式以及應用場景可參考《像管理 Pod 一樣管理 Node》，或者可參考騰訊云容器服務官方文檔。

2.2 調度

Kubernetes 調度機制是 Kubernetes 原生提供的一種高效優(yōu)雅的資源分配機制，它的核心功能是為每個 Pod 找到最適合它的節(jié)點，在 TKE 場景下，調度機制幫助實現了應用層彈性伸縮到資源層彈性伸縮的過渡。通過合理利用 Kubernetes 提供的調度能力，根據業(yè)務特性配置合理的調度策略，也能有效提高集群中的資源利用率。

2.2.1 節(jié)點親和性

倘若你的某個業(yè)務是 CPU 密集型，不小心被 Kubernetes 的調度器調度到內存密集型的節(jié)點上，導致內存密集型的 CPU 被占滿，但內存幾乎沒怎么用，會造成較大的資源浪費。如果你能為節(jié)點設置一個標記，表明這是一個 CPU 密集型的節(jié)點，然后在創(chuàng)建業(yè)務負載時也設置一個標記，表明這個負載是一個 CPU 密集型的負載，Kubernetes 的調度器會將這個負載調度到 CPU 密集型的節(jié)點上，這種尋找最合適的節(jié)點的方式，將有效提升資源利用率。

創(chuàng)建 Pod 時，可以設置節(jié)點親和性，即指定 Pod 想要調度到哪些節(jié)點上（這些節(jié)點是通過 K8s Label）來指定的。

節(jié)點親和性使用場景

節(jié)點親和性非常適合在一個集群中有不同資源需求的工作負載同時運行的場景。比如說，騰訊云的 CVM（節(jié)點） 有 CPU 密集型的機器，也有內存密集型的機器。如果某些業(yè)務對 CPU 的需求遠大于內存，此時使用普通的 CVM 機器，勢必會對內存造成較大浪費。此時可以在集群里添加一批 CPU 密集型的 CVM，并且把這些對 CPU 有較高需求的 Pod 調度到這些 CVM 上，這樣可以提升 CVM 資源的整體利用率。同理，還可以在集群中管理異構節(jié)點（比如 GPU 機器），在需要 GPU 資源的工作負載中指定需要GPU資源的量，調度機制則會幫助你尋找合適的節(jié)點去運行這些工作負載。

TKE 上的節(jié)點親和性

TKE 提供與原生 Kubernetes 完全一致的親和性使用方式，你可通過控制臺或配置 YAML 的方式使用此項功能，具體可參考。

2.2.2 動態(tài)調度器

原生的 Kubernetes 調度策略傾向于調度pod到節(jié)點剩余資源較多的節(jié)點上， 比如默認的 LeastRequestedPriority 策略。但是原生調度策略存在一個問題：這樣的資源分配是靜態(tài)的，Request 不能代表資源真實使用情況，因此一定會存在一定程度的浪費。因此，如果調度器可以基于節(jié)點的實際資源利用率進行調度，將一定程度上解決資源浪費的問題。

TKE 自研的動態(tài)調度器所做的就是這樣的工作。動態(tài)調度器的核心原理如下：

動態(tài)調度器的使用場景

除了降低資源浪費，動態(tài)調度器還可以很好的緩解集群調度熱點的問題。

1. 動態(tài)調度器會統計過去一段時間調度到節(jié)點的 Pod 數目，避免往同一節(jié)點上調度過多的 Pod

2. 動態(tài)調度器支持設置節(jié)點負載閾值，在調度階段過濾掉超過閾值的節(jié)點。

TKE 上的動態(tài)調度器

你可以在擴展組件里面安裝和使用動態(tài)調度器： 更多關于動態(tài)調度器的使用指南，可以參考 《TKE 重磅推出全鏈路調度解決方案》 和官方文檔。

2.3 在離線業(yè)務混部

如果你既有在線 Web 服務業(yè)務，又有離線的計算服務業(yè)務，借助 TKE 的在離線業(yè)務混部技術可以動態(tài)調度和運行不同的業(yè)務，提升資源利用率。

在傳統架構中，大數據業(yè)務和在線業(yè)務往往部署在不同的資源集群中，這兩部分業(yè)務相互獨立。但大數據業(yè)務一般更多的是離線計算類業(yè)務，在夜間處于業(yè)務高峰，而在線業(yè)務恰恰相反夜間常常處于空載狀態(tài)。云原生技術借助容器完整(CPU，內存，磁盤IO，網絡IO等)的隔離能力，及 Kubernetes 強大的編排調度能力，實現在線和離線業(yè)務混合部署，從而使在離線業(yè)務充分利用在線業(yè)務空閑時段的資源，以提高資源利用率。

在離線業(yè)務混部使用場景

在 Hadoop 架構下，離線作業(yè)和在線作業(yè)往往分屬不同的集群，然而在線業(yè)務、流式作業(yè)具有明顯的波峰波谷特性，在波谷時段，會有大量的資源處于閑置狀態(tài)，造成資源的浪費和成本的提升。在離線混部集群，通過動態(tài)調度削峰填谷，當在線集群的使用率處于波谷時段，將離線任務調度到在線集群，可以顯著的提高資源的利用率。然而，Hadoop Yarn 目前只能通過 NodeManager 上報的靜態(tài)資源情況進行分配，無法基于動態(tài)資源調度，無法很好的支持在線、離線業(yè)務混部的場景。

TKE 上的在離線混部

在線業(yè)務具有明顯的波峰浪谷特征，而且規(guī)律比較明顯，尤其是在夜間，資源利用率比較低，這時候大數據管控平臺向 Kubernetes 集群下發(fā)創(chuàng)建資源的請求，可以提高大數據應用的算力，具體可參考。

如何權衡資源利用率與穩(wěn)定性

在企業(yè)的運維工作中，除了成本，系統的穩(wěn)定性也是十分重要的指標。如何在兩者間達到平衡，可能是很多運維人員心中的“痛點”。一方面，為了降低成本，資源利用率當然是越高越好，但是資源利用率達到一定水位后，負載過高極有可能導致業(yè)務 OOM 或 CPU 抖動等問題。 為了減小企業(yè)成本控制之路上的顧慮，TKE 還提供了“兜底神器“ - 重調度器 來保障集群負載水位在可控范圍內。 重調度器是動態(tài)調度器是一對好搭檔（它們的關系可以參考下圖），就像它的名字一樣，它主要負責“保護”節(jié)點中已經負載比較“危險”的節(jié)點， 優(yōu)雅驅逐這些節(jié)點上的業(yè)務。

TKE 上的重調度器

可以在擴展組件里面安裝和使用重調度器：

到此，相信大家對“kubernetes如何提升資源利用率”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！