前言

環(huán)境：k8s-v1.22.17 docker-20.10.9 centos-7.9

什么是可計(jì)算資源

CPU、GPU、Memory等都是計(jì)算資源，所謂計(jì)算資源，就是可計(jì)量的、能被申請(qǐng)的、能被分配使用的資源。
CPU在容器技術(shù)中屬于可壓縮資源，因此，pod對(duì)CPU的使用超過(guò)其cpu.limit限制一般不會(huì)導(dǎo)致容器被系統(tǒng)"殺死"，而Memory屬于不可壓縮資源，當(dāng)容器使用的memory超過(guò)其memory.limit限制時(shí)，系統(tǒng)將可能會(huì)"殺掉"容器，這就是常見(jiàn)的OOM（out of memory）異常，如果該容器的重啟策略是always，則kubelet將會(huì)重啟該容器，因此評(píng)估好pod的memory.limit是一個(gè)重要的事情。

CPU、Memory計(jì)量單位

CPU：CPU的request和limits是通過(guò)cpu核數(shù)（cpus）來(lái)度量的，單位是m（milliunit），數(shù)量可以為整數(shù)或小數(shù)，如0.1m、50m，CPU的資源是絕對(duì)值而不是相對(duì)值，比如0.1CPU在單核或多核上是一樣的，都嚴(yán)格等于0.1 CPU core。m，milliunit代表“千分之一核心”，譬如50m的含義是指50/1000核心，即5%

Memory：內(nèi)存的計(jì)量單位是字節(jié)Byte，Byte是由8個(gè)位組成的一個(gè)單元，也就是1 Byte = 8 bit。pod的內(nèi)存requests或limits都是使用整數(shù)加上國(guó)際單位制來(lái)表示內(nèi)存值，國(guó)際單位制可以是
十進(jìn)制的E、P、T、G、M、K、m或二進(jìn)制的Ei、Pi、Gi、Mi、Ki。
常見(jiàn)的KiB和MiB是以二進(jìn)制表示的字節(jié)單位，KB和MB是以十進(jìn)制表示的字節(jié)單位。
十進(jìn)制：1 KB = 1000 Byte = 8000 bit
二進(jìn)制：1 KiB = 2的10次方 Byte = 1024 Byte = 8192 bit

Mi：1Mi = 1024乘1024，而平時(shí)使用的單為M是1M = 1000乘1000

memory：內(nèi)存大小，可以使用Gi、Mi、G、M等單位
cpu的單位m：
注意：Gi和G，Mi和M優(yōu)點(diǎn)區(qū)別，官網(wǎng)解釋：Mi表示（1Mi=1024×1024）,M表示（1M=1000×1000）（其它單位類推， 如Ki/K Gi/G）

pod資源請(qǐng)求、限額方式

在k8s中，全面限制一個(gè)應(yīng)用及其中的pod所能占用的資源配額，具體可以使用下面三種方式：
1、定義每個(gè)pod的資源配額相關(guān)參數(shù)，如CPU/memory的request、limits；
2、自動(dòng)為每個(gè)沒(méi)有定義資源配額的pod添加資源配額模板（LimitRange）；
3、從總量上限制一個(gè)租戶（namespace）應(yīng)用所能使用的資源配額（ResourceQuota）

pod的request、limits是指pod中所有容器的request、limits的總和，對(duì)于沒(méi)有設(shè)置request、limits的容器，該值為0或者按照集群配置的默認(rèn)值計(jì)算；
LimiteRang正是用于解決了沒(méi)有設(shè)置配額參數(shù)的pod的默認(rèn)資源配額問(wèn)題；
REsourceQuota則約束租戶的資源總量配額問(wèn)題。

pod定義requests、limits

pod可以定義資源配額的相關(guān)參數(shù)：
spec.container[].resources.requests.cpu：容器初始要求的CPU數(shù)量
spec.container[].resources.limits.cpu：容器所能使用的最大CPU數(shù)量
spec.container[].resources.requests.memory：容器初始要求的內(nèi)存數(shù)量
spec.container[].resources.limits.memory：容器所能使用的最大內(nèi)存數(shù)量

默認(rèn)情況下，pod中只寫(xiě)requests（cpu和memory寫(xiě)其中一個(gè)或兩個(gè)都寫(xiě)）不寫(xiě)limits，則默認(rèn)沒(méi)有最大資源限制；
pod中只寫(xiě)limits.cpu、limits.memory，不寫(xiě)requests.cpu、requests.memory，默認(rèn)的requests的cpu、memory其值等于對(duì)應(yīng)的limits的cpu、memory值；
pod中只寫(xiě)limits的cpu或memory其中的一個(gè)，則requests對(duì)應(yīng)的也等價(jià)于limits的對(duì)應(yīng)的一個(gè)值。如只寫(xiě)limits.cpu，則requests.cpu值=limits.cpu值，limits.memory沒(méi)寫(xiě)則requests.memory也沒(méi)有值。

requests和limits背后的機(jī)制
如果容器運(yùn)行時(shí)是docker，那么pod的requests和limits歸根結(jié)底還是要轉(zhuǎn)換為docker run啟動(dòng)容器的參數(shù)，對(duì)應(yīng)如下：
spec.container[].resources.requests.cpu docker run --cpu-shares
spec.container[].resources.limits.cpu docker run --cpu-period
spec.container[].resources.requests.memory 無(wú)，請(qǐng)求內(nèi)存只會(huì)作為調(diào)度器的參考，不會(huì)作為如何參數(shù)傳遞給docker run
spec.container[].resources.limits.memory docker run --memory

查看節(jié)點(diǎn)資源情況

kubectl describe node master01 ：可以查看節(jié)點(diǎn)的計(jì)算資源總量和已分配量

pod使用request、limits示例

kubectl  create ns nginx	#創(chuàng)建命名空間
vim nginx-test.yaml 		#創(chuàng)建pod，pod包含2個(gè)容器
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
  namespace: nginx-test
spec:
........
    spec:
      containers:
      - image: nginx
        imagePullPolicy: IfNotPresent
        name: nginx-test-1
        resources:                              #定義資源請(qǐng)求、資源限制
          requests:                             #資源請(qǐng)求
            memory: "20Mi"                      #內(nèi)存請(qǐng)求
            cpu: "30m"                          #CPU請(qǐng)求
          limits:                               #資源限制
            memory: "50Mi"                      #內(nèi)存限制
            cpu: "50m"                          #CPU限制
        ports:
        - containerPort: 80
          name: nginx
      - image: tomcat
        imagePullPolicy: IfNotPresent
        name: tomcat-test-2
        resources:                              #定義資源請(qǐng)求、資源限制
          requests:                             #資源請(qǐng)求
            memory: "10Mi"                      #內(nèi)存請(qǐng)求
            cpu: "20m"                          #CPU請(qǐng)求
          limits:                               #資源限制
            memory: "40Mi"                      #內(nèi)存限制
            cpu: "40m"                          #CPU限制
        ports:
        - containerPort: 8080
          name: tomcat

#查看pod占用的資源情況
[root@master ~]# kubectl describe node node2  | grep -C10  nginx-test-7d448999cb-mxq6s
  Namespace        Name                           CPU Requests  CPU Limits  Memory Requests  Memory Limits  Age
  ---------        ----                           ------------  ----------  ---------------  -------------  ----
  nginx-test       nginx-test-7d448999cb-mxq6s    50m (1%)      90m (2%)    30Mi (1%)        90Mi (4%)      6m31s
可以看到，我們創(chuàng)建的pod一共請(qǐng)求50m的CPU,30Mi的內(nèi)存,最大CPU限制為90m,最大內(nèi)存限制為90Mi

LimitRange限制命名空間下的pod的資源配額

前面我們討論了pod中可以手動(dòng)定義requests.cpu、requests.memory、limits.cpu、limits.memory參數(shù)實(shí)現(xiàn)pod的資源請(qǐng)求和資源限制，但是當(dāng)集群很大，存在很多pod中，對(duì)每個(gè)pod定義資源請(qǐng)求和資源限制顯得很繁瑣，所以出現(xiàn)了LimitRange機(jī)制。

一個(gè) LimitRange（限制范圍） 對(duì)象提供的限制能夠做到：
1、在一個(gè)命名空間中實(shí)施對(duì)每個(gè) Pod 或 Container 最小和最大的資源使用量的限制。
2、在一個(gè)命名空間中實(shí)施對(duì)每個(gè) PersistentVolumeClaim 能申請(qǐng)的最小和最大的存儲(chǔ)空間大小的限制。
3、在一個(gè)命名空間中實(shí)施對(duì)一種資源的申請(qǐng)值和限制值的比值的控制。
4、設(shè)置一個(gè)命名空間中對(duì)計(jì)算資源的默認(rèn)申請(qǐng)/限制值，并且自動(dòng)的在運(yùn)行時(shí)注入到多個(gè) Container 中。

limitrange屬于命名空間，當(dāng)在一個(gè)命名空間中創(chuàng)建了一個(gè)limitrange對(duì)象，將會(huì)在該命名空間中實(shí)施 LimitRange 限制。

LimitRange機(jī)制的原理：在某個(gè)命名空間下，創(chuàng)建一個(gè)limitrang資源對(duì)象，表示對(duì)該命名空間下創(chuàng)建的pod和容器的requests和limits配置進(jìn)行限制，比如pod和容器的最大、最小、默認(rèn)requests和limits值。

下面進(jìn)行演示：

#創(chuàng)建一個(gè)命名空間
kubectl  create ns limitrang-nginx	#創(chuàng)建命名空間
#為命名空間創(chuàng)建一個(gè)limitrange
vim my-limits.yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: my-limits
  namespace: limitrang-nginx
spec:
  limits:					#定義了容器的request和limit的最大最小值，以及默認(rèn)request、limit值
  - type: Pod				#類型是pod，表示下面這段整對(duì)整個(gè)pod而言
    max:					#pod的最大值
      cpu: "4"				#pod的最大cpu
      memory: 2Gi			#pod的最大內(nèi)存
    min:					#pod的最小值
      cpu: "200m"  			#pod的最小cpu
      memory: 6Mi			#pod的最小內(nèi)存
    maxLimitRequestRatio:	#這個(gè)好像是pod的limits和requests的最大比例
      cpu: 3
      memory: 2
  - type: Container			#類型是容器，表示下面這段整對(duì)pod里面的每一個(gè)容器而言
    default:	#容器的默認(rèn)限制值,注意這是默認(rèn)limits值,當(dāng)容器沒(méi)有給定limits時(shí)將啟動(dòng)該值(下面說(shuō)的default limit就是這個(gè)參數(shù))
      cpu: 300m				#容器的默認(rèn)limits.cpu
      memory: 200Mi			#容器的默認(rèn)limits.memory
    defaultRequest:			#容器的默認(rèn)請(qǐng)求值，當(dāng)容器沒(méi)有設(shè)置request時(shí)使用
      cpu: 100m				#容器的默認(rèn)requests.cpu
      memory: 100Mi			#容器的默認(rèn)requests.memory
    max:					#容器的最大值
      cpu: 2				#容器的最大cpu,即limits.cpu
      memory: 1Gi			#容器的最大memory,即limits.memory
    min:					#容器的最小值
      cpu: 100m				#容器的最小cpu,即requests.cpu
      memory: 3Mi			#容器的最小memory,即requests.memory
    maxLimitRequestRatio:	#這個(gè)好像是容器的limits和requests的最大比例
      cpu: 5
      memory: 4
    

參數(shù)說(shuō)明：
在limitrange中，pod和container都可以設(shè)置CPU或內(nèi)存的min、max、maxLimitRequestRatio參數(shù)，container還可以定義default request和
default limit參數(shù)，而pod不能設(shè)置default request和default limit參數(shù)。
對(duì)container參數(shù)解讀如下：
container的min表示pod中所有容器的requests最小值；
container的max表示pod中所有容器的requests最大值；
container的defaultRequest是pod中所有未指定requests值的容器的的默認(rèn)request值；
container的default是pod中所有未指定limits值的容器的默認(rèn)limits值。（注意看了，default對(duì)應(yīng)的是容器默認(rèn)limits，不要被它的單詞迷糊了）
maxLimitRequestRatio這個(gè)參數(shù)好像是容器的最大超賣比例。
四個(gè)參數(shù)關(guān)系：min<=defaultRequest<=default<=max

對(duì)pod的參數(shù)解讀如下：
pod的min表示pod中全部容器的requests總和最小值；
pod的max表示pod中全部容器的limits總和最大值；
maxLimitRequestRatio這個(gè)參數(shù)好像是pod的最大超賣比例。

當(dāng)一個(gè)pod沒(méi)有定義requests或limits時(shí)，且該pod所屬命名空間中存在limitrange，則系統(tǒng)將根據(jù)limitrange給pod默認(rèn)設(shè)置對(duì)應(yīng)的requests和
limits值；
當(dāng)即沒(méi)有l(wèi)imitrange時(shí)，參考上面小節(jié)《 pod定義requests、limits》講的那樣；
當(dāng)有l(wèi)imitrange時(shí)，但是只給定了limits，沒(méi)有給定requests值時(shí)，經(jīng)驗(yàn)證，pod還是默認(rèn)requests值與limits值相等，而不是設(shè)置為limitrange設(shè)定的defaultRequest值。

Qos服務(wù)質(zhì)量等級(jí)

（暫時(shí)先忽略limitrange吧，因?yàn)镼os服務(wù)質(zhì)量等級(jí)涉及pod中容器requests和limits）
在系統(tǒng)資源不足時(shí)，k8s會(huì)選擇"殺掉"部分容器來(lái)釋放資源，選擇哪些pod進(jìn)行殺掉呢，那么如何衡量一個(gè)pod的重要程度時(shí)，使用Qos服務(wù)質(zhì)量等級(jí)衡量，k8s將容器劃分為3個(gè)QoS等級(jí)，如下：

Guaranteed：完全可靠的，是指pod的所有容器都定義了requests和limits，并且每一個(gè)容器的requests和limits值都對(duì)應(yīng)相等且不為0，我們指定，如果定義了limits沒(méi)有定義requests，那么requests值就等于limits，這種pod的QoS等級(jí)就是Guaranteed。

Burstable：彈性波動(dòng)，較可靠的，當(dāng)pod的QoS等級(jí)既不是Guaranteed又不是BestEffect，那就是Burstable；
這分為2種情況：pod中一部分容器定義了requests和limits且requests值小于limits值；pod中一部分容器都未定義requests和limits。注意：這里說(shuō)的是沒(méi)有定義requests和limits，但是不代表這里limitrange不會(huì)默認(rèn)設(shè)置，這里可以先暫時(shí)忽略limitrange吧。

BestEffect：盡力而為，不太可靠的，是指pod中所有容器都沒(méi)有定義requests和limits，那么這種pod的QoS等級(jí)就是BestEffect。注意：這里說(shuō)的是沒(méi)有定義requests和limits，但是不代表這里limitrange不會(huì)默認(rèn)設(shè)置，這里可以先暫時(shí)忽略limitrange吧。

Guaranteed > Burstable > BestEffect

資源配額管理 Resource Quotas

一個(gè)k8s集群可能被多個(gè)租戶使用，如何分配不同租戶可以使用的資源呢？ Resource Quotas就是來(lái)解決這個(gè)問(wèn)題的。
一般的，一個(gè)租戶占用一個(gè)命名空間，則可以在該命名空間下創(chuàng)建 Resource Quotas來(lái)進(jìn)行資源使用限制；
Resource Quotas可以限制命名空間中某種資源類型對(duì)象的總數(shù)上限，也可以限制命名空間中pod可使用的可計(jì)算資源（可計(jì)算資源：cpu、memory）的總上限；資源配額還支持作用域，對(duì)符合特定范圍的對(duì)象加以限制。
官網(wǎng)：https://kubernetes.io/zh-cn/docs/concepts/policy/resource-quotas/

一個(gè)命名空間可以設(shè)定多個(gè)resourcequotas，resourcequotas在k8s中可以簡(jiǎn)寫(xiě)為quota。

#資源配額，對(duì)指定命名空間某種資源對(duì)象總數(shù)進(jìn)行限制
[root@master ~]# vim resource-count.yaml 
apiVersion: v1
kind: ResourceQuota
metadata:
  name: resource-count
  namespace: limitrang-nginx				#quota在哪個(gè)命名空間就表示對(duì)該命名空間進(jìn)行限制
spec:
  hard:										#目前支持對(duì)下面這些資源對(duì)象進(jìn)行總數(shù)量限制
    configmaps: "50"                        #在該命名空間中允許存在的 ConfigMap 總數(shù)上限
    persistentvolumeclaims: "50"            #在該命名空間中允許存在的 PVC 的總數(shù)上限
    pods: "4"                               #在該命名空間中允許存在的非終止?fàn)顟B(tài)的 Pod 總數(shù)上限
    replicationcontrollers: "35"            #在該命名空間中允許存在的 ReplicationController 總數(shù)上限
    resourcequotas: "34"                    #在該命名空間中允許存在的 ResourceQuota 總數(shù)上限
    services: "68"                          #在該命名空間中允許存在的 Service 總數(shù)上限
    services.loadbalancers: "465"           #在該命名空間中允許存在的 LoadBalancer 類型的 Service 總數(shù)上限
    services.nodeports: "65"                #在該命名空間中允許存在的 NodePort 類型的 Service 總數(shù)上限
    secrets: "6"                            #在該命名空間中允許存在的 Secret 總數(shù)上限

#測(cè)試，在limitrang-nginx命名空間中擴(kuò)容副本數(shù)，單由于quota限制了pod副本數(shù)最大只能是4個(gè)，所以deployment擴(kuò)容并不會(huì)成功
#擴(kuò)容到10個(gè)副本
[root@master ~]# kubectl  scale  deployment -n limitrang-nginx  nginx  --replicas=10
[root@master ~]# kubectl  describe deployments.apps  nginx --namespace=limitrang-nginx  | grep Replicas
Replicas:               10 desired | 4 updated | 4 total | 4 available | 6 unavailable

#通過(guò)查看deployment對(duì)應(yīng)的rs，我們看到rs的報(bào)錯(cuò)信息，正是由于quota限制命名空間pod副本數(shù)最大只能是4個(gè)才導(dǎo)致報(bào)錯(cuò)擴(kuò)容不成功
[root@master ~]# kubectl -n limitrang-nginx  describe  rs nginx-6799fc88d8 | tail  -n 1
  Warning  FailedCreate      14m   replicaset-controller  Error creating: pods "nginx-6799fc88d8-tmjpt" 
  is forbidden: exceeded quota: resource-count, requested: pods=1, used: pods=4, limited: pods=4
[root@master ~]# 

#資源配額，對(duì)指定命名空間可計(jì)算資源資源總數(shù)進(jìn)行限制
[root@master ~]# vim compute-resources.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    requests.cpu: "100"				#所有非終止?fàn)顟B(tài)的 Pod，其 CPU 需求總量不能超過(guò)該值
    requests.memory: 100Gi			#所有非終止?fàn)顟B(tài)的 Pod，其內(nèi)存需求總量不能超過(guò)該值
    limits.cpu: "200"				#所有非終止?fàn)顟B(tài)的 Pod，其 CPU 限額總量不能超過(guò)該值
    limits.memory: 200Gi			#所有非終止?fàn)顟B(tài)的 Pod，其內(nèi)存限額總量不能超過(guò)該值
    requests.nvidia.com/gpu: 4		#所有非終止?fàn)顟B(tài)的 Pod，GPU需求總量不能超過(guò)該值
#   hugepages-<size>: xx			#對(duì)于所有非終止?fàn)顟B(tài)的 Pod，針對(duì)指定尺寸的巨頁(yè)請(qǐng)求總數(shù)不能超過(guò)此值
EOF

#例子不舉了

還可以對(duì)存儲(chǔ)資源配額：

requests.storage: 所有PVC存儲(chǔ)資源的需求總量不能超過(guò)該值
persistentvolumeclaims: 該命名空間中允許的PVC總數(shù)量
<storage-class-name>.storageclass.storage.k8s.io/requests.storage: 在所有與 <storage-class-name> 相關(guān)的持久卷申領(lǐng)中，存儲(chǔ)請(qǐng)求的總和不能超過(guò)該值
<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims: 在與 storage-class-name 相關(guān)的所有持久卷申領(lǐng)中，命名空間中可以存在的持久卷申領(lǐng)總數(shù)

配額作用域
資源配額可以指定作用域，對(duì)符合特定范圍的對(duì)象加以限制；
更詳細(xì)可以看官網(wǎng)：https://kubernetes.io/zh-cn/docs/concepts/policy/resource-quotas/#quota-scopes

apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pods-low
  spec:
    hard:
      cpu: "5"
      memory: 10Gi
      pods: "10"
    scopeSelector:			#指定了作用域選擇器
      matchExpressions:
      - operator: In
        scopeName: PriorityClass
        values: ["low"]

總結(jié)

1、可計(jì)算資源

cpu、memory是k8s中最常見(jiàn)的可計(jì)算資源，cpu是可壓縮資源，cpu可被超量使用，memory是不可壓縮資源，超出內(nèi)存最大值將發(fā)生OOM異常；

2、cpu的單位

cpu的是通過(guò)cpu核數(shù)（cpus）來(lái)度量的，單位是m（milliunit），數(shù)量可以為整數(shù)或小數(shù)，如0.1m、50m；單位m，因?yàn)楹x是milliunit，代表"千分
之一核心"，譬如50m的含義是指50/1000核心，即5%。

3、memory的單位

Memory：內(nèi)存的計(jì)量單位是字節(jié)Byte，Byte是由8個(gè)位組成的一個(gè)單元，也就是1 Byte = 8 bit。pod的內(nèi)存requests或limits都是使用整數(shù)加上國(guó)際
單位制來(lái)表示內(nèi)存值，國(guó)際單位制可以是
十進(jìn)制的E、P、T、G、M、K、m或二進(jìn)制的Ei、Pi、Gi、Mi、Ki。
常見(jiàn)的KiB和MiB是以二進(jìn)制表示的字節(jié)單位，KB和MB是以十進(jìn)制表示的字節(jié)單位。
十進(jìn)制：1 KB = 1000 Byte = 8000 bit
二進(jìn)制：1 KiB = 2的10次方 Byte = 1024 Byte = 8192 bit

Mi：1Mi = 1024乘1024，而平時(shí)使用的單為M是1M = 1000乘1000

memory：內(nèi)存大小，可以使用Gi、Mi、G、M等單位
cpu的單位m：
注意：Gi和G，Mi和M優(yōu)點(diǎn)區(qū)別，官網(wǎng)解釋：Mi表示（1Mi=1024×1024）,M表示（1M=1000×1000）（其它單位類推， 如Ki/K Gi/G）

4、pod定義requests、limits來(lái)進(jìn)行容器的cpu、memory資源請(qǐng)求和限制

pod的request等于pod中所有容器的request相加之和。
pod的limit等于pod中所有容器的limits相加之和。

pod可以定義資源配額的相關(guān)參數(shù)：
spec.container[].resources.requests.cpu：容器初始要求的CPU數(shù)量
spec.container[].resources.limits.cpu：容器所能使用的最大CPU數(shù)量
spec.container[].resources.requests.memory：容器初始要求的內(nèi)存數(shù)量
spec.container[].resources.limits.memory：容器所能使用的最大內(nèi)存數(shù)量

默認(rèn)情況下，pod中只寫(xiě)requests（cpu和memory寫(xiě)其中一個(gè)或兩個(gè)都寫(xiě)）不寫(xiě)limits，則默認(rèn)沒(méi)有最大資源限制；
pod中只寫(xiě)limits.cpu、limits.memory，不寫(xiě)requests.cpu、requests.memory，默認(rèn)的requests的cpu、memory其值等于對(duì)應(yīng)的limits的cpu、
memory值；
pod中只寫(xiě)limits的cpu或memory其中的一個(gè)，則requests對(duì)應(yīng)的也等價(jià)于limits的對(duì)應(yīng)的一個(gè)值。如只寫(xiě)limits.cpu，則requests.cpu值
=limits.cpu值，limits.memory沒(méi)寫(xiě)則requests.memory也沒(méi)有值。

5、LimitRange限制命名空間下的pod的資源配額

limitrange屬于命名空間，當(dāng)在一個(gè)命名空間中創(chuàng)建了一個(gè)limitrange對(duì)象，將會(huì)在該命名空間中實(shí)施 LimitRange 限制。
LimitRange機(jī)制的原理：在某個(gè)命名空間下，創(chuàng)建一個(gè)limitrang資源對(duì)象，表示對(duì)該命名空間下創(chuàng)建的pod和容器的requests和limits配置進(jìn)行限
制，比如pod和容器的最大、最小、默認(rèn)requests和limits值。
spec:
  limits:					#定義了容器的request和limit的最大最小值，以及默認(rèn)request、limit值
  - type: Pod				#類型是pod，表示下面這段整對(duì)整個(gè)pod而言
    max:					#pod的最大值
      cpu: "4"				#pod的最大cpu
      memory: 2Gi			#pod的最大內(nèi)存
    min:					#pod的最小值
      cpu: "200m"  			#pod的最小cpu
      memory: 6Mi			#pod的最小內(nèi)存
    maxLimitRequestRatio:	#這個(gè)好像是pod的limits和requests的最大比例
      cpu: 3
      memory: 2
  - type: Container			#類型是容器，表示下面這段整對(duì)pod里面的每一個(gè)容器而言
    default:	#容器的默認(rèn)限制值,注意這是默認(rèn)limits值,當(dāng)容器沒(méi)有給定limits時(shí)將啟動(dòng)該值(下面說(shuō)的default limit就是這個(gè)參數(shù))
      cpu: 300m				#容器的默認(rèn)limits.cpu
      memory: 200Mi			#容器的默認(rèn)limits.memory
    defaultRequest:			#容器的默認(rèn)請(qǐng)求值，當(dāng)容器沒(méi)有設(shè)置request時(shí)使用
      cpu: 100m				#容器的默認(rèn)requests.cpu
      memory: 100Mi			#容器的默認(rèn)requests.memory
    max:					#容器的最大值
      cpu: 2				#容器的最大cpu,即limits.cpu
      memory: 1Gi			#容器的最大memory,即limits.memory
    min:					#容器的最小值
      cpu: 100m				#容器的最小cpu,即requests.cpu
      memory: 3Mi			#容器的最小memory,即requests.memory
    maxLimitRequestRatio:	#這個(gè)好像是容器的limits和requests的最大比例
      cpu: 5
      memory: 4

6、pod的Qos服務(wù)質(zhì)量等級(jí)

在k8s系統(tǒng)中，使用Qos服務(wù)質(zhì)量等級(jí)來(lái)衡量一個(gè)pod的重要程度，當(dāng)k8s集群資源不足時(shí)，如內(nèi)存不足，那么Qos服務(wù)質(zhì)量等級(jí)低的pod將會(huì)被優(yōu)先"殺
掉"以是否系統(tǒng)資源壓力， k8s將pod劃分為3個(gè)QoS等級(jí)，如下：

Guaranteed：完全可靠的，是指pod的所有容器都定義了requests和limits，并且每一個(gè)容器的requests和limits值都對(duì)應(yīng)相等且不為0，我們指定，
如果定義了limits沒(méi)有定義requests，那么requests值就等于limits，這種pod的QoS等級(jí)就是Guaranteed。

Burstable：彈性波動(dòng)，較可靠的，當(dāng)pod的QoS等級(jí)既不是Guaranteed又不是BestEffect，那就是Burstable；
這分為2種情況：pod中一部分容器定義了requests和limits且requests值小于limits值；pod中一部分容器都未定義requests和limits。注意：這里
說(shuō)的是沒(méi)有定義requests和limits，但是不代表這里limitrange不會(huì)默認(rèn)設(shè)置，這里可以先暫時(shí)忽略limitrange吧。

BestEffect：盡力而為，不太可靠的，是指pod中所有容器都沒(méi)有定義requests和limits，那么這種pod的QoS等級(jí)就是BestEffect。注意：這里說(shuō)的
是沒(méi)有定義requests和limits，但是不代表這里limitrange不會(huì)默認(rèn)設(shè)置，這里可以先暫時(shí)忽略limitrange吧。

Guaranteed > Burstable > BestEffect

7、資源配額管理 Resource Quotas

k8s集群是一個(gè)多租戶的系統(tǒng)，可能有多個(gè)命名空間，一般的每個(gè)租戶占用一個(gè)命名空間進(jìn)行自己的應(yīng)用部署，那么如何分配不同租戶可以使用的資源呢？ Resource Quotas就是來(lái)解決這個(gè)問(wèn)題的。
一般的，一個(gè)租戶占用一個(gè)命名空間，則可以在該命名空間下創(chuàng)建 Resource Quotas來(lái)進(jìn)行資源使用限制；
Resource Quotas可以限制命名空間中某種資源類型對(duì)象的總數(shù)上限，也可以限制命名空間中pod可使用的可計(jì)算資源（可計(jì)算資源：cpu、memory）的總上限；資源配額還支持作用域，對(duì)符合特定范圍的對(duì)象加以限制。

8、limitrange和resourcequotas的區(qū)別文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-427058.html

limitrange主要是對(duì)一個(gè)命名空間下創(chuàng)建的pod和容器的requests和limits配置進(jìn)行限制，比如pod和容器的最大、最小、默認(rèn)requests和limits值等，換句話說(shuō)，limitrange針對(duì)的是單個(gè)pod的可計(jì)算資源；
resourcequotas是對(duì)命名空間中某種資源對(duì)象總數(shù)進(jìn)行限制，如A命名空間能創(chuàng)建多少個(gè)pod，能創(chuàng)建多少個(gè)configmap等；
resourcequotas還可以對(duì)指定命名空間的可計(jì)算資源總數(shù)進(jìn)行限制，如限制A命名空間中全部非終止?fàn)顟B(tài)的pod的CPU和memory不能超過(guò)多少；
resourcequotas還可以對(duì)指定命名空間的存儲(chǔ)資源總數(shù)進(jìn)行限制，如限制A命名空間中的pvc數(shù)量不能超過(guò)100個(gè)等。

到了這里，關(guān)于pod的requests、limits解讀、LimitRange資源配額、Qos服務(wù)質(zhì)量等級(jí)、資源配額管理 Resource Quotas的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！