Kuberntes 服務質量保證（QoS）_Kubernetes中文社群
【編者的話】Kubernetes做為目前主流的容器叢集管理平臺，需要整體統籌平臺資源使用情況、公平合理的將資源分配給相關pod容器使用，並且要保證容器生命週期內有足夠的資源來保證其執行。 與此同時，由於資源發放的獨佔性，即資源已經分配給了某容器，同樣的資源不會在分配給其他容器，對於資源利用率相對較低的容器來說，佔用資源卻沒有實際使用（比如CPU、記憶體）造成了嚴重的資源浪費，Kubernetes需從優先順序與公平性等角度提高資源的利用率。為了實現資源被有效排程和分配的同時提高資源利用率，Kubernetes針對不同服務質量的預期，通過QoS來對pod進行服務質量管理，提供了個採用requests
設定資源限制的原因
如果未做過節點 nodeSelector，親和性（node affinity）或pod親和、反親和性（pod affinity/anti-affinity）等Pod高階排程策略 設定，我們沒有辦法指定服務部署到指定機器上，如此可能會造成cpu或記憶體等密集型的pod同時分配到相同Node，造成資源競爭。另一方面，如果未對資源進行限制，一些關鍵的服務可能會因為資源競爭因OOM等原因被kill掉，或者被限制CPU使用。
資源需求（Requests）和限制（ Limits）
對於每一個資源，container可以指定具體的資源需求（requests）和限制（limits），requests申請範圍是0到node節點的最大配置，而limits申請範圍是requests到無限，即0 <= requests <=Node Allocatable, requests <= limits <= Infinity。
對於CPU，如果pod中服務使用CPU超過設定的limits，pod不會被kill掉但會被限制。如果沒有設定limits，pod可以使用全部空閒的cpu資源。
對於記憶體，當一個pod使用記憶體超過了設定的limits
QoS分類
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）。
containers: name: foo resources: limits: cpu: 10m memory: 1Gi name: bar resources: limits: cpu: 100m memory: 100Mi
Guaranteed舉例2：requests與limit均指定且值相等。
containers: name: foo resources: limits: cpu: 10m memory: 1Gi requests: cpu: 10m memory: 1Gi name: bar resources: limits: cpu: 100m memory: 100Mi requests: cpu: 100m memory: 100Mi
Burstable: pod中只要有一個容器的requests和limits的設定不相同，該pod的QoS即為Burstable。舉例如下：
Container bar沒有指定resources
containers: name: foo resources: limits: cpu: 10m memory: 1Gi requests: cpu: 10m memory: 1Gi name: bar
Burstable舉例2：對Container foo與bar不同的resources（foo為memory，而bar為cpu）設定了limits。
containers: name: foo resources: limits: memory: 1Gi name: bar resources: limits: cpu: 100m
Burstable舉例3：Container foo沒有設定limits，而bar requests與 limits均未設定。
containers: name: foo resources: requests: cpu: 10m memory: 1Gi name: bar
Best-Effort：如果對於全部的resources來說requests與limits均未設定，該pod的QoS即為Best-Effort。舉例如下：
containers: name: foo resources: name: bar resources:
可壓縮資源與不可壓縮資源
Kubernetes根據資源能否伸縮排行分類，劃分為可壓縮資源和不可以壓縮資源2種。CPU資源是目前支援的一種可壓縮資源，而記憶體資源和磁碟資源為目前所支援的不可壓縮資源。
QoS優先順序
3種QoS優先順序從有低到高（從左向右）：
Best-Effort pods -> Burstable pods -> Guaranteed pods
靜態pod
在Kubernetes中有一種DaemonSet型別pod，此型別pod可以在某個節點上長期執行，由該節點上的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。
不可壓縮資源記憶體：當Node 記憶體資源不足時，那麼就會有程序因OOM會被kernel kill掉，3種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