摘要：本地數據卷管理。本地數據卷的管理是一個比較復雜的工程，需要支持文件系統和塊存儲。在中，本地數據卷管理暫時不會處理該問題會設計一個外部控制器來定期查詢該錯誤狀態，并根據一定的策略重新調度。本地數據卷的創建由新的組件處理，該組件將以的方式部署。

?
本期文章來自才云科技（Caicloud）CTO 鄧德源的技術原創。

1
Overview

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

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

本地數據卷管理。本地數據卷管理的主要內容是將非主分區的其他分區全部作為本地持久化數據卷供 Kubernetes 調度使用，遵循 Kubernetes 的 PV/PVC 模型。

2
Local Volume API

在本文中，我們集中介紹本地數據卷管理，一起思考如何設計本地持久化數據卷，后續再介紹 Kubernetes 準備如何進行容量管理。

首先，在設計之初，我們需要思考本地數據卷的場景和用例，社區認為的兩個主要應用場景是分布式文件系統和數據庫，因為兩者都需要高性能和可靠性，比如在云的環境里，本地 SSD 比掛載的數據盤性能高出許多；另外，本地磁盤在多數情況下成本更低，適合數據量大的場景。

了解場景之后，開始進入 API 設計階段。本地數據卷的管理是一個比較復雜的工程，需要支持文件系統和塊存儲。不同的文件系統具有不同的特性（比如 xfs 支持 quota，而目前 ext4 并不支持 quota），掛載選項也大相徑庭。

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

有了上述定義，我們可以創建相對應的 Persistent Volume：

這里有幾個注意事項：

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

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

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

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

這里最大的問題在于，我們將 PV 的拓撲結構限定在節點層面，但是“本地”的含義并不是說存儲一定是分配在某臺機器上，我們可以說：這個存儲是屬于該 rack 的本地存儲。那么對于 rack 內的機器而言，該存儲就是他們的本地存儲。鑒于此，local volume 的 API 需要設計得更加通用：

上述 Yaml 與最開始介紹的配置表達的相同的內容，但是提供了更加靈活的表達方式，同時也復用了 Kubernetes 中已經存在的 node affinity 的概念。

3
Local Volume Scheduling

Kubernetes PV/PVC 在設計時，忽略了與調度器的交互部分，導致 PV/PVC 的綁定與 Pod 調度毫無關系。在 “remote volume“ 的情況下問題并不大，因為 Pod 被調度后，可以動態掛載數據卷，但是在本地數據卷的情況下，問題已經凸顯出來。當用戶創建 PV 和 PVC 之后，由于本地數據卷的特性，任何要求某個特定 PVC 的 Pod 實際上已經被調度了。

例如，管理員創建一個名為 super-pv 的數據卷，該數據卷存在于節點 Kube-node-1 上；當用戶創建一個名為 claim-it 的 PVC 并被 Kubernetes 綁定在 super-pv 上之后，任何使用 PVC 的 Pod 實際上已經被調度到了 Kube-node-1 上。

假設此時，Kube-node-1 的資源無法滿足 Pod 的需求（例如 CPU 足夠），那么 Pod 會一直處于 Pending 狀態，即使另外一臺機器 Kube-node-2 有足夠的資源，也有滿足需求的本地數據卷。

在 Kubernetes 1.7 中，本地數據卷管理暫時不會處理該問題（會設計一個外部控制器來定期查詢該錯誤狀態，并根據一定的策略重新調度）。后續的解決方案暫無定論，其中一個可行的方案是將綁定邏輯放在調度器中：

PV/PVC 的綁定被延遲到調度時刻，即當真有 Pod 使用某個 PVC 時再進行綁定
調度器通過 PVC.storageclass 找到可以使用的 PV，并拿到每個 PV 的 affinity
調度器綜合考慮 Pod 的調度需求和 PV 的 affinity 進行調度
如果沒有滿足需求的 Node，調度器通過和 PV provisioner 交互，動態創建 PV

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

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

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

4
Local Volume Static Provisioner

本地數據卷的創建由新的 Kubernetes 組件處理（local volume provisioner addon），該組件將以 DaemonSet 的方式部署。

Provisioner 有兩個核心組件：

Discovery: discovery 組件的功能是接收用戶配置的信息，然后創建 PV。例如，當用戶將 “/var/lib/kubelet/localstorages” 作為本地數據卷的目錄后，provisioner 會為該目錄下的每一個目錄創建一個新的 PV，并添加正確的拓撲信息。

Deleter: deleter 負責處理 PV 狀態改變。當 deleter 發現其管理的 PV 進入了 Released 狀態，deleter 會清理數據并將 PV 從 Kubernetes API 中刪除。此時，Discovery 發現 PV 被刪除，會重新創建新的 PV，從而達到回收的效果。

Provisioner 后續還可以完成各種錯誤匯報，容量檢查等功能，在 kubernetes 1.7 中會提供 alpha 版本。

5
Future

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

相關閱讀：
https://github.com/kubernetes...

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