Kubernetes 叢集資源的那些事_Kubernetes中文社群
大多數時候，我們在跟 K8S 玩耍的時候，主要目的就是：“把 XXX 打個映象，在叢集上跑起來 ——— 誒快看，真的跑起來了嘿！”。
Kubernetes 和 Docker 的預設配置，就能夠幫我們省卻很多麻煩。不過大家都很清楚，資源問題是無法迴避的，我們在傳統 IT 環境下遇到的各種資源相關問題，在容器叢集環境下一樣要得到解決，多租戶動態分配環境下，這些問題會更加複雜。
本文僅是一個索引，不準備也沒能力做過多的深入，只是將一些需要注意的內容羅列出來做一些大致介紹。
有些內容稱作資源可能並不是很恰當，暫時存在資源這個筐裡吧。
磁碟
一般我們會用儲存卷的方式來給 Pod 提供儲存資源。
起初的儲存卷，在用量的控制方面，只能借儲存的實際提供者的能力來進行。例如可以限制 GlusterFS 中 Volume 的大小。
接下來出現了 Persistent Volume (PV) 和 Persistent Volume Claim (PVC) 這一組物件，完成了 “生產——消費” 關係，這就可以通過 Provision -> Claim 的方式，來對儲存資源進行控制。
而最新版本中還出現了動態卷供給的功能，能夠對這一部分功能進行簡化，無需首先建立 PV，直接建立 PVC 即可。
有了 PVC 這一能力之後，Kubernetes 就借用這一物件對 Namespace 的儲存訪問進行了限制：
| 物件名稱 | 解釋 |
|---|---|
| requests.storage | 所有的 PVC 申請容量之和不能超過此數值 |
| persistentvolumeclaims | 一個 Namespace 中 PVC 的總數（Count） |
<storage-class-name>.storageclass.storage.k8s.io/requests.storage |
所有針對該 StorageClass 的 PVC 所申請的儲存總容量不得超出這一數值 |
<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims |
所有針對該 StorageClass 最多能建立的 PVC 數量 |
日誌
目前我們在實際使用中，爆磁碟的原因，除了對儲存卷的控制不夠之外，還有一個重要的點就是容器的日誌，預設情況下 Docker 使用的日誌驅動是 json-file，這一驅動有個附加引數 --log-opt max-size=[size] 可以用來限制日誌的最大佔用空間。
https://docs.docker.com/engine/admin/logging/overview/ 還提供了很多其他的日誌選項供選擇
Node
除了上面講到的叢集層面的問題之外，磁碟空間還對 Node(Kubelet) 的健康有重大影響。Kubelet 有幾個引數用於對儲存使用進行控制：
--low-diskspace-threshold-mb：如果剩餘空間低於這一限制，則拒絕在這一 Node 上新建 Pod（目前建議用新的驅逐規則來代替這一引數）。--image-gc-high-threshold：高於該值則啟動 GC。--image-gc-low-threshold：低於該值拒絕啟動 GC。
在驅逐策略中，提供瞭如下幾個磁碟相關的引數：
- nodefs.available
- nodefs.inodesFree
- imagefs.available
- imagefs.inodesFree
這裡把 Node 磁碟分為 node 和 image 兩種分別度量其 available 和 inodes，應該說比上面的 threshold 更加精確了
CPU 和記憶體
這一對資源應該算是 Kubernetes 中的 “經典” 資源了。Kubernetes 對 CPU 和記憶體提供了 requests/limits 兩種度量，可以在 Container 的 Spec 中進行指定。
在 namespace 一級中，提供瞭如下的總量限制：
- limits.cpu：所有非結束狀態的 Pod 的 CPU limit 總數。
- limits.memory：所有非結束狀態的 Pod 的 記憶體 limit 總數。
- requests.cpu：所有非結束狀態的 Pod 的 CPU request 總數。
- requests.memory：所有非結束狀態的 Pod 的 CPU request 總數。
Node
和前面的磁碟的情況類似，Kubelet 中對 CPU 和記憶體也有新舊兩套切換中的體系來進行限制：
--kube-reserved
驅逐策略中提供瞭如下引數：
- memory.available
quota 和 limitrange
這是兩個不同的 API Object，分別對應 namespace 的配額，和執行應用(Pod/Container)的資源限制。
GPU
這方面基本沒有接觸，但是隨著深度學習之類名詞的迅速炒熱，相信 Kubernetes 會快速跟進的。
將在 1.6 中推出多 GPU 支援的 Alpha 版本。
網路
在 K8S1.5版本 中，網路策略已經成為 Beta 版本，利用這一物件，橫向可以實現 namespace 之間的隔離；縱向可以定義 namespace 內不同職責應用的網路訪問能力。這就有效的阻斷了不同租戶之間利用 dns 進行授權之外的訪問的途徑。
參考資料：
- 網路策略：https://kubernetes.io/docs/user-guide/networkpolicies/
- 驅逐策略：http://blog.fleeto.us/translation/configuring-out-resource-handling
- 儲存：
- http://blog.fleeto.us/translation/dynamic-provisioning-and-storage-classes-kubernetes
- http://blog.fleeto.us/translation/persistent-volumes