作者介绍：简历上没有一个精通的运维工程师。请点击上方的蓝色《运维小路》关注我，下面的思维导图也是预计更新的内容和当前进度(不定时更新)。
我们上一章介绍了Docker基本情况，目前在规模较大的容器集群基本都是Kubernetes，但是Kubernetes涉及的东西和概念确实是太多了，而且随着版本迭代功能在还增加，笔者有些功能也确实没用过，所以只能按照我自己的理解来讲解。
上一小节，我们介绍了kubernetes的几种存储类型，并且介绍了PV&PVC两种逻辑概念，本小节我们讲通过实际案例来讲解。
声明PV
apiVersion: v1
kind: PersistentVolume
metadata:
name: my-local-pv
spec:
capacity:
storage: 100Gi
volumeMode: Filesystem
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: ""
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- node01
local:
path: /mnt/pv_disk
这个配置定义了一个名为 my-local-pv 的持久卷，具有 100Gi 的存储容量，卷模式为文件系统，访问模式为 ReadWriteOnce，回收策略为 Retain，并且指定了节点亲和性，使得该持久卷只能被调度到标签为 kubernetes.io/hostname=node01 的节点上。持久卷的本地路径为 /mnt/pv_disk
声明PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-local-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 100Gi
storageClassName: ""
volumeName: my-local-pv
在这个YAML文件中，我们创建了一个名为my-local-pvc的PVC，它请求100GB的存储容量，并使用ReadWriteOnce的访问模式。storageClassName字段为空字符串，表示不使用特定的存储类。通过设置volumeName字段为my-local-pv，我们将这个PVC与先前定义的my-local-pv PV绑定。
请确保my-local-pv是先前定义的PV的名称，以确保PVC与正确的PV绑定。当创建这个PVC时，Kubernetes将会使用指定的PV来满足PVC的存储需求,当PV和PVC的STATUS为Bound则算是可用使用的。
申请PVC
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 1
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: nginx
volumeMounts:
- name: data
mountPath: /data
volumes:
- name: data
persistentVolumeClaim:
claimName: my-local-pvc
实际上这种应用方式，在真实环境基本不会这样使用，因为没什么价值，还需要提前创建，还需要考虑PV和PVC的对应关系。当前的PVC实际在Deployment里面直接挂在HostPath效果是一样的，不过用于理解PV&PVC是有意义的，因为测试用的是本地目录。
运维小路
一个不会开发的运维！一个要学开发的运维！一个学不会开发的运维！欢迎大家骚扰的运维！
关注微信公众号《运维小路》获取更多内容。
