k8s之存储卷

一、本地存储卷

• emptyDir

  emptyDir卷是最简单的卷，主要用于存储临时数据，当pod生命周期结束，emptyDir卷也就销毁。
  emptyDir卷应用场景一般是pod中多个容器共享数据，即在pod中定义一个emptyDir卷，然后容器A挂载到某个目录，容器B也挂载到某个目录，这样，容器A和容器B就能读写文件，就能共享数据。
  

• hostpath

   hostPath：用于将目录从工作节点的文件系统挂载到pod中。
   我们知道，虽然hostPath卷实现pod中数据存储到节点的文件系统中，但是pod的调度不是固定的，也就是当pod消失后deployment重新创建一个pod，而这pod如果不是被调度到之前pod的节点，那么该pod就不能访问之前的数据。
  

• local

  local能够作为PV使用的本地存储卷
  local 卷所代表的是某个被挂载的本地存储设备，例如磁盘、分区或者目录。
  local 卷只能用作静态创建的持久卷。不支持动态配置。
  与 hostPath 卷相比，local 卷能够以持久和可移植的方式使用，而无需手动将 Pod 调度到节点。系统通过查看 PersistentVolume 的节点亲和性配置，就能了解卷的节点约束。然而，local 卷仍然取决于底层节点的可用性，并不适合所有应用程序。 如果节点变得不健康，那么 local 卷也将变得不可被 Pod 访问。使用它的 Pod 将不能运行。 使用 local 卷的应用程序必须能够容忍这种可用性的降低，以及因底层磁盘的耐用性特征而带来的潜在的数据丢失风险。
  

二、网络存储卷

• NFS

  将nfs服务器上导出 (export) 的文件系统用作存储卷；
  nfs是文件系统级共享服务，它支持多路挂载请求，可由多个Pod对象同时用作存储卷后端；
  网络卷首先要由主机节点挂载，然后才能暴露在pod;
  有些网终卷未必支持多主机节点同时挂载；
  

三、持久化卷

以上，我们在pod创建nfs存储卷时，是直接在pod定义存储卷的，这显然需要开发pod的工程师知道nfs服务器的ip地址及其他的参数，这违背了kubernetes的基本理念，kubernetes的基本理念旨在向应用程序及其开发人员隐藏真实的底层基础设施，使他们不必担心基础设施的具体状态，并使应用程序可在大量云服务商和数据企业之间进行功能迁移。

理想的情况是，在Kubernetes上部署应用程序的开发人员不需要知道底层使用的是哪种存储技术，同理他们也不需要了解应该使用哪些类型的物理服务器来运行pod，与基础设施相关的交互是集群管理员独有的控制领域。

当开发人员需要一定数量的持久化存储来进行应用时，可以向Kubernetes请求，就像在创建pod时可以请求CPU、内存和其他资源一样。系统管理员可以对集群进行配置让其可以为应用程序提供所需的服务。

在Kubernetes集群中，为了使应用能够正常请求存储资源，同时避免处理基础设施细节，引入了两个新的资源，分别是持久卷和持久卷声明。

• pv持久卷

  PersistentVolume（持久卷，简称PV），PV不属于任何命名空间，PV是集群层面的资源。
  简单的来说，持久卷就是定义存储的一个k8s资源对象；
  

• pvc持久卷声明

  当集群用户需要在其pod中使用持久化存储时，他们并不是直接使用pv的，而是，首先创建一个持久卷声明（PersistentVolumeClaim，简称PVC），指定所需要的最低容量要求和访问模式，然后用户将pvc清单提交给Kubernetes API服务器，Kubernetes将找到可匹配的pv并将其绑定到pvc。
  pvc可以当作pod中的一个卷来使用，其他用户不能使用相同的持久卷，除非先通过删除持久卷声明绑定来释放。
  

• StorageClass

持久卷的动态卷配置、为什么需要StorageClass，一般我们创建pv和使用pv的流程是：

1、创建一个持久卷；
2、再创建一个持久卷声明，持久卷声明根据访问模式和容量大小来自动适配到PV，并进行绑定；
3、pod中应用持久卷声明即可实现使用存储。

假如在一个大规模的Kubernetes集群里，可能有成千上万个PVC，这就意味着运维人员必须实现创建出这个多个PV，此外，随着项目的需要，会有新的PVC不断被提交，那么运维人员就需要不断的添加新的，满足要求的PV，否则新的Pod就会因为PVC绑定不到PV而导致创建失败。而且通过 PVC 请求到一定的存储空间也很有可能不足以满足应用对于存储设备的各种需求。

而且不同的应用程序对于存储性能的要求可能也不尽相同，比如读写速度、并发性能等，为了解决这一问题，Kubernetes 又为我们引入了一个新的资源对象：StorageClass，通过 StorageClass 的定义，管理员可以将存储资源定义为某种类型的资源，比如快速存储、慢速存储等，用户根据 StorageClass 的描述就可以非常直观的知道各种存储资源的具体特性了，这样就可以根据应用的特性去申请合适的存储资源了。

什么是StorageClass（简写sc）

  Kubernetes提供了一套可以自动创建PV的机制，即：Dynamic Provisioning。而这个机制的核心在于StorageClass这个API对象。
  StorageClass定义存储细节，对接远程存储管理API接口。
  StorageClass对象会定义下面两部分内容:
  1、PV的属性。比如，存储类型，Volume的大小等。
  2、创建这种PV需要用到的存储插件，即存储制备器。
  有了这两个信息之后，Kubernetes就能够根据用户提交的PVC，找到一个对应的StorageClass，之后Kubernetes就会调用该StorageClass声明的存储插件，进而创建出需要的PV。

优化后的流程
引入了持久卷的动态配置之后，整个流程就变成了如下：

  1、管理员首选需要提供或创建Provisioner（供应者），Provisioner负责为外部请求提供pv(持久化存储卷)实例（相当于定义哪个是nfs存储服务器），说白了，Provisioner作用就是，决定使用哪个卷插件分配 PV；
  2、StorageClass向绑定的Provistioner发出创建pv(持久化存储卷)请求；
  3、PVC绑定到StorageClass，StorageClass就会根据PVC指定的容量、访问模式来自动创建与PVC匹配的PV，无需人工干预；
  4、Pod应用PVC。

正向流程：pod引用pvc，pvc向sc发出请求，sc向provisioner发出创建pv请求并成功创建pv。

  以上4步就是整个动态卷的流程，现在只需要我们运维人员前期创建多个StorageClass存储类，然后就不用管了，开发人员他们自己创建pvc，pvc就会自动向sc发出创建pv请求，这样pv自动创建成功，就不需要运维人员手动一个个创建pv了。

四、参考

原文链接：https://blog.csdn.net/MssGuo/article/details/123611986