摘要：本地?cái)?shù)據(jù)卷管理。本地?cái)?shù)據(jù)卷的管理是一個(gè)比較復(fù)雜的工程，需要支持文件系統(tǒng)和塊存儲。在中，本地?cái)?shù)據(jù)卷管理暫時(shí)不會處理該問題會設(shè)計(jì)一個(gè)外部控制器來定期查詢該錯(cuò)誤狀態(tài)，并根據(jù)一定的策略重新調(diào)度。本地?cái)?shù)據(jù)卷的創(chuàng)建由新的組件處理，該組件將以的方式部署。

?
本期文章來自才云科技（Caicloud）CTO 鄧德源的技術(shù)原創(chuàng)。

1
Overview

Kubernetes 1.7 不會引入過多新功能，比較重要的幾個(gè)特性包括 Priority API、CRI 的增強(qiáng)以及 Federation 的部分功能。此外，計(jì)劃中還將提供本地存儲管理，主要分為兩個(gè)層面：

本地系統(tǒng)容量的管理。Kubernetes 的主分區(qū)主要包含 Kubelet 的根目錄（/var/lib/kubelet），/var/log 目錄等。此外，容器鏡像，容器讀寫層，容器日志，Kubernetes 空數(shù)據(jù)卷（emptyDir）等都需要消耗該空間（默認(rèn)情況下）。在 Kubernetes 1.7 中，社區(qū)將嘗試把此類資源集中管理起來，并作為調(diào)度資源。

本地?cái)?shù)據(jù)卷管理。本地?cái)?shù)據(jù)卷管理的主要內(nèi)容是將非主分區(qū)的其他分區(qū)全部作為本地持久化數(shù)據(jù)卷供 Kubernetes 調(diào)度使用，遵循 Kubernetes 的 PV/PVC 模型。

2
Local Volume API

在本文中，我們集中介紹本地?cái)?shù)據(jù)卷管理，一起思考如何設(shè)計(jì)本地持久化數(shù)據(jù)卷，后續(xù)再介紹 Kubernetes 準(zhǔn)備如何進(jìn)行容量管理。

首先，在設(shè)計(jì)之初，我們需要思考本地?cái)?shù)據(jù)卷的場景和用例，社區(qū)認(rèn)為的兩個(gè)主要應(yīng)用場景是分布式文件系統(tǒng)和數(shù)據(jù)庫，因?yàn)閮烧叨夹枰咝阅芎涂煽啃裕热缭谠频沫h(huán)境里，本地 SSD 比掛載的數(shù)據(jù)盤性能高出許多；另外，本地磁盤在多數(shù)情況下成本更低，適合數(shù)據(jù)量大的場景。

了解場景之后，開始進(jìn)入 API 設(shè)計(jì)階段。本地?cái)?shù)據(jù)卷的管理是一個(gè)比較復(fù)雜的工程，需要支持文件系統(tǒng)和塊存儲。不同的文件系統(tǒng)具有不同的特性（比如 xfs 支持 quota，而目前 ext4 并不支持 quota），掛載選項(xiàng)也大相徑庭。

并且，本地存儲卷是目前為止唯一一個(gè)涉及到同時(shí)支持文件系統(tǒng)和塊存儲的插件方案（ceph 可以算一個(gè)，但是 cephfs 和 RBD 目前是兩個(gè)插件）。為了兼容各種可能的情況，經(jīng)過長時(shí)間討論，目前 API 已經(jīng)基本定型：

有了上述定義，我們可以創(chuàng)建相對應(yīng)的 Persistent Volume：

這里有幾個(gè)注意事項(xiàng)：

spec.local.path 可以是任意的路徑，但是 Kubernetes 推薦把一塊磁盤或者分區(qū)掛載到該分區(qū)。使用一塊磁盤除了可以做到容量隔離之外，還可以做到性能隔離；如果性能隔離對應(yīng)用場景不重要，那么可以把磁盤劃分為多個(gè)分區(qū)，因此可以創(chuàng)建多個(gè) PV。Kubernetes 的這種方式將控制權(quán)全部交給了用戶，用戶可以更加靈活的配置系統(tǒng)。

spec.local.path 目前只能是路徑，后續(xù) Kubernetes 會支持塊設(shè)備，這樣一來 spec.local.path 會被重用，即當(dāng) PV 是一個(gè)掛載點(diǎn)時(shí)，path 是一個(gè)路徑；當(dāng) PV 是一個(gè)塊設(shè)備時(shí)，path 代表設(shè)備路徑。另一種方案是采用更深層次的鍵值，例如 spec.local.fs.path, spec.local.block.path，這樣的好處是可以支持多重屬性，比如 spec.local.fs.fsType，但是社區(qū)目前并沒有這么去做，主要原因是考慮適配 CSI (container storage interface)。

spec.capacity 目前是 informational。如果我們采用的是磁盤或者分區(qū)的方式，那么該值是磁盤或分區(qū)的大小，也就做到了容量隔離。但如果我們采用的是任意的目錄，目前 Kubernetes 并不會限制該目錄可以使用的大小。

上述 API 僅僅定義了 local PV 的 path 屬性，但是不同于其他存儲插件，local PV 的一大特點(diǎn)就是它一定會與本地所綁定，因此，我們需要給 PV 再加一個(gè)屬性，告知系統(tǒng) PV 屬于哪個(gè)節(jié)點(diǎn)。我們可以簡簡單單地在 PV 內(nèi)加上 NodeName 的屬性，如下所示：

這里最大的問題在于，我們將 PV 的拓?fù)浣Y(jié)構(gòu)限定在節(jié)點(diǎn)層面，但是“本地”的含義并不是說存儲一定是分配在某臺機(jī)器上，我們可以說：這個(gè)存儲是屬于該 rack 的本地存儲。那么對于 rack 內(nèi)的機(jī)器而言，該存儲就是他們的本地存儲。鑒于此，local volume 的 API 需要設(shè)計(jì)得更加通用：

上述 Yaml 與最開始介紹的配置表達(dá)的相同的內(nèi)容，但是提供了更加靈活的表達(dá)方式，同時(shí)也復(fù)用了 Kubernetes 中已經(jīng)存在的 node affinity 的概念。

3
Local Volume Scheduling

Kubernetes PV/PVC 在設(shè)計(jì)時(shí)，忽略了與調(diào)度器的交互部分，導(dǎo)致 PV/PVC 的綁定與 Pod 調(diào)度毫無關(guān)系。在 “remote volume“ 的情況下問題并不大，因?yàn)?Pod 被調(diào)度后，可以動態(tài)掛載數(shù)據(jù)卷，但是在本地?cái)?shù)據(jù)卷的情況下，問題已經(jīng)凸顯出來。當(dāng)用戶創(chuàng)建 PV 和 PVC 之后，由于本地?cái)?shù)據(jù)卷的特性，任何要求某個(gè)特定 PVC 的 Pod 實(shí)際上已經(jīng)被調(diào)度了。

例如，管理員創(chuàng)建一個(gè)名為 super-pv 的數(shù)據(jù)卷，該數(shù)據(jù)卷存在于節(jié)點(diǎn) Kube-node-1 上；當(dāng)用戶創(chuàng)建一個(gè)名為 claim-it 的 PVC 并被 Kubernetes 綁定在 super-pv 上之后，任何使用 PVC 的 Pod 實(shí)際上已經(jīng)被調(diào)度到了 Kube-node-1 上。

假設(shè)此時(shí)，Kube-node-1 的資源無法滿足 Pod 的需求（例如 CPU 足夠），那么 Pod 會一直處于 Pending 狀態(tài)，即使另外一臺機(jī)器 Kube-node-2 有足夠的資源，也有滿足需求的本地?cái)?shù)據(jù)卷。

在 Kubernetes 1.7 中，本地?cái)?shù)據(jù)卷管理暫時(shí)不會處理該問題（會設(shè)計(jì)一個(gè)外部控制器來定期查詢該錯(cuò)誤狀態(tài)，并根據(jù)一定的策略重新調(diào)度）。后續(xù)的解決方案暫無定論，其中一個(gè)可行的方案是將綁定邏輯放在調(diào)度器中：

PV/PVC 的綁定被延遲到調(diào)度時(shí)刻，即當(dāng)真有 Pod 使用某個(gè) PVC 時(shí)再進(jìn)行綁定
調(diào)度器通過 PVC.storageclass 找到可以使用的 PV，并拿到每個(gè) PV 的 affinity
調(diào)度器綜合考慮 Pod 的調(diào)度需求和 PV 的 affinity 進(jìn)行調(diào)度
如果沒有滿足需求的 Node，調(diào)度器通過和 PV provisioner 交互，動態(tài)創(chuàng)建 PV

如果我們從整體的設(shè)計(jì)上來看，該問題并非只會出現(xiàn)在本地存儲上，任何需要調(diào)度器和 PV/PVC 綁定控制器交互的地方都會有問題。

例如，在多 zone 的情況下，PV/PVC 控制器并不會考慮一個(gè) PV 需要?jiǎng)?chuàng)建在哪個(gè) zone 里面；因此，很有可能控制器選擇了一個(gè) zone，但是該 zone 并不滿足 Pod 的需求（例如 affinity 需求，或者所有節(jié)點(diǎn)資源都不夠）。

由于一個(gè) zone 可能包含多個(gè)機(jī)器，因此問題被縮小，但仍然存在。如果我們仔細(xì)思考可以看出，實(shí)際上 node 就是一個(gè) ”tiny zone“，問題的本質(zhì)實(shí)際上是一樣的。

4
Local Volume Static Provisioner

本地?cái)?shù)據(jù)卷的創(chuàng)建由新的 Kubernetes 組件處理（local volume provisioner addon），該組件將以 DaemonSet 的方式部署。

Provisioner 有兩個(gè)核心組件：

Discovery: discovery 組件的功能是接收用戶配置的信息，然后創(chuàng)建 PV。例如，當(dāng)用戶將 “/var/lib/kubelet/localstorages” 作為本地?cái)?shù)據(jù)卷的目錄后，provisioner 會為該目錄下的每一個(gè)目錄創(chuàng)建一個(gè)新的 PV，并添加正確的拓?fù)湫畔ⅰ?/p>

Deleter: deleter 負(fù)責(zé)處理 PV 狀態(tài)改變。當(dāng) deleter 發(fā)現(xiàn)其管理的 PV 進(jìn)入了 Released 狀態(tài)，deleter 會清理數(shù)據(jù)并將 PV 從 Kubernetes API 中刪除。此時(shí)，Discovery 發(fā)現(xiàn) PV 被刪除，會重新創(chuàng)建新的 PV，從而達(dá)到回收的效果。

Provisioner 后續(xù)還可以完成各種錯(cuò)誤匯報(bào)，容量檢查等功能，在 kubernetes 1.7 中會提供 alpha 版本。

5
Future

盡管 Kubernetes 1.7 中本地存儲卷只能說處于基本可以試一試的狀態(tài)，社區(qū)后續(xù)會為這個(gè)功能投入大量精力，具體實(shí)現(xiàn)內(nèi)容已經(jīng)涉及到 1.8、1.9 版，包括 dynamic provisioner, fsGroup support, SELinux support, taints/toleration, local PV monitoring, block storage support 等，相信后續(xù)會有更多進(jìn)展。

相關(guān)閱讀：
https://github.com/kubernetes...

https://github.com/kubernetes...