我有一个使用Longhorn作为存储的Kubernetes集群。最近我把一个新的工作节点加入到集群中，那个节点上的Longhorn所需的前置条件似乎都已满足。

然而，我遇到一个问题：应用程序Pod未被调度到新加入的工作节点，即使重启部署后也是如此。

可正常工作的部分

• 新加入的工作节点已成功加入集群，并处于 Ready 状态

• Longhorn组件已在新节点上运行：

• longhorn-system Pods已被正确调度

• 其他系统级组件也在运行：

• nginx-ingress（Ingress控制器）

• CNI Pods（网络插件）
• Kubernetes作业

问题

• 应用程序Pod（我自己的工作负载）未被调度到新工作节点

• 即使在以下情况下：

• 重启部署

• 调整副本数
• 调度器仍然只在现有工作节点上调度Pod

我已检查的内容

• 节点状态为 Ready
• 没有明显的资源压力（CPU/内存看起来正常）
• Longhorn节点状态正常
• 未显式添加污点（或至少我不清楚的没有添加）

现有节点上的StorageClass和 PVC运行正常

预期行为

新的工作负载（或重新调度的Pod）应该分布在所有工作节点上，包括新加入的节点。

实际行为

只有系统级Pod（Longhorn、Ingress、CNI、作业）在新节点上运行。应用程序Pod从未在那里被调度。

解决方案

你可以尝试以下步骤来排查这个问题

1. 如果你在输出中看到节点出现在kubectl get nodes的结果中，那么该节点已经是集群的一部分，但你的应用程序Pod没有被调度到那里，需要进行调试
2. 某些初始化脚本或云提供商会给节点添加一个“占位”污点，以防在节点完全配置好之前就启动Pod。

你可以使用命令 kubectl describe node <new-node-name> | grep Taints 查看节点详情中 Taints 部分的内容

如果在节点上看到任何 "node.kubernetes.io/unschedulable" 或 "dedicated=system" 类型的污点，你需要在部署中对它们进行容忍（toleration）。

要了解Kubernetes中的污点和容忍度，请阅读 https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ 3.另一种可能的原因是，如果你的应用Deployments使用 nodeSelector 或 nodeAffinity，新节点可能缺少所需的标签。

运行以下命令以查看旧节点和新节点之间的差异：kubectl get nodes --show-labels

一旦你识别出缺失的污点/容忍度、标签不匹配，你的应用程序Pod就应该能够在新节点上被调度。