k8s环境中ceph rbd已经被挂载问题分析解决

k8s环境中ceph rbd已经被挂载问题分析解决

背景

之前为k8s准备了ceph rbd块存储，但是最近再使用过程中发现了一个由于deployment更新导致rdb不能被正常挂载的问题。

问题描述

我们通过deployment生成一个pod，并且这个pod挂载一个rbd块存储用来提供持久化存储功能。有一次deployment更新，发现deployment先启动了一个被调度到其它node新的pod一直处于pending状态，而对于的老pod一直处于Terminating状态。导致了此次更新失败。

问题排查

通过describe新pod发现如下报错： Warning FailedAttachVolume 15m attachdetach-controller Multi-Attach error for volume "pvc-c78521e4-196e-4d7a-9858-23cf0b021d43" Volume is already used by pod(s) atd-dashboard-66958b6996-xggl4 Warning FailedMount 118s (x2 over 11m) kubelet, work4 Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[default-token-66blg yunlian-configmap data atdrtapi-configmap dashboard-configmap]: timed out waiting for the condition 通过google和官方文档发现ceph rbd共享挂载的一些特性： ceph rbd块存储能在同一个node上跨pod以ReadWriteOnce共享挂载 ceph rbd块存储能在同一个node上同一个pod多个容器中以ReadWriteOnce共享挂载 ceph rbd块存储不能跨node以ReadWriteOnce共享挂载 如果一个使用ceph rdb的pod所在的node挂掉，这个pod虽然会被调度到其它node，但是由于rbd不能跨node多次挂载和挂掉的pod不能自动解绑pv的问题，这个新pod不会正常运行 我们知道了ceph rbd共享挂载的特性，我们再结合deployment更新的特性： deployment触发更新的时候，它确保至少所需 Pods 75% 处于运行状态（最大不可用比例为 25%）。故像一个pod的情况，肯定是新创建一个新的pod，新pod运行正常之后，再关闭老的pod。 默认情况下，它可确保启动的 Pod 个数比期望个数最多多出 25%

原因

结合ceph rb共享挂载的特性和deployment更新的特性，我们发现原因如下：由于deployment触发更新，为了保证服务的可用性，deployment要先创建一个pod并运行正常之后，再去删除老pod。而如果新创建的pod和老pod不在一个node，就会导致此故障。

问题解决

1，使用能支持跨node和pod之间挂载的共享存储，例如cephfs，GlusterFS等2，给node添加label，只允许deployment所管理的pod调度到一个固定的node上。（不建议，这个node挂掉的话，服务就故障了）

参考资料

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。