Kubernetes default-scheduler报PVC不存在致Jenkins Pod Pending排查

核心问题预判 #

从你贴的输出来看，99%的概率是PVC名称、所属命名空间和Pod引用的资源不匹配，你认为"存在的PVC"并不是调度器要找的那个PVC，不存在集群存储层面的异常。

分步排查路径 #

• 第一步：核对命名空间一致性
  执行kubectl get po jenkins-0 -o yaml | grep namespace确认Jenkins Pod实际所在的命名空间。注意K8s中PVC是命名空间级资源，Pod只能引用同命名空间下的PVC，跨命名空间无法挂载。
  从现有输出看：
  • 你查到的已Bound的PVC位于g2-jenkins-test-azure命名空间
  • 你贴的PVC配置清单声明的命名空间是g2-jenkins-azure-test
    两个命名空间名字的test和azure字段顺序相反，是完全独立的两个命名空间。
• 第二步：核对PVC名称拼写
  调度器报错明确提示找不到名为g2-jenkins-azure-test的PVC，但你当前集群中已Bound的PVC名称是g2-jenkins-test-azure，两个PVC名称的test和azure字段顺序同样相反，属于拼写错误。另外你查到的Bound PVC的Used By字段显示为<none>，也能佐证这个PVC从来没被任何Pod挂载引用过，不是Pod要找的资源。
• 第三步：核对工作负载的PVC引用配置
  你的Pod名为jenkins-0，是StatefulSet管理的有状态应用，执行kubectl get statefulset jenkins -o yaml（记得加-n指定Pod所在命名空间），找到volumeClaimTemplates或者volumes.persistentVolumeClaim.claimName字段，确认配置里写的PVC名称、期望部署的命名空间是否和实际存在的PVC匹配。

修复方案 #

二选一即可解决问题：

1. 如果要复用已经Bound的g2-jenkins-test-azurePVC：修改Jenkins StatefulSet配置，将PVC引用名改为g2-jenkins-test-azure，同时将StatefulSet部署到g2-jenkins-test-azure命名空间下。
2. 如果要使用g2-jenkins-azure-test作为PVC名：在Jenkins Pod所在的命名空间下应用你贴的那份PVC清单，等待nfs-client provisioner自动完成PV创建、PVC绑定（状态变为Bound）后，Pod会自动重试调度。

兜底排查（修正上述问题后仍异常时操作） #

• 检查nfs-client-provisioner运行状态：执行kubectl get po -A | grep nfs-client找到存储供应插件的Pod，确认其状态为Running，无重启、报错日志，避免新PVC创建后一直卡在Pending状态无法绑定。
• 若确认同命名空间下PVC确实存在、名称完全匹配仍报找不到的错误，再查看kube-scheduler的运行日志，排查是否存在调度缓存不同步、RBAC权限异常的问题，这类场景出现概率极低。

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