Kubernetes & Volume & Persistent Volume

Kubernetes & Volume & Persistent Volume

一、Volume

Volume(存储卷)是Pod中能够被多个容器访问的共享目录。

KubernetesVolume概念、用途和目的与Docker的Volume比较类似,但两者不能等价。首先,Kubernetes中的Volume被定义在Pod上,然后被一个Pod里的多个容器挂载到具体的文件目录下;

其次,Kubernetes中的Volume与Pod的生命周期相同,但与容器的生命周期不相关,当容器终止或者重启时,Volume中的数据也不会丢失。

最后,Kubernetes支持多种类型的Volume,例如GlusterFSCeph等先进的分布式文件系统。

Volume的使用也比较简单,在大多数情况下,我们先在Pod上声明一个Volume,然后在容器里引用该Volume并挂载(Mount)到容器里的某个目录上。

Kubernetes提供了非常丰富的Volume类型,下面逐一进行说明。

1.emptyDir

一个emptyDir Volume是在Pod分配到Node时创建的。从它的名称就可以看出,它的初始内容为空,并且无须指定宿主机上对应的目录文件,因为这是Kubernetes自动分配的一个目录,当Pod从Node上移除时,emptyDir中的数据也会被永久删除。emptyDir的一些用途如下。

  • ◎ 临时空间,例如用于某些应用程序运行时所需的临时目录,且无须永久保留。
  • ◎ 长时间任务的中间过程CheckPoint的临时保存目录。
  • ◎ 一个容器需要从另一个容器中获取数据的目录(多容器共享目录)。

目前,用户无法控制emptyDir使用的介质种类。如果kubelet的配置是使用硬盘,那么所有emptyDir都将被创建在该硬盘上。Pod在将来可以设置emptyDir是位于硬盘、固态硬盘上还是基于内存的tmpfs上。

2.hostPath

hostPath为在Pod上挂载宿主机上的文件或目录,它通常可以用于以下几方面。

  • ◎ 容器应用程序生成的日志文件需要永久保存时,可以使用宿主机的高速文件系统进行存储。
  • ◎ 需要访问宿主机上Docker引擎内部数据结构的容器应用时,可以通过定义hostPath为宿主机/var/lib/docker目录,使容器内部应用可以直接访问Docker的文件系统。

在使用这种类型的Volume时,需要注意以下几点。

  • ◎ 在不同的Node上具有相同配置的Pod,可能会因为宿主机上的目录和文件不同而导致对Volume上目录和文件的访问结果不一致。
  • ◎ 如果使用了资源配额管理,则Kubernetes无法将hostPath在宿主机上使用的资源纳入管理。

3.gcePersistentDisk

使用这种类型的Volume表示使用谷歌公有云提供的永久磁盘(Persistent Disk,PD)存放Volume的数据,它与emptyDir不同,PD上的内容会被永久保存,当Pod被删除时,PD只是被卸载(Unmount),但不会被删除。需要注意的是,你需要先创建一个PD,才能使用gcePersistentDisk

使用gcePersistentDisk时有以下一些限制条件。

  • ◎ Node(运行kubelet的节点)需要是GCE虚拟机。
  • ◎ 这些虚拟机需要与PD存在于相同的GCE项目和Zone中。

4.awsElasticBlockStore

与GCE类似,该类型的Volume使用亚马逊公有云提供的EBS Volume存储数据,需要先创建一个EBS Volume才能使用awsElasticBlockStore

使用awsElasticBlockStore的一些限制条件如下。

  • ◎ Node(运行kubelet的节点)需要是AWS EC2实例。

  • ◎ 这些AWS EC2实例需要与EBS Volume存在于相同的regionavailability-zone中。

  • ◎ EBS只支持单个EC2实例挂载一个Volume。

5.NFS

使用NFS网络文件系统提供的共享目录存储数据时,我们需要在系统中部署一个NFS Server。

6.其他类型Volume

  • ◎ iscsi:使用iSCSI存储设备上的目录挂载到Pod中。

  • ◎ flocker:使用Flocker管理存储卷。

  • ◎ glusterfs:使用开源GlusterFS网络文件系统的目录挂载到Pod中。

  • ◎ rbd:使用Ceph块设备共享存储(Rados Block Device)挂载到Pod中。

  • ◎ gitRepo:通过挂载一个空目录,并从Git库clone一个git repository以供Pod使用。

  • ◎ secret:一个Secret Volume用于为Pod提供加密的信息,你可以将定义在Kubernetes中的Secret直接挂载为文件让Pod访问。Secret Volume是通过TMFS(内存文件系统)实现的,这种类型的Volume总是不会被持久化的

二、Persistent Volume

之前提到的Volume是被定义在Pod上的,属于计算资源的一部分,而实际上,网络存储是相对独立于计算资源而存在的一种实体资源。比如在使用虚拟机的情况下,我们通常会先定义一个网络存储,然后从中划出一个“网盘”并挂接到虚拟机上。Persistent Volume(PV)和与之相关联的Persistent Volume Claim(PVC)也起到了类似的作用。

PV可以被理解成Kubernetes集群中的某个网络存储对应的一块存储,它与Volume类似,但有以下区别。

  • ◎ PV只能是网络存储,不属于任何Node,但可以在每个Node上访问。

  • ◎ PV并不是被定义在Pod上的,而是独立于Pod之外定义的。

  • ◎ PV目前支持的类型包括:gcePersistentDisk、AWSElasticBlockStore、AzureFile、AzureDisk、FC(Fibre Channel)、Flocker、NFS、iSCSI、RBD(Rados Block Device)、CephFS、Cinder、GlusterFS、VsphereVolume、Quobyte Volumes、VMware Photon、Portworx Volumes、ScaleIO Volumes和HostPath

比较重要的是PV的accessModes属性,目前有以下类型。

  • ◎ ReadWriteOnce:读写权限,并且只能被单个Node挂载。
  • ◎ ReadOnlyMany:只读权限,允许被多个Node挂载。
  • ◎ ReadWriteMany:读写权限,允许被多个Node挂载。

最后说说PV的状态。PV是有状态的对象,它的状态有以下几种。

  • ◎ Available:空闲状态。
  • ◎ Bound:已经绑定到某个PVC上。
  • ◎ Released:对应的PVC已经被删除,但资源还没有被集群收回。
  • ◎ Failed:PV自动回收失败。
posted @ 2020-08-05 15:09  roverliang  阅读(414)  评论(0编辑  收藏  举报