Kubernetes部署RabbitMQ集群时Pod卡在Pending状态无法调度

从kubectl describe pod rabbitmq-0返回的调度事件可以直接定位问题：Pod卡在Pending状态的核心原因是其关联的持久卷声明data-rabbitmq-0未完成绑定，集群内没有满足存储申请要求的可用持久卷（PV），调度器无法完成Pod调度。事件中明确提示0/1 nodes are available: 1 pod has unbound immediate PersistentVolumeClaims，和存储绑定失败的特征完全匹配。

• 先确认PVC实际状态
  执行如下命令查看命名空间下所有PVC状态：

  kubectl get pvc
  

  如果data-rabbitmq-0的状态显示为Pending，即可确认是存储绑定故障。
• 根据集群类型对应修复
  • 本地测试集群（minikube、Docker Desktop K8s、单节点kubeadm等）：这类测试集群默认没有配置动态存储供给（StorageClass），StatefulSet通过volumeClaimTemplates自动创建的PVC无法自动匹配到可用PV。两种处理方式：
    1. 快速测试场景：直接修改StatefulSet的存储配置，将/var/lib/rabbitmq挂载的持久卷临时替换为emptyDir，即可跳过存储绑定限制直接启动Pod。注意该方式下Pod重启、重建后所有RabbitMQ数据会丢失，仅适合功能验证场景。
    2. 需保留数据场景：手动创建匹配PVC容量、访问模式要求的本地PV，或者为测试集群部署本地路径动态存储供给组件，实现PVC自动绑定。
  • 云托管/生产级K8s集群：执行kubectl get sc查看集群内已有的可用存储类，检查StatefulSet中volumeClaimTemplates字段指定的storageClassName是否和集群现有存储类名称一致，修正为实际可用的存储类名称后，集群会自动动态创建对应PV完成PVC绑定。
• 验证修复效果
  配置修正后，执行kubectl get pod -w持续观察Pod状态，PVC进入Bound状态后，RabbitMQ Pod会自动完成调度、启动流程。

注：公开的这类K8s部署示例大多默认集群已经配置好可用的动态存储供给，不会专门提存储前置要求，单节点测试环境部署时非常容易踩这个PVC绑定的坑。

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