資源模型

• 在 Kubernetes 里，Pod 是最小的原子調(diào)度單位。這也就意味著，所有跟調(diào)度和資源管理相關(guān)的屬性都應(yīng)該是屬于 Pod 對象的字段。而這其中最重要的部分，就是 Pod 的 CPU 和內(nèi)存配置，如下所示：

apiVersion: v1
kind: Pod
metadata:name: frontend
spec:containers:- name: dbimage: mysqlenv:- name: MYSQL_ROOT_PASSWORDvalue: "password"resources:requests:memory: "64Mi"cpu: "250m"limits:memory: "128Mi"cpu: "500m"- name: wpimage: wordpressresources:requests:memory: "64Mi"cpu: "250m"limits:memory: "128Mi"cpu: "500m"

• 在 Kubernetes 中，像 CPU 這樣的資源被稱作“可壓縮資源”（compressible resources）。它的典型特點是，當(dāng)可壓縮資源不足時，Pod 只會“饑餓”，但不會退出。而像內(nèi)存這樣的資源，則被稱作“不可壓縮資源（incompressible resources）。當(dāng)不可壓縮資源不足時，Pod 就會因為 OOM（Out-Of-Memory）被內(nèi)核殺掉。
• Pod 可以由多個 Container 組成，所以 CPU 和內(nèi)存資源的限額，是要配置在每個 Container 的定義上的。這樣，Pod 整體的資源配置，就由這些 Container 的配置值累加得到。
  • Kubernetes 里為 CPU 設(shè)置的單位是“CPU 的個數(shù)”。比如，cpu=1 指的就是，這個 Pod 的 CPU 限額是 1 個 CPU。當(dāng)然，具體“1 個 CPU”在宿主機上如何解釋，是 1 個 CPU 核心，還是 1 個 vCPU，還是 1 個 CPU 的超線程（Hyperthread），完全取決于宿主機的 CPU 實現(xiàn)方式。Kubernetes 只負責(zé)保證 Pod 能夠使用到“1 個 CPU”的計算能力。Kubernetes 允許你將 CPU 限額設(shè)置為分?jǐn)?shù)。當(dāng)然，你可以直接把這個配置寫成 cpu=0.5。但在實際使用時，推薦使用 500m 的寫法，畢竟這才是 Kubernetes 內(nèi)部通用的 CPU 表示方式。
  • Kubernetes 里對于內(nèi)存資源來說，它的單位自然就是 bytes。Kubernetes 支持使用 Ei、Pi、Ti、Gi、Mi、Ki（或者 E、P、T、G、M、K）的方式來作為 bytes 的值。比如，在上面的例子里，Memory requests 的值就是 64MiB (2 的 26 次方 bytes) 。這里要注意區(qū)分 MiB（mebibyte）和 MB（megabyte）的區(qū)別。備注：1Mi=1024*1024；1M=1000*1000
• Kubernetes 里 Pod 的 CPU 和內(nèi)存資源，實際上還要分為 limits 和 requests 兩種情況，如下所示：

spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory

• 兩者的區(qū)別：在調(diào)度的時候，kube-scheduler 只會按照 requests 的值進行計算。而在真正設(shè)置 Cgroups 限制的時候，kubelet 則會按照 limits 的值來進行設(shè)置。

QoS 模型

• Kubernetes 中，不同的 requests 和 limits 的設(shè)置方式，其實會將這個 Pod 劃分到不同的 QoS 級別當(dāng)中。
  • 當(dāng) Pod 里的每一個 Container 都同時設(shè)置了 requests 和 limits，并且 requests 和 limits 值相等的時候，這個 Pod 就屬于 Guaranteed 類別。
  • 當(dāng) Pod 不滿足 Guaranteed 的條件，但至少有一個 Container 設(shè)置了 requests。那么這個 Pod 就會被劃分到 Burstable 類別。
  • 當(dāng)一個 Pod 既沒有設(shè)置 requests，也沒有設(shè)置 limits，那么它的 QoS 類別就是 BestEffort。
• QoS 劃分的主要應(yīng)用場景，是當(dāng)宿主機資源緊張的時候，kubelet 對 Pod 進行 Eviction（即資源回收）時需要用到的。
• 當(dāng) Kubernetes 所管理的宿主機上不可壓縮資源短缺時，就有可能觸發(fā) Eviction。比如，可用內(nèi)存（memory.available）、可用的宿主機磁盤空間（nodefs.available），以及容器運行時鏡像存儲空間（imagefs.available）等等。
• Eviction 在 Kubernetes 里其實分為 Soft 和 Hard 兩種模式。
  • Soft Eviction 允許你為 Eviction 過程設(shè)置一段“優(yōu)雅時間”，比如 imagefs.available=2m，就意味著當(dāng) imagefs 不足的閾值達到 2 分鐘之后，kubelet 才會開始 Eviction 的過程。
  • Hard Eviction 模式下，Eviction 過程就會在閾值達到之后立刻開始。
• 當(dāng) Eviction 發(fā)生的時候，kubelet 具體會挑選哪些 Pod 進行刪除操作，就需要參考這些 Pod 的 QoS 類別了。
  • 首當(dāng)其沖的，自然是 BestEffort 類別的 Pod。
  • 其次，是屬于 Burstable 類別、并且發(fā)生“饑餓”的資源使用量已經(jīng)超出了 requests 的 Pod。
  • 最后，才是 Guaranteed 類別。并且，Kubernetes 會保證只有當(dāng) Guaranteed 類別的 Pod 的資源使用量超過了其 limits 的限制，或者宿主機本身正處于 Memory Pressure 狀態(tài)時，Guaranteed 的 Pod 才可能被選中進行 Eviction 操作。
• 當(dāng)然，對于同 QoS 類別的 Pod 來說，Kubernetes 還會根據(jù) Pod 的優(yōu)先級來進行進一步地排序和選擇。

cpuset 的設(shè)置

• 在使用容器的時候，可以通過設(shè)置 cpuset 把容器綁定到某個 CPU 的核上，而不是像 cpushare 那樣共享 CPU 的計算能力。這種情況下，由于操作系統(tǒng)在 CPU 之間進行上下文切換的次數(shù)大大減少，容器里應(yīng)用的性能會得到大幅提升。事實上，cpuset 方式，是生產(chǎn)環(huán)境里部署在線應(yīng)用類型的 Pod 時，非常常用的一種方式。
• 在 Kubernetes 里又該如何實現(xiàn)呢？首先，你的 Pod 必須是 Guaranteed 的 QoS 類型；然后，你只需要將 Pod 的 CPU 資源的 requests 和 limits 設(shè)置為同一個相等的整數(shù)值即可。這時候，該 Pod 就會被綁定在 獨占的 CPU 核上。當(dāng)然，具體是哪個 CPU 核，是由 kubelet 分配的。

在實際的使用中，強烈建議你將 DaemonSet 的 Pod 都設(shè)置為 Guaranteed 的 QoS 類型。否則，一旦 DaemonSet 的 Pod 被回收，它又會立即在原宿主機上被重建出來，這就使得前面資源回收的動作，完全沒有意義了。

GPU 管理

• 后續(xù)補充…

你知道的越多，你不知道的越多。