Kubernetes 中 QoS Burstable pod 的資源分配

Question

如果limit資源大於request資源，K8 會將 pod 分配給QoS Burstable

示例配置：

apiVersion: v1
kind: Pod
metadata:
  name: test-metadata
  namespace: demo
spec:
  containers:
  - name: test1
    image: nginx
    resources:
      limits:
        memory: "14Gi"
      requests:
        memory: "4Gi"

• Kubernetes 是否總是將這個 pod 分配到一個具有 14GB 內存的實例上？
• Kubernetes 會一直為這個 pod 預留 14 GB 的內存嗎？ 如果是，那么它與QoS Guaranteed類有何不同？

我不想使用QoS Guaranteed因為工作負載可能會有所不同。

Answer 1

默認情況下，Kubernetes 在嘗試調度 Pod 時僅考慮資源請求。 這意味着您的 Pod 只會被調度到某個節點，該節點至少具有 Pod 請求的可用資源。

更准確地說，pod 將被調度到節點之一，這樣所有 pod（包括它試圖調度的 pod）請求的資源總和不會超過節點可分配的資源。 這里的操作詞是可分配資源。

可分配資源是指那些超出操作系統 Pod 所需資源的可用資源。 為系統進程保留了多少硬件資源是 Kubernetes 的可配置屬性，在他們的節點可分配資源文檔中有更好的描述

Answer 2

調度 Pod 時不考慮內存限制。

Kubernetes 是否總是將這個 pod 分配到一個具有 14GB 內存的實例上？

默認情況下，這個 pod 將分配給任何滿足 4GB 內存請求的節點。

在節點方面，當節點耗盡資源時，任何使用超過其請求資源的 pod 都會被驅逐。 換句話說，Kubernetes 從不提供任何超出 Pod 請求的資源可用性保證。

使用超過節點總內存的內存限制將永遠不會達到。

Kubernetes 會一直為這個 pod 預留 14 GB 的內存嗎？ 如果是，那么它與 QoS 保證類有何不同？

不，默認情況下 kubernetes 將保留所需的最少內存量，即 4GB 作為請求。

調度程序還考慮了調度程序配置和調度程序策略：

調度程序配置允許通過編寫配置文件並將其路徑作為命令行參數傳遞來自定義kube-scheduler的行為。

調度策略可用於指定kube-scheduler運行以分別過濾和評分節點的謂詞和優先級。