Kubernetes 叢集資源的那些事

大多數時候，我們在跟 K8S 玩耍的時候，主要目的就是：“把 XXX 打個鏡像，在叢集上跑起來 ——— 诶快看，真的跑起來了嘿！”。

Kubernetes 和

Docker 的預設配置，就能夠幫我們省卻很多麻煩。不過大家都很清楚，資源問 題是無法回避的，我們在傳統 IT 環境下遇到的各種資源相關問題，在容器叢集環境下一樣要得到解決，多租戶動态配置設定環境下，這些問題會更加複雜。

本文僅是一個索引，不準備也沒能力做過多的深入，隻是将一些需要注意的内容羅列出來做一些大緻介紹。

有些内容稱作資源可能并不是很恰當，暫時存在資源這個筐裡吧。

磁盤

Volume

一般我們會用存儲卷的方式來給 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 總數。

和前面的磁盤的情況類似，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 進行授權之外的通路的途徑。

本文轉自中文社群-

Kubernetes 叢集資源的那些事