【K8S 存储卷】K8S的存储卷+PV/PVC
目录
一、K8S的存储卷
1、概念：
2、挂载的方式：
2.1、emptyDir：
2.2、hostPath：
2.3、NFS共享存储：
二、PV和PVC：
1、概念
2、请求方式
3、静态请求流程图：
4、PV和PVC的生命周期
5、PV的状态：
6、PV的读写挂载方式：
7、回收策略：
三、PV和PVC静态请求实验：
1、默认的Retain保留策略：
2、设置Recycle回收释放策略：
3、Delete回收策略
4、总结：
一、K8S的存储卷
1、概念：
存储卷：数据卷
容器内的目录和宿主机的目录进行挂载
容器在系统上的生命周期是短暂的，delete，K8S用控制器创建的pod，delete相当于重启，容器的状态也会恢复到最初的状态
一旦回到初始状态，所有后天编辑的文件都会消失
容器和节点之间创建一个可以持久化保存容器内文件的存储卷。即使容器被销毁，删除，重启，节点上的存储卷的数据依然存在，后续也可以继续使用。可以继续将容器内目录和宿主机挂载，保存的数据继续使用
2、挂载的方式：
2.1、emptyDir：
在容器内部共享存储卷。在K8S系统中，是一个pod中多个容器共享一个存储卷目录
emptyDir卷可以使pod中的容器在这个存储卷上读取和写入，这个emptyDir是不能挂载到节点的。随着pod的生命周期结束，emptyDir也会结束，数据不会保留
实验部署：
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx:1.22
name: nginx1
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html
#第一个name，存储的名称，可以自定义，mountPath，定义容器内的挂载目录点，和节点或者其他容器共享目录
- image: nginx:1.22
name: nginx2
volumeMounts:
- name: html
mountPath: /data
#引用上一个挂载点的名称，表示将和/usr/share/nginx/html这个目录进行挂载，由data目录和他挂载
command: ["/bin/bash", "-c", "while true; do echo $(date) >> /data/index.html; sleep 2; done"]
volumes:
- name: html
emptyDir: {}#-c进入指定容器
kubectl exec -it nginx-c669845b5-grs7s -c nginx2 bash
emptyDir说白了就是容器内部共享，重启数据就没有了
2.2、hostPath：
将容器内的挂载点和节点上的目录进行挂载
hostPath可以实现数据的持久化。
node节点在他就在，node节点一旦被销毁，数据也将丢失
注意点：
污点设置为NoExecute驱逐时，会把pod驱逐，那么pod的hostPath的文件数据还在不在？
pod被驱逐，并不是node节点被销毁，所有的数据还保留在节点上
但是前提是基于控制器创建的pod
pod被驱逐，会在其他node节点重新部署，又会在其他节点生成一个新的存储卷。数据依然可以持久化
但是emptyDir的数据被驱逐，数据会丢失
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx:1.22
name: nginx1
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html
#第一个name，存储的名称，可以自定义，mountPath，定义容器内的挂载目录点，和节点或者其他容器共享目录
- image: nginx:1.22
name: nginx2
volumeMounts:
- name: html
mountPath: /data
#引用上一个挂载点的名称，表示将和/usr/share/nginx/html这个目录进行挂载，由data目录和他挂载
command: ["/bin/bash", "-c", "while true; do echo $(date) >> /data/index.html; sleep 2; done"]
volumes:
- name: html
hostPath:
path: /opt/test0
type: DirectoryOrCreate#-c查看不同容器的日志
kubectl logs nginx-dir-84469899f7-ww65t -c nginx22.3、NFS共享存储：
在63主机上，创建nfs共享目录：
去验证是否发布：
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx:1.22
name: nginx1
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html
#第一个name，存储的名称，可以自定义，mountPath，定义容器内的挂载目录点，和节点或者其他容器共享目录
- image: nginx:1.22
name: nginx2
volumeMounts:
- name: html
mountPath: /data
#引用上一个挂载点的名称，表示将和/usr/share/nginx/html这个目录进行挂载，由data目录和他挂载
command: ["/bin/bash", "-c", "while true; do echo $(date) >> /data/index.html; sleep 2; done"]
volumes:
- name: html
nfs:
path: /data
server: 20.0.0.63这里的server可以是共享节点的IP地址也可以是主机名，主机名要和所有K8S节点做映射
映射之后，可以用主机名共享
所有pod内的目录都和节点上的nfs共享目录形成数据卷，所有的数据文件都保存在共享目录中。增删改查对所有pod都生效
集中、方便管理
一般用hostPath和nfs，推荐用nfs
二、PV和PVC：
1、概念
PV：全称Persistent Volume持久化存储卷，描述和定义一个存储卷，PV是由运维人员来定的。
PVC：Persistent Volume Claim持久化存储的请求。PVC实际上是用来描述或者声明我希望使用什么样的PV来进行存储
PVC和PV是一一对应的关系（描述、存储（大小））
PVC来请求PV，nfs提供存储
PVC和PV都是虚拟化的概念，是K8S的抽象的虚拟的存储资源
2、请求方式
PV和PVC的请求方式有两种：静态和动态请求
PVC和PV之间的静态请求，一旦有成百个PVC，工总量太大，所有还有动态PVC
3、静态请求流程图：
PV是集群中的存储资源，PVC请求存储资源，也是对存储资源的一个检索（检查索引），选择一个最合适PV来存储资源
4、PV和PVC的生命周期
PV和PVC之间有生命周期管理：
Provisioning（配置）—PVC请求request—检索（找一个合适的PV）—PVC和PV binding（绑定）—使用—pod被删除—PV的releasing（释放，供下一个PVC使用）—recycling（回收）
配置：配置静态、动态
绑定：就是把PV分配给PVC
使用：就是pod通过PVC使用存储策略----NFS
释放：pod解除和Volume的关系，删除PVC
回收：保留PV，让下一次PVC使用
5、PV的状态：
Available：可用，而且没有被任何PVC绑定
Bound：绑定，表示PV已经绑定到了PVC，绑定就代表使用
Released：释放，PVC已经被删除了，但是PV的存储资源还没有被集群回收
Failed：表示PV资源回收失败，而且PV为不可用状态
6、PV的读写挂载方式：
ReadWriteOnce：RWO，在yaml配置文件中是全称，表示存储PV是可读可写，但是只能被单个pod挂载。
ReadOnlyMany：ROX，存储的PV可以以制度的方式被多个pod挂载
ReadWriteMany：RWX，存储可以支持读写的方式被多个pod共享
nfs：以上三种读写挂载方式都能支持
hostPath：只支持ReadWriteOnce方式
磁盘类型：
SCSI：不支持ReadWriteMany
ISCSI：不支持ReadWriteMany
查看节点的磁盘类型：
#查看iscsi设备
iscsiadm -m session -P 3
iscsiadm查看服务器是否有iscsi设备
-m session 指定操作的会话模块，管理iscsi的会话
-P 3 显示详细信息的级别，级别3就是显示详细信息
#查看scsi设备
lsscsi
7、回收策略：
整个集群回收PV资源的方式：
Retain：保留，pod和挂载点的数据不会被删除
Recycle：回收，PV上的数据被删除挂载点的数据也被删除
Delete：删除，解绑时会自动删除PV上的数据（本地硬盘不能使用，只有云平台才能使用：AWS、EBS、GCE），支持动态卷的可以使用，PV不再可用（云平台自己处理）
补充：当pod运行之后，通过PVC请求到了PV，除非pod被销毁，否则无法删除PVC
只有挂载点先解除，才能删除PVC
三、PV和PVC静态请求实验：
1、默认的Retain保留策略：
pv文件：
vim pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv001
labels:
name: pv001
spec:
nfs:
path: /data/v1
server: 20.0.0.66
accessModes:
- ReadWriteMany
- ReadWriteOnce
capacity:
storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv002
labels:
name: pv002
spec:
nfs:
path: /data/v2
server: 20.0.0.66
accessModes:
- ReadWriteOnce
capacity:
storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv003
labels:
name: pv003
spec:
nfs:
path: /data/v3
server: 20.0.0.66
accessModes:
- ReadWriteMany
- ReadWriteOnce
capacity:
storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv004
labels:
name: pv004
spec:
nfs:
path: /data/v4
server: 20.0.0.66
accessModes:
- ReadWriteMany
- ReadWriteOnce
capacity:
storage: 4Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv005
labels:
name: pv005
spec:
nfs:
path: /data/v5
server: 20.0.0.66
accessModes:
- ReadWriteMany
- ReadWriteOnce
- ReadOnlyMany
capacity:
storage: 5GiPVC声明式文件：
vim pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mypvc
spec:
accessModes: ["ReadWriteMany"]
#pvc期望请求的PV的读写挂载类型是什么
resources:
requests:
storage: 2Gi
#PVC期望请求PV的存储大小是2G。上面合起来的意思：期望读写模式：ReadWriteMany 并且大小是2G
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx:1.22
name: nginx
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html
volumes:
- name: html
persistentVolumeClaim:
claimName: mypvc
PVC—请求用哪个PV存储—PV和物理存储做映射（挂载）—物理设备提供存储
nfs共享目录查看文件
取消挂载：
要取消挂载，要先删除pod，再删pvc。想回到最后状态，最后修改pv配置文件
#先删除pod
kubectl delete deployment nginx
#删除PVC请求
kubectl delete pvc mypvc#kubectl get pv
#修改pv配置文件
kubectl edit pv pv003
#查看pv状态
kubectl get pv
取消挂载之后，nfs共享目录的数据也会被删除
2、设置Recycle回收释放策略：
kubectl apply -f pv.yaml
删除pod，再删pvc请求
不用修改edit
kubectl delete deployments.apps nginx
kubectl delete pvc mypvc
kubectl get pv
3、Delete回收策略
Delete不支持本地，只支持云平台
取消挂载：
先删pod，再删pvc。想回到最初状态，最后修改pvc配置文件
kubectl delete deployments.apps nginx
kubectl delete pvc mypvc
kubectl edit pv pv0034、总结：
K8S中存储卷的模式：
emptyDir：容器内的存储卷，随着pod被销毁，emptyDir也会被销毁，数据不保留
hostPath：和节点目录的存储卷，可以实现持久化存储。数据在每个节点上都有，不方便集中管理
nfs：用的最多的模式，共享目录存储卷，既可以实现持久化，数据集中在一个目录，方便管理
PV和PVC：
PVC请求—PV的存储资源—硬盘空间（NFS）
NFS支持PVC的所有挂载方式和读写模式，最好用
hostPath：仅支持ReadWriteOnce模式
PVC是以检索的方式找到匹配的PV资源，
检索内容： 挂载方式和读写模式
检索PV能提供的存储资源的大小
谁合适选谁
保留：默认，可以不写
回收：自动回收，节点上的数据会被删除
删除：PV会变成Failed模式，不可用，数据也会被删除
静态比较麻烦，如何能自动的匹配PV资源呢？——动态PVC
四、动态请求
1、概述
上面介绍的PV和PVC模式是需要运维人员先创建好PV，然后开发人员定义好PVC进行一对一的Bond，但是如果PVC请求成千上万，那么就需要创建成千上万的PV，对于运维人员来说维护成本很高，Kubernetes提供一种自动创建PV的机制，叫StorageClass，它的作用就是创建PV的模板。
创建 StorageClass 需要定义 PV 的属性，比如存储类型、大小等；另外创建这种 PV 需要用到的存储插件，比如 Ceph 等。 有了这两部分信息，Kubernetes 就能够根据用户提交的 PVC，找到对应的 StorageClass，然后 Kubernetes 就会调用 StorageClass 声明的存储插件，
自动创建需要的 PV 并进行绑定。
//搭建 StorageClass + NFS，实现 NFS 的动态 PV 创建
Kubernetes 本身支持的动态 PV 创建不包括 NFS，所以需要使用外部存储卷插件分配PV。
卷插件称为 Provisioner（存储分配器），NFS 使用的是 nfs-client，这个外部卷插件会使用已经配置好的 NFS 服务器自动创建 PV。
Provisioner：用于指定 Volume 插件的类型，包括内置插件（如 kubernetes.io/aws-ebs）和外部插件（如 external-storage 提供的 ceph.com/cephfs）。
在 Kubernetes 存储领域，Provisioner 是一种用于动态创建 Persistent Volumes (PV) 的组件。
它可以根据 Persistent Volume Claims (PVC) 的请求动态地创建相应的 PV，并将其绑定到请求的 PVC 上。
Provisioner 通常与 StorageClass 一起使用。StorageClass 是定义存储配置的 Kubernetes 资源，其中包含了 Provisioner 的信息，以及其他关于存储的配置参数。
StorageClass 允许管理员在集群中定义不同类型的存储，而不需要提前手动创建 PV。
用户创建一个 PVC 时，如果其请求了一个特定的 StorageClass，Provisioner 将检测到这个请求
并按照 StorageClass 的配置动态创建相应的 PV。
2、实验
master01:20.0.0.61
node01:20.0.0.62
node02:20.0.0.63
nfs服务器：20.0.0.66
2.1、配置nfs服务
在66节点上安装nfs，并配置nfs服务
mkdir /opt/k8s
chmod 777 /opt/k8s/
vim /etc/exports
/opt/k8s 20.0.0.0/24(rw,no_root_squash,sync)
systemctl restart rpcbind
systemctl restart nfs
showmount -e
2.2、创建 Service Account和role
用来管理 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
---
#创建集群角色,给角色定义一组权限规则，kubectl explain ClusterRole 查看模版
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: nfs-client-provisioner-role
rules:
- apiGroups: [""]
#apiGroups定义了规则可用使用哪个api组的权限，空字符双引号""，表示直接使用api的核心组的资源
resources: ["persistentvolumes"]
verbs: ["get","list","watch","create","delete"]
#表示权限的动作
- apiGroups: [""]
resources: ["persistentvolumeclaims"]
verbs: ["watch","get","list","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"]
---
#集群角色绑定，kubectl explain ClusterRoleBinding 查看模版
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: nfs-client-provisioner-bind
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
#要和最上面的名一一对应
namespace: default
#指定权限的命名空间
roleRef:
kind: ClusterRole
name: nfs-client-provisioner-role
#要和上面角色权限名保持一致
apiGroup: rbac.authorization.k8s.io
#整个脚本表示，将写好的规则roles赋予给最上面的账户kubectl apply -f nfs-client-rbac.yaml
apiVersion 和 kind:
apiVersion: rbac.authorization.k8s.io/v1: 表示这是 RBAC API 的版本。
kind: ClusterRole: 表示这是一个 ClusterRole，即集群级别的角色。
metadata:
name: nfs-client-provisioner-clusterrole: 给这个 ClusterRole 起一个名字，方便在集群中引用。
rules:
这是权限规则的列表，定义了该角色拥有的权限。
每个规则（rule）的结构如下：
apiGroups: 定义这个规则适用的 API 组。在这里，使用了空字符串 "" 表示核心 API 组。
resources: 定义了这个规则适用的资源类型。例如，persistentvolumes 表示持久卷，persistentvolumeclaims 表示持久卷声明，storageclasses 表示存储类，events 表示事件，
endpoints 表示服务的终结点。
verbs: 定义了这个规则允许的操作，如 get（获取资源信息）、list（列出资源列表）、
watch（监视资源变化）、create（创建资源）、delete（删除资源）等。
核心 API 组通常是默认的 API 组，无需额外的路径前缀
通过这个 ClusterRoleBinding，服务账户 nfs-client-provisioner 将被授予 ClusterRole nfs-client-provisioner-clusterrole 中定义的一组权限，使其能够执行与持久卷、持久卷声明、存储类、事件和服务终结点相关的操作。
3、使用 Deployment 来创建 NFS Provisioner
NFS Provisione(即 nfs-client)，有两个功能：一个是在 NFS 共享目录下创建挂载点(volume)，
另一个则是将 PV 与 NFS 的挂载点建立关联。
#由于 1.20 版本启用了 selfLink，所以 k8s 1.20+ 版本通过 nfs provisioner 动态生成pv会报错，解决方法如下：
在 Kubernetes 中，selfLink 是 API 资源对象的字段之一，它表示该资源对象在 Kubernetes API 中的自身链接（Self Link）。
Self Link 是一个唯一标识符，用于唯一地标识 Kubernetes 集群中的每个资源对象。
selfLink 的值是一个 URL，指向该资源对象的 Kubernetes API 路径。
它由 Kubernetes API Server 自动生成，并提供给用户和其他系统，以便可以方便地引用或访问该资源对象。
selfLink 字段是为了提供资源对象的唯一标识符，并且它在 API 中的使用主要是为了实现更好的资源链接和引用
模板可能没有考虑到 selfLink 字段的存在。如果存储插件没有适当处理这个字段，可能会导致 PV 的生成失败或报错
Feature Gate 提供了一种在不破坏现有功能的基础上引入新功能或修改现有功能的机制。
通过在 API Server 启动时设置 Feature Gate 选项，可以在集群中启用或禁用特定功能。
vim /etc/kubernetes/manifests/kube-apiserver.yaml
spec:
containers:
- command:
- kube-apiserver
- --feature-gates=RemoveSelfLink=false #添加这一行
- --advertise-address=20.0.0.61
......
Feature Gate 提供了一种在不破坏现有功能的基础上引入新功能或修改现有功能的机制。
通过在 API Server 启动时设置 Feature Gate 选项，可以在集群中启用或禁用特定功能。
kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml
更新apiserver之后，会导致陷入notready，整个集群都会陷入瘫痪
#重启apiserver
kubectl delete pods kube-apiserver -n kube-system
kubectl get pods -n kube-system | grep apiserver
2.3、创建 NFS Provisioner
vim nfs-client-provisioner.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nfs-provisioner
labels:
app: nfs1
spec:
replicas: 1
selector:
matchLabels:
app: nfs1
template:
metadata:
labels:
app: nfs1
spec:
serviceAccountName: nfs-client-provisioner
#指定ServiceAccount账户
containers:
- name: nfs1
image: quay.io/external_storage/nfs-client-provisioner:latest
volumeMounts:
- name: nfs
mountPath: /persistentvolumes
env:
- name: PROVISIONER_NAME
value: nfs-storage
#配置Provisioner的账户名称，确保该名称与StorageClass资源中的provisioner名称保持一致
- name: NFS_SERVER
value: 20.0.0.66
#绑定nfs共享服务器的地址
- name: NFS_PATH
value: /opt/k8s
volumes:
- name: nfs
nfs:
server: 20.0.0.66
path: /opt/k8s
#申明nfs数据卷Deployment 部署了一个 Pod，其中运行了一个 NFS 客户端 provisioner 容器。
该容器会监听 Kubernetes 中的 PV 请求，并动态地创建并配置与 NFS 服务器相关的 PV。
容器使用的配置信息（如 NFS 服务器地址、路径）通过环境变量传递给容器。
这样，通过部署该 Deployment，你可以在 Kubernetes 中使用动态创建的 NFS 存储卷。
kubectl apply -f nfs-client-provisioner.yaml
kubectl get pod
2.4、创建 StorageClass
负责建立 PVC 并调用 NFS provisioner 进行预定的工作，并让 PV 与 PVC 建立关联
vim nfs-client-storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: nfs-client-stotageclass
#匹配Provisioner
provisioner: nfs-storage
parameters:
archiveOnDelete: "false"
#当PVC被删除之后，PV的状态，定义的是false，PVC被删除，PV的状态将是released，可以人工调整，继续使用
#如果定义的是true，PV的状态将是Archived，表示PV不再可用。一般都用released
reclaimPolicy: Retain
#定义PV的回收策略，只支持两种：Retain和Delete，不支持回收策略
allowVolumeExpansion: true
#PV的存储空间可以动态的扩缩容，但是需要云平台支持，本地使用不了------------------------------------------------------------------
保留策略为删除。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: nfs-client-storageclass
provisioner: nfs-storage
parameters:
archiveOnDelete: "false"
reclaimPolicy: Delete
allowVolumeExpansion: truekubectl apply -f nfs-client-storageclass.yaml
动态策略不支持Recycle
如果 archiveOnDelete 设置为 "true"，则表示在删除 PV 时要进行存档。
这可能意味着存储插件会采取一些措施，例如将 PV 标记为 "Archived" 状态，
以便数据仍然可用，但不再对新的 PersistentVolumeClaim（PVC）进行匹配。
如果 archiveOnDelete 设置为 "false"，则表示在删除 PV 时不进行存档。
在这种情况下，存储插件可能会将 PV 标记为 "Released" 或其他状态，
并且可能会允许存储系统回收这些数据以供其他 PVC 使用。
kubectl apply -f nfs-client-storageclass.yaml
kubectl get storageclass
NAME: StorageClass 的名称，这里是 nfs-client-storageclass。
PROVISIONER: Provisioner 的名称，这里是 nfs-storage。它指定了用于动态创建 PV 的 Provisioner。
RECLAIMPOLICY: 回收策略，这里是 Delete。表示当 PersistentVolume（PV）被释放时，它的数据将被删除。
其他可能的值包括 Retain，表示在释放 PV 时保留数据。
VOLUMEBINDINGMODE: 卷绑定模式，这里是 Immediate。表示当 PVC 请求创建 PV 时，
系统会立即绑定一个可用的 PV。另一种可能的值是 WaitForFirstConsumer，
表示系统将等待第一个使用者出现后再绑定 PV。
ALLOWVOLUMEEXPANSION: 允许卷扩展，这里是 false。表示不允许扩展 PV 的容量。
如果设置为 true，则表示允许在运行时扩展 PV 的容量。
AGE: StorageClass 的年龄，这里是 7s。表示该 StorageClass 创建后的时间。
2.5、创建 PVC 和 Pod 测试
vim test-pvc-pod.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nfs-pvc
spec:
accessModes:
- ReadWriteMany
storageClassName: nfs-client-stotageclass
resources:
requests:
storage: 2Gi
#创建一个PVC名字叫做，nfs-pvc，使用的PV属性是nfs-client-stotageclass定义的属性，最后定义PV大小2G
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx1
name: nginx1
spec:
replicas: 1
selector:
matchLabels:
app: nginx1
template:
metadata:
labels:
app: nginx1
spec:
containers:
- image: nginx:1.22
name: nginx1
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html
volumes:
- name: html
persistentVolumeClaim:
claimName: nfs-pvc
#可以更换名称实验多个
kubectl apply -f test-pvc-pod.yaml
//PVC 通过 StorageClass 自动申请到空间
kubectl get pvc
//查看 NFS 服务器上是否生成对应的目录，
自动创建的 PV 会以 ${namespace}-${pvcName}-${pvName} 的目录格式放到 NFS 服务器上
ls /opt/k8s/
kubectl get pv
取消挂载：
#先删除pod
kubectl delete deployments.apps nginx1
#再删除pvc
kubectl delete pvc nfs-pvc
Delete策略取消挂载之后，会删除PV卷
动态测量的默认策略是Delete。
动态策略只能支持两个策略：Retain和Delete
配置Retain策略：
#先删除之前配置的storageclass
kubectl delete storageclasses.storage.k8s.io nfs-client-stotageclass
kubectl apply -f nfs-client-storageclass.yaml
运行PVC：
Retain取消挂载：
进入回收状态：
改PV的配置文件：
3、总结：
动态PV
最重要的两个组件：
Provisioner插件：支持nfs，是他创建PV目录
storageclass：定义PV的属性
动态PV的默认策略是删除Delete
动态没有回收策略只有Retain和Delete
动态PV删除PVC之后的状态，released，改配置文件之后，让他恢复可以复用
- 创建账号，给卷插件能够在集群内部通信，获取资源，监听事件，创建和删除、更新PV
- 创建卷插件的pod，卷插件的pod创建PV
- 定义storageclass给PV赋予属性（PVC被删除之后PV的状态，以及回收策略）
- 创建PVC，完成
里面的名称要一一对应