k8s系列第七篇~k8s资源对象-存储类资源对象

第三篇~第六篇文章主要带大家了解了应用类资源对象，本文将带大家学习存储类资源对象。存储类资源对象主要包括Volume、Persistent Volume、PVC和StorageClass。

一、存储资源对象-Volume

Volume是pod中能够被多个容器访问的共享目录。K8s中的Volume与docker的Volume类似，但是二者不能等价。

• K8s中的Volume被定义在pod上，被一个pod里的多个容器挂载到具体的文件目录下。
• k8s中的Volume与pod的生命周期相同，与容器的生命周期不相关（当容器终止或重启时，Volume中的数据不会丢失）。
• k8s支持多种类型的Volume，例如GlustreFS、Ceph等文件系统。

Volume的使用也比较简单，在大多数情况下，先在pod上声明一个Volume，然后在容器里引用该Volume并将其挂载到容器的某个目录下，Volume资源对象定义示例如下：

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

k8s提供了丰富的Volume类型供容器使用，例如临时目录、宿主机目录、共享存储等，下面对常用的类型进行说明。

一个emptyDir是在pod被分配到node时创建的，初始内容为空，无需指定宿主机上对应的目录文件，k8s自动分配一个目录，当pod从node上移除时，emptyDir中的数据也被永久删除。

• 临时空间，例如用于某些应用程序运行时所需的临时目录，且无须永久保留。

• 长时间任务执行过程中使用的临时目录。

• 一个容器需要从另一个容器获取数据的目录（多容器共享目录）。

默认情况下，emptyDir使用的是节点存储介质，例如磁盘或者网络存储。可以使用emptyDir.medium属性设置为Memory，就可以使用更快的基于内存的后端存储，这种情况emptyDir使用的内存会被计入容器的内存消耗，受资源限制和配额机制的影响。

2、 hostPath

hostPath为在pod上挂载宿主机上的文件或目录，可以用于以下几方面：

• 在容器应用程序生成的日志文件需要永久保存时，可以使用宿主机的高速文件系统对其进行存储。

• 需要访问宿主机上Docker引擎内部数据结构的容器应用时，可以通过定义hostPath为宿主机/var/lib/docker目录，使容器内部的应用可以直接访问docker的文件系统。

注意事项：

• 不同node上具有相同配置的pod，可能会因为宿主机上的文件和目录不同，导致对Volume上的目录和文件访问结果不一致。

• 如果使用了资源配额管理，k8s无法将hostPath在宿主机上使用的资源纳入管理。

下面的示例是使用宿主机上的/data目录定义了一个hostPath类型的Volume：

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:
      # 宿主上目录位置
      path: /data
      # 此字段为可选
      type: Directory

公有云提供的Volume类型包括谷歌公有云、亚马逊公有云等，我们的k8s集群运行在公有云上或者使用公有云厂家提供的k8s集群时，可以使用这类的Volume。

iscsi：将ISCSI存储设备上的目录挂载到pod中

nfs：将NFS Server上的目录挂载到pod中

glusterfs：将开源GlusterFS网络文件系统的目录挂载到pod中

rbd：将Ceph块设备共享存储（Rados Block Device）挂载到pod中

gitRepo：通过挂载一个空目录，并从Git库克隆一个git Repository以供pod使用

ConfigMap：将配置数据挂载为容器内的文件

Secret：将Secret数据挂载为容器内的文件

Volume属于静态管理的存储，即我们需要事先定义每个Volume，然后将其挂载到pod中去用，这种方式存在弊端：配置参数繁琐，存在大量手工操作，违背了k8s自动化的追求目标；预定义的静态Volume可能不符合目标应用的需求，比如容量、性能问题。

K8s提供了存储动态化的机制，实现存储的自动化管理，相关核心概念：Persistent Volume（PV）、StorageClass、PVC。

PV表示由系统动态创建的一个存储，可以理解成k8s集群中某个网络存储对应的一块存储，与Volume类似，但是不被定义在pod上，独立于pod之外定义。PV目前支持的类型主要有gcePersistentDisk、awsElasticBlockStore、Cinder、Glusterfs、rbd、Azure File、Azure Disk、Portworx、FlexVolumes CSI、NFS、ISCSI、hostPath、local等。

K8s支持的存储系统有多种，那么系统使用那种规格的pv存储卷由什么决定？这就涉及StorageClass和PVC。StorageClass用来描述和定义某种存储系统的特征，示例如下：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
reclaimPolicy: Retain
allowVolumeExpansion: true
mountOptions:
  - debug
volumeBindingMode: Immediate

核心参数说明：

StorageClass的名称会在PVC中出现，下面是PVC的示例：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: standard
  selector:
    matchLabels:
      release: "stable"
    matchExpressions:
      - {key: environment, operator: In, values:[dev]}

PVC表示应用希望申请的pv规格，重要的属性：accessModes（存储访问模式）、storageClassName（用那种storageClass来实现动态创建）、resources（存储的具体规格）。

有了PV、StorageClass、PVC就很容易使用和管理Volume了，只要在pod中引用pvc即可达到目的，pod中引用pvc示例如下：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim