下面是我们生产环境容器的重启日志，可以看到是configm挂载失败了。但奇怪的是只有一个pod发生了这个现象。

登录到主机后，发现mount挂载已经不存在了。

# cat /proc/self/mountinfo |grep subpath
3254 61 253:0 /var/lib/kubelet/pods/a90fef26-916e-11e9-b408-d2840e89eb12/volumes/kubernetes.io~configmap/fsosmpc-x0/..2019_06_18_02_13_28.600673272/php.ini /var/lib/kubelet/pods/a90fef26-916e-11e9-b408-d2840e89eb12/volume-subpaths/fsosmpc-x0/fsosimupc/0 rw,relatime shared:1 - xfs /dev/mapper/centos-root rw,attr2,inode64,sunit=512,swidth=512,noquota

kubeket 会将pods下

volumes/kubernetes.io~configmap/fsosmpc-x0/..2019_06_18_02_13_28.600673272/php.ini 

通过bind mount挂载到

volume-subpaths/fsosmpc-x0/fsosimupc/0

上面的时间戳目录是为了实现原子操作。但这里存在一个问题，如果文件内容发生变化，会导致重新生成时间戳，导致原理的mount的源失效。
如果此时容器因为OOM等原因发生了重启，那么容器将无法启动了，因为mount的源已经不存在了。
但正常的升级是通过创建新pod，所以不会有问题。
看一下，k8s pr
解决这个问题也比较简单就是挂载前检查一下，如果源已经发生改变，就先执行umount操作，卸载。
这个bug要等到1.19后才会修复，如果大家比较着急就自己pick吧。