AKS集群部署GlusterFS就绪探针失败问题求助

嘿，我之前在AKS上用gk-deploy部署GlusterFS的时候也碰到过类似的问题——glusterd明明正常跑着，但探针一直卡着gluster-blockd.service的检查过不去。下面是我亲测有效的排查思路和解决办法：

先确认gluster-blockd的真实状态 #

首先得钻进出问题的Pod里，手动跑一遍探针里的命令，看看实际结果：

kubectl exec -it <你的gluster-pod名称> -- systemctl is-active gluster-blockd.service

如果返回inactive或者failed，那这个服务确实没起来，赶紧查它的启动日志找原因：

kubectl exec -it <你的gluster-pod名称> -- journalctl -u gluster-blockd.service

我当时碰到的常见原因有这几个：

• 缺了tcmu-runner依赖——gluster-blockd靠它管理块设备，没这个根本启动不了
• 容器权限不够（不过gk-deploy的Pod一般都是特权模式，这个概率低）
• 存储设备或者配置文件写错了

如果你不需要块存储，直接修改探针逻辑 #

其实不是所有GlusterFS场景都要用到gluster-blockd——它是用来提供块存储功能的，如果你只需要GlusterFS的文件存储卷，完全可以跳过这个检查：

1. 找到gk-deploy生成的DaemonSet（因为GlusterFS一般是节点级部署）配置
2. 编辑探针部分：要么把探针命令改成只检查glusterd，比如：

   systemctl -q is-active glusterd.service
   

   要么直接修改容器里的/usr/local/bin/status-probe.sh脚本，把关于gluster-blockd的检查代码注释掉就行。

如果确实需要块存储，修复gluster-blockd的启动问题 #

要是你的业务依赖块存储，那得把这个服务搞起来：

• 先检查容器里有没有装tcmu-runner：

  # 针对RHEL/CentOS系镜像
  kubectl exec -it <你的gluster-pod名称> -- rpm -q tcmu-runner
  # 针对Debian/Ubuntu系镜像
  kubectl exec -it <你的gluster-pod名称> -- apt list --installed tcmu-runner
  

  没装的话，要么手动在容器里装，要么修改gk-deploy用的镜像，把这个依赖加上。
• 再检查节点内核是否支持target_core_user模块——AKS节点内核一般支持，但确认下没坏处：

  kubectl exec -it <你的gluster-pod名称> -- lsmod | grep target_core_user
  

  要是没找到，就加载模块：modprobe target_core_user（因为是特权Pod，权限应该够），然后重启gluster-blockd试试：

  systemctl restart gluster-blockd.service
  

最后检查AKS节点的安全限制 #

AKS节点可能有SELinux或者AppArmor的限制，影响systemd服务启动。可以临时关了测试：

kubectl exec -it <你的gluster-pod名称> -- setenforce 0

然后重启gluster-blockd，要是能正常启动，那就是安全策略的问题，得调整对应的规则放行。

内容的提问来源于stack exchange，提问作者Maurya M