k8s的資源管理

李世贊發(fā)布于2019-07-01 17:28 / 791人閱讀

摘要：中對容器的資源分配有三種策略。顧名思義是該容器對資源的最低要求和最高使用量限制。磁盤的使用不像有通過和進行配置，磁盤用量可以認為是一種策略為的資源。在這個時長范圍內(nèi)即便資源使用下降到閾值以下，也不會恢復(fù)。

QoS

k8s中對容器的資源分配有三種策略：

Guaranteed 。該策略下，pod.spec.containers[].resources中會存在cpu或memory的request和limit。顧名思義是該容器對資源的最低要求和最高使用量限制。如果我們配置了limit，沒有配置request，默認會以limit的值來定義request。具體的配置可以參考以前的這篇筆記。

BestEffort。當pod的描述文件中沒有resource.limit、resource.request相關(guān)的配置時，意味著這個容器想跑多少資源就跑多少資源，其資源使用上限實際上即所在node的capacity。

Burstable。當resource.limit和resource.request以上述兩種方式以外的形式配置的時候，就會采用本模式。

QoS目前只用cpu和memory來描述，其中cpu可壓縮資源，當一個容器的cpu使用率超過limit時會被進行流控，而當內(nèi)存超過limit時則會被oom_kill。這里kubelet是通過自己計算容器的oom_score，確認相應(yīng)的linux進程的oom_adj，oom_adj最高的進程最先被oom_kill。
Guaranteed模式的容器oom_score最?。?998，對應(yīng)的oom_adj為0或1，BestEffort模式則是1000，Burstable模式的oom_score隨著其內(nèi)存使用狀況浮動，但會處在2-1000之間。

因此我們可以看出，當某個node內(nèi)存被嚴重消耗時，BestEffort策略的pod會最先被kubelet殺死，其次Burstable（該策略的pods如有多個，也是按照內(nèi)存使用率來由高到低地終止），再其次Guaranteed。

kubelet的eviction機制

完全依賴于oom_kill并不是一個很好的方案，一來對于cpu要求高的容器沒有作用，二來單純將pod殺死，并不能根本上解決困局，比如pod占用node絕大部分內(nèi)存，加入pod被kill后再次調(diào)度到這個node上，oom的情況還會復(fù)現(xiàn)。所以kubelet增加了一套驅(qū)逐機制。
eviction機制適用于：
memory.available 、nodefs.available 、nodefs.inodesFree 、imagefs.available 、imagefs.inodesFree
分別對應(yīng)于node目前可用內(nèi)存、node上用于kubelet運行日志、容器掛載磁盤所使用的的文件系統(tǒng)的余量和inode余量、node上用于存放容器鏡像和讀寫層的文件系統(tǒng)的余量、inode余量。

eviction中要設(shè)置觸發(fā)驅(qū)逐的閾值Eviction Thresholds，這個閾值的配置可以是一個定值或一個百分比。如：
memory.available<10%
memory.available<1Gi

Soft Eviction Thresholds

軟驅(qū)逐機制表示，當node的內(nèi)存/磁盤空間達到一定的閾值后，我要觀察一段時間，如果改善到低于閾值就不進行驅(qū)逐，若這段時間一直高于閾值就進行驅(qū)逐。
這里閾值通過參數(shù)--eviction-soft配置，樣例如上；觀察時間通過參數(shù)--eviction-soft-grace-period進行配置，如1m30s。
另外還有一個參數(shù)eviction-max-pod-grace-period，該參數(shù)會影響到要被驅(qū)逐的pod的termination time，即終止該pod的容器要花費的時間。

Hard Eviction Thresholds

強制驅(qū)逐機制則簡單的多，一旦達到閾值，立刻把pod從本地kill，驅(qū)逐eviction-hard參數(shù)配置，樣例亦如上。

pod eviction

當資源使用情況觸發(fā)了驅(qū)逐條件時，kubelet會啟動一個任務(wù)去輪流停止運行中的pod，直到資源使用狀況恢復(fù)到閾值以下。以硬驅(qū)逐為例，整體流程是：

每隔一段時間從cadvisor中獲取資源使用情況，發(fā)現(xiàn)觸發(fā)了閾值；

從運行中的pod里找到QoS策略最開放的一個，比如策略為bestEffort的一個pod（即便這個pod沒有吃多少內(nèi)存，大部分內(nèi)存是另一個策略為burstable，但內(nèi)存使用率也很高的pod），kubelet停止該pod對應(yīng)的所有容器，然后將pod狀態(tài)更新為Failed。如果該pod長時間沒有被成功kill掉，kubelet會再找一個pod進行驅(qū)逐。

檢查內(nèi)存用量是否恢復(fù)到閾值以下，如果沒有，則重復(fù)第二步（這里就要干掉那個罪魁禍首了）。一直到內(nèi)存使用情況恢復(fù)到閾值以下為止。

有幾個要注意的點是：

kubelet挑選pod進行驅(qū)逐的策略，就是按照QoS的策略開放度排序，而同一個QoS的多個pod中，kubelet會優(yōu)先驅(qū)逐使用觸發(fā)指標資源最多的一個。

磁盤的使用不像memory有通過request和limit進行配置，磁盤用量可以認為是一種QoS策略為BestEffort的資源。當觸發(fā)磁盤資源不足時，kubelet會做一些額外的工作，比如清理已經(jīng)dead的pod的容器日志，清理沒有被使用的容器鏡像，當然kubelet也會挑磁盤使用量（包括掛載本地volume空間+容器log大小,若是imagefs指標超額，此處還要加上容器運行時讀寫層的文件大?。┳畲蟮囊粋€pod進行驅(qū)逐。

node condition

如上圖，當軟驅(qū)逐或者硬驅(qū)逐觸發(fā)時，kubelet會嘗試干掉一個pod，并且會將自身的狀態(tài)從驅(qū)逐的指標信息中映射過來，比如內(nèi)存使用超標觸發(fā)驅(qū)逐，node的condtion就會變成memoryPressure，這個condition伴隨的kubelet定時的心跳報文上傳到master，記錄在etcd中。在調(diào)度器進行調(diào)度時，會以這些condition作為調(diào)度條件的參考。比如，處于diskPressure的node，調(diào)度器就不會再將任何pod調(diào)度上去。否則一旦磁盤空間用滿，node上的容器可能會嚴重崩潰。

但如果node的內(nèi)存在閾值上下波動，condition被反復(fù)更新為pressure或正常，那么pod被誤調(diào)度到node上也會很耽誤事，所以用eviction-pressure-transition-period參數(shù)指定觸發(fā)eviction后condition更新一次后要保留改狀態(tài)的最小時長。在這個時長范圍內(nèi)即便資源使用下降到閾值以下，condition也不會恢復(fù)。

其他

Minimum eviction reclaim 我們擔(dān)心node可能驅(qū)逐了一個小pod后，指標就只是稍低于閾值，那么一旦其他pod的指標稍一上來，該node就又要進行eviction。所以用這個參數(shù)：
--eviction-minimum-reclaim(值如"memory.available=0Mi,nodefs.available=500Mi,imagefs.available=2Gi")進行限定，一旦發(fā)生了eviction，必須要保證node的某指標用量低于（該指標閾值-本參數(shù)指定的該指標值）才認為node恢復(fù)正常，否則還要接著驅(qū)逐pod。
簡單的說，該參數(shù)表示的是node進行驅(qū)逐工作后要達到的效果是低于閾值多少。