kubesphere3.1.1+glusterfs部署失败，PVC始终处于pending状态

nickzlm

创建部署问题时，请参考下面模板：
操作系统信息，例如：虚拟机/物理机，Centos7.5/Ubuntu18.04，4C/8G
unubtu18.04 2C/4G
Kubernetes版本信息，例如：v18.6。单节点还是多节点。
V19.8 和 V20.4都试过。多节点，其中：
2个节点安装Keepalived和Haproxy做高可用。
3个节点配置glusterfs服务器（手动尝试通过heketi-cli可以创建卷）
3个节点做为master
3个节点做为node
KubeSphere版本信息，例如：v2.1.1/v3.0.0。离线安装还是在线安装。已有K8s安装还是全套安装。
v3.1.1,在线安装，参控kuberspere3.1.1的文档全套安装。
问题是什么，报错日志是什么，最好有截图。
问题是安装到最后时刻，通过文档中的kubectl logs的报错截图如下：

web页面也无法登录，可以确定安装失败。但不知道问题出在哪里？各位大侠帮忙看看。
报错以后的信息搜集如下：

查看集群状态，PVC处于pending状态，没有pv被创建，部分pods状态一次，截图如下：
kube-controller-manager的日志截图如下：
此时在glusterfs服务器上通过heketi-cli topology info，可以看到卷在频繁反复的创建中，但磁盘空间并未被释放，直至填满，之后再无新建卷出现。截图如下：
我的集群配置文件和glusterfs配置文件如下：

kevendeng

nickzlm
GlusterFS的PV动态供应是内置在kube-controller-manager中的，根据它的日志提示，你应该检查它更详细的日志文件，进一步确认为何创建存储卷失败了。

nickzlm

重新查看了kube-controller-managede 日志，第一次报错信息如下：
E0915 23:18:20.009891 1 attach_detach_controller.go:434] Error creating spec for volume “data”, pod “kubesphere-system”/“redis-ha-server-0”: error processing PVC "k
ound phase (“Pending”) or empty pvc.Spec.VolumeName ("")
日志输出截图：

帮忙看看为啥报这个错？谢谢。

kevendeng

nickzlm
你目前所获取到的日志详细级别不够，需要将它调高。

由于kube-controller-manager是由节点上的配置文件生成的静态pod，且你的环境为多master节点，你需要在每个master节点上编辑它的配置文件：

vi /etc/kubernetes/manifests/kube-controller-manager.yaml

在其中的.spec.containers[0].command字段下新增一个命令行参数- --v=4，等待pod重启并重新选主，再查看对应leader pod的相关错误日志。

nickzlm

kevendeng 你好，
我将你说的设置加上了，之后在glusterfs服务器上将硬盘重新添加，确保有空间剩余，在16:00以后进行测试。这是查看kube-controller-manager得日志显示如下：
I0916 16:00:22.272365 1 pv_controller.go:247] synchronizing PersistentVolumeClaim[kubesphere-system/data-redis-ha-server-0]: phase: Pending, bound to: "", bindCompleted: false, boundByController: false
I0916 16:00:22.272521 1 pv_controller.go:344] synchronizing unbound PersistentVolumeClaim[kubesphere-system/data-redis-ha-server-0]: no volume found
I0916 16:00:22.272537 1 pv_controller.go:1426] provisionClaim[kubesphere-system/data-redis-ha-server-0]: started
I0916 16:00:22.272558 1 pv_controller.go:1723] scheduleOperation[provision-kubesphere-system/data-redis-ha-server-0[13255e66-8529-49e8-a090-a664d28a277e]]
I0916 16:00:22.272628 1 pv_controller_base.go:635] storeObjectUpdate updating claim “kubesphere-monitoring-system/prometheus-k8s-db-prometheus-k8s-0” with version 3439
I0916 16:00:22.272647 1 pv_controller.go:247] synchronizing PersistentVolumeClaim[kubesphere-monitoring-system/prometheus-k8s-db-prometheus-k8s-0]: phase: Pending, bound to: "", bindCompleted: false, boundByController: false
I0916 16:00:22.272682 1 pv_controller.go:344] synchronizing unbound PersistentVolumeClaim[kubesphere-monitoring-system/prometheus-k8s-db-prometheus-k8s-0]: no volume found
I0916 16:00:22.272696 1 pv_controller.go:1426] provisionClaim[kubesphere-monitoring-system/prometheus-k8s-db-prometheus-k8s-0]: started
I0916 16:00:22.272709 1 pv_controller.go:1723] scheduleOperation[provision-kubesphere-monitoring-system/prometheus-k8s-db-prometheus-k8s-0[91e3e573-9f66-40a8-bd46-d929e284ecfa]]
I0916 16:00:22.272719 1 pv_controller.go:1736] operation “provision-kubesphere-monitoring-system/prometheus-k8s-db-prometheus-k8s-0[91e3e573-9f66-40a8-bd46-d929e284ecfa]” postponed due to exponential backoff
I0916 16:00:22.272742 1 pv_controller_base.go:635] storeObjectUpdate updating claim “kubesphere-monitoring-system/prometheus-k8s-db-prometheus-k8s-1” with version 3453
I0916 16:00:22.272796 1 pv_controller.go:247] synchronizing PersistentVolumeClaim[kubesphere-monitoring-system/prometheus-k8s-db-prometheus-k8s-1]: phase: Pending, bound to: "", bindCompleted: false, boundByController: false
I0916 16:00:22.272681 1 pv_controller.go:1466] provisionClaimOperation [kubesphere-system/data-redis-ha-server-0] started, class: “glusterfs”
I0916 16:00:22.272818 1 pv_controller.go:344] synchronizing unbound PersistentVolumeClaim[kubesphere-monitoring-system/prometheus-k8s-db-prometheus-k8s-1]: no volume found
I0916 16:00:22.272827 1 pv_controller.go:1426] provisionClaim[kubesphere-monitoring-system/prometheus-k8s-db-prometheus-k8s-1]: started
I0916 16:00:22.272838 1 pv_controller.go:1723] scheduleOperation[provision-kubesphere-monitoring-system/prometheus-k8s-db-prometheus-k8s-1[366f0953-d8cf-4180-90d8-9305e666e6fe]]
I0916 16:00:22.272847 1 pv_controller.go:1736] operation “provision-kubesphere-monitoring-system/prometheus-k8s-db-prometheus-k8s-1[366f0953-d8cf-4180-90d8-9305e666e6fe]” postponed due to exponential backoff

这个信息有用吗？我把日志的输出作为附件也上传了，请帮忙看看，谢谢。

nickzlm

kevendeng 日志文件无法上传，我这边传几张日志截图吧。

nickzlm

在此期间，仍可以从glusterfs服务器上看到有块设备在不断的重复创建并占用这磁盘空间，输出截图如下：

kevendeng

nickzlm
你可以执行kubectl logs xxx | grep glusterfs | less筛选出你所关心的日志，日志级别调高以后输出的日志太多了。

nickzlm

kevendeng ，我将glusterfs的磁盘空间充值后，重新进行测试。
下面的截图是我通过以下命令获取的：

kubectl logs -f kube-controller-manager-hulk05 –namespace kube-system |grep glusterfs|less

你看看是否有可分析的信息？

这里我不太明白的是，明明glusterfs服务器上有磁盘空间，而且可以看到有卷在创建（只不过创建的卷很快又消失了，又有新的卷创建），为什么日志中会显示在创建捐的时候没空间呢？比如如下日志信息：
I0916 17:45:37.792429 1 glusterfs.go:793] create volume of size 20GiB
I0916 17:45:37.792456 1 glusterfs.go:803] provided clusterIDs [08d319152964900f70086dd0caf93dc9]
I0916 17:45:37.798970 1 glusterfs.go:821] failed to create volume: Failed to allocate new volume: No space

谢谢

kevendeng

nickzlm
no online storage device in cluster
这是使用heketi创建volume时的报错，已经不属于K8s的范畴了。

ruiyaoOps

你自己有用这个 glusterfs 作为 storageclass 创建PV pvc 并绑定pod吗？

nickzlm

之前部署的时候因为报错无法完成，我曾经手动创建PVC和pod尝试过，现象一样。这是配置文件：

nickzlm

kevendeng ，好的，我再试试看看glusterfs这边是不是有问题，多谢。

nickzlm

kevendeng ,问题找到了，是glusterfs集群中的一台服务器有一步配置没有做导致的，非常感谢你的支持。

kevendeng

nickzlm
如果有时间的话建议将具体问题以及解决方案回复到帖子中，并将该回帖标记为最佳回复，帖子打上已解决的标签。这样可方便以后有相同问题的同学快速检索。

skgwd2022

kevendeng

我也遇到这种情况的问题，但是我的是因为heketi v7.0的问题，创建失败的brick不能回收资源导致，显示的容量和空间都满了，所以不能创建pv导致pvc一直pending，使用heketi重新同步一下资源就ok，但是这样显然处理不直观，据说升级到heketi v10.0以上可以解决

yzjstc

skgwd2022 请问heketi重新同步资源怎么处理?