为何持续出现‘5 pod has unbound immediate PersistentVolumeClaims’错误？Kubernetes部署Prometheus等应用的存储绑定问题问询

首先直接给你结论：是的，你需要为Prometheus Server的PVC执行和之前RabbitMQ/Node.js相同的操作——创建匹配的PersistentVolume(PV)并配置对应的StorageClass，或者配置集群的动态存储类。下面详细解释原因和解决方案：

问题根源分析 #

从你提供的kubectl describe pod输出的Events部分可以明确看到核心错误：

Warning FailedScheduling 28m (x734 over 14h) default-scheduler 0/6 nodes are available: 6 pod has unbound immediate PersistentVolumeClaims.

这个错误说明Prometheus Server的PVC（monitor-prometheus-server）找不到任何可以匹配的PV，导致Pod无法被调度到节点上。

为什么Helm旧chart没有相关指引？ #

你使用的stable/prometheus是已经被弃用很久的Helm仓库（现在官方推荐的是prometheus-community/prometheus），旧版本的chart默认假设你的集群已经配置了动态存储类（Dynamic Storage Class）——这种情况下，PVC会自动触发集群创建对应的PV，不需要手动操作。但如果你的集群没有配置动态存储类（比如本地自建集群），就会出现PVC无法绑定的问题，而旧chart的文档没有覆盖这种场景。

解决方案 #

方案1：手动创建匹配的PV #

1. 先查看Prometheus PVC的需求：

kubectl get pvc monitor-prometheus-server -n monitoring

记录下PVC的STORAGE大小和ACCESS MODES（一般是ReadWriteOnce）。

2. 创建对应的PV YAML文件（比如prometheus-server-pv.yaml），示例如下：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: prometheus-server-pv
spec:
  capacity:
    storage: 8Gi # 必须和PVC请求的大小一致或更大
  accessModes:
    - ReadWriteOnce # 和PVC的访问模式匹配
  storageClassName: your-custom-storageclass # 如果之前解决RabbitMQ时用了自定义存储类，这里要和PVC的storageClassName一致；如果PVC没指定，这里可以留空
  hostPath:
    path: /mnt/prometheus-data # 节点上的本地路径，需要确保该节点存在这个目录，且权限为777（或Prometheus进程可读写）

如果你的集群是多节点，建议使用共享存储（比如NFS）作为PV的后端，避免Pod调度到没有该路径的节点。

3. 应用PV配置：

kubectl apply -f prometheus-server-pv.yaml

执行后，PVC会自动绑定这个PV，Prometheus Server Pod就会开始调度。

方案2：配置动态存储类（推荐长期使用） #

如果你的集群经常需要创建PVC，建议配置动态存储类，这样后续部署应用时不需要手动创建PV。比如基于NFS、Local Path Provisioner或者云提供商的存储服务创建动态存储类，然后将其设置为集群默认存储类：

1. 创建动态存储类的YAML（以Local Path Provisioner为例），然后应用到集群。
2. 设置该存储类为默认：

kubectl patch storageclass your-storageclass -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

之后新创建的PVC会自动使用这个默认存储类，动态生成PV。

方案3：迁移到官方最新的Prometheus Helm Chart #

由于你使用的stable仓库已被弃用，建议迁移到官方维护的prometheus-community仓库，新版本的Chart有更完善的文档和配置选项：

1. 卸载旧的Release：

helm uninstall monitor -n monitoring

2. 添加新仓库并更新：

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

3. 安装新版本Prometheus，可根据需求配置存储：

• 如果不需要持久化存储：

helm install monitor prometheus-community/prometheus -n monitoring --create-namespace --set server.persistentVolume.enabled=false

• 如果需要指定存储类：

helm install monitor prometheus-community/prometheus -n monitoring --create-namespace --set server.persistentVolume.storageClass=your-custom-storageclass

关于Kubernetes API更新的疑问 #

这个问题不是Kubernetes API更新导致的——PVC绑定PV的逻辑从始至终都是一致的：

• 如果PVC指定了存储类，要么该存储类支持动态创建PV，要么手动创建匹配的PV；
• 如果PVC未指定存储类，会使用集群的默认存储类，没有默认存储类的话就无法绑定。

你之前能成功部署RabbitMQ和Node.js，是因为当时手动创建了匹配的PV/StorageClass，而这次用旧Helm Chart时没做同样的操作，才出现了问题。

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