PVC 是 Kubernetes 中一种比较常见的持久化存储方案，其后端一般是独立的存储系统如 NFS、iSCSI、cephfs 、glusterfs 等。本文将简单阐述这一套存储体系的大致内容。

基本概念

在学习 Kubernetes 的持久化存储体系之前，您需要先了解以下几个概念：

  • Volume（卷）

所谓容器的 Volume，其实就是将一个宿主机上的目录，跟一个容器里的目录绑定挂载在一起。在 Kubernets 中，卷的类型有很多，不同类型的卷的功能都不一样，具体可以参照文档：http://docs.kubernetes.org.cn/429.html#i[Kubernetes 中文文档-Kubernetes Volume]。

  • PV

    PV 描述的是持久化存储数据卷。所谓的“持久化 Volume”，指的是宿主机上的目录，具备“持久性”。即：这个目录里面的内容，既不会因为容器的删除而被清理掉，也不会跟当前的宿主机绑定。

  • PVC

    PVC 描述的则是 Pod 所希望使用的持久化存储的属性。比如：Volume 存储的大小、可读写权限等。

  • StorageClass

    StorageClass 即创建 PV 的模板。

API 对象详解

以下主要介绍 PV、PVC、StorageClass 等这三种 API 对象。

PV

PV 全称是 PersistentVolume ，是集群中的一块存储，由管理员配置或使用存储类动态配置。 它是集群中的资源，就像节点是集群资源一样。 PV 是与 Volumes 类似的卷插件，但具有独立于使用 PV 的任何单个 Pod 的生命周期。

其定义方式如下：（以 NFS 类型的 PV 为例）

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs
spec:
  storageClassName: manual
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    server: 10.244.1.4
    path: "/"

可以看到，在这个 yaml 文件的 spec 中，我们在 spec 中声明了 storageClassName ，capacity ，accessModes ，persistentVolumeReclaimPolicy ，以及 NFS 的属性。

这些参数的主要作用如下：

  • storageClassName： 此处声明 storageClass 的名字。

  • capacity：设置存储空间大小。

  • accessModes：设置访问模式，PV 支持三种访问模式，分别是：

    • ReadWriteMany：多路读写，卷能被集群多个节点挂载并读写；

    • ReadWriteOnce：单路读写，卷只能被单一集群节点挂载读写；

    • ReadOnlyMany：多路只读，卷能被多个集群节点挂载且只能读。

      说明

      访问模型总共有三种，但不同的存储类型支持的访问模型不同，具体支持什么类型，需要查询官网。

      一个卷一次只能使用一种访问模式挂载，即使它支持多种访问模式。

      详细参见 官方文档。

  • persistentVolumeReclaimPolicy：设置回收策略，此处同样支持三种回收策略：

    • Retain：保留，需要手动回收。当删除与之绑定的 PVC 时候，这个 PV 被标记为 released（PVC 与 PV 解绑但还没有执行回收策略）且之前的数据依然保存在该 PV 上，但是该 PV 不可用，需要手动来处理这些数据并删除该 PV。

    • Recycle：回收，当用户不再使用其存储卷时，他们可以从 API 中将 PVC 对象删除，从而允许 该资源被回收再利用。 回收策略 Recycle 已被废弃。取而代之的建议方案是使用动态供应。

    • Delete：对于支持 Delete 回收策略的卷插件，当删除阈值绑定的 PVC 时，会将 PersistentVolume 对象从 Kubernetes 中移除，同时也会从外部基础设施（如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷）中移除所关联的存储资产。

Volume

前面有说到，PV 描述的是持久化存储数据卷，为了保证这个 Volume 基本持久性，Kubernetes 就做的工作，就是使用这些存储服务（NFS ，GlusterFS ，远程块存储），来为容器准备一个持久化的宿主机目录，以供将来进行绑定挂载时使用。而容器在这个目录里写入的文件，都会保存在远程存储中，从而使得这个目录具备了持久性。

这个“持久化”的的过程主要分为如下两步，一般形象的称为“两阶段处理”：

  • 第一阶段 Attach

    这一阶段主要是为虚拟机挂载磁盘。

    当一个 pod 被调度到某个节点后，kubelet 就会为这个 pod 创建对应的 Volume 目录。如果pod 的 Volume 类型是远程块存储，那么 kubelet 就会调用对应的 API 为 node 加载一块磁盘。而如果你的后端存储是远程文件存储（比如 NFS）的话，kubelet 会直接从“第二阶段”（Mount）开始准备宿主机上的 Volume 目录。

  • 第二阶段 Mount

    这一阶段主要是将挂载的磁盘进行格式化处理，并挂载到宿主机 Volume 目录上。

以上就是 Volume 持久化的过程，对应地，在删除一个 PV 的时候，Kubernetes 也需要 Unmount 和 Dettach 两个阶段来处理。这个过程执行“反向操作”即可。

PVC

PVC 全称 PersistentVolumeClaim，表达的是用户对存储的请求。概念上与 Pod 类似。 Pod 会耗用节点资源，而 PVC 申领会耗用 PV 资源。Pod 可以请求特定数量的资源（CPU 和内存）；同样 PVC 申领也可以请求特定的大小和访问模式 。

其可以通过如下方式来定义。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: manual
  resources:
    requests:
      storage: 1Gi

可以看到 PVC 中声明的东西很多和 PV 中声明的类似，主要是声明了 accessModes，storageClassName 以及卷的容量。因为 PVC 主要是表达用户对存储的请求，所以 PVC 要真正被容器使用起来，就必须先和某个符合条件的 PV 进行绑定。

这里要检查的条件，包括两部分：

  • 第一个条件，当然是 PV 和 PVC 的 spec 字段。比如，PV 的存储（storage）大小，就必须满足 PVC 的要求。

  • 第二个条件，则是 PV 和 PVC 的 storageClassName 字段必须一样。

PVC 可以理解为持久化存储的“接口”，它提供了对某种持久化存储的描述，但不提供具体的实现；而这个持久化存储的实现部分则由 PV 负责完成。

Volume Controller

前面说到，PVC 必须和 PV 绑定之后才能被 pod 使用。但是这个绑定操作应该由谁来完成呢？其实在 Kubernetes 中运行着一个单独的控制器 Volume Controller，它所维护的一个名叫 PersistentVolumeController 的控制循环，专门负责这个操作。

PersistentVolumeController 会不断地查看当前每一个 PVC，是不是已经处于 Bound（已绑定）状态。如果不是，那它就会遍历所有的、可用的 PV，并尝试将其与这个 PVC 进行绑定。而所谓将一个 PV 与 PVC 进行“绑定”，其实就是将这个 PV 对象的名字，填在了 PVC 对象的 spec.volumeName 字段上。

StorageClass

前面介绍 PVC 的时候有说到，PVC 需要和 PV 绑定之后才能供 pod 使用。所以，这也要求 PV 需要提前创建好，但是在生产中，尤其是在云平台上，这些操作不应该由人工来完成。而在 Kubernetes 为我们提供了一套可以自动创建 PV 的机制，即：Dynamic Provisioning。Dynamic Provisioning 机制工作的核心，在于一个名叫 StorageClass 的 API 对象。

StorageClass 对象的作用，其实就是创建 PV 的模板。

具体地说，StorageClass 对象会定义如下两个部分内容：

  • 第一，PV 的属性。比如，存储类型、Volume 的大小等等。

  • 第二，创建这种 PV 需要用到的存储插件。比如，Ceph 等等。

当用户创建了一个 PVC 的资源之后，Kubernetes 就会根据 PVC 中的 StroageClassName 找到对应的 StroageClass，然后调用该 StorageClass 声明的存储插件，创建出需要的 PV。

需要注意的是，虽然 Kubernetes 在绑定 PV 和 PVC 的时候会匹配 StroageClass 的名字，但是如果对于静态创建的 PV 和 PVC，即便你的 StroageClass 不存在（如文章中的名叫 manual 的 StorageClass 并不存在），但 Kubernetes 在做绑定决策的时候，它依然会考虑 PV 和 PVC 的 StorageClass 定义。

其次，如果你的集群已经开启了名叫 DefaultStorageClass 的 Admission Plugin，那么在定义存储时候即便没有声明 StorageClass，kubernetes 也会为 PVC 和 PV 自动添加一个默认的 StorageClass；否则，PVC 的 storageClassName 的值就是“”，这也意味着它只能够跟 storageClassName 也是 “” 的 PV 进行绑定。