k8s管理存儲資源

 

 

 

1、Kubernetes 如何管理存儲資源：

理解volume

1） Kubernetes 如何經過 Volume 爲集羣中的容器提供存儲；

2）實踐幾種經常使用的 Volume 類型並理解它們各自的應用場景；

3） Kubernetes 如何經過 Persistent Volume 和 Persistent Volume Claim 分離集羣管理員與集羣用戶的職責，

4）實踐 Volume 的靜 態供給和動態供給。

 

 

Volume

本節咱們討論 Kubernetes 的存儲模型 Volume，學習如何將各類持久化存儲映射到容器。

 

咱們常常會說： 容器和 Pod 是短暫的。

 

其含義是它們的生命週期可能很短，會被頻繁地銷燬和建立。 容器銷燬時，保存在容器內部文件系統中的數據都會被清除。

 

爲了持久化保存容器的數據，可使用 Kubernetes Volume。

 

Volume 的生命週期獨立於容器，Pod 中的容器可能被銷燬和重建，但 Volume 會被保留。

 

本質上，Kubernetes Volume 是一個目錄，這一點與 Docker Volume 相似。 當 Volume 被 mount 到 Pod，Pod 中的全部容器均可以訪問這個 Volume。Kubernetes Volume 也支持多種 backend 類型，包括 emptyDir、hostPath、GCE Persistent Disk、AWS Elastic Block Store、NFS、Ceph 等。

 

Volume 提供了對各類 backend 的抽象，容器在使用 Volume 讀寫數據的時候不須要關心數據究竟是存放在本地節點的文件系統中呢仍是雲硬盤上。對它來講 ，全部類型的 Volume 都只是一個目錄。

 

 

2、kubernetes Volume種類：

emptyDir

emptyDir 是最基礎的 Volume 類型。正如其名字所示， 一個 emptyDir Volume 是 Host 上的一個空目錄。

 

emptyDir Volume 對於容器來講是持久的，對於 Pod 則不是。 當 Pod 從節點刪除時，Volume 的內容也會被刪除。但若是隻是容器被銷燬而 Pod 還在，則 Volume 不受影響。

 

也就是說：emptyDir Volume 的生命週期與 Pod 一致。 Pod 中的全部容器均可以共享 Volume，它們能夠指定各自的 mount 路徑。下面經過例子來實踐 emptyDir，配置文件以下：

 

 

這裏咱們模擬了一個 producer-consumer 場景。 Pod 有兩個容器 producer和 consumer，它們共享一個 Volume。producer 負責往 Volume 中寫數據，consumer 則是從 Volume 讀取數據。

 

 

① 文件最底部 volumes 定義了一個 emptyDir 類型的 Volume shared-volume。

② producer 容器將 shared-volume mount 到 /producer_dir 目錄。

③ producer 經過 echo 將數據寫到文件 hello 裏。

④ consumer 容器將 shared-volume mount 到 /consumer_dir 目錄。

⑤ consumer 經過 cat 從文件 hello 讀數據。

 

 

emptyDir 是 Host 上建立的臨時目錄，其 優勢是可以方便地爲 Pod 中的容器提供共享存儲，不須要額外的配置。但它不具有持久性，若是 Pod 不存在了，emptyDir 也就沒有了。根據這個特性，emptyDir 特別 適合 Pod 中的容器須要臨時共享存儲空間的場景，好比前面的生產者消費者用例。

 

 

hostPath Volume

hostPath Volume 的 做用是將 Docker Host 文件系統中已經存在的目錄 mount 給 Pod 的容器。大部分應用都不會使用 hostPath Volume，由於這 實際上增長了 Pod 與節點的耦合，限制了 Pod 的使用（缺點）。不過那些須要訪問 Kubernetes 或 Docker 內部數據（配置文件和二進制庫）的應用則須要使用 hostPath。

看下面是 Volume 的相關部分：

 

 

 

 

這裏定義了三個 hostPath volume k8s、certs 和 pki，分別對應 Host 目錄 /etc/kubernetes、/etc/ssl/certs 和 /etc/pki。

若是 Pod 被銷燬了，hostPath 對應的目錄也還會被保留，從這點看，hostPath 的持久性比 emptyDir 強。不過一旦 Host 崩潰，hostPath 也就無法訪問了。

 

 

 

外部 Storage Provider

若是 Kubernetes 部署在諸如 AWS、GCE、Azure 等公有云上，能夠直接使用雲硬盤做爲 Volume，下面是 AWS Elastic Block Store 的例子：

 

 

要在 Pod 中使用 ESB volume，必須先在 AWS 中建立，而後經過 volume-id 引用。其餘雲硬盤的使用方法可參考各公有云廠商的官方文檔。

Kubernetes Volume 也可使用主流的分佈式存，好比 Ceph、GlusterFS 等，下面是 Ceph 的例子：

 

 

 

 

Ceph 文件系統的 /some/path/in/side/cephfs 目錄被 mount 到容器路徑 /test-ceph。

 

相對於 emptyDir 和 hostPath，這些 Volume 類型的最大特色就是不依賴 Kubernetes。Volume 的底層基礎設施由 獨立的存儲系統管理，與 Kubernetes 集羣是分離

 

的。數據被持久化後，即便整個 Kubernetes 崩潰也不會受損。

 

固然，運維這樣的存儲系統一般不是項簡單的工做，特別是對可靠性、高可用和擴展性有較高要求時。

 

Volume 提供了很是好的數據持久化方案，不過在可管理性上還有不足。

 

PV & PVC

Volume 提供了很是好的數據持久化方案，不過在可管理性上還有不足。

拿前面 AWS EBS 的例子來講，要使用 Volume，Pod 必須事先知道以下信息：

1. 當前 Volume 來自 AWS EBS。
2. EBS Volume 已經 提早建立，而且知道 確切的 volume-id。

Pod 一般是由應用的開發人員維護，而 Volume 則一般是由存儲系統的管理員維護。開發人員要得到上面的信息：

1. 要麼詢問管理員。
2. 要麼本身就是管理員。

這樣就帶來一個管理上的問題：應用開發人員和系統管理員的職責耦合在一塊兒了。若是系統規模較小或者對於開發環境這樣的狀況還能夠接受。但當集羣規模變大，特別是對於生成環境，考慮到效率和安全性，這就成了必需要解決的問題。

 

Kubernetes 給出的解決方案是 PersistentVolume 和 PersistentVolumeClaim。

 

PersistentVolume (PV) 是外部存儲系統中的一塊存儲空間，由管理員建立和維護。與 Volume 同樣， PV 具備持久性，生命週期獨立於 Pod。

 

PersistentVolumeClaim (PVC) 是對 PV 的申請 (Claim)。 PVC 一般由普通用戶建立和維護。須要爲 Pod 分配存儲資源時， 用戶能夠建立一個 PVC，指明存儲資源的容

 

量大小和訪問模式（好比只讀）等信息，Kubernetes 會查找並提供知足條件的 PV。

 

有了 PersistentVolumeClaim，用戶只須要告訴 Kubernetes 須要什麼樣的存儲資源，而沒必要關心真正的空間從哪裏分配，如何訪問等底層細節信息。這些 Storage

 

 

Provider 的底層信息交給管理員來處理，只有管理員才應該關心建立 PersistentVolume 的細節信息。