一、基本了解

為什么會有資源配額管理？

• 可以提高集群穩(wěn)定性，確保指定的資源對象在任何時(shí)候都不會超量占用系統(tǒng)物理資源，避免業(yè)務(wù)進(jìn)程在設(shè)計(jì)或?qū)崿F(xiàn)上的缺陷導(dǎo)致整個(gè)系統(tǒng)運(yùn)行紊亂甚至意外宕機(jī)。

資源配額管理維度：

1. 容器級別，定義每個(gè)Pod上資源配額相關(guān)的參數(shù)，比如CPU/Memory、Request/Limit；
2. Pod級別，自動(dòng)為每個(gè)沒有定義資源配額的Pod添加資源配額模板，比如LimitRanger。
3. Namespace級別，從總量上限制一個(gè)租戶（應(yīng)用）所能使用的資源配額，比如ResourceQuota，包括資源有：Pod數(shù)量、Replication Controller數(shù)量、Service數(shù)量、ResourceQuota數(shù)量、Secret數(shù)量和可持有的PV數(shù)量。

資源配額參數(shù)：

• 程序所使用的CPU與Memory是一個(gè)動(dòng)態(tài)的量，跟負(fù)載密切相關(guān)，當(dāng)負(fù)載增加時(shí)，CPU和Memory的使用量也會增加。
• 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ù)量。

1.1 資源計(jì)算

• Pod的Requests或Limits指該P(yáng)od中所有容器的Requests或Limits的總和，若Pod中沒有設(shè)置Requests或Limits的容器，則該項(xiàng)的值被當(dāng)作0或者按照集群配置的默認(rèn)值來計(jì)算。

計(jì)算CPU：

• CPU的Requests和Limits是通過CPU數(shù)（cpus）來度量的。
• CPU的資源值是絕對值，而不是相對值，比如0.1CPU在單核或多核機(jī)器上是一樣的，都嚴(yán)格等于0.1 CPU core。

計(jì)算Memory：

• 內(nèi)存的Requests和Limits計(jì)量單位是字節(jié)數(shù)。使用整數(shù)或者定點(diǎn)整數(shù)加上國際單位制來表示內(nèi)存值。
• 國際單位制包括十進(jìn)制的E、P、T、G、M、K、m，或二進(jìn)制的Ei、Pi、Ti、Gi、Mi、Ki。
• KiB與MiB是以二進(jìn)制表示的字節(jié)單位，常見的KB與MB則是以十進(jìn)制表示的字節(jié)單位，比如：
  • 1 KB=1000 Bytes=8000 Bits；
  • 1 KiB=2^10 Bytes=1024 Bytes=8192 Bits。

注意事項(xiàng)：

• 計(jì)算資源單位大小寫敏感，m表示千分之一單位，M表示十進(jìn)制的1000，二者的含義不同。

1.2 調(diào)度機(jī)制

基于Requests和Limits的Pod調(diào)度機(jī)制：

• 調(diào)度器在調(diào)度時(shí)，首先要確保調(diào)度后該節(jié)點(diǎn)上所有Pod的CPU和內(nèi)存的Requests總和，不超過該節(jié)點(diǎn)能提供給Pod使用的CPU和Memory的最大容量值。
• 例如，某個(gè)節(jié)點(diǎn)上的CPU資源充足，而內(nèi)存為4GB，其中3GB可以運(yùn)行Pod，而某Pod的Memory Requests為1GB、Limits為2GB，那么在這個(gè)節(jié)點(diǎn)上最多可以運(yùn)行3個(gè)這樣的Pod。

Requests和Limits的背后機(jī)制：

• kubelet在啟動(dòng)Pod的某個(gè)容器時(shí)，會將容器的Requests和Limits值轉(zhuǎn)化為相應(yīng)的容器啟動(dòng)參數(shù)傳遞給容器執(zhí)行器（Docker或者rkt）。
• 若容器的執(zhí)行環(huán)境是Docker，那么容器的4個(gè)參數(shù)傳遞給Docker的過程如下：
  1. spec.container[].resources.requests.cpu：參數(shù)值會被轉(zhuǎn)化為core數(shù)（比如配置的100m會轉(zhuǎn)化為0.1），然后乘以1024，再將這個(gè)結(jié)果作為–cpu-shares參數(shù)的值傳遞給docker run命令。
  2. spec.container[].resources.limits.cpu：參數(shù)值會被轉(zhuǎn)化為millicore數(shù)（比如配置的1被轉(zhuǎn)化為1000，配置的100m被轉(zhuǎn)化為100），將此值乘以100000，再除以1000，然后將結(jié)果值作為–cpu-quota參數(shù)的值傳遞給docker run命令。
  3. spec.container[].resources.requests.memory：參數(shù)值只提供給Kubernetes調(diào)度器作為調(diào)度和管理的依據(jù)，不會作為任何參數(shù)傳遞給Docker。
  4. spec.container[].resources.limits.memory：參數(shù)值會被轉(zhuǎn)化為單位為Bytes的整數(shù)，值作為–memory參數(shù)傳遞給docker run命令。

常見問題分析：

1. 若Pod狀態(tài)為Pending，錯(cuò)誤信息為FailedScheduling。若調(diào)度器在集群中找不到合適的節(jié)點(diǎn)來運(yùn)行Pod，那么這個(gè)Pod會一直處于未調(diào)度狀態(tài)，直到調(diào)度器找到合適的節(jié)點(diǎn)為止。每次調(diào)度器嘗試調(diào)度失敗時(shí)，Kubernetes都會產(chǎn)生一個(gè)事件。
2. 容器被強(qiáng)行終止（Terminated）。如果容器使用的資源超過了它配置的Limits，那么該容器可能被強(qiáng)制終止。我們可以通過kubectl describe pod命令來確認(rèn)容器是否因?yàn)檫@個(gè)原因被終止

1.3 服務(wù)質(zhì)量等級

Pod的三種QoS級別：

1. Guaranteed（完全可靠的）：如果Pod中的所有容器對所有資源類型都定義了Limits和Requests，并且所有容器的Limits值都和Requests值相等（且都不為0），那么該P(yáng)od的QoS級別就是Guaranteed。
   • 未定義Requests值，所以其默認(rèn)等于Limits值。
   • 其中定義的Requests與Limits的值完全相同。
2. BestEffort（盡力而為、不太可靠的）：如果Pod中所有容器都未定義資源配置（Requests和Limits都未定義），那么該P(yáng)od的QoS級別就是BestEffort。
3. Burstable（彈性波動(dòng)、較可靠的）：當(dāng)一個(gè)Pod既不為Guaranteed級別，也不為BestEffort級別時(shí)，該P(yáng)od的QoS級別就是Burstable。
   • Pod中的一部分容器在一種或多種資源類型的資源配置中定義了Requests值和Limits值（都不為0），且Requests值小于Limits值。
   • Pod中的一部分容器未定義資源配置（Requests和Limits都未定義）。

工作特點(diǎn)：

1. BestEffort Pod的優(yōu)先級最低，在這類Pod中運(yùn)行的進(jìn)程會在系統(tǒng)內(nèi)存緊缺時(shí)被第一優(yōu)先“殺掉”。當(dāng)然，從另一個(gè)角度來看，BestEffortPod由于沒有設(shè)置資源Limits，所以在資源充足時(shí)，它們可以充分使用所有閑置資源。
2. Burstable Pod的優(yōu)先級居中，這類Pod在初始時(shí)會被分配較少的可靠資源，但可以按需申請更多的資源。當(dāng)然，如果整個(gè)系統(tǒng)內(nèi)存緊缺，又沒有BestEffort容器可以被殺掉以釋放資源，那么這類Pod中的進(jìn)程可能被“殺掉”。
3. Guaranteed Pod的優(yōu)先級最高，而且一般情況下這類Pod只要不超過其資源Limits的限制就不會被“殺掉”。當(dāng)然，如果整個(gè)系統(tǒng)內(nèi)存緊缺，又沒有其他更低優(yōu)先級的容器可以被“殺掉”以釋放資源，那么這類Pod中的進(jìn)程也可能會被“殺掉”。

二、資源配額 ResourceQuota

為何會有資源配額？

• 當(dāng)多個(gè)團(tuán)隊(duì)、多個(gè)用戶共享使用K8s集群時(shí)，會出現(xiàn)不均勻資源使用，默認(rèn)情況下先到先得，這時(shí)可以通過ResourceQuota來對命名空間資源使用總量做限制，從而解決這個(gè)問題。

使用流程：

• k8s管理員為每個(gè)命名空間創(chuàng)建一個(gè)或多個(gè)ResourceQuota對象，定義資源使用總量，K8s會跟蹤命名空間資源使用情況，當(dāng)超過定義的資源配額會返回拒絕。

注意事項(xiàng)：

• 如果在集群中新添加了節(jié)點(diǎn)，資源配額不會自動(dòng)更新，該資源配額所對應(yīng)的命名空間中的對象也不能自動(dòng)增加資源上限。

2.1 支持的限制資源

資源限制對象：

1. 容器資源請求值（requests）：命名空間下的所有pod申請資源時(shí)設(shè)置的requests總和不能超過這個(gè)值。
   • resources.requests.cpu
   • resources.requests.memory
2. 容器資源限制值（limits）：命名空間下的所有pod申請資源時(shí)設(shè)置的limits總和不能超過這個(gè)值。
   • resources.limits.cpu
   • resources.limits.memory

注意事項(xiàng)：

1. CPU單位：可以寫m也可以寫浮點(diǎn)數(shù)，例如0.5=500m，1=1000m
2. requests必須小于limits，建議一個(gè)理論值：requests值小于limits的20%-30%，一般是limits的70%。
3. limits盡量不要超過所分配宿主機(jī)物理配置的80%，否則沒有限制意義
4. requests只是一個(gè)預(yù)留性質(zhì)，并非實(shí)際的占用，用于k8s合理的分配資源（每個(gè)節(jié)點(diǎn)都有可分配的資源，k8s抽象的將這些節(jié)點(diǎn)資源統(tǒng)一分配）。比如requests分配1核1G，在滿足的節(jié)點(diǎn)上創(chuàng)建完容器后實(shí)際資源可能只有0.5C1G。
5. requests會影響pod調(diào)度，k8s只能將pod分配到能滿足該requests值的節(jié)點(diǎn)上。
6. ResourceQuota功能是一個(gè)準(zhǔn)入控制插件，默認(rèn)已經(jīng)啟用。

2.2 配額作用域

• 每個(gè)配額都有一組相關(guān)的 scope（作用域），配額只會對作用域內(nèi)的資源生效。 配額機(jī)制僅統(tǒng)計(jì)所列舉的作用域的交集中的資源用量。
• 當(dāng)一個(gè)作用域被添加到配額中后，它會對作用域相關(guān)的資源數(shù)量作限制。 如配額中指定了允許（作用域）集合之外的資源，會導(dǎo)致驗(yàn)證錯(cuò)誤。
• scopeSelector 支持在 operator 字段中使用以下值：
  • In
  • NotIn
  • Exists
  • DoesNotExist

注意事項(xiàng)：

• 不能在同一個(gè)配額對象中同時(shí)設(shè)置 Terminating 和 NotTerminating 作用域。
• 不能在同一個(gè)配額中同時(shí)設(shè)置 BestEffort 和 NotBestEffort 作用域。
• 定義 scopeSelector 時(shí)，如果使用以下值之一作為 scopeName 的值，則對應(yīng)的 operator 只能是 Exists：
  • Terminating
  • NotTerminating
  • BestEffort
  • NotBestEffort

2.3 資源配額選型

2.3.1 計(jì)算資源配額

• 用戶可以對給定命名空間下的可被請求的 計(jì)算資源 總量進(jìn)行限制。

示例：

apiVersion: v1
kind: ResourceQuota
metadata:
 name: compute-resources
 namespace: test        ##作用在哪個(gè)命名空間，對該命名空間的pod資源進(jìn)行限制。
spec:
 hard:
   requests.cpu: "4"        ##test命名空間下的所有pod的cpu資源最小請求值不能超過4核。
   requests.memory: 10Gi    ##test命名空間下的所有pod的內(nèi)存資源最小請求值不能超過10G。
   limits.cpu: "6"          ##test命名空間下的所有pod內(nèi)的應(yīng)用cpu資源最大限制值不能超過6核。
   limits.memory: 12Gi      ##test命名空間下的所有pod內(nèi)的應(yīng)用內(nèi)存資源最大限制值不能超過12G。

1.創(chuàng)建一個(gè)計(jì)算資源配額qingjun，限制test命名空間的pod，最小請求cpu為2核，最小請求內(nèi)存大小為2G；容器最大使用資源不能超過cpu 6核、內(nèi)存10G。

[root@k8s-master1 ResourceQuota]# cat rq1.yaml 
apiVersion: v1
kind: ResourceQuota
metadata:
  name: qingjun
  namespace: test
spec:
  hard:
    requests.cpu: 2
    requests.memory: 2Gi
    limits.cpu: 6
    limits.memory: 10Gi

[root@k8s-master1 ResourceQuota]# kubectl  apply -f rq1.yaml 

2.查看創(chuàng)建的resourcequota。

3.創(chuàng)建pod資源，查看效果。此時(shí)所創(chuàng)建的3個(gè)pod要求資源是滿足的，所以創(chuàng)建成功。

[root@k8s-master1 ResourceQuota]# cat deploy.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
  namespace: test
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        resources: 
          requests:
            cpu: 0.2
            memory: 200Mi
          limits:
            cpu: 1
            memory: 1Gi

[root@k8s-master1 ResourceQuota]# kubectl  apply -f deploy.yaml 

4.給這組pod擴(kuò)容到10個(gè)，發(fā)現(xiàn)最終只能擴(kuò)容到6個(gè)，因?yàn)槊總€(gè)pod上限配置為cpu 1核、內(nèi)存 1G，而限制的資源計(jì)數(shù)配額上限配置為6核，超過的部分不會被創(chuàng)建。

[root@k8s-master1 ResourceQuota]# kubectl  scale deploy nginx --replicas=10 -n test

5.查看創(chuàng)建失敗原因。

[root@k8s-master1 ResourceQuota]# kubectl  describe rs -n test

2.3.2 存儲資源配額

• 用戶可以對給定命名空間下的存儲資源 總量進(jìn)行限制。

示例：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-resources
  namespace: test
spec:
  hard:
    requests.storage: "10G"     ##限制pvc能使用的最大內(nèi)存。
    managed-nfs-storage.storageclass.storage.k8s.io/requests.storage: "5G"

1.創(chuàng)建資源配額baimu。

[root@k8s-master1 ResourceQuota]# cat rq2.yaml 
apiVersion: v1
kind: ResourceQuota
metadata:
  name: baimu
  namespace: test
spec:
  hard:
    requests.storage: "10G"

[root@k8s-master1 ResourceQuota]# kubectl  apply -f  rq2.yaml 

2.創(chuàng)建pvc測試效果，先創(chuàng)建指定內(nèi)存為8G，小于限制大小，可以創(chuàng)建成功。

[root@k8s-master1 ResourceQuota]# cat pvc.yaml 
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
  namespace: test
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi

[root@k8s-master1 ResourceQuota]# kubectl  apply -f pvc.yaml

3.再創(chuàng)建第二個(gè)pvc，同樣申請8G，此時(shí)會創(chuàng)建失敗，原因是先前創(chuàng)建的pvc已經(jīng)占用了8G，而這次創(chuàng)建要求的8G已經(jīng)超過了限制大小的10G。

2.3.3 對象數(shù)量配額

• 你可以使用以下語法對所有標(biāo)準(zhǔn)的、命名空間域的資源類型進(jìn)行配額設(shè)置。
• count/< resource >.< group >：用于非核心（core）組的資源。
• count/< resource >：用于核心組的資源

示例：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-counts
  namespace: test
spec:
  hard:
    pods: "10"            ##最多可以創(chuàng)建pod數(shù)量。
    count/deployments.apps: "3"          ##最多可以創(chuàng)建deploy數(shù)量。
    count/services: "3"                  ##最多可以創(chuàng)建svc數(shù)量。

1.創(chuàng)建資源配額wuhan1。

[root@k8s-master1 ResourceQuota]# cat rq3.yaml 
apiVersion: v1
kind: ResourceQuota
metadata:
  name: wuhan
  namespace: test
spec:
  hard:
    pods: "10"                       ##最多可以創(chuàng)建pod數(shù)量。
    count/deployments.apps: "3"      ##最多可以創(chuàng)建deploy數(shù)量。
    count/services: "3"              ##最多可以創(chuàng)建svc數(shù)量。

[root@k8s-master1 ResourceQuota]# kubectl  apply -f rq3.yaml 

2.創(chuàng)建一個(gè)deploy，其pod副本有3個(gè)，滿足限制要求，創(chuàng)建成功。

3.創(chuàng)建第二個(gè)、第三個(gè)deploy資源都可以，創(chuàng)建第四個(gè)deploy失敗，原因時(shí)超過了限制要求。

三、資源限制 LimitRange

基本了解：

• 默認(rèn)情況下，K8s集群上的容器對計(jì)算資源沒有任何限制，可能會導(dǎo)致個(gè)別容器資源過大導(dǎo)致影響其他容器正常工
  作，這時(shí)可以使用LimitRange定義容器默認(rèn)CPU和內(nèi)存請求值或者最大上限。
• 也存在員工在設(shè)置ResourceQuota時(shí)，過大或過小，甚至忘記設(shè)置。那么limirange就可以設(shè)置個(gè)默認(rèn)值，即時(shí)忘記沒有設(shè)置限制值時(shí)，也可給你設(shè)置個(gè)默認(rèn)限制值；也可以限制員工在設(shè)置限制值時(shí)要合理，不能超過limitrange的最小值，也不能低于limitrange的最小值。

LimitRange限制維度：

1. 限制容器配置requests.cpu/memory，limits.cpu/memory的最小、最大值。
2. 限制容器配置requests.cpu/memory，limits.cpu/memory的默認(rèn)值。
3. 限制PVC配置requests.storage的最小、最大值。

注意事項(xiàng)：

3.1 限制資源大小值

1.創(chuàng)建一個(gè)LimitRange。

[root@k8s-master1 ResourceQuota]# cat lr1.yaml 
apiVersion: v1
kind: LimitRange
metadata:
  name: qingjun
  namespace: test        ##策略作用哪個(gè)命名空間。
spec:
  limits:
  - max:                 ##容器能設(shè)置limit的最大值。
      cpu: 1
      memory: 1Gi
    min:                 ##容器能設(shè)置request的最小值。
      cpu: 200m 
      memory: 200Mi
    type: Container    ##限制對象。

[root@k8s-master1 ResourceQuota]# kubectl  apply -f lr1.yaml 

2.創(chuàng)建資源測試。創(chuàng)建的pod申請最大cpu資源超過設(shè)置值，會創(chuàng)建失敗，限制成功。

[root@k8s-master1 ResourceQuota]# kubectl  describe rs -n test 

3.創(chuàng)建的pod申請最小cpu資源低于設(shè)置值，會創(chuàng)建失敗，限制成功。

3.2 設(shè)置限制默認(rèn)值

基本了解：

• 這個(gè)資源默認(rèn)值，是在限制資源大小值時(shí)就會默認(rèn)創(chuàng)建，根據(jù)max最大值創(chuàng)建。
• 當(dāng)默認(rèn)值不合理時(shí)，需要我們手動(dòng)去設(shè)置。
• Containers可以設(shè)置限制默認(rèn)值，Pod不能設(shè)置Default Request和Default Limit參數(shù)。
  

1.可以直接在限制大小的基礎(chǔ)上設(shè)置限制默認(rèn)值。

[root@k8s-master1 ResourceQuota]# cat lr1.yaml 
apiVersion: v1
kind: LimitRange
metadata:
  name: qingjun
  namespace: test
spec:
  limits:
  - max:               ##限制最大值。
      cpu: 2            
      memory: 5Gi
    min:               ##限制最小值。
      cpu: 0.5 
      memory: 1Gi
    type: Container
    default:              ##限制默認(rèn)最大值。
      cpu: 1
      memory: 3Gi
    defaultRequest:       ##限制默認(rèn)最小值。
      cpu: 0.5
      memory: 1Gi

[root@k8s-master1 ResourceQuota]# kubectl  apply  -f lr1.yaml 

2.查看。

3.創(chuàng)建pod時(shí)不設(shè)置資源申請大小時(shí)，可以看到會默認(rèn)設(shè)置成默認(rèn)值。

##創(chuàng)建。
[root@k8s-master1 ResourceQuota]# kubectl  run nginx1 --image=nginx -n test

##查看。
[root@k8s-master1 ResourceQuota]# kubectl  describe  pod nginx1 -n test

3.3 限制存儲大小值

1.創(chuàng)建限制策略。

[root@k8s-master1 ResourceQuota]# cat lr2.yaml 
apiVersion: v1
kind: LimitRange
metadata:
  name: baimu1
  namespace: test
spec:
  limits:
  - type: PersistentVolumeClaim
    max:
      storage: 10Gi
    min:
      storage: 1Gi

[root@k8s-master1 ResourceQuota]# kubectl  apply -f lr2.yaml 

2.測試效果。生成一個(gè)pvc，申請資源為15G，超過了設(shè)置的限制最大值，創(chuàng)建失敗，測試成功。

3.創(chuàng)建pvc的申請資源改成8G后，符合設(shè)置的限制區(qū)間值，創(chuàng)建成功，測試通過。
文章來源地址http://www.zghlxwxcb.cn/news/detail-689374.html

到了這里，關(guān)于k8s進(jìn)階3——資源配額、資源限制的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！