Kubernetes的的 Persistent Volumes

經過一番實驗，證明，這東西除了抽象，沒啥鳥用，直接掛 Volume 應該是目前最佳選擇。

持久卷 PersistentVolumes

本文描述了 Kubernetes 中的 PersistentVolumes。要求讀者有對卷 (volumes) 所有了解。

簡介

存儲管理跟計算管理是兩個不同的問題。PersistentVolume 子系統，對存儲的供應和使用做了抽象，以 API 形式提供給管理員和用戶使用。要完成這一任務，我們引入了兩個新的 API 資源：PersistentVolume（持久卷） 和 PersistentVolumeClaim（持久卷申請）。

PersistentVolume（PV）是集群之中的一塊網絡存儲。跟 Node 一樣，也是集群的資源。PV 跟 Volume (卷) 類似，不過會有獨立於 Pod 的生命周期。這一 API 對象包含了存儲的實現細節，例如 NFS、iSCSI 或者其他的雲提供商的存儲系統。

PersistentVolumeClaim (PVC) 是用戶的一個請求。他跟 Pod 類似。Pod 消費 Node 的資源，PVCs 消費 PV 的資源。Pod 能夠申請特定的資源（CPU 和 內存）；Claim 能夠請求特定的尺寸和訪問模式（例如可以加載一個讀寫，以及多個只讀實例）

PV 和 PVC 的生命周期

PV 是集群的資源。PVC 是對這一資源的請求，也是對資源的所有權的檢驗。PV 和 PVC 之間的互動遵循如下的生命周期。

供應

集群管理員會創建一系列的 PV。這些 PV 包含了為集群用戶提供的真實存儲資源。他們可利用 Kubernetes API 來消費。

綁定

用戶創建一個包含了容量和訪問模式的持久卷申請。Master 會監聽 PVC 的產生，並嘗試根據請求內容查找匹配的 PV，並把 PV 和 PVC 進行綁定。用戶能夠獲取滿足需要的資源，並且在使用過程中可能超出請求數量。

如果找不到合適的卷，這一申請就會持續處於非綁定狀態，一直到出現合適的 PV。例如一個集群准備了很多的 50G 大小的持久卷，（雖然總量足夠）也是無法響應 100G 的申請的，除非把 100G 的 PV 加入集群。

使用

Pod 把申請作為卷來使用。集群會通過 PVC 查找綁定的 PV，並 Mount 給 Pod。對於支持多種訪問方式的卷，用戶在使用 PVC 作為卷的時候，可以指定需要的訪問方式。

一旦用戶擁有了一個已經綁定的 PVC，被綁定的 PV 就歸該用戶所有了。用戶的 Pods 能夠通過在 Pod 的卷中包含的 PVC 來訪問他們占有的 PV。

釋放

當用戶完成對卷的使用時，就可以利用 API 刪除 PVC 對象了，而且他還可以重新申請。刪除 PVC 后，對應的卷被視為 “被釋放”，但是這時還不能給其他的 PVC 使用。之前的 PVC 數據還保存在卷中，要根據策略來進行后續處理。

回收

PV 的回收策略向集群闡述了在 PVC 釋放卷的時候，應如何進行后續工作。目前可以采用三種策略：保留，回收或者刪除。保留策略允許重新申請這一資源。在持久卷能夠支持的情況下，刪除策略會同時刪除持久卷以及 AWS EBS/GCE PD 或者 Cinder 卷中的存儲內容。如果插件能夠支持，回收策略會執行基礎的擦除操作（rm -rf /thevolume/*），這一卷就能被重新申請了。

持久卷的類型

持久卷是以插件方式實現的，目前支持如下插件：

• GCEPersistentDisk
• AWSElasticBlockStore
• NFS
• iSCSI
• RBD (Ceph Block Device)
• Glusterfs
• HostPath (單節點測試使用)

持久卷

每個 PV 包含一個 spec 以及 status ，用於描述該卷的規格和狀態。

  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: pv0003
  spec:
    capacity:
      storage: 5Gi
    accessModes:
      - ReadWriteOnce
    persistentVolumeReclaimPolicy: Recycle
    nfs:
      path: /tmp
      server: 172.17.0.2

Capacity（容量）

一般來說，PV 會指定存儲容量。這里需要使用 PV 的 capcity 屬性。參見 Kubernetes 的 Resource Model 一文，來獲取這一屬性的計量單位 (Mi/Gi....)。

目前存儲大小是唯一一個能夠被申請的指標，今后會加入更多屬性，例如 IOPS，吞吐能力等。

Access Modes（訪問模式）

只要資源提供者支持，持久卷能夠被用任何方式加載到主機上。每種存儲都會有不同的能力，每個 PV 的訪問模式也會被設置成為該卷所支持的特定模式。例如 NFS 能夠支持多個讀寫客戶端，但是某個 NFS PV 可能會在服務器上以只讀方式使用。每個 PV 都有自己的一系列的訪問模式，這些訪問模式取決於 PV 的能力。

訪問模式的可選范圍如下：

• ReadWriteOnce：該卷能夠以讀寫模式被加載到一個節點上。
• ReadOnlyMany：該卷能夠以只讀模式加載到多個節點上。
• ReadWriteMany：該卷能夠以讀寫模式被多個節點同時加載。

在 CLI 下，訪問模式縮寫為：

• RWO：ReadWriteOnce
• ROX：ReadOnlyMany
• RWX：ReadWriteMany

重要！一個卷不論支持多少種訪問模式，同時只能以一種訪問模式加載。例如一個 GCEPersistentDisk 既能支持 ReadWriteOnce ，也能支持 ReadOnlyMany。

Recycling Policy（回收策略）

當前的回收策略可選值包括：

• Retain - 人工重新申請
• Recycle - 基礎擦除（“rm -rf /thevolume/*”）
• Delete - 相關的存儲資產例如 AWS EBS，GCE PD 或者 OpenStack Cinder 卷一並刪除。

目前，只有 NFS 和 HostPath 支持 Recycle 策略，AWS EBS、GCE PD 以及 Cinder 卷支持 Delete 策略（其他的都是 Retain 是吧。。）。

階段（Phase）

一個卷會處於如下階段之一：

• Available：可用資源，尚未被綁定到 PVC 上
• Bound：該卷已經被綁定
• Released：PVC 已經被刪除，但該資源尚未被集群回收
• Failed：該卷的自動回收過程失敗。

CLI 會顯示綁定到該 PV 的 PVC。

PersistentVolumeClaims（持久卷申請）

每個 PVC 包含一個 spec 以及 status，用以表達其規格和狀態。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi

訪問模式

PVC 使用跟 PV 一致的訪問模式。

資源

PVC 跟 Pod 一樣可以請求特定數量的資源。在這里的請求內容就是存儲（storage）。Resource Model 文中提到的內容對 PV 和 PVC 同樣適用。

PVC 卷

Pod 能夠借助 PVC 來訪問存儲。PVC 必須跟 Pod 處於同一個命名空間。集群找到 Pod 命名空間中的 PVC，然后利用 PVC 獲取到背后的 PV。這個卷就會被加載到主機上，讓 Pod 可以使用。

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: dockerfile/nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim