K8S系列学习之PVC和PV实战
Kubernetes学习路上的那些事儿，很有必要分享出来
（此图来自网络）
什么是PV和PVC
还是先上官网瞧瞧，看看“正宗”的定义是什么，当然，这也是个人习惯，凡事儿先从官方渠道获取信息，然后配合其他途径的信息加以佐证。
PV是PersistentVolume的缩写，翻译过来就是“持久卷”，主要是为k8s集群提供持久的存储介质的。
PVC是PersistentVolumeClaim的缩写，可以翻译成“持久卷申领”，这可不是“塑料管”哦。
简单的说，PV是对应到物理节点上的存储区域的，比如在Node1节点上，指定一个大小容量为50MB的存储空间，这个存储空间不会因为Pod的消失而释放的，相当于物理服务器上的物理存储硬盘，可以永久保存数据的。而PVC是在Pod需要访问“永久存储”时，才被调用的API，根据PVC的类型，k8s集群会自动匹配PVC和PV，然后将分配的“永久存储”挂载到具体Pod上，可供Pod中的容器应用访问。
K8s集群中的PV（持久卷）又分为静态和动态，静态实现方式是手动创建PVC、PV，集群通过匹配容量（storage）和访问模式（accessModes），将合适的PVC和PV绑定，用户创建Pod时通过关联Pod中的spec.volumes. persistentVolumeClaim.claimName和PVC中的metadata.name，实现Pod->PVC->PV的绑定和调用。而动态实现方式要通过StorageClass来实现，具体内容在后续帖子中分享。
本帖主要实现PV静态调用，可以通过实验来观察一下。
实验过程
实验准备：
本地k8s集群环境一套，不过两个Node节点未启动，显示“NotReady”，之所以能够在Master节点上创建Pod等资源，可以通过一条命令来实现。
kubectl taint nodes --all node-role.kubernetes.io/master-
步骤一：安装和启动nfs。先在实验环境Master节点（192.168.1.3）上安装并启动nfs服务，同时创建3个共享文件夹。这一步容易被忽略，如果NFS服务器环境没有搭建好，在具体使用PV和PVC中可能会无法访问NFS服务器上的共享文件。
yum install nfs-utils -y //安装nfs服务
mkdir /data/nfs/volumes/v{1,2,3} -p //在根目录下创建3个文件夹编辑/etc/exports文档，将创建的3个文件添加进去。文件目录就是刚创建的，192.168.1.3是本次实验的节点IP地址。
/data/nfs/volumes/v1 192.168.1.3/24(rw,no_root_squash)
/data/nfs/volumes/v2 192.168.1.3/24(rw,no_root_squash)
/data/nfs/volumes/v3 192.168.1.3/24(rw,no_root_squash)启动nfs服务，然后查看共享文件目录。
systemctl start nfs //启动nfs
showmount -e 192.168.1.3 //查看共享文件夹
步骤二：编写PV，PVC的yaml文件，在PV的yaml文件中编写三种类型存储卷，起名叫pv-static.yaml，PVC的yaml文件就叫pvc-static.yaml。由于是静态调用，所以需要手动指定具体参数。
pv-static.yaml #pv的yaml文件
apiVersion: v1 #指定的api版本，要符合kubectl apiVersion规定，v1是稳定版本，必选参数
kind: PersistentVolume #k8s资源类型，PersistentVolume资源
metadata: #资源的元数据语句块，是针对kind对应资源的全局属性
name: pv001 #自定义名称pv001
labels: #PV资源的标签语句块
name: pv001 #标签名，可自定义
spec: #规格语句块
capacity: #PV的存储空间语句块
storage: 10Mi #PV的具体存储空间大小，Mi表示1024进制
volumeMode: Filesystem #卷模式，有两种，Filesystem(文件系统)，Block(块)
accessModes: ["ReadWriteOnce"] #访问模式，有三种，ReadWriteOnce，ReadOnlyMany，ReadWriteMany
persistentVolumeReclaimPolicy: Recycle #回收策略，有三种，Retain，Recycle，Delete
nfs: #NFS文件系统配置语句块
path: /data/nfs/volumes/v1 #在NFS文件系统上创建的共享文件目录
server: 192.168.1.3 #NFS服务器IP地址
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv002
labels:
name: pv002
spec:
capacity:
storage: 20Mi
volumeMode: Filesystem
accessModes: ["ReadOnlyMany"]
persistentVolumeReclaimPolicy: Recycle
nfs:
path: /data/nfs/volumes/v2
server: 192.168.1.3
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv003
labels:
name: pv003
spec:
capacity:
storage: 30Mi
volumeMode: Filesystem
accessModes: ["ReadWriteMany"]
persistentVolumeReclaimPolicy: Recycle
nfs:
path: /data/nfs/volumes/v3
server: 192.168.1.3PV对应的代码详解如下图：
PVC代码文件如下，pvc-static.yaml：
apiVersion: v1 #指定的api版本，要符合kubectl apiVersion规定，v1是稳定版本
kind: PersistentVolumeClaim #k8s资源类型，PersistentVolumeClaim资源，
metadata: #资源的元数据语句块，是针对kind对应资源的全局属性元数据块
name: pvcstatic #PVC名称，自定义
spec: #规格语句块
accessModes: ["ReadWriteMany"] #访问模式
resources: #访问模式下的资源语句块
requests: #请求语句块
storage: 25Mi #请求存储空间
--- #以下代码是通过创建一个pod来调用PVC，集群再将合适的PVC和PV绑定
apiVersion: v1
kind: Pod
metadata:
name: pvcpod
namespace: default
spec:
volumes:
- name: html
persistentVolumeClaim:
claimName: pvcstatic
containers:
- name: mynginx
image: nginx
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html/PVC代码的相关解释如下：
步骤三：创建PV、PVC，并验证结果。在PVC用于验证的Pod中，请求一个大小为25Mi容量的存储空间，且访问模式是“ReadWriteMany”（可被多个节点挂载，并拥有读写权限），与步骤二中创建的pv003最为匹配。
kubectl apply -f pv-static.yaml //创建PV
kubectl get pv //查看PV
kubectl apply -f pvc-static.yaml //创建PVC
kubectl get pvc //查看PVC
进入Pod内部，在/usr/share/nginx/html目录下创建一个index.html，然后退出到Master节点上，观察一下Master节点（192.168.1.3）中共享目录下的情况，/data/nfs/volumes/v3应该会出现一个index.html文件，说明成功。
实验总结
PV和PVC的设计，仍然符合“分布式”的理念，即“分层解耦”，Pod关联PVC，然后由系统匹配合适的PV绑定到PVC上，从而为Pod提供合适的“永久卷”。
后面的帖子中，我们进一步来实验一下PV的动态使用方法。