建站
咨詢
售后
建站咨詢
新聞中心
很多組織在Kubernetes集群中創(chuàng)建資源時(shí)可能會遇到以下情況：
目前成都創(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é)力一起成長，共同發(fā)展。
(1)沒有為工作負(fù)載指定CPU資源請求或較低的CPU資源請求，這意味著更多Pod可能在同一節(jié)點(diǎn)上工作。而在流量突增的時(shí)候，服務(wù)器中的CPU會以更長的延遲以達(dá)到最大值，但某些服務(wù)器可能會出現(xiàn)CPU軟鎖定的情況。
(2)同樣，沒有為工作負(fù)載指定內(nèi)存資源請求或較低的內(nèi)存資源請求。一些Pod(尤其是那些運(yùn)行Java商業(yè)應(yīng)用程序的Pod)將會重新啟動，盡管它們實(shí)際上可以在本地測試中正常運(yùn)行。
(3)在Kubernetes集群中，工作負(fù)載通常并不會在節(jié)點(diǎn)之間平均分配。特別是在大多數(shù)情況下，內(nèi)存資源分布并不均勻，這意味著某些節(jié)點(diǎn)可以比其他節(jié)點(diǎn)有著更高的內(nèi)存利用率。作為容器編排事實(shí)上的標(biāo)準(zhǔn)，Kubernetes應(yīng)該具有一個有效的調(diào)度程序，以確保資源的均勻分配。但真的是這樣嗎?
在通常情況下，如果流量突然出現(xiàn)爆發(fā)性增長，并在服務(wù)器出現(xiàn)宕機(jī)以至于SSH登錄失敗時(shí)，則集群管理員將無法執(zhí)行任何操作，只能重新啟動群集。在本文中，將通過分析可能出現(xiàn)的問題并討論如今解決的最佳實(shí)踐，深入探討Kubernetes的資源請求和限制。如果你對其底層機(jī)制感興趣，則還可以從源代碼的角度找到分析。本文將對你了解Kubernetes的資源請求和限制的工作方式以及它們可以按預(yù)期的方式工作的原因有所幫助。
概念
為了充分利用Kubernetes集群中的資源，提高調(diào)度效率，Kubernetes使用資源請求和限制來控制容器的資源分配。每個容器都有自己的請求和限制。這兩個參數(shù)由resources.requests和resources.limits指定。一般來說，請求在調(diào)度中更為重要，而限制在運(yùn)行中更為重要。
請求定義了容器所需的最少資源。例如，對于運(yùn)行Spring Boot業(yè)務(wù)的容器，其指定的請求必須是Java虛擬機(jī)(JVM)需要在容器映像中消耗的最少資源量。如果只是指定低內(nèi)存請求，則Kubernetes調(diào)度程序很可能會將Pod調(diào)度到?jīng)]有足夠資源來運(yùn)行JVM的節(jié)點(diǎn)。也就是說，Pod無法使用JVM啟動過程所需的更多內(nèi)存。因此導(dǎo)致Pod不斷重啟。
另一方面，限制決定了容器可以使用的最大資源量，從而防止了由于過度消耗資源而導(dǎo)致的資源短缺或服務(wù)器宕機(jī)的情況。如果將其設(shè)置為0，則表示該容器沒有資源限制。特別是，如果在沒有指定請求的情況下設(shè)置限制，Kubernetes會認(rèn)為默認(rèn)情況下請求的值與限制的值相同。
請求和限制適用于兩種類型的資源——可壓縮的(例如CPU)和不可壓縮的(例如內(nèi)存)。對于不可壓縮資源，進(jìn)行適當(dāng)?shù)南拗剖欠浅Ｖ匾摹?/p>
以下是請求和限制的概述：
- 如果Pod中的服務(wù)使用的CPU資源超過了指定的限制值，則Pod將會受到限制，但不會被終止。如果未設(shè)置限制值，則Pod可以使用所有空閑的CPU資源。
- 如果Pod使用的內(nèi)存資源超出了指定的限制值，Pod中的容器進(jìn)程將因OOM而終止。在這種情況下，Kubernetes傾向于在原始節(jié)點(diǎn)上重新啟動容器，或者簡單地創(chuàng)建另一個Pod。
- 0≤請求≤節(jié)點(diǎn)可分配;請求≤限制≤無限。
場景分析
在了解了請求和限制的概念之后，回顧一下以上提到的三種情況：
(1)情況1
首先，需要知道CPU資源和內(nèi)存資源是完全不同的。CPU資源是可壓縮的，CPU的分配和管理基于完全公平調(diào)度程序(CFS)。簡而言之，如果Pod中的服務(wù)使用的CPU資源超過了指定的限制值，它將受到Kubernetes的限制。對于沒有CPU限制的Pod來說，一旦空閑的CPU資源耗盡，之前分配的CPU資源量將逐漸減少。在這兩種情況下，最終，Pod將無法處理外部請求，從而導(dǎo)致更長的延遲和響應(yīng)時(shí)間。
(2)情況2
與其相反，內(nèi)存資源無法壓縮，并且Pod無法共享內(nèi)存資源。這意味著如果內(nèi)存耗盡，分配新的內(nèi)存資源肯定會失敗。
Pod中的某些進(jìn)程專門在初始化時(shí)需要一定數(shù)量的內(nèi)存。例如，JVM在啟動時(shí)會應(yīng)用一定數(shù)量的內(nèi)存。如果指定的內(nèi)存請求小于JVM應(yīng)用的內(nèi)存，則內(nèi)存應(yīng)用程序?qū)?OOM終止)。因此，這個Pod將繼續(xù)重啟并發(fā)生故障。
(3)情況3
在創(chuàng)建Pod時(shí)，Kubernetes需要以平衡和全面的方式分配或配置不同的資源，其中包括CPU和內(nèi)存。與此同時(shí)，Kubernetes調(diào)度算法需要考慮多種因素，例如NodeResourcesLeastAllocated和Pod affinity。內(nèi)存資源常常分布不均的原因是，對于應(yīng)用程序來說，內(nèi)存被認(rèn)為比其他資源更稀缺。
此外，Kubernetes調(diào)度程序根據(jù)集群的當(dāng)前狀態(tài)工作。換句話說，當(dāng)創(chuàng)建新的Pod時(shí)，調(diào)度程序會根據(jù)此時(shí)集群的資源規(guī)范為Pod選擇一個最佳節(jié)點(diǎn)來運(yùn)行。由于Kubernetes集群是高度動態(tài)的，因此在這里可能會發(fā)生潛在問題。例如，要維護(hù)一個節(jié)點(diǎn)，可能需要對其進(jìn)行鎖定，并且在該節(jié)點(diǎn)上運(yùn)行的所有Pod都將被調(diào)度到其他節(jié)點(diǎn)。而出現(xiàn)的問題是，在維護(hù)之后，這些Pod不會自動安排回原始節(jié)點(diǎn)。這是因?yàn)镵ubernetes本身無法將運(yùn)行中的Pod重新綁定到另一個節(jié)點(diǎn)，也就無法將其重新調(diào)度到另一個節(jié)點(diǎn)。
優(yōu)秀實(shí)踐
從以上分析可以知道，集群穩(wěn)定性直接影響應(yīng)用程序的性能。暫時(shí)的資源短缺通常是導(dǎo)致集群不穩(wěn)定的主要原因，而在云平臺不穩(wěn)定意味著應(yīng)用程序出現(xiàn)故障，甚至節(jié)點(diǎn)出現(xiàn)故障。
以下介紹兩種提高集群穩(wěn)定性的方法：
首先，通過編輯Kubelet配置文件來保留一定數(shù)量的系統(tǒng)資源。當(dāng)處理不可壓縮的計(jì)算資源(例如內(nèi)存或磁盤空間)時(shí)，這一點(diǎn)尤其重要。
其次，為Pod配置適當(dāng)?shù)姆?wù)質(zhì)量(QoS)類。Kubernetes使用QoS類來確定Pod的調(diào)度和逐出優(yōu)先級。可以為不同的Pod分配不同的QoS類，其中包括“Guaranteed”(最高優(yōu)先級)、“Burstable”和“BestEffort”(最低優(yōu)先級)。
- Guaranteed。Pod中的每個容器(包括init容器)都必須具有為CPU和內(nèi)存指定的請求和限制，并且它們必須相等。
- Burstable。Pod中至少有一個容器具有為CPU或內(nèi)存指定的請求。
- BestEffort。Pod中沒有容器具有為CPU和內(nèi)存指定的請求和限制。
注：使用Kubelet的CPU管理策略，可以為特定Pod設(shè)置CPU親和性。
當(dāng)資源耗盡時(shí)，集群將首先用BestEffort的QoS類終止Pod，然后是Burstable。換句話說，優(yōu)先級最低的Pod首先終止。如果具有足夠的資源，可以給所有的Pod分配一個Guaranteed類。這可以看作是計(jì)算資源與性能和穩(wěn)定性之間的權(quán)衡。你可能期望采用更多的資源，但集群可以更高效地工作。與此同時(shí)，為了提高資源利用率，你可以將運(yùn)行業(yè)務(wù)服務(wù)的Pod分配為Guaranteed類。對于其他服務(wù)，根據(jù)優(yōu)先級為它們分配Burstable或BestEffort類別。
接下來，將以KubeSphere容器平臺為例，了解如何更好地為Pod配置資源。
使用KubeSphere分配資源
如上所述，請求和限制是集群穩(wěn)定性的兩個重要組成部分。作為Kubernetes的主要發(fā)行版之一，KubeSphere擁有簡潔、清晰、交互式的用戶界面，極大地降低了Kubernetes的學(xué)習(xí)難度。
1.在開始之前做的工作
KubeSphere具有功能強(qiáng)大的多租戶系統(tǒng)，可對不同用戶進(jìn)行細(xì)粒度的訪問控制。在KubeSphere 3.0中，可以分別為名稱空間(ResourceQuotas)和容器(LimitRanges)設(shè)置請求和限制。要執(zhí)行這些操作，需要創(chuàng)建一個工作區(qū)、一個項(xiàng)目(即名稱空間)和一個帳戶(ws-admin)。
2.設(shè)置資源配額
轉(zhuǎn)到項(xiàng)目的“概述”頁面，導(dǎo)航到“項(xiàng)目設(shè)置”中的“基本信息”，然后從“管理項(xiàng)目”下拉菜單中選擇“編輯配額”。
在出現(xiàn)的對話框中，為項(xiàng)目設(shè)置請求和限制。
需要記住：
- 在這個頁面上設(shè)置的請求或限制必須大于為項(xiàng)目中所有Pod指定的總請求或限制。
- 在項(xiàng)目中創(chuàng)建容器而不指定請求或限制時(shí)，創(chuàng)建時(shí)將看到錯誤消息(記錄在事件中)。
在配置項(xiàng)目配額后，需要為項(xiàng)目中創(chuàng)建的所有容器指定請求和限制。項(xiàng)目配額為所有容器設(shè)置了規(guī)則。
注：KubeSphere中的項(xiàng)目配額與Kubernetes中的ResourceQuotas相同。除了CPU和內(nèi)存，還可以分別為其他對象(如Deployments和ConfigMaps)設(shè)置資源配額。
3.設(shè)置默認(rèn)請求和限制
如上所述，如果指定了項(xiàng)目配額，則需要相應(yīng)地配置Pod的請求和限制。實(shí)際上，在測試甚至生產(chǎn)中，請求的值和限制的值非常接近，甚至對于大多數(shù)Pod來說都是相等的。為了簡化創(chuàng)建工作負(fù)載的過程，KubeSphere允許用戶預(yù)先設(shè)置容器的默認(rèn)請求和限制。這樣無需在每次創(chuàng)建Pod時(shí)都設(shè)置請求和限制。
要設(shè)置默認(rèn)請求和限制，需要執(zhí)行以下步驟：
(1)同樣在“基本信息”頁面上，從“管理項(xiàng)目”下拉菜單中單擊“編輯資源默認(rèn)請求”。
在出現(xiàn)的對話框中，配置容器的默認(rèn)請求和限制。
注：KubeSphere中的默認(rèn)容器請求和限制在Kubernetes中稱為LimitRanges。
(2)以后創(chuàng)建工作負(fù)載時(shí)，請求和限制將自動填充。
對于運(yùn)行關(guān)鍵業(yè)務(wù)流程的容器，它們需要比其他容器處理更多的流量。實(shí)際上并沒有什么萬能的解決方案，你需要根據(jù)這些容器的要求和限制做出謹(jǐn)慎而全面的決定。因此需要考慮以下問題：
①容器是CPU密集型還是IO密集型?
②它們的可用性高嗎?
③服務(wù)的上游和下游對象是什么?
如果長時(shí)間觀察一些容器的運(yùn)行，就會發(fā)現(xiàn)它是周期性的。因此，在配置請求和限制時(shí)，歷史監(jiān)視數(shù)據(jù)可以作為重要的參考。對于集成到平臺中的Prometheus，KubeSphere具有強(qiáng)大而全面的可觀察性系統(tǒng)，可以對資源進(jìn)行更細(xì)致的監(jiān)視。在縱向上，它涵蓋了從集群到Pod的數(shù)據(jù);在橫向上，它跟蹤有關(guān)CPU、內(nèi)存、網(wǎng)絡(luò)和存儲的信息。通常情況下，可以基于歷史數(shù)據(jù)的平均值來指定請求，而限制則需要高于平均值。也就是說，可能需要根據(jù)需要對最終決定進(jìn)行一些調(diào)整。
源代碼分析
現(xiàn)在已經(jīng)了解了配置請求和限制的一些優(yōu)秀實(shí)踐，以下將更深入地研究源代碼。
(1)請求和計(jì)劃
以下代碼顯示了Pod的請求與Pod中容器的請求之間的關(guān)系。
從上面的代碼可以看出，調(diào)度程序計(jì)算了要調(diào)度的Pod所需的資源。具體來說，它根據(jù)Pod規(guī)范分別計(jì)算初始化容器的總請求和工作容器的總請求，將會使用更大的一個。需要注意的是，對于輕量級虛擬機(jī)(例如kata容器)，需要將自己的虛擬化資源消耗計(jì)入緩存中。在接下來的過濾階段，將檢查所有節(jié)點(diǎn)以查看它們是否滿足條件。
注：調(diào)度過程需要不同的階段，其中包括前置過濾器、過濾器、后置過濾器和評分。
在過濾之后，如果只有一個適用的節(jié)點(diǎn)，則會將Pod調(diào)度到該節(jié)點(diǎn)。如果有多個適用的Pod，則調(diào)度程序?qū)⑦x擇加權(quán)分?jǐn)?shù)總和最高的節(jié)點(diǎn)。計(jì)分插件的實(shí)現(xiàn)基于多種因素，調(diào)度插件實(shí)現(xiàn)一個或多個擴(kuò)展點(diǎn)。需要注意的是，請求的值和限制的值直接影響插件NodeResourcesLeastAllocated的最終結(jié)果。以下是源代碼：
對于NodeResourcesLeastAllocated，如果一個節(jié)點(diǎn)具有相同Pod的更多資源，則它將獲得更高的分?jǐn)?shù)。換句話說，一個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)資源平衡。在評分階段，除了NodeResourcesLeastAllocated外，調(diào)度程序還使用其他插件進(jìn)行評分，例如InterPodAffinity。
(2)QoS和調(diào)度
作為Kubernetes中的一種資源保護(hù)機(jī)制，QoS主要用于控制不可壓縮的資源(例如內(nèi)存)。它還會影響不同Pod和容器的OOM分?jǐn)?shù)。當(dāng)節(jié)點(diǎn)內(nèi)存不足時(shí)，內(nèi)核(OOM Killer)終止優(yōu)先級較低的Pod(分?jǐn)?shù)越高，優(yōu)先級越低)。以下是源代碼：
結(jié)語
作為一個可移植且可擴(kuò)展的開源平臺，Kubernetes誕生于管理容器化工作負(fù)載和服務(wù)。它擁有一個全面的、快速發(fā)展的生態(tài)系統(tǒng)，已經(jīng)幫助其鞏固了在容器編排中事實(shí)上的標(biāo)準(zhǔn)的地位。用戶學(xué)習(xí)Kubernetes并不是那么容易，而這正是KubeSphere發(fā)揮作用的地方。 KubeSphere使用戶可以在其儀表板上執(zhí)行幾乎所有操作，同時(shí)還可以選擇使用內(nèi)置的Web Kubectl工具來運(yùn)行命令。本文重點(diǎn)介紹了請求和限制，它們在Kubernetes中的基本邏輯以及如何使用KubeSphere對其進(jìn)行配置以簡化集群的操作和維護(hù)。
名稱欄目：深入研究Kubernetes的資源請求和限制
當(dāng)前路徑：http://www.dlmjj.cn/article/djihsis.html
