047.集群管理-資源及配額管理

一 資源管理

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個參數：

  1. spec.container[].resources.requests.cpu

  2. spec.container[].resources.limits.cpu

  3. spec.container[].resources.requests.memory

  4. 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使用率的區別。

clipboard

clipboard

儘管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調度失敗且有這類錯誤，那麼可以嘗試以下幾種解決方法：

  1. 添加更多的節點到集群中；

  2. 停止一些不必要的運行中的Pod，釋放資源；

  3. 檢查Pod的配置，錯誤的配置可能導致該Pod永遠無法被調度執行。比如整個集群中所有節點都只有1CPU，而Pod配置的CPURequests為2，該Pod就不會被調度執行。

可以使用kubectl describe nodes命令來查看集群中節點的計算資源容量和已使用量：

[root@k8smaster01 ~]# kubectl describe nodes k8snode01

clipboard

超過可用資源容量上限（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}}{{“rnLastate:”}}{{.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的配置做一個全局限制。

常見的配置場景如下：

  1. 集群中的每個節點都有2GB記憶體，集群管理員不希望任何Pod申請超過2GB的記憶體：因為在整個集群中都沒有任何節點能滿足超過2GB記憶體的請求。如果某個Pod的記憶體配置超過2GB，那麼該Pod將永遠都無法被調度到任何節點上執行。為了防止這種情況的發生，集群管理員希望能在系統管理功能中設置禁止Pod申請超過2GB記憶體。

  2. 集群由同一個組織中的兩個團隊共享，分別運行生產環境和開發環境。生產環境最多可以使用8GB記憶體，而開發環境最多可以使用512MB記憶體。集群管理員希望通過為這兩個環境創建不同的命名空間，並為每個命名空間設置不同的限制來滿足這個需求。

  3. 用戶創建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

clipboard

解讀：

  1. 不論是CPU還是記憶體，在LimitRange中，Pod和Container都可以設置Min、Max和MaxLimit/RequestsRatio參數。Container還可以設置Default Request和Default Limit參數，而Pod不能設置Default Request和DefaultLimit參數。

  2. 對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值總和的比例上限。

  1. 如果設置了Container的Max，那麼對於該類資源而言，整個集群中的所有容器都必須設置Limits，否則無法成功創建。Pod內的容器未配置Limits時，將使用Default Limit的值（本例中的300mCPU和200MiB記憶體），如果也未配置Default，則無法成功創建。

  2. 如果設置了Container的Min，那麼對於該類資源而言，整個集群中的所有容器都必須設置Requests。如果創建Pod的容器時未配置該類資源的Requests，那麼在創建過程中會報驗證錯誤。Pod里容器的Requests在未配置時，可以使用默認值default Request（本例中的200mCPU和100MiB記憶體）；如果未配置而又沒有使用默認值default Request，那麼會默認等於該容器的Limits；如果此時Limits也未定義，就會報錯。

  3. 對於任意一個Pod而言，該Pod中所有容器的Requests總和必須大於或等於6MiB，而且所有容器的Limits總和必須小於或等於1GiB；同樣，所有容器的CPU Requests總和必須大於或等於200m，而且所有容器的CPU Limits總和必須小於或等於2。

  4. 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資源配置有如下特點：

  1. 如果Pod配置的Requests值等於Limits值，那麼該Pod可以獲得的資源是完全可靠的。

  2. 如果Pod的Requests值小於Limits值，那麼該Pod獲得的資源可分成兩部分：

    1. 完全可靠的資源，資源量的大小等於Requests值；

    2. 不可靠的資源，資源量最大等於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針對不同計算資源類型的限制機制存在差異。這種差異主要取決於計算資源類型是可壓縮資源還是不可壓縮資源。

  1. 可壓縮資源

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）

  1. 不可壓縮資源

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（儘力而為、不太可靠的），這三種優先順序依次遞減。

clipboard

QoS等級和優先順序的關係從理論上來說，QoS級別應該作為一個單獨的參數來提供API，並由用戶對Pod進行配置，這種配置應該與Requests和Limits無關。但在當前版本的Kubernetes的設計中，為了簡化模式及避免引入太多的複雜性，QoS級別直接由Requests和Limits來定義。在Kubernetes中容器的QoS級別等於容器所在Pod的QoS級別，而Kubernetes的資源配置定義了Pod的如上三種QoS級別。

  1. 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的值完全相同。

  1. BestEffort

如果Pod中所有容器都未定義資源配置（Requests和Limits都未定義），那麼該Pod的QoS級別就是BestEffort。

示例3：

  1 containers：    2   name: foo    3     resources:    4   name: bar    5     resources:    6

解讀：該容器都未定義資源配置。

  1. 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會被壓縮限流。由於記憶體是不可壓縮的資源，所以針對記憶體資源緊缺的情況，會按照以下邏輯進行處理。

  1. BestEffort Pod的優先順序最低，在這類Pod中運行的進程會在系統記憶體緊缺時被第一優先殺掉。當然，從另外一個角度來看，BestEffort Pod由於沒有設置資源Limits，所以在資源充足時，它們可以充分使用所有的閑置資源。

  2. Burstable Pod的優先順序居中，這類Pod初始時會分配較少的可靠資源，但可以按需申請更多的資源。當然，如果整個系統記憶體緊缺，又沒有BestEffort容器可以被殺掉以釋放資源，那麼這類Pod中的進程可能會被殺掉。

  3. 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計分調整值規則如下所示。

QoS等級

oom_score_adj

Guaranteed

-998

BestEffort

1000

Burstable

min(max(2,1000-(1000*memoryRequestBytes)/machineMemoryCapacityBytes),999)

其中：

  • 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典型的場景如下：

  1. 不同的團隊工作在不同的命名空間下，目前這是非約束性的，在未來的版本中可能會通過ACL（Access Control List，訪問控制列表）來實現強制性約束。

  2. 集群管理員為集群中的每個命名空間都創建一個或者多個資源配額項。

  3. 當用戶在命名空間中使用資源（創建Pod或者Service等）時，Kubernetes的配額系統會統計、監控和檢查資源用量，以確保使用的資源用量沒有超過資源配額的配置。

  4. 如果在創建或者更新應用時資源使用超過了某項資源配額的限制，那麼創建或者更新的請求會報錯（HTTP 403 Forbidden），並給出詳細的出錯原因說明。

  5. 如果命名空間中的計算資源（CPU和記憶體）的資源配額啟用，那麼用戶必須為相應的資源類型設置Requests或Limits；否則配額系統可能會直接拒絕Pod的創建。這裡可以使用LimitRange機制來為沒有配置資源的Pod提供默認資源配置。

場景示例：

  • 集群共有32GB記憶體和16CPU，兩個小組。A小組使用20GB記憶體和10CPU，B小組使用10GB記憶體和2CPU，剩下的2GB記憶體和2CPU作為預留。在名為testing的命名空間中，限制使用1CPU和1GB記憶體；在名為production的命名空間中，資源使用不受限制。

在使用資源配額時，需要注意以下兩點。

  1. 如果集群中總的可用資源小於各命名空間中資源配額的總和，那麼可能會導致資源競爭。資源競爭時，Kubernetes系統會遵循先到先得的原則。

  2. 不管是資源競爭還是配額的修改，都不會影響已經創建的資源使用對象。

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的計算資源的總和。目前支援的計算資源類型如下表：

資源名稱

說明

cpu

所有非終止狀態的Pod，CPU Requests的總和不能超過該值

limits.cpu

所有非終止狀態的Pod，CPU Limits的總和不能超過該值

limits.memory

所有非終止狀態的Pod，記憶體Limits的總和不能超過該值

Memory

所有非終止狀態的Pod，記憶體Requests的總和不能超過該值

requests.cpu

所有非終止狀態的Pod，CPU Requests的總和不能超過該值

requests.memory

所有非終止狀態的Pod，記憶體Requests的總和不能超過該值

  • 存儲資源配額（Volume Count Quota）

可以在給定的命名空間中限制所使用的存儲資源（StorageResources）的總量，目前支援的存儲資源名稱如下表：

資源名稱

說明

requests.storage

所有PVC，存儲請求總量不能超過此值

PersistentVolumeclaims

在該命名空間中能存在的持久卷的總數上限

.storageclass.storage.k8s.io/requests.storage

和該存儲類關聯的所有PVC，存儲請求總和不能超過此值

.storageclass.storage.k8s.io/persistentvolumeclaims

和該存儲類關聯的所有PVC的總和

  • 對象數量配額（ Object Count Quota）

指定類型的對象數量可以被限制。 如下表列出了ResourceQuota支援限制的對象類型：

資源名稱

說明

Configmaps

在該命名空間中能存在的ConfigMap的總數上限

Pods

在該命名空間中能存在的非終止狀態Pod的總數上限，Pod終止狀態等價於Pod的status.phase in(Failed, Succeeded) = true

Replicationcontrollers

在該命名空間中能存在的RC的總數上限

Resourcequtas

在該命名空間中能存在的資源配額項的總數上限

Services

在該命名空間中能存在的Service的總數上限

service.loadbalancers

在該命名空間中能存在的負載均衡的總數上限

services.nodeports

在該命名空間中能存在的NodePort的總數上限

Secrets

在該命名空間中能存在的Secret的總數上限

通常，可以通過資源配額來限制在命名空間中能創建的Pod的最大數量，這種設置可以防止某些用戶大量創建Pod而迅速耗盡整個集群的Pod IP和計算資源。

5.4 配額的作用域（QuotaScopes）

每項資源配額都可以單獨配置一組作用域，配置了作用域的資源配額只會對符合其作用域的資源使用情況進行計量和限制，作用域範圍內超過了資源配額的請求都會報驗證錯誤。ResourceQuota的4種作用域如下所示：

作用域

說明

Termination

匹配所有spec.activeDeadlineSeconds 不小於0的Pod

NotTermination

匹配所有spec.activeDeadlineSeconds是nil的Pod

BestEffort

匹配所有QoS是 BestEffort的Pod

NotBestEffort

匹配所有QoS不是BestEffort的Pod

其中，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

clipboard

5.7 資源配額與集群資源總量的關係

資源配額與集群資源總量是完全獨立的。資源配額是通過絕對的單位來配置的，這也就意味著如果在集群中新添加了節點，那麼資源配額不會自動更新，而該資源配額所對應的命名空間中的對象也不能自動增加資源上限。在某些情況下，可能希望資源配額支援更複雜的策略，如下所述。

  • 對於不同的租戶，按照比例劃分整個集群的資源。

  • 允許每個租戶都能按照需要來提高資源用量，但是有一個較寬容的限制，以防止意外的資源耗盡情況發生。

  • 探測某個命名空間的需求，添加物理節點並擴大資源配額值。

這些策略可以通過將資源配額作為一個控制模組、手動編寫一個控制器來監控資源使用情況，並調整命名空間上的資源配額來實現。資源配額將整個集群中的資源總量做了一個靜態劃分，但它並沒有對集群中的節點做任何限制：不同命名空間中的Pod仍然可以運行在同一個節點上。

參考鏈接：https://blog.csdn.net/dkfajsldfsdfsd/article/details/81004172

VirMach 便宜 VPS

QNews

QNews