Volume

前言：

根据应用本身是否需要持久存储数据，以及某一次请求跟此前的请求之间是否有关联性，可以分为四类应用：有状态要持久存储、有状态无持久存储、无状态持久存储、无状态要持久存储。

大多数与数据存储服务相关的应用如果为有状态，几乎都需要持久存储。

pod运行的时候是运行在某个节点上，只要不出故障，pod就一直在某个节点上运行，节点或者pod故障才会重新调度。一旦这个pod故障了被删除，那么久被重构，重构的原因就在于pod故障，这个故障可能是用户手动删除了或者pod所在的节点挂了，然后pod被重新编排到其他节点上运行，不管是哪种形式，pod都是有生命周期的，因此我们把数据放在它的自有的名称空间中，数据会随之容器的结束而结束。为了突破数据受pod生命周期限制的现状，我们需要把数据放在pod自有文件系统之外的地方。如果把数据存放在本地主机的目录上，一旦node节点挂掉了，数据就没有了。为了实现更加强大的持久性，我们应该使用脱离节点而存在的存储设备。

对于Pod来讲，pod有个特性：同一个pod内的容器可以共享访问同一个存储卷。对于k8s来说，存储卷不属于容器，而是属于pod。我们可以在容器中去挂载，所以，如果你两个容器都挂载了，相当于这两个容器共享数据。“为什么pod内部能有存储卷和网络空间呢”。每个Pod里运行着一个特殊的被称之为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此他们之间通信和数据交换更为高效，在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中。同一个Pod里的容器之间仅需通过localhost就能互相通信。

 

这个pause容器的镜像空间很小。我们创建pod的时候，它是pod的根，我们在pod中运行的主容器都是共享网络存储空间的，容器要挂载存储卷，其实是挂载他的存储卷，这是复制了这个pause容器的存储卷而已，所以pause也称为基础架构容器。

如果我在pod中使用存储卷，其实就是使用这个基础架构容器pause。容器的存储卷只不过是容器目录与宿主机目录建立了关联关系。如果宿主机的目录可就是宿主机本地的，那么久会随着宿主机的终结而终结，因此，为了实现真正地持久性，宿主机的目录不是本地的，而是挂载在外部的存储设备上的。三级关联关系图如下：

（一）空目录

k8s有哪些存储卷可以使用呢：

第一种：只在本地节点使用。在本地中起一个Pod,给pod分一个存储卷，这个存储卷就只在节点本地使用的。

这样存在问题，一旦pod删除了，这个存储卷也会一并被删除。如果pod删除，存储卷不删除，还能在一定意义上持久性（本地节点不挂），现在是pod 一旦删除，存储卷的数据也会被清除，所以，它不是为了持久而设计，而是用来做临时目录，这种存储卷我们称为空目录（emprydir，类似虚拟机的tmp目录）。

随着pod被删除，所以它只是用来当临时目录或者缓存。emprydir背后功能的宿主机目录可以是宿主机的内存。我把内存弄一块当硬盘使用，直接挂载目录，然后再跟pod的存储卷建立关联关系

• （二）hostpath(主机路径)

这种会把宿主机上的指定卷加载到容器，容器删除后，在本地重建pod仍然可以读取到之前的数据。当然，如果pod发生跨主机的破坏（调度到其他主机上），其数据就会损坏。

• （三）网络存储

• 网络存储分为三类：

  第一种是传统意义上的网络存储设备：

  SAN: iscsi、fc

  NAS：nfs，cifs

  第二种是分布式存储：

  glusterfs，ceph，cephfs

  第三种是云存储：

  亚马逊的EBS、阿里华为腾讯的存储服务

  作为一个容器，支持网络存储自然是重中之重，k8s为支持网络存储，各种支持的方式不尽相同，例如glusterfs需要创建endpoint。