前情概要
这里引用阿里云的说明文档
为什么要使用
noresvport
参数挂载NAS?不重新挂载会有什么后果?如果发生网络切换或者后端服务的HA倒换,小概率会造成NFS文件系统阻塞,那就可能需要几分钟时间连接才会自动恢复,极端情况下甚至需要重启ECS才能恢复。使用
noresvport
参数后,这个恢复几秒就可以自动完成。什么情况会引发网络切换或者后端服务的HA倒换?
NAS服务是稳定的,网络切换或者后端服务的HA倒换都是罕见情况。
后端服务升级会触发上述切换,但导致客户端阻塞的概率很低,并且在升级之前我们会提前通知相关集群的用户,留出充足时间使用
noresvport
参数。其他可能引发切换的场景,还有负载均衡调整、服务端硬件故障等情况,有一定的不可预测性,所以即使服务端没有升级安排,也请尽快使用
noresvport
参数避免这样的风险。为什么需要重新挂载?还有没有其他的方案?
需要重新挂载的原因是要把之前没有使用
noresvport
参数的TCP连接断掉,然后使用noresvport
参数挂载时,会建立新的TCP连接。为了把老的TCP连接断掉,就必须把NAS相关的业务都停掉,然后执行
umount
卸载。如果不希望重新挂载,可以考虑新建NAS挂载点,使用
noresvport
参数挂载到新的本地路径,然后把业务进程逐步迁移过去,最后废弃老的挂载路径和挂载点。
挂载NFS
静态存储卷
- NFS v3版
1 | apiVersion: v1 |
- NFS v4.0版
1 | apiVersion: v1 |
动态存储卷
假设集群已经部署了
nfs-client-provisioner
用来实现在动态提供PersistentVolume
创建StorageClass
- NFS v3版
1 | apiVersion: storage.k8s.io/v1 |
- NFS v4.0版
1 | apiVersion: storage.k8s.io/v1 |
创建PVC
- NFS v3版
1 | apiVersion: v1 |
- NFS v4.0版
1 | apiVersion: v1 |
测试挂载PV
1 | kind: Pod |
验证挂载选项
- 确认Pod所在宿主机
1 | kubectl -n default get pod test-nfs-pod -o wide |
- 登录到宿主机查看mount,关注是否有
noresvport
1 | mount | grep nfs |
1 | nas_server:/default on /var/lib/kubelet/pods/a3d10191-04f2-11ea-b668-162fb9b39758/volumes/kubernetes.io~nfs/nfsv4-pvc type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,noresvport,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.146,local_lock=none,addr=192.168.0.128,_netdev) |
存量NFS存储卷更新
- 修改NFS存储卷对应的PV,添加
mount
参数 - 重新调度使用NFS存储卷的Pod
注意!如果服务器上还有其他挂载点使用了同一个NFS存储,有可能无法更新挂载选项