# 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 ，用于描述该卷的规格和状态。

~~~yaml
  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](https://github.com/kubernetes/kubernetes/blob/release-1.2/docs/design/resources.md) 一文，来获取这一属性的计量单位 (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，用以表达其规格和状态。

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

### 访问模式

PVC 使用跟 PV 一致的访问模式。

### 资源

PVC 跟 Pod 一样可以请求特定数量的资源。在这里的请求内容就是存储（storage）。[Resource Model](https://github.com/kubernetes/kubernetes/blob/release-1.2/docs/design/resources.md) 文中提到的内容对 PV 和 PVC 同样适用。

## PVC 卷

Pod 能够借助 PVC 来访问存储。PVC 必须跟 Pod 处于同一个命名空间。集群找到 Pod 命名空间中的 PVC，然后利用 PVC 获取到背后的 PV。这个卷就会被加载到主机上，让 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
~~~