【51CTO.com快譯】很多組織在Kubernetes集群中創建資源時可能會遇到以下情況：

(1)沒有為工作負載指定CPU資源請求或較低的CPU資源請求，這意味著更多Pod可能在同一節點上工作。而在流量突增的時候，服務器中的CPU會以更長的延遲以達到最大值，但某些服務器可能會出現CPU軟鎖定的情況。

(2)同樣，沒有為工作負載指定內存資源請求或較低的內存資源請求。一些Pod(尤其是那些運行Java商業應用程序的Pod)將會重新啟動，盡管它們實際上可以在本地測試中正常運行。

(3)在Kubernetes集群中，工作負載通常并不會在節點之間平均分配。特別是在大多數情況下，內存資源分布并不均勻，這意味著某些節點可以比其他節點有著更高的內存利用率。作為容器編排事實上的標準，Kubernetes應該具有一個有效的調度程序，以確保資源的均勻分配。但真的是這樣嗎?

在通常情況下，如果流量突然出現爆發性增長，并在服務器出現宕機以至于SSH登錄失敗時，則集群管理員將無法執行任何操作，只能重新啟動群集。在本文中，將通過分析可能出現的問題并討論如今解決的最佳實踐，深入探討Kubernetes的資源請求和限制。如果你對其底層機制感興趣，則還可以從源代碼的角度找到分析。本文將對你了解Kubernetes的資源請求和限制的工作方式以及它們可以按預期的方式工作的原因有所幫助。

概念

為了充分利用Kubernetes集群中的資源，提高調度效率，Kubernetes使用資源請求和限制來控制容器的資源分配。每個容器都有自己的請求和限制。這兩個參數由resources.requests和resources.limits指定。一般來說，請求在調度中更為重要，而限制在運行中更為重要。

請求定義了容器所需的最少資源。例如，對于運行Spring Boot業務的容器，其指定的請求必須是Java虛擬機(JVM)需要在容器映像中消耗的最少資源量。如果只是指定低內存請求，則Kubernetes調度程序很可能會將Pod調度到沒有足夠資源來運行JVM的節點。也就是說，Pod無法使用JVM啟動過程所需的更多內存。因此導致Pod不斷重啟。

另一方面，限制決定了容器可以使用的最大資源量，從而防止了由于過度消耗資源而導致的資源短缺或服務器宕機的情況。如果將其設置為0，則表示該容器沒有資源限制。特別是，如果在沒有指定請求的情況下設置限制，Kubernetes會認為默認情況下請求的值與限制的值相同。

請求和限制適用于兩種類型的資源——可壓縮的(例如CPU)和不可壓縮的(例如內存)。對于不可壓縮資源，進行適當的限制是非常重要的。

以下是請求和限制的概述：

• 如果Pod中的服務使用的CPU資源超過了指定的限制值，則Pod將會受到限制，但不會被終止。如果未設置限制值，則Pod可以使用所有空閑的CPU資源。
• 如果Pod使用的內存資源超出了指定的限制值，Pod中的容器進程將因OOM而終止。在這種情況下，Kubernetes傾向于在原始節點上重新啟動容器，或者簡單地創建另一個Pod。
• 0≤請求≤節點可分配;請求≤限制≤無限。

場景分析

在了解了請求和限制的概念之后，回顧一下以上提到的三種情況：

(1)情況1

首先，需要知道CPU資源和內存資源是完全不同的。CPU資源是可壓縮的，CPU的分配和管理基于完全公平調度程序(CFS)。簡而言之，如果Pod中的服務使用的CPU資源超過了指定的限制值，它將受到Kubernetes的限制。對于沒有CPU限制的Pod來說，一旦空閑的CPU資源耗盡，之前分配的CPU資源量將逐漸減少。在這兩種情況下，最終，Pod將無法處理外部請求，從而導致更長的延遲和響應時間。

(2)情況2

與其相反，內存資源無法壓縮，并且Pod無法共享內存資源。這意味著如果內存耗盡，分配新的內存資源肯定會失敗。

Pod中的某些進程專門在初始化時需要一定數量的內存。例如，JVM在啟動時會應用一定數量的內存。如果指定的內存請求小于JVM應用的內存，則內存應用程序將會失敗(OOM終止)。因此，這個Pod將繼續重啟并發生故障。

(3)情況3

在創建Pod時，Kubernetes需要以平衡和全面的方式分配或配置不同的資源，其中包括CPU和內存。與此同時，Kubernetes調度算法需要考慮多種因素，例如NodeResourcesLeastAllocated和Pod affinity。內存資源常常分布不均的原因是，對于應用程序來說，內存被認為比其他資源更稀缺。

此外，Kubernetes調度程序根據集群的當前狀態工作。換句話說，當創建新的Pod時，調度程序會根據此時集群的資源規范為Pod選擇一個最佳節點來運行。由于Kubernetes集群是高度動態的，因此在這里可能會發生潛在問題。例如，要維護一個節點，可能需要對其進行鎖定，并且在該節點上運行的所有Pod都將被調度到其他節點。而出現的問題是，在維護之后，這些Pod不會自動安排回原始節點。這是因為Kubernetes本身無法將運行中的Pod重新綁定到另一個節點，也就無法將其重新調度到另一個節點。

優秀實踐

從以上分析可以知道，集群穩定性直接影響應用程序的性能。暫時的資源短缺通常是導致集群不穩定的主要原因，而在云平臺不穩定意味著應用程序出現故障，甚至節點出現故障。

以下介紹兩種提高集群穩定性的方法：

首先，通過編輯Kubelet配置文件來保留一定數量的系統資源。當處理不可壓縮的計算資源(例如內存或磁盤空間)時，這一點尤其重要。

其次，為Pod配置適當的服務質量(QoS)類。Kubernetes使用QoS類來確定Pod的調度和逐出優先級。可以為不同的Pod分配不同的QoS類，其中包括“Guaranteed”(最高優先級)、“Burstable”和“BestEffort”(最低優先級)。

• Guaranteed。Pod中的每個容器(包括init容器)都必須具有為CPU和內存指定的請求和限制，并且它們必須相等。
• Burstable。Pod中至少有一個容器具有為CPU或內存指定的請求。
• BestEffort。Pod中沒有容器具有為CPU和內存指定的請求和限制。

注：使用Kubelet的CPU管理策略，可以為特定Pod設置CPU親和性。

當資源耗盡時，集群將首先用BestEffort的QoS類終止Pod，然后是Burstable。換句話說，優先級最低的Pod首先終止。如果具有足夠的資源，可以給所有的Pod分配一個Guaranteed類。這可以看作是計算資源與性能和穩定性之間的權衡。你可能期望采用更多的資源，但集群可以更高效地工作。與此同時，為了提高資源利用率，你可以將運行業務服務的Pod分配為Guaranteed類。對于其他服務，根據優先級為它們分配Burstable或BestEffort類別。

接下來，將以KubeSphere容器平臺為例，了解如何更好地為Pod配置資源。

使用KubeSphere分配資源

如上所述，請求和限制是集群穩定性的兩個重要組成部分。作為Kubernetes的主要發行版之一，KubeSphere擁有簡潔、清晰、交互式的用戶界面，極大地降低了Kubernetes的學習難度。

1.在開始之前做的工作

KubeSphere具有功能強大的多租戶系統，可對不同用戶進行細粒度的訪問控制。在KubeSphere 3.0中，可以分別為名稱空間(ResourceQuotas)和容器(LimitRanges)設置請求和限制。要執行這些操作，需要創建一個工作區、一個項目(即名稱空間)和一個帳戶(ws-admin)。

2.設置資源配額

轉到項目的“概述”頁面，導航到“項目設置”中的“基本信息”，然后從“管理項目”下拉菜單中選擇“編輯配額”。

在出現的對話框中，為項目設置請求和限制。

需要記住：

• 在這個頁面上設置的請求或限制必須大于為項目中所有Pod指定的總請求或限制。
• 在項目中創建容器而不指定請求或限制時，創建時將看到錯誤消息(記錄在事件中)。

在配置項目配額后，需要為項目中創建的所有容器指定請求和限制。項目配額為所有容器設置了規則。

注：KubeSphere中的項目配額與Kubernetes中的ResourceQuotas相同。除了CPU和內存，還可以分別為其他對象(如Deployments和ConfigMaps)設置資源配額。

3.設置默認請求和限制

如上所述，如果指定了項目配額，則需要相應地配置Pod的請求和限制。實際上，在測試甚至生產中，請求的值和限制的值非常接近，甚至對于大多數Pod來說都是相等的。為了簡化創建工作負載的過程，KubeSphere允許用戶預先設置容器的默認請求和限制。這樣無需在每次創建Pod時都設置請求和限制。

要設置默認請求和限制，需要執行以下步驟：

(1)同樣在“基本信息”頁面上，從“管理項目”下拉菜單中單擊“編輯資源默認請求”。

在出現的對話框中，配置容器的默認請求和限制。

注：KubeSphere中的默認容器請求和限制在Kubernetes中稱為LimitRanges。

(2)以后創建工作負載時，請求和限制將自動填充。

對于運行關鍵業務流程的容器，它們需要比其他容器處理更多的流量。實際上并沒有什么萬能的解決方案，你需要根據這些容器的要求和限制做出謹慎而全面的決定。因此需要考慮以下問題：

①容器是CPU密集型還是IO密集型?

②它們的可用性高嗎?

③服務的上游和下游對象是什么?

如果長時間觀察一些容器的運行，就會發現它是周期性的。因此，在配置請求和限制時，歷史監視數據可以作為重要的參考。對于集成到平臺中的Prometheus，KubeSphere具有強大而全面的可觀察性系統，可以對資源進行更細致的監視。在縱向上，它涵蓋了從集群到Pod的數據;在橫向上，它跟蹤有關CPU、內存、網絡和存儲的信息。通常情況下，可以基于歷史數據的平均值來指定請求，而限制則需要高于平均值。也就是說，可能需要根據需要對最終決定進行一些調整。

源代碼分析

現在已經了解了配置請求和限制的一些優秀實踐，以下將更深入地研究源代碼。

(1)請求和計劃

以下代碼顯示了Pod的請求與Pod中容器的請求之間的關系。

從上面的代碼可以看出，調度程序計算了要調度的Pod所需的資源。具體來說，它根據Pod規范分別計算初始化容器的總請求和工作容器的總請求，將會使用更大的一個。需要注意的是，對于輕量級虛擬機(例如kata容器)，需要將自己的虛擬化資源消耗計入緩存中。在接下來的過濾階段，將檢查所有節點以查看它們是否滿足條件。

注：調度過程需要不同的階段，其中包括前置過濾器、過濾器、后置過濾器和評分。

在過濾之后，如果只有一個適用的節點，則會將Pod調度到該節點。如果有多個適用的Pod，則調度程序將選擇加權分數總和最高的節點。計分插件的實現基于多種因素，調度插件實現一個或多個擴展點。需要注意的是，請求的值和限制的值直接影響插件NodeResourcesLeastAllocated的最終結果。以下是源代碼：

對于NodeResourcesLeastAllocated，如果一個節點具有相同Pod的更多資源，則它將獲得更高的分數。換句話說，一個Pod將更有可能被調度到具有足夠資源的節點。

在創建Pod時，Kubernetes需要分配不同的資源，包括CPU和內存。每種資源都有權重(源代碼中的resToWeightMap結構)。總體而言，它們告訴Kubernetes調度程序，最佳的決定可能是實現資源平衡。在評分階段，除了NodeResourcesLeastAllocated外，調度程序還使用其他插件進行評分，例如InterPodAffinity。

(2)QoS和調度

作為Kubernetes中的一種資源保護機制，QoS主要用于控制不可壓縮的資源(例如內存)。它還會影響不同Pod和容器的OOM分數。當節點內存不足時，內核(OOM Killer)終止優先級較低的Pod(分數越高，優先級越低)。以下是源代碼：

結語

作為一個可移植且可擴展的開源平臺，Kubernetes誕生于管理容器化工作負載和服務。它擁有一個全面的、快速發展的生態系統，已經幫助其鞏固了在容器編排中事實上的標準的地位。用戶學習Kubernetes并不是那么容易，而這正是KubeSphere發揮作用的地方。 KubeSphere使用戶可以在其儀表板上執行幾乎所有操作，同時還可以選擇使用內置的Web Kubectl工具來運行命令。本文重點介紹了請求和限制，它們在Kubernetes中的基本邏輯以及如何使用KubeSphere對其進行配置以簡化集群的操作和維護。

原文標題：Dive Deep Into Resource Requests and Limits in Kubernetes，作者：Sherlock Xu

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】