k8s学习-持久化存储（Volumes、hostPath、emptyDir、PV、PVC）详解与实战

---

概念

Volumes

容器中的磁盘文件是短暂的，容器崩溃后，再次重启，数据就丢失了。k8s通过volumes进行数据持久化和共享数据。volumes的本质就是一个目录。volume有很多类型，有些已经弃用了，这里提几个还在用的。

ConfigMap && Secret

之前介绍过，可以查看下面的文章：
k8s学习-ConfigMap（创建、使用、更新、删除等）
k8s学习-Secret（创建、使用、更新、删除等）

hostPath

hostPath卷能将主机节点文件系统上的文件或目录挂载到你的 Pod 中。
hostPath卷存在许多安全风险，最佳做法是尽可能避免使用hostPath。 当必须使用hostPath 卷时，它的范围应仅限于所需的文件或目录，并以只读方式挂载。

如果通过 AdmissionPolicy 限制hostPath 对特定目录的访问，则必须要求 volumeMounts 使用 readOnly 挂载以使策略生效。
注意：使用hostPath时，别忘了指定Pod部署的节点。

模版

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      # 宿主上目录位置
      path: /data
      # 此字段为可选
      type: Directory
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

支持的 type 值如下：

emptyDir

当 Pod 分派到某个 Node 上时，emptyDir 卷会被创建，并且在 Pod 在该节点上运行期间，卷一直存在。 就像其名称表示的那样，卷最初是空的。 尽管 Pod 中的容器挂载 emptyDir 卷的路径可能相同也可能不同，这些容器都可以读写 emptyDir 卷中相同的文件。 当 Pod 因为某些原因被从节点上删除时，emptyDir 卷中的数据也会被永久删除。

说明： 容器崩溃并不会导致 Pod 被从节点上移除，因此容器崩溃期间 emptyDir 卷中的数据是安全的。

emptyDir 的一些用途：

• 缓存空间，例如基于磁盘的归并排序。
• 为耗时较长的计算任务提供检查点，以便任务能方便地从崩溃前状态恢复执行。
• 在Web服务器容器服务数据时，保存内容管理器容器获取的文件。

模版

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  - image: test-webserver
    name: test-container2
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

PV

PV就是持久卷（Persistent Volume），是集群中的一块存储，可以由管理员事先制备， 或者使用存储类（Storage Class）来动态制备。与Volume不同的是，它们有独立的生命周期，是一种k8s资源，在kubectl中可以缩写为pv。

模版

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0003
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /tmp
    server: 172.17.0.2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

persistentVolumeReclaimPolicy有以下三种：

• Retain – 手动回收
• Delete – 诸如 AWS EBS、GCE PD、Azure Disk 或 OpenStack Cinder 卷这类关联存储资产也被删除
• Recycle – 基本擦除 (rm -rf /thevolume/*)，已被废弃，使用动态制备替代。

capacity: PV的容量

VolumeMode（卷模式）有两种：

• Filesystem：被 Pod 挂载到某个目录
• Block：这类卷以块设备的方式交给 Pod 使用，其上没有任何文件系统。

accessModes（访问模式）有以下几种：

• ReadWriteOnce：单节点读写模式挂载
• ReadWriteMany：多节点读写模式挂载
• ReadOnlyMany：多节点只读模式挂载

说明：Kubernetes 使用卷访问模式来匹配 PersistentVolumeClaim 和 PersistentVolume。 在某些场合下，卷访问模式也会限制 PersistentVolume 可以挂载的位置。

storageClassName：PVC和PV的保持一致

每个卷会处于以下阶段（Phase）之一：

• Available（可用）-- 卷是一个空闲资源，尚未绑定到任何申领；
• Bound（已绑定）-- 该卷已经绑定到某申领；
• Released（已释放）-- 所绑定的申领已被删除，但是资源尚未被集群回收；
• Failed（失败）-- 卷的自动回收操作失败。

PVC

PVC就是持久卷申领（PersistentVolumeClaim，PVC） 表达的是用户对存储的请求。Pod 将 PVC 申领当做存储卷来使用。集群会检视 PVC 申领，找到所绑定的卷， 并为 Pod 挂载该卷。如果用户删除被某 Pod 使用的 PVC 对象，该 PVC 申领不会被立即移除。 PVC 对象的移除会被推迟，直至其不再被任何 Pod 使用。

模版

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: slow
  selector:
    matchLabels:
      release: "stable"
    matchExpressions:
      - {key: environment, operator: In, values: [dev]}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

selector说明：

• matchLabels - 卷必须包含带有此值的标签
• matchExpressions - 通过设定键（key）、值列表和操作符（operator） 来构造的需求。合法的操作符有 In、NotIn、Exists 和 DoesNotExist。

实战

volumes - hostPath

宿主机的时区、时间和Pod中容器的不一致

修改一下上面的模版，nginx-hostpath.yaml如下

apiVersion: v1
kind: Pod
metadata:
  name: nginx-hostpath
spec:
  nodeName: xxx-105-centos
  containers:
  - image: nginx:1.14.2
    name: nginx
    volumeMounts:
    - mountPath: /etc/timezone
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      path: /etc/timezone
      type: File
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

根据个人情况，替换node名，镜像等

命令

kubectl create -f nginx-hostpath.yaml
1

结果

可以看到，文件挂载成功了。

volumes - emptyDir

busybox-emptydir.yaml

apiVersion: v1
kind: Pod
metadata:
  name: busybox-emptydir
spec:
  containers:
  - image: busybox:latest
    name: busybox1
    imagePullPolicy: IfNotPresent
    command: ['sh','-c','sleep 3600']
    volumeMounts:
    - mountPath: /home
      name: cache-volume
  - image: busybox:latest
    name: busybox2
    imagePullPolicy: IfNotPresent
    command: ['sh','-c','sleep 3600']
    volumeMounts:
    - mountPath: /home
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

命令

kubectl create -f busybox-emptydir.yaml
1

kubectl exec -it busybox-emptydir -c busybox1 -- touch /home/lady_killer
kubectl exec -it busybox-emptydir -c busybox2 -- ls /home
1
2

结果

PV & PVC - hostPath

任务：

1. 创建一个pv，名字为app-config，大小为2Gi，访问权限为ReadWriteMany，storageClassName为manual。Volume的类型为hostPath，路径为/srv/app-config
2. 创建一个名字为app-config-pvc的pvc，绑定上面的pv，大小为10Mi
3. 创建一个Pod，名字为web-server，镜像为nginx:1.14.2，并且挂载该PVC至/usr/share/nginx/html，挂载的权限为ReadWriteMany。

app-config.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: app-config
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteMany
  hostPath:
    path: "/srv/app-config"
1
2
3
4
5
6
7
8
9
10
11
12
13
14

app-config-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-config
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Mi
1
2
3
4
5
6
7
8
9
10
11

web-server-pvc.yaml

apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  volumes:
    - name: app-config
      persistentVolumeClaim:
        claimName: app-config
  containers:
    - name: nginx
      image: nginx:1.14.2
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: app-config
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

命令

kubectl create -f app-config.yaml
kubectl create -f app-config-pvc.yaml
kubectl create -f web-server-pvc.yaml
1
2
3

结果

可以看到PV在创建PVC后，状态由Available转为Bound，说明PVC绑定成功。

注意项

绑定不上pv的可能情况：

• PVC的空间申领大小大于PV的大小
• PVC的StorageClassName与PV的不一致
• PVC的accessModes和PV的不一致

挂在PVC的Pod处于Pending状态：

• PVC创建失败
• PVC和Pod不在同一个namespace

删除PVC时建议先将使用PVC的Pod等删除

参考

k8s-volumes
k8s-Persistent Volumes
k8s-storage-classes
配置 Pod 以使用 PersistentVolume 作为存储
更多k8s相关内容，请看文章：k8s学习-思维导图与学习笔记