一、容器存储的短暂性问题
容器的文件系统是临时性的:
- 容器崩溃重启后,容器内数据会丢失
- 同一个 Pod 内的多个容器无法直接共享文件
Kubernetes的Volume抽象 解决了这两个问题:通过Pause容器 让多个容器共享同一个 Volume,从而实现文件共享与持久化。
二、emptyDir存储卷
2.1 特点
- Pod 调度到节点时自动创建
- Pod 删除后数据也随之销毁
- 仅适合临时缓存或容器间数据共享
2.2 案例
bash
mkdir /opt/volumes
cd /opt/volumes
vim pod-emptydir.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-emptydir
namespace: default
labels:
app: myapp
tier: frontend
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
#定义容器挂载内容
volumeMounts:
#使用的存储卷名称,如果跟下面volume字段name值相同,则表示使用volume的这个存储卷
- name: html
#挂载至容器中哪个目录
mountPath: /usr/share/nginx/html/
- name: busybox
image: busybox:latest
imagePullPolicy: IfNotPresent
volumeMounts:
- name: html
#在容器内定义挂载存储名称和挂载路径
mountPath: /data/
command: ['/bin/sh','-c','while true;do echo $(date) >> /data/index.html;sleep 2;done']
#定义存储卷
volumes:
#定义存储卷名称
- name: html
#定义存储卷类型
emptyDir: {}
-------------------------------------------------------------------------------------
//在上面定义了2个容器,其中一个容器是输入日期到index.html中,然后验证访问nginx的html是否可
以获取日期。以验证两个容器之间挂载的emptyDir实现共享。

三、hostPath存储卷
3.1 特点
- 将节点(宿主机)上的目录挂载到容器
- 可实现持久化
- 但节点故障会导致数据丢失
3.2 案例
bash
1)在node01节点上创建挂载目录
mkdir -p /data/pod/volume1
echo 'this is node01' > /data/pod/volume1/index.html
2)在node02节点上创建挂载目录
mkdir -p /data/pod/volume1
echo 'this is node02' > /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: ikubernetes/myapp:v1
#定义容器挂载内容
volumeMounts:
#使用的存储卷名称,如果跟下面volume字段name值相同,则表示使用volume的这个存储卷
- name: html
#挂载至容器中哪个目录
mountPath: /usr/share/nginx/html
#读写挂载方式,默认为读写模式false
readOnly: false
#volumes字段定义了paues容器关联的宿主机或分布式文件系统存储卷
volumes:
#存储卷名称
- name: html
#路径,为宿主机存储路径
hostPath:
#在宿主机上目录的路径
path: /data/pod/volume1
#定义类型,这表示如果宿主机没有此目录则会自动创建
type: DirectoryOrCreate
kubectl apply -f pod-hostpath.yaml

bash
//删除pod,再重建,验证是否依旧可以访问原来的内容
kubectl delete -f pod-hostpath.yaml
kubectl apply -f pod-hostpath.yaml
Pod 删除重建后仍能访问相同内容,说明数据持久化。

四、NFS网络共享存储卷
4.1 特点
- 多节点共享数据
- 数据集中存放于 NFS 服务端
- 支持 RWX(多路读写)
4.2 案例
4.2.1 在stor01节点上安装NFS,并配置NFS服务
bash
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 -anpu | grep rpc
showmount -e
Export list for stor01:
/data/volumes 192.168.10.0/24
4.2.2 master节点操作
bash
vim pod-nfs-vol.yaml
kind: Pod
apiVersion: v1
metadata:
name: pod-vol-nfs
namespace: default
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html
volumes:
- name: html
nfs:
path: /data/volumes
server: stor01 #主机名或者ip
kubectl apply -f pod-nfs-vol.yaml

4.2.3 在stor01节点创建index.html
bash
echo "<h1> this is nfs stor01</h1>" >/data/volumes/index.html
4.2.4 在master节点操作并且验证
bash
#在 NFS 服务器创建 `index.html`,Pod 可直接访问该文件。
curl 10.244.196.181
<h1> this is nfs stor01</h1>
kubectl delete -f pod-nfs-vol.yaml #删除nfs相关pod,再重新创建,可以得到数据的持久化存储
kubectl apply -f pod-nfs-vol.yaml

五、PV与PVC持久化机制
5.1 PV与PVC的概念
- PV全称叫做 Persistent Volume,持久化存储卷。它是用来描述或者说用来定义一个存储卷的,这个通常都是由运维工程师来定义。
- PVC的全称是 Persistent Volume Claim,是持久化存储的请求。它是用来描述希望使用什么样的或者说是满足什么条件的PV存储。
PVC 的使用逻辑:在 Pod 中定义一个存储卷(该存储卷类型为 PVC),定义的时候直接指定大小,PVC必须与对应的PV建立关系,PVC会根据配置的定义去PV申请,而PV是由存储空间创建出来的。PV和PVC是 Kubernetes抽象出来的一种存储资源。
概念 | 作用 | 维护者 |
---|---|---|
PV(Persistent Volume) | 定义底层存储资源 | 运维管理员 |
PVC(Persistent Volume Claim) | 用户提出存储需求 | 应用开发者 |
StorageClass | 自动创建 PV 模板 | 运维工程师 |
5.2 PV和PVC的生命周期
bash
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 以便下次使用,也可以直接从云存储中删除
5.3 PV的状态
根据这5个阶段,PV的状态有以下四种:
- Available(可用):表示可用状态,还未被任何 PVC 绑定
- Bound(已绑定):表示 PV 已经绑定到 PVC
- Released(已释放):表示 PVC 被删掉,但是资源尚未被集群回收
- Failed(失败):表示该 PV 的自动回收失败
5.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.5 PV的示例
bash
kubectl explain pv #查看pv的定义方式
FIELDS:
apiVersion: v1
kind: PersistentVolume
metadata: #由于PV是集群级别的资源,即PV可以跨namespace使用,所以PV的metadata中不用配置 namespace
name:
spec
kubectl explain pv.spec #查看pv定义的规格
spce:
nfs:(定义存储类型)
path:(定义挂载卷路径)
server:(定义服(定义访问模型,务器名称) 主机名/ip
accessModes:有以下三种访问模型,以列表的方式存在,也就是说可以定义多个访问模式)
- ReadWriteOnce #(RWO)存储可读可写,但只支持被单个 Pod 挂载
- ReadOnlyMany #(ROX)存储可以以只读的方式被多个 Pod 挂载
- ReadWriteMany #(RWX)存储可以以读写的方式被多个 Pod 共享
#nfs支持全部三种;iSCSI不支持ReadWriteMany(iSCSI就是在IP网络上运行SCSI协议的一种网络存储
技术);HostPath不支持ReadOnlyMany和ReadWriteMany。
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)
kubectl explain pvc.spec
spec:
accessModes: (定义访问模式,必须是PV的访问模式的子集)
resources:
requests:
storage: (定义申请资源的大小)
storageClassName: (定义存储类名称,此配置用于绑定具有相同类别的PVC和PV)
六、NFS+PV+PVC实战
6.1 配置NFS存储
bash
mkdir /data/volumes/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)
exportfs -arv
showmount -e
官方文档:https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume
6.2 定义PV
bash
//这里定义5个PV,并且定义挂载的路径以及访问模式,还有PV划分的大小。
vim pv-demo.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv001
labels:
name: pv001
spec:
nfs:
path: /data/volumes/v1
server: stor01
accessModes: ["ReadWriteMany","ReadWriteOnce"]
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
kubectl apply -f pv-demo.yaml
kubectl get pv

6.3 定义PVC+Pod
bash
//这里定义了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: ikubernetes/myapp:v1
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html
volumes:
- name: html
persistentVolumeClaim:
claimName: mypvc
kubectl apply -f pod-vol-pvc.yaml
kubectl get pv

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

七、StorageClass+NFS动态存储
通过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)。
7.1 在stor01节点上安装nfs,并配置nfs服务
bash
rpm -q rpcbind nfs-utils
yum install -y nfs-utils rpcbind
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
7.2 创建 Service Account
创建Service Account,用来管理NFS Provisioner在k8s集群中运行的权限,设置nfs-client对 PV,PVC,StorageClass等的规则
bash
vim demo1-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
kubectl get sa #查看集群中ServiceAccount(服务账户)
kubectl get clusterrole #查看集群级别的角色(ClusterRole)


7.3 部署NFS Provisioner
NFS Provisione(即 nfs-client),有两个功能:一个是在NFS共享目录下创建挂载点(volume),另一个则是将PV与NFS的挂载点建立关联。
bash
1) 由于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
Kubernetes 1.24+:RemoveSelfLink已被移除不用配置
2) #创建 NFS Provisioner
vim demo2-nfs-client-provisioner.yaml
kind: Deployment
apiVersion: apps/v1
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: k8s.gcr.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2
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
kubectl get pod

7.4 创建StorageClass
创建 StorageClass,负责建立 PVC 并调用 NFS provisioner 进行预定的工作,并让 PV 与 PVC 建立关联。
bash
vim demo3-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时不会对数据进行存档,即删除数据
kubectl apply -f nfs-client-storageclass.yaml
kubectl get storageclass

7.5 测试PVC+Pod
bash
vim demo4-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名称保持一致
kubectl apply -f test-pvc-pod.yaml
7.6 验证结果
- PVC 自动创建并绑定 PV
- NFS 服务端自动生成对应目录
- 在 Pod 中写入文件,NFS 端可见文件内容
bash
1) PVC 通过 StorageClass 自动申请到空间
kubectl get pvc
2) 查看 NFS 服务器上是否生成对应的目录,自动创建的 PV 会以 ${namespace}-${pvcName}-${pvName} 的目录格式放到 NFS 服务器上
ls /opt/k8s/
3) 进入 Pod 在挂载目录 /mnt 下写一个文件,然后查看 NFS 服务器上是否存在该文件
kubectl exec -it test-storageclass-pod sh
/ # cd /mnt/
/mnt # echo 'this is test file' > test.txt
4)发现 NFS 服务器上存在,说明验证成功
cat /opt/k8s/test.txt



八、总结
存储类型 | 生命周期 | 共享性 | 持久性 | 典型场景 |
---|---|---|---|---|
emptyDir | Pod 生命周期 | 同 Pod 内 | ❌ | 临时缓存 |
hostPath | 节点生命周期 | 单节点 | ✅ | 节点级存储 |
NFS | 独立服务 | 多节点 | ✅✅ | 集群共享存储 |
PV + PVC | 集群级别 | 按需分配 | ✅✅✅ | 生产环境 |
StorageClass | 自动创建 PV | 动态 | ✅✅✅✅ | 大规模部署 |