Persistent Volume（持久化卷） · kubernetes完整攻略

# Persistent Volume（持久化卷）本文檔介紹了 Kubernetes 中 `PersistentVolume` 的當前狀態。建議您在閱讀本文檔前先熟悉 [volume](https://kubernetes.io/docs/concepts/storage/volumes/)。 ## 介紹對于管理計算資源來說，管理存儲資源明顯是另一個問題。`PersistentVolume` 子系統為用戶和管理員提供了一個 API，該 API 將如何提供存儲的細節抽象了出來。為此，我們引入兩個新的 API 資源：`PersistentVolume` 和 `PersistentVolumeClaim`。 `PersistentVolume`（PV）是由管理員設置的存儲，它是群集的一部分。就像節點是集群中的資源一樣，PV 也是集群中的資源。 PV 是 Volume 之類的卷插件，但具有獨立于使用 PV 的 Pod 的生命周期。此 API 對象包含存儲實現的細節，即 NFS、iSCSI 或特定于云供應商的存儲系統。 `PersistentVolumeClaim`（PVC）是用戶存儲的請求。它與 Pod 相似。Pod 消耗節點資源，PVC 消耗 PV 資源。Pod 可以請求特定級別的資源（CPU 和內存）。聲明可以請求特定的大小和訪問模式（例如，可以以讀/寫一次或只讀多次模式掛載）。雖然 `PersistentVolumeClaims` 允許用戶使用抽象存儲資源，但用戶需要具有不同性質（例如性能）的 `PersistentVolume` 來解決不同的問題。集群管理員需要能夠提供各種各樣的 `PersistentVolume`，這些`PersistentVolume` 的大小和訪問模式可以各有不同，但不需要向用戶公開實現這些卷的細節。對于這些需求，`StorageClass` 資源可以實現。請參閱[工作示例的詳細過程](https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)。 ## 卷和聲明的生命周期 PV 屬于集群中的資源。PVC 是對這些資源的請求，也作為對資源的請求的檢查。 PV 和 PVC 之間的相互作用遵循這樣的生命周期： ### 配置（Provision）有兩種方式來配置 PV：靜態或動態。 #### 靜態集群管理員創建一些 PV。它們帶有可供群集用戶使用的實際存儲的細節。它們存在于 Kubernetes API 中，可用于消費。 #### 動態當管理員創建的靜態 PV 都不匹配用戶的 `PersistentVolumeClaim` 時，集群可能會嘗試動態地為 PVC 創建卷。此配置基于 `StorageClasses`：PVC 必須請求[存儲類](https://kubernetes.io/docs/concepts/storage/storage-classes/)，并且管理員必須創建并配置該類才能進行動態創建。聲明該類為 `""` 可以有效地禁用其動態配置。要啟用基于存儲級別的動態存儲配置，集群管理員需要啟用 API server 上的 `DefaultStorageClass` [準入控制器](https://kubernetes.io/docs/admin/admission-controllers/#defaultstorageclass)。例如，通過確保 `DefaultStorageClass` 位于 API server 組件的 `--admission-control` 標志，使用逗號分隔的有序值列表中，可以完成此操作。有關 API server 命令行標志的更多信息，請檢查 [kube-apiserver](https://kubernetes.io/docs/admin/kube-apiserver/) 文檔。 ### 綁定再動態配置的情況下，用戶創建或已經創建了具有特定存儲量的 `PersistentVolumeClaim` 以及某些訪問模式。master 中的控制環路監視新的 PVC，尋找匹配的 PV（如果可能），并將它們綁定在一起。如果為新的 PVC 動態調配 PV，則該環路將始終將該 PV 綁定到 PVC。否則，用戶總會得到他們所請求的存儲，但是容量可能超出要求的數量。一旦 PV 和 PVC 綁定后，`PersistentVolumeClaim` 綁定是排他性的，不管它們是如何綁定的。 PVC 跟 PV 綁定是一對一的映射。如果沒有匹配的卷，聲明將無限期地保持未綁定狀態。隨著匹配卷的可用，聲明將被綁定。例如，配置了許多 50Gi PV的集群將不會匹配請求 100Gi 的PVC。將100Gi PV 添加到群集時，可以綁定 PVC。 ### 使用 Pod 使用聲明作為卷。集群檢查聲明以查找綁定的卷并為集群掛載該卷。對于支持多種訪問模式的卷，用戶指定在使用聲明作為容器中的卷時所需的模式。用戶進行了聲明，并且該聲明是綁定的，則只要用戶需要，綁定的 PV 就屬于該用戶。用戶通過在 Pod 的 volume 配置中包含 `persistentVolumeClaim` 來調度 Pod 并訪問用戶聲明的 PV。 ### 持久化卷聲明的保護 PVC 保護的目的是確保由 pod 正在使用的 PVC 不會從系統中移除，因為如果被移除的話可能會導致數據丟失。注意：當 pod 狀態為 `Pending` 并且 pod 已經分配給節點或 pod 為 `Running` 狀態時，PVC 處于活動狀態。當啟用PVC 保護 alpha 功能時，如果用戶刪除了一個 pod 正在使用的 PVC，則該 PVC 不會被立即刪除。PVC 的刪除將被推遲，直到 PVC 不再被任何 pod 使用。您可以看到，當 PVC 的狀態為 `Teminatiing` 時，PVC 受到保護，`Finalizers` 列表中包含 `kubernetes.io/pvc-protection`： ```bash kubectl described pvc hostpath Name: hostpath Namespace: default StorageClass: example-hostpath Status: Terminating Volume: Labels: <none> Annotations: volume.beta.kubernetes.io/storage-class=example-hostpath volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath Finalizers: [kubernetes.io/pvc-protection] ... ``` ### 回收用戶用完 volume 后，可以從允許回收資源的 API 中刪除 PVC 對象。`PersistentVolume` 的回收策略告訴集群在存儲卷聲明釋放后應如何處理該卷。目前，volume 的處理策略有保留、回收或刪除。 #### 保留保留回收策略允許手動回收資源。當 `PersistentVolumeClaim` 被刪除時，`PersistentVolume` 仍然存在，volume 被視為“已釋放”。但是由于前一個聲明人的數據仍然存在，所以還不能馬上進行其他聲明。管理員可以通過以下步驟手動回收卷。 1. 刪除 `PersistentVolume`。在刪除 PV 后，外部基礎架構中的關聯存儲資產（如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷）仍然存在。 2. 手動清理相關存儲資產上的數據。 3. 手動刪除關聯的存儲資產，或者如果要重新使用相同的存儲資產，請使用存儲資產定義創建新的 `PersistentVolume`。 #### 回收如果存儲卷插件支持，回收策略會在 volume上執行基本擦除（`rm -rf / thevolume / *`），可被再次聲明使用。但是，管理員可以使用如[此處](https://kubernetes.io/docs/admin/kube-controller-manager/)所述的 Kubernetes controller manager 命令行參數來配置自定義回收站 pod 模板。自定義回收站 pod 模板必須包含 `volumes` 規范，如下面的示例所示： ```yaml apiVersion: v1 kind: Pod metadata: name: pv-recycler namespace: default spec: restartPolicy: Never volumes: - name: vol hostPath: path: /any/path/it/will/be/replaced containers: - name: pv-recycler image: "k8s.gcr.io/busybox" command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/* && test -z \"$(ls -A /scrub)\" || exit 1"] volumeMounts: - name: vol mountPath: /scrub ``` 但是，`volumes` 部分的自定義回收站模塊中指定的特定路徑將被替換為正在回收的卷的特定路徑。 #### 刪除對于支持刪除回收策略的卷插件，刪除操作將從 Kubernetes 中刪除 `PersistentVolume` 對象，并刪除外部基礎架構（如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷）中的關聯存儲資產。動態配置的卷繼承其 `StorageClass`，默認為 Delete。管理員應該根據用戶的期望來配置 `StorageClass`，否則就必須要在 PV 創建后進行編輯或修補。請參閱[更改 PersistentVolume 的回收策略](https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/)。 ### 擴展持久化卷聲明 Kubernetes 1.8 增加了對擴展持久化存儲卷的 Alpha 支持。在 v1.9 中，以下持久化卷支持擴展持久化卷聲明： - gcePersistentDisk - awsElasticBlockStore - Cinder - glusterfs - rbd 管理員可以通過將 `ExpandPersistentVolumes` 特性門設置為true來允許擴展持久卷聲明。管理員還應該啟用[`PersistentVolumeClaimResize` 準入控制插件](https://kubernetes.io/docs/admin/admission-controllers/#persistentvolumeclaimresize)來執行對可調整大小的卷的其他驗證。一旦 `PersistentVolumeClaimResize` 準入插件已打開，將只允許其 `allowVolumeExpansion` 字段設置為 true 的存儲類進行大小調整。 ``` yaml kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: gluster-vol-default provisioner: kubernetes.io/glusterfs parameters: resturl: "http://192.168.10.100:8080" restuser: "" secretNamespace: "" secretName: "" allowVolumeExpansion: true ``` 一旦功能門和前述準入插件打開后，用戶就可以通過簡單地編輯聲明以請求更大的 `PersistentVolumeClaim` 卷。這反過來將觸發 `PersistentVolume` 后端的卷擴展。在任何情況下都不會創建新的 `PersistentVolume` 來滿足聲明。 Kubernetes 將嘗試調整現有 volume 來滿足聲明的要求。對于擴展包含文件系統的卷，只有在 ReadWrite 模式下使用 `PersistentVolumeClaim` 啟動新的 Pod 時，才會執行文件系統調整大小。換句話說，如果正在擴展的卷在 pod 或部署中使用，則需要刪除并重新創建要進行文件系統調整大小的pod。此外，文件系統調整大小僅適用于以下文件系統類型： - XFS - Ext3、Ext4 **注意**：擴展 EBS 卷是一個耗時的操作。另外，每6個小時有一個修改卷的配額。 ## 持久化卷類型 `PersistentVolume` 類型以插件形式實現。Kubernetes 目前支持以下插件類型： - GCEPersistentDisk - AWSElasticBlockStore - AzureFile - AzureDisk - FC (Fibre Channel) - FlexVolume - Flocker - NFS - iSCSI - RBD (Ceph Block Device) - CephFS - Cinder (OpenStack block storage) - Glusterfs - VsphereVolume - Quobyte Volumes - HostPath （僅限于但節點測試—— 不會以任何方式支持本地存儲，也無法在多節點集群中工作） - VMware Photon - Portworx Volumes - ScaleIO Volumes - StorageOS 原始塊支持僅適用于以上這些插件。 ## 持久化卷每個 PV 配置中都包含一個 sepc 規格字段和一個 status 卷狀態字段。 ```yaml apiVersion: v1 kind: PersistentVolume metadata: name: pv0003 spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Recycle storageClassName: slow mountOptions: - hard - nfsvers=4.1 nfs: path: /tmp server: 172.17.0.2 ``` ### 容量通常，PV 將具有特定的存儲容量。這是使用 PV 的容量屬性設置的。查看 Kubernetes [資源模型](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) 以了解 `capacity` 預期。目前，存儲大小是可以設置或請求的唯一資源。未來的屬性可能包括 IOPS、吞吐量等。 ### 卷模式在 v1.9 之前，所有卷插件的默認行為是在持久卷上創建一個文件系統。在 v1.9 中，用戶可以指定一個 volumeMode，除了文件系統之外，它現在將支持原始塊設備。 volumeMode 的有效值可以是“Filesystem”或“Block”。如果未指定，volumeMode 將默認為“Filesystem”。這是一個可選的 API 參數。 **注意**：該功能在 V1.9 中是 alpha的，未來可能會更改。 ### 訪問模式 `PersistentVolume` 可以以資源提供者支持的任何方式掛載到主機上。如下表所示，供應商具有不同的功能，每個 PV 的訪問模式都將被設置為該卷支持的特定模式。例如，NFS 可以支持多個讀/寫客戶端，但特定的 NFS PV 可能以只讀方式導出到服務器上。每個 PV 都有一套自己的用來描述特定功能的訪問模式。存儲模式包括： - ReadWriteOnce——該卷可以被單個節點以讀/寫模式掛載 - ReadOnlyMany——該卷可以被多個節點以只讀模式掛載 - ReadWriteMany——該卷可以被多個節點以讀/寫模式掛載在命令行中，訪問模式縮寫為： - RWO - ReadWriteOnce - ROX - ReadOnlyMany - RWX - ReadWriteMany > **重要**！一個卷一次只能使用一種訪問模式掛載，即使它支持很多訪問模式。例如，GCEPersistentDisk 可以由單個節點作為 ReadWriteOnce 模式掛載，或由多個節點以 ReadOnlyMany 模式掛載，但不能同時掛載。 | Volume 插件 | ReadWriteOnce | ReadOnlyMany | ReadWriteMany | | :------------------- | :-----------: | :----------: | :-------------: | | AWSElasticBlockStore | ✓ | - | - | | AzureFile | ✓ | ✓ | ✓ | | AzureDisk | ✓ | - | - | | CephFS | ✓ | ✓ | ✓ | | Cinder | ✓ | - | - | | FC | ✓ | ✓ | - | | FlexVolume | ✓ | ✓ | - | | Flocker | ✓ | - | - | | GCEPersistentDisk | ✓ | ✓ | - | | Glusterfs | ✓ | ✓ | ✓ | | HostPath | ✓ | - | - | | iSCSI | ✓ | ✓ | - | | PhotonPersistentDisk | ✓ | - | - | | Quobyte | ✓ | ✓ | ✓ | | NFS | ✓ | ✓ | ✓ | | RBD | ✓ | ✓ | - | | VsphereVolume | ✓ | - | - （當 pod 并列時有效） | | PortworxVolume | ✓ | - | ✓ | | ScaleIO | ✓ | ✓ | - | | StorageOS | ✓ | - | - | ### 類 PV 可以具有一個類，通過將 `storageClassName` 屬性設置為 [StorageClass](https://kubernetes.io/docs/concepts/storage/storage-classes/) 的名稱來指定該類。一個特定類別的 PV 只能綁定到請求該類別的 PVC。沒有 `storageClassName` 的 PV 就沒有類，它只能綁定到不需要特定類的 PVC。過去，使用的是 `volume.beta.kubernetes.io/storage-class` 注解而不是 `storageClassName` 屬性。這個注解仍然有效，但是將來的 Kubernetes 版本中將會完全棄用它。 ### 回收策略當前的回收策略包括： - Retain（保留）——手動回收 - Recycle（回收）——基本擦除（`rm -rf /thevolume/*`） - Delete（刪除）——關聯的存儲資產（例如 AWS EBS、GCE PD、Azure Disk 和 OpenStack Cinder 卷）將被刪除當前，只有 NFS 和 HostPath 支持回收策略。AWS EBS、GCE PD、Azure Disk 和 Cinder 卷支持刪除策略。 ### 掛載選項 Kubernetes 管理員可以指定在節點上為掛載持久卷指定掛載選項。 **注意**：不是所有的持久化卷類型都支持掛載選項。以下卷類型支持掛載選項： - GCEPersistentDisk - AWSElasticBlockStore - AzureFile - AzureDisk - NFS - iSCSI - RBD （Ceph Block Device） - CephFS - Cinder （OpenStack 卷存儲） - Glusterfs - VsphereVolume - Quobyte Volumes - VMware Photon 掛載選項沒有校驗，如果掛載選項無效則掛載失敗。過去，使用 `volume.beta.kubernetes.io/mount-options` 注解而不是 `mountOptions` 屬性。這個注解仍然有效，但在將來的 Kubernetes 版本中它將會被完全棄用。 ### 狀態卷可以處于以下的某種狀態： - Available（可用）——一塊空閑資源還沒有被任何聲明綁定 - Bound（已綁定）——卷已經被聲明綁定 - Released（已釋放）——聲明被刪除，但是資源還未被集群重新聲明 - Failed（失敗）——該卷的自動回收失敗命令行會顯示綁定到 PV 的 PVC 的名稱。 ## PersistentVolumeClaim 每個 PVC 中都包含一個 spec 規格字段和一個 status 聲明狀態字段。 ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: myclaim spec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 8Gi storageClassName: slow selector: matchLabels: release: "stable" matchExpressions: - {key: environment, operator: In, values: [dev]} ``` ### 訪問模式在請求具有特定訪問模式的存儲時，聲明使用與卷相同的約定。 ### 卷模式聲明使用與卷相同的約定，指示將卷作為文件系統或塊設備使用。 ### 資源像 pod 一樣，聲明可以請求特定數量的資源。在這種情況下，請求是用于存儲的。相同的[資源模型](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md)適用于卷和聲明。 ### 選擇器聲明可以指定一個[標簽選擇器](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors)來進一步過濾該組卷。只有標簽與選擇器匹配的卷可以綁定到聲明。選擇器由兩個字段組成： - matchLabels：volume 必須有具有該值的標簽 - matchExpressions：這是一個要求列表，通過指定關鍵字，值列表以及與關鍵字和值相關的運算符組成。有效的運算符包括 In、NotIn、Exists 和 DoesNotExist。所有來自 `matchLabels` 和 `matchExpressions` 的要求都被“與”在一起——它們必須全部滿足才能匹配。 ### 類聲明可以通過使用屬性 `storageClassName` 指定 [StorageClass](https://kubernetes.io/docs/concepts/storage/storage-classes/) 的名稱來請求特定的類。只有所請求的類與 PVC 具有相同 `storageClassName` 的 PV 才能綁定到 PVC。 PVC 不一定要請求類。其 `storageClassName` 設置為 `""` 的 PVC 始終被解釋為沒有請求類的 PV，因此只能綁定到沒有類的 PV（沒有注解或 `""`）。沒有 `storageClassName` 的 PVC 根據是否打開[`DefaultStorageClass` 準入控制插件](https://kubernetes.io/docs/admin/admission-controllers/#defaultstorageclass)，集群對其進行不同處理。 - 如果打開了準入控制插件，管理員可以指定一個默認的 `StorageClass`。所有沒有 `StorageClassName` 的 PVC 將被綁定到該默認的 PV。通過在 `StorageClass` 對象中將注解 `storageclass.kubernetes.io/is-default-class` 設置為 “true” 來指定默認的 `StorageClass`。如果管理員沒有指定缺省值，那么集群會響應 PVC 創建，就好像關閉了準入控制插件一樣。如果指定了多個默認值，則準入控制插件將禁止所有 PVC 創建。 - 如果準入控制插件被關閉，則沒有默認 `StorageClass` 的概念。所有沒有 `storageClassName` 的 PVC 只能綁定到沒有類的 PV。在這種情況下，沒有 `storageClassName` 的 PVC 的處理方式與 `storageClassName` 設置為 `""` 的 PVC 的處理方式相同。根據安裝方法的不同，默認的 `StorageClass` 可以在安裝過程中通過插件管理器部署到 Kubernetes 集群。當 PVC 指定了 `selector`，除了請求一個 `StorageClass` 之外，這些需求被“與”在一起：只有被請求的類的 PV 具有和被請求的標簽才可以被綁定到 PVC。 **注意**：目前，具有非空 `selector` 的 PVC 不能為其動態配置 PV。過去，使用注解 `volume.beta.kubernetes.io/storage-class` 而不是 `storageClassName` 屬性。這個注解仍然有效，但是在未來的 Kubernetes 版本中不會支持。 ## 聲明作為卷通過將聲明用作卷來訪問存儲。聲明必須與使用聲明的 pod 存在于相同的命名空間中。集群在 pod 的命名空間中查找聲明，并使用它來獲取支持聲明的 `PersistentVolume`。該卷然后被掛載到主機的 pod 上。 ```yaml 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 ``` ### 命名空間注意點 `PersistentVolumes` 綁定是唯一的，并且由于 `PersistentVolumeClaims` 是命名空間對象，因此只能在一個命名空間內掛載具有“多個”模式（`ROX`、`RWX`）的聲明。 ## 原始塊卷支持原始塊卷的靜態配置在 v1.9 中作為 alpha 功能引入。由于這個改變，需要一些新的 API 字段來使用該功能。目前，Fibre Channl 是支持該功能的唯一插件。 ### 使用原始塊卷作為持久化卷 ```yaml apiVersion: v1 kind: PersistentVolume metadata: name: block-pv spec: capacity: storage: 10Gi accessModes: - ReadWriteOnce volumeMode: Block persistentVolumeReclaimPolicy: Retain fc: targetWWNs: ["50060e801049cfd1"] lun: 0 readOnly: false ``` ### 持久化卷聲明請求原始塊卷 ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: block-pvc spec: accessModes: - ReadWriteOnce volumeMode: Block resources: requests: storage: 10Gi ``` ### 在 Pod 規格配置中為容器添加原始塊設備 ```yaml apiVersion: v1 kind: Pod metadata: name: pod-with-block-volume spec: containers: - name: fc-container image: fedora:26 command: ["/bin/sh", "-c"] args: [ "tail -f /dev/null" ] volumeDevices: - name: data devicePath: /dev/xvda volumes: - name: data persistentVolumeClaim: claimName: block-pvc ``` **注意**：當為 Pod 增加原始塊設備時，我們在容器中指定設備路徑而不是掛載路徑。 ### 綁定塊卷如果用戶通過使用 `PersistentVolumeClaim` 規范中的 `volumeMode` 字段指示此請求來請求原始塊卷，則綁定規則與以前不認為該模式為規范一部分的版本略有不同。下面是用戶和管理員指定請求原始塊設備的可能組合的表格。該表指示卷是否將被綁定或未給定組合。靜態設置的卷的卷綁定矩陣： | PV volumeMode | PVC volumeMode | 結果 | | ------------- | :------------: | ---: | | unspecified | unspecified | 綁定 | | unspecified | Block | 不綁定 | | unspecified | Filesystem | 綁定 | | Block | unspecified | 不綁定 | | Block | Block | 綁定 | | Block | Filesystem | 不綁定 | | Filesystem | Filesystem | 綁定 | | Filesystem | Block | 不綁定 | | Filesystem | unspecified | 綁定 | **注意**：alpha 版本只支持靜態配置卷。使用原始塊設備時，管理員應該注意考慮這些值。 ## 編寫可移植配置如果您正在編寫在多種集群上運行并需要持久存儲的配置模板或示例，我們建議您使用以下模式： - 要在您的在配置組合中包含 `PersistentVolumeClaim` 對象（與 Deployment、ConfigMap等一起）。 - 不要在配置中包含 `PersistentVolume` 對象，因為用戶實例化配置可能沒有創建 `PersistentVolume` 的權限。 - 給用戶在實例化模板時提供存儲類名稱的選項。 - 如果用戶提供存儲類名稱，則將該值放入 `persistentVolumeClaim.storageClassName` 字段中。如果集群具有由管理員啟用的 StorageClass，這將導致 PVC 匹配正確的存儲類別。 - 如果用戶未提供存儲類名稱，則將 `persistentVolumeClaim.storageClassName` 字段保留為 nil。 - 這將導致使用集群中默認的 StorageClass 為用戶自動配置 PV。許多集群環境都有默認的 StorageClass，或者管理員可以創建自己的默認 StorageClass。 - 在您的工具中，請注意一段時間之后仍未綁定的 PVC，并向用戶展示它們，因為這表示集群可能沒有動態存儲支持（在這種情況下用戶應創建匹配的 PV），或集群沒有存儲系統（在這種情況下用戶不能部署需要 PVC 的配置）。原文地址：https://kubernetes.io/docs/concepts/storage/persistent-volumes/ 譯者：[rootsongjc](https://github.com/rootsongjc)