前言:
容器磁盘上的文件的生命周期是短暂的,这就使得在容器中运行重要应用时会出现一些问题。首先,当容器崩溃时,kubelet 会重启它,但是容器中的文件将丢失——容器以干净的状态(镜像最初的状态)重新启动。其次,在Pod中同时运行多个容器时,这些容器之间通常需要共享文件。Kubernetes 中的Volume抽象就很好的解决了这些问题
1、背景
Kubernetes 中的卷有明确的寿命 —— 与封装它的 Pod 相同。所f以,卷的生命比 Pod 中的所有容器都长,当这个容器重启时数据仍然得以保存。当然,当 Pod 不再存在时,卷也将不复存在。也许更重要的是,Kubernetes支持多种类型的卷,Pod 可以同时使用任意数量的卷
2、卷的类型
Kubernetes支持以下类型的卷
- awsElasticBlockStore
- azureDisk
- azureFile
- cephfs
- configMap
- csi
- downwardAPI
- emptyDir
- fc (fibre channel)
- flocker
- gcePersistentDisk
- gitRepo (deprecated)
- glusterfs
- hostPath
- iscsi
- local
- nfs
- persistentVolumeClaim
- projected
- portworxVolume
- quobyte
- rbd
- scaleIO
- secret
- storageos
- vsphereVolume
3、常见存储类型说明及示例
cephfs
cephfs是一款优秀、流行的云环境存储解决方案,原因是它开源、高可用、弹性伸缩,对操作系统、硬件无特殊要求,用户很容易搭建,使用它的节点也无特别要求。它具备awsElasticBlockStore陈述之所有特点,并且单个voluem可以被多个节点同时使用。用户首先搭建自己的cephfs环境,然后配置kubernetes集群与其对接,最后在pod中使用其提供的volume,详细参考这里。
configMap
用户首先创建configMap并创建数据保存其中,此时数据保存在kubernetes的etcd数据库中,volume还不存在。当用户在pod中引用创建的configMap时,系统首先在节点上创建volume并将数据保存其中,这个volume占用的是节占的存储空间。此后就可以像使用普通volume一样使用它。
configMap是kubernetes中的一种对象类型,核心本质是以volume的方式将单独管理的配置信息传递给pod中的容器,并非用来存储持久化数据。详细参考这里。
downwardAPI
与configMap类似,以volume的方式向pod中的容器传递信息。configMap中的信息由用户在创建对象时传递,而downwardAPI的信息就来自pod对象本身,downwardAPI不需要创建,它是pod Spec中的一个字段,内容指向pod对象本身的其它字段,如pod的metadata、image等信息。在创建pod时系统首先将指向的字段提取出来,然后创建volume并保存提取出来的字段并挂载,容器就可以读取这些字段了。
downwardAPI的目的是为将pod本身的字段信息如label、annotation等传递给容器的一种手段。详细参考这里。
glusterfs
与cephfs一样,流行的云环境下的存储解决方案,详细参考这里,示例参考这里。
emptyDir
当 Pod 被分配给节点时,首先创建emptyDir卷,并且只要该 Pod 在该节点上运行,该卷就会存在。正如卷的名字所述,它最初是空的。Pod 中的容器可以读取和写入emptyDir卷中的相同文件,尽管该卷可以挂载到每个容器中的相同或不同路径上。当出于任何原因从节点中删除 Pod 时,emptyDir中的数据将被永久删除
注意:容器崩溃不会从节点中移除Pod,因此emptyDir卷中的数据在容器崩溃时是安全的。
emptyDir的用法有:
- ①暂存空间,例如用于基于磁盘的合并排序
- ②用作长时间计算崩溃恢复时的检查点
- ③Web服务器容器提供数据时,保存内容管理器容器提取的文件
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: k8s.gcr.io/test-webserver
name: test-container
volumeMounts:
- mountPath: /cache
name: cache-volume
volumes:
- name: cache-volume
emptyDir: {}
hostPath
hostPath卷将主机节点的文件系统中的文件或目录挂载到集群中
hostPath的用途如下:
- 运行需要访问 Docker 内部的容器;使用/var/lib/docker的hostPath
- 在容器中运行 cAdvisor;使用/dev/cgroups的hostPath
- 允许 pod 指定给定的 hostPath 是否应该在 pod 运行之前存在,是否应该创建,以及它应该以什么形式存在
除了所需的path属性之外,用户还可以为hostPath卷指定type
| 值 | 行为 |
|---|---|
| 空字符串(默认)用于向后兼容,这意味着在挂载 hostPath 卷之前不会执行任何检查 | |
| DirectoryOrCreate | 如果在给定的路径上没有任何东西存在,那么将根据需要在那里创建一个空目录,权限设置为0755,与Kubelet具有相同的组和所有权。 |
| Directory | 给定的路径下必须存在目录 |
| FileOrCreate | 如果在给定的路径上没有任何东西存在,那么会根据需要创建一个空文件,权限设置为0644,与Kubelet具有相同的组和所有权。 |
| File | 给定的路径下必须存在文件 |
| Socket | 给定的路径下必须存在UNIX套接字 |
| CharDevice | 给定的路径下必须存在字符设备 |
| BlockDevice | 给定的路径下必须存在块设备 |
使用这种卷类型是请注意,因为:
- 由于每个节点上的文件都不同,具有相同配置(例如从 podTemplate 创建的)的 pod 在不同节点上的行为可能会有所不同
- 当 Kubernetes 按照计划添加资源感知调度时,将无法考虑hostPath使用的资源
- 在底层主机上创建的文件或目录只能由 root 写入。您需要在特权容器中以 root 身份运行进程,或修改主机上的文件权限以便写入hostPath卷
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: k8s.gcr.io/test-webserver
name: test-container
volumeMounts:
- mountPath: /test-pd
name: test-volume
volumes:
- name: test-volume
hostPath:
# directory location on host
path: /data
# this field is optional type: Directory
type: Directory
iscsi
互联网小型计算机系统接口,其特点是便宜。示例参考这里。
local
与emptyDir相似,它也占用节点的存储空间。不同点是它是kubernetes中的一种对象类型,用户可以像管理普通对象一样管理它。emptyDir在pod实例开时运行时分配,当pod离节点时删除。local类型的volume则由用户创建,系统在合适的节点上为其分配资源,调度到这个节点上的pod可以挂载它,pod离开时它也不会消失,除非用户删除。示例:
apiVersion: v1
kind: PersistentVolume
metadata:
name: example-pv
spec:
capacity:
storage: 100Gi
# volumeMode field requires BlockVolume Alpha feature gate to be enabled.
volumeMode: Filesystem
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Delete
storageClassName: local-storage
local:
path: /mnt/disks/ssd1
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- example-node
nfs
nfs网络文件系统,详细参考这里。
persistentVolumeClaim
与flocker相似,用来屏蔽不同云环境,详细参考这里。
projected
如果一个容器需要挂开多个已经存在的volume比如Secret、ConfigMap、DownwardAPI等,原本每个这种类型的volume需要各自占用一个挂载目录,而projected能将它们整合在一起,并只挂开到一个目录下,示例:
apiVersion: v1
kind: Pod
metadata:
name: volume-test
spec:
containers:
- name: container-test
image: busybox
volumeMounts:
- name: all-in-one
mountPath: "/projected-volume"
readOnly: true
volumes:
- name: all-in-one
projected:
sources:
- secret:
name: mysecret
items:
- key: username
path: my-group/my-username
- downwardAPI:
items:
- path: "labels"
fieldRef:
fieldPath: metadata.labels
- path: "cpu_limit"
resourceFieldRef:
containerName: container-test
resource: limits.cpu
- configMap:
name: myconfigmap
items:
- key: config
path: my-group/my-config