系列目录

Volume是对各种存储资源的抽象、虚拟化。为管理、控制、使用存储资源提供统一接口。Openstack中的volume为虚拟机提供存储，Docker中的volume为容器提供存储。因为在kubernetes中可部署运行最小单位是pod ,所以kubernetes的volume为pod提供存储。当然在部署pod时可以不为其提供volume，pod中的容器使用所在节点的硬盘，能同时读写数据的地方称为可读写层。这种存储是容器级的临时存储，不是pod级。其生命周期与容器相同，如果容器crash后被重启，也就是旧容器被删除而新容器启动，则旧容器的可读写层与容器一起被删除，其上数据丢失。同理如果pod在节点之间迁移调度，容器的可读写层并不会迁移调度。因此，kubernetes需要提供pod级volume，本文中的volume特指kubernetes。

Volume类型
Volume是抽象概念，有很多种具体实现，每种实现各具目的、特点、特性。差不多什么东西都可以当成volume，类型如下：

  • 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

这里不对以上所有类型一一介绍,只对目前可能会用到的本地磁盘存储和分布式存储做简单介绍说明

cephfs是一款优秀、流行的云环境存储解决方案，原因是它开源、高可用、弹性伸缩，对操作系统、硬件无特殊要求，用户很容易搭建，使用它的节点也无特别要求。它具备awsElasticBlockStore陈述之所有特点，并且单个voluem可以被多个节点同时使用。用户首先搭建自己的cephfs环境，然后配置kubernetes集群与其对接，最后在pod中使用其提供的volume，详细参考这里。

用户首先创建configＭap并创建数据保存其中，此时数据保存在kubernetes的etcd数据库中，volume还不存在。当用户在pod中引用创建的configMap时，系统首先在节点上创建volume并将数据保存其中，这个volume占用的是节占的存储空间。此后就可以像使用普通volume一样使用它。

configMap是kubernetes中的一种对象类型，核心本质是以volume的方式将单独管理的配置信息传递给pod中的容器，并非用来存储持久化数据。详细参考这里。

与configＭap类似，以volume的方式向pod中的容器传递信息。configMap中的信息由用户在创建对象时传递，而downwardAPI的信息就来自pod对象本身，downwardAPI不需要创建，它是pod Spec中的一个字段，内容指向pod对象本身的其它字段，如pod的metadata、image等信息。在创建pod时系统首先将指向的字段提取出来，然后创建volume并保存提取出来的字段并挂载，容器就可以读取这些字段了。

downwardAPI的目的是为将pod本身的字段信息如label、annotation等传递给容器的一种手段。详细参考这里。

在节点上运行pod实例时才会创建emptyDir volume。它首先是节点上的一个空目录，pod中的任何容器都可以用volume的形式挂载使用它。如果容器因为某种原因被删除并重新启动，创建的emptyDir不会删除也不会被清空。当pod实例离开节点调度到其它节点或因为缩容被删除时，emptyDir被删除，相当于pod还在但数据丢了。示例：

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: test-pd
  5. spec:
  6.   containers:
  7.   - image: k8s.gcr.io/test-webserver
  8.     name: test-container
  9.     volumeMounts:
  10.     - mountPath: /cache
  11.       name: cache-volume
  12.   volumes:
  13.   - name: cache-volume
  14.     emptyDir: {}

与cephfs一样，流行的云环境下的存储解决方案，详细参考这里，示例参考这里。

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: test-pd
  5. spec:
  6.   containers:
  7.   - image: k8s.gcr.io/test-webserver
  8.     name: test-container
  9.     volumeMounts:
  10.     - mountPath: /test-pd
  11.       name: test-volume
  12.   volumes:
  13.   - name: test-volume
  14.     hostPath:
  15.       # directory location on host
  16.       path: /data
  17.       # this field is optional
  18.       type: Directory

互联网小型计算机系统接口，其特点是便宜。示例参考这里。

与emptyDir相似，它也占用节点的存储空间。不同点是它是kubernetes中的一种对象类型，用户可以像管理普通对象一样管理它。emptyDir在pod实例开时运行时分配，当pod离节点时删除。local类型的volume则由用户创建，系统在合适的节点上为其分配资源，调度到这个节点上的pod可以挂载它，pod离开时它也不会消失，除非用户删除。示例：

  1. apiVersion: v1
  2. kind: PersistentVolume
  3. metadata:
  4.   name: example-pv
  5. spec:
  6.   capacity:
  7.     storage: 100Gi
  8.   # volumeMode field requires BlockVolume Alpha feature gate to be enabled.
  9.   volumeMode: Filesystem
  10.   accessModes:
  11.   - ReadWriteOnce
  12.   persistentVolumeReclaimPolicy: Delete
  13.   storageClassName: local-storage
  14.   local:
  15.     path: /mnt/disks/ssd1
  16.   nodeAffinity:
  17.     required:
  18.       nodeSelectorTerms:
  19.       - matchExpressions:
  20.         - key: kubernetes.io/hostname
  21.           operator: In
  22.           values:
  23.           - example-node

nfs
网络文件系统，详细参考这里。

与flocker相似，用来屏蔽不同云环境，详细参考这里。

如果一个容器需要挂开多个已经存在的volume比如Secret、ConfigMap、DownwardAPI等，原本每个这种类型的volume需要各自占用一个挂载目录，而projected能将它们整合在一起，并只挂开到一个目录下，示例：

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: volume-test
  5. spec:
  6.   containers:
  7.   - name: container-test
  8.     image: busybox
  9.     volumeMounts:
  10.     - name: all-in-one
  11.       mountPath: "/projected-volume"
  12.       readOnly: true
  13.   volumes:
  14.   - name: all-in-one
  15.     projected:
  16.       sources:
  17.       - secret:
  18.           name: mysecret
  19.           items:
  20.             - key: username
  21.               path: my-group/my-username
  22.       - downwardAPI:
  23.           items:
  24.             - path: "labels"
  25.               fieldRef:
  26.                 fieldPath: metadata.labels
  27.             - path: "cpu_limit"
  28.               resourceFieldRef:
  29.                 containerName: container-test
  30.                 resource: limits.cpu
  31.       - configMap:
  32.           name: myconfigmap
  33.           items:
  34.             - key: config
  35.               path: my-group/my-config

版权声明：本文为tylerzhou原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://www.cnblogs.com/tylerzhou/p/11001617.html