很多組織在Kubernetes集群中創(chuàng)建資源時(shí)可能會(huì)遇到以下情況：

目前成都創(chuàng)新互聯(lián)已為上千余家的企業(yè)提供了網(wǎng)站建設(shè)、域名、虛擬空間、網(wǎng)站托管、企業(yè)網(wǎng)站設(shè)計(jì)、霞浦網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長(zhǎng)，共同發(fā)展。

(1)沒(méi)有為工作負(fù)載指定CPU資源請(qǐng)求或較低的CPU資源請(qǐng)求，這意味著更多Pod可能在同一節(jié)點(diǎn)上工作。而在流量突增的時(shí)候，服務(wù)器中的CPU會(huì)以更長(zhǎng)的延遲以達(dá)到最大值，但某些服務(wù)器可能會(huì)出現(xiàn)CPU軟鎖定的情況。

(2)同樣，沒(méi)有為工作負(fù)載指定內(nèi)存資源請(qǐng)求或較低的內(nèi)存資源請(qǐng)求。一些Pod(尤其是那些運(yùn)行Java商業(yè)應(yīng)用程序的Pod)將會(huì)重新啟動(dòng)，盡管它們實(shí)際上可以在本地測(cè)試中正常運(yùn)行。

(3)在Kubernetes集群中，工作負(fù)載通常并不會(huì)在節(jié)點(diǎn)之間平均分配。特別是在大多數(shù)情況下，內(nèi)存資源分布并不均勻，這意味著某些節(jié)點(diǎn)可以比其他節(jié)點(diǎn)有著更高的內(nèi)存利用率。作為容器編排事實(shí)上的標(biāo)準(zhǔn)，Kubernetes應(yīng)該具有一個(gè)有效的調(diào)度程序，以確保資源的均勻分配。但真的是這樣嗎?

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

概念

為了充分利用Kubernetes集群中的資源，提高調(diào)度效率，Kubernetes使用資源請(qǐng)求和限制來(lái)控制容器的資源分配。每個(gè)容器都有自己的請(qǐng)求和限制。這兩個(gè)參數(shù)由resources.requests和resources.limits指定。一般來(lái)說(shuō)，請(qǐng)求在調(diào)度中更為重要，而限制在運(yùn)行中更為重要。

請(qǐng)求定義了容器所需的最少資源。例如，對(duì)于運(yùn)行Spring Boot業(yè)務(wù)的容器，其指定的請(qǐng)求必須是Java虛擬機(jī)(JVM)需要在容器映像中消耗的最少資源量。如果只是指定低內(nèi)存請(qǐng)求，則Kubernetes調(diào)度程序很可能會(huì)將Pod調(diào)度到?jīng)]有足夠資源來(lái)運(yùn)行JVM的節(jié)點(diǎn)。也就是說(shuō)，Pod無(wú)法使用JVM啟動(dòng)過(guò)程所需的更多內(nèi)存。因此導(dǎo)致Pod不斷重啟。

另一方面，限制決定了容器可以使用的最大資源量，從而防止了由于過(guò)度消耗資源而導(dǎo)致的資源短缺或服務(wù)器宕機(jī)的情況。如果將其設(shè)置為0，則表示該容器沒(méi)有資源限制。特別是，如果在沒(méi)有指定請(qǐng)求的情況下設(shè)置限制，Kubernetes會(huì)認(rèn)為默認(rèn)情況下請(qǐng)求的值與限制的值相同。

請(qǐng)求和限制適用于兩種類(lèi)型的資源——可壓縮的(例如CPU)和不可壓縮的(例如內(nèi)存)。對(duì)于不可壓縮資源，進(jìn)行適當(dāng)?shù)南拗剖欠浅Ｖ匾摹?/p>

以下是請(qǐng)求和限制的概述：

• 如果Pod中的服務(wù)使用的CPU資源超過(guò)了指定的限制值，則Pod將會(huì)受到限制，但不會(huì)被終止。如果未設(shè)置限制值，則Pod可以使用所有空閑的CPU資源。
• 如果Pod使用的內(nèi)存資源超出了指定的限制值，Pod中的容器進(jìn)程將因OOM而終止。在這種情況下，Kubernetes傾向于在原始節(jié)點(diǎn)上重新啟動(dòng)容器，或者簡(jiǎn)單地創(chuàng)建另一個(gè)Pod。
• 0≤請(qǐng)求≤節(jié)點(diǎn)可分配;請(qǐng)求≤限制≤無(wú)限。

場(chǎng)景分析

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

(1)情況1

首先，需要知道CPU資源和內(nèi)存資源是完全不同的。CPU資源是可壓縮的，CPU的分配和管理基于完全公平調(diào)度程序(CFS)。簡(jiǎn)而言之，如果Pod中的服務(wù)使用的CPU資源超過(guò)了指定的限制值，它將受到Kubernetes的限制。對(duì)于沒(méi)有CPU限制的Pod來(lái)說(shuō)，一旦空閑的CPU資源耗盡，之前分配的CPU資源量將逐漸減少。在這兩種情況下，最終，Pod將無(wú)法處理外部請(qǐng)求，從而導(dǎo)致更長(zhǎng)的延遲和響應(yīng)時(shí)間。

(2)情況2

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

Pod中的某些進(jìn)程專門(mén)在初始化時(shí)需要一定數(shù)量的內(nèi)存。例如，JVM在啟動(dòng)時(shí)會(huì)應(yīng)用一定數(shù)量的內(nèi)存。如果指定的內(nèi)存請(qǐng)求小于JVM應(yīng)用的內(nèi)存，則內(nèi)存應(yīng)用程序?qū)?huì)失敗(OOM終止)。因此，這個(gè)Pod將繼續(xù)重啟并發(fā)生故障。

(3)情況3

在創(chuàng)建Pod時(shí)，Kubernetes需要以平衡和全面的方式分配或配置不同的資源，其中包括CPU和內(nèi)存。與此同時(shí)，Kubernetes調(diào)度算法需要考慮多種因素，例如NodeResourcesLeastAllocated和Pod affinity。內(nèi)存資源常常分布不均的原因是，對(duì)于應(yīng)用程序來(lái)說(shuō)，內(nèi)存被認(rèn)為比其他資源更稀缺。

此外，Kubernetes調(diào)度程序根據(jù)集群的當(dāng)前狀態(tài)工作。換句話說(shuō)，當(dāng)創(chuàng)建新的Pod時(shí)，調(diào)度程序會(huì)根據(jù)此時(shí)集群的資源規(guī)范為Pod選擇一個(gè)最佳節(jié)點(diǎn)來(lái)運(yùn)行。由于Kubernetes集群是高度動(dòng)態(tài)的，因此在這里可能會(huì)發(fā)生潛在問(wèn)題。例如，要維護(hù)一個(gè)節(jié)點(diǎn)，可能需要對(duì)其進(jìn)行鎖定，并且在該節(jié)點(diǎn)上運(yùn)行的所有Pod都將被調(diào)度到其他節(jié)點(diǎn)。而出現(xiàn)的問(wèn)題是，在維護(hù)之后，這些Pod不會(huì)自動(dòng)安排回原始節(jié)點(diǎn)。這是因?yàn)镵ubernetes本身無(wú)法將運(yùn)行中的Pod重新綁定到另一個(gè)節(jié)點(diǎn)，也就無(wú)法將其重新調(diào)度到另一個(gè)節(jié)點(diǎn)。

優(yōu)秀實(shí)踐

從以上分析可以知道，集群穩(wěn)定性直接影響應(yīng)用程序的性能。暫時(shí)的資源短缺通常是導(dǎo)致集群不穩(wěn)定的主要原因，而在云平臺(tái)不穩(wěn)定意味著應(yīng)用程序出現(xiàn)故障，甚至節(jié)點(diǎn)出現(xiàn)故障。

以下介紹兩種提高集群穩(wěn)定性的方法：

首先，通過(guò)編輯Kubelet配置文件來(lái)保留一定數(shù)量的系統(tǒng)資源。當(dāng)處理不可壓縮的計(jì)算資源(例如內(nèi)存或磁盤(pán)空間)時(shí)，這一點(diǎn)尤其重要。

其次，為Pod配置適當(dāng)?shù)姆?wù)質(zhì)量(QoS)類(lèi)。Kubernetes使用QoS類(lèi)來(lái)確定Pod的調(diào)度和逐出優(yōu)先級(jí)?？梢詾椴煌腜od分配不同的QoS類(lèi)，其中包括“Guaranteed”(最高優(yōu)先級(jí))、“Burstable”和“BestEffort”(最低優(yōu)先級(jí))。

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

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

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

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

使用KubeSphere分配資源

如上所述，請(qǐng)求和限制是集群穩(wěn)定性的兩個(gè)重要組成部分。作為Kubernetes的主要發(fā)行版之一，KubeSphere擁有簡(jiǎn)潔、清晰、交互式的用戶界面，極大地降低了Kubernetes的學(xué)習(xí)難度。

1.在開(kāi)始之前做的工作

KubeSphere具有功能強(qiáng)大的多租戶系統(tǒng)，可對(duì)不同用戶進(jìn)行細(xì)粒度的訪問(wèn)控制。在KubeSphere 3.0中，可以分別為名稱空間(ResourceQuotas)和容器(LimitRanges)設(shè)置請(qǐng)求和限制。要執(zhí)行這些操作，需要?jiǎng)?chuàng)建一個(gè)工作區(qū)、一個(gè)項(xiàng)目(即名稱空間)和一個(gè)帳戶(ws-admin)。

2.設(shè)置資源配額

轉(zhuǎn)到項(xiàng)目的“概述”頁(yè)面，導(dǎo)航到“項(xiàng)目設(shè)置”中的“基本信息”，然后從“管理項(xiàng)目”下拉菜單中選擇“編輯配額”。

在出現(xiàn)的對(duì)話框中，為項(xiàng)目設(shè)置請(qǐng)求和限制。

需要記?。?/p>

• 在這個(gè)頁(yè)面上設(shè)置的請(qǐng)求或限制必須大于為項(xiàng)目中所有Pod指定的總請(qǐng)求或限制。
• 在項(xiàng)目中創(chuàng)建容器而不指定請(qǐng)求或限制時(shí)，創(chuàng)建時(shí)將看到錯(cuò)誤消息(記錄在事件中)。

在配置項(xiàng)目配額后，需要為項(xiàng)目中創(chuàng)建的所有容器指定請(qǐng)求和限制。項(xiàng)目配額為所有容器設(shè)置了規(guī)則。

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

3.設(shè)置默認(rèn)請(qǐng)求和限制

如上所述，如果指定了項(xiàng)目配額，則需要相應(yīng)地配置Pod的請(qǐng)求和限制。實(shí)際上，在測(cè)試甚至生產(chǎn)中，請(qǐng)求的值和限制的值非常接近，甚至對(duì)于大多數(shù)Pod來(lái)說(shuō)都是相等的。為了簡(jiǎn)化創(chuàng)建工作負(fù)載的過(guò)程，KubeSphere允許用戶預(yù)先設(shè)置容器的默認(rèn)請(qǐng)求和限制。這樣無(wú)需在每次創(chuàng)建Pod時(shí)都設(shè)置請(qǐng)求和限制。

要設(shè)置默認(rèn)請(qǐng)求和限制，需要執(zhí)行以下步驟：

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

在出現(xiàn)的對(duì)話框中，配置容器的默認(rèn)請(qǐng)求和限制。

注：KubeSphere中的默認(rèn)容器請(qǐng)求和限制在Kubernetes中稱為L(zhǎng)imitRanges。

(2)以后創(chuàng)建工作負(fù)載時(shí)，請(qǐng)求和限制將自動(dòng)填充。

對(duì)于運(yùn)行關(guān)鍵業(yè)務(wù)流程的容器，它們需要比其他容器處理更多的流量。實(shí)際上并沒(méi)有什么萬(wàn)能的解決方案，你需要根據(jù)這些容器的要求和限制做出謹(jǐn)慎而全面的決定。因此需要考慮以下問(wèn)題：

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

②它們的可用性高嗎?

③服務(wù)的上游和下游對(duì)象是什么?

如果長(zhǎng)時(shí)間觀察一些容器的運(yùn)行，就會(huì)發(fā)現(xiàn)它是周期性的。因此，在配置請(qǐng)求和限制時(shí)，歷史監(jiān)視數(shù)據(jù)可以作為重要的參考。對(duì)于集成到平臺(tái)中的Prometheus，KubeSphere具有強(qiáng)大而全面的可觀察性系統(tǒng)，可以對(duì)資源進(jìn)行更細(xì)致的監(jiān)視。在縱向上，它涵蓋了從集群到Pod的數(shù)據(jù);在橫向上，它跟蹤有關(guān)CPU、內(nèi)存、網(wǎng)絡(luò)和存儲(chǔ)的信息。通常情況下，可以基于歷史數(shù)據(jù)的平均值來(lái)指定請(qǐng)求，而限制則需要高于平均值。也就是說(shuō)，可能需要根據(jù)需要對(duì)最終決定進(jìn)行一些調(diào)整。

源代碼分析

現(xiàn)在已經(jīng)了解了配置請(qǐng)求和限制的一些優(yōu)秀實(shí)踐，以下將更深入地研究源代碼。

(1)請(qǐng)求和計(jì)劃

以下代碼顯示了Pod的請(qǐng)求與Pod中容器的請(qǐng)求之間的關(guān)系。

從上面的代碼可以看出，調(diào)度程序計(jì)算了要調(diào)度的Pod所需的資源。具體來(lái)說(shuō)，它根據(jù)Pod規(guī)范分別計(jì)算初始化容器的總請(qǐng)求和工作容器的總請(qǐng)求，將會(huì)使用更大的一個(gè)。需要注意的是，對(duì)于輕量級(jí)虛擬機(jī)(例如kata容器)，需要將自己的虛擬化資源消耗計(jì)入緩存中。在接下來(lái)的過(guò)濾階段，將檢查所有節(jié)點(diǎn)以查看它們是否滿足條件。

注：調(diào)度過(guò)程需要不同的階段，其中包括前置過(guò)濾器、過(guò)濾器、后置過(guò)濾器和評(píng)分。

在過(guò)濾之后，如果只有一個(gè)適用的節(jié)點(diǎn)，則會(huì)將Pod調(diào)度到該節(jié)點(diǎn)。如果有多個(gè)適用的Pod，則調(diào)度程序?qū)⑦x擇加權(quán)分?jǐn)?shù)總和最高的節(jié)點(diǎn)。計(jì)分插件的實(shí)現(xiàn)基于多種因素，調(diào)度插件實(shí)現(xiàn)一個(gè)或多個(gè)擴(kuò)展點(diǎn)。需要注意的是，請(qǐng)求的值和限制的值直接影響插件NodeResourcesLeastAllocated的最終結(jié)果。以下是源代碼：

對(duì)于NodeResourcesLeastAllocated，如果一個(gè)節(jié)點(diǎn)具有相同Pod的更多資源，則它將獲得更高的分?jǐn)?shù)。換句話說(shuō)，一個(gè)Pod將更有可能被調(diào)度到具有足夠資源的節(jié)點(diǎn)。

在創(chuàng)建Pod時(shí)，Kubernetes需要分配不同的資源，包括CPU和內(nèi)存。每種資源都有權(quán)重(源代碼中的resToWeightMap結(jié)構(gòu))?？傮w而言，它們告訴Kubernetes調(diào)度程序，最佳的決定可能是實(shí)現(xiàn)資源平衡。在評(píng)分階段，除了NodeResourcesLeastAllocated外，調(diào)度程序還使用其他插件進(jìn)行評(píng)分，例如InterPodAffinity。

(2)QoS和調(diào)度

作為Kubernetes中的一種資源保護(hù)機(jī)制，QoS主要用于控制不可壓縮的資源(例如內(nèi)存)。它還會(huì)影響不同Pod和容器的OOM分?jǐn)?shù)。當(dāng)節(jié)點(diǎn)內(nèi)存不足時(shí)，內(nèi)核(OOM Killer)終止優(yōu)先級(jí)較低的Pod(分?jǐn)?shù)越高，優(yōu)先級(jí)越低)。以下是源代碼：

結(jié)語(yǔ)

作為一個(gè)可移植且可擴(kuò)展的開(kāi)源平臺(tái)，Kubernetes誕生于管理容器化工作負(fù)載和服務(wù)。它擁有一個(gè)全面的、快速發(fā)展的生態(tài)系統(tǒng)，已經(jīng)幫助其鞏固了在容器編排中事實(shí)上的標(biāo)準(zhǔn)的地位。用戶學(xué)習(xí)Kubernetes并不是那么容易，而這正是KubeSphere發(fā)揮作用的地方。 KubeSphere使用戶可以在其儀表板上執(zhí)行幾乎所有操作，同時(shí)還可以選擇使用內(nèi)置的Web Kubectl工具來(lái)運(yùn)行命令。本文重點(diǎn)介紹了請(qǐng)求和限制，它們?cè)贙ubernetes中的基本邏輯以及如何使用KubeSphere對(duì)其進(jìn)行配置以簡(jiǎn)化集群的操作和維護(hù)。

網(wǎng)頁(yè)標(biāo)題：深入研究Kubernetes的資源請(qǐng)求和限制
本文路徑：http://uogjgqi.cn/article/djihsis.html