pv+statefulset

集群外部很多类存储。是存储工程师创建的
k8s想使用的话关联方式都不同。
因此提供了新的对象资源pv,持久卷。
他先在k8s中将pv卷创建出来。持久卷会对应到相应的存储上。
也就是不用的存储对应不用的存储卷。
应用工程师部署pod直接调用集群的内部的存储卷即可完成存储的使用。

创建pod会附带一个pvc .pvc的请求相当于去寻找一个合适的pv进行绑定。
pvc就是pv的请求方案。

优先选择资源量小的pv进行使用。

pv独立与pod的生命周期之外。比如pv挂载在pod的某个目录上，pod被删除了，pv也依然保存。
类似卷。

动态pv就比如根据云存储进行一些存储的申请等。目前没使用。很贵。

一个pvc只能绑定一个pv.
一一对应
一个pv也只能被一个pvc绑定。

使用nfs机制。
访问策略：只有一个人读写
存储卷的大小为5G
存储类名称：slow
存储类就是划分存储情况的一个指标
比如pvc请求2类的资源就会去找2类的资源pv。
mountoptions就是一些说明，

nfs服务
path挂在到某个服务器的某个目录下
把nfs封装为pv0003,并且存储类是slow.大小为5G
readwriteonce只能被单个节点挂载使用。



保留就是如果PV不使用了，会进入保留的状态，等待管理员手动释放掉。

回收：删除对应卷下的所有内容。最新版本中已经被删除了。

删除：都是跟云相关的。

PV的状态:

已释放指的就是等待K8S重新声明化。

！！PV.PVC,Statefulset

实验部分

一、

当然NFS可以在第三方主机安装。
比如在Harbor安装66.100

创建共享目录

根下的所有允许读写，no_root_squash的权限以及sync的同步方式。

rw：读写权限
sync：数据同步写内存硬盘
async：将数据先保存在内存缓冲区中，必要时才写入磁盘；
all_squash：不管你访问共享目录的用户是谁，都必须压缩为nfsnobody用户的权限；
no_all_squash（默认）：访问用户先与本机用户匹配，匹配失败后再映射为匿名用户或用户组；
root_squash： 如果访问共享目录是root的权限用户，对共享目录的权限会被压缩为nfsnobody用户的权
no_root_squash：来访的root用户保持root帐号权限；

nfs服务：https://blog.csdn.net/weixin_52184735/article/details/112510977

尝试NFS是否能被节点所使用、

可以使用。解除挂在。删除目录。

只允许一个节点读写。
NFS服务的访问路径是/nfs

这个PV已经可以正常挂载到POD使用了。但是一般都是采用PVC的模式去调用。

注意：如果是statefulset的话对应的serviceName必须是无头服务。

因为采用CluserIP为none.所以下面在Statefulset中将serviceName指定为nginx和上面的service服务的name对应。

注意：如果想要创建一个statefulset的控制器必须先创建一个service的无头服务。

volumrvlsimtrmplates就是一个PV模板。挂载点volumeMounts的名字为www其实就是下面PV模板创建的www。挂载路径在/usr/share/nginx/html上。

以上就是通过statefulset调用pv的过程。

为了实验效果多创建几个

测试：
注意在master节点测试下nfs

可以正常访问和使用。
继续创建新的PV

注意更改了访问方式以及挂载目录

4个PV,但是都是NFS类的
更改下、


创建SVC和Statefulset

挂载的是名字为WWW的卷 挂载在XX目录下

声明一个卷的请求的模板
访问模式是readwriteonce
类必须是nfs类
申请的卷的大小必须满足1Gi


没有对应的请求能被绑定了

查看pod.yaml

PVC的请求中需求是RWO,nfs,必须是满足的。大小大于等于即可。优先选择小资源绑定。
只有第一个是符合的 所以被绑定了 Bound

因为副本数目是3，第二个都没有绑定成功。

所以第二个也没有创建成功，因为按顺序执行，第一个没有running后续无法继续
因为每个POD只能挂载一个PV。

因为绑定不了，所以更改pv3和4为符合要求的重新测试下。

可以看到pod也绑定成功并创建出来了


因为每个Pod都有自己的请求模板。会创建对应的pvc,pvc跟pv匹配。匹配成功后与之绑定。


到nfs中看下
cd /nfs

内容：aaaaaaa

看另外的

pv3用的是nfs2的存储

bbbbbbbb
其他的类似访问。
删除一个pod

重新启动了一个

ip变了，但是内容没变。数据不丢失，就是statefulset的特点。

2.dns域名的这个 尝试Ping

ping podname.svc的name
比如web-0
随便进入一个Pod 然后访问web-0看是否能访问成功

可以看到ip是10.244.2.87就是web-0的pod的ip
删除改pod

重启了一个新的


所以想在pod访问web-0服务，通过这种pod的dns域名的方式访问。

这也就是为什么能实现绑定地址不同的原因，通过无头服务绑定的

可以看到是从web-2开始删除的

如何删除？

pvc这些请求不会因为pod的删除而被删除。

发现也没有被api调度了，
手动释放资源

发现还是没变
因为nfspv1不会看default/www-web-1下面是什么内容
他只知道在他的数据里依然有一个pvc在连接，


还是有使用者信息。
就以为还有人使用

把claimRef部分都删除

发现已经可用；

其他两个回收同理

连接关系图

statefulset控制器定义了一些pvc模板，
statefulset创建pod，再创建对应的会创建出对应的pvc,pvc就是匹配pv的一些属性准则。
pvc再与pv关联