25｜PersistentVolume + NFS：怎么使用网络共享存储？

思考题： 1: 首先，静态存储卷PV这个动作是要由运维手动处理的，如果是处在大规模集群的成千上万个PVC的场景下，这个工作量是难以想象的； 再者，业务的迭代变更是动态的，这也就意味着随时会有新的PVC被创建，或者就的PVC被删除，这也就要求运维每碰到PVC的变更，就要跟着去手动维护一个新的 PV。来满足业务的新需求，这个情况如果解决不了，我相信运维这个职业马上就会消失。 最后，动态存储卷的好处还在于分层和解耦，对于简单的localPath或者NFS这种存储卷或许相对来说还比较简单一些，但是像类似于远程存储磁盘这种就相对来说比较 复杂了，动态存储可以让我们只关注于需求点，至于怎么把这些东西创建出来，就交由各个类型的provisioner去处理就行了。 缺点：缺点的话就是在于资源的管控方面，比如原本我可能只需要2Gi的空间，但是业务人员对容量把握不够申请了10Gi，就会有8Gi空间的浪费。 2:StorageClass 作用是帮助指定特定类型的provisioner，这决定了你要使用的具体某种类型的存储插件；另外它还限定了PV和PVC的绑定关系，只有从属于同一StorageClass的PV和PVC才能做绑定动作，比如指定GlusterFS类型的PVC对象不能绑定到另外一个PVC定义的NFS类型的StorageClass 模版创建出的Volume的PV对象上面去。

不妨试一试docker版的nfs-server，简单又方便 https://hub.docker.com/r/fuzzle/docker-nfs-server

云服务器环境搭建：主要在nfs权限那边比较麻烦 -- 服务端 1: 查看是否安装了必要的软件 $ dpkg -l | grep rpcbind ... $ sudo apt -y install rpcbind $ sudo apt -y install nfs-kernel-server $ sudo apt -y install nfs-common 2.修改 /etc/services 追加 # Local services mountd 4011/udp mountd 4011/tcp 内容，固定mountd 的端口号 打开端口号访问限制： TCP: 2049、111、4011 UDP: 111、4046、4011 3. 创建目录 追加配置（和文档中的一样） $ mkdir -p /tmp/nfs /etc/exports 内容增加以下内容（我的云服务器外网ip是175.179网段，这里要根据自身的情况修改）： /tmp/nfs 175.178.0.0/16(rw,sync,no_subtree_check,no_root_squash,insecure) $ sudo exportfs -v $ sudo exportfs -v 4.开启服务 $ sudo systemctl start nfs-server $ sudo systemctl enable nfs-server $ sudo systemctl status nfs-server $ sudo systemctl start rpcbind $ sudo systemctl enable rpcbind $ sudo systemctl status rpcbind -- 客户端 1.安装客户端软件 $ sudo apt -y install nfs-common $ sudo apt -y install rpcbind 其它步骤和老师基本一样

老师，不知道这么理解对不对，因为存储它涉及到了对物理机文件系统绑定的操作，因此K8S做了一系列抽象。PV在这个抽象里，其实就指代了主机文件系统的路径，当然至于再往实现层面走，是网络文件系统还是主机文件系统，这就全由PV的绑定类型决定。而往抽象层走，作为K8S的核心系统，K8S想尽可能屏蔽掉底层，也就是主机文件系统的概念，所以它抽象了StorageClass，用来统一指代/管理PV。至此，K8S持久化存储就可以分两个部分，第一部分是由 主机文件系统+PV+StorageClass组成的，用来将抽象对象绑定到真实文件系统的生产者部分；第二部分就是 Volume+PVC+StorageClass，完全被抽象为K8S核心业务的消费者部分，而StorageClass，可以看作是两部分连接的桥梁。

nfs provisoner 在生产建议使用HELM包方式进行，而且已经在生产实践过， nfs-subdir-external-provisioner 优势2个： 1. 无需复杂的配置 2. 可支持离线下载，方便传输到生产环境。 自己可以玩可以采用教程的方法，了解一下RBAC的流程

用面向对象的思想来理解 kubernetes 在存储上的设计： SC 是类，PV 是实例，PVC 是创建实例的代码，provisioner 是工厂。 有一种豁然开朗的感觉

看了这节课和上节课，终于把storageclass的使用方式搞清楚了，如果都是静态存储和使用，那么只需要在pv和pvc中加上这个name这个属性就可以，并不需要storageClass这个对象，而关键是，这个东西是可以引用provisioner的，让这个和deployment挂钩，其实iwo有一个问题啊，为啥不讲provisioner单独设置为一个对象，而是使用deployment进行部署呢，又是设置环境变量，又是配置参数，另外rabc到底是干嘛的，我真不理解。

思考题: 1. 动态存储卷PV需要手动运维，而且受限于分配的大小问题，如果分配的PV都比较小，需求又比较大，极易造成PV使用不当，造成浪费。反之，动态存储则按需分配。权利的无限放大也会带来问题，就是预先申请与实际使用之间的矛盾，动态申请大了，也是一种浪费。 2. StorageClass应证了“所有问题都可以通过增加一层来解决”。作用是解决了特定底层存储与K8S上资源的解耦问题，通过SC统一接口，具体厂商负责具体的存储实现。

已实操 遇到的问题： 搭建nfs的时候，目录挂载成功，但是创建文件，没有同步到服务端 原因： 在挂载的时候，客户端目录和服务端共享目录一样导致的，挂载目录和共享目录不能根目录相同 修改前： sudo mount -t nfs 192.168.56.103:/home/layne/data/nfs /home/layne/data/nfs 修改后： sudo mount -t nfs 192.168.56.103:/home/layne/data/nfs /data/nfs

有个问题没有想明白，provisioner如何知道系统的存储容量呢？如果我 pvc 一个 100G 空间，但是 nfs 只有不到 100G 空间的时候，provisioner怎么处理这种场景呢？