一 資源管理
1.1 資源調度機制
對於Kubernetes資源，有兩個重要參數：CPU Request與Memory Request。
通常在定義Pod時並沒有定義這兩個參數，此時Kubernetes會認為該Pod所需的資源很少，並可以將其調度到任何可用的Node上。因此，當集群中的計算資源不很充足時，如果集群中的Pod負載突然增大，就會使某個Node的資源嚴重不足。為了避免Node系統掛掉，該Node會選擇“清理”某些Pod來釋放資源，此時每個Pod都可能被“清理”。若其中某些Pod非常重要，比如與數據存儲相關的、與登錄相關的、與查詢余額相關的，需要在系統資源嚴重不足時，也得保障這些Pod的存活。
Kubernetes中該保障機制的核心如下：
- 通過資源限額來確保不同的Pod只能占用指定的資源。
- 允許集群的資源被超額分配，以提高集群的資源利用率。
- 為Pod划分等級，確保不同等級的Pod有不同的服務質量（QoS），資源不足時，低等級的Pod會被清理，以確保高等級的Pod穩定運行。
Kubernetes集群里的節點提供的資源主要是計算資源，計算資源是可計量的能被申請、分配和使用的基礎資源，這使之區別於API資源（API Resources，例如Pod和Services等）。
當前Kubernetes集群中的計算資源主要包括CPU、GPU及Memory，通常絕大多數常規應用不需要GPU資源。CPU與Memory是被Pod使用的，因此在配置Pod時可以通過參數CPU Request及Memory Request為其中的每個容器指定所需使用的CPU與Memory量，Kubernetes會根據Request的值去查找有足夠資源的Node來調度此Pod，如果沒有相應的Node能滿足，則調度失敗。
通常，一個程序所使用的CPU與Memory是一個動態的量，確切地說，是一個范圍，跟它的負載密切相關：負載增加時，CPU和Memory的使用量也會增加。因此最准確的說法是，某個進程的CPU使用量為0.1個CPU～1個CPU，內存占用則為500MB～1GB。對應到Kubernetes的Pod容器上，就是下面這4個參數：
- spec.container[].resources.requests.cpu
- spec.container[].resources.limits.cpu
- spec.container[].resources.requests.memory
- spec.container[].resources.limits.memory
其中，limits對應資源量的上限，即最多允許使用這個上限的資源量。由於CPU資源是可壓縮的，進程無論如何也不可能突破上限，因此設置起來比較容易。對於Memory這種不可壓縮資源來說，需要進行一定的規划，若設置得小了，當進程在業務繁忙期試圖請求超過Limit限制的Memory時，此進程就會被Kubernetes殺掉。因此，Memory的Request與Limit的值需要結合進程的實際需求謹慎設置。
1.2 批量設置
若存在成百上千個不同的Pod，那么先手動設置每個Pod的這4個參數，再檢查並確保這些參數的設置是否合理。比如不能出現內存超過2GB或者CPU占據2個核心的Pod。最后需要手工檢查不同租戶（Namespace）下的Pod的資源使用量是否超過限額。
若上設置相對繁瑣復雜，為此，Kubernetes提供了另外兩個相關對象：LimitRange及ResourceQuota，前者解決request與limit參數的默認值和合法取值范圍等問題，后者則解決約束租戶的資源配額問題。集群管理涉及計算資源管理（ComputeResources）、服務質量管理（QoS）、資源配額管理（LimitRange、ResourceQuota）等方面。
ResourceQoS解讀：若不設置CPU或Memory的Limit值，該Pod的資源使用量有一個彈性范圍，假設Pod A的Memory Request被設置為1GB，Node A當時空閑的Memory為1.2GB，符合Pod A的需求，因此Pod A被調度到Node A上。運行3天后，Pod A的訪問請求大增，內存需要增加到1.5GB，此時Node A的剩余內存只有200MB，由於Pod A新增的內存已經超出系統資源，所以在這種情況下，Pod A就會被Kubernetes殺掉。沒有設置Limit的Pod，或者只設置了CPULimit或者MemoryLimit兩者之一的Pod，表面看都是很有彈性的，但實際上，相對於4個參數都被設置的Pod，是處於一種相對不穩定的狀態的，它們與4個參數都沒設置的Pod相比，只是穩定一點而已。
二 計算資源管理
2.1 Requests和Limits
以CPU為例，下圖顯示了未設置Limits和設置了Requests、Limits的CPU使用率的區別。
盡管Requests和Limits只能被設置到容器上，但是設置Pod級別的Requests和Limits能大大提高管理Pod的便利性和靈活性，因此在Kubernetes中提供了對Pod級別的Requests和Limits的配置。對於CPU和內存而言，Pod的Requests或Limits是指該Pod中所有容器的Requests或Limits的總和（對於Pod中沒有設置Requests或Limits的容器，該項的值被當作0或者按照集群配置的默認值來計算）。
2.2 CPU和Memory計算
CPU的Requests和Limits是通過CPU數（cpus）來度量的。CPU的資源值是絕對值，而不是相對值，比如0.1CPU在單核或多核機器上是一樣的，都嚴格等於0.1CPUcore。
Memory內存的Requests和Limits計量單位是字節數。使用整數或者定點整數加上國際單位制來表示內存值。國際單位制包括十進制的E、P、T、G、M、K、m，或二進制的Ei、Pi、Ti、Gi、Mi、Ki。KiB與MiB是以二進制表示的字節單位，常見的KB與MB則是以十進制表示的字節單位，比如：
- 1KB（KiloByte）= 1000Bytes = 8000Bits
- 1KiB（KibiByte）= 2^10Bytes = 1024Bytes = 8192Bits
因此，128974848、129e6、129M、123Mi的內存配置是一樣的。
Kubernetes的計算資源單位是大小寫敏感的，因為m可以表示千分之一單位（milliunit），而M可以表示十進制的1000，二者的含義不同；同理，小寫的k不是一個合法的資源單位。
示例1：
[root@k8smaster01 study]# vi requests01.yaml
1 apiVersion: v1 2 kind: Pod 3 metadata: 4 name: frontend 5 spec: 6 continers: 7 - name: db 8 image: mysql 9 resources: 10 requests: 11 memory: "64Mi" 12 cpu: "250m" 13 limits: 14 memory: "128Mi" 15 cpu: "500m" 16 - name: wp 17 image: wordpress 18 resources: 19 requests: 20 memory: "64Mi" 21 cpu: "250m" 22 limits: 23 memory: "128Mi" 24 cpu: "500m" 25
解讀：如上所示，該Pod包含兩個容器，每個容器配置的Requests都是0.25CPU和64MiB（226 Bytes）內存，而配置的Limits都是0.5CPU和
128MiB（227 Bytes）內存。
這個Pod的Requests和Limits等於Pod中所有容器對應配置的總和，所以Pod的Requests是0.5CPU和128MiB（227 Bytes）內存，Limits是1CPU和256MiB（228 Bytes）內存。
2.3 Requests和Limits的Pod調度機制
當一個Pod創建成功時，Kubernetes調度器（Scheduler）會為該Pod選擇一個節點來執行。對於每種計算資源（CPU和Memory）而言，每個節點都有一個能用於運行Pod的最大容量值。調度器在調度時，首先要確保調度后該節點上所有Pod的CPU和內存的Requests總和，不超過該節點能提供給Pod使用的CPU和Memory的最大容量值。
例如，某個節點上的CPU資源充足，而內存為4GB，其中3GB可以運行Pod，而某Pod的Memory Requests為1GB、Limits為2GB，那么在這個節點上最多可以運行3個這樣的Pod。假設該節點已經啟動3個此Pod實例，而這3個Pod的實際內存使用都不足500MB，那么理論上該節點的可用內存應該大於1.5GB。但是由於該節點的Pod Requests總和已經達到節點的可用內存上限，因此Kubernetes不會再將任何Pod實例調度到該節點上。
注意：可能某節點上的實際資源使用量非常低，但是已運行Pod配置的Requests值的總和非常高，再加上需要調度的Pod的Requests值，會超過該節點提供給Pod的資源容量上限，這時Kubernetes仍然不會將Pod調度到該節點上。如果Kubernetes將Pod調度到該節點上，之后該節點上運行的Pod又面臨服務峰值等情況，就可能導致Pod資源短缺。
2.4 Requests和Limits機制
kubelet在啟動Pod的某個容器時，會將容器的Requests和Limits值轉化為相應的容器啟動參數傳遞給容器執行器（Docker或者rkt）。如果容器的執行環境是Docker，那么會傳遞如下4個參數給Docker容器：
- spec.container[].resources.requests.cpu
這個參數會轉化為core數（比如配置的100m會轉化為0.1），然后乘以1024，再將這個結果作為--cpu-shares參數的值傳遞給docker run命令。在docker run命令中，--cpu-share參數是一個相對權重值（RelativeWeight），這個相對權重值會決定Docker在資源競爭時分配給容器的資源比例。
舉例說明--cpu-shares參數在Docker中的含義：比如將兩個容器的CPU Requests分別設置為1和2，那么容器在docker run啟動時對應的--cpu-shares參數值分別為1024和2048，在主機CPU資源產生競爭時，Docker會嘗試按照1∶2的配比將CPU資源分配給這兩個容器使用。
注意這個參數對於Kubernetes而言是絕對值，主要用於Kubernetes調度和管理；同時Kubernetes會將這個參數的值傳遞給docker run的--cpu-shares參數。--cpu-shares參數對於Docker而言是相對值，主要用於資源分配比例。
- spec.container[].resources.limits.cpu
這個參數會轉化為millicore數（比如配置的1被轉化為1000，而配置的100m被轉化為100），將此值乘以100000，再除以1000，然后將結果值作為--cpu-quota參數的值傳遞給docker run命令。docker run命令中另外一個參數--cpu-period默認被設置為100000，表示Docker重新計量和分配CPU的使用時間間隔為100000μs（100ms）。
Docker的--cpu-quota參數和--cpu-period參數一起配合完成對容器CPU的使用限制：比如Kubernetes中配置容器的CPU Limits為0.1，那么計算后--cpu-quota為10000，而--cpu-period為100000，這意味着Docker在100ms內最多給該容器分配10ms×core的計算資源用量，10/100=0.1core的結果與Kubernetes配置的意義是一致的。
注意：如果kubelet的啟動參數--cpu-cfs-quota被設置為true，那么kubelet會強制要求所有Pod都必須配置CPU Limits（如果Pod沒有配置，則集群提供了默認配置也可以）。從Kubernetes1.2版本開始，這個--cpu-cfs-quota啟動參數的默認值就是true。
- spec.container[].resources.requests.memory
這個參數值只提供給Kubernetes調度器作為調度和管理的依據，不會作為任何參數傳遞給Docker。
- spec.container[].resources.limits.memory
這個參數值會轉化為單位為Bytes的整數，數值會作為--memory參數傳遞給docker run命令。如果一個容器在運行過程中使用了超出了其內存Limits配置的內存限制值，那么它可能會被殺掉，如果這個容器是一個可重啟的容器，那么之后它會被kubelet重新啟動。
因此對容器的Limits配置需要進行准確測試和評估。與內存Limits不同的是，CPU在容器技術中屬於可壓縮資源，因此對CPU的Limits配置一般不會因為偶然超標使用而導致容器被系統殺。
2.5 計算資源使用情況監控
Pod的資源用量會作為Pod的狀態信息一同上報給Master。如果在集群中配置了Heapster來監控集群的性能數據，那么還可以從Heapster中查看Pod的資源用量信息。
2.6 計算資源調度常見問題
- Pod狀態為Pending，錯誤信息為FailedScheduling
如果Kubernetes調度器在集群中找不到合適的節點來運行Pod，那么這個Pod會一直處於未調度狀態，直到調度器找到合適的節點為止。每次調度器嘗試調度失敗時，Kubernetes都會產生一個事件，我們可以通過下面這種方式來查看事件的信息：
kubectl describe pod <podname>| grep -A 3 Events
如果一個或者多個Pod調度失敗且有這類錯誤，那么可以嘗試以下幾種解決方法：
- 添加更多的節點到集群中；
- 停止一些不必要的運行中的Pod，釋放資源；
- 檢查Pod的配置，錯誤的配置可能導致該Pod永遠無法被調度執行。比如整個集群中所有節點都只有1CPU，而Pod配置的CPURequests為2，該Pod就不會被調度執行。
可以使用kubectl describe nodes命令來查看集群中節點的計算資源容量和已使用量：
[root@k8smaster01 ~]# kubectl describe nodes k8snode01
超過可用資源容量上限（Capacity）和已分配資源量（Allocatedresources）差額的Pod無法運行在該Node上。
- 容器被強行終止（Terminated）
如果容器使用的資源超過了它配置的Limits，那么該容器可能會被強制終止。可以通過kubectl describe pod命令來確認容器是否因為這個原因被終止：
kubectl describe pod
Restart Count:5說明這個名為simmemleak的容器被強制終止並重啟了5次。可以在使用kubectl get pod命令時添加-o go-template=...格式參數來讀取已終止容器之前的狀態信息：
kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name:"}}{{.name}}{{"\r\nLastate:"}}{{.lastState}}{{end}}'
可以看到這個容器因為reason:OOM Killed而被強制終止，說明這個容器的內存超過了限制（OutofMemory）。
三 資源配置范圍管理（LimitRange）
3.1 LimitRange
在默認情況下，Kubernetes不會對Pod加上CPU和內存限制，這意味着Kubernetes系統中任何Pod都可以使用其所在節點的所有可用的CPU和內存。通過配置Pod的計算資源Requests和Limits，可以限制Pod的資源使用，但對於Kubernetes集群管理員而言，配置每一個Pod的Requests和Limits是煩瑣的，而且很受限制。更多時候，需要對集群內Requests和Limits的配置做一個全局限制。
常見的配置場景如下：
- 集群中的每個節點都有2GB內存，集群管理員不希望任何Pod申請超過2GB的內存：因為在整個集群中都沒有任何節點能滿足超過2GB內存的請求。如果某個Pod的內存配置超過2GB，那么該Pod將永遠都無法被調度到任何節點上執行。為了防止這種情況的發生，集群管理員希望能在系統管理功能中設置禁止Pod申請超過2GB內存。
- 集群由同一個組織中的兩個團隊共享，分別運行生產環境和開發環境。生產環境最多可以使用8GB內存，而開發環境最多可以使用512MB內存。集群管理員希望通過為這兩個環境創建不同的命名空間，並為每個命名空間設置不同的限制來滿足這個需求。
- 用戶創建Pod時使用的資源可能會剛好比整個機器資源的上限稍小，而恰好剩下的資源大小非常尷尬：不足以運行其他任務但整個集群加起來又非常浪費。因此，集群管理員希望設置每個Pod都必須至少使用集群平均資源值（CPU和內存）的20%，這樣集群能夠提供更好的資源一致性的調度，從而減少了資源浪費。
針對這些需求，Kubernetes提供了LimitRange機制對Pod和容器的Requests和Limits配置進一步做出限制。
示例1：
[root@k8smaster01 study]# kubectl create namespace limit-example #創建namespace
[root@k8smaster01 study]# vi limits.yaml #創建limitrange
1 apiVersion: v1 2 kind: LimitRange 3 metadata: 4 name: mylimits 5 spec: 6 limits: 7 - max: 8 cpu: "4" 9 memory: 2Gi 10 min: 11 cpu: 200m 12 memory: 6Mi 13 maxLimitRequestRatio: 14 cpu: 3 15 memory: 2 16 type: Pod 17 - default: 18 cpu: 300m 19 memory: 200Mi 20 defaultRequest: 21 cpu: 200m 22 memory: 100Mi 23 max: 24 cpu: "2" 25 memory: 1Gi 26 min: 27 cpu: 100m 28 memory: 3Mi 29 maxLimitRequestRatio: 30 cpu: 5 31 memory: 4 32 type: Container 33
[root@k8smaster01 study]# kubectl create -f limits.yaml --namespace=limit-example #為Namespace“limit-example”創建LimitRange
[root@k8smaster01 study]# kubectl get limitranges -n limit-example
[root@k8smaster01 study]# kubectl describe limitranges mylimits -n limit-example
解讀：
- 不論是CPU還是內存，在LimitRange中，Pod和Container都可以設置Min、Max和MaxLimit/RequestsRatio參數。Container還可以設置Default Request和Default Limit參數，而Pod不能設置Default Request和DefaultLimit參數。
- 對Pod和Container的參數解釋如下：
- Container的Min（如上圖100m和3Mi）是Pod中所有容器的Requests值下限；Container的Max（如上圖2和1Gi）是Pod中所有容器的Limits值上限；Container的Default Request（如上圖200m和100Mi）是Pod中所有未指定Requests值的容器的默認Requests值；Container的DefaultLimit（如上圖300m和200Mi）是Pod中所有未指定Limits值的容器的默認Limits值。對於同一資源類型，這4個參數必須滿足以下關系：Min ≤ Default Request ≤ Default Limit ≤ Max。
- Pod的Min（如上圖200m和6Mi）是Pod中所有容器的Requests值的總和下限；Pod的Max（如上圖4和2Gi）是Pod中所有容器的Limits值的總和上限。當容器未指定Requests值或者Limits值時，將使用Container的Default Request值或者Default Limit值。
- Container的Max Limit/Requests Ratio（如上圖5和4）限制了Pod中所有容器的Limits值與Requests值的比例上限；而Pod的MaxLimit/RequestsRatio（如上圖3和2）限制了Pod中所有容器的Limits值總和與Requests值總和的比例上限。
- 如果設置了Container的Max，那么對於該類資源而言，整個集群中的所有容器都必須設置Limits，否則無法成功創建。Pod內的容器未配置Limits時，將使用Default Limit的值（本例中的300mCPU和200MiB內存），如果也未配置Default，則無法成功創建。
- 如果設置了Container的Min，那么對於該類資源而言，整個集群中的所有容器都必須設置Requests。如果創建Pod的容器時未配置該類資源的Requests，那么在創建過程中會報驗證錯誤。Pod里容器的Requests在未配置時，可以使用默認值default Request（本例中的200mCPU和100MiB內存）；如果未配置而又沒有使用默認值default Request，那么會默認等於該容器的Limits；如果此時Limits也未定義，就會報錯。
- 對於任意一個Pod而言，該Pod中所有容器的Requests總和必須大於或等於6MiB，而且所有容器的Limits總和必須小於或等於1GiB；同樣，所有容器的CPU Requests總和必須大於或等於200m，而且所有容器的CPU Limits總和必須小於或等於2。
- Pod里任何容器的Limits與Requests的比例都不能超過Container的MaxLimit/RequestsRatio；Pod里所有容器的Limits總和與Requests的總和的比例不能超過Pod的MaxLimit/RequestsRatio。
[root@k8smaster01 study]# kubectl run nginx --image=nginx --replicas=1 --namespace=limit-example
[root@k8smaster01 study]# kubectl get pods --namespace=limit-example
NAME READY STATUS RESTARTS AGE
nginx-7bb7cd8db5-mzcvb 1/1 Running 0 54s
解讀：命名空間中LimitRange只會在Pod創建或者更新時執行檢查。如果手動修改LimitRange為一個新的值，那么這個新的值不會去檢查或限制之前已經在該命名空間中創建好的Pod。如果在創建Pod時配置的資源值（CPU或者內存）超過了LimitRange的限制，那么該創建過程會報錯，在錯誤信息中會說明詳細的錯誤原因。
[root@k8smaster01 study]# kubectl get pods nginx-7bb7cd8db5-mzcvb --namespace=limit-example -o yaml | grep resources -C 6 #查看該Pod的resource
1 uid: 5fd37e03-ea08-44f3-a2c7-30ad31c7ab4a 2 spec: 3 containers: 4 - image: nginx 5 imagePullPolicy: Always 6 name: nginx 7 resources: 8 limits: 9 cpu: 300m 10 memory: 200Mi 11 requests: 12 cpu: 200m 13 memory: 100Mi 14
解讀：由於該Pod未配置資源Requests和Limits，所以使用了namespace limit-example中的默認CPU和內存定義的Requests和Limits值。
[root@k8smaster01 study]# vi invalid-pod.yaml
1 apiVersion: v1 2 kind: Pod 3 metadata: 4 name: invalid-pod 5 spec: 6 containers: 7 - name: kubernetes-serve-hostname 8 image: gcr.azk8s.cn/google_containers/server_hostname 9 resources: 10 limits: 11 cpu: "3" 12 memory: 100Mi 13
[root@k8smaster01 study]# kubectl create -f invalid-pod.yaml --namespace=limit-example
Error from server (Forbidden): error when creating "invalid-pod.yaml": pods "invalid-pod" is forbidden: maximum cpu usage per Container is 2, but limit is 3
解讀：創建該Pod，會出現系統報錯了，並且提供的錯誤原因為超過資源限制。
[root@k8smaster01 study]# vi limit-test-nginx.yaml
1 apiVersion: v1 2 kind: Pod 3 metadata: 4 name: limit-test-nginx 5 labels: 6 name: limit-test-nginx 7 spec: 8 containers: 9 - name: limit-test-nginx 10 image: nginx 11 resources: 12 limits: 13 cpu: "1" 14 memory: 512Mi 15 requests: 16 cpu: "0.8" 17 memory: 250Mi 18
[root@k8smaster01 study]# kubectl create -f limit-test-nginx.yaml -n limit-example
Error from server (Forbidden): error when creating "limit-test-nginx.yaml": pods "limit-test-nginx" is forbidden: memory max limit to request ratio per Pod is 2, but provided ratio is 2.048000
解讀：由於limit-test-nginx這個Pod的全部內存Limits總和與Requests總和的比例為512∶250，大於在LimitRange中定義的Pod的最大比率2（maxLimitRequestRatio.memory=2），因此創建失敗。
[root@k8smaster01 study]# vi valid-pod.yaml
1 apiVersion: v1 2 kind: Pod 3 metadata: 4 name: valid-pod 5 labels: 6 name: valid-pod 7 spec: 8 containers: 9 - name: kubernetes-serve-hostname 10 image: gcr.io/google_containers/serve_hostname 11 resources: 12 limits: 13 cpu: "1" 14 memory: 512Mi 15
[root@k8smaster01 study]# kubectl create -f valid-pod.yaml -n limit-example
[root@k8smaster01 study]# kubectl get pods valid-pod -n limit-example -o yaml | grep resources -C 6 #查看該Pod的資源信息
1 uid: 59e3d05a-8c09-479e-a3ad-1a4dbfd8e946 2 spec: 3 containers: 4 - image: gcr.io/google_containers/serve_hostname 5 imagePullPolicy: Always 6 name: kubernetes-serve-hostname 7 resources: 8 limits: 9 cpu: "1" 10 memory: 512Mi 11 requests: 12 cpu: "1" 13 memory: 512Mi 14
解讀：該Pod配置了明確的Limits和Requests，因此該Pod不會使用在namespace limit-example中定義的default和default Request。
注意：CPU Limits強制配置這個選項在Kubernetes集群中默認是開啟的；除非集群管理員在部署kubelet時，通過設置參數--cpucfs-quota=false來關閉該限制：如果集群管理員希望對整個集群中容器或者Pod配置的Requests和Limits做限制，那么可以通過配置Kubernetes命名空間中的LimitRange來達到該目的。在Kubernetes集群中，如果Pod沒有顯式定義Limits和Requests，那么Kubernetes系統會將該Pod所在的命名空間中定義的LimitRange的default和default Requests配置到該Pod上。
四 資源服務質量管理（Resource QoS）
4.1 服務資源質量
Kubernetes會根據Pod的Requests和Limits配置來實現針對Pod的不同級別的資源服務質量控制（QoS）。在Kubernetes的資源QoS體系中，需要保證高可靠性的Pod可以申請可靠資源，而一些不需要高可靠性的Pod可以申請可靠性較低或者不可靠的資源。
容器的資源配置分為Requests和Limits，其中Requests是Kubernetes調度時能為容器提供的完全可保障的資源量（最低保障），而Limits是系統允許容器運行時可能使用的資源量的上限（最高上限）。Pod級別的資源配置是通過計算Pod內所有容器的資源配置的總和得出來的。
Kubernetes中Pod的Requests和Limits資源配置有如下特點：
- 如果Pod配置的Requests值等於Limits值，那么該Pod可以獲得的資源是完全可靠的。
- 如果Pod的Requests值小於Limits值，那么該Pod獲得的資源可分成兩部分：
- 完全可靠的資源，資源量的大小等於Requests值；
- 不可靠的資源，資源量最大等於Limits與Requests的差額，這份不可靠的資源能夠申請到多少，取決於當時主機上容器可用資源的余量。
通過這種機制，Kubernetes可以實現節點資源的超售（OverSubscription），比如在CPU完全充足的情況下，某機器共有32GiB內存可提供給容器使用，容器配置為Requests值1GiB，Limits值為2GiB，那么在該機器上最多可以同時運行32個容器，每個容器最多可以使用2GiB內存，如果這些容器的內存使用峰值能錯開，那么所有容器都可以正常運行。超售機制能有效提高資源的利用率，同時不會影響容器申請的完全可靠資源的可靠性。
4.2 Requests和Limits限制機制
容器的資源配置滿足以下兩個條件：
- Requests <= 節點可用資源
- Requests <= Limits
Kubernetes根據Pod配置的Requests值來調度Pod，Pod在成功調度之后會得到Requests值定義的資源來運行；而如果Pod所在機器上的資源有空余，則Pod可以申請更多的資源，最多不能超過Limits的值。Requests和Limits針對不同計算資源類型的限制機制存在差異。這種差異主要取決於計算資源類型是可壓縮資源還是不可壓縮資源。
- 可壓縮資源
Kubernetes目前支持的可壓縮資源是CPU。
Pod可以得到Pod的Requests配置的CPU使用量，而能否使用超過Requests值的部分取決於系統的負載和調度。不過由於目前Kubernetes和Docker的CPU隔離機制都是在容器級別隔離的，所以Pod級別的資源配置並不能完全得到保障；Pod級別的cgroups等待引入，以便於確保Pod級別的資源配置准確運行。
空閑CPU資源按照容器Requests值的比例分配。舉例說明：容器A的CPU配置為Requests 1 Limits 10，容器B的CPU配置為Request 2 Limits8，A和B同時運行在一個節點上，初始狀態下容器的可用CPU為3 cores，那么A和B恰好得到在它們的Requests中定義的CPU用量，即1CPU和2CPU。如果A和B都需要更多的CPU資源，而恰好此時系統的其他任務釋放出1.5CPU，那么這1.5 CPU將按照A和B的Requests值的比例1∶2分配給A和B，即最終A可使用1.5CPU，B可使用3CPU。
如果Pod使用了超過在Limits 10中配置的CPU用量，那么cgroups會對Pod中的容器的CPU使用進行限流（Throttled）；如果Pod沒有配置Limits 10，那么Pod會嘗試搶占所有空閑的CPU資源（Kubernetes從1.2版本開始默認開啟--cpu-cfs-quota，因此在默認情況下必須配置Limits）
- 不可壓縮資源
Kubernetes目前支持的不可壓縮資源是內存。
Pod可以得到在Requests中配置的內存。如果Pod使用的內存量小於它的Requests的配置，那么這個Pod可以正常運行；如果Pod使用的內存量超過了它的Requests的配置，那么這個Pod有可能被Kubernetes殺掉：比如Pod A使用了超過Requests而不到Limits的內存量，此時同一機器上另外一個Pod B之前只使用了遠少於自己的Requests值的內存，此時程序壓力增大，Pod B向系統申請的總量不超過自己的Requests值的內存，那么Kubernetes可能會直接殺掉Pod A，而優先保障Pod B的Requests得到滿足；另外一種情況是Pod A使用了超過Requests而不到Limits的內存量，此時Kubernetes將一個新的Pod調度到這台機器上，新的Pod需要使用內存，而只有Pod A使用了超過了自己的Requests值的內存，那么Kubernetes也可能會殺掉Pod A來釋放內存資源。
如果Pod使用的內存量超過了它的Limits設置，那么操作系統內核會殺掉Pod所有容器的所有進程中使用內存最多的一個，直到內存不超過Limits為止。
4.3 對調度策略的影響
Kubernetes的kubelet通過計算Pod中所有容器的Requests的總和來決定對Pod的調度。
不管是CPU還是內存，Kubernetes調度器和kubelet都會確保節點上所有Pod的Requests的總和不會超過在該節點上可分配給容器使用的資源容量上限。
4.4 服務質量等級（QoSClasses）
在一個超用（Over Committed，容器Limits總和大於系統容量上限）系統中，由於容器負載的波動可能導致操作系統的資源不足，最終可能導致部分容器被殺掉。在這種情況下，理想是優先殺掉那些不太重要的容器。Kubernetes將容器划分成3個QoS等級來衡量重要程度：
Guaranteed（完全可靠的）、Burstable（彈性波動、較可靠的）和BestEffort（盡力而為、不太可靠的），這三種優先級依次遞減。
QoS等級和優先級的關系從理論上來說，QoS級別應該作為一個單獨的參數來提供API，並由用戶對Pod進行配置，這種配置應該與Requests和Limits無關。但在當前版本的Kubernetes的設計中，為了簡化模式及避免引入太多的復雜性，QoS級別直接由Requests和Limits來定義。在Kubernetes中容器的QoS級別等於容器所在Pod的QoS級別，而Kubernetes的資源配置定義了Pod的如上三種QoS級別。
- Guaranteed
如果Pod中的所有容器對所有資源類型都定義了Limits和Requests，並且所有容器的Limits值都和Requests值全部相等（且都不為0），那么該Pod的QoS級別就是Guaranteed。
注意：在這種情況下，容器可以不定義Requests，因為Requests值在未定義時默認等於Limits。
示例1：如下定義的PodQoS級別就是Guaranteed。
1 containers： 2 name: foo 3 resources: 4 limits: 5 cpu: 10m 6 memory: 1Gi 7 name: bar 8 resources: 9 limits: 10 cpu: 100m 11 memory: 100Mi 12
解讀：如上未定義Requests值，所以其默認等於Limits值。
示例2：
1 containers： 2 name: foo 3 resources: 4 requests: 5 cpu: 10m 6 memory: 1Gi 7 limits: 8 cpu: 10m 9 memory: 1Gi 10 name: bar 11 resources: 12 requests: 13 cpu: 10m 14 memory: 1Gi 15 limits: 16 cpu: 100m 17 memory: 100Mi 18
解讀：該定義的Requests和Limits的值完全相同。
- BestEffort
如果Pod中所有容器都未定義資源配置（Requests和Limits都未定義），那么該Pod的QoS級別就是BestEffort。
示例3：
1 containers： 2 name: foo 3 resources: 4 name: bar 5 resources: 6
解讀：該容器都未定義資源配置。
- Burstable
當一個Pod既不為Guaranteed級別，也不為BestEffort級別時，該Pod的QoS級別就是Burstable。Burstable級別的Pod包括兩種情況。
- 第1種情況：Pod中的一部分容器在一種或多種資源類型的資源配置中定義了Requests值和Limits值（都不為0），且Requests值小於Limits值；
- 第2種情況：Pod中的一部分容器未定義資源配置（Requests和Limits都未定義）。
注意：在容器未定義Limits時，Limits值默認等於節點資源容量的上限。
示例4：容器foo的CPURequests不等於Limits。
1 containers： 2 name: foo 3 resources: 4 requests: 5 cpu: 5m 6 memory: 1Gi 7 limits: 8 cpu: 10m 9 memory: 1Gi 10 name: bar 11 resources: 12 requests: 13 cpu: 5m 14 memory: 1Gi 15 limits: 16 cpu: 100m 17 memory: 100Mi 18
示例5：容器bar未定義資源配置而容器foo定義了資源配置。
1 containers： 2 name: foo 3 resources: 4 requests: 5 cpu: 10m 6 memory: 1Gi 7 limits: 8 cpu: 10m 9 memory: 1Gi 10 name: bar 11
示例6：容器foo未定義CPU，而容器bar未定義內存。
1 containers： 2 name: foo 3 resources: 4 limits: 5 memory: 1Gi 6 name: bar 7 resources: 8 limits: 9 cpu: 100m 10
示例7：容器bar未定義資源配置，而容器foo未定義Limits值。
containers： name: foo resources: requests: cpu: 5m memory: 1Gi name: bar
4.5 Kubernetes QoS的工作特點
Pod的CPU Requests無法得到滿足（比如節點的系統級任務占用過多的CPU導致無法分配足夠的CPU給容器使用）時，容器得到的CPU會被壓縮限流。由於內存是不可壓縮的資源，所以針對內存資源緊缺的情況，會按照以下邏輯進行處理。
- BestEffort Pod的優先級最低，在這類Pod中運行的進程會在系統內存緊缺時被第一優先殺掉。當然，從另外一個角度來看，BestEffort Pod由於沒有設置資源Limits，所以在資源充足時，它們可以充分使用所有的閑置資源。
- Burstable Pod的優先級居中，這類Pod初始時會分配較少的可靠資源，但可以按需申請更多的資源。當然，如果整個系統內存緊缺，又沒有BestEffort容器可以被殺掉以釋放資源，那么這類Pod中的進程可能會被殺掉。
- Guaranteed Pod的優先級最高，而且一般情況下這類Pod只要不超過其資源Limits的限制就不會被殺掉。當然，如果整個系統內存緊缺，又沒有其他更低優先級的容器可以被殺掉以釋放資源，那么這類Pod中的進程也可能會被殺掉。
4.6 OOM計分系統
OOM（Out Of Memory）計分規則包括如下內容：
OOM計分的計算方法為：計算進程使用內存在系統中占的百分比，取其中不含百分號的數值，再乘以10的結果，這個結果是進程OOM的基礎分；將進程OOM基礎分的分值再加上這個進程的OOM分數調整值OOM_SCORE_ADJ的值，作為進程OOM的最終分值（除root啟動的進程外）。在系統發生OOM時，OOM Killer會優先殺掉OOM計分更高的進程。
進程的OOM計分的基本分數值范圍是0～1000，如果A進程的調整值OOM_SCORE_ADJ減去B進程的調整值的結果大於1000，那么A進程的OOM計分最終值必然大於B進程，會優先殺掉A進程。
不論調整OOM_SCORE_ADJ值為多少，任何進程的最終分值范圍也是0～1000。在Kubernetes，不同QoS的OOM計分調整值規則如下所示。
其中：
- BestEffortPod設置OOM_SCORE_ADJ調整值為1000，因此BestEffortPod中容器里所有進程的OOM最終分肯定是1000。
- GuaranteedPod設置OOM_SCORE_ADJ調整值為-998，因此GuaranteedPod中容器里所有進程的OOM最終分一般是0或者1（因為基礎分不可能是1000）。
- BurstablePod規則分情況說明：如果BurstablePod的內存Requests超過了系統可用內存的99.8%，那么這個Pod的OOM_SCORE_ADJ調整值固定為2；否則，設置OOM_SCORE_ADJ調整值為1000－10×(%of memory requested)；如果內存Requests為0，那么OOM_SCORE_ADJ調整值固定為999。這樣的規則能確保OOM_SCORE_ADJ調整值的范圍為2～999，而BurstablePod中所有進程的OOM最終分數范圍為2～1000。BurstablePod進程的OOM最終分數始終大於GuaranteedPod的進程得分，因此它們會被優先殺掉。如果一個BurstablePod使用的內存比它的內存Requests少，那么可以肯定的是它的所有進程的OOM最終分數會小於1000，此時能確保它的優先級高於BestEffortPod。如果在一個BurstablePod的某個容器中某個進程使用的內存比容器的Requests值高，那么這個進程的OOM最終分數會是1000，否則它的OOM最終分會小於1000。假設在下面的容器中有一個占用內存非常大的進程，那么當一個使用內存超過其Requests的BurstablePod與另外一個使用內存少於其Requests的BurstablePod發生內存競爭沖突時，前者的進程會被系統殺掉。如果在一個BurstablePod內部有多個進程的多個容器發生內存競爭沖突，那么此時OOM評分只能作為參考，不能保證完全按照資源配置的定義來執行OOMKill。
OOM還有一些特殊的計分規則，如下所述。
- kubelet進程和Docker進程的調整值OOM_SCORE_ADJ為-998。
- 如果配置進程調整值OOM_SCORE_ADJ為-999，那么這類進程不會被OOMKiller殺掉。
五 資源配額管理（ Resource Quotas）
5.1 配額管理
ResourceQuotas通常用於在共享集群資源場景中平衡資源，通過ResourceQuota對象，可以定義資源配額，這個資源配額可以為每個命名空間都提供一個總體的資源使用的限制：它可以限制命名空間中某種類型的對象的總數目上限，也可以設置命名空間中Pod可以使用的計算資源的總上限。
ResourceQuotas典型的場景如下：
- 不同的團隊工作在不同的命名空間下，目前這是非約束性的，在未來的版本中可能會通過ACL（Access Control List，訪問控制列表）來實現強制性約束。
- 集群管理員為集群中的每個命名空間都創建一個或者多個資源配額項。
- 當用戶在命名空間中使用資源（創建Pod或者Service等）時，Kubernetes的配額系統會統計、監控和檢查資源用量，以確保使用的資源用量沒有超過資源配額的配置。
- 如果在創建或者更新應用時資源使用超過了某項資源配額的限制，那么創建或者更新的請求會報錯（HTTP 403 Forbidden），並給出詳細的出錯原因說明。
- 如果命名空間中的計算資源（CPU和內存）的資源配額啟用，那么用戶必須為相應的資源類型設置Requests或Limits；否則配額系統可能會直接拒絕Pod的創建。這里可以使用LimitRange機制來為沒有配置資源的Pod提供默認資源配置。
場景示例：
- 集群共有32GB內存和16CPU，兩個小組。A小組使用20GB內存和10CPU，B小組使用10GB內存和2CPU，剩下的2GB內存和2CPU作為預留。在名為testing的命名空間中，限制使用1CPU和1GB內存；在名為production的命名空間中，資源使用不受限制。
在使用資源配額時，需要注意以下兩點。
- 如果集群中總的可用資源小於各命名空間中資源配額的總和，那么可能會導致資源競爭。資源競爭時，Kubernetes系統會遵循先到先得的原則。
- 不管是資源競爭還是配額的修改，都不會影響已經創建的資源使用對象。
5.2 開啟資源配額特性
資源配額可以通過在kube-apiserver的--admission-control參數值中添加ResourceQuota參數進行開啟。如果在某個命名空間的定義中存在ResourceQuota，那么對於該命名空間而言，資源配額就是開啟的。一個命名空間可以有多個ResourceQuota配置項。
提示：在v 1.10后續的版本中，--admission-control 已經廢棄,建議使用 --enable-admission-plugins。
[root@k8smaster01 study]# vi /etc/kubernetes/manifests/kube-apiserver.yaml …… - --enable-admission-plugins=NodeRestriction,ResourceQuota,LimitRanger …… [root@k8smaster01 study]# systemctl restart kubelet.service
5.3 資源配額類型
- 計算資源配額（ComputeResourceQuota）
資源配額可以限制一個命名空間中所有Pod的計算資源的總和。目前支持的計算資源類型如下表：
- 存儲資源配額（Volume Count Quota）
可以在給定的命名空間中限制所使用的存儲資源（StorageResources）的總量，目前支持的存儲資源名稱如下表：
- 對象數量配額（ Object Count Quota）
指定類型的對象數量可以被限制。 如下表列出了ResourceQuota支持限制的對象類型：
通常，可以通過資源配額來限制在命名空間中能創建的Pod的最大數量，這種設置可以防止某些用戶大量創建Pod而迅速耗盡整個集群的Pod IP和計算資源。
5.4 配額的作用域（QuotaScopes）
每項資源配額都可以單獨配置一組作用域，配置了作用域的資源配額只會對符合其作用域的資源使用情況進行計量和限制，作用域范圍內超過了資源配額的請求都會報驗證錯誤。ResourceQuota的4種作用域如下所示：
其中，BestEffort作用域可以限定資源配額來追蹤pods資源的使用，Terminating、NotTerminating和NotBestEffort這三種作用域可以限定資源配額來追蹤以下資源的使用：
- cpu
- limits.cpu
- limits.memory
- memory
- pods
- requests.cpu
- requests.memory
5.5 資源配額（ResourceQuota）設置Requests和Limits
資源配額也可以設置Requests和Limits。如果在資源配額中指定了requests.cpu或requests.memory，那么它會強制要求每個容器都配置自己的CPU Requests或CPU Limits（可使用Limit Range提供的默認值）。
同理，如果在資源配額中指定了limits.cpu或limits.memory，那么它也會強制要求每個容器都配置自己的內存Requests或內存Limits（可使用LimitRange提供的默認值）。
5.6 資源配額的定義
與LimitRange相似，ResourceQuota也被設置在Namespace中。
示例1：
[root@k8smaster01 study]# kubectl create namespace myspace #創建名為myspace的Namespace
[root@k8smaster01 study]# vi compute-resources.yaml #創建ResourceQuota配置文件
1 apiVersion: v1 2 kind: ResourceQuota 3 metadata: 4 name: compute-resources 5 spec: 6 hard: 7 pods: "4" 8 requests.cpu: "1" 9 requests.memory: 1Gi 10 limits.cpu: "2" 11 limits.memory: 2Gi 12
[root@k8smaster01 study]# kubectl create -f compute-resources.yaml --namespace=myspace #創建該ResourceQuota
創建另一個名為object-counts.yaml的文件，用於設置對象數量的配額：
[root@k8smaster01 study]# vi object-counts.yaml
1 apiVersion: v1 2 kind: ResourceQuota 3 metadata: 4 name: object-counts 5 spec: 6 hard: 7 configmaps: "10" 8 persistentvolumeclaims: "4" 9 replicationcontrollers: "20" 10 secrets: "10" 11 services: "10" 12 services.loadbalancers: "2" 13
[root@k8smaster01 study]# kubectl create -f object-counts.yaml --namespace=myspace
[root@k8smaster01 study]# kubectl describe quota compute-resources --namespace=myspace
[root@k8smaster01 study]# kubectl describe quota object-counts --namespace=myspace
5.7 資源配額與集群資源總量的關系
資源配額與集群資源總量是完全獨立的。資源配額是通過絕對的單位來配置的，這也就意味着如果在集群中新添加了節點，那么資源配額不會自動更新，而該資源配額所對應的命名空間中的對象也不能自動增加資源上限。在某些情況下，可能希望資源配額支持更復雜的策略，如下所述。
- 對於不同的租戶，按照比例划分整個集群的資源。
- 允許每個租戶都能按照需要來提高資源用量，但是有一個較寬容的限制，以防止意外的資源耗盡情況發生。
- 探測某個命名空間的需求，添加物理節點並擴大資源配額值。
這些策略可以通過將資源配額作為一個控制模塊、手動編寫一個控制器來監控資源使用情況，並調整命名空間上的資源配額來實現。資源配額將整個集群中的資源總量做了一個靜態划分，但它並沒有對集群中的節點做任何限制：不同命名空間中的Pod仍然可以運行在同一個節點上。
參考鏈接：https://blog.csdn.net/dkfajsldfsdfsd/article/details/81004172