047.Kubernetes集群管理-資源及配額管理-有解無憂

一資源管理

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使用率的區別， 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調度失敗且有這類錯誤，那么可以嘗試以下幾種解決方法：

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

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

檢查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}}{{"\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 clipboard

解讀：

不論是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（盡力而為、不太可靠的），這三種優先級依次遞減， clipboard

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

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

不同的團隊作業在不同的命名空間下，目前這是非約束性的，在未來的版本中可能會通過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的計算資源的總和，目前支持的計算資源型別如下表：

資源名稱	說明
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這三種作用域可以限定資源配額來追蹤以下資源的使用：

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

轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/112738.html

標籤：Linux

上一篇：inno setup [registry]段使用變數

下一篇：常用LInux命令和操作

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

一 資源管理