跳转至

存储卷基本概念

基本存储概念

  • PV 与 PVC

可以通过 hostPath 或者 emptyDir 的方式来持久化数据，但是显然还需要更加可靠的存储来保存应用的持久化数据，这样容器在重建后，依然可以使用之前的数据

但是存储资源和 CPU 资源以及内存资源有很大不同，为了屏蔽底层的技术实现细节，让用户更加方便的使用，Kubernetes 便引入了 PV 和 PVC 两个重要的资源对象来实现对存储的管理。

PVC 和 PV 的设计，其实跟“面向对象”的思想完全一致，PVC 可以理解为持久化存储的 “接口”，它提供了对某种持久化存储的描述，但不提供具体的实现；而这个持久化存储的实现部分则由 PV 负责完成。这样做的好处是，作为应用开发者，只需要跟 PVC 这个 “接口” 打交道，而不必关心具体的实现是 hostPath、NFS 还是 Ceph。这样对于 Pod 来说就不用管具体的细节，只需要给一个可用的 PVC 即可，这样是不是就完全屏蔽细节和解耦，所以更应该使用 PV、PVC 这种方式。

  • StorageClass

但是通过 PVC 请求到一定的存储空间也很有可能不足以满足应用对于存储设备的各种需求，而且不同的应用程序对于存储性能的要求可能也不尽相同，比如读写速度、并发性能等，为了解决这一问题，Kubernetes 又为我们引入了一个新的资源对象：StorageClass

持久化卷

PV 的全称是：PersistentVolume（持久化卷），是对底层共享存储的一种抽象

  • PV 由管理员进行创建和配置，它和具体的底层的共享存储技术的实现方式有关，比如 Ceph、GlusterFS、NFS、hostPath 等，都是通过插件机制完成与共享存储的对接

持久化卷声明

PVC 的全称是：PersistentVolumeClaim（持久化卷声明），PVC 是用户存储的一种声明

  • PVC 和 Pod 比较类似，Pod 消耗的是节点，PVC 消耗的是 PV 资源，Pod 可以请求 CPU 和内存，而 PVC 可以请求特定的存储空间和访问模式

  • 对于真正使用存储的用户不需要关心底层的存储实现细节，只需要直接使用 PVC 即可

目前 PV 和 PVC 之间是一对一绑定的关系，也就是说一个 PV 只能被一个 PVC 绑定。

存储类

StorageClass 存储类

存储类简介：https://kubernetes.io/zh-cn/docs/concepts/storage/storage-classes/

  • 通过 StorageClass 的定义，管理员可以将存储资源定义为某种类型的资源，比如快速存储、慢速存储等，用户根据 StorageClass 的描述就可以非常直观的知道各种存储资源的具体特性了，这样就可以根据应用的特性去申请合适的存储资源了

  • 此外 StorageClass 还可以为我们自动生成 PV，免去了每次手动创建的麻烦

持久化卷

静态的 PV 管理方式

需要注意的是，手动创建 PV 的方式，即静态的 PV 管理方式，在删除 PV 时需要按如下流程执行操作：

  • 删除使用这个 PV 的 Pod
  • 从宿主机移除本地磁盘
  • 删除 PVC
  • 删除 PV

配置参数

存储能力

Capacity（存储能力）：一般来说，一个 PV 对象都要指定一个存储能力，通过 PV 的 capacity 属性来设置的

目前只支持存储空间的设置，不过未来可能会加入 IOPS、吞吐量等指标的配置

访问模式

AccessModes（访问模式）：用来对 PV 进行访问模式的设置，用于描述用户应用对存储资源的访问权限

访问权限包括下面几种方式：

  • ReadWriteOnce（RWO）：读写权限，但是只能被单个节点挂载
  • ReadOnlyMany（ROX）：只读权限，可以被多个节点挂载
  • ReadWriteMany（RWX）：读写权限，可以被多个节点挂载

一些 PV 可能支持多种访问模式，但是在挂载的时候只能使用一种访问模式，多种访问模式是不会生效的

img

回收策略

RECLAIM POLICY 的配置，同样可以通过 PV 的 persistentVolumeReclaimPolicy（回收策略）属性来进行配置，目前 PV 支持的策略有三种：

  • Retain（保留）：保留数据，需要管理员手工清理数据
  • Recycle（回收）：清除 PV 中的数据，效果相当于执行 rm -rf /thevoluem/*
  • Delete（删除）：与 PV 相连的后端存储完成 volume 的删除操作，当然这常见于云服务商的存储服务，比如 ASW EBS

不过需要注意的是，目前只有 NFS 和 HostPath 两种类型支持回收策略，当然一般来说还是设置为 Retain 这种策略保险一点

Recycle 策略会通过运行一个 busybox 容器来执行数据删除命令

默认定义的 busybox 镜像是：gcr.io/google_containers/busybox:latest，并且 imagePullPolicy: Always，如果需要调整配置，需要增加kube-controller-manager 启动参数：--pv-recycler-pod-template-filepath-hostpath 来进行配置。

PV 的四种状态

PV 的状态，实际上描述的是 PV 的生命周期的某个阶段，一个 PV 的生命周期中，可能会处于 4 种不同的阶段：

  • Available（可用）：表示可用状态，还未被任何 PVC 绑定
  • Bound（已绑定）：表示 PV 已经被 PVC 绑定
  • Released（已释放）：PVC 被删除，但是资源还未被集群重新声明
  • Failed（失败）： 表示该 PV 的自动回收失败

存储类

配置参数

回收策略

由 StorageClass 动态创建的 PersistentVolume 会在类的 reclaimPolicy 字段中指定回收策略，可以是 Delete 或者 Retain。如果 StorageClass 对象被创建时没有指定 reclaimPolicy，它将默认为 Delete。

通过 StorageClass 手动创建并管理的 PersistentVolume 会使用它们被创建时指定的回收策略。

卷绑定模式

在 StorageClass 种有一个 volumeBindingMode=WaitForFirstConsumer 的属性，就是告诉 Kubernetes 在发现这个 StorageClass 关联的 PVC 与 PV 可以绑定在一起，但不要现在就立刻执行绑定操作（即：设置 PVC 的 VolumeName 字段），而是要等到第一个声明使用该 PVC 的 Pod 出现在调度器之后