所屬技術領域：
Kubernetes
|名詞定義|
Requests是容器請求要使用的資源，Kubernetes 會保證 Pod 能使用到這麼多的資源。請求的資源是排程的依據，隻有當節點上的可用資源大于 Pod 請求的各種資源時，排程器才會把 Pod 排程到該節點上（如果 CPU 資源足夠，記憶體資源不足，排程器也不會選擇該節點）。
需要注意的是，排程器隻關心節點上可配置設定的資源，以及節點上所有 Pods 請求的資源，而不關心節點資源的實際使用情況，換句話說，如果節點上的 Pods 申請的資源已經把節點上的資源用滿，即使它們的使用率非常低，比如說 CPU 和記憶體使用率都低于 10%，排程器也不會繼續排程 Pod 上去。
|技術特點|
通過 request 和 limit 的組合來确定我們想要的 QoS level。
- Guaranteed Pod
Kubernetes必備知識： Kubernetes資源模型requests
Kubernetes 裡面有一個要求：如果你要建立出一個 Guaranteed Pod，那麼你的基礎資源（包括 CPU 和 memory），必須它的 request==limit，其他的資源可以不相等。隻有在這種條件下，它建立出來的 pod 才是一種 Guaranteed Pod，否則它會屬于 Burstable，或者是 BestEffort Pod。
- Burstable Pod
Kubernetes必備知識： Kubernetes資源模型requests
比如說上面的例子，可以不用填寫 memory 的資源，隻要填寫 CPU 的資源，它就是一種 Burstable Pod。
- BestEffort Pod
Kubernetes必備知識： Kubernetes資源模型requests
第三類 BestEffort Pod，它也是條件比較死的一種使用方式。它必須是所有資源的 request/limit 都不填，才是一種 BestEffort Pod。
不同的 QoS 表現
接下來，為大家介紹一下：不同的 QoS 在排程和底層表現有什麼樣的不同？不同的 QoS，它其實在排程和底層表現上都有一些不一樣。比如說排程表現，排程器隻會使用 request 進行排程，也就是說不管你配了多大的 limit，它都不會進行排程使用。
在底層上，不同的 Qos 表現更不相同。比如說 CPU，它是按 request 來劃分權重的，不同的 QoS，它的 request 是完全不一樣的，比如說像 Burstable 和 BestEffort，它可能 request 可以填很小的數字或者不填，這樣的話，它的時間片權重其實是非常低的。像 BestEffort，它的權重可能隻有 2，而 Burstable 或 Guaranteed，它的權重可以多到幾千。
requests的特點
1.requests用于schedule階段，在排程pod保證所有pod的requests總和小于node能提供的計算能力
2.requests.cpu被轉成docker的--cpu-shares參數，與cgroup cpu.shares功能相同
設定容器的cpu的相對權重
該參數在CPU資源不足時生效，根據容器requests.cpu的比例來配置設定cpu資源
CPU資源充足時，requests.cpu不會限制container占用的最大值，container可以獨占CPU
3.requests.memory沒有對應的docker參數，作為k8s排程依據
4.使用requests來設定各容器需要的最小資源
關于Requests的底層實作機制：
|資料來源|
名詞定義：
https://blog.51cto.com/dangzhiqiang/2298673技術特點：
https://blog.csdn.net/zhonglinzhang/article/details/80663249 https://blog.csdn.net/qq180782842/article/details/87719739