深入剖析 Kubernetes-4 容器持久化存储

1 PV&PVC&StorageClass

1.1 概念

• PV描述的是持久化存储数据卷。

• PVC描述的是Pod所希望使用的持久化存储的属性。

• StorageClass其实就是创建PV的模板。

用户创建的PVC要真正被容器使用起来，必须先和某个符合条件的PV进行绑定。这里要检查的条件包括两部分：

• PV 和 PVC 的 spec 字段。比如，PV 的存储（storage）大小，就必须满足 PVC 的要求。
• PV 和 PVC 的 storageClassName 字段必须一样。

PVC 和 PV 的设计，其实跟“面向对象”的思想完全一致。

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

在 Kubernetes 中，实际上存在着一个专门处理持久化存储的控制器，叫作 Volume Controller。这个 Volume Controller 维护着多个控制循环，其中有一个循环，扮演的就是撮合 PV 和 PVC 的“红娘”的角色。它的名字叫作 PersistentVolumeController。它会不断地查看当前每一个 PVC，是不是已经处于Bound（已绑定）状态。如果不是，那它就会遍历所有的、可用的 PV，并尝试将其与这个“单身”的 PVC 进行绑定。

将一个 PV 与 PVC 进行“绑定”，其实就是将这个 PV 对象的名字，填在了 PVC 对象的 spec.volumeName 字段上。所以，接下来 Kubernetes 只要获取到这个 PVC 对象，就一定能够找到它所绑定的 PV。

1.2 PV对象如何变成容器里的一个持久化存储

所谓容器的 Volume，其实就是将一个宿主机上的目录，跟一个容器里的目录绑定挂载在了一起。而所谓的“持久化 Volume”，指的就是这个宿主机上的目录，具备“持久性”。而所谓的“持久化 Volume”，指的就是这个宿主机上的目录，具备“持久性”。

Kubernetes 需要做的工作，就是使用远程存储服务，来为容器准备一个持久化的宿主机目录，以供将来进行绑定挂载时使用。

准备“持久化”宿主机目录的过程，我们可以形象地称为“两阶段处理”。

• 第一阶段：Attach

  为虚拟机挂载远程磁盘的操作，对应的正是“两阶段处理”的第一阶段。在Kubernetes 中，我们把这个阶段称为 Attach。

• 第二阶段：Mount

  将磁盘设备格式化并挂载到 Volume 宿主机目录的操作，对应的正是“两阶段处理”的第二个阶段，我们一般称为：Mount。

注：如果你的 Volume 类型是远程文件存储（比如 NFS）的话，kubelet 的处理过程就会更简单一些。在这种情况下，kubelet 可以跳过“第一阶段”（Attach）的操作，这是因为一般来说，远程文件存储并没有一个“存储设备”需要挂载在宿主机上。kubelet 会直接从“第二阶段”（Mount）开始准备宿主机上的 Volume 目录。

经过了“两阶段处理”，我们就得到了一个“持久化”的 Volume 宿主机目录。所以，接下来，kubelet 只要把这个 Volume 目录通过 CRI 里的 Mounts 参数，传递给Docker，然后就可以为 Pod 里的容器挂载这个“持久化”的 Volume 了。

关于 PV 的“两阶段处理”流程，是靠独立于 kubelet 主控制循环（Kubelet Sync Loop）之外的两个控制循环来实现的。

Attach（以及 Dettach）操作，是由 Volume Controller 负责维护的，这个控制循环的名字叫作：AttachDetachController。而它的作用，就是不断地检查每一个 Pod 对应的 PV，和这个 Pod 所在宿主机之间挂载情况。从而决定，是否需要对这个 PV 进行 Attach（或者 Dettach）操作。AttachDetachController是运行在Master节点上的。

Mount（以及 Unmount）操作，必须发生在 Pod 对应的宿主机上，所以它必须是 kubelet 组件的一部分。这个控制循环的名字，叫作：VolumeManagerReconciler，它运行起来之后，是一个独立于 kubelet 主循环的Goroutine。

kubelet 的一个主要设计原则，就是它的主控制循环绝对不可以被 block。

1.3 StorageClass

人工管理 PV 的方式就叫作 Static Provisioning。Kubernetes 为我们提供了一套可以自动创建 PV 的机制，即：Dynamic Provisioning。Dynamic Provisioning 机制工作的核心，在于一个名叫 StorageClass 的 API 对象。

StorageClass 对象会定义如下两个部分内容：

• PV 的属性。比如，存储类型、Volume 的大小等等。
• 创建这种 PV 需要用到的存储插件。比如，Ceph 等等。

需要注意的是，StorageClass 并不是专门为了 Dynamic Provisioning 而设计的。你可以在PVC和PV中定义相同的即便不存在的StorageClass，Kubernetes 会将他们绑定起来，这个时候进行的是Static Provisioning。

如果你的集群已经开启了名叫 DefaultStorageClass 的 Admission Plugin，它就会为 PVC 和 PV 自动添加一个默认的 StorageClass；否则，PVC 的 storageClassName的值就是“”，这也意味着它只能够跟 storageClassName 也是“”的 PV 进行绑定。

1.4 总结

PVC 描述的，是 Pod 想要使用的持久化存储的属性，比如存储的大小、读写权限等。
PV 描述的，则是一个具体的 Volume 的属性，比如 Volume 的类型、挂载目录、远程存储服务器地址等。
StorageClass 的作用，则是充当 PV 的模板。并且，只有同属于一个 StorageClass的 PV 和 PVC，才可以绑定在一起。

StorageClass 的另一个重要作用，是指定 PV 的 Provisioner（存储插件）。这时候，如果你的存储插件支持 Dynamic Provisioning 的话，Kubernetes 就可以自动为你创建 PV 了。