存储类（StorageClass）
当用户需要使用存储时，需要通过PVC进行绑定PV，有几种情况会出现问题（一句话就是k8s你不自能）
- PVC需求匹配不到需要的PV
- PVC需求量很大的时候，PV创建会很频繁
- 用户需求无法确定，通常会随着环境而改变
存储类就是为了实现PV动态供给，对于PV进行分组管理，管理员可以自定义级别或者功能来区分使用
上篇静态的PV和PVC留给我很大的一个疑惑，就是k8s不能解放管理员双手，那么存储类就是为了实现这个而来的，就非常类似openstack的cinder功能，能自动根据PVC需求自动创建PV进行绑定，解放管理员双手
存储类字段
命令查看：kubectl explain StorageClass
- metadata下层name字段：就是PVC字段storageClassName，很重要，匹配条件就是通过类名
- provisioner：供给方，存储类需要依赖供给方存储插件完成存储类型的创建（也就是类似各种存储驱动，为了实现存储卷的创建）
k8s供给方存储类型不是全部都是支持，但是也支持符合规范的自定义，看下图支持情况
- parameters：用户关联到存储卷里的参数，不同的provisioner参数不一样
- reclaimPolicy：回收策略，Delete（默认的）和Retain（删除pvc针对pv的处理过程）
- mountOptions：也就是mount -o选项参数（hard、ro、soft等等）
- volumeBindingMode：对于pvc创建后的是立即绑定还是等待Pod调度的时候绑定，考虑的问题是local volume基于节点存储，或者可能后端存储网络不是全部互通的（延迟绑定可以基于Pod调度再次进行过滤条件）
- Immediate：立即绑定（默认）
- WaitForFirstConsumer：延迟绑定
这样可以确保PersistentVolumeClaim绑定策略将Pod可能具有的任何其他node节点约束也进行评估，例如节点资源要求、节点选择器、Pod亲和性和Pod反亲和性
- allowVolumeExpansion：开启支持PVC动态扩容空间
举例NFS实现动态PV（NFS本身是不支持插件的）
- provisioner创建，基于deployment创建，需要实现存储卷的管理（本来由管理员自己手动做的是交给程序）
- rbac授权，因为provisioner提供者需要访问集群
- 创建存储类
- 创建PVC
- 创建Pod测试
整个yaml文件查看：https://github.com/kubernetes-retired/external-storage/tree/master/nfs-client/deploy
1、provisioner创建
只需要修改自己的NFS地址和路径
2、rbac授权
可以根据需求修改下namespace
3、创建存储类
provisioner：需要匹配provisioner创建env指定的名称，用于类调用
archiveOnDelete：“false” 没有感觉有什么用，作用就是删除PVC后,PV被删除，"true"就相反，跟回收策略类似
4、创建PVC
annotations：注释的作用
但是PVC这边没有指定storageClassName，PVC存储类资源是可以2种方式的，第一种storageClassName，第二种annotations（通常使用第一种）
5、创建Pod测试
claimName指定PVC定义的name名称
观察现象
1、先确保provisioner的Pod已经成功运行，一般都是镜像下载的问题，dns需要改成8.8.8.8
2、PV已经自动创建，并自动绑定，默认回收策略是delete
3、容器内查看挂载情况，帮我自动创建了单独下级目录（实现自动创建）
4、删除pvc，pv也被删除
5、修改回收策略
- 创建存储类指定reclaimPolicy字段
- 已经创建的PV通过命令：kubectl patch pv -p ‘{“spec”:{“persistentVolumeReclaimPolicy”:“Retain”}}’
6、开启默认存储类（开启需要2个条件）
开启后PVC可以不写storageClassName或annotations，默认会添加指定的默认存储类
- kube-api需要添加DefaultStorageClass控制器（–admission-control=DefaultStorageClass）
- kubectl patch storageclass 类名 -p ‘{“metadata”: {“annotations”:{“storageclass.kubernetes.io/is-default-class”:“true”}}}’
思考1
可以看到容器挂载的容量还是没有变，我PVC申请的资源是1M，相比静态的我好理解，PV是自己创建的，也就说nfs路径都要自己提前的，当然容量自己也要创建好的
关于resources字段 静态和动态的区别
- 静态是匹配PV进行绑定的
- 动态是创建存储卷时的卷大小（这个创建就是不同存储类型的支持插件来做的，而不用管理员）
NFS有点特殊，没法指定大小，NFS的大小是跟着第一路径的，换ceph rbd就能看到容量是1兆，因为自动创建image的时候指定的大小就是resources字段下定义的
动态PV这样看下来就已经符合我们正常需求了，用户只要确定存储类型和大小就行了（存储类型就是类的一个代表，比如是SSD的，ceph存储的）
思考2
存储类可以作为默认存储匹配，PVC先匹配静态PV绑定，没有合适的走动态绑定