容器化囧途之nfs 之囧

现象：

1、客户表示重启机器大量pod无法创建。

2、客户查看发现大量nfs挂载超时的现象

3、客户表示这个集群大概有600+pod（分布在10余个节点当中），当天进行了批量重启

排查过程：

1、查看本地nfs进程和client 进程正常

然后客户反馈重启后好了一会又不行了：

大量pod挂载不能。然后客户手动在节点上手动mount也不行，反馈命令卡很久然后失败

然后客户尝试抓包，然后发现根本没有网络包。

然后demesg看到了如下日志：

其中 “ task mount.nfs:3188 blocked for more than 120 seconds.”这条日志表示内核无法在120秒内调度任务，然后下面的堆栈显示尝试挂载NFS显示mutex一直不释放而挂载的程序关闭了抢占式调度，导致了死锁（前面的挂载进程失败，一直占着锁导致后续的挂载操作超时失败）。

通过和客户沟通了解，该集群有1000左右的pod都需要挂载NFS，这对NFS来说是不小的压力，而事发时客户进行了批量重启，触发了挂载风暴。

同时kubelet 的控制器模式会持续尝试挂载，加剧这个负载。

处理：

1、从客户侧了解到当时节点的docker kubelet进程都在，在客户停止kubelet和docker并清理阻塞的进程后再尝试挂载成功。

从客户侧了解到，挂载NFS主要是为了同步字体文件和skywalking的agent。

建议：

1、使用本地存储，然后同步字体和agent

思考：

1、大量使用网络共享存储确实方便，但是性能方面的开销却不容忽略，尤其是锁方面的。

2、一旦挂载失败，就会导致pod启动不能，大新闻。。。。。。大大的影响SLA

3、确认正在的需求，好钢要用在刀刃上。

4、不要太轴换一个思路往往又是一个新天地

5、系统选型尽量依赖少，LOL