k8s存储卷

简介

存储卷是定义在Pod之上的可被其内部所有容器挂载是使用的共享目录，该目录实际上是宿主机或外部存储设备之上的存储空间，可以被Pod内的多个容器挂载使用。存储卷独立与Pod的生命周期，因此它存储的数据可以在容器重启或重建后继续使用。

目前k8s支持的存储卷可以大致分为一下几类，它们各自有着不同的实现插件：

1. 临时存储卷：emptyDir
2. 本地存储卷：hostPath
3. 网络存储卷：nfs、cinder、rbd、iscsi等
4. 特殊存储卷：configmap、secret
5. 扩展支持第三方存储的存储接口：CSI

通常k8s内置的存储卷插件可以归类为In-Tree类型，它们通k8s源码一起发布迭代，而由存储厂商借助CSI接口扩展的独立于k8s源码的插件统称为Out-of-Tree类型，集群管理员可以根据需要创建自定义的扩展插件，CSI是比较常用的实现方式。目前k8s已经开始逐步将In-Tree类型的存储卷插件迁移到CSI，所以建议在新环境中使用CSI。

emptyDir存储卷

emptyDir存储卷可以看作是Pod上的一个临时目录，其生命周期和Pod相同，Pod创建时被创建，Pod删除时被删除，通常用于数据缓存和临时存储。
emptyDir存储卷定义在Pod资源的spec.volumes.emptyDir字段，可嵌套使用的字段有两个：

• medium：用于指定emptyDir存储卷使用的存储介质，可用值为default和Memory，默认是default表示使用节点的默认存储介质(磁盘)；Memory表示使用基于内存的临时文件系统tmpfs，可用空间受限于内存，但性能很好，一般用于缓存
• sizeLimit ：当前存储卷的空间限额，默认为nil，不限制

apiVersion: apps/v1
kind: Deployment
metadata:
  name: volume-emptydir-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: volume-emptydir-demo
  template:
    metadata:
      labels:
        app: volume-emptydir-demo
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 80
        volumeMounts:
        - name: cache-volume
          mountPath: /cache
      volumes:
      - name: cache-volume
        emptyDir:
          medium: Memory
          sizeLimit: 128Mi

进入Pod验证

emptyDir其实就是node节点上的一个目录，它存放在 /var/lib/kubelet/pods//volumes/kubernetes.io~empty-dir/ 下

hostPath存储卷

hostPath是将工作节点上的目录或文件关联到Pod上的一种卷类型，类似于Docker的bind mount，hostPath卷的生命周期和工作节点相同。hostPath存储卷在Pod需要访问节点上的文件时很有用。

hostPath存储卷定义在Pod资源的spec.volumes.hostPathz字段，可嵌套使用的字段有两个：

• path ：用于指定工作节点上的目录路径
• type ：用于指定工作节点之上的存储类型

关于type字段，目前支持的值有下面这些：

• DirectoryOrCreate：指定的目录不存在时，自动将其创建为0755权限的空目录，属主和属组都为kubelet
• Directory：事先必须存在的目录
• FileOrCreate：指定的不存在时，自动将其创建为0644权限的空文件，属主和属组都为kubelet
• File：事先必须存在的文件
• Socket：事先必须存在的Socket文件
• CharDevice：事先必须存在的字符设备路径
• BlockDevice：事先必须存在的文件设备路径
• “”：空字符串，默认值，用于向后兼容，在关联hostPath卷之前不进行任何检查

apiVersion: apps/v1
kind: Deployment
metadata:
  name: volume-hostpath-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: volume-hostpath-demo
  template:
    metadata:
      labels:
        app: volume-hostpath-demo
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 80
        volumeMounts:
        - name: cache-volume
          mountPath: /cache
      volumes:
      - name: cache-volume
        hostPath:
          path: /data/kubernetes

进入Pod创建一个文件

在主机上验证文件是否存在

网络存储卷

k8s内置了多种类型的网络存储插件，它们支持的存储服务包括传统的NAS或SAS设备，以及分布式存储、云存储等。网络存储卷的生命周期可以超出工作节点的生命周期，存储卷的回收由集群管理员手动处理，存储的数据可以被Pod重复使用。

下面以NFS存储卷为例进行演示，其它网络存储卷的使用可以参考：https://kubernetes.io/docs/concepts/storage/volumes/

NFS存储卷

nfs存储卷可以将现有的nfs-server上的存储空间挂载到Pod中使用。当删除Pod时，nfs存储卷的内容会被保留，卷仅是被卸载而不是删除。而且NFS是文件系统级共享服务，支持被多个Pod挂载使用。定义NFS存储卷时支持嵌套使用3个字段：

• server：NFS Server的地址或域名
• path：NFS Server共享的目录
• readOnly：是否以只读方式挂载，默认false

首先安装一下nfs-server，地址是192.168.122.1

apt -y install nfs-server
mkdir -p /data/k8s

vim /etc/exports
/data/k8s *(rw,no_root_squash,subtree_check)

exportfs -r
showmount -e 192.168.122.1

所有k8s工作节点都要安装nfs客户端

apt -y install nfs-common

nfs存储卷示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: volume-nfs-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: volume-nfs-demo
  template:
    metadata:
      labels:
        app: volume-nfs-demo
    spec:
      containers:
      - name: nginx
        image: nginx
        volumeMounts:
        - name: nfs-volume
          mountPath: /usr/share/nginx/html/mysite
      volumes:
      - name: nfs-volume
        nfs:
         server: 192.168.122.1
         path: /data/k8s

等Pod创建之后，在nfs共享目录写入一个文件，然后访问nginx验证

PV和PVC

PV和PVC介绍

PV是由k8s集群管理员在全局级别配置的存储卷，它通过支持的存储卷插件及给定的配置参数关联到指定存储系统的存储空间，这个的存储空间可能是ceph rbd-image、nfs共享的目录和cephfs文件系统等，也就是说PV的数据最终是保存在后端的存储系统上的。PV将存储系统上的存储空间抽象为集群级别的API资源，由管理员负责创建维护。

将PV提供的存储空间用于Pod对象存储卷时，用户需要先在namespace中创建PVC资源声明需要的存储空间大小和访问模式等属性，接下来PV控制器会选择合适的PV与PVC进行绑定。随后，在Pod资源中通过persistenVolumeCliam卷插件指定要使用的PVC对象就可以使用这个PVC绑定的PV的存储空间。

总结来说，PV和PVC就是在用户和存储系统之间添加的一个中间层，管理员事先定义好PV，用户通过PVC声明要使用的存储特性来绑定符合条件的最佳PV，从而实现了用户和存储系统之间的解耦，用户不需要了解存储系统的具体使用方式，只需要定义PVC就可以。

PV生命周期

PV生命周期中存在几个状态，创建后未正确关联到存储设备的PV处于Pending状态，直到成功关联后转为Available状态。之后如果该PV被PVC绑定后转为Bound状态，直到相应的PVC被删除后会自动解除绑定，PV的状态转换为Released，随后PV的去向将由其回收策略决定。目前PV支持的回收策略有如下3种：

1. Delete：删除PVC后，删除其所绑定的PV和PV关联的存储设备
2. Retain：默认策略，删除PVC后将保留其所绑定的PV和存储的数据，但会将PV至于Released状态，此时PV不能被其它PVC绑定使用，需要管理员执行后续回收操作
3. Recycle（已废弃）：删除PVC时其所绑定的PV上存储的数据会被清空，而后PV转为Available状态，可以再次被其它PVC绑定使用，此策略已废弃

相对应的，PVC在创建之后也处于Pending状态，成功绑定PV后转为Bound状态，被删除后处于Deleted状态

静态PV

PV资源的spec字段可以嵌套使用下面这些字段：