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原理图
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
k8s对于有状态的容器应用或者数据需要持久化存储的应用，不仅仅需要将容器内的目录挂载到宿主机的目录或者通过emptyDir临时存储卷，同样需要更加可靠的持久卷和持久卷声明这两个资源对象进行应用重要数据的存储，这样可以对用户屏蔽底层存储实现的细节，让其更好的关注pod这些资源的维护。
持久卷： pv，persistentVolume，不属于任何命名空间，和节点一样属于集群层面的资源，管理员通过k8s API Server创建pv时，需要告知k8s：容量需求、访问模式（RWO/ROX/RWX）、处理ov逻辑（pvc绑定删除后的逻辑）、存储类型、存储位置等属性。
持久卷声明： pvc，persistentVolumeClaim，pvc可以当做pod中的一个卷来使用，其他用户不能使用相同的持久卷pv，但可以通过删除pvc绑定来释放出pv。虽然pv不在特定的命名空间下创建，但pvc只能在特定的命名空间下创建，所以pvc和pv只能被同一个命名空间内的pod创建使用。
通过持久化存储，研发人员需要了解底层的基础设施实际情况，为了能够顺应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访问模式
- RWO：ReadWriteOnce，仅允许当个节点挂载进行读写；
- ROX：ReadOnlyMany，允许多个节点挂载且只读；
- RWX：ReadWriteMany，允许多个节点挂载进行读写；
