資訊專欄INFORMATION COLUMN
摘要：中對容器的資源分配有三種策略。顧名思義是該容器對資源的最低要求和最高使用量限制。磁盤的使用不像有通過和進行配置，磁盤用量可以認為是一種策略為的資源。在這個時長范圍內即便資源使用下降到閾值以下，也不會恢復。
QoS
k8s中對容器的資源分配有三種策略：
Guaranteed 。該策略下，pod.spec.containers[].resources中會存在cpu或memory的request和limit。顧名思義是該容器對資源的最低要求和最高使用量限制。如果我們配置了limit，沒有配置request，默認會以limit的值來定義request。具體的配置可以參考以前的這篇筆記。
BestEffort。當pod的描述文件中沒有resource.limit、resource.request相關的配置時，意味著這個容器想跑多少資源就跑多少資源，其資源使用上限實際上即所在node的capacity。
Burstable。當resource.limit和resource.request以上述兩種方式以外的形式配置的時候，就會采用本模式。
QoS目前只用cpu和memory來描述，其中cpu可壓縮資源，當一個容器的cpu使用率超過limit時會被進行流控，而當內存超過limit時則會被oom_kill。這里kubelet是通過自己計算容器的oom_score，確認相應的linux進程的oom_adj，oom_adj最高的進程最先被oom_kill。
Guaranteed模式的容器oom_score最小：-998，對應的oom_adj為0或1，BestEffort模式則是1000，Burstable模式的oom_score隨著其內存使用狀況浮動，但會處在2-1000之間。
因此我們可以看出，當某個node內存被嚴重消耗時，BestEffort策略的pod會最先被kubelet殺死，其次Burstable（該策略的pods如有多個，也是按照內存使用率來由高到低地終止），再其次Guaranteed。
kubelet的eviction機制完全依賴于oom_kill并不是一個很好的方案，一來對于cpu要求高的容器沒有作用，二來單純將pod殺死，并不能根本上解決困局，比如pod占用node絕大部分內存，加入pod被kill后再次調度到這個node上，oom的情況還會復現。所以kubelet增加了一套驅逐機制。
eviction機制適用于：
memory.available 、nodefs.available 、nodefs.inodesFree 、imagefs.available 、imagefs.inodesFree
分別對應于node目前可用內存、node上用于kubelet運行日志、容器掛載磁盤所使用的的文件系統的余量和inode余量、node上用于存放容器鏡像和讀寫層的文件系統的余量、inode余量。
eviction中要設置觸發驅逐的閾值Eviction Thresholds，這個閾值的配置可以是一個定值或一個百分比。如：
memory.available<10%
memory.available<1Gi
軟驅逐機制表示，當node的內存/磁盤空間達到一定的閾值后，我要觀察一段時間，如果改善到低于閾值就不進行驅逐，若這段時間一直高于閾值就進行驅逐。
這里閾值通過參數--eviction-soft配置，樣例如上；觀察時間通過參數--eviction-soft-grace-period進行配置，如1m30s。
另外還有一個參數eviction-max-pod-grace-period，該參數會影響到要被驅逐的pod的termination time，即終止該pod的容器要花費的時間。
強制驅逐機制則簡單的多，一旦達到閾值，立刻把pod從本地kill，驅逐eviction-hard參數配置，樣例亦如上。
pod eviction當資源使用情況觸發了驅逐條件時，kubelet會啟動一個任務去輪流停止運行中的pod，直到資源使用狀況恢復到閾值以下。以硬驅逐為例，整體流程是：
每隔一段時間從cadvisor中獲取資源使用情況，發現觸發了閾值；
從運行中的pod里找到QoS策略最開放的一個，比如策略為bestEffort的一個pod（即便這個pod沒有吃多少內存，大部分內存是另一個策略為burstable，但內存使用率也很高的pod），kubelet停止該pod對應的所有容器，然后將pod狀態更新為Failed。如果該pod長時間沒有被成功kill掉，kubelet會再找一個pod進行驅逐。
檢查內存用量是否恢復到閾值以下，如果沒有，則重復第二步（這里就要干掉那個罪魁禍首了）。一直到內存使用情況恢復到閾值以下為止。
有幾個要注意的點是：
kubelet挑選pod進行驅逐的策略，就是按照QoS的策略開放度排序，而同一個QoS的多個pod中，kubelet會優先驅逐使用觸發指標資源最多的一個。
磁盤的使用不像memory有通過request和limit進行配置，磁盤用量可以認為是一種QoS策略為BestEffort的資源。當觸發磁盤資源不足時，kubelet會做一些額外的工作，比如清理已經dead的pod的容器日志，清理沒有被使用的容器鏡像，當然kubelet也會挑磁盤使用量（包括掛載本地volume空間+容器log大小,若是imagefs指標超額，此處還要加上容器運行時讀寫層的文件大小）最大的一個pod進行驅逐。
node condition
如上圖，當軟驅逐或者硬驅逐觸發時，kubelet會嘗試干掉一個pod，并且會將自身的狀態從驅逐的指標信息中映射過來，比如內存使用超標觸發驅逐，node的condtion就會變成memoryPressure，這個condition伴隨的kubelet定時的心跳報文上傳到master，記錄在etcd中。在調度器進行調度時，會以這些condition作為調度條件的參考。比如，處于diskPressure的node，調度器就不會再將任何pod調度上去。否則一旦磁盤空間用滿，node上的容器可能會嚴重崩潰。
但如果node的內存在閾值上下波動，condition被反復更新為pressure或正常，那么pod被誤調度到node上也會很耽誤事，所以用eviction-pressure-transition-period參數指定觸發eviction后condition更新一次后要保留改狀態的最小時長。在這個時長范圍內即便資源使用下降到閾值以下，condition也不會恢復。
其他Minimum eviction reclaim 我們擔心node可能驅逐了一個小pod后，指標就只是稍低于閾值，那么一旦其他pod的指標稍一上來，該node就又要進行eviction。所以用這個參數：
--eviction-minimum-reclaim(值如"memory.available=0Mi,nodefs.available=500Mi,imagefs.available=2Gi")進行限定，一旦發生了eviction，必須要保證node的某指標用量低于（該指標閾值-本參數指定的該指標值）才認為node恢復正常，否則還要接著驅逐pod。
簡單的說，該參數表示的是node進行驅逐工作后要達到的效果是低于閾值多少。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/33037.html
摘要：將用戶命令通過接口傳送給，從而進行資源的增刪改等操作。要使用編寫應用程序，當下大多語言都可以很方便地去實現請求來操作的接口從而控制和查詢資源，但本文主要是利用已有的客戶端來更加優雅地實現的資源控制。 showImg(https://segmentfault.com/img/remote/1460000013517345); 【利用K8S技術棧打造個人私有云系列文章目錄】 利用K8S...
摘要：將用戶命令通過接口傳送給，從而進行資源的增刪改等操作。要使用編寫應用程序，當下大多語言都可以很方便地去實現請求來操作的接口從而控制和查詢資源，但本文主要是利用已有的客戶端來更加優雅地實現的資源控制。 showImg(https://segmentfault.com/img/remote/1460000013517345); 【利用K8S技術棧打造個人私有云系列文章目錄】 利用K8S...
摘要：去年換工作后，開始真正在生產環境中接觸容器與。今天想先談談，我理解的容器是什么，以及為什么它們能火起來。一個容器鏡像的實質就是程序進程加所有運行時環境及配置依賴的集合。這里再談談我理解的。而，就是目前的容器編排的平臺的事實標準了。 去年換工作后，開始真正在生產環境中接觸容器與Kubernetes。邊惡補相關知識的同時，也想把學到的內容和自己的理解整理出來。學習的途徑包括k8s官方文檔...
摘要：去年換工作后，開始真正在生產環境中接觸容器與。今天想先談談，我理解的容器是什么，以及為什么它們能火起來。一個容器鏡像的實質就是程序進程加所有運行時環境及配置依賴的集合。這里再談談我理解的。而，就是目前的容器編排的平臺的事實標準了。 去年換工作后，開始真正在生產環境中接觸容器與Kubernetes。邊惡補相關知識的同時，也想把學到的內容和自己的理解整理出來。學習的途徑包括k8s官方文檔...
摘要：如版本之前版本到版本之間版本之后一各種的含義該軟件可能包含錯誤。啟用一個功能可能會導致隨時可能會丟棄對該功能的支持，恕不另行通知軟件經過很好的測試。啟用功能被認為是安全的。 本篇文章來自Terraform與Kubernetes中關于Deployment apps/v1的吐槽 Kubernetes的官方文檔中并沒有對apiVersion的詳細解釋，而且因為K8S本身版本也在快速迭代，有些...
摘要：但考慮到該用戶在跨集群模式下的困擾，開始策劃將托管云物理機納入現有集群統一管理的方案，即在混合云架構下僅需部署管理一套集群。托管云物理機納入UK8S集群統一管理后，可實現托管云物理機保障平峰時業務正常運行，高峰時期利用UK8S快速擴容公有云資源的理想應用場景，繼而提升混合云的可用性。 ——海豹他趣技術負責人 張嵩 混合云的業務模式 廈門海豹他趣信息技術股份有限公司于2012年4...
閱讀 2053·2021-11-11 16:55
閱讀 1395·2021-09-28 09:36
閱讀 1038·2019-08-29 15:21
閱讀 1571·2019-08-29 14:10
閱讀 2757·2019-08-29 14:08
閱讀 1628·2019-08-29 12:31
閱讀 3243·2019-08-29 12:31
閱讀 976·2019-08-26 16:47
