kubernetes如何提升資源利用率

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

背景

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

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

資源浪費場景

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

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

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

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

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

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

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

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

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

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

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

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

1. 如何資源劃分和限制

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

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

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

1.1 使用 Resource Quota 劃分資源

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

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

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

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

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

Resource Quota 使用場景

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

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

TKE 上的 Resource Quota

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

1.2 使用 Limit Ranges 限制資源

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

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

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

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

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

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

Limit Ranges 使用場景

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

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

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

TKE 上的 Limit Ranges

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

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

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

2.1 彈性伸縮

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

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

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

HPA 使用場景

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

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

TKE 上的 HPA

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

2.1.2 通過 HPC 定時擴縮容

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

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

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

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

HPC 使用場景

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

TKE 上的 HPC

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

安裝：

使用：

2.1.3 通過 CA 自動調整節點數量

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

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

CA 使用場景

1. 在業務波峰時，根據業務突增的負載擴容合適的節點

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

TKE 上的 CA

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

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

2.2 調度

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

2.2.1 節點親和性

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

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

節點親和性使用場景

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

TKE 上的節點親和性

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

2.2.2 動態調度器

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

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

動態調度器的使用場景

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

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

2. 動態調度器支持設置節點負載閾值，在調度階段過濾掉超過閾值的節點。

TKE 上的動態調度器

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

2.3 在離線業務混部

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

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

在離線業務混部使用場景

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

TKE 上的在離線混部

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

如何權衡資源利用率與穩定性

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

TKE 上的重調度器

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

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