自定义kube-scheduler部署后无法调度节点，请求协助排查

我之前也碰到过一模一样的问题！严格跟着官方文档部署完my-scheduler后，目标Pod一直卡在Pending状态，调度器日志里全是资源访问被拒绝的报错，折腾了好一阵才理清问题，给你几个关键排查方向：

1. 验证RBAC绑定的准确性 #

这是最容易出问题的环节，要确保ClusterRole和ServiceAccount的绑定完全匹配：

• 查看ClusterRoleBinding的subjects配置，确认ServiceAccount的名称和命名空间都正确：

  kubectl describe clusterrolebinding my-scheduler-as-kube-scheduler
  

  重点检查Subjects部分是否包含：Kind: ServiceAccount、Name: my-scheduler、Namespace: kube-system（如果你的调度器部署在kube-system命名空间）。
• 检查ClusterRole的权限规则，确保包含调度器必需的核心权限：

  kubectl describe clusterrole my-scheduler-clusterrole
  

  关键权限包括nodes的list/watch、pods的create/update/delete、persistentvolumeclaims的list/watch等，缺任何一个都可能导致调度失败。

2. 确认调度器Pod的ServiceAccount挂载配置 #

很多时候会漏掉Deployment里的ServiceAccount指定，导致调度器Pod使用默认的ServiceAccount（没有权限）：

• 查看调度器Deployment的yaml配置：

  kubectl get deployment my-scheduler -n kube-system -o yaml
  

  检查spec.template.spec.serviceAccountName字段是否明确设置为my-scheduler，如果这个字段缺失或值不对，调度器就会用默认权限运行。

3. 检查调度器的启动参数 #

自定义调度器需要明确指定认证和授权的kubeconfig参数，否则会导致权限验证失败：

• 查看调度器Pod的启动命令：

  kubectl logs my-scheduler-<pod-id> -n kube-system
  

  确认启动参数中包含--authentication-kubeconfig=/var/run/secrets/kubernetes.io/serviceaccount/kubeconfig和--authorization-kubeconfig=/var/run/secrets/kubernetes.io/serviceaccount/kubeconfig，这两个参数让调度器使用挂载的ServiceAccount凭证进行身份验证。

4. 验证待调度Pod的调度器指定 #

确保你要调度的Pod已经明确指定使用my-scheduler：

• 查看Pending状态Pod的yaml：

  kubectl get pod <pending-pod-name> -o yaml
  

  检查spec.schedulerName字段是否设置为my-scheduler，如果没指定，Pod会默认使用kube-scheduler，自然不会被自定义调度器处理。

5. 排查节点层面的限制（可选） #

如果前面的RBAC和配置都没问题，再检查节点是否有污点或Pod有亲和性规则：

• 查看节点污点：kubectl describe node <node-name>，检查Taints部分，如果有污点，需要确保my-scheduler配置了对应的容忍度，或者Pod有匹配的容忍。

我当时的问题就是Deployment里漏写了serviceAccountName，导致调度器用了默认ServiceAccount，补全后立刻就正常调度了，你可以先从这个方向排查！

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