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

一資源管理 1.1 資源調度機制對於Kubernetes資源，有兩個重要參數：CPU Request與Memory Request。通常在定義Pod時並沒有定義這兩個參數，此時Kubernetes會認為該Pod所需的資源很少，並可以將其調度到任何可用的Node上。因此，當集群中的計算資源不很充 ...

一資源管理

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可以獲得的資源是完全可靠的。