計算資源管理 QoS

2022-10-02 07:03:14 字數 2525 閱讀 4913

假設有兩個 pod, pod a 使用了節點記憶體的 90%, pod b 突然需要比之前更多的記憶體,這時節點無法提供足量記憶體,哪個容器將被殺掉呢?應該是 pod b 嗎?因為節點無法滿足它的記憶體請求, 或者應該是 pod a 嗎?這樣釋放的記憶體就可以提供給pod b 了。

顯然,這要分情況討論。 kubernetes 無法自己做出正確決策,因此就需要一種方式,通過這種方式可以指定哪種 pod 在該場景中優先順序更高。

kubernetes pod 劃分為三種 qos 等級

qos 等級** pod 所包含的容器的資源 requests 和 limits 的配置。

為 pod 分配 besteffort 等級

最低優先順序的 qos 等級是 besteffort 會分配給那些沒有(為任何容器)設定任何 requests 和 limits pod 。在個等級執行的容器沒有任何資源保證。在最壞情況下,它們分不到任何 cpu 時間,同時要為其他 pod 釋放記憶體時, 這些容器會第一批被殺死,不過因為 besteffortpod 沒有配置記憶體 limits,當有充足的可用記憶體時,這些容器可以使用任意多的記憶體

為 pod 分配 guaranteed 等級

與 burstable 相對的是 guaranteed 等級,會分配給那些所有資源 request 和 limits 相等的 pod。 對於乙個 guaranteed 級別的 pod ,有以下幾個條件:

因為如果容器的資源 request 沒有顯式設定,預設與 limits 相同,所以只設定所有資源(pod 內每個容器的每種資源)的限制量就可以使 pod 的 qos 等級為guaranteed。這些 pod 容器可以使用它所申請的等額資源,但是無法消耗更多的資源(因為它們的 limits 和 requests 相等)。

為 pod 分配 burstable 等級

burstable qos 級介於 besteffort guaranteed 之間。其他所有 pod 屬於這個等級。 包括容器的 requests 和 limits 不相同的單容器 pod ,至少有乙個容器只定義了 requests 但沒有定義 limits 的pod ,以及乙個容器的 request limits 相等,但是另乙個容器不指定 requests 或 limits 的 pod。burstable 可以獲得它們所申請的等額資源,並可以使用額外的資源(不超過 imits)。

在乙個超賣的系統,qos 等級決定著哪個容器第乙個被殺掉, 這樣釋放出的資源可以提供給高優先順序的 pod 使用。 besteffort 等級的 pod 首先被殺掉, 其次是 burstable pod, 最後是guaranteed pod。 guaranteed pod 只有在系統程序需要記憶體時才會被殺掉。

了解 qos 等級的優先順序

請看上圖中的例子。 假設兩個單容器的pod, 第乙個屬於besteffort qos 等級, 第二個屬於 burstable 等級。 當節點的全部記憶體已經用完, 還有程序嘗試申請更多的記憶體時,系統必須殺死其中乙個程序(甚至包括嘗試申請額外記憶體的程序)以兌現記憶體分配請求。這種情況下, besteffort 等級執行的程序會在 burstable 等級的程序之前被系統殺掉。

顯然, besteffort pod 的程序會在 guaranteed pod 的程序之前被殺掉 。 同樣地,burstable pod 的程序也先於 guaranteed pod 的程序被殺掉 。 但如果只有兩個 burstable pod 會發生什麼呢?很明顯需要選擇乙個優先於另 乙個的程序。

如何處理相同qos等級的容器

每個執行中的程序都有乙個稱為 outofmemory (oom)分數的值。 系統通過比較所有執行程序的 oom 分數來選擇要殺掉的程序。 當需要釋放記憶體時, 分數最高的程序將被殺死。

oom分數由兩個引數計算得出:程序已消耗記憶體佔可用記憶體的百分比, 與 乙個基於 pod qos等級和容器記憶體申請量固定的 oom 分數調節因子。 對於兩個屬於 burstable 等級的單容器的 pod ,系統會殺掉記憶體實際使用量佔記憶體申請量比例更高的 pod。 這就是圖中使用了記憶體申請量90%的 pod b 在 pod c(只使用了70%) 之前被殺掉的原因, 儘管 pod c 比 pod b 使用了更多兆位元組的記憶體 。

這說明我們不僅要注意 requets 和 limits 之間的關係, 還要留心 requests 和預期實際消耗記憶體之間的關係。

MTK資源管理

資源檔案生成的臨時檔案主要有 custmenutree out.c,這個檔案是選單臨時檔案,生成了我們的最終顯示的選單結構。如果你新增的選單沒有顯示,正常顯示的選單突然不顯示了或者顯示錯位了,或者顯示的選單與呼叫的功能不符合了,都可以從這裡查到原因。resource base table.txt這個...

MTK資源管理

使用mtk作開發,常常不可避免和資源打交道,常使用的資源有字串,字型,選單,風格,聲音等,mtk好像沒有系統的專門的資源管理工具,導 致資源管理十分凌亂而容易出問題,雖然有些牛人也開發了一些工具來管理這些資源,但由於使用不便或者其他一些原因,比如資源由大量的巨集控制,以及修改維護 的人多,還有一些其...

linux 資源管理

一 系統資源 網路資源 儲存資源,計算資源 二 系統資源管理名命令 1.檢視目錄下的檔案使用情況 du sh 目錄 檔案 注 du sh檢視的是目錄 檔案占用block塊的大小 ll h檢視檔案 目錄的本身大小 2.檢視檔案系統 格式化好的分割槽 的使用情況 df h 注 檢視檔案系統使用i節點的情...