本文主要是介绍k8s configmap subpath bug，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
下面是我们生产环境容器的重启日志，可以看到是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吧。
这篇关于k8s configmap subpath bug的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
