1 卷的介绍

1.1 卷的概念

在搞容器的时候，我们在处理完应用如何起，如何运行，最终落实到数据的时候，我们又要考虑2个问题：容器是如何访问外部磁盘存储的？容器之间如何共享存储空间？在一些场景下，我们经常希望新起的容器可以在之前容器over的那个卡点处继续运行下去。
怎么做？怎么能解决上面的问题？这个时候k8s中的卷，也就是存储卷应运而生。卷不是独立的k8s对象，它是pod的一部分，和pod同生命周期（共享），不能单独创建和销毁，即跟随pod启动时创建，删除时销毁。当重启容器时，卷可以保持不变，新的容器可以识别上一个容器写入卷的所有文件，这样就可以卡点继续工作。
所有容器使用卷的前提是将卷挂载在每个需要访问它的容器中，当然，这个操作可以在容器文件系统的任意位置挂载。不过，容器可以装载也可以选择不装载卷。

2 卷的分类

2.1 卷的常用分类

这边主要列举一些常见的分类

emptyDir——用于存储临时数据的简单空目录；
hostPath——用于将目录从工作节点的文件系统挂载到pod中；
gitRepo——通过Git仓库的内容来初始化的卷；
nfs——挂载到pod中的NFS共享卷；
configMap、secret、downwardAPI——用于将k8s部分资源和集群信息等元数据公开给运行在pod中应用程序的特殊类型的卷，它们不用于存储数据；
persistentVolumeClaim——一种使用预置或者动态配置的持久存储类型。

2.2 emptyDir卷
emptyDir卷，就是从一个空目录开始，运行在pod内的应用程序可以写入它需要的任何文件。其生命周期是和pod捆绑，随着pod创建而创建；删除而销毁，卷的内容将会丢失。emptyDir卷适用于同一个pod中运行的容器之间共享文件。
举例：

volumes:
  - name: emptyDir1
    emptyDir: {}

两个容器挂载同一个卷进行共享：

spec:
  template:
     containers:
        - name: container1
          image: test/image1
          volumeMounts:
          - name: emptyDir1
            mountPath: /var/dir1
        - name: container2
          image: test/image2
          volumeMounts:
          - name: emptyDir1
            mountPath: /dev/doc/dir2
            readOnly: true
          ports:
          - containerPort: 80
            protocol: TCP
     volumes:
     - name: emptyDir1
       emptyDir: {}

第一个容器为container1，运行镜像test/image1，名为emptyDir1的卷挂载在容器的/var/dir1路径中；第二个容器胃container2，运行镜像test/image2，与第一个容器相同的卷挂载在/dev/doc/dir2路径上，且为只读。

2.3 gitRepo卷

gitRepo卷是一种emptyDir卷，通过克隆Git仓库并在pod启动时，检查出特定版本来填充数据（注意：pod启动时，是在创建容器前）。
原理如下：

用户创建带有gitRepo volume的pod；
k8s创建一个空目录并将指定的git仓库克隆到其中；
pod中的容器启动（卷挂载在路径上）

gitRepo volume有一个缺陷：每次将更改推送到gitRepo时，都需要删除pod才可以拉取到最新版本的信息，即本地目录和git仓库无法同步。当然，这个缺陷可以通过同步容器来实现。

2.4 hostPath卷

hostPath卷指向节点文件系统上的特定文件或目录，某些系统级别的pod可以通过挂载hostPath卷去读取节点的文件或使用节点文件系统对节点进行访问。在同一个节点上运行并在其hostPath卷中使用相同路径的pod可以看到相同的文件。
hostPath卷属于持久性存储，删除pod1后，卷里面的文件继续保持，不丢失，新的pod2如果使用了指向主机相同路径的hostPath卷，则pod2就能够发现pod1留下的文件和数据（前提，pod2能够被调度到pod1相同的节点）。
pod对预定规划的节点敏感，基于这种前提，因为卷的内容存储在特定节点的文件系统，所以pod被重新调度到其他节点时，就无法访问到原数据，hostPath卷不适合作为存储数据库数据的目录。hostPath卷通常用于尝试单节点集群中的持久化存储，仅当需要在节点上读取或写入系统文件时才会使用hostPath，不用做持久化跨pod的数据。

2.5 持久化存储

持久化
带有单个运行db1的容器的pod，容器挂载引用外部的GCE持久磁盘。这种方式需要pod的开发人员了解这个环境集群中的可用真实网络存储的基础结构，这就违背了k8s的基本理念（向应用程序及开发人员隐藏集群环境的真实基础设施，这种基础设施应该由集群管理员来控制）

2.6 持久卷PV/持久卷声明PVC

持久卷： pv，persistentVolume，不属于任何命名空间，和节点一样属于集群层面的资源，管理员通过k8s API Server创建pv时，需要告知k8s：容量需求、访问模式（RWO/ROX/RWX）、处理ov逻辑（pvc绑定删除后的逻辑）、存储类型、存储位置等属性。
持久卷声明： pvc，persistentVolumeClaim，pvc可以当做pod中的一个卷来使用，其他用户不能使用相同的持久卷pv，但可以通过删除pvc绑定来释放出pv。虽然pv不在特定的命名空间下创建，但pvc只能在特定的命名空间下创建，所以pvc和pv只能被同一个命名空间内的pod创建使用。
pv和pvc
通过持久化存储，研发人员需要了解底层的基础设施实际情况，为了能够顺应k8s的理念，通过pvc和pv来向研发人员屏蔽掉底层存储的架构。集群管理员设置底层存储，通过k8s API Server指定其大小和所支持的访问模式，创建持久卷并注册。研发人员只需要创建持久卷声明PVC清单，指定所需要的最低容量要求和访模式就可以了，剩下的pvc会提交到k8s API Server端，k8s找到可以匹配的pv，并将该pv绑定到pvc。

流程：

集群管理员创建某种类型的网络存储；
集群管理员通过k8s API Server创建持久卷pv，指定大小和访问模式；
用户创建持久卷声明pvc；
k8s寻找一个具有足够容量的pv，将其设置为访问模式，将pvc绑定到该pv上；
用户创建一个pod并通过卷配置spec.template.spec.volumes.persistentVolumeClaim.claimName来引用pvc

附：pv访问模式

扫描二维码关注公众号，回复： 9620482 查看本文章

RWO：ReadWriteOnce，仅允许当个节点挂载进行读写；
ROX：ReadOnlyMany，允许多个节点挂载且只读；
RWX：ReadWriteMany，允许多个节点挂载进行读写；

Kubernetes-卷/存储卷（emptyDir/hostPath/pv/pvc）