kubernetes对象之Volume

系列目录

概述

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

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

configMap

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

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

downwardAPI

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

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

emptyDir

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

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: {}

glusterfs

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

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

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