---

前言

容器存储天生具备短暂性，数据易随容器销毁丢失。本文从基础存储卷到动态供给，拆解各类容器持久化方案，附实操步骤助力落地。

---

一、容器存储短暂性问题

容器的文件系统是临时性的：
1）容器崩溃重启后，容器内数据会丢失；
2）同一个 Pod 内的多个容器无法直接共享文件。
Kubernetes 的 Volume 抽象 解决了这两个问题：
通过 Pause 容器 让多个容器共享同一个 Volume，从而实现文件共享与持久化。

二、emptyDir存储卷

特点：

• Pod 调度到节点时自动创建；
• Pod 删除后数据也随之销毁；
• 仅适合临时缓存或容器间数据共享。

创建示例：

mkdir /opt/volumes cd /opt/volumes vim pod-emptydir.yaml # API版本：Pod是K8s的核心资源，属于v1版本 apiVersion: v1 # 资源类型：这里声明要创建的是Pod kind: Pod # 元数据：用于描述Pod的基础信息 metadata: # Pod的名称，在命名空间内唯一 name: pod-emptydir # Pod所属的命名空间，默认就是default namespace: default # 自定义标签：用于筛选、关联其他资源（比如Service） labels: app: myapp tier: frontend # 规格：Pod的核心配置，定义容器、存储卷等 spec: # 容器列表：一个Pod可以包含多个容器，这里定义两个Nginx容器 containers: # 第一个容器的配置 - name: myapp-nginx # 容器名称，自定义且在Pod内唯一 # 镜像替换为官方Nginx最新版（原镜像ikubernetes/myapp:v1替换） image: nginx:latest # 镜像拉取策略：本地有就用本地，没有再从仓库拉 imagePullPolicy: IfNotPresent # 端口配置：声明容器要暴露的端口（Nginx默认80端口） ports: - name: http # 端口名称，自定义 containerPort: 80 # 容器内部的端口号 # 容器挂载配置：将存储卷挂载到容器内指定目录 volumeMounts: # 要挂载的存储卷名称（必须和下方volumes里的name一致） - name: html # 挂载到容器内的目录（Nginx默认的网页根目录） mountPath: /usr/share/nginx/html/ # 第二个容器的配置 - name: busybox-nginx # 容器名称，自定义且在Pod内唯一 # 镜像替换为官方Nginx最新版（原镜像busybox:latest替换） image: nginx:latest # 镜像拉取策略：本地有就用本地，没有再从仓库拉 imagePullPolicy: IfNotPresent # 同样挂载名为html的存储卷 volumeMounts: # 要挂载的存储卷名称（和第一个容器共用同一个） - name: html # 挂载到该容器内的/data目录 mountPath: /data/ # 容器启动命令：持续往/data/index.html写入当前时间（每2秒一次） command: ['/bin/sh','-c','while true;do echo $(date) >> /data/index.html;sleep 2;done'] # 存储卷定义：Pod级别的存储，供容器挂载使用 volumes: # 存储卷名称（和容器volumeMounts里的name对应） - name: html # 存储卷类型：emptyDir（Pod存在时生效，Pod删除则数据丢失，用于Pod内容器共享数据） emptyDir: {}

kubectl apply -f pod-emptydir.yaml
验证：在上面定义了2个容器，其中一个容器是输入日期到index.html中，然后验证访问nginx的html是否可以获取日期。以验证两个容器之间挂载的emptyDir实现共享。

三、hostPath 存储卷

特点：

• 将节点（宿主机）上的目录挂载到容器；
• 可实现持久化；
• 但节点故障会导致数据丢失。
  创建示例：

1）在 node01 节点上创建挂载目录 mkdir -p /data/pod/volume1 echo 'node01.benet.com' > /data/pod/volume1/index.html 2）在 node02 节点上创建挂载目录 mkdir -p /data/pod/volume1 echo 'node02.benet.com' > /data/pod/volume1/index.html 3) 创建 Pod 资源 vim pod-hostpath.yaml apiVersion: v1 kind: Pod metadata: name: pod-hostpath namespace: default spec: containers: - name: myapp image: nginx # 定义容器挂载内容 volumeMounts: # 使用的存储卷名称，需和下方volumes的name一致 - name: html # 挂载至容器中哪个目录 mountPath: /usr/share/nginx/html # 读写挂载方式，默认为读写模式（false） readOnly: false # volumes字段定义Pod关联的存储卷（hostPath为宿主机路径） volumes: # 存储卷名称 - name: html # 存储卷类型为hostPath（关联宿主机路径） hostPath: # 宿主机上的目录路径 path: /data/pod/volume1 # 类型：宿主机无此目录则自动创建 type: DirectoryOrCreate

kubectl apply -f pod-hostpath.yaml
验证结果如下所示：

删除重建pod，查看效果
kubectl delete -f pod-hostpath.yaml
kubectl apply -f pod-hostpath.yaml

查看结果一致

Pod 删除重建后仍能访问相同内容，说明数据持久化。

四、NFS网络共享卷

1、特点

• 多节点共享数据；
• 数据集中存放于 NFS 服务端；
• 支持 RWX（多路读写）

2、创建步骤

2.1、在stor01节点上安装nfs，并配置nfs服务

# 查看rpcbind nfs-utils是否安装，没有则yum 安装 rpm -q rpcbind nfs-utils yum install -y nfs-utils rpcbind # 共享卷路径 mkdir /data/volumes -p chmod 777 /data/volumes # 配置共享卷共享网段 vim /etc/exports #NFS 的配置文件为/etc/exports，文件内容默认为空（无任何共享） /data/volumes 192.168.10.0/24(rw,no_root_squash) systemctl start rpcbind systemctl start nfs systemctl enable rpcbind systemctl enable nfs # 验证 netstat -antulp | grep rpc # 查看共享卷是否生效 showmount -e

2.2、master节点操作

vim pod-nfs-vol.yaml apiVersion: v1 kind: Pod metadata: name: pod-vol-nfs namespace: default spec: containers: - name: myapp image: nginx volumeMounts: - name: html mountPath: /usr/share/nginx/html volumes: - name: html nfs: path: /data/volumes server: stor01 # node节点设置stor01解析主机名称 vim /etc/hosts 192.168.10.102 stor01 # node节点安装nfs客户端 yum install -y nfs-utils

2.3、在nfs服务器上创建index.html

echo “

nfs stor01

” >/data/volumes/index.html

2.4、 master节点操作并且验证

删除nfs相关pod，再重新创建，可以得到数据的持久化存储
kubectl delete -f pod-nfs-vol.yaml
kubectl apply -f pod-nfs-vol.yaml

2.5、其他跨主机持久化工具

NAS、GFS、Ceph、SAN
Ceph 是一款开源的、分布式的统一存储系统，它能同时提供文件存储、块存储和对象存储三种接口，且具备高可用、高扩展、无中心架构的特点，是容器化（如 Kubernetes）和云计算场景中主流的持久化存储方案之一。

五、PV和PVC持久化机制

1、 PV与PVC的概念

1）PV 全称叫做 Persistent Volume，持久化存储卷。它是用来描述或者说用来定义一个存储卷的，这个通常都是由运维工程师来定义。
2）PVC 的全称是 Persistent Volume Claim，是持久化存储的请求。它是用来描述希望使用什么样的或者说是满足什么条件的 PV 存储。
PVC 的使用逻辑：在 Pod 中定义一个存储卷（该存储卷类型为 PVC），定义的时候直接指定大小，PVC 必须与对应的 PV 建立关系，PVC 会根据配置的定义去 PV 申请，而 PV 是由存储空间创建出来的。PV 和 PVC 是 Kubernetes 抽象出来的一种存储资源

2、PV和PVC生命周期

PV和PVC之间的相互作用遵循这个生命周期
Provisioning（配置）–> Binding（绑定）–> Using（使用）–> Releasing（释放）–> Recycling（回收）

• Provisioning，即 PV 的创建，可以直接创建 PV（静态方式），也可以使用 StorageClass 动态创建
• Binding，将 PV 分配给 PVC
• Using，Pod 通过 PVC 使用该 Volume，并可以通过准入控制StorageProtection（1.9及以前版本为PVCProtection） 阻止删除正在使用的 PVC
• Releasing，Pod 释放 Volume 并删除 PVC
• Reclaiming，回收 PV，可以保留 PV 以便下次使用，也可以直接从云存储中删除

3、pv的状态

根据这 5 个阶段，PV 的状态有以下 4 种：
Available（可用）：表示可用状态，还未被任何 PVC 绑定
Bound（已绑定）：表示 PV 已经绑定到 PVC
Released（已释放）：表示 PVC 被删掉，但是资源尚未被集群回收
Failed（失败）：表示该 PV 的自动回收失败

4、一个PV从创建到销毁的具体流程如下

1）一个PV创建完后状态会变成Available，等待被PVC绑定。
2）一旦被PVC邦定，PV的状态会变成Bound，就可以被定义了相应PVC的Pod使用。
3）Pod使用完后会释放PV，PV的状态变成Released。
4）变成Released的PV会根据定义的回收策略做相应的回收工作。有三种回收策略，Retain、Delete和 Recycle。
策略：

• Retain：保留数据，需手动清理；retain就是保留现场，K8S集群什么也不做，等待用户手动去处理PV里的数据，处理完后，再手动R删除PV。
• Delete：自动删除存储资源；
• Recycle：清空数据重新可用（仅 NFS / HostPath 支持）。 K8S会将PV里的数据删除，然后把PV的状态变成Available，又可以被新的PVC绑定使用。

5、pv示例解析

kubectl explain pv # 查看pv的定义方式 metadata: # 由于 PV 是集群级别的资源，即 PV 可以跨 namespace 使用， # 所以 PV 的 metadata 中不用配置 namespace kubectl explain pv.spec #查看pv定义的规格 spce: nfs:（定义存储类型） path:（定义挂载卷路径） server:（定义服（定义访问模型，务器名称） accessModes:有以下三种访问模型，以列表的方式存在，也就是说可以定义多个访问模式） * * * - ReadWriteOnce #（RWO）存储可读可写，但只支持被单个 Pod 挂载 - ReadOnlyMany #（ROX）存储可以以只读的方式被多个 Pod 挂载 - ReadWriteMany #（RWX）存储可以以读写的方式被多个 Pod 共享 capacity:（定义存储能力，一般用于设置存储空间） storage: 2Gi （指定大小） storageClassName: （自定义存储类名称，此配置用于绑定具有相同类别的PVC和PV） persistentVolumeReclaimPolicy: Retain #回收策略（Retain/Delete/Recycle） ** * #Retain（保留）：当删除与之绑定的PVC时候，这个PV被标记为released（PVC与PV解绑但还没有执行回 收策略）且之前的数据依然保存在该PV上，但是该PV不可用，需要手动来处理这些数据并删除该PV。 #Delete（删除）：删除与PV相连的后端存储资源（只有 AWS EBS, GCE PD, Azure Disk 和 Cinder 支持） #Recycle（回收）：删除数据，效果相当于执行了 rm -rf /thevolume/* （只有 NFS 和 HostPath 支持） kubectl explain pvc #查看PVC的定义方式 KIND: PersistentVolumeClaim VERSION: v1 FIELDS: apiVersion <string> kind <string> metadata <Object> spec <Object> #PV和PVC中的spec关键字段要匹配，比如存储（storage）大小、访问模式（accessModes）、存储类名 # 称（storageClassName） spec: accessModes: （定义访问模式，必须是PV的访问模式的子集） resources: requests: storage: （定义申请资源的大小） storageClassName: （定义存储类名称，此配置用于绑定具有相同类别的PVC和PV）

六、NFS+PV+PVC实战

1、配置nfs存储

cd /data/volumes/ mkdir v{1,2,3,4,5} vim /etc/exports /data/volumes/v1 192.168.10.0/24(rw,no_root_squash) /data/volumes/v2 192.168.10.0/24(rw,no_root_squash) /data/volumes/v3 192.168.10.0/24(rw,no_root_squash) /data/volumes/v4 192.168.10.0/24(rw,no_root_squash) /data/volumes/v5 192.168.10.0/24(rw,no_root_squash) showmount -e

2、定义PV

vim pv-demo.yaml

# 定义5个PV，指定NFS挂载路径、访问模式和存储大小 apiVersion: v1 kind: PersistentVolume # 资源类型：持久化卷（PV） metadata: name: pv001 # PV的唯一名称，集群内不能重复 labels: name: pv001 # 给PV打标签，PVC可通过标签筛选绑定该PV spec: nfs: path: /data/volumes/v1 # NFS服务器上的共享目录路径（需提前在NFS服务端创建） server: stor01 # NFS服务器的地址（主机名/IP，需保证K8s节点能解析/访问） # 访问模式：支持的挂载方式（数组形式，可写多个） # ReadWriteMany(RWX)：多Pod可同时读写；ReadWriteOnce(RWO)：仅单个Pod读写 accessModes: ["ReadWriteMany","ReadWriteOnce"] # 存储容量配置：该PV提供的存储空间大小 capacity: storage: 1Gi --- apiVersion: v1 kind: PersistentVolume metadata: name: pv002 labels: name: pv002 spec: nfs: path: /data/volumes/v2 server: stor01 accessModes: ["ReadWriteOnce"] capacity: storage: 2Gi --- apiVersion: v1 kind: PersistentVolume metadata: name: pv003 labels: name: pv003 spec: nfs: path: /data/volumes/v3 server: stor01 accessModes: ["ReadWriteMany","ReadWriteOnce"] capacity: storage: 2Gi --- apiVersion: v1 kind: PersistentVolume metadata: name: pv004 labels: name: pv004 spec: nfs: path: /data/volumes/v4 server: stor01 accessModes: ["ReadWriteMany","ReadWriteOnce"] capacity: storage: 4Gi --- apiVersion: v1 kind: PersistentVolume metadata: name: pv005 labels: name: pv005 spec: nfs: path: /data/volumes/v5 server: stor01 accessModes: ["ReadWriteMany","ReadWriteOnce"] capacity: storage: 5Gi

结果如下：

3、定义PVC+Pod

这里定义了pvc的访问模式为多路读写，该访问模式必须在前面pv定义的访问模式之中。定义PVC申请的大小为2Gi，此时PVC会自动去匹配多路读写且大小为2Gi的PV，匹配成功获取PVC的状态即为Bound

vim pod-vol-pvc.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mypvc namespace: default spec: accessModes: ["ReadWriteMany"] resources: requests: storage: 2Gi --- apiVersion: v1 kind: Pod metadata: name: pod-vol-pvc namespace: default spec: containers: - name: myapp image: ingix volumeMounts: - name: html mountPath: /usr/share/nginx/html volumes: - name: html persistentVolumeClaim: claimName: mypvc

结果如下：

4、测试访问

# 在存储服务器上创建index.html，并写入数据，通过访问Pod进行查看，可以获取到相应的页面。 cd /data/volumes/v3/ echo "welcome to use pv3" > index.html kubectl get pods -o wide curl 10.244.2.101

七、StorageClass + NFS 动态存储

1、为什么要使用动态存储

通过 nfs-client-provisioner 实现 自动 PV 创建
Kubernetes 本身支持的动态 PV 创建不包括 NFS，所以需要使用外部存储卷插件分配PV。详见：https://kubernetes.io/zh/docs/concepts/storage/storage-classes/
卷插件称为 Provisioner（存储分配器），NFS 使用的是 nfs-client，这个外部PV。
Provisioner：用于指定 Volume 插件的类型，包括内置插件（如 kubernetes.io/aws-ebs）和外部插件（如 exte卷插件会使用已经配置好的 NFS 服务器自动创建 rnal-storage 提供的 ceph.com/cephfs）。

2、在stor01节点上安装nfs，并配置nfs服务

mkdir /opt/k8s chmod 777 /opt/k8s/ vim /etc/exports /opt/k8s 192.168.10.0/24(rw,no_root_squash,sync) systemctl restart nfs

3、创建 Service Account

创建 Service Account，用来管理 NFS Provisioner 在 k8s 集群中运行的权限，设置 nfs-client 对 PV，PVC，StorageClass 等的规则

vim nfs-client-rbac.yaml #创建 Service Account 账户，用来管理 NFS Provisioner 在 k8s 集群中运行的权限 apiVersion: v1 kind: ServiceAccount metadata: name: nfs-client-provisioner --- # 创建集群角色 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: nfs-client-provisioner-clusterrole rules: - apiGroups: [""] resources: ["persistentvolumes"] verbs: ["get", "list", "watch", "create", "delete"] - apiGroups: [""] resources: ["persistentvolumeclaims"] verbs: ["get", "list", "watch", "update"] - apiGroups: ["storage.k8s.io"] resources: ["storageclasses"] verbs: ["get", "list", "watch"] - apiGroups: [""] resources: ["events"] verbs: ["list", "watch", "create", "update", "patch"] - apiGroups: [""] resources: ["endpoints"] verbs: ["create", "delete", "get", "list", "watch", "patch", "update"] --- # 集群角色绑定 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: nfs-client-provisioner-clusterrolebinding subjects: - kind: ServiceAccount name: nfs-client-provisioner namespace: default roleRef: kind: ClusterRole name: nfs-client-provisioner-clusterrole apiGroup: rbac.authorization.k8s.io

kubectl apply -f nfs-client-rbac.yaml

4、部署 NFS Provisioner

NFS Provisione(即 nfs-client)，有两个功能：一个是在 NFS 共享目录下创建挂载点(volume)，另一个则是将 PV 与 NFS 的挂载点建立关联。

#由于 1.20 版本启用了 selfLink，所以 k8s 1.20+ 版本通过 nfs provisioner 动态生成pv会报错，解决方法如下： vim /etc/kubernetes/manifests/kube-apiserver.yaml spec: containers: - command: - kube-apiserver - --feature-gates=RemoveSelfLink=false #添加这一行 - --advertise-address=192.168.10.19 ...... kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml kubectl delete pods kube-apiserver -n kube-system kubectl get pods -n kube-system | grep apiserver

创建 NFS Provisioner

vim nfs-client-provisioner.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nfs-client-provisioner spec: replicas: 1 selector: matchLabels: app: nfs-client-provisioner strategy: type: Recreate template: metadata: labels: app: nfs-client-provisioner spec: serviceAccountName: nfs-client-provisioner # 指定Service Account账户 containers: - name: nfs-client-provisioner image: quay.io/external_storage/nfs-client-provisioner:latest imagePullPolicy: IfNotPresent volumeMounts: - name: nfs-client-root mountPath: /persistentvolumes env: - name: PROVISIONER_NAME value: nfs-storage # 配置provisioner的Name，确保该名称与StorageClass资源中的provisioner名称保持一致 - name: NFS_SERVER value: stor01 # 配置绑定的nfs服务器 - name: NFS_PATH value: /opt/k8s # 配置绑定的nfs服务器目录 volumes: # 申明nfs数据卷 - name: nfs-client-root nfs: server: stor01 path: /opt/k8s

5、创建 StorageClass

创建 StorageClass，负责建立 PVC 并调用 NFS provisioner 进行预定的工作，并让 PV 与 PVC 建立关联

vim nfs-client-storageclass.yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: nfs-client-storageclass provisioner: nfs-storage # 这里的名称要和provisioner配置文件中的环境变量PROVISIONER_NAME保持一致 parameters: archiveOnDelete: "false" # false表示在删除PVC时不会对数据进行存档，即直接删除NFS上对应的目录和数据

kubectl apply -f nfs-client-storageclass.yaml

6、测试 PVC + Pod

vim test-pvc-pod.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: test-nfs-pvc spec: accessModes: - ReadWriteMany storageClassName: nfs-client-storageclass # 关联StorageClass对象（修正了原拼写错误） resources: requests: storage: 1Gi --- apiVersion: v1 kind: Pod metadata: name: test-storageclass-pod spec: containers: - name: busybox image: busybox:latest imagePullPolicy: IfNotPresent command: - "/bin/sh" - "-c" args: - "sleep 3600" volumeMounts: - name: nfs-pvc mountPath: /mnt restartPolicy: Never volumes: - name: nfs-pvc persistentVolumeClaim: claimName: test-nfs-pvc # 与PVC名称保持一致

pod/test-storageclass-pod created

7、验证结果

● PVC 自动创建并绑定 PV；
● NFS 服务端自动生成对应目录；
● 在 Pod 中写入文件，NFS 端可见文件内容

1. PVC 通过 StorageClass 自动申请到空间
   
2. 查看 NFS 服务器上是否生成对应的目录，自动创建的 PV 会以
   n a m e s p a c e − {namespace}-namespace−{pvcName}-${pvName} 的目录格式放到 NFS 服务器上
3. 进入 Pod 在挂载目录 /mnt 下写一个文件，然后查看 NFS 服务器上是否存在该文件
   kubectl exec -it test-storageclass-pod sh
   cd /mnt/
   echo ‘this is test file’ > test.txt
   4)发现 NFS 服务器上存在，说明验证成功
   cat /opt/k8s/test.txt
   

---

总结

本文覆盖容器持久化全流程实操，从基础卷到 PV/PVC 及动态存储，按需选型即可兼顾数据稳定与运维效率，适配不同业务场景。