原文地址：http://www.cnblogs.com/leidaxia/p/6485646.html

持久卷 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