Kubernetes之服務品質保證（QoS）

本文講的是<b>Kubernetes之服務品質保證（QoS）</b>【編者的話】Kubernetes做為目前主流的容器叢集管理平台，需要整體統籌平台資源使用情況、公平合理的将資源配置設定給相關pod容器使用，并且要保證容器生命周期内有足夠的資源來保證其運作。 與此同時，由于資源發放的獨占性，即資源已經配置設定給了某容器，同樣的資源不會在配置設定給其他容器，對于資源使用率相對較低的容器來說，占用資源卻沒有實際使用（比如CPU、記憶體）造成了嚴重的資源浪費，Kubernetes需從優先級與公平性等角度提高資源的使用率。為了實作資源被有效排程和配置設定的同時提高資源使用率，Kubernetes針對不同服務品質的預期，通過QoS（Quality of Service）來對pod進行服務品質管理，提供了個采用requests和limits兩種類型對資源進行配置設定和使用限制。對于一個pod來說，服務品質展現在兩個為2個具體的名額： CPU與記憶體。實際過程中，當NODE節點上記憶體資源緊張時，kubernetes會根據預先設定的不同QoS類别進行相應處理。

對于每一個資源，container可以指定具體的資源需求（requests）和限制（limits），requests申請範圍是0到node節點的最大配置，而limits申請範圍是requests到無限，即0 &lt;= requests &lt;=Node Allocatable, requests &lt;= limits &lt;= Infinity。

對于CPU，如果pod中服務使用CPU超過設定的limits，pod不會被kill掉但會被限制。如果沒有設定limits，pod可以使用全部空閑的cpu資源。

對于記憶體，當一個pod使用記憶體超過了設定的limits，pod中container的程序會被kernel因OOM kill掉。當container因為OOM被kill掉時，系統傾向于在其原所在的機器上重新開機該container或本機或其他重新建立一個pod。

Kubelet提供QoS服務品質管理，支援系統級别的OOM控制。在Kubernetes中，pod的QoS級别：Guaranteed, Burstable與 Best-Effort。下面對各級别分别進行相應說明：

Guaranteed：pod中所有容器都必須統一設定limits，并且設定參數都一緻，如果有一個容器要設定requests，那麼所有容器都要設定，并設定參數同limits一緻，那麼這個pod的QoS就是Guaranteed級别。

注：如果一個容器隻指明limit而未設定request，則request的值等于limit值。

Guaranteed舉例1：容器隻指明了limits而未指明requests）。

Guaranteed舉例2：requests與limit均指定且值相等。

Burstable: pod中隻要有一個容器的requests和limits的設定不相同，該pod的QoS即為Burstable。舉例如下：

Container bar沒有指定resources

Burstable舉例2：對Container foo與bar不同的resources（foo為memory，而bar為cpu）設定了limits。

Burstable舉例3：Container foo沒有設定limits，而bar requests與 limits均未設定。

Best-Effort：如果對于全部的resources來說requests與limits均未設定，該pod的QoS即為Best-Effort。舉例如下：

Kubernetes根據資源能否伸縮進行分類，劃分為可壓縮資源和不可以壓縮資源2種。CPU資源是目前支援的一種可壓縮資源，而記憶體資源和磁盤資源為目前所支援的不可壓縮資源。

3種QoS優先級從有低到高（從左向右）：

在Kubernetes中有一種DaemonSet類型pod，此類型pod可以常駐某個Node運作，由該Node上kubelet服務直接管理而無需api server介入。靜态pod也無需關聯任何RC，完全由kubelet服務來監控，當kubelet發現靜态pod停止時，kubelet會重新啟動靜态pod。

當kubernetes叢集中某個節點上可用資源比較小時，kubernetes提供了資源回收政策保證被排程到該節點pod服務正常運作。當節點上的記憶體或者CPU資源耗盡時，可能會造成該節點上正在運作的pod服務不穩定。Kubernetes通過kubelet來進行回收政策控制，保證節點上pod在節點資源比較小時可以穩定運作。

可壓縮資源：CPU

在壓縮資源部分已經提到CPU屬于可壓縮資源，當pod使用超過設定的limits值，pod中程序使用cpu會被限制，但不會被kill。

不可壓縮資源：記憶體

Kubernetes通過cgroup給pod設定QoS級别，當資源不足時先kill優先級低的pod，在實際使用過程中，通過OOM分數值來實作，OOM分數值從0-1000。

OOM分數值根據OOM_ADJ參數計算得出，對于Guaranteed級别的pod，OOM_ADJ參數設定成了-998，對于BestEffort級别的pod，OOM_ADJ參數設定成了1000，對于Burstable級别的POD，OOM_ADJ參數取值從2到999。對于kuberntes保留資源，比如kubelet，docker，OOM_ADJ參數設定成了-999，表示不會被OOM kill掉。OOM_ADJ參數設定的越大，通過OOM_ADJ參數計算出來OOM分數越高，表明該pod優先級就越低，當出現資源競争時會越早被kill掉，對于OOM_ADJ參數是-999的表示kubernetes永遠不會因為OOM而被kill掉。

QoS pods被kill掉場景與順序 

Best-Effort 類型的pods：系統用完了全部記憶體時，該類型pods會最先被kill掉。

Burstable類型pods：系統用完了全部記憶體，且沒有Best-Effort container可以被kill時，該類型pods會被kill掉。

Guaranteed pods：系統用完了全部記憶體、且沒有Burstable與Best-Effort container可以被kill，該類型的pods會被kill掉。

注：如果pod程序因使用超過預先設定的limites而非Node資源緊張情況，系統傾向于在其原所在的機器上重新開機該container或本機或其他重新建立一個pod。

如果資源充足，可将QoS pods類型均設定為Guaranteed。用計算資源換業務性能和穩定性，減少排查問題時間和成本。

如果想更好的提高資源使用率，業務服務可以設定為Guaranteed，而其他服務根據重要程度可分别設定為Burstable或Best-Effort，例如filebeat。

不支援swap，目前的QoS政策假設swap已被禁止。

歡迎轉載，請注明作者出處：張夏，FreeWheel Lead Engineer，DockOne社群

原文釋出時間為：2017-08-16

本文作者：張夏

本文來自雲栖社群合作夥伴Dockerone.io，了解相關資訊可以關注Dockerone.io。

原文标題：Kubernetes之服務品質保證（QoS）