kubernetes做為目前主流的容器集群管理平台，需要整體統籌平台資源使用情況、公平合理的將資源分配給相關pod容器使用，並且要保證容器生命週期內有足夠的資源來保證其執行。 與此同時，由於資源發放的獨占性，即資源已經分配給了某容器，同樣的資源不會在分配給其他容器，對於資源利用率相對較低的容器來說，占用資源卻沒有實際使用（比如cpu、記憶體）造成了嚴重的資源浪費，kubernetes需從優先順序與公平性等角度提高資源的利用率。為了實現資源被有效排程和分配的同時提高資源利用率，kubernetes針對不同服務質量的預期，通過qos來對pod進行服務質量管理，提供了個採用requests和limits兩種型別對資源進行分配和使用限制。對於乙個pod來說，服務質量體現在兩個為2個具體的指標： cpu與記憶體。實際過程中，當node節點上記憶體資源緊張時，kubernetes會根據預先設定的不同qos類別進行相應處理。
如果未做過節點 nodeselector，親和性（node affinity）或pod親和、反親和性（pod affinity/anti-affinity）等pod高階排程策略 設定，我們沒有辦法指定服務部署到指定機器上，如此可能會造成cpu或記憶體等密集型的pod同時分配到相同node，造成資源競爭。另一方面，如果未對資源進行限制，一些關鍵的服務可能會因為資源競爭因oom等原因被kill掉，或者被限制cpu使用。
對於每乙個資源，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，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）。
containersguaranteed舉例2：requests與limit均指定且值相等。:name
:foo
resources
:limits
:cpu
:10m
memory
:1gi
name
:bar
resources
:limits
:cpu
:100m
memory
:100mi
containersburstable: pod中只要有乙個容器的requests和limits的設定不相同，該pod的qos即為burstable。舉例如下：: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
container bar沒有指定resources
containersburstable舉例2：對container foo與bar不同的resources（foo為memory，而bar為cpu）設定了limits。:name
:foo
resources
:limits
:cpu
:10m
memory
:1gi
requests
:cpu
:10m
memory
:1gi
name
:bar
containersburstable舉例3：container foo沒有設定limits，而bar requests與 limits均未設定。:name
:foo
resources
:limits
:memory
:1gi
name
:bar
resources
:limits
:cpu
:100m
containersbest-effort：如果對於全部的resources來說requests與limits均未設定，該pod的qos即為best-effort。舉例如下：:name
:foo
resources
:requests
:cpu
:10m
memory
:1gi
name
:bar
containerskubernetes根據資源能否伸縮進行分類，劃分為可壓縮資源和不可以壓縮資源2種。cpu資源是目前支援的一種可壓縮資源，而記憶體資源和磁碟資源為目前所支援的不可壓縮資源。:name
:foo
resources
:name
:bar
resources
:
3種qos優先順序從有低到高（從左向右）：
best在kubernetes中有一種daemonset型別pod，此型別pod可以在某個節點上長期執行，由該節點上的kubelet服務直接管理，無需api server介入，靜態pod也無需關聯任何rc，完全是由kubelet服務來監控，當kubelet發現靜態pod停止時，kubelet會重新啟動靜態pod。-effort
pods
->
burstable
pods
->
guaranteed
pods
當kubernetes集群中某個節點上可用資源比較小時，kubernetes提供了資源**策略來保證節點以此pod中服務正常執行。當節點上的記憶體或者cpu資源耗盡時，排程到該節點上執行的pod服務可能會不穩定。kubernetes通過kubelet來進行**策略控制，保證節點上pod在節點資源比較小時可以穩定執行。
可壓縮資源cpu
：在壓縮資源部分已經提到cpu屬於可壓縮資源，當pod使用超過設定的limits值，pod中程序使用cpu會被限制，但不會被kill。
不可壓縮資源記憶體
：當node 記憶體資源不足時，那麼就會有程序因oom會被kernel kill掉，3種qos pods被kill掉的順序與場景如下：
注：如果pod程序因使用超過預先設定的limites而非node資源緊張情況，系統傾向於在其原所在的機器上重啟該container或本機或其他重新建立乙個pod。
不支援swap
本文**中文社群-kuberntes 服務質量保證（qos）
軟體質量保證
一 軟體質量的概念 概括的說 軟體質量就是 軟體與明確地和隱含地定義的要求相一致的程度 具體的說 軟體質量是軟體與明確地敘述的功能和效能需求 文件中明確描述的開發標準以及任何專業開發的軟體產品都應該具有的隱含特性相一致的程度。有3個要點 1 軟體需求是度量軟體質量的基礎，與需求不一致就質量不高。2 ...
軟體質量保證 軟體質量
這篇博文將較為全面深入地談談軟體質量保證中關於軟體質量的概念，內容等相關問題。關於質量的定義，不同的領域，不同的人，不同的側重點會得出截然不同的結果。因此關於其質量的基礎概念相對而言較為好理解，但是具體如何去定義實際上確是無關緊要的。不過我們在分析軟體質量的時候，不僅要考慮其面向使用者的需求覆蓋率，...
程式設計規範 質量保證
1 正確性，指程式要實現設計要求的功能。2 穩定性 安全性，指程式穩定 可靠 安全。3 可測試性，指程式要具有良好的可測試性。4 規範 可讀性，指程式書寫風格 命名規則等要符合規範。5 全域性效率，指軟體系統的整體效率。6 區域性效率，指某個模組 子模組 函式的本身效率。7 個人表達方式 個人方便性...