kubernetes基础知识之存储volume类型和emptyDir

kubernetes中downward API可以获取本pod相关的一些元数据信息。

downward API的使用案例：比如在pod中去运行一个golang的应用程序，它会根据当前的核心数量去调整我们的协程上级管理进程的数量。所以这种情况下，如果CPU数量跟真实的情况不相符的话，那会影响性能，还有Java它的内存的关系。所以这种情况下，我们可以通过思想或者手段去将真实的可用的资源量，传递到pod内部，或者pod内部容器内。

如果这些元数据还不够用，那我们可以通过扩展，通过apiserver访问的方式，去实现我们对应的元数据的调取，这样可以实现跨pod甚至乃至于跨命名空间的元数据调取。

Configmap、secret、downward api 它们本质上是元数据的一种存储方式，而不是真正的去存储，真实数据的存储应该用volume等方式存储。

一般yaml文件中volume的定义是：

volumeMounts:

-name: xxx

mountPath: /$path

volumes:

-name: xxx

emptyDir: {}

Volume支持多种类型卷，比如emptyDir、hostPath、configMap等，但是挂载路径根据卷类型和挂载需求去设置。

volumeMounts依赖于pod中通过volumes字段定义的卷，不能独立存在。

volume存在的意义：

容器磁盘上的文件的生命周期是短暂的，这就使得在容器中运行重要应用时会出现一些问题。首先，当容器崩溃时，kubelet会重启它。但是容器中的文件将丢失，容器以干净的状态也就是容器镜像最初的状态来重新启动。其次，在pod 中同时运行多个容器时，这些容器之间通常需要共享文件。kubernetes中的volume 抽象就很好地解决了这些问题。

存储的分类：

①：emptyDir

②：hostPath

③：PersistentVolume(PV)和PersistentVolumeClaim(PVC)

④：ConfigMap和Secret

⑤：NFS

⑥：CephFS和RBD（Ceph Block Device）

⑦：ISCSI，GlusterFS、Azure File、AWS EBS（Elastic Block Store）

⑧：CSI（Container Storage Interface）

Volume可以解决两个问题：

1.pod内部容器重建，导致的文件丢失问题。

2.pod内部多容器间实现文件共享的问题。

存储卷的分类：

1.awsElasticBlockStore

2.azureDisk

3.azureFile

4.cephfs

5.csi

6.downwardAPI

7.emptyDir

8.fc

9.flocker

10.gcePersistentDisk

11.gitRepo

12.glusterfs

13.hostPath

14.iscsi

15.local

16.nfs

17.persistentVolumeClaim

18.projected

19.portworxVolume

20.quobyte

21.rbd

22.scaleIO

23.secret

24.storageos

25.vsphereVolume

awsElasticBlockStore是亚马逊的持久化存储，

azureDisk是微软云的块存储，

azureFile是微软云的文件存储，

CSI是Container Storage Interface容器存储接口。现在跑的软件应用，或者分布式存储，都会对接到CSI，给容器提供一个存储的能力。

很多kubernetes的存储方式都是主动对接过去，可是CSI是k8s的pod去主动暴露一个接口，然后对端的共享文件系统来对接到CSI的接口，以此来对接到pod。

hostPath叫主机路径，就是把容器跟主机的一个目录去进行绑定映射。可以将hostPath做中间层，将任意的分布式存储或者稳定的文件系统引用到容器内部。比如有多个kubernetes worker node节点，比如后端运行了一个MFS。在这种情况下，可以挂载后端的MFS到比如节点根下的MFS目录下。挂载到根下的MFS目录下，然后让MFS文件系统与kubernetes worker node节点进行关联，所有的分布式存储和网络存储都支持Linux系统，我们在kubernetes worker node节点上运行pod，pod内部的某个容器需要去使用MFS存储，可以让pod中的容器以主机路径的方式往物理机根下的MFS目录去绑定，实际上是等同于使用背后的MFS分布式存储。没有一个问题不是中间件解决不了的，如果不够用的话那就来多几个中间件。就是说可以用中间层的方式，帮我们去做转换。

国内的很多云厂商都兼容亚马逊的AWS Elastic Block Store对应的接口。

emptyDir它可以用做pod内部的多容器间的文件共享问题。

hostPath它完全可以充当一个后端的共享存储和容器之间的中间层的作用。

emptyDir:

当pod被分配给节点时，首先创建emptyDir卷。并且只要该pod在这个节点上运行，那么这个卷就会存在。正如卷的名字所述，它最初是空的。pod中的容器可以读取和写入emptyDir卷中的相同文件，尽管这个卷可以挂载到每个容器中的相同或者不同路径上。当出于任何原因从节点中删除pod时，emptyDir中的数据被永久删除。

容器崩溃不会从节点中移除pod，因此emptyDir卷中的数据在容器崩溃时是安全的。

emptyDir的用法有：

①：暂存空间，例如用于基于磁盘的合并排序、用作长时间计算崩溃恢复时的检查点。

②：web服务器容器提供数据时，保存内容管理器容器提取的文件。

emptyDir绑定的生命周期是pod，而不是容器级别的。pod创建，此卷存在；pod删除，此卷消失，emptyDir类型的卷和pod的生命周期是一致的，绑定的并不是pod内部的容器。

emptyDir类型的卷生命周期是pod级别，跟pod是关联的，并不是跟内部容器关联。

容器崩溃，不会从节点中移除pod，因此emptyDir卷中的数据在容器崩溃时是安全的，因为它的生命周期和pod绑定。

假如说有一个pod，这个pod里面有一个init container，远程有一个git仓库，需求是：希望init container能够从git仓库中将代码提取出来，然后放入main container中，去将当前的代码运行起来。当main Container出现的时候，init container已经完成了初始化，这种情况下，就可以借助一个emptyDir。首先从git仓库中将代码拉取出来，然后emptyDir会挂载到当前init Container的某个目录里，这样的话，我们可以把下载的代码放在一个共享路径里。接着再将emptyDir卷共享给main Container。这个main Container启动的时候，就可以基于这个共享卷中的代码去实现运行。

鼓励的话语：沧海横流显砥柱，万山磅礴看主峰！