在容器编排中,Pod的生命周期是短暂的,当Pod终止时,其中的数据通常也会被销毁。为了解决这个问题,Kubernetes引入了Persistent Volume(PV)和Persistent Volume Claim(PVC)的概念。
PVC是对PV的一种声明,它定义了Pod对存储资源的需求。Pod通过PVC来请求PV,而PV则提供了实际的存储资源。PVC的引入使得开发者无需关心底层存储的细节,能够更灵活地使用和管理存储。
PVC有一些基本的属性和状态,这些属性决定了PVC的行为和与PV的关联。
PVC支持与PV相同的访问模式,用于定义Pod如何与PV进行交互。主要有以下三种访问模式:
PVC可以选择性地指定Storage Class,用于指导Kubernetes动态地创建PV。Storage Class定义了PV的属性,包括存储类型、访问模式等。
PVC可以定义对存储资源的需求,包括容量和访问模式。这决定了K8s为Pod提供的PV的选择。
PVC的状态包括当前的Phase,表示PVC的生命周期阶段,可能包括Pending、Bound、Lost等
为了更好地理解Persistent Volume Claim的使用,以下是一个详细的示例,涉及PVC的创建、Pod的声明和与PV的关联。
首先,我们创建一个PV,作为实际的存储资源。
apiVersion: v1
kind: PersistentVolume
metadata:
name: my-pv
spec:
capacity:
storage: 1Gi
volumeMode: Filesystem
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: manual
hostPath:
path: "/mnt/data"
在这个例子中,我们创建了一个1Gi容量的PV,使用了ReadWriteOnce的访问模式,并指定了Retain的回收策略。PV的存储类为manual,表示这是一个手动创建的PV。PV的存储路径为/mnt/data
。
接下来,我们创建一个PVC,用于声明对存储资源的需求。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteOnce
storageClassName: manual
resources:
requests:
storage: 1Gi
在这个例子中,我们创建了一个PVC,请求1Gi容量,并指定了ReadWriteOnce的访问模式和manual的存储类。
最后,我们创建一个Pod,并将PVC挂载到Pod的路径中。
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: nginx
volumeMounts:
- name: my-storage
mountPath: "/usr/share/nginx/html"
volumes:
- name: my-storage
persistentVolumeClaim:
claimName: my-pvc
这个Pod使用了Nginx镜像,并将PVC挂载到了/usr/share/nginx/html
路径。这样,Pod就能够访问并写入PV中的持久化数据。
通过访问Pod中挂载的路径,我们可以验证数据是否能够持久化。
kubectl exec -it my-pod -- /bin/sh
# 在Pod中执行以下命令
echo "Hello, Persistent Volume Claim!" > /usr/share/nginx/html/index.html
exit
通过访问PV的存储路径,我们也可以验证数据是否持久化。
cat /mnt/data/index.html