一、基礎(chǔ)了解

1.1 資源說明

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

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

資源配額管理維度解釋？

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

資源配額參數(shù)有什么？

程序所使用的CPU與Memory是一個動態(tài)的量，跟負(fù)載密切相關(guān)，當(dāng)負(fù)載增加時，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 資源計算

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

• 計算CPU

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

• 計算Memory

內(nèi)存的Requests和Limits計量單位是字節(jié)數(shù)。使用整數(shù)或者定點整數(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=8000Bits； 1 KiB=2^10 Bytes=1024 Bytes=8192 Bits。

• 注意事項

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

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

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

調(diào)度器在調(diào)度時，首先要確保調(diào)度后該節(jié)點上所有Pod的CPU和內(nèi)存的Requests總和，不超過該節(jié)點能提供給Pod使用的CPU和Memory的最大容量值。

例如，某個節(jié)點上的CPU資源充足，而內(nèi)存為4GB，其中3GB可以運(yùn)行Pod，而某Pod的Memory Requests為1GB、Limits為2GB，那么在這個節(jié)點上最多可以運(yùn)行3個這樣的Pod。

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

>> kubelet在啟動Pod的某個容器時，會將容器的Requests和Limits值轉(zhuǎn)化為相應(yīng)的容器啟動參數(shù)傳遞給容器執(zhí)行器（Docker或者rkt）。

>> 若容器的執(zhí)行環(huán)境是Docker，那么容器的4個參數(shù)傳遞給Docker的過程如下：
	1. spec.container[].resources.requests.cpu：參數(shù)值會被轉(zhuǎn)化為core數(shù)（比如配置的100m會轉(zhuǎn)化為0.1），然后乘以1024，再將這個結(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，錯誤信息為FailedScheduling。若調(diào)度器在集群中找不到合適的節(jié)點來運(yùn)行Pod，那么這個Pod會一直處于未調(diào)度狀態(tài)，直到調(diào)度器找到合適的節(jié)點為止。每次調(diào)度器嘗試調(diào)度失敗時，Kubernetes都會產(chǎn)生一個事件。
2. 容器被強(qiáng)行終止（Terminated）。如果容器使用的資源超過了它配置的Limits，那么該容器可能被強(qiáng)制終止。我們可以通過kubectl describe pod命令來確認(rèn)容器是否因為這個原因被終止

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

• Pod的三種QoS級別：

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

• 工作特點：

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

二、資源配額 ResourceQuota

為何會有資源配額？

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

• 使用流程

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

• 注意事項

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

2.1 支持的限制資源

• 資源限制對象

容器資源請求值（requests）：命名空間下的所有pod申請資源時設(shè)置的requests總和不能超過這個值。
容器資源限制值（limits）：命名空間下的所有pod申請資源時設(shè)置的limits總和不能超過這個值。文章來源地址http://www.zghlxwxcb.cn/news/detail-546160.html

• 注意事項

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

到了這里，關(guān)于k8s資源配額限制的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！