大白话说明白K8S的PV / PVC / StorageClass _K8S

先来个一句话总结：PV、PVC是K8S用来做存储管理的资源对象，它们让存储资源的使用变得可控，从而保障系统的稳定性、可靠性。StorageClass则是为了减少人工的工作量而去自动化创建PV的组件。所有Pod使用存储只有一个原则：先规划 → 后申请 → 再使用。

文章插图
一、理论1、PV概念PV是对K8S存储资源的抽象，PV一般由运维人员创建和配置，供容器申请使用。
没有PV之前，服务器的磁盘没有分区的概念，有了PV之后，相当于通过PV对服务器的磁盘进行分区。
2、PVC概念PVC 是Pod对存储资源的一个申请，主要包括存储空间申请、访问模式等。创建PV后，Pod就可以通过PVC向PV申请磁盘空间了。类似于某个应用程序向操作系统的D盘申请1G的使用空间。
PVC 创建成功之后，Pod 就可以以存储卷（Volume）的方式使用 PVC 的存储资源了。Pod 在使用 PVC 时必须与PVC在同一个Namespace下。
3、PV / PVC的关系PV相当于对磁盘的分区，PVC相当于App（应用程序）向某个分区申请多少空间。比如说安装wps程序时，一般会告知我们安装它需要多少存储空间，让你选择在某个磁盘下安装。如果将来某个分区磁盘满了，也不会影响别的分区磁盘的使用。
一旦 PV 与PVC绑定，Pod就可以使用这个 PVC 了。如果在系统中没有满足 PVC 要求的 PV，PVC则一直处于 Pending 状态，直到系统里产生了一个合适的 PV 。
4、StorageClass概念K8S有两种存储资源的供应模式：静态模式和动态模式，资源供应的最终目的就是将适合的PV与PVC绑定：

静态模式：管理员预先创建许多各种各样的PV，等待PVC申请使用。
动态模式：管理员无须预先创建PV，而是通过StorageClass自动完成PV的创建以及与PVC的绑定。

StorageClass就是动态模式，根据PVC的需求动态创建合适的PV资源，从而实现存储卷的按需创建。
一般某个商业性的应用程序，会用到大量的Pod，如果每个Pod都需要使用存储资源，那么就需要人工时不时的去创建PV ，这也是个麻烦事儿。解决方法就是使用动态模式：当Pod通过PVC申请存储资源时，直接通过StorageClass去动态的创建对应大小的PV ，然后与PVC绑定，所以基本上PV → PVC是一对一的关系。
5、Provisioner概念在创建 PVC 时需要指定 StorageClass，PVC 选择到对应的StorageClass后，与其关联的 Provisioner 组件来动态创建 PV 资源。
那Provisioner是个啥呢？其实就一个存储驱动，类似操作系统里的磁盘驱动。
StorageClass 资源对象的定义主要包括：名称、Provisioner、存储的相关参数配置、回收策略。StorageClass一旦被创建，则无法修改，只能删除重新创建。
PV和PVC的生命周期，包括4个阶段：资源供应（Provisioning）、资源绑定（Binding）、资源使用（Using）、资源回收（ReclAIming）。首先旧的有资源供应，说白了就是得有存储驱动，然后才能创建、绑定和使用、回收。
6、使用PV / PVC前后对比6.1、通过描述对比在没有使用PV、PVC之前，各个Pod都可以任意的向存储资源里（比如NFS）写数据，随便一个Pod都可以往磁盘上插一杠子，长期下去磁盘的管理会越来越混乱，然后导致数据使用超限，磁盘爆掉，最后导致磁盘上的所有应用全部挂掉。
为了解决这个问题，引入了PV、PVC的概念，达到限制Pod写入存储数据大小的目的，从而更好地保障了系统的可用性、稳定性。
有了PVC、PV之后，所有Pod使用存储资源，保持一个原则：先规划 → 后申请 → 再使用。
那你肯定有一个疑问， “StorageClass是自动化创建PV，跟原本的无序不可控是一样的效果啊，都可以随便占用存储资源啊” 。
其实不然，使用StorageClass只是自动化了创建PV的流程，但依旧执行的是一个存储可控的流程。每个Pod使用多少存储空间是固定的，Pod没有办法超额使用存储空间，更不会影响到别的应用，要出故障也只是某个Pod自己出故障。
6.2、通过图片对比没有使用PV、PVC之前的情况，如下面2张图：